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! 🙂

You can now add and configure fonts in CGE editor.

1. Use the “Design -> Add Non-Visual Component” menu item, or the context menu (when you right-click in the hierarchy on the left). Font is added as “Non-Visual Component” to whatever parent you selected.

   The parent that keeps reference to the font node can be anything — TCastleComponent, TCastleTransform, TCastleUserInterace etc. It is similar to VCL/LCL non-visual components: it doesn’t really matter where you drop them on the form.

2. Then assign this font to TCastleLabel.CustomFont. Or any other UI control descending from TCastleUserInterfaceFont, like TCastleButton or TCastleEdit.

   New property TCastleText.CustomFont is also available, and you can also assign to it using CGE editor. This allows to adjust the (potentially 3D) TCastleText in the same way.

Along with this change, we upgrade our font classes:

1. Renames to better names:

   • TCastleFont -> TCastleAbstractFont

   • TTextureFont -> TCastleFont (definitely the most common font class you will use)

   • TSimpleTextureFont -> TCastleBitmapFont

   • TFontFamily -> TCastleFontFamily

   • TCustomizedFont -> for now not renamed and not published in CGE editor, as it doesn’t seem critical enough, use-case is only to provide multiple alternative “optimal sizes”. We may integrate this use-case into TCastleFont one day.

   Some unit cleanup has been done by the way: TCastleFontFamily has been moved to CastleFonts unit, and TRichText has been moved to CastleInternalRichText unit and CastleFontFamily unit has been deprecated. In effect: user code needs to use 1 less unit (no need to use CastleFontFamily unit), and some internal things (TRichText and friends) have been hidden to make API easier.

2. TCastleFont gets new comfortable properties:

   • URL (font file URL, e.g. TTF or OTF),

   • OptimalSize,

   • AntiAliased,

   • LoadCharacters,

   • LoadBasicCharacters to control the loaded font.

3. TCastleBitmapFont gets comfortable properties:

   • ImageUrl,

   • ImageColumns,

   • ImageRows,

   • ImageMargin,

   • DisplayMargin.

4. When the font is not loaded (e.g. TCastleFont.URL was not set, or TCastleFontFamily has TCastleFontFamily.Regular not set) then we always display some default font (Window.Container.DefaultFont, falling back on global default UIFont) to avoid having invisible e.g. TCastleLabel.

5. As usual, assigning URL to ” (empty) is allowed and valid way to just “unload” the font.

6. FreeType version distributed in our Windows DLLs has been updated.

7. TCastleText is now a sans-serif font by default. This follows the UI default fonts.

8. See examples, e.g. examples/fonts/text_tests for initial demos of it.

9. TODO: Manual page about text and fonts will be soon updated to reflect all of the above.

I just merged to Castle Game Engine master branch a big work that I’ve been doing for the past 6 weeks (exactly 200 commits). This brings a number of new cool features that I’m going to describe in details in the upcoming news posts (and a video!).

Brace yourselves 🙂

Here’s the summary:

1. Non-visual components in the editor (attached to visual components, or saved to .castle-component)

2. Upgrade to the font API and fonts (bitmap and TTF, OTF…) fully configurable in the CGE editor

3. TCastleText improvements

4. Serialization improvements

5. Behaviors in the editor, including billboard behavior — the easiest way now to make a billboard

6. Complete rework of the sound API with many improvements — less hassle to track playing sources, distance model good by default, all concepts more natural to use

7. Sounds (spatial or not) can be set up in CGE editor (even drag-and-drop works!)

8. Sound configuration in editor preferences (volume, mute-on-play)

9. FMOD backend complete (added: spatial sounds, priority, distance model, offset)

10. And lots of new examples (or heavily upgraded old ones), look in examples/audio/ , examples/fonts/ , also examples/window/window_events .

We have a big update to our examples/platformer demo. It is now a complete demo of a platformer game, with

• Level (and all UI) designed visually using CGE editor.

• Sprites sheets designed using CGE editor and managed in .castle-sprite-sheet format (see sprite sheets docs).

• Full platformer gameplay. Player can move, jump, pick up a weapon, be hurt by enemies, be hurt by obstacles, collect things, die, finish the level. Extra jumps in the air are possible (check out Advanced player checkbox). Enemies move following a simple pattern.

• Sound and music.

• All UI states you expect from a usual game — main menu, options (with volume configuration), pause, credits, and of course the actual game.

It is actually super-playable and fun, just as a normal game, regardless if you want to learn CGE or not 🙂 So give it a try.

This is all thanks to Andrzej Kilijański work. We hope that this demo will be useful for everyone to see how to create games, and platformer games in particular, using all recent CGE features!

Minor fixes

• glTF import now handles arrays in glTF “extra” data correctly. This avoids warnings when loading a glTF exported from Blender, when the Blender mesh had shape keys defined.

• The cause of “Calling UnAssociateNode on X3D node…” warning, that you could previously see, is fixed now. The underlying cause was fixed in this commit. The warning was signalling an actual problem (and if we make the same bug again, the warning will occur again, we also have automatic tests to check it).

• The Viewport.PositionToRay and similar methods have been improved in this commit to work OK, even if used early (before any resize/render event happened on this viewport).

Coming soon

