Hacktoberfest is an annual event dedicated to promoting Open Source software development and to help developers from all the world (regardless of their experience level) to contribute to open source projects.

Now you can also participate in the event by contributing to Castle Game Engine! Many related projects at Castle Engine (GitHub org) received a hacktoberfest tag 🙂 Feel free to look around!

First of all, of course it’s a good idea to check out main repository of Castle Game Engine:

A good beginner task (whether you want to participate in hacktoberfest or not :)) is to browse our examples. Just download CGE and navigate to projects in examples subdirectory. By testing examples you will:

• learn how to do various things using the engine
• undoubtedly notice places to improve.

The examples are being constantly added and improved, but it is also a never-ending work 🙂

Many examples could use a better 3D, 2D graphics or even just better presentation of the content. This doesn’t necessarily mean that you have to create your own art from the scratch. Using / extending assets with open-source licenses is absolutely welcome and even encouraged. See e.g. Castle Game Engine Assets, OpenGameArt, Kenney, Quaternius etc. — we have lots of people already doing pretty things. In a lot of cases, you can just use / remix them for the purpose of CGE example and create something much prettier than some of the current demos 🙂

Adding various small functionalities is also welcome. With CGE editor, editing a lot of these things to be more functional/prettier is really easy.

Note that we don’t want to over-complicate the examples — each example is deliberately limited in scope. Some examples are deliberately simple. The primary point is to show “how feature X of CGE works, what are the main properties of this feature”. We usually do not show every possible variation of X, alternative of X, property of X — we focus on most important stuff around X. This is of course very subjective — so when in doubt (“should I extend this example with Y?”) just ask on any of our channels (Discord, Forum etc.)

And if you find some example that seems outdated (e.g. doesn’t use CGE editor to design UI, or has missing README.md) — that is also (probably — ask if in doubt!) something to update.

Moreover, non-trivial examples definitely can be published as a demo on Itch.Io Page and Google Play Store (Android).

We did it with examples/platformer. However, some examples may deserve it too, for example:

• examples/tiled/strategy_game
• examples/third_person_navigation (but it really needs better 3D art 🙂 — note that mechanics are already being improved by new physics, but not gfx.)
• examples/mobile/activity_recognition (though recognition is only on iOS now; but another task could be — add recognition of walk/run on Android too, using the simplest approach that relies on Android API for it)
• examples/deprecated_to_upgrade/fixed_camera_game (but it requires upgrade to use glTF and CGE editor for most things)

You can also browse API docs. Surely there are some places that lack description or maybe their description is unclear or could be improved by examples. All these API docs are just taken from comments in units’ interface — to improve those, just edit the appropriate unit’s comments. They are processed by Pasdoc, check PasDoc documentation to see what formatting features are available.

Last Sunday, I gave a presentation about Castle Game Engine at the Game Industry Conference. I think it went really well — a lot of people came, I had a lot of positive feedback and good questions. I felt that a lot of work we put lately into making the engine not only packed with features, but also really easy to use, paid off!

The slides from the presentation are available here, and embedded in them are 4 short movies (physics, 3D game, 2D game, code). Enjoy!

Note that I used physics branch to demonstrate the physics components (not yet merged to master, just due to my obsession to review everything perfectly 🙂 ). Everything else you see there is available on CGE master already.

I also bring back some thoughts and conclusions:

• Confirmed TODO: The hierarchy on the left is getting a little overcrowded when we put lots of behaviors (like rigid bodies and colliders) together with transformations. The current state may be acceptable at start, but eventually we should improve this. This is a UI thing — we can organize it better and we will, we already talked with Andrzej Kilijański about it.

• Confirmed TODO: WebGL port is important 🙂

