I hope you enjoyed the packed series of Castle Game Engine news last week.

It’s time for the first news in 2022: summary of 2021 and plans for 2022!

Before we start, I want to thank everyone who contributed to the engine in 2021. Together, we work on making a great open-source game engine. I have really big plans for what we can achieve in the future. Thank you for joining me in this!

Most important things we did in 2021

1. 7.0-alpha.1 release with loads of new features.

2. Sprite Sheet editor, to easily design and use sprite sheets (see news).

3. Many improvements to TUIState possibilities, docs, creating new state in editor.

4. TCastleBehavior, a way to enhance TCastleTransform behavior.

5. Designing fonts, sounds, other non-visual components in the editor.

6. Primitives like box, sphere, 3D text in editor for easily designing.

7. Many platformer demo updates, it is also on itch.io now.

8. While not yet part of CGE repo, we have 2 approaches for particle effects in CGE being developed.

9. Inspector available under F8 in any debug game.

10. Delphi port, merged to CGE master now.

11. Integration with Vampyre Imaging Library.

Plans for 2022

Definitely:

1. Editor improvements for 3D and 2D levels design:

   1. Better camera/navigation in the CGE editor. Like in most other 3D applications, the “camera that will be used at start of the game” should be a normal 3D entity in the world, separate from “camera that is used at design-time”. See TCastleCameraTransform in examples/creature_behaviors/code/ for start of it.

      Right now, design-time camera/navigation and runtime camera/navigation are the same, which makes it esp. cumbersome to switch navigation for design-time when you don’t want to change the mode for runtime.

   2. Ability to modify lights in CGE editor. New classes TCastlePointLight, TCastleSpotLight, TCastleDirectionalLight, TCastleEnvironmentLight.

      Right now, you have to set up lights in 3D authoring software (like Blender), and export to glTF. At runtime you can modify lights using X3D nodes for lights.

   3. Ability to modify materials in CGE editor of the TCastleScene. Materials present is scene (with names derived from underlying names in glTF, X3D etc.) should be slots that you can configure in the editor. This should also extend currente material config at primitives, like TCastleBox and TCastleSphere.

      Right now, you have to configure materials in 3D authoring software (like Blender). At runtime you can modify materials using X3D nodes for materials.

   4. Physics components (TRigidBody, TCollider and descendants) expressed as behaviors, and with auto-size by default. You should be able to design and test CGE physics in our editor.

   5. Utilities for typical 3D games (CreatureCreatures / CastleResources / CastleLevels / CastleItems / CastlePlayer) should be replaced with a better API and everything should be easy to make in editor. See planned features.

      New class TCastleMoveAttack and remake examples/fps_game/ demo to be designed 100% in editor.

2. Official Steam integration in CGE. We already used it for The Unholy Society, we want to either “just publish that approach” or propose a new, improved (without an intermediate “wrapper” library) approach.

3. Nodes optimization. Our current X3D nodes are unnecessarily heavy on memory. This matters in some cases, if you’d like to compose your game world from lots of scenes. This is already in progress, provoked by issue #285.

4. Documentation and promotion:

   1. Upgrade of the main page to emphasize our features.

   2. Upgrades of the documentation to describe the editor, as I outlined in previous post.

   3. We need to gain more users of the engine. Esp. now that we have Delphi compatibility, which opens us for more devs.

5. Engine 7.0-alpha2 release ASAP (in January 2022, after some documentation updates).

6. Engine 7.0 release in 2022!

7. WebGL port, using recently announced FPC WebAssembly target!

   Yeah — we already planned WebGL port using pure pas2js. Using FPC+WebAssembly means that it is easier to do and result will be more efficient.

Maybe:

1. Physics abstraction layer, with alternative physics engine being Bullet.

2. Rendering abstraction layer, with alternative renderer being Vulkan.

3. Explore USD – Universal Scene Description support, as a first-class citizen, alongside glTF and X3D.

4. Terrain designer, see planned features.