An essay about gameplay + a game design document for a remake.

Contents

Introduction.

Scope of the Game project.

Game Feel & Gameplay Philosophy.

Game Setting (or lack therof).

Game objectives.

Factions.

The Diplomats.

The Tyrants.

The Hive.

The Machines.

The Meta-Game.

Artificial Intelligence.

Early Game to End Game evolution.

Sub-Games in Detail

1. Territorial Map.

2. Tactical Ship Combat.

I. Ship Design.

II. Technology Research.

III. City Builder.

IV. Planetary Invasion.

V. Diplomacy.

VI. RPG Quest.

What’s left.

Introduction

For more than 20 years, people have been trying, and failing, to remake Master of Orion 2. MoO2, as it is known, is considered a genre masterpiece of 4x Space Strategy. There is a reason developers have been attempting to reconstruct it, and there is a reason they have consistently failed. In some cases the game has been near-faithfully cloned, right down to menu layouts. In others, just a few modern tweaks — realtime strategy, or removing the tactical combat minigame, or making ship customization happen on little fill-in grids, or tweaking the way in which planetary buildings are constructed. None of them have succeeded. A game from 1996 has yet to be recaptured.

This is not a phenomenon entirely unique to Master of Orion 2 — a number of classics have fallen prey to this, notably Jagged Alliance, a game from 1999. Is this some kind of curse of the 1990s? Not remotely. XCOM and XCOM2 managed to be a meaningful reboot of the X-com franchise of the 90s, using similar gameplay elements to create a similar experience. But what was the difference?

It’d be hard to pin down, precisely, how they went about it. But as an end-user, the difference is obvious. The team behind XCOM and XCOM2 managed to create something that replicated the feel of playing the original titles. Not the precise gameplay mechanics, not the menu design, but the feel. This document is the author’s attempt to discuss the feel behind playing Master of Orion 2, the pitfalls behind remaking it. In addition, it outlines a game design.

Traditional game design documents will cover a game in its entirety, almost like an engineering guide to building it. This document is intended to examine various issues to consider in a putative remake of Master of Orion 2 — as well as remakes in general — and provide a very loose, early game design document treatment which could be used as inspiration towards, or an early outline for, a game development project.

The author very much hopes that hobby developers find this document of interest, and encourages them to make use of whatever materials within it they find helpful.

In order to set expectations accordingly, this document was written over the period of about two weeks as a hobby project, and was written primarily to allow the author to get some ideas out of their head and into a written format.

Scope of the Game project

Master of Orion 2 is a simulation of an imaginary galaxy of star systems, which are warred over towards one of several goals: total extermination of all other players, a diplomatic victory in which you are elected leader of the galactic council, and defeat and conquer the villainous Antarans and thus gain control over their ancient technologies.

This is achieved by building various forms of starship to ‘explore’ the galaxy, ‘expand’ by colonizing star systems, build facilities to ‘exploit’ the resources of star systems, and ‘exterminate’ rivals through warfare.

These are the four x’s that have led us to the genre definition of the 4X. Everyone loves 4X. It’s a great way to simplify what is a massively complex set of interlocking game systems into something that a player can wrap their head around.

It has also completely and utterly hamstrung everyone attempting to make these games — most infamously those attempting to make Master of Orion 3, which pridefully boasted it would add a fifth X — Experience. 4X makes for neat marketing copy, and it’s a fun way to define a genre, but as a design principle? Throw it out. Why? The 4x concept unhelpfully simplifies the scope of a game to the basic functions of an algorithm designed to play the game. It ignores, utterly, two of the most significant elements of Master of Orion 2 — the research system, and the ship design system. As a result there are a number of 4Xs that experiment with reducing the research system to a series of tiered unlocks, and ship design (and by extension, ship combat) to the bare minimum.

This also occurs in remakes of Jagged Alliance, and some of the attempts to remake X-Com before 2012’s XCOM. In the first of these games we hire a squad of mercenaries to liberate a country — and remakes focus on the gunplay, completely ignoring the fact that Jagged Alliance was also a role playing game complete with quests, NPCs, dialogue, special character abilities, and experience points. In the second, X-Com, we defend the world from an alien invasion by sending little squads of soldiers out to fight the invading aliens. Remakes focussed on this, ignoring that the tactical fighting in the game was intimately linked to success in the game’s GEOSCAPE — a global campaign overview in which one researched the alien artefacts acquired.

In short, when remaking or cloning a game, if you remake the game by focussing on the surface level elements of the game — the simple things you can point at — you are not likely to make something nearly so fun to play as the original.

So let’s define Master of Orion 2 again, without talking about 4Xs.

Master of Orion 2 is a series of interwoven games, the outcomes of which affect each other in a variety of ways.

(I will use the terms sub-game, mini-game, meta-game and subgame relatively interchangeably. For the purposes of this document a sub-game is a fully functioning game in its own right, a mini-game is a game which is heavily reliant on or supports actions within a sub-game, and a subgame without the hyphen is either a sub-game or mini-game. A meta-game or metagame is a game made up of multiple subgames which influence each other’s play conditions, such as rules, starting positions, components, etcetera.)

The high level meta-game is the simulation of an imaginary galaxy of star systems, in which a player assumes leadership of a nascent empire. They control this empire’s infrastructure and development.

Feeding into the high level metagame are a series of sub-games and mini-games, some of which are quite complete in their own right: Diplomacy, Tactical Ship Combat, City Builder, Territorial Map, Technology Research… there are likely others, like Leader Acquisition, Ship Design, and Planetary Invasion if you choose to cut the game down finely enough. But each of these games were complete in and of themselves.

It may have been slightly anaemic, but one could have simply packaged and sold the Tactical Ship Combat element of MoO2 as a game in its own right. The Territorial Map game is independent enough it’s possible to skip the Tactical Ship Combat battles entirely by having them autoresolve. (In other games this is done with single click, in MoO2 the battle is watched as it progresses and the player can intervene.) Despite each of the component games being simple in and of themselves, the magic happened where these mini-games overlapped.

The City Builder game — designing the facilities in each planet — fed into the Territorial Map game by allowing you to build the Territorial Map game’s game pieces, like colony ships and fleets. The Territorial Map game fed into the Tactical Ship Combat battles by determining the composition of forces and battlefield conditions. The Tactical Ship Combat fed into the Technology Research game by allowing you to capture enemy ships and scrap them to acquire the technology they were built with. This feeds into the Diplomacy game, where you can trade your stolen technology to cement an alliance with another player in order to strengthen an attack in the Territorial Map game against a third party.

Many successful games operate by weaving together smaller games which would otherwise be independent. The Total War series are one obvious example — with a Territorial Map game, a very basic City Builder game, and a very detailed Tactical Battles game.

So the first question in defining the scope of our MoO2 remake must be, what games are being woven together in order to make up the overall meta-game, and how will the rules and play of the sub-games and mini-games affect one another and the meta-game itself?

Personally I really enjoy ship combat, and I found that most of my time playing MoO2 focussed on that area, so I’m going to say that the scope of our remake will be a meta-game simulating a galaxy in which a player assumes leadership of a nascent empire, several aspects of which will exist as sub-games and mini-games. The key sub-games are the Territorial Map and Tactical Ship Combat, while the key mini-games are Ship Design, Technology Research, City Builder, Planetary Invasion, Diplomacy, and RPG Quests.

Of the two key sub-games:

The Territorial Map game consists of a map of a variety of star systems and interstellar geographical features, like nebulae and black holes. It is played by moving tokens representing fleets and special agents from point to point on the map, while features on the map can be captured or created — such as planets orbiting stars, or interstellar starbases. This game is turn-based.

The Tactical Ship Combat game consists of a game map in a grid — with collision detection rules so objects do not overlap — with tokens representing groups of starships or individual starships, starbases, planets, and other geographical features which all have a size and facing. Players take turns taking actions with their tokens — such as moving a ship or firing its weapons. This game is turn-based.

Of the key mini-games:

The Ship Design game consists of a series of menus and simulated blueprints for designing starships for use as components in fleet tokens for the Territorial Map game, and for use as tokens within the Tactical Ship Combat game. It involves selecting components for starships, and balancing those components’ needs against a variety of resources, such as available space within a starship, its power supply, need for logistic resources (such as command points generated by star bases), as well as factors like structural integrity and speed in the key sub-games.

The Technology Research game consists of a series of menus for selecting the research priorities for the player empire’s scientific research groups, which unlock or alter elements like star ship components or city buildings. Factors in playing the Technology Research game include resources provided from other games, but also a series of interlocking dependencies and mutually exclusive choices. One can either develop a technology for cybernetically augmenting their empire’s species, or a technology for genetically inducing psionic abilities, but not both, as an example.

The City Builder game consists of a series of menus for developing infrastructure on planets found within the Territorial Map game, which will generate and consume a variety of resources used across all other games, including research capacity and materials. In addition the planets in the City Builder game will be used to build tokens for use in the other games, such as starships, spies, etcetera. Citizen morale will play an element in this game, and it will be possible for a planet that has been mismanaged in this game to ‘revolt’ and thus leave the player’s control in the Territorial Map game.

The Planetary Invasion game consists of a map of a planet with a simple interface for selecting battle strategies and what troops to deploy. This game will be played when a fleet has control of a planet, having destroyed all orbital defences in the Tactical Ship Combat game. It will include options for space-to-ground bombardment. This game has as its main outcome control of a given planet in the Territorial Map game, but resources and technologies can be looted from planets in this game.