• My new idea (this one is not from feedback to my CGE talk, but it is a combination of 2 ideas from 2 talks I had at GIC):

  We should have a demo in CGE showing a huge city and loading neighboring pieces of the city asynchronously. This idea came to me during “Open World Streaming in Dying Light 2” talk — I believe the core idea is something completely doable in CGE (and testable on a 3D big city generated from ready buildings (with interiors) in CGE example).

  This idea clicked with something I learned thanks to meeting Grzegorz Wojciechowski also at GIC. He’s doing amazing things with OpenGL, among them — spreading work into multiple processes and threads at the engine layer. He made me aware that you can load things asynchronously, in another thread, into OpenGL!, if you do this in another OpenGL context that is shared with your main (rendering) context. And in CGE our TCastleWindow and TCastleControl already always do sharing (because it makes caching natural for multi-window applications), so we got this!

  This is a very possible and within-reach solution to a promise “Asynchronous loading will be possible some day” made in our Threads usage manual chapter.

A quick video demonstrating new Castle Game Engine physics joints!

Joints presented:

• hinge (rotation around an axis)

• ball (free rotation)

• grab (follow a specified point)

• rope (one object is tied to another with an invisible rope – it can move and rotate, as long as the rope distance is preserved).

We can design and simulate everything in CGE editor. This is all open-source, on Castle Game Engine physics_j branch.

Andrzej Kilijański and Michalis Kamburelis work on making it merged to CGE master 🙂 If you like this work, please support us.

We use physics engine Kraft for the underlying computation by Benjamin ‘BeRo’ Rosseaux.

You can now activate shadows by shadow volumes by toggling a trivial boolean property Shadows at the light source to true! This works (also) in editor at design-time.

This makes the shadow volumes we have documented here easily available, finally. No more messing around with X3D lights nodes.

A simple demo is in examples/viewport_and_scenes/shadows.

We also publish TCastleTransform.CastShadows property to control if some object casts shadows.

Future:

This is just the beginning of “really easy shadows”. I enjoy how simple API we have (just a checkbox really!) and how great it is to play with shadows in the editor. But we can improve the functionality underneath now 🙂

