Last Sunday, I gave a presentation about Castle Game Engine at the Game Industry Conference. I think it went really well — a lot of people came, I had a lot of positive feedback and good questions. I felt that a lot of work we put lately into making the engine not only packed with features, but also really easy to use, paid off!

The slides from the presentation are available here, and embedded in them are 4 short movies (physics, 3D game, 2D game, code). Enjoy!

Note that I used physics branch to demonstrate the physics components (not yet merged to master, just due to my obsession to review everything perfectly 🙂 ). Everything else you see there is available on CGE master already.

I also bring back some thoughts and conclusions:

• Confirmed TODO: The hierarchy on the left is getting a little overcrowded when we put lots of behaviors (like rigid bodies and colliders) together with transformations. The current state may be acceptable at start, but eventually we should improve this. This is a UI thing — we can organize it better and we will, we already talked with Andrzej Kilijański about it.

• Confirmed TODO: WebGL port is important 🙂

• My new idea (this one is not from feedback to my CGE talk, but it is a combination of 2 ideas from 2 talks I had at GIC):

  We should have a demo in CGE showing a huge city and loading neighboring pieces of the city asynchronously. This idea came to me during “Open World Streaming in Dying Light 2” talk — I believe the core idea is something completely doable in CGE (and testable on a 3D big city generated from ready buildings (with interiors) in CGE example).

  This idea clicked with something I learned thanks to meeting Grzegorz Wojciechowski also at GIC. He’s doing amazing things with OpenGL, among them — spreading work into multiple processes and threads at the engine layer. He made me aware that you can load things asynchronously, in another thread, into OpenGL!, if you do this in another OpenGL context that is shared with your main (rendering) context. And in CGE our TCastleWindow and TCastleControl already always do sharing (because it makes caching natural for multi-window applications), so we got this!

  This is a very possible and within-reach solution to a promise “Asynchronous loading will be possible some day” made in our Threads usage manual chapter.