TUIState is now TCastleView, methods to change the view are now part of Container, new slick UI when opening the project

Posted on

Platformer game view
Editor UI to open existing views

We have an important change to one of our most important concepts: states (TUIState descendants) are now called views (and descend from TCastleView).

It’s a change in terminology, and a change in API. While previously you were changing states using class functions and properties, like TUIState.Current := Xxx, now you should use regular container methods, like Container.View := Xxx.

Oh, and to this we add a new slick UI when opening the project 🙂

Why?

It addresses two things:

  1. The name “state” was too generic and thus meaningless. Almost every variable and object instance in your application can be called some “state”.

    It made sense if you think “user interface state” or “state of a state machine… but the sole word “state” is too generic.

    Moreover, TUIState class name is not consistent with CGE naming. And TCastleUIState or TCastleUiState are too convoluted. So for a long time I knew it will have to be renamed to TCastleState or TCastleView. I finally finished the work to go with TCastleView.

    “View” doesn’t seem too bad name. It clearly communicates it’s something visual and is a way to “see” CGE stuff. And, view isn’t that often used as a noun, so when someone says “This view is amazing” you can fairly safely assume they talk about TCastleView (assuming you’re in the middle of CGE manual, not on a hiking trip 🙂 ).

    It is consistent e.g. with React view.

  2. The way we changed states, using TUIState class methods/properties, could be improved to use simple methods on Container.

    This way there’s often no need to know what is the “central” container (TCastleControl.MainControl is now deprecated) and every container has it’s own, separate, state stack (or rather: view stack now). This makes things simpler if you try to use multiple containers or TCastleControl (whether for LCL, VCL or FMX). You can just do

    instead of

    This is already reflected in new TCastleControl docs.

Upgrading

This change is 100% backward-compatible. The old code will continue to work, though we advise you to upgrade to new names and container methods/properties.

In total, the upgrade path in typical applications is rather straightforward, although it will require to do a lot of replacements (I recommend to commit everything to your version control before doing the upgrade, and then have a nice diff to audit with state->view upgrade):

  1. Rename TUIState -> TCastleView.

  2. Remove CastleUIState unit from your uses clause. Make sure unit CastleUIControls is there (it likely is there already).

  3. Change in ApplicationInitialize:

    to

  4. Change in various states (views):

    to (respectively)

  5. Optionally, as a final touch: rename your units and designs.

    Previously we called them gamestatexxx . With class like TStateXxx, with variable like StateXxx.

    Now we advise to call them gameviewxxx . With class like TViewXxx, with variable like ViewXxx. If you choose to go with rename, you will likely find that a general interactive rename state->view, and accepting 99% of the replacements, it the way to go.

    You can just rename them everywhere. Remember that the unit also refers to the design, doing something like

    So if you rename both the unit and design (which we recommend, to keep F12 working nicely in CGE editor) then change also that line of code to

New editor UI when opening new project

This is accompanied by a cool upgrade to our CGE editor UI. It happened because of independent reasons (I did UX testing on a live human at Christmas :), and came back with lots of nice conclusions) but it is nicely connected with the whole views terminology.

Now, when opening any project, you will be greeted with a UI to

  • compile and run / stop the project
  • create a new view (Pascal unit and design)
  • open an existing view

This UI emphasizes your most recommended actions after opening the project.

Docs

Our documentation, including important chapters about view events and managing views, has been upgraded to new terminology.

Our examples are also fully upgraded now to use view terminology everywhere.

Comments on the forum (4) ➤

“Lynch” gamejam game release on itch.io, nice example code for footsteps and some creepy game logic

Posted on

"Lynch" game
"Lynch" game
"Lynch" game in CGE editor
"Lynch" game in CGE editor
"Lynch" game in CGE editor

“Lynch”, my gamejam game done using Blender and CGE, is now on itch.io — https://cat-astrophe-games.itch.io/lynch. Easy download for Windows and Linux.

