I’ve been doing some thinking about the Castle Game Engine future.

Basically, I’m excited — we’re at a point where I feel the engine is seriously great. It has been proven by developing a number of cross-platform games and demos and more are in-progress. And I feel we can seriously start to compete with other game engines, in Pascal or not, even the big ones whose names start with “U” :).

The plans, in short:

1. Release the Castle Game Engine 6.4 as soon as possible
2. Start developing a visual editor (both inside Lazarus / Delphi and as a standalone application) as soon as possible
3. Work in 2018 on the most important/requested features (in rough order): Delphi compatibility, visual editor, glTF, and looking closely at the WebGL target

More details:

1. Release the Castle Game Engine 6.4 ASAP

My initial primary goal for the 6.4 release was Delphi compatibility. I documented it publicly and made some progress (also our containers now use Delphi-compatible Generics.Collections). But it’s simply taking me a long time, partially because I’m distracted by other cool tasks on the engine, partially because I’m working on various games using the engine.

I know that many of you want the Delphi compatibility, and you have all the right to scold me for taking so long to finish it.

As for the good news, we’ve made a lot of engine improvements since the last release, 6.2. Rigid-body physics, big API improvements (new CastleVectors API, TCastleTransform class), modernizing the renderer code (which resulted in using modern shader rendering for everything, by default, and in possibility to have Phong shading and bump mapping on mobile), Apple Game Center, in-app purchases, KTX, and more smaller stuff…

Note that one the biggest new features, physics integration, was done explicitly thanks to your request on Patreon, and thus: it happened because you support me on Patreon. It would not happen otherwise (at least not so soon). I’m really grateful for that, and I hope that using the engine is as much fun for you as it is for me to extend it 🙂 Thank you!

After a bit of thinking, I decided that we will release the next version of Castle Game Engine as soon as possible, which means: try to do it in 2017, eventually do it in the first week of 2018. Yes, that soon. Looking above, we have a lot of improvements done since last release, and it’s becoming hard to keep it unreleased for me 🙂 All of my new games are using the new engine features, and I consider the current state of “unstable” GitHub code to be actually… very stable.

The Delphi compatibility of course remains on the nearest roadmap, it’s just scheduled for 6.6 release now.

2. Visual editor (inside Lazarus / Delphi and as a standalone application)

I believe that the biggest missing feature, which sets us behind some other game engines, is the lack of a visual game editor. Yet, it is something very easy to make, with the right design — so, let’s do it! I want to make a working prototype of it ASAP, release it with 6.6, and polish it within 6.8 release.

I have a couple of design requirements of the editor, and together they determine how I’m going to implement it:

1. The editor must be available as a standalone editor application. So you download Castle Game Engine and it’s not just code — it’s also a ready CGE Editor application that you can use to create a project, drop some 2D and 3D assets, invoke your favourite Pascal editor (Lazarus or Delphi), then press Build to compile a game.

   So the Castle Game Engine Editor will also wrap our build tool (to build your project for any platform, including desktop and mobile, which in turn uses FPC or Delphi compiler underneath), view3dscene (to view 3D and 2D game assets) and glViewImage (to view simple images). It can also contain some ready project templates — so instead of Clear project you can start with “3D first-person shooter” or “2D platformer” template.

   The designed hierarchy can be saved to a .cge-control files (serialized just like .lfm and .dfm), and the project uses TCastleWindow to load it (inside TUIState) and play. This is our ultimate flexible architecture to develop “pure games” applications (where OpenGL context is your only user-interface): TCastleWindow with a number of TUIState instances using TUIControl inside.

2. The editor must also be available as integrated inside Lazarus / Delphi, to edit the TCastleControl contents on a normal LCL / VCL form.

   Once the castle_components.lpk is installed, you should be able to double-click on the TCastleControl to edit the game world inside. This is quite like GLScene or FireMonkey experience — a RAD tool to edit your game right inside the environment you know and love.

   It’s actually already started:) Double-click on TCastleControl under a new Lazarus (where my patch to add ocoRenderAtDesignTime is already included). You will be presented with a question whether to add some 3D sphere to your game. This dialog will be replaced with a full-featured world editor:)

