Design Philosophy

In a nutshell: 4x space strategy for modern and future cpus, (initially) no art assets

I developed this project partly out of a desire to see what sort of strategy game could be written using oodles of compute time. I have also harbored a desire for a (mostly) realistic physics game set in space for some time after reading novels like The Gripping Hand, Ender's Game, and The Forever War. I believe that realism in strategy games provides much of the fun factor--without ties to real-world dynamics and intuitions, the player is just cranking numbers in a spreadsheet. Finally, and perhaps most importantly, I am attempting to create a strategy game tailored for competitive, hardcore play.

I am attempting to allow as many types of gameplay dynamics and interactions as I can. I do so primarily because I think one of the fundamental problems with many strategy games is the predictability with which they evolve. Part of my design philosophy has been to consider whether every feature I think of could benefit from being represented as a floating point number, and mutate the features that can't into ones that can. With this in mind, I have tried not to impose hard caps on anything. The player ought to and will be able to research and build units as he sees fit, not according to what I choose to make available. As such, most every calculation is subject to "soft caps" which make all the extremes gradually more expensive and less efficient. Players are free to find their own happy points, in research, in economy, and in play strategy. All units can be made orbital, fitted with engines, equipped with crew, outfitted with weapons, or have any of these elements removed. There is no distinction between a planetside weapons installation, an automated mining ship, a starbase, or a torpedo. All of these possibilities are simple logical combinations of the elements a unit can possess. If the player wants his civilization to live in ships and bases, traveling to planetary systems solely to drain their resources, he can. If the player wants his civilization to live on a single planet, only launching automated warships and mining drones, and move his planet when all the resources nearby have been consumed, he can. If the player wants to equip his Death Star with lots of rock throwers, he can. If the player wants to field a fleet of tiny one-man fighters brought to the battlefield in a huge carrier, he can. The result, hopefully, is a game of surprising depth and complexity.

In order to facilitate balance, I make no distinction between different player races. In Hyades, all players represent a splinter human civilization trying to succeed on its own. Thus, all the players have equal capabilities. In any release of Hyades, any "broken" feature is "broken" for all players, keeping the playing field level.

The main concession I've made is instantaneous communication. All commands are carried out without delay, and all inter-civilization communication has no propagation delay, as well. I do think the lightspeed barrier could make for a very interesting game, but I know it would be subject to abuse in an anonymous multiplayer game like Hyades. There's any number of possible attacks and abuses. Consider two players who choose to collaborate using ICQ while the rest of the players communicate in-game. I can't force players to stick to the lightspeed barrier, so I choose not to try.

That said, all objects in game are subject to the lightspeed barrier, and accelerate in a relativistic manner. That is, more and more energy is required to get fractionally closer to the speed of light. Furthermore, the game universe is defined in three dimensions, with a complete three degrees of freedom of movement. Finally, the game universe evolves with time: stars move in a cluster orbit around the center of mass while planets orbit their stars and binary systems orbit each other.

Another big part of my design philosophy is multiple levels of abstraction. The engine hides many of the details of the player's empire and gloms them together into figures of merit, reports, and higher-level abstractions. For instance, all objects are group-able into territories, fleets, military zones, provinces, etc. and all groups are group-able as well. Orders may be issued to a complete cluster of stars and settlements with just a single command. Consider: planets are actually represented as primitive units in the game. Their orbits are calculated and ships will match their trajectories to enter planetary orbits. The player need never even look at a planet if he does not wish to, and simply consider each system as a whole. Yet, it is possible for multiple players to have colonies in a single solar system, if there are enough planets to support them. My initial goal was to design a game that, on my circa 2001 computer, could be played with at least one thousand stars in the game universe. Some of the games that don't scale very well top out around one hundred stars. My hope is that as computers follow Moore's Law inevitably upward, Hyades will scale to tens of thousands of stars, and beyond.

Hyades does not fit into the current notions of RTS versus turn-based strategy. Physics calculations are constantly being carried out by the game engine--the game universe is always evolving, like an RTS. However, player intervention is not required for any of the interactions, with the exception of a very few. The result is a game that should only require player commands once a day, perhaps only three or four times a week. The resulting gameplay is very familiar to any PBEM gamer, as a single game will last weeks.

Unless otherwise noted, this website is licensed under a Creative Commons License.