In the meantime, I got married, and my wife is making a way better videogames than I do.
But anyway, since last time I’ve been making quite some progress on new systems I need to get to a prototype state. And by prototype state, I mean a game in which I could pour some content to get my main game loop to be tested not only from a functional perspective (does it work?) but from a game perspective (do you have fun or do you see yourself having fun with this game?).
One of the bigger system for which I managed to make a first iteration is my Journey System. As KED is a transportation game, determining journeys between an origin and a destination, proposing itinerary options, calculating the resource costs for each option is central. For now, most of it is rather static in the sense that there isn’t much logic and most of it is precalculated and put in data points.
I’ve opted for a quite simple data architecture with journey points (point on a map with basic information such as position and elevation), journey legs (a piece of journey between two journey points, where most of the game data sits currently, such as the distance, the dangerosity, the speed ratio,…) and journey options (an end-to-end way to reach a location from another, composed of journey legs and linked to a journey that specify the origin/destination). As you can see, with this structure, I don’t calculate journey options on the fly: each option is predetermined. It could look like a major shortcoming for the game, but I actually think it makes sense, because those journey options are to be discovered by the player, and can therefore be part of the storytelling. I don’t plan on this game to a a realistic business or cycling simulation, but rather an exploration game with added management mechanisms.
In Godot, I created all those objects as Resources. I hesitated with using a static database file, as they could probably fit in a single csv or Json. But opting for Resources has been quite a good intuition, as I ended-up using the capacity for Resources to host functions (a nice feature of the Godot engine). It helps me to encapsulate the support functions for specific data points within them: the function to calculate the duration of a leg (based on the player effective speed) is in the JourneyLeg Resource, and the function to calculate the total distance for an itinerary is within the JourneyOption. Sure, I end-up with a quite fragmented code base, as you don’t have a single one script where all the functions related to the JourneyEngine sit, but I feel that it will be easier to maintain and expand when needed, as changes to data entities will be made in the same place than the basic functions that work on them. I also hope that it will allow me to avoid rewriting more core elements of the code when doing changes.
Beside the JourneyEngine, I’ve also added a TimeManager. In my game, time is one of the main player resource. When the player does something, it costs them time, and therefore, choices must be made. Most of the actions of the player are done instantenously (a discussion that would take 30min would be read in a few seconds), but I do wanted that actually doing the journeys would happen in real-time, so that in a later phase, the player could change their plan as they go. The TimeManager therefore support both way of « using » time: as a ressource spent at once or as a real-time flow, with the possibility to consume other ressources, trigger events and display progressive animations. It’s still quite bare bone, but is in a state that I can move forward with.
The next step now is to implement more than the two locations and characters I’ve made to test the system, in order to start testing the game. Even if there is still quite some missing scope and if I could spend more time building more systems (I believe this is what I like the most), it would be foolish to move forward and end-up with a big pile of systems that don’t make anything close to a game.