The full source code and data are available on GitHub.

I did some cool post-gamejam improvements:

  1. Added sounds: new ambience, footsteps, statue sound.

    The demo code shows my recommended approach to add footsteps sound for 3D walking game, see the TFootstepsBehavior class in GameBehavior unit.

  2. Added 2 water surfaces.

  3. Added some creepy logic for the statues behavior 🙂

    The code of it is again quite nice and you can reuse it for your projects. It is in GameBehavior unit. I will let you figure out on your own what is exactly this “creepy logic” :), just play the game!

  4. Fixed octree creation (the roof was extremely high-poly by accident, at it was causing problems).

    I also added better facility to debug such things in CGE. Octree creation for shapes happens now reliably on load, and you can debug what is taking the most time by using our profiler. Just set Profiler.Enabled := true and look at log.

Comments on the forum ➤

Summary of 4th open meeting – physics, Pascal LSP, Android on-screen keyboard, near release plans, QuickJS; announcing 5th meeting

Posted on

4th Open Meeting
4th Open Meeting
4th Open Meeting

With so much going on around the engine, I barely have time to write it all down in news 🙂

First of all, we had our open meeting on Discord 2 weeks ago. A short summary:

  1. I showed our new physics features. You know, the things merged in that huge merge right before the meeting 🙂

    (Since the open meeting, I have actually merged the 2nd big part of this work: physics joints!)

    The documentation how to use physics is available along with a lot of examples in the engine examples/physics subdirectory.

  2. I showed our Pascal LSP, to provide intelligent code completion in Visual Studio Code and other editors.

  3. I showed other small features:

  4. We showed some things in progress:

  5. I described some plans. I guess the most important — release a new CGE version around Christmas (hey, so it’s really soon! 🙂 ).

    Then release 7.0 in January 2023. Most important things to finish: new materials components, AI behaviors, Steam integration.

  6. Then Coldzer0 gave us a great update about the progress about using Castle Game Engine from JavaScript through QuickJS.

    It exposes a really nice and comfortable JS API. And you can create instances, assign callbacks, and generally have the same power as CGE in Pascal.

    More information about it will come as available. My recommendation: look into scaling the implementation, to account for our 100+ classes and components :), and look into porting e.g. “3D FPS Game” template to JS.

I would like to immediately announce next open meeting: 5th Open Meeting: Spring 2023. Join us March 18th (Saturday), 2023. At the usual hour 15:00 UTC. Go ahead and click on the link to the meeting on Discord, there you can click “I’m interested”, see it in your timezone and add to the calendar.

Comments on the forum ➤

Watch tomorrow Castle Game Engine presentation at Embarcadero CodeRage 2022

Posted on

Enterprise CodeRage 2022

You’re welcome to watch Michalis presentation tomorrow, December 21, at Embarcadero Enterprise CodeRage 2022.

The topic of the presentation is using Castle Game Engine as a 3D visualization tool that you can add to the existing Delphi applications. As part of it, I also want to show for the first time a new feature, requested a few times by Delphi users — yeah, you guessed it, a CGE control you can put on FMX or VCL form! Of course, the talk will also feature a general overview of the engine capabilities, regardless of how you want to use it.

The hour is 3:00 PM in CST (Central Standard Time (US)).

The event is free, you can register a seat following this link or just watch a live stream on YouTube Embarcadero channel.

Comments on the forum ➤

My mind is blown. I can use AI to generate Castle Game Engine code to integrate it with PhysX. I can use AI to generate HTML documentation from comments in Pascal code.

Posted on

ChatGPT generating Pascal code integrating PhysX with Castle Game Engine
ChatGPT generating Pascal code integrating PhysX with Castle Game Engine
ChatGPT generating HTML documentation for Pascal source code
ChatGPT generating HTML documentation for Pascal source code
ChatGPT generating HTML documentation for Pascal source code

