Forest Fortress

Real Time Strategy game about little forest guys battling for reign.

I participated in the Little Guy Game Jam #2. I recruited former teammates from other game jams to complete this project: RatDrum, Audio Designer; RustyScreech, 2D Artist; CrimPatches, General Artist; and SirSunstone, Narrative Writer. This jam only asked for us to include little guys, so we represented this through little forest creatures in a real-time strategy game.

When planning this project, I used Canva to first compile game mechanics that I currently had the skill set to develop: adventure, stealth, escape rooms. I also included mechanics that I was interested in trying, including idle clicker and pet simulator. When SirSunstone proposed a real-time strategy, I considered how my skills in developing finite state machines could be applied here, as well as how I wanted to develop my skills in advanced AI agents. After charting the base actors, objects, and behaviours needed to create this game system, I was on board and developing the next day.

The first step I took was to extract code from previous projects, including an Audio Manager, Menu UI Prefab, and Scriptable Object Data Containers. I chose use Scriptable Objects as data containers to extract data from the functionality of the code, keeping the code base cleaner and the data easier to find and manipulate. This was especially useful for the Game Manager data, character Units data, Audio data, and Buildings data.

Another experimental choice was to limit the number of Monobehavior Start and Update functions used in the game. I used the GameManager's update function as the primary game loop and created custom Update functions for other scripts so I could control the order of execution of the other core scripts.

After adding the Menu UI (which I would continue to develop throughout the project), I immediately began on the Units and the enum-based state machine(s). The essential aspects to develop were: what were the simplest variations of the units needed, how were states being tracked, and how were state actions being executed. Originally, state actions existed within the unit variations, and the manager would deduce if the unit was of type ResourceUnit or AttackUnit, and proceed through the state conditions from there.

I began testing the ResourceUnits first, using simple position translation for movement and debugging if the unit would collect the resource when in proximity. For the real-time strategy aspect, it was important that the units operated on partially autonomous AI, such that the player could command and direct the units to make specified actions and the AI could 'bid' for autonomy and act on it's own. I was able to get the resource unit fully autonomous and separately commanded by the player, but could not get them to act together.

[Aside: While I have lists intended to be reusuable object pools, I haven't yet adjusted the code to take units from the pool before spawning new ones.]

The resource unit would bid for if it could proceed with it's state's action; if it could, it proceeds with a coroutine, and if it couldn't another, coroutine times when it can retry the bid. Before I implemented this, I was able to select a unit, select a resource on the map, and the unit would then follow the course of collecting and then storing that resource. But I reached a point where I struggled to have both of these processes operable at once.

I sought support from the Work With Indies Discord server, and after a few hours of discussion settled on the suggestion to change my state machine to a Push-Down Automata (PDA) System. This would be a halfway point between a state machine and a behavior tree. I would go on to re-implement the partial autonomy system in this way, developing an Action interface and separating the actions from the unit's code, and using a List as a Stack to control which action was executed each frame. The individual action's would check if they could be executed based on internal or unit variables, and give the UnitManager access to execute if no invalid conditions were triggered. This took quite a bit of organizing and testing to find where variables needed to be stored, how and when they were being updated, and how actions would be added to and removed from the stack.

I continued to test until the resource unit understood the difference between player input and a successful autonomy bid, and could navigate between Hold, Collect/Store, and Move. After this, I could test the AttackUnits, especially for targeting a random enemy and spawning enemy units.

Some of the other issues I had to resolve included:

• Active ResourceUnit moving to InactivePool, causing error since there are no game objects in ActivePool (unit started with 0 health)

• A stack overflow exception on a bool (variable accessor referencing itself)

• Strong AI overpowering player input response time (reduced the autonomy weight)

• The actionQueue loading as null despite multiple inits, was due to last Hold() being removed (adjusted the clause so that if there's only one holdaction in the queue, to leave it and not destroy it)

• Adjusting from coroutines to float-based timers (could be ticked while in non-monobehavior Actions)

• Printing time into the HUD (presented format adjusted based on minimal value)

• Colliders hiding under each other, 2D layering of trees and other objects, and many more!

Overall, I'm extremely pleased with how the development of this project turned out. I've learned how to use simple data structures to take more control over the execution and conditions of my code. I will be taking this system apart and creating a modular reusable version of it to be utilized on further projects. Developing new systems from scratch is very time-consuming, especially during a game jam, but the pressure allowed me to accomplish something great, and I now have a head start on my next real-time strategy game.

View on Github | Play on Itch.io