The Diplomacy game consists of a series of menus with which to trade with other entities int he game world, primarily other empires. It allows a player to attempt to barter resources with other entities, control their behaviour through various treaties — such as non-aggression pacts — and utilize espionage in the form of spies to achieve a variety of outcomes affecting other game types, such as sabotaging other empires’ starships or fomenting revolts on their planets. A player’s behaviour in other games will affect the Diplomacy game — for example, some entities will not cooperate with a player who uses biological weaponry.

The RPG Quest game consists of menus presented at various times and in response to various conditions in other games in order to simulate unusual encounters. The player will make a choice from several in response to a situation, which will then resolve based on varying criteria. For example, a player might move a fleet to a new star system, and an RPG Quest menu might appear saying that the fleet has encountered an abandoned star base. The player might be given the option to ignore the star base, or to explore it. Exploring the star base will randomly either provide a reward — a cache of valuable game resources — or a penalty — one of the player’s starships is destroyed by the station’s defence systems. This system will also include Archaeological Research, which will allow a player to trigger the system with fleets or buildings containing Archaeological Research modules.

So that’s the scope of our game project. And somewhere, with all those elements weaving together, we might find some magic happening. But the scope of a game says nothing about the feel, and more importantly, about the way the player experiences these various sub-games and spends time with them.

Game Feel & Gameplay Philosophy

Developers have been remaking soccer games for decades. FIFA 19 is a different beast to FIFA Soccer 96, but somehow in 2019 people can remake soccer games from 1996 while they can’t remake complex strategy games.

The reason is feel.

Replicating the feel of a soccer game, or a first person shooter, requires a focus on only one game — moving a character through an environment. Some first person shooters become slightly more like RPGs by integrating an inventory system — the inventory system itself can be argued to be a separate game, and by playing it, you select and change the characteristics of the main game because the character you control now has different attributes. They move faster, they fire a different gun. Fundamentally, however, these sorts of genres rely on a single primary game, with any subgames being as minimal as possible. Replicating the feel of something like Master of Orion 2, with its multiple interlocking subgames, requires replicating not only those subgames, but the feel of how they interact.

If you remake MoO2 but foul up one of the subgames — a problem with Tactical Ship Combat, say — you significantly alter the feel of all of the other subgames. Technology Research options become differently weighted. If the difference between researching laser cannons and missiles is now ultimately an arbitrary choice, Technology Research as a whole becomes less consequential, and therefore less compelling, as a subgame. In the example of Jagged Alliance remakes, eliminating the RPG plotline might mean that the need to liberate a city or town with your team of mercenaries is far less compelling, and that means that the goals of tactical combat are less compelling.

The feel of any game reliant on an overall meta-game derived from subgames must, therefore, deeply consider the nature and interactions between those subgames.

As an example, let’s examine the City Builder segment of MoO2 briefly. It is very simplified, primarily asking the player what structures to build in what order, and what fraction of the available workforce to commit to agriculture to feed the colonists, to manufacturing buildings and starships at the colony, and to contributing to the empire’s research efforts.

Very few choices are available at the start, mostly determined by the player’s research choices, and as the game progresses more and more options will emerge. Planets can typically build a single example of every structure available — the only difference between planets a colony might be on are bonuses and maluses applied to production statistics and the number of colonists that can populate the colony. At the beginning of the game, with only a few colonies, each choice in the City Builder is significant, but not terribly time consuming. Selections are made in a queue, and the player can shift back to the Territorial Map or other subgames relatively quickly.

But a problem emerges towards the mid or end-game. Large numbers of colonies sinks the player into a repetitive grind to deal with them. While it’s possible to have automation take care of colonies for a player, that automation is essentially finding a way to avoid making the player engage with the City Builder subgame instead of playing it. This isn’t simply a shame, it’s tacit recognition that something has gone wrong.

In MoO2, automating the City Builder in colonies is generally done when the game moves towards the overall end-game of MoO2, and the significance of what is built at an individual colony becomes a non-issue. Thankfully, in MoO2 this means that it’s perfectly acceptable to leave automation running and as it will eventually build every available building, it is impossible for automation to build a colony ‘wrong’ for a player.

Some remakes have attempted to sidestep the same problem by making the City Builder segment more complicated, perhaps hoping to make it more interesting for players to interact with in the end game.

The game Star Ruler 1 — not a direct remake of MoO2 but certainly borrowing many genre elements — chose to limit each colony to a certain number of build slots, and multiple buildings of the same type could be stacked onto any given colony. This created the problematic situation where automatic build orders might be far from optimal, or a given colony’s resource requirements might not match what the automatic build order provides, causing the player’s economy to stall. This made Star Ruler 1’s early game more difficult than the late game, when having multiple colonies meant that the failures of one colony were propped up by several others, allowing the player to once again largely ignore that game’s City Builder component.

Other schemes for complexifying the City Builder component have brought up problems of their own. Instead of playing a very simple City Builder once every half hour or so in MoO2, a remake might demand a player engage with a complex City Builder repeatedly. It may be interesting to have a very complex City Builder segment of the game, with individual placement of homes for colonists, but when there are fifty colonies demanding a player’s attention, making them click ten times at fifty colonies to build their colonists’ homes is at best needless grinding, at worst utterly wasting your player’s time.

As such, it’s important to keep in mind how much time it’s intended a player needs to spend with each of the subgames involved. MoO2 solved the question by using a simple City Builder which was nonetheless consequential in the early game, and safe to automate or ignore in the late game, keeping the amount of time a player absolutely needs to spend with the City Builder relatively consistent throughout.

Another solution might be to put a cap on the amount of time a player will spend with the City Builder by limiting the number of colonies that the player will play the City Builder for, using the subgame only for a few capital worlds while other smaller settlements are entirely automated. In short, rather than asking a player to play thirty simple City Builder games simultaneously for about a fifth of their play time, ask them to play a single high quality City Builder for about a fifth of their play time.

MoO2 makes other choices to keep this balance between subgames relatively steady. There’s a chance that marauding space creatures such as space amoebas or dragons will be found in star systems the player has explored in the early game. This way the player doesn’t need to wait for a war with a neighbouring empire to ensure they’re playing the combat portion of the game as well as the Territorial Map portion. Remakes that ignore this, putting a player in a situation where they won’t encounter any ship combat in the early game because they have yet to reach neighbouring empires and wars with them, lose this balance between subgames, and as such, lose the feel of MoO2. This is a very good reason for remakes to include marauding pirate factions to attack the player in the early game.

Balance of time spent with the various subgames isn’t the only major factor. The other which will be examined is the impact of the subgames on one another.

If two subgames — the Territorial Map game and the Tactical Ship Combat game — fail to interact meaningfully, the balance of significance between them alters, and the game’s feel is altered or lost.

In MoO2, a battle in space will frequently be between two fleets above a planet belonging to the defender. If the defender loses, the planet will be bombarded, potentially destroying buildings in the planet’s colony or the entire colony as a whole, or the planet will be invaded, allowing the attacker to take control of the colony. While other encounters are possible, this most common type of battle encounter holds immediate and significant consequences for playing the Territorial Map game. A planet is won or lost.

If a remake chooses to make battles between fleets in deep space a common type of encounter, the significance is lost. While a battle in deep space may have long reaching consequences — leaving planets defended or undefended, preventing a possible invasion — the immediate consequences instantly vanish. The state of play on the Territorial Map changes very little, and while a future problem might be averted, dealing with future problems has a very different game feel to dealing with immediate problems like an imminent bombardment.

As the scope of our game project has an intended focus on the Tactical Ship Combat game, it is important to make sure that it links well with the Territorial Map game.

This will be achieved by ensuring that opportunities for combat are frequent, although not overwhelmingly so, that the amount of time required to play through a combat encounter will be reasonably significant without wasting a player’s time, and that as many encounters as possible will have outcomes which are significant to play on the Territorial Map.

These will include:

Ships travel directly to points of interest on the territorial map with their warp drives, so almost every encounter will determine control of a point of interest such as a planet or starbase. Deep space interceptions will not be possible.

Non-empire factions, such as pirates or space-amoebas, will periodically attack the player and provide a variety of on-going threats to deal with.

The winner of a battle can optionally retrieve the life-pods and debris ejected from the opponent’s destroyed ships. These will provide resources for the Territorial Map and other opportunities for the RPG Quest and Diplomacy subgames. This will (hopefully) increase the incentive to defend a planet against repeated attacks.

It will be assumed that occasionally extremely lopsided combats are inevitable, as players may have extremely mismatched forces fighting against each other, and to mitigate against these unsatisfying match-ups an option to autoresolve will be provided.

When it comes to linking the Territorial Map game to the Tactical Ship Combat game, the Territorial Map game (and its directly linked subgames, like Ship Design), it is important that moves made on the Territorial Map directly affect the combat encounters. Methods to ensure this will include:

Ensuring different points of interest provide different space terrain features, such as nebulas that alter the function of ship components like shields, or asteroids which might block attacks or cause damage when ships are improperly piloted.

