Tenjin service for Android and iOS (also a good example how to roll your own service), improved FMOD service by CastleEngineService.xml

Posted on

Tenjin website

You can now easily integrate your mobile applications with Tenjin, an analytics service with emphasis on install attribution (“from where did users install this application”). The idea is to have more knowledge about your organic and paid (from marketing campaigns) installations, to better make decisions how to promote your application.

New tenjin service can be declared in your CastleEngineManifest.xml file. Read the documentation:

The service sends to Tenjin:

  • initialization (user device data, e.g. Android/iOS version),

  • purchase details (when user makes in-app purchase), so you can correlate them with your marketing campaigns,

  • custom events you send by trivial TCastleTenjin.SendEvent

Note that we are not associated with Tenjin in any way. We just added to CGE a component to easily use their mobile SDK. The Tenjin is in general a paid service, although basic install attribution is free.

Please refer to the Tenjin documentation to know more about Tenjin features, and how to view these statistics.

The Pascal API will be extended soon with easy option to opt-in/out of the statistics by user.

We also introduced a new mechanism how services can declare their information: CastleEngineService.xml files.

The new Tenjin service may also serve as a good example of a service that integrates with a 3rd-party SDK in Objective-C (on iOS) and Java (on Android). It makes a basic integration, and allows for basic communication with Pascal through TCastleTenjin.SendEvent.

Comments on the forum ➀

Important fixes, small website and engine improvements

Posted on

New assets list webpage
API docs searching
Test All State Events demo

Important fixes:

  1. Editor on Windows: Fixed a random crash when doing F9 on Windows.

  2. Fixed physics crash on i386 (32-bit CPUs)

  3. Editor UI fix: Alt+tab and back no longer clears selection, no longer resets the preview in bottom-right corner.

  4. Fixed castle-engine package-source – it was accidentally by default creating a zip file, but with tar.gz extension. Now it correctly by default creates a zip file with zip extension, it also reacts correctly to --package-format=targz .

Website improvements:

  1. API docs searching for short/common words like X or Up fixed.

  2. We have a new page Gallery -> Assets (3D and 2D Graphics, Sound) listing various useful places where you can download good quality assets (graphics and sounds) for your CGE games.

    It just lists a few sites with good quality stuff useful with CGE. The list is absolutely very subjective, based on my (Michalis) opinion and just reflecting what I’m using myself when I need a ready graphic/sound. I like good quality things, useful in games, and free on clear open-source licenses (although I’m OK when the site has paid assets too — e.g. I’m cool with recommending Sketchfab, as long as they also support assets on open-source licenses).

    Before you ask: Yes, we should have Castle Game Engine Asset Store some day πŸ™‚ In the meantime, I would encourage to submit to OpenGameArt.org assets with [CGE] in the name (this has been approved by OGA moderators as the way to go).

  3. Simpler talk to us page to show the 4 important ways of contact: Discord, forum, GitHub issues, Patreon.

Small engine improvements:

  1. We have an automatic tool to check correctness of our Lazarus packages in tools/internal/check_lazarus_packages/. This checks that our LPK contain all the necessary files (which also means they’ll be recompiled on changes), and is automatically run by our Jenkins after every commit / on every new branch to check it.

  2. New simple demo examples/user_interface/test_all_state_events, replaces old examples/window/window_events.

Comments on the forum ➀

Improvements to cross-platform building: choose platform in editor, optionally allow case-insensitive URLs on case-sensitive filesystems, run Windows builds through WINE on Unix

Posted on

Choose platfom in CGE editor
Seamlessly running Windows application through WINE on Linux
  1. You can now choose the platform (Windows, Linux, Android, iOS…) to build and run from the editor. This platform is then used by compile, run, package, install build tool commands. This means that, if you have cross-compilers set up (hint: use fpcupdeluxe) then you can now easily build for various platforms, right from the GUI editor, without resorting to command-line and playing with environment variables.

  2. Another new feature, also related to the cross-platform development, is specifically for Linux/FreeBSD developers that want to target Windows too:

    You can now run Windows application on Unix seamlessly — if only you have WINE installed. The build tool, as well as GUI editor, will invoke wine / wine32 / wine64 under the hood, if you run Windows build on Unix. From the command-line, it means you use castle-engine run --os=win64 --cpu=x86_64 (or --os=win32 --cpu=i386 for 32-bit Windows) while your current (source, host) OS is Unix.

    Together, this means that if you have FPC cross-compiler from Linux to Windows installed (again, use fpcupdeluxe — it’s easy πŸ™‚ ), and WINE installed (it should be included in the packages of all Linux distributions), then you can just switch in CGE editor platform to Windows, and press F9, and see the Windows application being compiled + run on your Linux without any fuss. The compilation / testing is then equally easy as for normal native Linux build.

  3. To make things balanced, we also have one new feature for Windows developers to make it easier for them to build apps for Unix (Linux, FreeBSD) desktops:

    You can set trivial global boolean CastleDataIgnoreCase, to easily run application with castle-data URLs that have wrong case on a case-sensitive filesystem. E.g. your file in the data directory may be called my_texture.png. Normally, accessing it by URL like castle-data:/My_Texture.png doesn’t work on Unix, as the file system honors the case (in contrast to Windows, where it works OK).

    Setting CastleDataIgnoreCase means that we search for the file name (and all directory components on the way) ignoring the upper/lower letters difference. It will raise an error only when it is impossible (no such file found, or ambiguous, e.g. you have both my_texture.png and My_Texture.png on disk — this is perfectly possible on case-sensitive filesystems).

    While this is slower (so we don’t really advise it as the “final solution”), but it is useful to quickly deploy applications tested mostly on Windows into Unix. In the long run, we still advise you to just honor the case, and thus make things work without CastleDataIgnoreCase, but using CastleDataIgnoreCase is now a possible and quick solution when you need it.

Comments on the forum ➀

Android and iOS improvements, Docker and releases upgrade to FPC 3.2.2

Posted on

detect_scene_hit example screenshot

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.

Comments on the forum ➀

Platformer demo released on itch.io

Posted on

Platformer demo - title screen

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:)

Comments on the forum ➀

New manual chapter that introduces editor and states, more manual and website updates, “Register Lazarus Packages” button

Posted on

Designing user interface in Castle Game Engine editor - resized biplane
Designing user interface in Castle Game Engine editor - image preview
State events demo - resulting application

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).

Comments on the forum (1) ➀

Packaging to Android App Bundle

Posted on

Android App Bundle

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.

Comments on the forum ➀

Adding behaviors in CGE editor (TCastleBillboard, TCastleSoundSource)

Posted on

Design: Werewolf, from a sprite sheet, is also a billboard and emits a 3D sound
Werewolf, from a sprite sheet, is also a billboard and emits a 3D sound

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.

Comments on the forum ➀