I'm finding that I have to bring this up every few months, usually whenever we get an influx of new people. Following is the FreeOrion Dev Team Position On Realism. You may not agree with it, but for better or worse, this is the way we work. It's not going to change, and if your idea/suggestion/argument relies on something contrary to this position, it's going to say to the Dev team that you didn't do your homework, and it won't be taken seoriusly.
I am sorry to sound so draconian about it. I don't mean to discourage folks from coming by and giving their two cents. But this is already an age-old debate within FO, and it's been done to death.
First, the definition of the pertinent terms.
: Logic in support of an argument in the design of the game that is founded on the assumption that 'things in real life work this way, and so should this game.'
: The feeling of being completely engrossed in the game. The opposite of something that reminds you that you're playing a computer game. In a film, having a character in the film make a self-referential comment about being in a film ruins the immersion. On the surface, this seems to be related to realism, but it's more about convention and polish. For example, if you fire weapons at an enemy ship and you can get an idea of the effect based on the graphical result, you remain immersed. If you have to read a bunch of numbers that pop up over the target indicating how much damage is done, you're breaking 'immersion' (or 'the fourth wall' if you're a theatre snob like me). Likewise, the AI doing something 'gamey' or obviously cheating just to compete with you damages immersion somewhat. But this has no bearing on 'realism' as it's defined above; it only breaks the 'real' in terms of what the game establishes as real.
: What seems natural to the player. This is sometimes interpreted to be related to realism on the grounds that players are used to the real world, and so they'll be used to in-game adaptations of the real world. But we don't tend to buy that argument. A good example of 'intuitive' that came up recently was in the money discussion: there are various 'intuitive' uses for money (like trade and fleet maintenance) that could be accomplished with other resources (like minerals), but it's a little more 'intuitive' to use money because most of the games that influence us take this approach. Even this is not a huge reason to do anything or not, though, but I'm more interested in establishing what intuitive isn't than what it is. It is
making things in the game easy to figure out through the application of good design principles and UI engineering.
Some examples of realism that have come up in discussion that we hope to avoid in the future:
- Governments must have some means of paying their people and people must have some means of buying things. Therefore, FO needs money.
- Diverse alien races would never use the same currency, so each race should have its own currency that could be converted when dealing with other races.
- A real galaxy has a bajillion stars in it. Therefore, we should not call our galaxies 'galaxies' since they only have dozens or a couple hundred. Alternatively, we should actually allow people to generate maps with huge numbers of stars.
I'll add more to this list as I remember things (or see new suggestions...), but the point is: Realism = Irrelevant. It's not bad -- it's not a good reason to do something or not to do something (it's just as invalid to say 'we can't do that because it's realistic' as it is to say 'we should do this because it's realistic').
In closing, remember our two cardinal rules of design:
Keep It Simple, Stupid (KISS). Put another way, you should not need a computer to understand the rules. The computer may be able to do it faster, but you should be able to explain the basic rules to a reasonably clever child without difficulty.
Steal What Works. Don't re-invent the wheel or figure out novel ways of doing things just because you can. It's probably already been done, and when it has been done, you can judge how well it was implemented and maybe implement it better; when it hasn't been done, it's much more of a risk and more difficult to get it just right.