A few loosely connected improvements for building and mobile devices:

Android:

1. Fixed building on Android when the project folder contained spaces. We no longer use ndk-build that cannot cope with that.

2. Fixed (well, workarounded) crashes on Snapdragon (Adreno) Android devices when using parallax bump mapping.

3. Updated Android prerequisites documentation. Using latest Android SDK with latest Java is OK now, and we no longer need to use ancient Java 8. Latest Android SDK is OK with Java 11, and just using default-jdk package in Debian stable works.

iOS:

1. Compilation for iOS with FPC 3.2.2 is fixed. Just like FPC, we now define iOS as a separate OS from “darwin”, and thus we’re ready for macOS 11 (desktops running on Arm64 CPU).

2. Updated iOS documentation. Installing iOS cross-compilers using fpcupdeluxe works cool now.

Docker and releases:

1. Our Docker image has been upgraded. It is now based on Debian buster (current stable) instead of stretch (oldstable). We kept relying on stretch (oldstable) for a long time, as Android SDK required ancient Java 8 — luckily this is no longer the case.

2. Our Docker image contains now latest FPC version 3.2.2 and it is the default FPC version. Also the FPC trunk revision has been updated to latest revisions on 2021-07-18.

3. This also means that CGE binary releases are now compiled with FPC 3.2.2 (instead of previous 3.2.0).

I did not really have any good image for this post, so attaching a screenshot from new examples/3d_rendering_processing/detect_scene_hit 🙂 It is a simple demo of TCastleViewport.TransformUnderMouse.

Do you want to compile Castle Game Engine yourself, from our source code? As this is the first step toward contributing in the engine development, we can only encourage it 🙂

We now have a detailed documentation how to compile CGE from sources yourself.

And we have a video recording of this process on Linux:

Watch the latest video on our channel — demonstration how to create and edit sprite sheets completely in Castle Game Engine, how to put them on the scene, how to load Starling and Cocos2d sprite sheets and more! With thousand thanks to Andrzej Kilijański for presenting this, after implementing all features and examples shown here:)

Have a lovely Sunday!

And play our platformer demo, if you haven’t already 🙂 We have compiled version of the game, for Windows and Linux, ready here:

https://castle-engine.itch.io/platformer

You can download it manually as a zip file, or using comfortable Itch.io App.

We have also updated Castle Game Engine itch.io page to represent the engine better.

For developers, an additional treat is the examples/platformer/itch.io/ directory that contains the shell script and manifest files that show how to 100% automatically release your game on CGE. You can combine our build tool and itch.io butler to do this.

The platformer demo was developed by Andrzej Kilijański. For more information, see the README and the previous news about it.

Last but not least, after playing, you can watch the movie where Eugene Loza managed to play through the entire game without firing a single shot 🙂 For a more typical gameplay, pick up the weapon and fire with a Space key! Spoiler warning – of course watching the movie will kind of spoil the game for you. It’s probably more fun to play it yourself first:)

I am deep in making big updates to the manual, to document the usage of editor and other concepts that become important during the CGE 7.0 development.

We start with new 1st and 2nd manual chapters:

1. Installation and building your first application

2. Designing user interface and handling events (press, update) within the state

Go ahead and read them now, whether you’re a seasoned CGE user or a new one 🙂

Details – what and why:

• The manual beginning is now much simpler than it was, replacing previous Getting Started (was needlessly complicated), Opening the window (unnecessary), Window events (obsolete, as you should now use TUIState events). The new pages focus clearly on doing things the way we advise — which is using our visual editor.

  In particular Designing user interface and handling events (press, update) within the state chapter is actually an introduction to using the editor, from zero-knowledge. It shows how to modify the design, add images, and then access them from code and use basic TUIState methods.

• While doing it, I also introduced new utilities TCastleUserInterface.ContainerToLocalPosition and reverse TCastleUserInterface.LocalToContainerPosition. It became apparent they are useful, both for internal and outside usage.

• I also introduced a button “Register Lazarus Packages” in the editor preferences. This button simplifies one installation step, which allowed to make chapter Installation and building your first application shorter 🙂

• The installation of castle_components package, and in general dealing with TCastleControlBase in LCL, has been deemphasized, and moved to new chapter Engine control to put on Lazarus form. Nothing changes with regards to our support (you have a choice between TCastleWindowBase and TCastleControlBase), but the manual is now more focused on the advised approach for “normal CGE applications”, which is to use TCastleWindowBase as set up by our templates.

• I made a link to our Castle Game Engine YouTube channel much more prominent, putting “Videos” right on the website menu bar.

• I also made some other minor website changes. New font (Inter), better size of the download icons, better news list (directly show the sharing buttons, and link to forum without an extra click).

You can now easily package Android games using Castle Game Engine to the AAB format (instead of APK). New Build Tool command-line options allow to execute:

• castle-engine package --target=android --package-format=android-app-bundle

  Will package to the new AAB format.

• castle-engine package --target=android --package-format=android-apk

  Will package to the traditional APK format. The --package-format=android-apk is right now the default behavior, equivalent to also using --package-format=default on Android — time will tell whether we will change this default to AAB.

Why the new Android package format?

Starting August 2021 (next month!) all new apps published on Google Play Store are required to be uploaded in Android App Bundle (AAB) format and from November 2021 all updates to existing apps at Google Play Store will be required to use AAB format. Also, uploading apps in AAB format overcomes Google Play Store 100 MB limitation on a project build, which is especially important for games, as different assets can take up a lot of space and reducing their quality is not always a good option.