Fleet composition will be heavily influenced by Territorial Map choices, such as what buildings are built in the City Builder portion, including a logistics system which will alter the effective size of fleet available for combat in various situations, or a fleet’s capabilities — a well supplied fleet will be able to launch more missile salvos than a fleet raiding into enemy territory.

Options available in the Ship Design element of the game will be influenced by territorial map choices. Being able to use ultra-pure crystals acquired at one point of interest will allow the installation of enhanced beam weapons — losing the point of interest containing the crystals will inflict a penalty on fleets, such as increased logistics costs.

With some luck, these choices and intents will skew the overall game’s feel in the directions we want. We’ll go into more detail about some of these aspects when talking about the subgames in depth.

Game Setting (or lack therof)

Master of Orion 2’s setting is a curious beast. It’s both very specific, and loosely defined enough it’s quite possible to impose your own fantasy of what’s really going on down on the ground. This is one of the reasons for the game enduring so long — the setting was even lifted wholesale and used by a novelist in Russia with the names of species unchanged. It’s entirely possible to tell yourself your own story by playing the game, something very much supported by MoO2 giving the player the option to make up their own empire’s species traits, picking from a list in an RPG-esque way, picking advantages and disadvantages. You could potentially make a subterranean insectoid cybernetic species with a hive mind, if you put your mind to it.

A player being able to make anything in a game theirs — truly belong to them — is an incredibly powerful mechanic, and one that’s been a significant part of the appeal behind Stellaris, which has such an in-depth empire/species creation system that some people effectively play that as a game all on its own.

So how much of a setting do we really need? Some similar games and remakes have pushed very hard towards creating a cohesive setting with a plot and interlocking quest lines. This tends to reduce the ability of a player to make parts of the game truly belong to them, but opens up concepts like lengthy RPG questlines and plots to help drive the game forward alongside the strategic experience.

MoO2 kept its setting simple, and entirely related to the game’s mechanics. There is an ancient homeworld of the Orions, at Orion, and the Orions were at war with the evil Antarans. In MoO2 you can find Orion, defeat its ancient guardian, and claim the powerful planet and a few remaining pieces of Orion technology. You can also build a star portal and attack the Antarans to attempt a win condition — in addition, the Antarans will appear from hyperspace to attack a particularly powerful player at random intervals.

The strong implication is that a good MoO2 remake needs to thread a needle — provide a setting that offers up a strong justification for a variety of game mechanics, without eradicating a player’s ability to make up their own alien empire, and discover the story of their empire’s rise and fall. This means there need to be gaps for players to make their own custom empires in.

So, in our game project, an ancient empire known as the Precursors created a massive structure at the centre of the galaxy — the Hyperwarp Dissolutor — which was built to cut off access from warp-space FTL travel for all non-Precursor species. But the machine is imperfect. Every few millennia, some working in the ancient device falters, and for a span of generations warp travel becomes possible, only for the device to reactivate and trap explorers and freeze burgeoning interstellar empires in their tracks. As the game begins, the Hyperwarp Dissolutor has begun to malfunction once more. Strange phenomena are occurring across the galaxy as it winds to a halt, leading to a race for species — both newly evolved and those fallen remnants of ancient peoples — to understand the possibilities of warp-space FTL technologies and put them into play.

The galaxy is dotted with ruins from empires that rose up, only to fall when warp-space was once again closed off. Some of these may provide opportunities to discover ancient and mysterious technologies, others may threaten the player’s growing empire, whether in the form of marauding pirates making use of patched together and ancient battlecruisers or long-dormant plagues.

As the game progresses, it becomes clear that if an empire could travel into the centre of the galaxy and lay claim to the Hyperwarp Dissolutor, they could control all FTL travel within the galaxy. They could thus become the ultimate power, able to cut their enemies off from FTL travel, or destroy the Hyperwarp Dissolutor, and be forever remembered in galactic history as the ones to free the galaxy forever.

There will be a variety of random elements to this setting, which must be discovered through archaeological research at various sites in the galaxy. The key random element will be the reason the Precursors built the Hyperwarp Dissolutor — either, as is widely thought, the Precursors were tyrants who sought to control the galaxy, or alternately the Precursors built the Hyperwarp Dissolutor to alter the galaxy’s physics to allow FTL travel — when FTL travel is cut off, it is because the Hyperwarp Dissolutor is failing and in order to make sure it endures, the Dissolutor must be repaired before it fails forever. These two scenarios are known as Tyrant Precursors and Benevolent Precursors.

Game objectives

In our game project, as in Master of Orion 2, there will be three ways to win the game.

The first is to destroy all competing Empire’s colonies.

The second is to unify the galaxy politically, by contacting all competing Empires, entering into a treaty with at least one other empire to build a diplomatic Megastation together and to successfully sign a treaty to pledge all empires to cease hostilities and work together to destroy the Hyperwarp Dissolutor before it cuts the galaxy off from FTL travel.

The third is to reach the galactic core and first military control of the Hyperwarp Dissolutor with a fleet, then by using archaeological research to unlock its secrets, either become a hero or galactic tyrant by destroying or taking control of the Hyperwarp Dissolutor.

Our setting lets us complexify this, however.

In the Tyrant Precursors scenario, everything occurs as above.

In the Benevolent Precursors scenario, if at some point the truth is discovered, the political victory will instead involve convincing other empires to come together to build a new Hyperwarp Dissolutor — this will flip the requirements of the diplomatic victory. Wheras in the Tyrant Precursors scenario it is easy to build the diplomatic megastation and difficult to successfully sign a treaty, in the Benevolent Precursors scenario it will be difficult to build a new Hyperwarp Dissolutor, but relatively easy to convince other empires of the truth — however some empires will refuse to believe the truth and go to war with the allied empires attempting to build the new Dissolutor. In the Benevolent Precursor scenario, the military control victory will involve making the choice to either repair the Dissolutor and take control of it forever, and become a tyrant, which will be difficult, or to transmit detailed scans of the Dissolutor across the galaxy, allowing all races to build a Dissolutor of their own, which will be easier.

If the truth is never discovered, there will be an alternate ‘bad’ game ending in which the Dissolutor is destroyed, either by a heroic empire or by a political coalition, dooming the galaxy.

In either scenario, there is a maximum game length imposed by the amount of time remaining before the Dissolutor, for either reason, locks the galaxy off from FTL travel.

The maximum game length can be extended by an empire researching a megatechnology — Thin-Warp FTL — which allows FTL travel for an additional number of turns (30?) each time it is researched, with research requirements increasing at each use.

After the game is won or lost, the game score will no longer be computed, but it can continue to be played indefinitely in the ‘you already won, but you can keep going’ way popular in other empire-building games.

If the game is won with a ‘good’ ending — by successfully resolving the Dissolutor crisis — FTL travel will continue. If the player-empire took military control of the Dissolutor they can switch on/off FTL travel for other empires at will.

If the game is lost, or won with the ‘bad’ ending — by inadvertently dooming the galaxy — no FTL travel is possible, but the game can continue, with all travel times occurring at the speed of light. Movements will take 100s of turns — ships that are not purpose built to survive the journey time will run out of supplies and stop working before arrival. Interstellar stargates for instant teleportation from point to point will continue to work, and can still be built, but will periodically and randomly break down and must be repaired/replaced — thus simulating the difficulty of maintaining an empire without FTL.

Factions

MoO2’s faction design is a mix of personality and practicality. The AI is given goals roughly in line with a faction’s capabilities, so the Psilon — a race of dedicated researchers — will tend to sit on their own and become a technological paragon almost impossible to topple. The Sakkra — a quick-growing Reptillian race — will spread across the map creating colony after colony. This personality is another major area where the feel of Master of Orion 2 is difficult to replicate.

By having those personalities work with the game mechanics, each empire the player encounters becomes that more tangibly an element in the story they’re building in their head as they play — and because they have a specific way of behaving, it opens up strategic possibilities as well. The Psilon are a good place to go looking for technology — either by trade or spycraft. If you’re close to the Sakkra in the early game, an early attack may save you a lot of trouble later when they’ve populated half the map.

Working to make these faction personalities become part of the game’s mechanics, rather than merely a bit of backstory, is another place where the feel of a game starts to emerge.

Making all factions fundamentally interchangeable, other than a few stat bonuses here and there, may seem like a logical thing to do to enable the game to be balanced for multiplayer, but it’s a mistake. Starcraft is a landmark real time strategy game not because it’s balanced for multiplayer, but because all of its factions are mechanically distinct from one another.

Game balance is something that happens by setting up the game, playing the game repeatedly, and tweaking things. Rock-Paper-Scissors style situations where everything has a counter help, too. Game balance isn’t starting off on a generic and level playing field and attempting to make changes while keeping a zero-sum equilibrium.

As such, our game project will have multiple factions, and (ideally after testing) provide the player the opportunity to custom-build a faction using an RPG style points system.

Our project will also need an artificial intelligence to play the other empires — and this will ideally be used to assist in refining game balance, by having the game play itself against itself repeatedly to help with working out areas to tweak for balance.

We will start with four factions which are mechanically distinct, and perhaps include others in later revisions of the design.

The Diplomats

The diplomats are essentially humans. Their primary mechanic will be diplomacy, which will give them access to more complex forms of treaty, and internal democracy, which will allow them to access various empire-wide bonuses and policies if they can manage their empire’s popular opinions on three main factors.

