Corner Kingdoms
Corner Kingdoms is a splitscreen RTS game where players build up their kingdom and fight against their opponent. The game is built in Unity and started because I wanted to expand a previous similar project named Birds and Blades. The game is currently in development.
- Exciting 2-4 player gameplay
- Fight in teams or every man for themselves
- Procedurally generated world every game
- Simplified RTS style gameplay
- No limit to army size. Bigger army, better person.
- Resource graph after the game ends
I have a couple development videos on the process of making this project.
Mechanics with a theme of simplicity.
Movement
Players and units alike move around the map on a Unity NavMesh. This allows for easy pathfinding and movement. As a comparison, the previous game I made, Birds and Blades, didn't use a pathfinding system.
The units only moved in a straight line from point A to point B. This was a lot easier to implement, but it didn't allow for any sort of interesting movement: walls couldn't be added, and units couldn't move around each other. It just made for a cluster of a battle.
With the NavMesh, units can move around each other, and the player can add walls or towers to block their opponent's units.
To save on performance, the NavMesh is only generated once at the start of the game. This way, the NavMesh doesn't have to be generated every frame. And obstacles like walls and rocks use what's called a "Nav Mesh Obstacle" that cuts out a section of the NavMesh so that units can't move through it.
The Movement system is also designed with reusability in mind. I use the same movement system for both the player and the units. This way, I don't have to write 2 different movement systems, and I can easily add new units or creatures to the game.
// BOX FORMATION MATH
float row = Mathf.FloorToInt(i / boxWidth);
float column = i % boxWidth;
// only apply if unit is in the last row (centering)
if (i >= lastRowStartIndex)
column += remainderInLastRow / 2f;
Vector3 dir =
transform.forward * (row + 1f) * patternSpacingMulti +
transform.right * (column - boxWidth / 2f) * patternSpacingMulti;
dir = MaxPosWithHit(dir); // limit the position to only be on the NavMesh
SetUnitPos(unitsToRally[i], dir, unitsToRally[i].GetStats.maxMoveSpeed);Another cool aspect of the movemnt is the formation system that I added. You can hold a button and cycle through various unit formations.
Combat
The combat in Corner Kingdoms is a simplified version of an RTS game. The player can select their units with a circle that adds to their current selected units.
private void SelectNearbyUnits()
{
float distanceToPlayer = (unit.transform.position - transform.position).sqrMagnitude;
selectedUnits = PlayerHolder.GetUnits(identifier.GetPlayerID)
.Where(unit => distanceToPlayer < currentSelectionRadius * currentSelectionRadius && unit.GetIsSelectable).ToList();
}The reason I use "sqrMagnitude" and not "magnitude" is because "magnitude" squares the calculation automatically, making the process slower. So if I just compare "sqrMagnitude" to the radius squared, I can get the same result, but faster.
And keeping the theme of simplicity, I went with a 1 button approach to combat. Once your troops are selected, you can click the "Rally Troops" button to call your selected troops towards your location. Depending on where you're standing and where your troops are relative to enemies, the troops will attack the enemies.
Staying in the realm of troops attacking enemies, there were some interesting technical difficulties that went into units finding the nearest enemy...
Attack - Spatial Grid
When you have hundreds of units on the screen, it can be very taxing on the CPU to have each unit check every other unit to see if it's the closest. You have to loop through every unit, and then loop through every other unit to see if it's the closest. This is an O(n^2) operation, and it can get very slow very quickly.
So to combat this, I implemented a spatial grid. The Spatial Grid is a 2D array of lists. Each list contains all the units that are in that grid cell. When a unit moves, it checks to see if it's grid cell has changed. If it has, it removes itself from the old grid cell and adds itself to the new grid cell. So when a unit wants to find the nearest enemy, it only has to check the units in it's grid cell and the surrounding grid cells. This is a lot faster than checking every unit on the map.
private void CellFindNearestEnemy()
{
int cellsOutToCheck = Mathf.CeilToInt(lookRangeWithHeight / UnitCellManager.cellWidth);
Cell activeCell = UnitCellManager.GetCell(transform.position);
Vector2Int bottomLeft = new Vector2Int(activeCell.pos.x - cellsOutToCheck, activeCell.pos.y - cellsOutToCheck);
Vector2Int topRight = new Vector2Int(activeCell.pos.x + cellsOutToCheck, activeCell.pos.y + cellsOutToCheck);
Cell[] cellsAroundMe = UnitCellManager.GetCells(bottomLeft, topRight);
SetNearestEnemy(ReturnClosestEnemy(cellsAroundMe));
}This change severely reduced the complexity of finding the nearest enemy . This is a huge improvement, and it allows for a lot more units to be on the screen at once.
UI / UX
The UI is designed to be simple and easy to understand. I wanted the barrier of entry to be as low as possible, and when designing an RTS game, this can have it's challenges. I think I've done a good job of making the game easy to understand, while still having a lot of depth.
As the base UI, the player can see their resources (current and income/min) and the amount of units they have. I like to have UI only show up when necessary as it removes confusion for newer players and makes the game feel more immersive. So when the player selects a unit, the UI changes to show which units are selected. Same goes for queuing units, the UI only shows up when the player is queuing units.
UI shows up for when units are queued
UI shows up for when units are selected
And for the build menu, every RTS game that I see always has such a complicated build/upgrade menu. I think when you're playing a "party game" with friends, you don't want to have to spend a lot of time learning the game. So I wanted to make the build menu as simple as possible as well.
When first opening the build menu, the player is presented with only a couple buildings. A way that I achieved a simpler build menu is through an upgrade system. The player can upgrade their buildings to change the building in some way.
For example: a player places down a house to increase population. From there, they can upgrade this house into a village house, an archery range, or a blacksmitch. This way, the player doesn't have to learn what each building does, they can just upgrade their buildings to get the desired effect and thus a simpler build menu.
Procedural Generation
The map is procedurally generated every game. Certain elements of the map don't matter as much due to a surplus of resources, like trees. Those are generated using the Perlin Noise algorithm.
But other elements that aren't as common are generated with a grid division algorithm. This algorithm divides the map into a grid, places at least x objects in each cell, then randomly places objects in each grid cell. This way, the map is always different, but resources are distributed evenly.
In Birds and Blades I just randomly placed objects on the map, but this led to the map being very unbalanced. Simply put, the location of your spawn heavily dictated who would win the game. So I wanted to make sure that the map was balanced, but still different every game.
