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:
- Release the Castle Game Engine 6.4 as soon as possible
- Start developing a visual editor (both inside Lazarus / Delphi and as a standalone application) as soon as possible
- Work in 2018 on the most important/requested features (in rough order): Delphi compatibility, visual editor, glTF, and looking closely at the WebGL target
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.
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:
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-controlfiles (serialized just like
.dfm), and the project uses
TCastleWindowto 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):
TCastleWindowwith a number of
The editor must also be available as integrated inside Lazarus / Delphi, to edit the
TCastleControlcontents on a normal LCL / VCL form.
castle_components.lpkis installed, you should be able to double-click on the
TCastleControlto 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
TCastleControlunder a new Lazarus (where my patch to add
ocoRenderAtDesignTimeis 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:)
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
TCastleEditorinside Castle Game Engine Editor (done using Lazarus) to edit a
TCastleWindowinstance (a window that shows only a game content).
TCastleEditorinside Lazarus when double-clicking on
- When the game is compiled from the Castle Game Engine Editor, make it possible to include the
TCastleEditorin 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).
- Release 6.4 with the current features: ASAP (maybe even 2017).
- Full Delphi compatibility and a working prototype of a visual editor (covering all 3 use-cases): 6.6 release.
- Visual engine editor fully working: 6.8 release.
- glTF 2 support, along with PBR (physically-based rendering).
- 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!