Untitled RTS Game
I've been discussing making an RTS game based on the game engine I'm developing for my maths quiz action RPG.
First the player builds a mill. Farmland spawns around the mill and villagers go to work like people in Sim City. When enemy forces are spotted, villagers teleport to inside the mill. If the mill dies the villagers inside also die and the player's pool of available villagers decreases.
If the player places a tower near the mill, the two buildings form a building group. If enemy forces arrive, villagers teleport to inside the tower. The tower shoots arrows at the enemy forces. If the mill is destroyed the villagers don't die, but if the tower is destroyed the villagers die and they are subtracted from the players pool of available villagers.
The player can upgrade the tower to a keep and then a castle, adding extra protection or firepower.
The basic unit of a player's army is a group of 12 foot soldiers, 6 horses or one elephant. The simulation treats these as one entity and then individuals are rendered separately.
Units can garrison in buildings for added firepower and protection.
Update 18/9/2026
Docks project an economic zone where villagers can sail around and fish. The villagers do this automatically and act like people in a Sim City game. Ships in deeper water project an economic zone that extends the dock's economic zone.
The player can choose between training small fast ships or large, slow, strong ships. Ships can garrison units the same way that towers do. Ships containing archers shoot arrows, ships containing cannons shoot cannon balls, ships containing rams can ram other ships.
Placing a military building near a dock creates a building group. A building group with an archery range and a dock can train ships preloaded with archers. A building group with a siege workshop and a dock can produce ships preloaded with cannons, etc.
I might not be able to make a full RTS game on my own, but these are some ideas,
Boston.
PS
I wanted to see what groups of 12 soldiers would feel like, so I made a mock-up in my work in progress game engine. They look pretty cute.
Boss
Update 20/9/2026
Villagers are like people in a SimCity game. They organise themselves to work and collect resources. In order to build, the player must recruit builders from the town centre.
A siege workshop trains mobile siege equipment. Mobile siege equipment can be used in the field or garrisoned in towers and ships. Siege workshops also train engineers. engineers are like builders, but they build things like anti-cavalry stakes, palisades and large siege equipment. Large siege equipment could be something like a trebuchet or a siege tower. Large siege equipment takes time and resources to build, and must be operated by an engineer.
Boston
Update 22/9/2026
I'm going to assemble a bunch of drawings like these and compose them into a battle field to get an idea of the visual language of the game.
Units will be divided into control groups. A control group would be like a player character and a bunch of minions, or a number of groups of 12 soldiers. Having different members in a control group would unlock abilities. Having infantry and some engineers in a control group would allow the infantry to entrench. Having a bunch of skeletons in a group would allow the player to command them to swarm an enemy.
I plan to implement both RTS and RPG mechanics in my game engine so that it will be easier to port from one genre to another.
One idea I had recently was to allow control groups to contain units owned by allied players. One player would then take responsibility for commanding a retinue of English longbowmen that are being protected by a Viking shield wall. This could lead to a rich system of allegiances. One player could choose to allow another player to command their military.
On allegiances: in a game like Age of Empires, the game usually ends when one team resigns. I have an idea for a richer style of gameplay. Player A can resign or be forced to resign to Player B. Player B can no longer attack player A, but player A is subjugated by player B. A subjugated player can continue to play and earn points based on some metric dependent on the game-type, but is forced to fight on the side of the player that subjugated them. The game ends when some victory condition is reached or all but one player has been subjugated.
That's probably enough for now.
Boston
Update 23/9/2026
I was able to colourise my sketches of the ballistas using the fill tool in GIMP3.
The game is designed to give the player control while keeping the user experience simple and focused on the more enjoyable aspects of gameplay. Civilizations don't have ages or tech trees in the traditional sense. Instead they have technology timelines. Progressing in a timeline unlocks upgrades and new features.
Each technology timeline is concerned with one category of upgrades and features. The timelines are: Economy, Architecture, Military, and Naval. The player has control over which timeline they prioritize. A team could have one player that specialises in each technology. One player might focus on their economy and send resources to the others. One might focus on building defenses and one might train units to man the defenses.
All for now,
Boston
Update 29/92026
RTS games generally have a map divided into tiles. I was thinking of making a game with a map that's divided into polygons. Instead of having to perform pathfinding going from tile to tile in a map with thousands of tiles, pathfinding would be calculated on a map made up of hundreds of polygons. To give a sense of scale, a polygon would be about 32 times the size of a map tile or the size of a clump of forest in the game.
Tiles would be nodes in a graph and pathfinding would just be finding the shortest path through the graph. There might be optimisations like covering large open areas with square tiles. Building walls and cutting down trees would modify the underlying tiling / graph. Building farms would be more of a visual change than a change to the NavMesh.
There will be 2 levels to the polygon system. At a lower level, the system will be concerned with navigation. Another layer will represent visual terrain differences. I could design a complete GIS system with multiple layers.
Trees come in groups that are treated as one entity by the simulation. If deforestation converts the ground under the trees from woodland to cleared land, the trees themselves will each decide what state they're in. The states could be upright, being logged, or fully cleared. There could even be animations for a tree swaying in the wind, a tree falling down, lumberjacks working on a tree, etc. The great thing is the simulation doesn't need to see the state of the individual trees and the trees only exist in the graphics thread if they're on-screen.
There will be a layer to the GIS system that represents what the player sees when they look at the ground. The ground will be made up of polygons filled with different textures. These would be things like grass, dirt, sand, road, farmland, or water. Water would play a special role in the NavMesh because it is only traversed by ships and fishing boats.
Farmland is interesting because farmland develops within a radius of a mill or a town with a mill. We don't want farmland to develop on the opposite side of a cliff to the mill. We would have to subtract the polygon of the cliff from the polygon of the farmland and then test for connectivity.
I think I'd want arbitrary polygons but there could be optimisations for convex polygons or even squares that match the existing spatial partitioning system.
That's enough on polygons,
Boston.
Update 30/9/2026
Here is a bit of a proof of concept for the 12 unit groups. The player gets chased by hundreds of little foxes, with not much strain on the cpu.
I was thinking about resource management in the game. Wood, stone and gold would just be resources that accumulate, that are then spent on making buildings and training units.
Food would be different because of attrition. Food stockpiled would increase over time based on the area of land being farmed, and decrease over time based on the population of the players civilisation.
Population would be another resource. The civilisation's population would limit the number of available SimCity workers and units. The population would grow when there's plenty of food and housing, and decrease when there's a food or housing shortage, or when SimCity workers or units are killed.
A man can dream :P
Boston
Update 3/10/2026
The game will be designed around having a modding community. The game will have map theme packs and civilisation packs. When an object is spawned in the graphics thread, the game will first search for assets in the graphics pack associated with that civilisation. If the civilisation pack doesn't contain an asset for the object being spawned, the game will search for an asset in the current theme pack. If the theme pack doesn't contain an asset for the object being spawned an asset from the default pack will be used.
It might be nice to swap out themes during gameplay. The game theme could switch between summer / autumn / winter / spring themes or day / night themes.
There could be a space theme and space civilisations. A space theme could have open space for water and solar farms instead of crops. A space civilisation could have robot workers instead of humans.
This could lead to interesting combinations like human farmers tending to solar farms or robot workers tending to crops.
All for now,
Boston
Update 5/10/2027
Since there's no tech tree and instead technologies are unlocked by increasing your technology timeline, there won't be any technologies to research at a blacksmith. Instead, a blacksmith speeds up your military timeline advancement. A mason's workshop would speed up defensive building advancement. A market would speed up economic advancement, and a dock would speed up naval advancement.
A blacksmith could also increase the rate at which units are trained.
I don't know. I'll keep my options open. Tech trees and tech timelines (and RPG skill trees) would essentially be a directed graph, where events notify the system to unlock abilities. This could all be user data stored in a civilisation pack and be totally customisable without having to recompile the game.
All for now,
Boston.
Update 6/10/2026
I figured out how to convert animations from 0AD into sprite sheets and I made a little combat scene:
I've been thinking a lot about a scripting system within the game. I think I'll post it on the other thread.
Update 8/10/2026
I was thinking about shadows. Units have animated shadows that are drawn to the ground plane. If there was a flying unit, the game would project a ray down from the unit to the curved ground plane and draw the shadow there. A ship would be like a flying unit, except it floats on the water's surface. The boat would cast a shadow down onto the seabed. A depth buffer could tell the system how much the shadow is occluded by the translucent water.
A ship could draw the reflection of the underside of its hull to a separate buffer and then a ripple effect could be added to visualise the reflection of the boat on the surface of the water.
Fun times
Boston.
Update 27/10/2026
I've been thinking about the damage system for my RTS game. Soldiers come in groups of 12, and I don't want each soldier to have it's own health bar. Instead each attack has a percentage chance of killing one soldier. A group of 12 archers would launch a cloud of 12 arrows, and have 12 chances to kill a soldier in a group of 12 soldiers.
Each attack would have have a base chance of killing a soldier, but the chance of an attack landing would drop off if the attacker has a low attack rating and the target has a high armor class.
Different units would have different use cases. A slinger would have low armor and low attack rating, but would be cheap to produce. A musketeer would be expensive and have low armor but a high attack rating. Since the slinger has low armor, the musketeer's high attack rating wouldn't come into play. In this case a slinger would be an effective counter to a musketeer. A musketeer's high attack rating would make it proportionately more effective against heavily armored units.
Not all units would come in groups of 12. Cavalry might come in groups of 6 and war elephants would come as individual units. Both the group of 6 cavalry and the war elephant would have 12 lives. A cavalry man would die when the cavalry group loses two lives. An elephant would die when it has zero lives.
One on one duels would be interesting because there is a clear winner and loser. A weaker opponent would have a small chance of killing a stronger unit outright. Larger battles would be more a matter of statistics.
In order to implement this I will need to calculate deterministic percentages for use in my rollback networking model. These will just use fixed point maths. Deterministic fixed point maths should be pretty easy to implement, but right now I'm preparing for an exam.
Buildings would have a fixed amount of lives just like elephants. A musketeer with a high attack rating should not be as effective against a building as a siege weapon with a high attack rating. Units should have a separate base attack and attack rating for each class of building or unit. For example spearmen should be more effective against cavalry, siege weapons should be more effective against buildings.
Ships would each have 12 lives. Winning the ocean should not mean the end of the game. Ships should be effective on water but not against land units. Garrisoned units onboard a ship would be able to attack from the ship. A ship could be equipped with a ram, a boarding party, a cannon, or even Greek fire, but would have a high chance of being damaged.
Towers would provide a defensive bonus to nearby units. A unit nearby a tower might be 10% less likely to be killed. This suggests a whole system of buffs and nerfs. This system would be useful for an RPG game as well, where individual units have special abilities and equipment that modify their effectiveness.
This will all be fun to code up but for the moment I'm focusing on my study.
All for now,
Boston.
Update 28/10/2026
Spaghetti Graveyard is the name of the game engine. The Spaghetti Graveyard RTS will be a game of large numbers of players and large armies. The group of 12 units per entity will allow for 12 times as many individual units in play, and having Sim City workers that are not individually simulated will allow for more soldiers in the field.
The number of players would be large for RTS standards, possibly with 24 players sharing the map. The Spaghetti Graveyard RTS would be a game of teamwork and cooperation, with a coordinated team being stronger than the sum of its players. For example, population would follow a logistic equation, where maximum population growth would occur at half the maximum capacity. One player could max out their population for maximum resource extraction and support a player that optimizes its population growth at half the maximum capacity, and spend that growth rate on replenishing their armies.
With the four different technology timelines (economic, naval, architectural and military), players on a team could specialize in one area while supporting players with different specializations.
Players specialize their civilizations and advance their timelines by building technology buildings. These will be markets, naval academies, masons workshops and armories. Building one of these buildings will provide an instant boost to a timeline and then a cumulative boost over time. A player might spam naval academies to prepare for a naval expansion, but they would have to balance this with the cost of building ships and their garrisons.
Soldiers can be commanded individually but usually they will gather themselves into groups of 12. Groups of 12 will arrange themselves into larger formations. Each attack against a group will have a chance of killing one or more soldiers. Larger units and buildings will be able to lose 12 lives before being destroyed. Elephants will recover their lives over time. Siege engines will be repaired by engineers. Buildings will be repaired by builders. Ships will recover lives if they are near a dock and in an idle state. This will be defined through a system of buffs and nerfs to entities nearby the source of the buff or nerf.
All for now,
Boston
PS 28/10/2026
Players will command large formations of soldiers. A formation could contain a front row of 60 spearmen and two rows containing 120 musketeers. Internally, these will be represented as 15 groups of 12 soldiers, so not a great number units in the simulation. The player will see individual soldiers in a large formation, and will be able to command individual soldiers if they choose.
Players will not be able to wall off the map using regular buildings. There will always be gaps between buildings and even large units will be able to fit through the gaps. Buildings will not even take part in large scale pathfinding. Players will have to build walls to partition the map. One exception to units moving between buildings will be very large siege towers, but they are not expected to move far enough to take part in large scale pathfinding, instead being constructed in-situ.
Ciao,
Boston
Comments
Post a Comment