1. The most important TODO here is that we plan to expose shadow maps in the same way. Actually shadow maps should be in the future the default algorithm activated by Shadows (and toggling between shadow maps and shadow volumes should be done using an independent property like ShadowMode = smShadowMaps, smShadowVolumes).

   Shadow maps have a number of advantages — they do not require the shadow caster to be 2-manifold, they already work on both desktop and mobile (OpenGLES), they can be applied on multiple light sources independently with correct result.

   While we had shadow maps implemented for years, with some impressive demos (see features section) but they do not work (yet!) across scenes, which means that the light that casts shadow must be in the same glTF/X3D file as the shadow receiver. This makes them not suitable to use shadow maps on our light nodes.

   The plan is to, well, remove this limitation (#284). Shadow maps should work cross-scene, they should not transform the X3D graph (whole work done by CastleInternalShadowMaps should be removed) and the renderer should just take and use at rendering a shadow map information attached to any light (and the renderer should add using that shadow map to particular shape).

2. Shadow volumes for now carry a few limitations:

   • The unfixable limitation is that shadow caster has to be 2-manifold, i.e. every edge must have exactly 2 neighboring faces, so the whole shape is a closed volume. Both CGE and 3D authoring tools like Blender help you modeling such shapes — see Make 3D models of shadow casters geometry to be 2-manifold.

   • The current limitation of shadow volumes in CGE is that we allow them from only one light (so set Shadows to true only on a single light!)

     We could improve that, though note that it will increase the number of rendering passes, in general you need to do 2^shadow_volumes_lights passes. So this technique is really not feasible for multiple lights. (Shadow maps scale much better.)

   • A temporary limitation is that shadow volumes do not render properly on mobile (OpenGLES), we have a PR in progress to address that.

OK, not really a zillion 🙂 But I seriously addressed a few important issues with editor usability and I think these improvements have a big impact. Some important things are now more intuitive for beginners, some behave better for larger projects.

As usual, I encourage you to try the improvements immediately by downloading the latest engine version. And please support us on Patreon because we really rely on it.

Improvements:

1. The default editor tool now allows to select and modify both UI (instances of TCastleUserInterface) and 3D / 2D game stfuf (instances of TCastleTransform).

   In a broader context, the tools to operate on UI and transformations have been merged. There’s no longer a special “Modify UI” tool (that didn’t work on transforms). The tools “Translate” / “Rotate” / “Scale” remain, but now they work on both transforms (allowing to translate / rotate / scale them) or UI (in which case you can always translate + resize it).

   This makes using editor much simpler. You will no longer need to switch modes so often.

   Note: To operate on something (UI or transform) without changing the currently selected object, remember you can drag with Shift.

2. Hierarchy (left panel) is updated smarter, without rebuilding it from scratch. This makes adding / removing components experience much better: it will not reset the expanded / collapsed state of your components, it will not reset the scroll position within the hierarchy list.

3. We now show a label alongside selected UI components of size zero, to make them actually visible in the editor.

   This addresses a common situation with TCastleVerticalGroup and TCastleHorizontalGroup — they have by default size zero (since they have no children initially, and have AutoSize = true by default). While the zero size makes sense for them, but to the user it was confusing what is going on — you added a group, but nothing was visible?

   Now, newly added TCastleVerticalGroup and TCastleHorizontalGroup, while it still has size zero, is clearly visible.

   This also fixes analogous issue with TCastleImageControl, that has size zero by default, because URL of the image is not set initially, and Stretch = false (so control size matches image size, and there’s no image).

4. If you cannot resize or move a component, sometimes it makes sense to move or resize the parent. This in particular applies to moving/resizing a UI with TCastleUserInterface.FullSize or moving a UI under TCastleVerticalGroup / TCastleHorizontalGroup. Previously these operations were blocked, now they affect the parent.

5. If you cannot resize a component because it has property like TCastleButton.AutoSize, now we display this using a tooltip (when you try to resize it). So it should be more obvious that you can turn off properties like TCastleButton.AutoSize on many components to make them resizeable.

6. Important API cleanup: We now have TCastleUserInterface.Translation property, consistent with TCastleTransform.Translation.

   The previous TCastleUserInterface.AnchorDelta is a deprecated alias for Translation. The HorizontalAnchorDelta, VerticalAnchorDelta, Left, Bottom are deprecated.

   This change is fully backward-compatible. We deprecate some things, but they all continue to work as before.

Screenshot for this news post continues our tradition — “if you don’t have a perfect screenshot to illustrate your features, just find a pretty model on Sketchfab and show it rendered using CGE” 🙂 In this case, I searched for “smooth” and found this beautiful monster: Gears of War – Grinder by nataliedesign.

Our components TCastleDesign and TCastleTransformDesign just got a number of significant improvements. I added a context menu to them to edit, revert, and open a referenced design. I fixed drag-and-dropping of .castle-transform. I even made a safeguard to not crash when you recursively reference yourself 🙂

All of this and more is now documented in the manual chapter about TCastleDesign and TCastleTransformDesign and demonstrated in our new video:

Try them out and have fun! And if you like it — please support us on Patreon.

I am proud to announce I will give a talk about Castle Game Engine at GIC (Game Industry Conference) in 2 weeks!

The conference is at 7-9th October (Friday-Sunday) in Poznań (Poland). It’s full of talks and events for game developers, from all around the world, in any technology. I attended it 4 times in the past and really advise it, it’s full of good talks (and majority of them are in English, suitable for everyone, anywhere around the world). The conference is, as every year, close to PGA (Poznań Game Arena), a game expo aimed at broader audience interested in games.

Our talk is part of GIC agenda. The detailed timeline does not yet assign the talks to days, but for sure it will between 7-9th October (Friday-Sunday).

If you want to join us, go ahead and buy a ticket to attend in-person (our talk is at Intermediate level, so you need at least Developer Pass). I see that this year, they also offer tickets to watch online – Pay What You Like and support Ukrainian gamedev (the online tickets grant you access to all talks and even business meetings — see the website for details).

See you in Poznań! 🙂

You can now define a “component editor” class to add commands to the context menu when you right-click the component in CGE editor hierarchy. Detailed instructions and example how to do this are in manual: Add “verbs” to the context menu for given component.

A full working example application is in examples/advanced_editor/custom_component, it defines a verb “Reload URL” over sample TImageGrid defined in that project.

This feature is already used by some built-in components:

1. “Reset Transformation” is now available for TCastleTransform and all descendants.
2. “Reload URL” is available for various components that load things from files (TCastleScene, TCastleImageTransform, TCastleImageControl).
3. “Edit”, “Revert”, “Open” are available for TCastleDesign and TCastleTransformDesign. These new commands will be described in a separate upcoming post — they greatly enhance how you can reuse the designs.

Thank you everyone for joining last Saturday and participating in our open meeting!

1. Short summary: I did a recap of the recent work on the engine (I think it was too long, but that’s because we did a lot of stuff 🙂 ), Andrzej Kilijański presented his work on physics joints, I talked about plans and answered many questions.

   Thank you for all the questions. I tried to answer them live, then I collected them and answered again on Discord chat so you can read them starting from this message.

   One question also sparked a new example in engine: examples/animations/animate_bones_by_code. It’s a demo how you can animate bones (transformations) by code while a predesigned animation (predesigned in Blender, exported to glTF) still runs on the same 3D model. The README.md inside this example explains details (and also notes current limitations and how we plan to overcome them).

   It was also fun to experience “Access Violation” at one point during the presentation. This was an unwanted visitor 🙂 Of course it is fixed now.

2. Same time in +3 months! I am announcing our next meeting, on December 10th (2022; as usual this is Saturday), at the usual hour (15:00 UTC).

   I advise you to go to the meeting on Discord right now and click there on “Interested” and add it to your calendar (click on “…” to see “Add to Calendar” option on Discord event). You don’t want the timezone stuff to surprise you :), and adding it to your calendar this way makes it reliably accessible in your time.