3. Finally, the editor must also be available to inspect and edit a running game. When you run the game, you can invoke the editor to inspect a hierarchy of TUIControl, including a scene manager with a hierarchy of TCastleTransform. You can view and edit the game world right there, while your game is running.

   This should provide an experience similar to running your game in game engines like Unity3d.

Once my mind was settled that I really want all the three possibilities above, the way to implement them seemed obvious: make a Lazarus component TCastleEditor, using LCL (portable to Delphi VCL), that can edit a hierarchy or TUIControl and TCastleTransform.

1. Use TCastleEditor inside Castle Game Engine Editor (done using Lazarus) to edit a TCastleWindow instance (a window that shows only a game content).
2. Use TCastleEditor inside Lazarus when double-clicking on TCastleControl.
3. When the game is compiled from the Castle Game Engine Editor, make it possible to include the TCastleEditor in the runtime, by using the LCL backend of TCastleWindow (-dCASTLE_WINDOW_LCL) and handling some key (F12?) to automatically show TCastleEditor (in a separate window, by default, maybe dockable too).

3. Plans for 2018

1. Release 6.4 with the current features: ASAP (maybe even 2017).
2. Full Delphi compatibility and a working prototype of a visual editor (covering all 3 use-cases): 6.6 release.
3. Visual engine editor fully working: 6.8 release.
4. glTF 2 support, along with PBR (physically-based rendering).
5. Look closely at pas2js progress, or WebAssembly compiler in FPC. As soon as we can reasonably adjust our code to it (e.g. it needs to support generics), port CGE to WebGL using pas2js! Yes – compile your games using Castle Game Engine to run in the browser (without any plugins). This will be huge, and I want to do this as soon as technically possible.

There are more plans of course. But the above should give you an idea where my priorities are.

4. Thank you!!!

Thank you for reading this long post. If you reached this far, maybe you would like to talk or help us with the development (not only coders are needed!). Finally, supporting me on Patreon really makes a difference, so please consider it.

Thank you all for the wonderful 2017!

1. In-app purchases on iOS! You can now sell products inside your iOS applications, through the Apple AppStore.

   We give you a very comfortable Pascal API to do this: TInAppPurchases class in the CastleInAppPurchases unit. And it works 100% for both Apple AppStore (on iOS) and Google Play (on Android), so you can really comfortably develop mobile games with in-app payments. Both “consumables” and “non-consumables” are handled.

   See the iOS services documentation.

2. We have improved the utilities and terminology around FPS (frames-per-second).

   • Read the new documentation about how to show and interpret FPS, it was improved in many ways.

   • You can now display FPS using Window.Fps.ToString. It accounts for the fact that we may be sleeping (Window.Fps.WasSleeping, possible when Window.AutoRedisplay = false), and always looks sensibly. It may show “no frames rendered” or “no need to render all frames”.

   • New --no-limit-fps command-line option is automatically handled by your games (if you let the build tool to autogenerate the program file, or you explicitly use Window.ParseParameters or Application.ParseStandardParameters).

3. You can now get world transformation of the TCastleTransform using the TCastleTransform.WorldTransform and TCastleTransform.WorldInverseTransform methods.

   While you may not often need to call these methods explicitly, they provide a very important internal feature. Every TCastleTransform and TCastleScene is now fully aware where is it placed with respect to the world, even when it is under a series of transformations. So this makes various things working correctly in all cases of transformations: the physics, X3D Billboard nodes (see e.g Text3D within the wyrd-forest demo).

4. New unit CastleDialogStates and new feature MessageOKPushesState allows you to use modal dialogs a TUIState descendants, and thus have easy modal boxes working on all platforms, including iOS. Read the manual for more information about TUIState usage.

5. Some tiny new features: build tool defines CASTLE_IOS when compiling for iOS (to easily detect any of the 4 platforms (os/cpu combinations) representing the iOS target), TCastleEdit cooperates with the clipboard (Ctrl+C / Ctrl+X / Ctrl+V work), fix logging long strings (> 4k) on Android, use Lazarus ocoRenderAtDesignTime automatically, and probably more:)