The first is belligerence — a factor which is increased when at war or when the empire is threatened by being close to disgusting aliens, and decreased when at peace or when there are a multitude of active treaties with other empires. When belligerence is high, there are bonuses to weapons research and to build factors for military units. When belligerence is low, there are bonuses to infrastructure research and build factors for infrastructure buildings.

The second is a scale which moves between arts and sciences. When the empire is high in arts, the other factors are more easily manipulated with media buildings set to produce propaganda. When the empire is high in sciences, the empire is harder to manipulate, but gains a research bonus.

The third is a scale that moves between individualism and collectivism. When the empire is high in individualism, it becomes harder to manipulate the empire and to change the population’s mix of expertise (scientists don’t want to retrain to become farmers). When the empire is high in collectivism, it’s easier to manipulate the empire and to change the population’s mix of expertise.

Some policies will lock or unlock depending on the mix of these factors. As examples, a high collectivism and high belligerence empire can enact a military draft, increasing recruitment speed. A high individualist and high science empire can enact a science programme, increasing research speed. A high arts, low belligerence, high individualism empire, can enact a morale-boosting policy which increases most statistic, and boosts population growth and immigration from other empires. A high arts, low belligerence, collectivist empire can enact a morale-boosting policy which increases most statistics, and speeds up building a specific class of infrastructure.

The overall intent is that the Diplomats can slowly adapt and shape their empire to specialize as they wish, but must cope with outside events that may disrupt their plans. (Another empire sending a belligerent empire unasked for aid during a disaster will lower their belligerence. A high arts empire becomes open to alien propaganda. An individualist empire’s morale falls due to building too little infrastructure, causing a collectivist revolution to build enough hospitals for the population. Etc.) The Diplomats cannot easily specialize specific colonies towards specific tasks — overall, they have to decide the specialization of their entire empire. (Difficult to build a single research world and a single military production world, easier to build a lot of research worlds, or a lot of production worlds.)

The Tyrants

The Tyrants are a rigidly controlled society, with a distinct top-down hierarchy in the manner of a dictatorship. Their primary mechanic is delegation, in which a selection of randomly generated characters (Advisors) may be assigned to any one of a number of command slots in their society to provide simple, straight-forward boosts and gains to stats like research or build speed. Advisors may be placed in any command slot — there’s no mechanical separation. The man who was your Research Advisor may become a colony governor in the next turn. Each of these characters have a loyalty to the leader, and various events will raise or lower their loyalty. If one of these characters has their loyalty drop far enough, they will rebel with a portion of the empire they controlled on behalf of the leader. Each Advisor has a relationship with one another and with the leader. If one Advisor with a high relationship with other Advisors is replaced, it may cause multiple Advisors to lose loyalty to the leader.

If an Advisor successfully leads a coup, they will become the new leader.

The primary slot is Leader, and this will be initially filled by an Advisor chosen by the player. The Leader has no role, but provides their bonuses to the entire empire. These bonuses increase as time passes, so replacing the Leader with another advisor will always weaken the empire temporarily. Each time the Leader is replaced, some Advisors will become more loyal, and others will lose loyalty.

Three command slots (more will be added) are as follows:

Each colony must be assigned an Advisor as governor, but by default will be given a generic ‘Lackey’ advisor who starts with unexceptional abilities and perfect loyalty to the Leader. (This ‘Lackey’ can develop and eventually rebel.) If the governor rebels, all military assets will randomly either join the rebellion or remain loyal, with chances altered by how charismatic the Advisor is, empire-wide bonuses, etcetera. If the rebellion manages to attack and take over the capital, they will win a coup and the Advisor will become the new Leader.

The Empire must be assigned a Research Advisor, but by default will be given a generic ‘Lackey’ advisor. The Research Advisor has an opinion on what the next technological research project should be — if the leader selects something else, the advisor will lose a small amount of loyalty. If the leader selects the one they wanted, they’ll gain a moderate amount of loyalty. If the Research Advisor rebels, a random event will be initiated in which either a number of prototype military units will appear at the capital colony and attempt to capture it in an immediate coup, or the advisor will attempt to flee to another empire with several of your confidential technologies and there will be a chance to pursue them.

The Empire must be assigned a Spymaster, but by default will be given a generic ‘Lackey’ advisor. The Spymaster organizes both internal and external espionage, and may be ordered to assassinate any Advisor character, trigger events to alter Advisor loyalty, or discover Advisor secret traits, motivations, and relationships. If the Spymaster rebels, a random event will be initiated in which either the Leader is instantly assassinated and replaced by the Spymaster, or the Spymaster and a random selection of Advisors will begin a rebellion at a colony.

Random events, such as old age, disease and disasters may kill any Advisor, including the Leader.

The intent is that while the Tyrants are largely free to pursue their own goals without much outside interference, and they may specialize as they choose, they are both more vulnerable to espionage and more able to specialize in it. The Tyrants are more flexible, as it is easier for the Tyrants to specialize individual colonies in different ways with their governors.

The Hive

The Hive are an insectile single hive-mind society, with a shared but distributed consciousness. Their primary mechanic is evolution, in which special research projects allow them to alter the nature of their overall society. These projects will provide various mutually exclusive choices leading to various bonuses, and altering a choice once it is made is impossible.

Examples of early-game choices are:

Parasitic — allows the Hive to convert other empires’ populations to join the Hive, by infecting them and using them to nurture eggs. This choice is repulsive to all other empires and makes conventional diplomacy impossible, but provides bonuses to planetary invasion. Mutually exclusive with Mutualism.

Mutualism — allows the Hive to have other empires’ populations immigrate as normal. This choice allows conventional diplomacy, and increases vulnerability to espionage, but colonial population that emigrates to another empire’s colonies provide line of sight at those colonies and are the only way for the Hive to acquire currency resources — which the Hive does not otherwise use — which can be used to buy things from other empires, such as ships, troops, population, trade deals, etc.

Examples of late-game choices are:

Shapeshifting — Allows the hive extraordinary espionage abilities, bonuses to ground combat and construction (as they can reshape limbs as necessary). Hive immigrants on other empire’s planets provide a bonus to relations (as they are able to reshape to look beautiful and appealing). Mutually exclusive with CyberCarapace

CyberCarapace — Alters the Hive’s relationship with their starships. Once they were tools, now they are extensions of the Hive’s bodies — bonuses to ship combat, and ship repair.

The overall intent is that as the Hive develops, the ways in which it plays the game become increasingly specialized, and it cannot go back. This means that while the Hive is able to access powerfully synergistic technologies and bonuses, they will be really vulnerable to counter-strategies, leaving their main response as attempting to brute force past it. A Parasitic, CyberCarapaced Hive will be militarily powerful — but if countered with a strong enough military defence, they will have no ability to diplomatically de-escalate the situation or use espionage. Their only option will be to build more ships. A mutualistic, shapeshifting hive will be able to spy on other players very effectively and be diplomatic, but will be unable to cope militarily, making their only option more espionage and more diplomacy.

The Machines

The Machines are a society governed by algorithms and artificial intelligences. Their primary mechanics are emergence, in which they alter the operating systems and computers of other empires in order to take over and absorb various aspects of other empires including technologies, and convergence, representing a unified and uncorrupted codebase across the entire Machine empire.

The Machines begin as an organic empire, which created them, fades and are replaced by the inorganic Machines. Machines will be able to do without life-supporting planets entirely, instead relying on barren moons, asteroids, starbases and similar points of interest, with industrial-focussed gameplay.

Machines will have extra espionage options, which will allow them to subvert and take over any produced starships, fleets or stations through emergence, injecting semi-sentient code hacks that will eventually take over the machinery, with good odds of success so long as the Machines have more powerful computing technologies. It will be possible for opposing empires to rely less on automated systems when creating their fleets, or to invest in anti-subterfuge technologies.

Balancing their powerful emergence abilities, the Machines are limited by convergence — the more they absorb from other empires, the more forms of corruption may enter their codebase. (This will be enhanced against organic empires with cybernetic implants — which therefore have more control over their systems, and can cause more corruption.) Convergence will gradually increase as newly integrated ships/fleets/stations integrate into the rest of the empire, but if convergence falls too low, the Machines will begin to fracture, with portions of their empire effectively rebelling — however the Machines can halt these rebellions by using emergence espionage options relatively easily.

The Machines have specialized technology bonuses towards working in space without planets, and significant maluses against exploiting the resources on planets with biospheres — and therefore, weather. The Machines do not have access to social and biological technologies, and therefore will be severely limited in terms of trade and commerce, diplomacy, dealing with pollution, etcetera. They will be unable to benefit from internal morale bonuses, as organic empires do.

The intent is that The Machines provide a significantly altered gameplay experience, by utilizing resources and locations which are ordinarily of little interest to the other empires, such as barren moons. Due to a heavy focus on espionage, stealth technologies — allowing secret starbases/moon outposts — may be especially useful to the Machines, however their strong industrial abilities give them many other options. While they have specialized technology bonuses in some areas, they are incapable of acquiring valuable social and biological technologies and resources without using their espionage options against organic empires. As such, the Machines will naturally be balanced towards being belligerent with organic empires, which they need to exploit to make full use of their abilities, and their powerful technologies makes them tempting targets for organic empires seeking to get an edge.

The Meta-Game

