We recently held a gamejam at Cat-astrophe Games and I decided to tackle something fun: can I make a real-time multi-player shooter (like Quake), using Castle Game Engine and RNL? In 1 day, during a gamejam? In turns out that yes! 🙂

I’m proud to present Not Quake, a new demo of Castle Game Engine and RNL. You can download the client (just run it and play!) from Not Quake on Itch.io. Or you can download both client, server, as well as the source code from Not Quake on GitHub.

Done in ~10 hours, I went from nothing to a simple shooter game, where multiple people can join (from clients on Windows, Linux, macOS, even Android in theory – though input on Android is not ready yet), send chat messages, and finally run and shoot. I went for a simple client-server architecture for this, just as a first attempt, with a central server that talks with all the clients — many other ways to do this are possible, but this was simplest to start with and indeed it works reliably for such a simple game.

The whole networking was done using RNL: Realtime Network Library, UDP-based network library for real-time applications and games, by Benjamin Rosseaux.

If you like it, please support us on Patreon:

• Michalis Kamburelis (Castle Game Engine) on Patreon

• Benjamin Rosseaux (RNL, PasGLTF, PasVulkan and more) on Patreon

Notes:

• (Edit: new-cameras was already merged to master!) It relies on CGE new-cameras branch, which is not yet merged to master. I wrote more about new features there in this post. It takes me a while to finish it (and merge to CGE master branch) — I have there still TODOs to fix mouse look in editor on Windows, improve 2D viewports, improve undo wrt. to cameras.

• Now that I’m more familiar with RNL, I want to refactor some messages code, to make it both simpler and more powerful.

• It uses my fork of RNL for now, which contains a very ugly hack to hide occasional problem with sending messages. I have to debug whether it is caused by my code, or by RNL unit, and of course fix. Unfortunately the crash occurs ~randomly, and never when testing through localhost, only on remote server. So it’s a pain to catch it.

• There are problems with macOS (mouse look, freetype) and Android (all input) clients. For now, Linux and Windows clients are really stable and advised.

Our editor relies on the fact that multiple TCastleControl instances work OK. This is turn requires that Lazarus TOpenGLControl (ancestor of our TCastleControl) supports sharing OpenGL resources (CGE caches assume that OpenGL data is shared across contexts). I submitted Lazarus pull requests to fix this:

• for Qt5 (so you can use it now for CGE editor, as a reliable alternative to Gtk2 on Linux/FreeBSD platforms) – qt5: Allow sharing OpenGL context data between instances of TOpenGLControl (!95) · Merge requests · FPC / Lazarus / Lazarus · GitLab.

• for Cocoa (for CGE editor on macOS) – Cocoa: Allow sharing OpenGL context data between instances of TOpenGLControl (!96) · Merge requests · FPC / Lazarus / Lazarus · GitLab. This patch is already applied for the Lazarus version used by our Jenkins to build CGE editor for macOS for our main downloads.

This is now documented in CGE manual about GitHub Actions.

We’ve made it so easy to use GitHub Actions to get automatic builds for your projects, done by GitHub, after every commit. You have to try this 🙂

1. Download this file: build.yml and place it at .github/workflows/build.yml path in your project. That is, create a subdirectory .github, then subdirectory workflows, then put the build.yml file inside.

   See the sample project castle-game using it.

2. Then commit, push and just watch the GitHub “Actions” tab as it picks up the commit and automatically rebuilds the project for:

   • Windows (x86_64)
   • Linux (x86_64)
   • Android (APK contains both 32-bit and 64-bit ARM code)
   • macOS (x86_64)

   Ready files are available in the “Artifacts” section. Download them, unpack — ready binary release of your game, for 4 systems above. You don’t need to do builds.

   Note that they will disappear after some time (90 days by default). If you want to preserve them you can e.g. make a GitHub release with them (and maybe even we will automate this too in the future, to make auto-updated “snapshot” release).

The actions execute on GitHub-hosted servers, completely free for open-source projects. They rely on Castle Game Engine Docker image and use the latest CGE “snapshot” revision and latest stable FPC (3.2.2) now. The build is done by executing CGE build tool with proper options. You don’t really need to understand it all — our build.yml just does it for you.

This is my first shot at implementing a new feature in CGE: “Automatic Cloud Builds” that you can quickly turn on when creating new CGE project, and will place a suitable file to integrate your project with

• Jenkins (your own Jenkins instance, that has to support declarative pipeline and Docker, similar to CGE Jenkins). This implies using a Jenkinsfile like this.

• GitHub Actions – based on above, this implies using .github/workflows/build.yml.

• GitLab CI. This means creating a file like .gitlab-ci.yml (example in FPC repo).

You can now download view3dscene builds for macOS (Intel-based macs) and Raspberry Pi. These new platforms are an addition to the existing Linux and Windows builds, that of course remain available too.

view3dscene is a viewer for all 3D and 2D model formats supported by Castle Game Engine, in particular glTF, X3D, VRML, Spine JSON, sprite sheets. It is a useful tool for Castle Game Engine developers (when you double-click on a model in CGE editor we actually open view3dscene), and for anyone else who just wants to view pretty 3D models downloaded from the Internet (test e.g. on glTF files from Sketchfab).

