In this series, we will share how the first iterations of "Branch Line Adventures" came to be. We would like give a glimpse behind the curtain, share our thoughts, why we implemented things the way we did as well as point out some interesting issues and their solutions we encountered along the way.

Whilst last weeks post focused on the idea finding process, this week's post is about the planning, what we wanted the game to be like as well as the reasoning behind some design and technical choices we had to made early on.

Project Scope

After having found the basic game idea (see the first post of this Postmortem series), we needed to flesh it out in more detail. Since we both knew that without proper planning and design requirements we would not be able to finish the game during the game jam, we spent a considerable amount of time discussing what we want the game to feel like, what is absolutely necessary for a good playing experience, what can be optional and so on. There was no specific theme for the Honest Jam 6 announced, with the only requirements being pacifistic core game play mechanics and a playable web version of the game, so we could plan relatively freely as long as we did not want to incorporate the optional modifiers.

Game Play Mechanics

After a lengthy discussion, we restricted the game play to four, what we at the time considered to be simple processes:

1. The player draws a random card and has to place it according to the rules onto the playing field. Each card is associated with a specific amount of points, which will be rewarded when a chain (e.g. a railroad between two stations) is finished, and costs, which will be added immediately to the total.
2. When finishing a chain, the player receives points (like in "Carcassonne"), but for balancing reasons might also obtain an additional card (like in "Dorfromantik"), so that the game duration is only limited by the skill of the player and not the size of the card deck.
3. Special Cards (e.g. a card with a School Building on it) have special requirements to their surroundings. When these requirements are met, the player is awarded additional points (like in "Carcassonne") and possibly other bonuses (as a measure of balancing the game during testing).
4. When the player has run out of cards, the game ends. Remaining points will be awarded and a efficiency calculation of the tile usage will be performed (usefulness for transportation capacity and utilization factor due to tile placement relative to its cost). Based upon these statistics, the final verdict whether the network will be closed is determined.

The intention was, that a tile has two different properties attached to it that determine the total score of the player: The "traditional points" as a reward for finishing a quest (e.g. a road in "Carcassonne" or built a certain number of houses in "Dorfromantik") and a complex efficiency metric, which is calculated by how useful the railroad line is in terms of building costs, upkeep, passenger and freight traffic statistics and efficiency of resource utilization. This would be taken into account at the end of the game and be used to determine the final verdict on whether the railroad will be closed. This was the novel feature we wanted to implement in order to add an interesting twist to the "Carcassonne" and "Dorfromantik" rules, as we did not want to make a straight-up clone. This game play mechanic was inspired by the creativity and wit which the railroad staff showed during the end of the narrow gauge network in the region, trying to keep operations going as long as possible, even though the bureaucrats wanted to close it for a long time. Besides making the game more interesting, this game play mechanic would also allow for future inclusion of a story about railroad staff versus bureaucrats, addition of constraints to tile placement rules during the game by introducing silly/strict regulations created by bureaucrats or even (in)direct "boss battles" in form of player versus bureaucrats (perhaps even turn/interlude based).

At the time, we felt quite confident that we could create a game with all those features within a week. There were many other ideas that we wanted to implement, but even before starting, we were certain that this will not be feasible during the duration of the game jam:

• After the Building Portion of the game is finished, the player should then have the possibility to optimize the time tables, used trains etc. to obtain the best cost efficiency and customer requirement fulfillment possible for the world that has been created. Basically, this would add a management simulation component to the basic puzzle/building simulator mechanics of the core game.
• 3D Landscaping, where when the player places mountain tiles, the rest of the play area gets raised/lowered accordingly.
• Two Building Stages: First build only the landscape with a set of random tiles, then afterwards try to connect important places with a random selection of infrastructure overlays.
• Multiplayer-Mode: Either classical (like in "Carcassonne") or two players against each other ("Nature vs. Infrastructure": one player building the landscape, the other has to place the infrastructure simultaneously).

Technical Goals

Since we wanted to focus more on the technical aspect of the project than the artistic one as well as create code and pipelines we could reuse in other projects, we decided to heavily focus on build tools, pipelines and procedures; definitely much more than would have been required by a simple game jam project (at least we thought so at the time):

• Integration of C++ code into Godot via GDNative/GDExtension,
• Functioning Web Build while using GDNative/GDExtension,
• Cross-Platform GDNative/GDExtension Build Tools,
• Cross-Platform Export of Godot Executables,
• Script based Art Asset Creation Pipeline (since we are both not very talented artists and are way better in coding).

The Web Build was the only technical requirement resulting from the Honest Jam 6 rules, but we would have attempted it anyways, even if it would not have been mandatory.

Why is GDNative/GDExtension so interesting?

