Status Update: October 2024

I will be making daily posts to this devlog for the next month, as I have decided to join Devtober. I think the idea is really cool, because I think putting in consistent, near-daily time for game dev is one way to make a larger game than anyone thinks a solo dev is capable of. I’m making this first post, before properly starting work for the day, to introduce everything that I have already done for this project up to this point (and help myself feel a little bit better about my slow progress in the process). This is a list of features coming from six years of work, and many false starts. It’s not an attempt to overwhelm, or to brag, either. There are very critical subsystems missing that prevent this game from being fully playable yet, and most of the assets have yet to be done. I am just trying to show a starting point, so that when I explain my process in my posts, there’s some context about what I’m working with. The way I will work for the upcoming month is not really different from the way I normally do things, as I already work on my game near-daily at a steady, not strenuous rate (though I have taken weeks/months off over time). The only difference for this month’s “challenge” will be that I am slightly more public about it and making daily progress posts.

To clarify, this game is an RTS, where the main mode is single-player, asymmetric skirmishes against the computer, and the player’s macro is exploration-based rather than base-building-based.

Over the course of six years of development (four if you count the fact I started the project over with a different project structure), I have implemented the following subsystems:

• A grouping system for units. Grouped units share buffs as well as orders. Groups can be split into more groups, and different groups you control can be merged into one.
• An ecosystem health system. Local ecosystems have a base recovery rate, but take damage over time if the map contains harmful buildings. There is also a “global” ecosystem health: the sum of all maps’ ecosystem health values. If global ecosystem health falls below the “game over” threshold, the player loses the skirmish.
• A finite state machine data type that also holds data for a group’s order queue. When an order is finished or invalidated, this system automatically transitions to the next state in the queue.
• A queue eligibility checker system for a group’s queue of orders. This system responds to signals emitted from other game objects
• A data type for the map, which contains terrain. Maps have entrances and exits to other, connected maps.
• A building system. Buildings occupy terrain tiles and cause ecosystem damage over time.
• An inheritance system inspired by real-world genetics. Each fauna has a clump of randomly-generated binary data that is its “genome”. Its morphology, appearance, and traits are deterministically determined from this data. The data is also “diploid”–there are two bits for each trait; 3 is homozygous dominant, 2 or 1 is heterozygous dominant, and 0 is homozygous recessive. New units can be generated with two other units as “parents”, randomly inheriting one bit from each of the parent’s genome for each locus.
• Recently, I modified the inheritance system. Instead of each bit being inherited independently from the parent genome data, the system now simulates gene linking by separating out the diploid parent data into strands, and then placing crossing-over points.
• A behavior tree for NPC “factions”, which are a collection of multiple NPC fauna groups with shared goals. Many “enemy” factions have behavior where they build and maintain buildings in their industrial “base”, and continually expand outward into more maps.
• A resource system intended to reflect “biodiversity”. This consists of hundreds of different possible items in a data table. Different resources are available across different maps, reflecting the biome and local ecosystem. There is a rarity system, too.
  • The system that generates resources cares about the current season and current ecosystem health as well. Some resources, particularly rarer ones, become temporarily unavailable (out of season), or extinct due to ecosystem damage.
• An upgrade system. Each fauna has multiple possible upgrades (with “recipes” among the item resources)
• A modifier data type which traits and upgrades use to change a fauna’s stats in various defined ways in a data-oriented way. Actual modifiers for traits and upgrades are then defined in the data tables.
• A system parsing, validating, and packing data from designer-friendly csv spreadsheet files into data files the game can use (strongly-typed struct-like objects). Any error in the spreadsheet yields detailed error messages.
  • If Godot Engine ever adds actual structs, I will take time to refactor these data objects to these for additional performance.
• Damage types and armor types, which create matchups between different types of fauna units.
• Damage calculations. Removing fauna units from the group (and map) they are in when they are defeated. There is respawn logic that may or may not stay, depending on balance needs of the eventual game.
• A spawn pool, which in game is coded as a special “building” type but has a unique order associated with it. A group using the spawn pool gets new units added to it over time.
• A navigation system. Units find paths independently and avoid each other and barriers in the map while following the group’s orders. Units in a group move through corridors in a single-file line
• A coloration and patterning system and accompanying 2D shaders for each display type (mesh and illustration). This applies colors to the fauna units based on the fauna’s unique personal genetics, making each fauna a uniquely distinguishable individual.

That’s for backend game mechanics. On the display and user interface side, I have the following features so far:

• A variety of ways of moving around the map: middle-click pan, edge-scroll, and WASD all implemented.
• Drag-rect to select units. Selecting whole groups with double-click. Selecting groups through clicking “leaf” display links at the top of the screen.
• Splitting and merging units.
• A world map of the continent that shows which maps are connected to each other.
• A minimap display that shows the terrain of a level in pixel form, as well as the current locations of fauna, buildings, and collectibles.
• A basic tutorial system that pops up explanation windows for certain gameplay triggers.
• A notification system that pops up small messages at the screen’s side for triggers like group being attacked, ecosystem health reaching a certain threshold, and idle groups.
• A menu to re-order the commands in a group’s queue.
• Display windows for status of map locations, buildings, units, resources, and some types of orders (the ones with timers associated with them).
• An animated analog and digital clock to show the current time, day, and season.
• A day night cycle, with 2D directional lighting.
• A display type for units that includes a rigged 2D polygon mesh, an animation tree, and logic for controlling and blending between the animations (as well as pass-through logic for unit types awaiting assets).
• A display type for static illustrations/portraits for fauna units that shows more detail.

You may be thinking, “Oh, wow, Oocu, you have so much done already! Isn’t your game nearly finished then?” to which I have to respond, sadly, no. Critical things like combat collision checks (in a way that actually works with multiple maps running at once, so no built-in physics system which assumes only one “world”), terrain passability of different fauna types based on method of locomotion, fog of war, and exposing many of the control capabilities to the player through the user interface are yet to be finished. And that’s not even counting the fact that I have done no audio work yet, and very few of the visual assets. That’s what Devtober is going to be about. Working on some of the stuff that’s remaining, to get me closer to pulling this massive undertaking all together into a playable alpha build.

Some of my August and September was spent working on jam projects instead of this game (for GMTK and Brackey’s jams respectively). I like game jams for the socialization and collaboration with other devs! But as I was looking through jams on Itch to decide if I wanted to take another break to do one, this one caught my eye as a way to “jam” while continuing to work on my main project.