view3dscene snapshots for macOS and Raspberry Pi are automatically rebuild by Jenkins after every commit to view3dscene and Castle Game Engine (that passes a number of automated tests) so they will continue to reflect the very latest features.

macOS notes:

1. macOS app bundle is not signed (for now). For the first time, you have to run it by clicking with right mouse button, choosing “Open” from the context menu, and then accepting to run an unsigned application. Next time you can run as usual, by just double-clicking on the application.

2. view3dscene for macOS benefits from latest huge improvements for macOS users in Castle Game Engine. It uses new CGE Cocoa backend (native look, easy build), is packaged to an app bundle etc. Thanks for MacStadium, we now have remote macOS machine available 24/7, for Jenkins and for interactive work, and this allows to build and test view3dscene on macOS forever.

Thank you all for joining on today’s 2nd open meeting!

I am immediately announcing our next meeting, on September 17th. Click here to register on Discord, add it to your calendar etc.

Summary of today’s meeting:

1. Summary of new/upcoming features:

   1. I talked about new camera/navigation features. On new-cameras branch, very very close to being finished + merged to master 🙂

   2. Andrzej Kilijański talked about new physics features. On physics branch, likewise very close to being finished 🙂

   3. I showed engine on macOS, a recent new feature.

2. I talked a bit about future:

   1. Stuff from from 2022 plans remains in place. We did some planned things, remaining: modifying materials, new examples/fps_game/, Steam, nodes optimization.

   2. I am doing lots of thinking about our “message to new users”. It comes down to better communication how we’re equal/competitive to other engines (cross-platform, editor, powerful OOP API), but also how we’re special (glTF, X3D, native Pascal) and what advantages come from it. I plan to reorganize our webpage to communicate this.

   3. Easy installers. Snapcraft on Linux. Package with bundled FPC and Lazarus (with Lazarus preconfigured for single window (anchor docking), dark theme).

   4. Automation. We want to provide ready files that will make your projects build by GitHub Actions and GitLab CI.

3. We talked about a few things:

   1. Code editor (I talked about how we decided to use Lazarus. Although VS Code is also very appealing — but Lazarus’ code tools for Pascal and debugger win)

   2. Kagamma mentioned: a way to assign events inside castle-editor. I did’t find time to address it, but the short answer is: yes!

   3. WebGL (using FPC WebAssembly) port is anticipated by everyone, including me 🙂

We have a number of game-changing improvements for macOS users today!

1. We have Castle Game Engine binary release, for macOS, available to download here. Download it and enjoy! Just unpack the zip and double-click castle-editor inside the bin/ subdirectory.

   UPDATE: due to important bug being fixed, I updated the above link to lead to latest CGE for macOS, not the older version announced at this date.

   Note: You have to still separately install FPC (and some IDE, like Lazarus) e.g. using Lazarus install for macOS or fpcupdeluxe.

   Note: our applications are not (yet) signed. Double-clicking for the first time on castle-editor will result in an unhelpful error. Just right-click on it instead, choose “Open” from the context menu, and then you will be able to confirm that you want to run an unsigned application.

   Soon: This macOS build will be automatically updated by Jenkins, and available prominently on our main page just like other platforms. UPDATE: This is done now 🙂

2. Your CGE applications now build on macOS without any extra steps, because we have a Cocoa backend in TCastleWindow. It is a fully-featured TCastleWindow backend, that supports:

   • Of course, opening and closing multiple windows with OpenGL context, using native Cocoa
   • Of course, key and mouse handling, including mouse wheel events
   • TCastleWindow.MainMenu, realized as native macOS menu, with submenus, key shortcuts, checked, enabled menu items
   • TCastleWindow.FileDialog, native dialog to open/save files
   • TCastleWindow.ColorDialog, native dialog to pick a color
   • TCastleWindow.MessageOK, TCastleWindow.MessageYesNo – native alerts to notify about something or ask a question

   Previously our support for macOS was weird — we had only non-optimal options:

   1. you could use X11 or GTK backends, but they don’t look native
   2. you could use LCL backend, with Cocoa underneath, but then compilation was more cumbersome: you needed to open project in Lazarus and change dependency from castle_window to alternative_castle_window_based_on_lcl.

   This is solved now. Our TCastleWindow will just use Cocoa (without the need for LCL in the middle) directly, and the code is simple and the effect is a 100% native look.

   This also means that you can build macOS applications from the build tool, or from CGE editor (using menu item “Compile And Run”, F9), and it just works like on other platforms.

   The Cocoa backend in TCastleWindow was based on

   • GLTK, a cool library to initialize GL context by Darius Blaszyk and Ryan Joseph.

   • Various dialog code was also based on Lazarus LCL implementation of the Cocoa widgetset.

3. CGE applications now run on macOS using application bundle, which is an Apple invention to “package” an application as a directory like MyApplication.app along with some metadata and conventions (where to place executable, data, icon etc.). This is necessary to make macOS GUI application fully functional, also with main menu.

   When running we create a temporary AppBundle, using symlinks to the actual files (so the process is lighting fast, even if you have large game data, as we will not copy the data — only symlink to the whole data directory).

   This applies to running from CGE editor, or using castle-engine run from the command-line.