I will post some more news soon (hopefully this weekend 🙂 ), about some exciting new plans for the engine. I want to start 2018 with a bang (actually, I want to end 2017 with a bang!), and I want you to know what I’m doing. So, stay tuned for the next post where I will lay out what I’m thinking about 🙂

Now we can talk about Castle Game Engine on Discord! You’re all invited, please come and talk:)

Also, I have some ideas for new ways to show CGE using video tutorials. Some of them may be for Patrons, some may be publicly available but requested by Patrons. All ideas and comments are welcome, the post is here.

“Wyrd Forest” – Castle Game Engine demo is now available on GitHub: https://github.com/castle-engine/wyrd-forest.

Read the details about the demo features in this post.

The binaries can be downloaded from here.

There’s a lot of new stuff to announce:

1. Jan Adamec is developing a mobile view3dscene: a viewer for various 3D and 2D models our engine can handle (X3D, Collada, Spine JSON…) designed to run on Android and iOS!

2. You can use the <custom_options> in CastleEngineManifest.xml to specify custom FPC options for compiling your game.

   Thanks to Jan Adamec, you can also specify custom options on the build tool command-line: add something like --compiler-option=-dMY_SYMBOL to the castle-engine compile|simple-compile|package ... command.

3. New section in manual about optimizing PNG loading.

4. New engine demo test_bump_mapping, to easily show bump mapping (with steep parallax, and self-shadowing) with animated light working everywhere — on mobile too.

5. GLFeatures.Memory to query GPU memory information. This way you can easily detect graphic cards with lower memory (e.g. test GLFeatures.Memory.LessTextureMemoryThan(1024)), to eventually load some alternative (e.g. smaller) textures.

6. When loading Spine JSON models, the atlas name is now more eagerly auto-detected. Loading various examples from official Spine installation will now (again) work.

7. New feature allows to apply fog from SceneManager.MainScene to the rest of SceneManager.Items . See UseGlobalFog. This is enabled by default, thus potentially changing the way your game looks. I decided to enable it by default, as it’s consistent with UseGlobalLights, which is also enabled by default.

8. RenderControlToImage is a new powerful function to easily render any TUIControl (like a scene manager, TCastleSceneManager!) into an RGBA image. It uses using off-screen rendering and FBO underneath (and thus you’re not limited to your window size).

9. Thanks to Jan Adamec, you can now associate files to open with iOS application. An equivalent for Android is in-progress 🙂 See the CastleEngineManifest.xml in view3dscene-mobile for example usage. The Window.OnDropFiles callback will be called when user will use our application to open a specified file type on a mobile device.

10. Creature corpses using TCreatureResoure by default no longer collide. Change TCreatureResoure.CollidesWhenDead (or collides_when_dead in resource.xml file of the creature) if necessary.

11. Fixes and a huge optimization for CastleCreatures if you have many (like > 50) creatures on your level.

12. Jan Adamec wrote a nice documentation how to set up FPC to compile from Mac OS X for iOS and Android on. Things are a little more complicated than usual there, due to having both 3.0.2 and 3.0.3 compilers.

13. The option --fpc-version-iphone-simulator of the build tool is auto-detected now by default. So it will be 3.0.5 for FPC 3.0.4, and thus work correctly out-of-the-box in more cases.

14. Also, look what Michalis is doing right now: Wyrd Forest – terrain and spawning fun 🙂 See code on GitHub.

Fun using Castle Game Engine terrain generation and spawning animated trees 🙂

This is the beginning of a “Wyrd Forest” game demo, done as a demo of Castle Game Engine, sponsored by Patreon. If you want to see more of such demos, please support us on Patreon!

The game source code and data, all open-source, are on https://github.com/castle-engine/wyrd-forest .