My mind is completely blown by the capabilities of OpenAI chat bot ChatGPT. It can tell jokes, invent stories and protagonists, write documents with game pitches, play an RPG game with you, pretend to be a virtual machine with an access to an Internet in a weird alternate universe (I checked, it works, you can even do wget https://castle-engine.io in that universe)…

Here are some interesting experiments with relation to Castle Game Engine and Pascal.

Integrating Castle Game Engine with PhysX

PhysX is a physics library from NVidia. It is not integrated with Castle Game Engine as of now. We use Kraft physics engine in CGE now.

As far as I know, no one has ever attempted so far to integrate PhysX with Castle Game Engine. Internet search doesn’t show any results even for PhysX in any Pascal application.

Yet AI can write ready code to do it..

My prompt: Write Pascal code implementation integrating PhysX with Castle Game Engine.

Bot answers:

It also added a short explanation. See the screenshots.

AI just integrated 2 libraries, never ever before integrated in the whole history of the universe.

Sure, there are a lot of problems with this code. It doesn’t really compile, the usage of TVector.One is wrong, there’s no unit called CastlePhysX

But it’s like written by a programmer that knows CGE, knows PhysX and understands the core of the task. And was just too lazy to check on some API details.

  • It is using CGE vectors API,

  • It is using PhysX API (DuckDuckGo confirms that PhysX has concepts like PhysXWorld, PxTransform, PxRigidDynamic).

  • It runs the simulation ~60 times per second, and uses Pascal Writeln to output the result. It added initial velocity to the object, to observe that it changes position. This is exactly what I would do in my first attempt at such application, to test the integration.

Next day, I realized I can ask it to fill the remaining stuff. I can say things like “Given the Pascal example as below: … , implement CastlePhysX unit”. Yes it works. I still didn’t reach a complete code that compiles… but wow. This is impressive.

Generating HTML documentation from Pascal source code (like PasDoc)

Let’s try something else. Let’s make it perform the job of PasDoc.

My prompt: Generate HTML documentation for the Pascal class declared as below:

(here I pasted actual long multi-line code declaring the TCastleButton class, cut down to public and published sections)

Answer with complete HTML code that can be easily copied and pasted.

It answered…

Next prompt: Show me the HTML markup of the above.

Bot answered with HTML markup…

Here is the HTML markup for the documentation of the TCastleButton class:

Yes, it’s a real HTML code. It’s cut — just a limitation of free ChatGPT version I guess, they limit the length of the answer.

It performed the basic job of PasDoc (convert Pascal code with comments -> HTML)….

Holy f**.

Comments on the forum ➤

Gamejam game using Blender and Castle Game Engine – “Lynch”

Posted on

"Lynch" gamejam game
"Lynch" gamejam game - in Castle Game Engine editor
"Lynch" gamejam game - in Castle Game Engine editor
"Lynch" gamejam game - planting trees
"Lynch" gamejam game - in Blender
"Lynch" gamejam game
"Lynch" gamejam game - in Blender

We held a gamejam in our Cat-Astrophe Games studio this Friday and I decided to make a short “walking simulator” game to refresh my Blender skills and of course test that the result works in Castle Game Engine!

The resulting game is on https://github.com/michaliskambi/lynch . It’s very much unfinished, I overestimated what I can do in a short amount of time — but I also learned a lot: using Archimesh, using Geometry Nodes, and generally I think I managed to made OKayish 3D model of a house + surroundings with reasonable proportions in game.

Enjoy the screens and (really trivial) code 🙂

P.S. The prominent pretty 3D asset comes from Bronze figurine of Cthulhu, from Sketchfab, by Jedi2583.

Comments on the forum ➤

Physics merge (pull request with 552 commits)! See you this Saturday on our open meeting!

Posted on

Physics forces visualization

After lots of work from Andrzej Kilijański and myself (started back in February this year), the big new physics features have landed! They are merged to the master branch of our Castle Game Engine now.

A full news announcement will be released once I’ll get some sleep :), short version:

  • new components to setup rigid bodies / colliders (also in the editor),

  • forces API,

  • 3rd-person navigation improvements to also be able to use physics,

  • buttons to run simulation from editor,

  • and much more…

