Space is big. Really really big. However, everything in it is really, really small. A typical solar system is about 100 AU (about 10 to the power of 13 metres) but a light year is about 10 to the power of 16, and solar systems are many light years apart. A solar system, at scale, would occupy 1/1000th of the distance between two stars space (not very optimal for a map with tens of them being drawn). The problem gets worse as one goes into a solar system. The Earth is 10 to the power of 5 in size while its distance from the sun is 1AU which I already said is 10 to the power of 11. This means that you wouldn't even bother drawing the earth on a screen. This gets further exacerbated when you try to do moons. Even if you tried to do the solar system with the planets not to scale (so they're visible), this leads to problems as the inner planets in our solar system (Mercury, Venus, Earth, Mars) are very close to the sun compared to the ones further away, and most astronomical texts show the inner solar system separately, if they try to draw the solar system in the first place.
In practise, for game designers creating space-based games (of any kind, strategy or fighter sim), this creates a huge headache. Any attempt to make the game realistic and so create an immersive space-based experience makes the game too complex, creating headaches for the game designers. Too many objects can result in too much happening in the game map (slowing the game down especially with physics collision scaling rapidly with the number of objects). Pushing the details on to the interface can lead to too much information on the screen, all of it displayed in a way that's not optimal for gaming interferes with the player's gaming experience. In the end, game designers solve problems like these by simplifying greatly and not using proper scale. This has the advantage that the game is simple, playable and easy to use. However, this sacrifice leads to a loss of immersion. It also leads to great practical design problems in space based strategy games like Free Orion. Chief among the problems are that the game designers usually have to code in a solar system for combat segments (and then the lack of scale becomes jarring, especially when they draw a planet on) and they also have to hack in inner system dynamics (like asteroid fields, orbitals, trade, production etc) without actually considering what is happening, leading to some pretty weird and jarring effects. Game designers spend a lot of time thinking about how they'll fix the problems they created by simplifying so greatly, believing that those problems are smaller than trying to do it properly.
Current space-based strategy games face this problem, and all of them have tried different schemes of simplification, with greater or smaller degrees of success. However, all of them are seriously flawed. Any game intending to extend on and improve the current games needs to find a solution to this problem that actually works.
A Possible Solution
This is my take at solving the problem. There are two main ingredients:
Space is Clustered
Although space's size is a considerable headache for game designers, it can be turned into a considerable advantage. Firstly, objects in the galaxy tend to be clustered in a small region (with not much in-between). Things in solar systems are clustered tightly around the solar system compared to the distance between solar systems and things inside solar systems (e.g. planets) are again clustered together into a small region, as moons are clustered tightly around planets and orbitals cluster tightly around moons/planets/planetoids. This pattern, of tight clustering, occurs everywhere in the Universe in reality. Even in a binary star system (something Free Orion doesn't do), it's easy to divide the system into the orbital region around star 1, the orbital region around star 2, and the orbital region around both stars. It really can be used to model everything in space using this regional system.
If we decompose our Solar system into regions as an example, we would have something like this:
Code: Select all
The solar system | + - Inner Solar System | + - Mercury + - Venus + - The Earth/Moon System | + - Earth + - Moon + - Mars/Space + - Asteroid Belt + - Outer Solar System + - Jupiter System | + - Jupiter + - (The moons of Jupiter, inc Io, Callisto etc) + - Saturn System | + - Saturn + - Rings of Saturn + - (Moons inc. Europa etc)
Why is this useful? Well, from both a physics and game design perspective, things in one region don't interact with things in another region, except by moving between a parent or child. This means that the map has been effectively split into several smaller maps, each of which are (by and large) independent from each other. From a physics perspective, E.g. the moons around Jupiter don't feel the physics influence of the Earth's moon, they will never collide, they will never interact and we don't have to worry about them. From a game design perspective, the individual components are effectively self-contained (e.g. production on Earth is probably going to only be used on Earth unless transported by the game). The structure outlined above is also well known in programming, It's called a tree. It's easy to code and it's easy to write simple algorithms that will span the tree, and FreeOrion already uses a subclassed system, so it's not incompatible with this idea (i.e. making the change would not totally require rewriting the code). It's easy to take the Earth/Moon system, for example, and issue orders to it, and have them transferred via tree-spanning algorithms. The tree system has the advantage also that it's natural for interfaces. You double click on a solar system to zoom in on it. You see the stats for your system. You double-click on a planet/moons system and zoom in and see its stats and then finally the planet itself (or the moon, or the orbitals). When you're done you zoom out. This system can never, never overload the interfaces with information and will automatically display it in a logical manner. Rather, any problems will come from trying to move around the tree and compare stats or issue orders that require one place to take another as an argument.
The size of a system is really its gravity well
The above tree system solves an awful lot of problems. One problem it only partially solves, however, is scale. Anything that interacts with an object A gravitationally tends to be at the same distance from it as other objects that are interacting with A. However, you'll notice that it doesn't work with the inner and outer solar system have wildly different scales. However, it does work if you split them manually. It's a hack, but a small one, and hopefully an acceptable one that can be done anywhere there's a dislocation in scale. It's also something you only need to do for systems with lots of orbiting stuff, and thanks to gravity's 1/r^2 law, you tend to only have to divide things into near and far for most cases to cope
The tree solution also doesn't solve the problem of planet and moon scale. Although the inner system is only some 3AU in size, that's still bigger than the Earth. Venus etc. Far too large to display them. However, if you consider the Earth Moon system, you realise that the Moon is 10 to the power of 8 away from the Earth, which is only 1/1000th of an AU. Also, you realise that, if the Earth influences the Moon at the power of 8, then it's influence will touch fleets about at the power of 9ish, and if we want to model orbitals, they'll be at a power of 7. This means that, in reality, we'd be forced to use a region of 10 to the power of 9, which is only 1/100th of an AU and eminently doable on the inner solar system map. So it's possible to see that gravity well sizes work well in most cases, both in reality and in game design, meaning that there's not too much hacking one has to do.
In those cases where it doesn't work, we can extend the region to a distance that displays nicely on its parent screen with no real problem that I can see.
The only immensely important and horrible programming issue I can see is that, although the maps are independent, because things can move from the child to the parent (and vice versa), you need to do the movement in all of the maps at once (or in incremental steps) to make sure things collide where they should.
The region system allows you to model any space system on a real scale without sacrificing gameplay. The complexity of this solution is the minimum that I believe can be realistically achieved by modelling space realistically. This solution doesn't make the game needlessly complex and it does add to the immersion of the game. It adds and removes complexity to the game (although it adds more than it takes), it obeys KISS and, well, no one's tried it yet, which is never good, although I'm sure they will one day, as it's an obvious solution once you think it through, and obvious is awesome. I also think that modern computing hardware is up to the challenge of handling these trees for the first time ever and the reason this has not been tried before is that programmers couldn't.
Complete freedom to build/move/attack/defend/explore anywhere in space, even in a system or in orbit.
The ability to model most space environments ever imagined in any science fiction book, including but not limited to: binary stars, Lagrange orbital points, different orbital bands (Low, high and geosynchronous orbit), O'Neil Halos, Iain M. Banks Culture-style orbitals and asteroid bases.
No separate tactical displays for combat, can reuse main map with no problem for any type of combat (except ground).
Completely new system of moving around which has extra clicks and is therefore, on the whole, more complicated, and particularly hard if you do lots of up/down tree operations.
Forces games designers to consider inner system dynamics in all cases.
Forces a tree structure over the entire game, each level based on the scale of space based system.
Transitions between regions can give collision headaches to programming.