• Michalis is working since ~3 weeks now on a behaviors-and-fonts-in-editor branch that will introduce new features in editor: behaviors, fonts, sounds. It also has new sound API (nicer to visually design, but also just much simpler to manage from code — I have learned a lot how to make sound API properly 🙂 ). And FMOD spatial sounds. Once merged (in a few days — it’s nearly finished) I will describe it all in more detail, and make a showcase video.

• Eugene Loza made a PR that allows CGE build tool to create Debian packages (deb). It’s in review (which means: waiting for Michalis 🙂 ) now. Once merged, you will be able to just create a Debian package, effortlessly, from all your CGE games!

• Andrzej Kilijański is working on new shadow volume rendering code, to make it working on OpenGLES too (and in general use OpenGL in an optimal, modern way).

New components in Castle Game Engine that you can place inside the viewport

We have a few new components in CGE, working perfectly with CGE editor:

• TCastleBox
• TCastleSphere
• TCastlePlane
• TCastleCone
• TCastleCylinder
• TCastleText

You can add them inside editor. They descend from TCastleTransform, so add them somewhere inside your Viewport.Items hierarchy, and they are 3D (e.g. TCastleText can be freely rotated in 3D, unlike 2D-only TCastleLabel). They expose a lot properties you would expect:

• size,
• material (simple properties to set material type and main color),
• texture (and normalmap),
• toggle visibility of sides/bottom,
• double-sidedness,
• rendering options (wireframe etc.),
• text size,
• text spacing,
• text alignment (horizontal and vertical).
• Notable TODO: the TCastleText font (and it’s quality, to avoid it being blurry at large sizes) is not yet adjustable. See below about plans.

Using these primitives allows to quickly set up some 3D environments in CGE editor. I think it is extremely useful for quick prototyping of 3D content, creating a scene from a composition of simple primitives or adding simple primitives to something more complicated (e.g. to TCastleScene using glTF). You don’t need to use Blender to create trivial 3D things 🙂

Previously this all was possible, but not always comfortable, and not in CGE editor. You can of course create 3D geometry primitives by directly creating X3D nodes, and you get extra flexibility (you can e.g. customize all material/texture parameters — our above primitives expose only a simple API to adjust material/textures). But this approach is not available visually, in the CGE editor. We have various ideas to “converge” these 2 approaches — one is to introduce a visual editor for X3D nodes, but adding this inside a CGE editor to make it really “seamless” is not easy task. Moreover, the experience showed that simpler CGE API, that hides X3D nodes and some of their complications, is often much simpler to use — so we play both sides, making X3D API simpler to use in CGE, while also hiding X3D in many places.

Upcoming new CGE components (that will work perfectly in CGE editor)

1. Non-visual components that can be still designed in CGE editor.

   • Components to set font properties (URL to ttf/otf file, LoadingSize to have larger texture but with less blurry characters). You will be able to assign these to TCastleLabel.CustomFont (already existing but not useful in editor, only from code) and upcoming TCastleText.CustomFont . This will be an upgrade of existing TCastleFont and other CGE font classes.

   • New component TCastleComponentGroup only to group non-visual components, if needed.

   • Ability to save in editor non-visual components to .castle-component file. Any TComponent descendant is OK. We already have this in code (ComponentLoad, ComponentSave). This will give us equivalent to TDataModule you may know from Lazarus/Delphi.

2. Behaviors (descendants of TCastleBehavior) that extend parent TCastleTransform.

   • TCastleBillboard (already done, but we need to expose it in the editor).

   • TCastleSoundSource (already done, but we need to expose it in editor, and make some changes applied better, without restarting sound).

   • TCastleMoveAttack (easy creature AI; half-finished in CastleBehaviors unit for now).

   • Physics components (TRigidBody, TCollider and descendants) expressed as behaviors, and with auto-size by default. IOW, you will be able to design and test CGE physics in our editor!

3. Lights. Using internal scenes with X3D lights underneath, using gizmos to manipulate lights like in view3dscene lights editor.

   • TCastlePointLight
   • TCastleSpotLight
   • TCastleDirectionalLight
   • TCastleEnvironmentLight (image-based lighting)

   • We already have the basis for all we need, but we need to fix issue 280 to make it functional.

   • To make shadow configuration on lights easy, we’ll need to improve additional stuff, both in shadow maps and shadow volumes.

4. Camera as TCastleTransform descendant. If you need it right now, just use my draft implementation of this idea in class TCastleCameraTransform inside examples/creature_behaviors/. Just copy this class interface+implementation to your code.

Our build tool got a few minor improvements/fixes lately:

• Build tool now supports executable_permission attribute to package some additional files with Unix executable bit set. In general useful by applications that have more than 1 executable. Used now by view3dscene manifest so that it packages tovrmlx3d binary with executable permissions.

• Build tool now warns if you try to use absolute path in search_paths in CastleEngineManifest.xml . This is almost always a mistake, you want to use relative paths.

• Many updates to CastleEngineManifest.xml docs.

• Fixes to castle-engine generate-program.

  On Windows, we need to use stricter wildcard matching in CastleFindFiles, so that "*.pas" does not match files like "bla.pas~~~something" (by default, Windows API, used by Pascal FindFirst/FindNext, only looks at 3 first characters of the extension).

• Various improvements to our Makefile and Jenkins to just rely on the build “all across the board” and not use some shell scripts.