Earlier it was discussed that Master of Orion 2 has a metagame, which is composed of multiple sub-games, but it’s worth taking another look at why the interplay of subgames specifically results in the unique experience of playing Master of Orion 2.

More formally speaking, a metagame is a game played in order to play, or alter the rules or outcomes of, other games. If you decide to play a hand of poker to determine who goes first in a game of chess, that hand of poker has become a metagame for chess. By using an outside game, the rules of chess have been altered. This example, however, is not terribly interesting. There’s a simple one way relationship, and the metagame — the hand of poker — is never relevant again.

In Master of Orion 2, every subgame interacts with every other subgame in some fashion. As a result, all of these games together build a series of interlocking formal metagames. The highest metagame — arguably the core of it — is the Territorial Map game, in which the galaxy the game takes place in is simulated. Each move made in the Territorial Map game determines the rules and contexts in which all other subgames are played. The Territorial Map game determines how many planets may be colonized, which determines how many research points will become available for research. It determines where mineral-rich planets may be found, which determines what may be built in the City Builder game. And yet, each of these subgames determines the outcomes available to a player in the Territorial Map game.

It would be highly instructive to build a flow chart mapping out the various relationships between all of these game elements, how each relates to the other, but there are simply so many moving pieces involved in Master of Orion 2 that flow chart may well wind up a network where every subgame is linked to every other subgame in some fashion.

When it comes to ensuring that there’s a similar interplay between all pieces of the game in our game project, it would be helpful to begin with a much simpler exploration of subgame interaction.

Each object in the game, whether it’s a building built at a starbase, a starship module, or a unit of an empire’s population, should in some way interact with technology unlocks from the Technology Research game. There should, also, be a way to meaningfully either make use of, or acquire, these technologies in every other subgame.

Doing this achieves two tasks — firstly it links every portion of the game together by at least one axis — Technology Research. Secondly, it provides at least one obvious ‘direction’ to play the game for every player: acquire more technology.

In the Territorial Map game, technologies will alter factors such as vision distance, travel distance, travel time, and available options — such as colonizing planets or building starbases.

In Tactical Ship Combat, and in Ship Design, technologies will alter every single ship module, and therefore all considerations around every ship design. Likewise, in the City Builder, technologies will alter all available buildings. In Diplomacy technologies will significantly change the espionage options available, and RPG quests will be affected by new options becoming available to deal with various channels as technologies are researched.

Technologies can be acquired in Tactical Ship Combat — by capturing or raiding ships, in Planetary Invasion by capturing buildings on planets and other points of interest, in Diplomacy through trade or through the use of espionage options, and in the RPG Quests through rewards for various options.

This relatively simple task would, then, need to be repeated for each and every subgame. So, for instance, the RPG Quests become available through actions on the territorial map, provide opportunities to use specialized ship designs in scripted Tactical Ship Combat encounters, etcetera. Some of this will be brought up in a later section.

Fundamentally, the need for every subgame to interact with every other subgame means that any time a subgame is added or removed from the design of a MoO2 remake, it must be made to relate to every other subgame. Diplomacy is one of the most difficult aspects of this genre to integrate this way — and typically it is used purely as a means to trade with other empires. This is where the game’s feel is lost, by making one of the subgames an optional branch of gameplay which can ultimately be ignored.

While it may not be desirable to obligate the player to deeply engage with each subgame, it is none the less essential to be sure that a player knows that there are mechanics within that subgame relevant to the overall metagame.

It is possible — perhaps not advisable — to play Master of Orion 2 without ever utilizing the City Builder colony management screens beyond setting them to automate, and perhaps to add a few starships to the queue. However, a player choosing to do this is intimately aware that the City Builder exists, that the buildings available are a vital part of the game, and that their actions elsewhere will impact this subgame even if they do not directly play it. While the city builder may be optional, it is no mere branch, but rather a part of the foundations which can safely be hidden if the player chooses to do so.

Artificial Intelligence

Artificial intelligence and a game’s design need to work relatively harmoniously. In some games it doesn’t matter terribly much whether an AI opponent behaves like a human or has a personality — algorithmic play is all that is required. Algorithmic play ideally requires that the game’s underlying structure and balance suit themselves to one of several ideal states, allowing an artificial intelligence algorithm to attempt to ‘solve’ the game and determine what the perfect play is at each and every step of the game. This may be achieved with a massive database of previously played games to compare the board to, neural networks and machine learning, or mathematical algorithms.

This is a very, very large undertaking for Go — in which a nineteen by nineteen gridded board may have a black or white stone placed at each point on the grid. In order to do so successfully full research teams have been assembled to develop techniques in machine learning.

For a computer game, this is overkill. For a computer game in which several hundred star systems might be battled over with fully customizable starships in just one of multiple subgames, with rules of play that can alter the dynamics significantly…

This brings us to scripted artificial intelligence techniques. It’s my understanding that Master of Orion 2 used these. This is similar to having a database of previously played games to examine.

In essence, with these techniques a script for play is developed, and the AI players follow the script. The script will alter depending on various game states. For example, if your empire strength is computed to be lower than the AI player’s, the AI player will attack to steal your colonies. If it is computed to be higher than the AI player’s, the AI will seek peace. This sort of ‘script’ can act in a way that’s reasonably intelligent — assuming you’ve developed a way for the AI player to move their ships and colonize planets — but it tends to lack a clear memory of recent events. There may be a background hidden score for how friendly they feel, which drops with each planet you blow up, but it’s rare that AI players in games like these will — for instance — remember that every time you negotiate a Non Aggression Pact with them, you exploit the fact that the AI reduces its border patrols to launch a surprise attack, and therefore the AI changes its behaviour and keeps their border patrols intact even after a Non Aggression Pact has been established.

In order to make up for these sorts of drawbacks in the kinds of behaviour it’s feasible to write an AI script for, on more difficult levels of many games the AI gets artificial boosts — their ships are automatically stronger, their industries more efficient. Making the AI more intelligent and reactive is far rarer, although sometimes the AI is given a more challenging and aggressive script to control their behaviour.

There are, naturally, many other ways to define AI in games and these are just two very different examples of how AI can be developed to play games.

In Master of Orion 2’s case, this use of scripted AI systems — which seems to combine with tweaks for each empire to help provide their personality — was used to provide not only the challenge in the single player mode, but also to help make the galaxy inhabited by the player empire seem alive. At every step you know that other empires are playing the game in their own way, potentially having wars you might never see for yourself until you discover a captured homeworld populated by Psilons underneath the banner of a Meklar warlord.

Scripted artificial intelligence, where each empire type is given its own build order lists and selections of predesigned ships to use, predetermined decisions to take given criteria the game tracks like relative empire strengths, and perhaps some vague element of memory — such as whether or not a player has previously breached treaty agreements — would therefore seem to be a useful starting point.

It may also prove helpful to consider artificial intelligence for playing our game project as a modular ‘add-on’, working from the point of view of each individual subgame, where an AI player routine can be developed to handle each one individually, while taking directives from a scripted overall ‘metaplayer’ that determines overall strategy and personality for playstyle. This would have the added advantage of allowing players to automate the play of given subgames, if they so choose.

If we can set up our project to run games with no human player at all, merely tracking various facets of play and providing us with some form of telemetry, it may become possible to develop and tweak whatever AI players used for our project based on that telemetry. Being able to watch a recording of the game being played, and being able to pause it at any time to inspect the state of the game and what part of its scripts the AI player is making use of, we will have a powerful tool to help us develop and tweak the controlling scripts.

Regardless, the goal should not be to emulate a human player. The goal should be to emulate the behaviour a player expects from an opposing empire given the information available to the player. If a Hive empire has developed in a benevolent way, with mutualism, it would be strange to observe that empire running rampant across the galaxy militarily. Likewise, it would be strange to see a Tyrant empire with no particular interest in using espionage, or a Diplomat empire that has a high belligerence score staying at war if events reduce their belligerence. The goal needs to be to remain internally consistent with what is presented. If more difficulty is required, the AI players can either be made more aggressive, given more resources, or otherwise boosted. Alternately, the player empire can become more constricted by their faction’s drawbacks as difficulty increases — Diplomats become less able to control the direction of their empire, Tyrant advisors become more likely to rebel, the Hive’s specializations come with a greater negative cost, the Machines’ convergence score becomes more difficult to raise, etcetera.

While it would be ideal to make the AI players more intelligent, instead of introducing artificial feeling bonuses and maluses, it’s a little bit beyond the scope of a design document. It’s a project for AI specialists once enough of the game structure has been developed to make working on AI for the project a feasible engineering challenge.

At worst, and lacking that specialization in a team, one could forgo advanced artificial intelligence entirely, and provide — as a single player challenge — something like constant waves of invading space monsters, which will be simple to script and for the AI to use — simply producing increasingly difficult combat encounters. This may be suitable for early prototypes, or a version of our game project focussed on a multiplayer experience.

Regardless of the choices ultimately made here, the vital factor is ensuring that whatever artificial intelligence is used to provide a single player experience is used to simulate the movements and changes that are consistent with the living galaxy the player empire inhabits. Simply making the AI act like an optimized human player will not achieve this. An AI player that knows an optimal build order and exactly what the player is doing, then sends an attack fleet the precise instant the player has left a planet unguarded, may be very challenging to defeat. However, it will not feel like part of the galaxy — and the sense that the galaxy, and the empires within it, are in some sense real and internally consistent will be damaged as a result.

