Callum Pearce Game Programmer

Enemy Confederation was the main project that highlighted all that I had learnt on my undergraduate course. Being heavily inspired by Age of Empires, I challenged myself to create a very similar style game with a strong focus on the AI. Total development time was about 8 months over the course of my final year.

​

Being an RTS, a lot of features were needed to be implemented. One of the first that had to work from the start was the pathfinding. This was created using an A* pathfinding algorithm to find the shortest route across a grid of nodes that were laid out across the terrain. These nodes defined their world position, grid position and whether that node was walkable. This formed the foundation of the whole game as things like buildings, resources and units all needed to update this grid of nodes.

​

Pathing allowed for the largest system to be developed which was the unit system. This system was vital as it is what connected all other systems including the resource, building and combat systems. All units could be individually or within a group commanded to perform tasks such as gather, build or attack, requiring wide range of subsystems such as selection, movement, gathering, building and combat. The resource system uses a manager to place the worlds resources in groups all over the map at the start. Units can then go gather from these resources and return them to their base. The building system allows the player to place down buildings that cost resources, allowing for additional population or the training of more units. Once placed, additional units can be commanded to go build decreasing the time. The combat system is what allows the player to win, by extinguishing their opponent. It allows units to go attack other units or buildings by dealing damage to them.

​

Defined above were two levels of AI. The low-level pathfinding, and medium-level unit decision making. The final part left is the high-level AI that simulates a real player. This was by far the trickiest part of development, as the game had reached a complex level and already there was a lot for the player to manage. To help break it down, the opponent had 3 strategies defined on how they chose to play: offensive, defensive, and balanced. Offensive focused on attacking the enemy early and focusing more on combat. Defensive relied more on gathering resources, and spending more to gain more. Balanced then did a mix of the two, rolling a dice to see if it should perform an offensive or defensive move. A command system was then made to allow actions to be performed, a lot of these commands had a requirement with them as well. The opponent would then attempt to execute a command provided the requirement was met. If the requirement wasn’t met, each requirement had a corresponding command it could perform. If an opponent cannot process a command yet, they would then wait some time before trying again. It can go down a complicated chain of commands, but that is exactly what a player does without thinking. For example, in the game to build a house you need resources. If you don’t have the resources, you need to assign a villager. If you don’t have an idle villager, you may try and create a new one… which can go on and on.

​

Creating a realistic world came at the end of development. Importing proper assets to represent different unit types, building types and resources. As a lot of the game was interacted through UI, it needed to be working properly, clearly showing information such as unit stats, resources, and selected object options. Finally, on a very basic level music and sounds were implemented with selection, building, gathering and combat sounds.