4X Space Strategy Game Concept: Summary

To a degree, this game idea is inspired by classic strategy games such as the Master of Orion series the Space Empire series, or the Galactic Civilization series. But just as importantly, I am influenced by the Warlords series, most notably Warlords II. It was a very tightly focused game that didn't throw a lot of complexity at the player, emphasizing military strategy. Even the battle mechanics were very abstract. I'd like to recapture that focused essence in a space strategy game.

Another notable influence was Shogun: Total War (the original). A few years ago I felt like playing it again, but the old game engine didn't work very well with my modern hardware and drivers. The turn-based campaign was fine, but the real-time battles were hardly playable. Instead of giving up, for some reason I chose to auto-resolve all battles. I wasn't expecting to be entertained (battles are a huge component to the Total War series after all), but I was pleasantly surprised. The campaign alone provided a compelling gameplay experience, one that was tightly focused as with Warlords II, and that experience stuck with me. Later, while thinking about space strategy games involving star gates between star systems, I realized that the Risk-style campaign map of the early Total War games was in fact very similar; it's just a graph of nodes and edges. This produced interesting crossover ideas such as having planets in a star system behave similarly to fortresses in a province.

One final significant influence is Master of Orion III's simultaneous turns. It wasn't perfect, but it was a far better system than I've seen with other turn-based games, as it didn't transform the game into a series of real-time phases where fast thinking and fast clicking were important. You wouldn't take direct action during your turn, but would simply choose the actions that would be taken once all players ended the current turn. I would like to expand on that design, as I think the benefits could be significant. The improvement to a multiplayer experience is obvious, as there would be much less downtime. Even in single player mode, not having to wait on the computer opponents at the end of every turn would be welcomed, I'm sure. It also completely alleviates the issue with turn order, wherein the first player might get an inherent advantage or disadvantage merely by going first.

Unfortunately, unlike games that just slap simultaneous turn mechanics on top of a game designed from the outset for synchronous turns, it does take effort to design the core mechanics such that they actually integrate naturally with the simultaneous turns. I've been thinking about this for a while and have run into numerous obnoxious edge cases, but I think I have some interesting solutions to most of them. Whether or not they actually work, only prototypes will tell.

I haven't concerned myself too much yet with research, production, or battle mechanics, since I would like to keep the game narrowly focused and not too complex, as I noted above. I've had a variety of thoughts on these topics in the past, but nothing organized is bouncing around in my head presently. After (and if) I validate the feasibility of the overall simultaneous turn system, I'll likely shift my thoughts to these other areas.


Simultaneous Turns Prototype (on hold)

A major overhaul of the UI from the previous prototype. Once the UI is able to again represent all the details of the previous UI, I'll continue with the gameplay mechanics.

Simultaneous Turns Prototype (superseded)

A completely rewritten variant of the prior prototype attempt. Supports primitive unit movement for one player and most intended visibility rules (exploration, fog of war, et cetera). Read more in the blog post.

Take a look! It's vaguely playable as is, or at least interactive.

Simultaneous Turns Prototype (superseded)

A simple HTML5 canvas prototype examining how well the simultaneous turn mechanics work, as I currently envision them. Currently very incomplete.

The overall concept is that movement and other actions of fleets occur during multiple sub-turns of a larger overall turn. Each sub-turn will be dedicated to only specific types of actions. In order, the phases will be 1) movement, 2) attack selection, and 3) battle resolution. During the movement phase, all players will choose where to move their fleets. Movement from one location to another neighboring location takes exactly one movement turn; there aren't multiple speeds that influence this. After all players have completed this phase, all movement takes place, and potential conflicts are determined, given the new fleet positions. During the attack selection phase, players can choose to resolve conflicts by attacking, defending (attack only if attacked), or retreating (again, only if attacked). After these choices have been made by all players, the battles are resolved, and the results of those battles are then presented to the players. Any retreating units must pick where they are retreating to during this phase, before moving on to the next movement phase. (This way, the attacker can know at the beginning of the movement phase where the retreater is running to, so that the attacker can pursue, if desired.)

Another important note is that there are two different types of movement phases that alternate each turn. The galaxy is set up so that star systems, planets, and what I'm currently calling "hyperlanes" are the different types of locations. Planets and hyperlanes only directly connect to star systems, not each other; star systems similarly only connect to planets and hyperlanes, not other star systems. During the first movement phase, movement is only allowed to occur from star systems. During the second movement phase, it is only allowed to occur to star systems. I think of it as launch turn (launching into the open space of a star system from a planet or out of a hyperlane exit) and a landing turn (landing on a planet or entering a hyperlane entrance). This ensures that when players are simultaneously choosing their fleet movements, it is impossible for two opposing fleets to pass each other in a single phase, eliminating that tricky edge case.

To my knowledge, these mechanics are new, so I'm eager to get the prototype functioning enough to discover if the extra burden is manageable or far too complex.