Early Game to End Game evolution

An area of special consideration with Master of Orion 2 and its remakes is in the difference between the early game and the end game, and how the feel of the experience evolves and alters.

MoO2 opens with the player in control of one, or with the advanced start settings two or three, colonized planets and explored systems. By the end of the game the player may control ten times that amount or more. At the opening one can reasonably expect a fleet of perhaps three ships — by the end of the game a player’s fleets might contain thirty or forty. The scale of the game, and the kinds of demands the game makes on the player’s time, change wildly from the early game to end game.

As the player progresses through the game, it’s not merely an increase in scale, but also in complexity. More and more kinds of planets, alien empires, and special events are encountered. There are scripted elements to MoO2’s galaxy, such as the titular system of Orion, guarded by a titanic starship. Once the player defeats the Guardian of Orion, they receive special technologies and a powerful leader character and their battleship. As a player’s relationships with other empires improves, more kinds of treaties can be successfully made — such as military alliances. Advanced technologies unlock entirely new abilities, like terraforming a planet to change its type, or using Evolutionary Mutation to add abilities to your empire’s species.

Every time a player of Master of Orion 2 clicks the ‘end turn’ button, it is with the expectation that the entire way they play the game can change as a result. It’s rare, but something strange and unexpected will happen or some new element of the game will present itself often enough that the experience is a little bit like gambling. And the rewards provided — some almost certain, others entirely random and difficult to plan for — provide the same addictive emotional rush.

Sometimes players will speak of early game, mid game, and end game as if they are clearly defined phases in how a game is played. That one can in some sense design and implement separate early game, mid game, and end game experiences. But almost all of the magic in Master of Orion 2’s movement from early to end game is in its slow and gradual evolution from simple to complex, from basic and comprehensible to an expansive richness.

Part of how MoO2 does it is by providing the player with short term, mid term, and long term objectives which keep moving the player’s attention from area to area of the game. The ultimate goal — dominating the galaxy, either by destroying all other empires, defeating the invading Antarans, or being elected supreme leader of the galaxy — opens up obvious short term goals towards reaching this end. Colonizing new star systems and building a powerful fleet, for instance. However, once a player has colonized new star systems, they are now in contact with an opposing empire and must find a way to deal with that empire. Regardless of how they do, by that time more empires have been encountered, and perhaps they’ve discovered a star system protected in a way similar to Orion is, just by a less imposing guardian NPC.

This continual progression and change is a difficult element to capture and recreate, as parts of it — such as the speed at which one encounters other empires — are heavily dependent on the mechanical game balance, while others — such as random events and special star systems — must be carefully distributed across a randomly generated map. Other parts, such as the progression of technologies and the timing for when new special abilities that change the flow of the game are introduced, can be more obviously controlled.

An unusual element behind MoO2’s sense of progression lies with the ‘Galactic News Network’, broadcasting information about events elsewhere in the galaxy — most frequently unseen. A planet suffers a global earthquake event? GNN will report on it, and tell the player about the poor Meklar suffering in this catastrophe. Whether intentional or not, this small way of reporting random events helps to keep the player curious about what’s happening in the parts of the galaxy they haven’t explored.

So having dealt with why the progression from a simple early game to a complex end game is significant, just what else is important about this transition in Master of Orion 2?

Put simply, Master of Orion 2 balances the complexity of its progression against the amount of work the player needs to do in order to deal with the added complexities of the end game phase.

Each fleet in Master of Orion 2 requires ‘command points’ to deploy — without enough command points, the economic cost of operating a fleet will quickly skyrocket. In an empire with 30 command points, a player could have a fleet consisting of 30 frigates. However, later in the game one will unlock ‘Doom Star’ technology, to build apocalyptically large ships. While these ships are individually quite complex, controlling and moving them around the galaxy is comparatively easy — with 30 command points, a player will have 5 doom stars. By helping to reduce the number of ships a player has to manage in their fleets, this technology helps prevent the end-game turning into a chore of micromanagement.

The City Builder portion of Master of Orion 2, managing each individual colony, is also simplified by the ability to automate production at the majority of colonies — leaving the player to concentrate on production at colonies with high industrial bonuses from mineral richness.

By taking care to mitigate the end game complexity in this way and allowing the player to focus their time in ways that accentuate the power of their empire — fewer and larger ships, fewer and more significant colonies — the game remains playable without demanding too much micromanagement from the player. This is vital.

Again, as with AI, achieving a good balance between early game and end game, and to find ways to mitigate the increasing complexity of the end game, is a little bit beyond the scope of an initial early design document. At best, this early, we can look at emulating two mechanics from Master of Orion 2. Providing the player with a series of tasks that will increase the complexity as they are completed, and techniques to mitigate the complexity of running an empire with multiple star systems.

In order to provide a player with goals, our game project will present its storyline in a series of RPG Quest windows, similarly to Stellaris, and the player will need to meet several criteria in order to continue, some of which are under the player’s control — such as a telescope network to observe the Hyperwarp Dissolutor — and others which will be random, such as discovering a relic of the Precursors when exploring a new planet. The storyline presentation may be used as a soft tutorial, ensuring a player has certain key elements of infrastructure built — such as shipyards in order to produce exploration ships — while the more random elements merely need to be introduced in such a fashion as to make it clear how the player might encounter more. Perhaps alien relic-traders may be encountered once most planets have been explored, or a specific surveying technique must be used.

In order to mitigate the complexity of running an empire with more and more colonies and ships within it, our project will include ways to give orders to multiple colonies and fleets as a group. For example, all planets designated as ‘research’ might be given the order, simultaneously, to build a newly unlocked research lab. If a series of ships are grouped together as a fleet, they can be given orders as if they were a single entity, rather than dealing with multiple individual units. In addition, our projects’ colony structure will mean that each star system will have a single ‘colonial capital’, and all other settlements within that system will be treated as expansions to the colonial capital. A mining station built on a moon will, effectively, be an upgrade to the colonial capital. Some factions or technologies might allow a player to develop an unusual type of colony — such as an orbital base, rather than a populated planet surface. This system will mean that such unusual colony types may be operated in exactly the same way as more conventional colonies. If any options are found to automate the relevant subgames — Tactical Ship Combat and City builder — these should be used with a mind towards allowing a player to focus on just one colony, or one fleet that they care about, while the others continue to contribute to their empire in some way without their oversight.

Sub-Games in Detail

Providing full details on each sub-game for our project is beyond the scope of this document, but partial work-ups of particular elements and brief discussion of factors relating to each sub-game will hopefully provide a foundation to work from for any interested parties.

A fuller game design document would ideally include everything from mock-up screenshots of each sub-game to provisional algorithms and equations for various aspects of the game, such as calculations for the industrial aspects of empires, weapons, each individual technology to be included in the game, etcetera. However, do not mistake that for simply making a complete list — by working up these elements fully at the design document stage, they are more easily tweaked and modified than if they have been fully coded and other required assets, like art, utilized to bring them to life. It would, however, be appropriate to use prototyping and very limited game projects to explore these elements while developing a fuller game design document. For example, a simplified version of the territorial map that allows fleet movement only, with many relevant values able to be entered directly into a menu, to explore the impact technologies altering FTL travel, would be of great help to designers manually calculating the relevant values. This allows them to explore options for technologies, without requiring coders to implement algorithms and systems to actually have technology unlocks impact the game.

1. Territorial Map

The territorial map is the primary interface to the game, and where all other sub-games will be accessed from. Its core feature is a movable map of the galaxy, in which all stars and points of interest can be located.

Stars and points of interest can be opened to a sub-map, which will display, in the case of stars, the planets surrounding that star, and in the case of points of interest, the submap will display objects such as deep space starbases, rogue planets, debris fields, etcetera. These submaps will provide access to the City Builder subgame, which will be detailed below.

These submaps will also provide a list of available resources at a star/point of interest, such as mineral wealth, colony locations, and special encounters available to be triggered for the RPG Quest subgame, which will be detailed below.

Fleets will be able to travel between stars/points of interest, and will show a line linking them to their destination while in travel. Each fleet will have a maximum distance it can travel, dependent on the fuel it carries, and fleets automatically refuel while within range of an empire’s colonies or starbases. When a fleet is clicked, it will open a menu allowing the player to manage that fleet by associating ships together into groups known as task forces. A task force allows multiple ships to be treated, organizationally, as a single entity, and they will be able to be given orders as a single entity in the Tactical Ship Combat subgame, which will be detailed below.

The fleet menu will also provide the opportunity to utilize the special abilities of specific utility ships, such as:

Colony ships — which can be used to establish a colony if the empire has a compatibility technology for the location. (EG: Special technology may be required to begin a colony at a rogue planet in interstellar space, with no star, or a star orbited by barren worlds that cannot support life.)

Outpost ships — which can be used to place a small starbase in any location, stellar or interstellar, which can be expanded with appropriate technologies in the same way as a colony. (A large enough starbase can be used to colonize planets directly.)

Exploration probes — which can be used as an alternative to an exploration fleet, which are sent to a point of interest and deployed to provide sight at that location and other nearby locations, similarly to an Outpost ship starbase, but without the opportunity to expand.

