SOVEREIGN OF SPACE

Battlegroups, Battle Tactics and Combat

Combat is a somewhat complex system that uses two sub systems, Battlegroups and Battle Tactics.

Combat Resolution

Once both sides have played their Battle Tactics the new AP values of Each Battlegroup is totaled. The Battlegroup with the larger AP value is declared the winner, both sides then calculate their losses and the losing fleet has to retreat to the nearest owned system. 

Damage Points

Once combat is over, both players calculate their damage points.  Every ship in a Battlegroup contributes 1 Damage point towards the total, the Battle Tactic played will also contribute some points. Finally, if the player won combat, they will receive two more damage points. 

Once damage points are generated, the players damage points are applied to the opponents battlegroup and vice versa. The player then must "spend" those damage points damaging or destroying their ships. Spending a ships AP value in damage points will destroyer it, where it is removed from the fleet. Spending half a ships AP value rounded up will damage it. Damaged ships cannot take part in battle until the Battlegroup reaches a friendly shipyard system. 

Iteration

Testing was a large part of Sovereign of Space's development, and through testing three problems with the games design arose. 

The first arose early, the initial design had player turns only have one phase, where they could move and build in any order. This caused some confusion among the players and led to some exploits around colonization and building battlegroups. This led to me splitting turns into two phases, each with a clearly defined actions that the player could take and hard triggers on how they move between them.  Also added was a waiting period of one turn before a player could move a newly built fleet. This prevent players from rushing to shipyards in order to build as many colony fleets as they could afford and settle multiple systems in a single turn. With these additions, turns progressed much closer to the intended experience of a steady expansion from the players capital. 

The second problem was that the players fleets became incredibly large incredibly quickly. This had a number of knock-on effects across the board but the largest was that it made combat incredibly cumbersome. More ships meant more variables when it came to calculating AP values, which meant that combat would take a very long time. To address this problem I added an upkeep system, where over a certain number of built ships the player would have one credit deducted from their income for every ship they had active. This change had several effects. The first was that the size of fleets did go down, making combat in future session go a bit faster. The second effect was to the economy, player income was massively slashed, meaning that they could not build up their fleets as fast. Individual ships became more important, as the lower amount of credits a player had meant they could not replace losses as quickly. At the same time, if a player took massive losses very rapidly, they suddenly had a lot more income, meaning that they could still recover.  Finally, the upkeep system gave the player more reason to expand, as taking new territory gave them more ships to work with.  Fleet sizes still bordered on unwieldy in the late game, but the addition of upkeep greatly reduced the problem.

The Third problem was one I should have spotted during the initial concepting phase, and it likely took me so long to address because it was difficult to test an entire game session. That was that players had very little reason to move out of their corner of the map and attack other players. Most conflicts in the earlier testing games amounted to border skirmishes as no player really wanted to take it to the enemy.  The central area of the map provided more benefits if a player could grab a larger chunk of it, but that wasn't enough. Victory in the original concept came when all the other players either forfeited or were eliminated, which would likely have expanded total playtime into the double digits of hours, which is not what I really wanted.  I addressed this problem by adding the Throneworld, a special system at the center of the map. Not only does the Throneworld give a massive amount of income, it also is necessary for victory.  This gave players a clear objective and path to victory. Players could now construct their strategy around getting to and holding the Throneworld. While I did not have too much time to test the addition of the Throneworld before development ended, it did have an immediate positive effect on gameplay.

Gameboard, Pieces and Cards

Postmortem

While I would like to say that the battle system was the most successful aspect of my design, I think the upkeep system had a larger impact on the game. It added more reasons for players to damage rather than destroy their ships, and made expansion more important. It kept fleets small and thus made balance easier without the need for hard caps. It added an extra layer to the games economy without adding an extra layer of complexity like the earlier infrastructure concept I had considered. It was successful because it connected all of the game's other systems together, without being so complex that it was another whole system of the game that players would need to understand like the combat. 

The aspect of my design that was unsuccessful was the damage point system, I had tinkered with it over the course of development, but it never felt right. The intent of the system was that after a battle both sides would take losses that depended on what they did during battle. Damage points were to be another factor that a player had to consider when entering a fight, and allow for things like pyrrhic victories. I wanted combat to cost something, even to the winner. However, problems appeared during the first test that I was unable to solve. The damage points that were generated after a battle were too high, so that even the fleet that won, would be entirely crippled. Later versions had lopsided results due to balance issues with combat and the massive fleets, meaning that the winner could take virtually no casualties while the loser was entirely wiped out. The final version of the system that I turned in solved some of these issues, but no in a way that I really liked. For one, there was no consideration for how well a fleet performed in combat. A fleet could decisively or barely win a battle, but deal the same amount of damage to the enemy. Players were confused by the system, and never really got what they expected from it. This aspect was unsuccessful because It was static, giving the player little control over it. It did not make battles feel decisive when they should have been, meaning combat could slow to a slog as fleets fought again and again, whittling each other down. 

Project Documentation and Links