1. We have a new class TCastleTransform that can be used to group and transform scenes, using properties like Translation, Rotation, Scale, Direction, Up.

   • This class replaces previous classes T3D, T3DList,T3DTransform, T3DOrient, T3DCustomTransform, merging all their functionality. The ability to “group and transform” is so basic feature that the previous split into multiple classes was uncomfortable.

   • This way you can freely switch between adjusting rotation directly (using Rotation, as axis vector + angle) or Direction and Up (that specify rotation versus a default orientation of your models, which is of course configurable).

   • The TCastleTransform class is now an ancestor of TCastleScene. So you can easily transform TCastleScene e.g. by Scene.Translation := Vector3(1, 2, 3);.

   • The TCastleTransform class is also used as the ancestor of SceneManager.Items list. So you can easily transform your whole world, e.g. scale everything down by SceneManager.Items.Scale := Vector3(0.1, 0.1, 0.1);. (Be careful though — transforming the SceneManager.MainScene is not supported yet, so you cannot use the above example if you use SceneManager.MainScene for default camera.)

   • Also, TCastleTransform has a nice name, correctly suggesting that it’s useful for both 3D and 2D games 🙂 As usual, 2D in our engine is just a special case of 3D, and I’m writing everything to be comfortable for both use-cases.

2. The GLFeatures.EnableFixedFunction is now false on desktops with modern GPUs (with OpenGL >= 2.0). This means that the rendering, by default, uses modern implementation that is more flexible and can be even faster.

   Remember that, in order to see even better shading, you can use “Phong shading”, either for the whole scene (Scene.Attributes.PhongShading := true;) or only for a particular shape (Shape.Shading := shPhong;), see shading methods documentation. By default we use Gouraud shading, which is uglier but faster.

   The new rendering method (based purely on shaders) should generally produce the same or better results as the old method (which was using a mix of fixed-function and shader approaches). It is more flexible, and may be even faster on modern GPUs. But there are some possible “gotchas”:

   1. If you have implemented custom rendering using immediate-mode OpenGL commands (in overridden LocalRender, or Window.OnRender) then you possibly depend on some deprecated state being set by the engine.

      The simplest solution is this case will be to reenable GLFeatures.EnableFixedFunction for now. Just set GLFeatures.EnableFixedFunction := true in Window.OnOpen or Application.OnInitialize (you want to do this early, but after OpenGL context is created).

      The more long-term solution is to upgrade your custom rendering to work with the new system. In most cases, you should not render things yourself using OpenGL — instead handle everything by loading appropriate 3D models into TCastleScene. The models can be in X3D format, with shader effects and many other fancy stuff. In general, let us know on the forum if you have a specialized need and are not sure how to upgrade.

   2. The fixed-function Gouraud shading was using two-sided lighting. The new shader pipeline makes one-sided lighting in case of Gouraud shading, for speed.

      One solution is to flip the side that receives lighting by flipping the ccw field at your geometry node (like IndexedFaceSet). The other solution is to use the “Phong shading” (that always does two-sided lighting), either for the whole scene or only for the particular shape — see instructions above.

   3. Finally, some old GPUs with buggy OpenGL implementations may be affected by this. We tried to protect from this (GLFeatures.EnableFixedFunction remains true if OpenGL version is less than 2, even if GL supports extensions for GLSL)/ But if you find a case when GLFeatures.EnableFixedFunction really needs to be enabled even on OpenGL > 2 (because otherwise rendering using shaders is buggy), please submit it to us (through the forum or as an issue on GitHub).

      Please attach the OpenGL version (and renderer and vendor) on your system — you can see it in the output of GLInformationString function, which is also dumped to the log file if you use InitializeLog in your game. You can also see it in the view3dscene message for Help->OpenGL Information.

   Note: If you use shadow volumes, they will still use fixed-function pipeline. This, and some other planned improvements to renderer, is documented here — contributions to improve this are welcome!

Share this:

• Facebook
• Twitter
• LinkedIn
• Reddit
• Email

1. We already posted about our new upcoming game “The Unholy Society”. Some more background:

   Our little indie game studio “Cat-astrophe Games”, making games using “Castle Game Engine”, has just signed a contract with a great Polish publisher “Fat Dog Games”. That means that we have someone who will pay our bills while we develop games using “Castle Game Engine” !

   And this means that I, as of today, can work 100% of my time on “Castle Game Engine” and games using it (“The Unholy Society”, and also “Escape from the Universe” for iOS soon). Many things will happen, in more-or-less this order:

   • Expect some iOS improvements in November, for “Escape from the Universe” for iOS.

   • Expect Delphi compatibility in CGE. I know I did not post about it lately, but it is still the main feature of the upcoming CGE 6.4. release! More plans about CGE are listed here — I “live by this list” since a long time, trying to prioritize my life to achieve these engine features.

   • Expect various engine improvements caused by “The Unholy Society”: Steam integration. Spine support improvements (animated meshes, shearing, probably Bezier curves). And I will make (probably as a separate project on GitHub) a Yarn dialogue reader and player (Yarn dialogue was used e.g. in a fantastic “Night In The Woods” game).