When a battle encounter is possible — or required before ending the game turn as when an empire attacks the player — the Territorial Map view will provide a dialogue to either simulate the combat encounter or go directly to the Tactical Ship Combat subgame. The Planetary Invasion game will be made available in the same way with a dialogue, either after a Tactical Ship Combat where the outcome involves taking control of a planet’s nearby space, or when control has already been established.

Menus to access the City Builder game (via the sub-maps at points of interest), the Ship Design game, The Technology Research game, the Diplomacy Game, and a management screen for the RPG Quest game will be available in a tool bar at all times.

The Territorial Map will also include convenience menus for placing simplified orders in the City Builder game, and for examining and comparing the economic output of all controlled colonies and points of interest, and for comparing potential colony sites by factors such as potential industrial or scientific output.

The Territorial Map will allow the player to end their game turn, at which point a check will be run for any events that require a resolution before the end of turn — primarily some combat encounters, but some RPG Quest encounters may also require a response. The start of the next game turn will include a report summarizing any major changes in the state of the game, including completed building projects — such as starships and major buildings, new empires encountered, treaties signed, etc.

2. Tactical Ship Combat

Tactical Ship Combat will be triggered whenever, in the Territorial Map, a battle encounter is selected to be played through rather than automatically resolved via simulated combat. A battle encounter is possible at any point two fleets from different empires are both at the same star/point of interest, and will be forced when one empire attacks another.

Tactical Ship Combat is composed of a map screen, representing a two dimensional battlespace viewed from above, on a hex grid. Terrain features, such as asteroids, nebulae and planets, and constructed features like starbases and colonies, appear on the map and will either block movement and line of sight (asteroids/planets), or allow movement across/through them (nebulae).

Ships will block movement, but not line of sight, in a circle as wide as their size class. (EG: Frigates are size class 1, and occupy a single hex, wheras Titans are size class 6, and occupy a circle six hexes in radius.) Each ship is simulated, for combat and damage purposes, as a single point containing all the equipment mounted on the ship. Each ship has a facing, being the direction its nose is pointing.

Each ship is moved in a turn order determined by the ship’s speed and the ship’s command level — determined by that ship’s experience level. A ship may fire its weapons and move in any order, firing some weapons, moving, firing some more, and completing its move. The areas to which it may move will be highlighted on the grid. A ship will have a forward speed and a rotation speed, with separate values. Rotation speed allows the ship to turn more tightly — some ships will take a long time to turn and must slow down to make tight turns, or move in much longer curving arcs.

Each item of equipment has a volume scale — used when designing ships — which determines that item’s vulnerability to attack, and a hitpoint value, which determines that item’s structural integrity. Attacks that strike a ship will, by default, randomly select a valid item of equipment and apply damage to it, with larger items being more likely to be hit. Some items may be bundled together in a group — such as a series of weapons in an armoured blister. An attack which strikes a bundled group deals damage to all equipment within it equally — so five lasers with five hitpoints apiece will instead act as a single item with 25 hitpoints. When an item’s hitpoint value falls to one quarter, it is out of action and may not be used unless the hitpoint value rises above one half. When an item’s hitpoint value reaches zero, it is destroyed and cannot be repaired without special technologies or without returning to a starbase dock. All ships by default have an item of equipment called ‘structure’, which is by default equal to the sum of all other mounted equipment’s hitpoints. A ship can be disabled by destroying one of three critical systems: Its reactor, its command module (usually a bridge with crew), or its life support (AI processors, for the Machines). A disabled ship is out of action for the remainder of combat If a ship’s structure component is destroyed, the ship is blasted to pieces. If a ship’s engine component is out of action or destroyed, the ship is incapable of movement, and even though it can continue to fire weapons, at the end of combat it is considered disabled. Ships may have shields or armour, which protect a specific facing and have a hitpoint value which must be destroyed before damage may be applied to the items of equipment within a ship’s hull. Shields and armour may have specific types, which will affect damage dealt to them. (EG: Anti-kinetic weapon shields, anti-energy weapon armour, etc.)

Ships may fire weapons individually. When firing weapons, a comparison is made between the range between the ship and its target, the relative speed of the ship and its target over the present turn and the previous turn, and this provides the base value to hit a target. This value will be modified by any special equipment on the target and on the firing ship, such as stealth equipment, targeting computers, combat sensors, etc. Very high values are more difficult to hit, very low values are easy to hit. (Targeting computers lower the to-hit value.) The ship’s command level — determined by that ship’s experience, the training of its crews/combat AI, etc — will then provide a number of simulated dice to roll. These are added together, and if they exceed the target value, the weapon fire strikes the target. Each weapon is fired individually, unless they are part of a bundled equipment group, in which case they are fired and hit together, but deal damage separately. (A bundled group of five lasers rolls once to hit, but deals damage five times as individual laser strikes. Thus, against an armoured target which reduces all laser damage by 5, it would be better to have one overpowered laser than five individual lasers, but against an unarmoured target it may be better to strike five separate times and deal damage to five separate items of equipment.)

After combat, destroyed and disabled ships may be salvaged by the winning side, providing technology, resources, and RPG Quest opportunities post-combat. Surviving ships will have their experience, and thus their command level, increase.

Ships grouped into a task force — a group of ships acting as a single unit — will form a single ‘ship’, with all the hexes the ships would ordinarily cover added together to form a larger circle. (So up to 7 frigates, ordinarily 1 hex each, would appear as a hex 2 hexes in radius, covering a total of 7 hexes. Two destroyers, each ordinarily a circle 2 hexes in radius, covering 7 hexes each, would then cover a total of 14 hexes — rounding up to a circle 3 hexes in radius, covering 19 hexes total. Etcetera.) A task force moves with the slowest speed/turning speeds of the ships within the task force. A task force may fire its weapons individually, as if all weapons belonged to a single oversized ship. When attacking a task force, one ship in the task force is selected for firing on.

When a ship or ship within a task force is selected, it will be possible to deploy any special abilities that ship has, such as bonus repair powers, afterburners to increase speed for a single turn, etcetera.

Fighters and missiles act like a miniature task-force with ships far less than one hex in size. They are targeted as a group, and damage will be dealt to random members of the group. Fighters and missiles are only given a target, and cannot be given other orders until the carrier bay/missile rack reloads. (Fighters returning to the ship increase the reload speed of the carrier bay. Fighters may be pre-deployed at the start of combat.)

I. Ship Design

The ship design subgame consists of a design screen, where items of equipment are added to a ship hull. Each size class — from 1 to 7 — increases the amount of available space by the number of hexes that the ships would cover on the map in Tactical Ship Combat. A ship contains by default all critical systems — Reactor, Command, and Life Support (AI processors for Machines) — which will take up a given percentage of hull space determined by technology levels. A portion of a ship’s space is given over to surface systems — such as armour, shields, and hull — which will take up a small portion as a ship’s size increases, due to the square-cube law. (As a shape grows in size, its volume increases more quickly than its surface area.) Therefore, larger ships will require less of these systems for equivalent coverage.

Systems may be bundled together into groups, which will in general act like a single system. (Bundled weapons will fire together, for instance, and other bundled systems will take damage together.) Bundled groups may be individually armoured, which will increase their cost and size, but provide protection against damage when hit.

Systems will be added to a list, rather than placed on a ship outline.

Weapons may have various modifiers to their mounts, such as heavy, oversized, etcetera, which will increase or decrease range and damage, as well as a firing arc. Some firing arcs — such as broadside — may reduce the overall space requirement for a weapon, while providing special advantages, while others — such as a spinal mount — will increase size and cost, while adding unique bonuses such as colossally oversized. Weapons will have one of a number of special damage ‘element’ types, such as energy, splash, piercing, kinetic, explosive, etcetera, which may be combined — for example a laser might be energy and piercing, while a specialized railcannon with exploding shells might be piercing, kinetic and explosive. These will alter the way they deal damage — splash and explosive weapons, for instance, will hit multiple internal systems, but be less effective against armour. Piercing weapons will only do damage to the first system they hit, but have a chance to deal damage through armor. Etcetera.

Special systems may unlock special abilities for a ship, such as cloaking, or afterburners giving a boost to speed for a single turn, or special repair powers, etcetera.

When using fighters, the fighters will be designed as if they are sub-scale ships. Fighters are carried in carrier bays, and are considered a type of ammunition for the carrier bay. As with a missile rack, the carrier bay has a set firing speed based on its size.

II. Technology Research

The Technology Research game is a system for unlocking technologies within the game. It is primarily a menu-driven game, in which resources derived from population units on colonies (research points, or RPs) are converted to unlock opportunities, with several random elements.

Research is split across five related groups — Chemistry, Biology, Sociology, Physics, and Engineering. Further, research is split into two types — Applied Research, and Theoretical Research.

Sliders are set to determine which groups receive a given mix of research points directed into Applied Research and Theoretical Research. At the end of each turn, research points are applied and the game progresses by one turn.

Theoretical Research expands the understanding of science within a group, and unlocks research unlock possibilities within those groups as nodes on a research tree. Applied Research utilizes known understood science to unlock actual objects — buildings, ship equipment and other bonuses — from nodes on the research tree.

Each node on the research tree has a difficulty and prerequisites. If there is not enough theoretical research in a group, as compared to the node’s difficulty level, using applied research to unlock it is more of a gamble, and failures will sometimes add research points to related technologies — even much more advanced ones, or add theoretical research to the group (albiet inefficiently.) There will be rare opportunities for breakthroughs and other unusual events — positive and negative — while using applied research far beyond the theoretical research level. If there is more than enough theoretical research, it becomes more certain, and fewer random events will occur.