4. Also, CGE applications are packaged to application bundle.

   This applies to packaging from CGE editor, or when using castle-engine package. You can also request the AppBundle format explicitly, using proper CGE editor menu item, or on command-line castle-engine package --package-format=mac-app-bundle.

   App bundles are also used throughout the CGE packaging. castle-editor, view3dscene, castle-view-image are packed by "pack_release.sh" to an app bundle, and they execute each other through a path in the bundle. Custom editor (in case you define project-specific custom components) is likewise run through the app bundle.

5. File associations now work on macOS as well, thanks to some automatic code from Cocoa backend. Opening the associated file will be reported using TCastleWindow.OnDropFiles.

   The syntax to specify file associations has been changed and extended, to accomodate more options.

   See example manifests how to specify associations in view3dscene, castle-view-image.

6. By the way of all this, an improvement for all platforms: CGE editor passes now to CGE build tool the detected CGE location. This makes some setups working more reliably, in case your CGE editor can detect CGE location but CGE build tool doesn’t (or would detect a different location).

7. By the way of all this, TCastleWindow.ColorDialog allows to edit alpha (not only RGB) of the color. Only backends Xlib, Cocoa actually allow user to edit alpha now.

This was all possible thanks to the MacStadium open-source program which provides us now full remote access to a macOS machine. This gives us long-term access to macOS, for the purpose of improving CGE support for macOS and iOS, so we can put work into perfect support and testing for these platforms!

The time is near! Join Michalis Kamburelis and other Castle Game Engine developers, contributors and users at our 2nd meeting on Discord.

The meeting will happen at 15:00 (UTC timezone) on Saturday, 4th June.

Meeting will be on our Discord channel #open_meeting.

• This is the direct link to the event on Discord. Right now you can click Interested button on this event and add it to your calendar (click on … to see the options).

• Simply join Castle Game Engine Discord before the meeting starts, and join that channel.

Please keep your mic muted when you’re not speaking, to avoid the noise 🙂

Agenda:

1. Presentation of new/upcoming big CGE features: new camera and navigation features, physics, macOS Cocoa, and more.

2. Your turn 🙂 I want to invite everyone to showcase what you are working on! I hope to make this a 2-way show, in which everyone interested has time to take the stage and show whatever (s)he wants.

3. This is also the time for questions. I will be more than happy to answer any questions about the engine — how to do something, what do we plan etc.

I have extended the Custom Components documentation, to serve as a good overview for people who want to create new components that are registered in CGE editor.

1. Nicer introduction and consolidates important information from other pages,

2. Documented publishing classes: using subcomponents, references, observing them using TFreeNotificationObserver

3. Documented when and why you should use SetTransient

4. There’s also a description of new TSerializationProcess features: (De)Serializing other values (not just published properties). This is preliminary, i.e. the feature is not yet available on master, only on new-cameras branch.

   TSerializationProcess was extended to allow you to read/write custom instances and simple types (integer, string, boolean, single) and vectors/colors to design file. This allows to

   1. have internal information (not published, may be even private) that is still serialized/deserialized (use-case: storing design-time camera and navigation params in editor),

   2. have backward compatibility for old designs by reading an old property name from file, and converting it to new property immediately. This allows to remove old property names from code, but still support it for file reading.

We also fixed a critical localization bug. And added auto-tests so that the bug will never return 🙂

I have improved the available “plugs” for our compositing shaders mechanism and updated their documentation.

The overall goal was to make them friendly when you target only Phong shading, or want to switch between Phong and Gouraud shading.

• New PLUG_fragment_modify, simplest way to modify calculation after lighting, textures, fog are applied. This is also used now in the initial examples on Chapter 5. Extending the shaders with plugs.

• Clear warning when trying to use deprecated PLUG_texture_apply.

• Improved documentation about new things, and differences between Phong and Gouraud shading — PLUG_main_texture_apply, PLUG_texture_apply, PLUG_lighting_apply all necessarily behave a bit different depending on shading.

I have also updated Mountains of Fire (see also game page) a bit, to use new shader effects.

Let’s kick-off the weekend with a small but important new feature:

You can now double-click in the Castle Game Engine editor “Output” list to open an editor at auto-detected file, with auto-detected line and column. Great to easily jump to the error message.

• It can detect various message types — errors, warnings, notes, progress “compiling …” messages.

• It can find units within your project or even CGE sources. So it’s great for CGE engine development too.

• Not all editors support opening at particular line/column of the file: only VS Code and (if you specify a specific command in “Preferences”) your custom editor.

  I already submitted a feature request to Lazarus to make it also possible there. You watch it / upvote (“thumbs up”) on GitLab.

  You can configure Emacs as a “custom editor” to handle this: emacs +${LINE}:${COLUMN} ${PAS} (put this as “Open Pascal file at line/column” in preferences).

  You can configure Notepad++ as a “custom editor” to handle this: notepad++ -n${LINE} -c${COLUMN} ${PAS} (put this as “Open Pascal file at line/column” in preferences).