2. Engine improvements that happened lately:

   • (Work in progress) We have a new class TCastleTransform, that unifies and simplifies previous classes T3DTransform, T3DOrient, T3DCustomTransform. It is also the ancestor of TCastleScene, so finally you can just do Scene.Translation : ... without the need to wrapp the TCastleScene in a T3DTransform instance.

     There are still some bits in-progress here. I’ll write more when it’s finished.

   • Improvements to setting X3D fields comfortably: SetXxx on various TMFNode classes, e.g. SetParts, SetShaders.

   • Partially workarounded Lazarus CodeTools problems with new generics. Unfortunately, Lazarus CodeTools do not handle Delphi generics OK, yet. So Generics.Collections cause problems. Also CastleUtils unit on FPC 3.0.x causes problems (but not with FPC 3.1.1.)

   • Sound engine sources are now updated better (without the need for TCastleSceneManager).

   • Lazarus packages always use inline now (it was disabled for some time). So things will be faster.

   • TCastlePrecalculatedAnimation was removed from the engine. It was deprecated before 6.0 release. Simply use TCastleScene to play *.castle-anim-frames or *.kanim files.

   Share this:

   • Facebook
   • Twitter
   • LinkedIn
   • Reddit
   • Email

1. Adding new renderer to the engine

I sometimes get questions “Will there be another renderer available in the Castle Game Engine?”. My answer was always this: “Yes! Contributions for this are most welcome. It is just not my own priority now, because the current renderer (using OpenGL / OpenGLES) works great, and it works on all platforms.”

To make it easy for everyone to actually start experimenting with a new renderer, I wrote a simple example code that shows how you can start a new renderer. Just fill the TVulkanWindow.Open and TCastleSceneVulkan.LocalRender and test on any 3D model 🙂

And if you have something (even just a start!) ready, don’t forget to show it on our Discord or forum (bonus points if you will already show a CGE fork on GitHub where it can be tested). This will make Michalis extremely happy:)

2. OpenGLES: suggestions for new contributors

If you know your way around 3D coding, and you’re looking for interesting tasks to implement in the engine, please take a look at our OpenGL ES (Android and iOS) TODOs. This page describes 6 features that are implemented in OpenGL, but are not (yet!) implemented in the OpenGLES version.

Some of these tasks are “relatively easy (and fun!) with high reward“. You can make a cool graphic effect working on Android and iOS. The groundwork is already done (since it’s a feature already working for OpenGL), and your job is to adjust the code to work also on OpenGLES. E.g. you can activate shadow volumes on OpenGLES just by changing the current fixed-function shadow volume rendering to use shaders (the desktop OpenGL rendering will be upgraded by this too, of course — we don’t need a fixed-function implementation of shadow volumes at all).

3. Renderer improvements implemented lately

• Gouraud shading in the shader pipeline now honors ccw field correctly. The Gouraud shading performs one-sided lighting, and now you can control which side receives the lighting using the ccw field, see the link for details.
• 2D rendering (TGLImage, DrawPrimitive) since some time uses shaders by default on desktop OpenGL.
• Occlusion query (Scene.Attributes.UseOcclusionQuery) does not use the fixed-function pipeline anymore.

Castle Game Engine is now integrated with the Apple Game Center on iOS! The new TGameService class handles both Google Play Games (on Android) and Apple Game Center (on iOS) with a common API.

New documentation how to use iOS services, with apple_game_center, is here.

A working example is within the examples/2d_dragon_spine_game/, in particular see the Game.pas that implements the game logic and achievements.

Also, CastleMessaging unit was ported to iOS (this is used by various Android/iOS services), and various other “infrastructure” changes were made to enable implementing “services” nicely on iOS.