3. Longer summary:

   Michalis: Recent things done (with links to read more):

   1. New cameras. Design-time navigation, right click in 2D 3D. Default 2D and 3D viewport nice. More info in this video.
   2. Fog component.
   3. Terrains
   4. GitHub Actions / GitLab CI / Jenkins possibilities. See castle-game on GitHub and test-gitlab-ci on GitLab.
   5. Material properties plans: focus on AMD Compressonator, KTX.
   6. Better drag-and-drop support in editor.
   7. Not Quake demo – real-time multi-player game using Castle Game Engine + RNL.
   8. Patreon changes.

   Andrzej: working on physics joints.

   1. “Joint” connects 2 rigid bodies, such that the connection acts naturally when something collides with one rigid body. For example, hinge joint allows to make realistic behavior of door opening
   2. On Andrzej branch: You can configure joints in editor too.
   3. Customize joint anchor position, by dragging a gizmo.
   4. See transforms affected by joints as wireframe.
   5. Limits for joint rotation.
   6. Rope to hang something.
   7. Can be used to create a chain.
   8. Breakcable configurable.
   9. BTW: you can change whole rendering to wireframe.

   Michalis: Plans:

   1. Immediate plans: Review new physics component, review joints, merge. Optimize node’s memory usage.

   2. Plan for 2022 still mostly doable.

      Done already: cameras, physics (almost), lights, documentation + website improvements, 7.0-alpha2.

      Definitely will be done in 2022 (so before 7.0 release): AI behaviors (new fps_game), nodes optimization, Steam integration, 7.0 release!!!

      Maybe (important things which would be very cool): TCastleEnvironmentLight, materials customization, WebGL.

   3. Come listen to me at GIC in Poznań (Poland) – this October 7-9th.

If you host your projects on GitLab, this will be a treat for you: We have done, tested and documented an integration of CGE projects with GitLab CI/CD. In simple words, it means that after each commit and push, GitLab can completely automatically (and for free) build your project (giving you ready packages for Windows and Linux).

We have documented how to use GitLab CI/CD here. It’s really trivial — just add the .gitlab-ci.yml file to your repository, that’s it.

We have an accompanying project on GitLab castle-engine/test-gitlab-ci that shows it in practice.

Note about alternatives:

• Do you use GitHub? Use GitHub Actions with Castle Game Engine.

• Do you use Jenkins? Use Jenkins with Castle Game Engine.

As you see, I really like continuous integration/delivery. It’s a helpful automation doing a job for you and it’s really easy to set it up in various environments. I’m proud we have documented options to use it with Castle Game Engine.