![]() |
![]() |
![]() |
Hello everyone! I hope you have a peaceful time at the end of December and spend it doing what you love — whether it means developing games, or playing games, or just resting (and thinking about games) 🙂 I wanted to share some of the recent engine developments and plans for the nearest future.
- First of all, I have to admit I failed. I had a secret plan to release a new engine version Castle Game Engine 7.0-alpha.4 before Christmas. This didn’t happen — due to a number of tasks (and one food poisoning…) that consumed my time in December.
On the upside, I already made arrangements to have more time for engine development since January 2026, and I shall have much more time since April 2026. I’m looking forward to a productive 2026.
-
And this feels like a natural way to mention that going forward we very much count on your support. If you enjoy using the engine please support us on Patreon. More ways to donate are available as well. Thank you in advance!
-
If you are interested in business 2 business cooperation, note that we have an official company dedicated to the Castle Game Engine development. We’re a regular Polish (EU) company and are happy to provide e.g. support work to help your company use the engine best.
-
Recent engine developments:
- We’ve made 2 skinned animation improvements:
- We fixed how it interacts with shadow maps. The shadows (cast by skinned animated mesh) in shadow maps are now correct.
- We improved our shader implementation, to be capable of handling practically any number of joints (no more 128 limit), by passing joint information through a float texture. We tested that it doesn’t cause any slowdown even in extreme cases.
- We support the
PointPropertiesX3D node.- Our docs of PointProperties support are here (see the bottom).
- Our testcase of PointProperties.
- Note that in Castle Model Viewer, the basic browser-specific point size is in “File -> Preferences -> Point Size…”, default 3.0. The value determined by
PointPropertiesfields (pointSizeScaleFactor,pointSizeMinValue,pointSizeMaxValue) multiplies this “nominal” value. - X3D specification of PointProperties.
- We have updated our Nintendo Switch integration to support the latest engine version. This may or may not have been related to the fact that I was playing a bit Zelda: Breath of the Wild over Christmas 🙂
- We’ve made 2 skinned animation improvements:
-
Our nearest plans:
- Release 7.0-alpha.4, naturally. With new skinned animation done, we have finalized our most important feature, and we have collected a lot of other good progress since last release (which was August 2024, quite some time ago).
-
I want to use SignPath to sign our Windows releases. They have already accepted us in their open source program, thanks to this we can have Windows binaries signed for free.
-
I want to switch our macOS releases to just be using macOS Silicon (i.e. Aarch64) for everything. And bundle with FPC for macOS+Aarch64, ship with binaries (build tool, editor) for macOS+Aarch64.
- Rationale: Our current macOS releases are still for macOS Intel (i.e. x86_64), and we rely on users to setup cross-compiler to macOS+Aarch64. But this is troublesome and buggy in some setups. It is also unnecessary additional work — since the macOS world has largely migrated to Aarch64, and Apple is explicit that Intel goes away (last macOS that supports Intel has been already released). So we should just offer macOS+Aarch64 experience, with everything working out-of-the-box on macOS+Aarch64, as 1st priority. We will still offer macOS+Intel builds too, relying on your support to test them.
- I’m also going to work more on our Codeberg mirror. It is already auto-synched with GitHub and you’re happy to download our code from there (or submit PRs there!). I want to test their Codeberg CI.
- Rationale 1: I’m worried about GitHub. They put a lot of their resources in AI-related development, and some of the outcomes seem to me over-hyped. And AI results can be seriously misleading — as they are often wrong, but presented with confidence. More guidelines about using AI from me are here (including positive notes how it can benefit your workflow) and 2 links to some negative AI usage examples in CGE context are here.
-
Rationale 2: I very like Codeberg mission. Fully open-source infrastructure and community consensus in what they do.
-
Thinking more about actual game engine features instead of infrastructure stuff (a lot of it above), our plans are clear for some time:
- We need to make our shadow maps better.
-
Our web target is great, I’m going to put more work into it.
-
Our roadmap is good and we should just do it !:)
That last point, our roadmap, leads to our conclusion: I think we have a good plan for the engine. And I love what I’m doing 🙂 From your good words, I think that you enjoy it too. We just need more resources (time) and we’ll be golden. If you can, please support us. Small donations sum up into actual money that allows me to simply spend time developing the engine, thus fueling all this development. Thank you!
And thank you for being part of this dream of having a 100% open-source game engine with features like a clean language, modern graphics, support for 3D standards, being cross-platform and enjoying a visual editor. Have fun developing games and have a great 2026!



Start the discussion at Castle Game Engine Forum