The intent is that while a player can struggle for a single advanced technology using applied research, doing so becomes increasingly risky the longer it’s done. For example, attempting to research an advanced reactor type early risks an accident which will damage a planet — as a research reactor explodes, but there’s also the potential gain of an advanced prototype military ship with a one-off version of the reactor installed with unusual bonuses. Many of these random events may cause RPG Quest dialogues, which will then determine the outcome.

Focussing on very high levels of theoretical research — far beyond the current average applied research level — can automatically and randomly unlock low level research nodes, so a very advanced theoretical research system will automatically unlock low level weapons, shields, etcetera.

Some nodes on the research tree have prerequisites, and while they can be researched, those nodes will not unlock without their prerequisites. Some nodes may not appear for all players, as part of a randomization. Some nodes, once unlocked, will lock off other branches of the research tree. This is mostly applicable to The Hive, and its mutually exclusive technologies, but other Empires will have similar choices to make. For example, an empire might be forced to choose between using magnetic railgun style kinetic weapons, or gunpowder/explosive propellant kinetic weapons. Once a sufficiently advanced weapon is unlocked, either railgun or gunpowder, the other tree will close off and lock as obsolete. These technologies can then only be acquired through unusual means, such as espionage.

III. City Builder

The City Builder game will be used to manage the structures built at stars and points of interest throughout the game.

Each point of interest, such as a star, will have a submap visible on the Territorial Map. These submaps will provide a guide to the locations it is possible to build structures in the City Builder game. (EG: A planet may provide 5000 units of building space, an asteroid might provide 50, and a constructed Starbase Extension might provide 25. A ‘colony’ building project may need to be used to unlock other areas of the star system, like other planets.) Each location, such as a planet, moon, or asteroid, will provide different bonuses and drawbacks.

Each location at a point of interest has a variety of local environment factors, such as biological support — essential for the civilian economy, and very high on planets which support life, non-existent on barren moons, mineral wealth — essential for industrial projects, and inspirations — representing unusual objects or natural phenomena conducive to conducting theoretical research. Some buildings will improve these factors — such as biohabitation domes for biological support, deep-core mines or energy-matter converters for mineral wealth, and particle accelerators for theoretical physics research.

Buildings are either considered infrastructure — and are not unique — or are considered Projects — which are unique. Housing for population would be infrastructure and can be built many times, but a specialist research building, such as a particle accelerator, is a unique project which can only be built once in a star system/point of interest. Orbital projects and infrastructure can be built without using building space, as the amount of orbital space available is effectively limitless.

Each point of interest — no matter how many planets or other locations have been unlocked with technologies or buildings — has an overall population value, represented by a token for each (approximate) million individuals of the population. These population tokens can be made up of any sentient species or machine that are resident at the point of interest.

Rather than selecting and assigning these tokens directly, sliders are used — or set to a preset automatic value — to indicate the desired mix of population assigned to the three groups — civilian economy, industrial economy, and research.

Civilian economy represents civilian economic activity, whether it is farming, capitalist business, socialist enterprise, entertainment, medicine, or any other form of economic activity that primarily takes place between members of the population for the purposes of supporting that population.

Industrial economy represents economic activity directed towards goals outside of the support of the population — for example, building new infrastructure to allow that population to expand, building military units, or building various projects within the region.

Population tokens will move between these three groups by themselves at rates varying depending on the population’s type — in terms of sapient species/machine model — and other social factors. It may take decades for civilian economy workers, such as farmers, to become skilled researchers in genetic engineering. However, machines or androids might be reprogrammed to perform a new job within hours. And, there will always be a minority of population members with transferrable skills that will let them switch immediately.

By default, population will also migrate to nearby stars/points of interest gradually, meaning that unless anti-migrant and anti-trade policies are taken, alien populations units can expect to be seen relatively soon.

Industrial production is done using a slider to mix output between local infrastructure, and projects.

Projects are built at specific locations, by selecting that location when building the project. Infrastructure is built and upgraded automatically on any available build space at the point of interest, in the location where it will provide the largest available bonus. Infrastructure is in three types — civilian, industrial, and research, and are built in the ratios determined by the population sliders. If infrastructure does not have a linked population unit, it falls into disrepair and gradually decays to ruins.

Some technologies and buildings — like habitation domes — are a form of infrastructure which are automatically built where needed, such as barren moons, to allow population to exist.

Projects that are not local buildings — such as the building of ships and military units, and the recruiting of spies — are simply selected on the overall build menu, and do not need a location selected.

All projects are built faster/slower depending on available mineral resources and population assigned to industrial economics.

IV. Planetary Invasion

The planetary invasion subgame allows players to send ground troops to secure and take over a point of interest, such as a star and its colonies. It uses a similar submap to the city builder.

All locations in a point of interest can be targeted for destruction by starship mounted weaponry, which may or may not be powerful enough to destroy or alter the target. (Destroying a starbase or satellite, or, as an extreme, rendering a planet uninhabitable and barren through weapons fire.)

All ships have a complement of marines, who can be deployed to attempt to take over a point of interest. They are supported in this effort by frigate-scale ships and fighters, which will provide major combat bonuses. A large fleet with several ships specialized as troop carriers will be required to take over a star system, and it may take several turns to do so.

Planetary Invasion will hold its current state between turns, so long as a fleet retains orbital superiority. If a fleet loses orbital superiority, losses at the location will begin to regenerate.

Each game turn, a player will select one or more locations on a submap to deploy marines to. Each deployment will do battle in that location once, resulting in casualties on both sides. Once all enemy troops have been killed in the point of interest, control passes to the invading player.

Once a location has been taken over, the local population receives a significant morale loss that may last for decades. (A good option may be to allow immigration, and dissatisfied population units will gradually migrate away.) Some empires and special technologies will allow alternate methods of dealing with this. (EG: Hive empires may be able to parasitize captured population units.)

V. Diplomacy

The Diplomacy game allows empires to interact with each other, with the outcome involving alterations in the AI behaviour of other empires in the environment, and the exchange of resources and technologies.

The majority of the diplomacy game will be played through dialogue menus, representing conversations between ambassadors. Once every few turns, it will be possible to enter into a treaty with another empire.

When a treaty is made, a separate dialogue is opened for a conference, with different bonuses and maluses depending on the interacting empires’ types. For example, in order for Diplomats to enter into a non aggression pact with Machines, the diplomats must construct a treaty and educate its officials on its terms, and the Machines must construct a new behavioural code-base which must be distributed throughout its network, and specialists from both sides must work to develop a workable set of criteria. There will be an advantage to agree clear terms, as the Diplomats are legalistic and the Machines operate through logic, but a disadvantage translating terminology from Machine operating codes to organic sapient languages.

At a conference, each player will select a motivation, which will add an element to the treaty. For example a non-aggression pact may additionally have a small number of trading ships, or open migration policies added to it, while a trade treaty may involve additional alterations to border security policies altering the strength of espionage between the two empires. Each motivation selected will increase or decrease the difficulty of completing the treaty.

Once all motivations have been selected, a random value, increased/decreased by the technologies, relevant diplomatic values (some empires might gain a boost from civilian economic activity, or from having large numbers of alien population within their empire) and relations between the empires, is rolled to determine the outcome, which will either be a catastrophic failure — which will reduce relations between the empires, a regular failure, which simply means the treaty has failed, a regular success, which simply means the treaty has succeeded, and a resounding success, which improves relations between the empires.

Trade will be done with a simple menu, increasing/decreasing a ‘willingness’ value which will be modified depending on how mucha given empire values the commodities being traded.

Espionage will be done in a fashion similar to the conference mechanic, albiet one-sided, where instead of a treaty, an empire will select an espionage outcome — such as stealing technology — and then move to a conference where instead of motives, spies may be added to the mission. The likelihood of detection will increase as more spies are added, but skilled spies may reduce this somewhat. Each spy will add bonuses to the mission’s outcome — such as one spy will increase the likelihood of stealing a technology from a specific technology group, such as physics. Espionage missions can be directed at any other empire only once every few turns, similarly to treaty declarations.

VI. RPG Quest

The RPG Quest game is primarily made up of multiple choice dialogues, which will be triggered at various times in reaction to events such as new star systems being explored, and sometimes at other times, such as twenty to thirty turns after a location with a secret relic having being colonized.

The options available will change depending on the empire type, the empire’s history, technologies, and treaties available. For example, if ancient remains of another species are discovered, if an empire of that species is presently at war with the player empire, the archaeological discovery might be used in propaganda against the enemy empire, whereas if they are at peace, the remains might be sent to the other empire to increase relations.

Some buildings may be used to trigger the RPG Quest game — for example, initiating a special project at a point of interest relating to the game’s plot will immediately open an RPG Quest dialogue.

RPG Quest dialogues may also be opened in reaction to espionage events, technology research failures, the acquisition of debris after a tactical ship battle, etcetera.

This system may also be useful for handling events such as Tyrant coup attempts.

Rewards from the RPG Quest dialogues will include unique star ships, resources, ship experience, and long-lasting bonuses/maluses, such as an empire-wide bonus to mineral wealth that lasts only a few turns.

What’s left.

This is