Up until now, we mentioned several times GDNative/GDExtension without properly explaining what this actually is. In short: The Godot Engine provides due to its API design the option to include plugins for using other programming languages than the officially supported ones (GDScript, C#, C++ (only to an extent, as it is not directly available like the other two, only via GDNative/GDExtension)). Depending on the individual plugins (which are developed by the community), it is possible to access Godot Engine functionality within for example Python, JavaScript, Lua, etc. (for a more complete list: see e.g. https://github.com/Vivraan/godot-lang-support) and also vice versa. For Godot 3.x, the implementation is called GDNative, where as in Godot 4.x its name is GDExtension. In principle, the functionality is for both variants almost identical. However, there are some minor technical implementation differences which are beyond the scope of this postmortem.

In the past, I already utilized Python with Godot and was surprised how easy it was (despite some problems originating from the Python backend, for which Godot can not be hold responsible). This made me keen to experiment with C++ inclusion, because if it would also be simple to use, I would have the option to integrate into Godot the two programming languages I use on a regular basis. Furthermore, the huge amount of available utilities, modules, etc. written in C++/Python and my personal back catalog would allow for rapid prototyping. In addition, C++ might give a performance boost compared to GDScript or even C#. This is not only beneficial for game development, but in my humble opinion, the GDNative/GDExtension feature renders Godot also very useful outside of game development for e.g. scientific applications, which I am personally very excited about and would like to have a go with.

So why bother with GDNative/GDExtension for a simple game jam project? For the type of game "The Cévennes Express" was decided to be, there was neither much code publicly available and we did not have anything suitable in our personal back catalogs, which did not create any rapid prototyping benefits, nor was there the need for any high performance code or exotic libraries. The answer is simple: At the time, it seemed to provide a good opportunity to experiment with C++ inclusion into Godot before tackling a more complicated, and perhaps even non-game related project.

Why Godot 3 LTS instead of Godot 4?

Ever since the release of Godot 4 in March 2023, there has been a lot of praise for the new version. However, a fact that is often overlooked, is that Godot 4.x (and especially Godot 4.0) is/was not a feature complete release, as the Godot Core Development Team has also stated multiple times, so the Godot 3 LTS version has definitely a right to exist. Giving general advice on which version to choose is very difficult, since the project specific requirements heavily influence the decision criteria. In addition, the rapid development pace leads to so much change, that a lot of information is quickly outdated. That is why we can give only a very subjective, incomplete, mostly project requirement related comparison between the drawbacks of each version as it were in December 2023, when we started the project.

Drawbacks Godot 3 LTS

• No built-in method for raw image rotation (except for Sprites) exists.
• No Vector2 with integer support (always float) can potentially lead to conversion precision errors and can potentially require excessive warning suppression.
• Integration of custom fonts/icons is not very elegant.
• Text formatting with the old font import and BBCode standard is very cumbersome/limited and often requires (manually) placing escape sequences or pixel pushing icons in continous text.
• Design/Architecture of Godot 3 and consequently GDScript 1.0 is a bit messy. A side effect of that is that the object naming conventions are not as consistent as in Godot 4.
• No access to Compute Shaders is available.

Drawbacks Godot 4

• Performance on older hardware/in web browser on low computing power devices can be half (or even less) as good as with Godot 3 from an fps and dropped frames perspective.
• In some cases, Godot 4 applications using the Forward+ render engine will not even run due to missing Vulkan support or be unusable due to unsupported Vulkan features in the fallback render engine.
• GDScript 2.0 had a lot of changes, so one with Godot 3 experience would have to re-learn the language quite a bit.
• GDExtension is allegedly not completely implemented.
• Documentation not complete at the time of beginning the project (December 2023); especially more niche topics like GDExtension.
• Web export only officially supports GDScript, which does not necessary mean that web export with GDExtension is impossible, but could add a serious amount of uncertainty and debugging time.
• Many addons not yet ported.

The only reason we could see why we should use Godot 4 was if we would have the need to use compute shaders. Since we did not need them and they would actually interfere with our web export ambitions, as well as the missing documentation of compute shaders in Godot 4, this was not a hard decision criterion for us. Speaking of documentation: In December 2023, the Godot 4 documentation was still lacking a lot of detailed information; at the time of writing (June 2024), this has improved by a lot. Still, one has to consider that the Godot documentation in general (that is unfortunately also true for Godot 3 LTS) is sometimes not as detailed as one would wish.

For this project, our main decision criteria was the web export capabilities: The game jam had a somewhat mandatory requirement for a playable web export, so we investigated the possibilities and limitations very diligently. As long as we would have limited ourselves to GDScript, web export with Godot 4 would not have been an issue in December 2023. Back then, as soon as one would like to use even C#, it would not work (and still does not at the time of the writing (June 2024)). Since there was conflicting information about the implementation status of GDExtension even for conventional exports and the GDExtension documentation was very lacking, it was too much of a risk that it might not work, which was the main reason why we decided to use Godot 3 LTS. Another positive side effect was that I could still use GDScript 1.0 and would not have to learn a new language flavor, which would make the development process easier for me.

The decision to use Godot 3 LTS also had some negative side effects: Since the majority of people was adopting Godot 4, most new tutorials were made for this specific version and older tutorials were updated or removed. Consequently, sometimes one could only find resources for very old Godot 3 versions, which are not all compatible with the current Godot 3 LTS release. For features added in Godot 3.5, Godot 3.6 or features back-ported from Godot 4, one had often the sometimes a bit meager official documentation as the only source of information. This left a information gap, but luckily did not occur too often so that it did not really hamper the development significantly.