Preliminary new (rather short now) docs are here.

I could direct you to the list of commits in the PR, but it’s too big to browse nicely on GitHub, so let me try to crash our website by pasting the result of git log master..physics > physics-log.txt below 🙂

And remember we have a 4th open meeting this Saturday. The meeting will take place at the usual hour (15:00 UTC) on our Discord. You can go to the meeting already and click there “Interested” and add it to your calendar. See you there! I will of course, among other things, present the new physics.

And now:

Comments on the forum (1) ➤

Fixes to 3rd-person navigation, UI outline and groups, LSP range check error

Posted on

third_person_navigation demo

Fixes to third person navigation component and example:

Fixes to UI:

LSP server:

Comments on the forum ➤

Dark Mode design :)

Posted on

Castle Game Engine Dark Mode design

I can’t count anymore how many times I’ve been asked “when is the Dark Mode coming to CGE editor” 🙂

One answer is: It is already possible. We use LCL and our editor just follows your OS (Windows, GTK, …) theme. If you switch your system theme to something dark, then all your applications (including CGE) will become dark. There are small improvements to it in the physics PR too — I hope to finally finish and merge it this weekend!

Another answer is: We will get to the dark mode (in a cross-platform way, that can be activated specifically for CGE editor) one day, just because we have to 🙂 No matter how hard it may be with LCL.

Here’s a dark mode design by Adrianna Matejek. Thank you!

Comments on the forum (1) ➤

Documentation enhancements: using children components, API and code conventions about memory management, nils, BeforeDestruction and more

Posted on

Raspberry Pi Pico by abdoubouam from https://sketchfab.com/3d-models/raspberry-pi-pico-79aba8c863a14b4682e34e241f2159d2

We have a number of enhancements to our 2 large documentation pages (targeting mostly advanced engine users / developers):

  1. Custom Components documentation was extended with description how do we advise to create children components in your custom components. This is useful when you want to create a new component, register it in CGE editor, and you want to use existing components as children.

    1. You can have internal children (using SetTransient).

    2. You can create regular components in OnCreate method that the user can later completely change and even remove (free).

    3. You can have subcomponents (where user can configure properties, but shouldn’t free / assign a different instance).

    All cases are documented with example code.

  2. We have a big Coding Conventions page that documents a lot of low-level and high-level guidelines about how the engine is developed. It starts with some mundane stuff (like indentation — 2 spaces, never tabs!) but later discussed more interesting topics that I recommend to read:

    1. Our guidelines for BeforeDestruction usage. Big thanks for Andrzej KilijaÅ„ski for talking it over with me — it’s a very powerful mechanism when combined with clear guidelines when to use it.

    2. You can (and should) free the things you allocated; you should never free other things, unless explicitly allowed.

    3. What can be nil.

    4. Declarative API (classes with independent properties) is simple to use.

    5. Optimize smartly: profile, optimize where it matters (and not where it doesn’t), think about smarter algorithms and moving CPU work to GPU to get big benefits.

    6. Fix warnings (let the compiler help you write reliable code). (Shining example: recent critical TCastleThirdPersonNavigation fix for seemingly-random bug.)

    7. Be consistent in API design.

    8. Backward compatibility is important; having a consistent (easy to learn) API and useful features is even more important.

This post’s image follows our tradition if there’s no clear image to illustrate this, just search for any pretty 3D model. It turns out that if you search for “documentation” on Sketchfab, one of the things that comes up are 3D models of Raspberry Pi, which we love and support in CGE (both as a platform where you can work, and as a platform to which you can compile your games). So here’s a screenshot of CGE editor rendering a 3D model of Raspberry Pi Pico by abdou bouam.

Comments on the forum ➤