Note that we still support packaging to regular Android Packages (APK) that can be instantly installed to an Android device and it still remains a default packaging format for Android platform, as it is very convenient for development purposes or for distribution through alternative to Play Store platforms, e.g. uploading to itch.io.

Android App Bundle (AAB) is a collection of prebuilt resources targeted for different user devices (such as Android version, CPU architecture, Screen resolution). Play Store then automatically generates an APK based on user configuration. Note that it also means that AAB package cannot be directly installed on a mobile device/emulator and therefore for debugging and internal testing APK is still a necessary format.

You can now add/remove behaviors using the CGE editor. “Behaviors” are components that enhance the behavior of the parent TCastleTransform. We have a few of them included in CGE, and you can define more (“3D FPS Game” template shows a trivial behavior of an enemy).

If you come from Unity, know that “creating TCastleBehavior” is now the closest equivalent to Unity “creating MonoBehaviour”.

The behaviors you can add now using the editor are:

1. TCastleBillboard. Turns any TCastleTransform into a billboard (visually, in the editor, too). Billboard automatically rotates (around some axis, or freely) to face the camera. TCastleBillboard is now our advised way to make billboards in CGE (much simpler to use than X3D node TBillboardNode, which we advised in the past).

   It exposes AxisOfRotation, by default +Y axis. Simply set it to zero Vector3(0, 0, 0) to rotate the transformation freely, to always face the camera.

2. TCastleSoundSource. This makes the parent TCastleTransform emit a sound. Such sound has a 3D position and can be spatialized, which means that distance of the emitter affects the volume, and position of the emitter affects whether you hear it more from the left or right side. More on this in later news about sounds 🙂

A simple example of it is now in examples/creature_behaviors. The wolf is a sprite sheet, and a billboard, and it emits a “howling” sound.

You can now edit any TComponent descendant in CGE editor. I expect to use it intensively to design basically everything in the editor.

The non-visual components registered automatically (and thus available by default in CGE editor) are:

• Fonts: TCastleBitmapFont, TCastleFontFamily, TCastleFont — described in the previous news about fonts.

• TCastleSound — describes a sound file to be played. More on this in the upcoming news about sounds and the updated manual chapter about it.

• TCastleComponent which is like standard TComponent but it can have non-visual children components managed by TCastleComponent.AddNonVisualComponent method and friends. These “non-visual children components” do not do anything, but they are serialized along with the parent component, thus you can organize your information in a tree.

  Oh, and sound and font classes mentioned above also descend from TCastleComponent. And all visual classes, like TCastleUserInterface and TCastleTransform can have non-visual components too, so e.g. a UI design root, or a TCastleLabel, can “store” the reference to a font. This is all flexible, so you can use the system to arrange information in any tree you like.

We also have new menu items to create a design that contains only non-visual components:

• Design -> New Non-Visual Component (Empty Component As Root) (root is TCastleComponent)
• Design -> New Non-Visual Component (Custom Root)

E.g. you can use it to store TCastleFont or TCastleSound collection in a file.

An example of using this approach to manage a list of sounds is in examples/fixed_camera_game, the design file data/sounds/all_sounds.castle-component defines all the sounds. The code that handles it is in code/gamesound.pas file. This is our new approach to define a “repository” of sounds, and it will soon be documented prominently in the manual and will deprecate the existing approach to define sound repository by an XML file.

This is our preferred editing and serialization approach for every TComponent. And so our preferred serialization for everything is to use RTTI with TComponent, which makes our CGE editor “complete” in the sense that it is now more universal than only “editor for CGE UI / transforms”, it is now “editor for everything in CGE”.

The non-visual components can be saved / loaded to a file with .castle-component extension.

The TCastleComponent also exposes a nice general mechanism to serialize children lists, using TCastleComponent.CustomSerialization and TSerializationProcess. It is now used to serialize regular children (TCastleUserInterface children of TCastleUserInterface, TCastleTransform children of TCastleTransform) and NonVisualComponents children (of any TCastleComponent) and Behaviors (of any TCastleTransform).

We also improved related JSON serialization code. It’s now a bit simpler (no more special $Children code, the TCastleComponent.CustomSerialization now covers this use-case). We write $$ClassName earlier (JSON is more readable for humans), we don’ write empty $Children (JSON simpler for humans).

A new Free and Open Source game made in Castle Game Engine: Kryftolike – a hide-and-seek roguelite game where the Player hides from monsters and seeks treasure in an infinite procedurally-generated map.  Danger awaits around every corner.

Source code: Kryftolike at GitLab (Also an example of efficient 2D batched rendering, creation of custom UI elements in Castle Game Engine)

Downloadable binaries for Android, Windows and Linux: Kryftolike at Itch.io

This video shows how to install FPC and Lazarus (Pascal compiler and IDE) using FpcUpDeluxe. This process is also documented here. The video shows the process on Linux, with some Linux-specific details (like setting up symlinks in /usr/local/bin).

This method of installation allows you to choose any FPC/Lazarus version (stable, development), switch between multiple FPC/Lazarus versions as needed, and add cross-compilers (e.g. for mobile, to compile Castle Game Engine applications for Android).

FPC and Lazarus installed like this will be automatically used by the Castle Game Engine build tool and editor.

Note: For new CGE/FPC/Lazarus users, we actually advise a simpler approach. Just install Lazarus bundled with FPC from the Lazarus website. It is easier and works well for normal usage. If ever you decide you need an Android cross-compiler, you can always go for the more flexible FpcUpDeluxe installation (or try our Docker image to get various FPC versions with cross-compilers).

This is a first video from Andrzej Kilijański. Many thanks! More will follow soon! 🙂