The real challenge is in organizing the design that takes the limits of a modern computer
Not really. Look, the amount of CPU it takes to simulate one
completely accurate physics simulation of
one spacecraft is beyond a modern home computer. And no, Kerbal Space Program is not a "simulation", except in the roughest sense; it's a
vague approximation that's fun.
I think you're really making a huge mistake here, in general; when designing a game, you need to start off with "what will be fun" and work from there to develop the systems that
create that fun.
Starting with the premise that "complexity is fun" is a non-starter; if that's true, then a "game" where one attempts to find a fully-simulated pink ping-pong ball in a sea of fully-simulated white ping-pong balls is inherently fun, when in fact it's really quite boring, even if you do so by melting them with a flamethrower or something.
If you approach game design that way, you're going to build a terrible game... and you're going to hit performance issues you never anticipated, because you're starting from a premise about simulation complexity and pre-optimization strategies that may or may not have any real bearing on the problems you'll face.
For example, if you make everything as simplistic as possible- simple Newtonian physics with circular collisions, no drag forces, only one force vector applied per frame, etc., that's great, the motion of the characters is now as simple as it can get without not being simulated in any real sense. But your AI for driving those characters might run to 1000 lines of code; compared to the physics, the simplistic, goal-seeking AI handling local steering is already far heavier.
Then you have the AI that would need to handle these independent agents in the larger simulation, making decisions that determined where, exactly, they choose to go next; this gets into further and further complexity. Then there's the complexity of drawing the character on the screen; once you're past a single quad that does nothing but appear / disappear depending on state, it's quite likely to make the AI code look
small and tidy. Again, I really feel like you need to spend some time actually trying to develop something here, instead of just theory-crafting, because you're making a lot of assumptions that simply aren't true.
Your argument is, essentially, if only the perfect strategy existed, then hugely complex sims could be realized... but that's not the question, ever. At the end of the day, the job of the game designer is to make fun happen. Develop the fun, then look at what needs optimization. Often, you'll be very surprised where the issues are.
Lastly, let's go ahead and talk about
Spore and
Minecraft.
Spore and Minecraft take two different approaches that are both noteworthy but are surprisingly similar when you really analyze them:
Minecraft uses an algorithm to build the voxel worlds. It also stores any voxels in a given set that have been changed, so that there is permanence. There are some practical limits to that, in the sense that if enough voxels are changed, then the amount of memory that is required to have permanence is too large to handle, but the data is so simple (literally an int in an array) that it's huge. Minecraft doesn't generate any new events (mobs, etc.) far away from players; these are generated procedurally when it's desirable, to save memory and CPU. It also doesn't allow for much permanence of local objects that can't be stored as simple ints in arrays (like, if you drop a bunch of blocks somewhere, they eventually fade out to save memory). So the world looks very complicated but actually isn't. Minecraft doesn't even simulate the AI for mobs that get beyond a certain distance from the player, and eventually culls them to save CPU. There are Minecraft mods that actually keep game entities from being culled for a much longer period; they are very, very memory and CPU-heavy.
Spore doesn't deal with permanence very much, beyond some very simple things, but instead uses procedural methods to create the local scenes. Because these scenes are generated from a seed, there is a CPU cost when entering the range at which they need to be turned into something, but it can be controlled by keeping the scope small. Very little else is actually being simulated, but because it's always busy around the player, it
appears very complex.
Note that both games are essentially like
Freelancer in this regard. There is very little real permanence in any of these games, because permanence eats a lot of memory, and the number of characters in any given situation is carefully controlled at all times. Where it's necessary, all three games made global events happen that change events far away from the player's current POV, but these are generally very small events, both computationally and memory-wise (setting a boolean somewhere to declare that a given task is done, an int to declare a specific state change in a script, etc.).
In short, both of those games are games where instead of chasing after this goal you're so enamored of, the developers simply keep it busy in the local area around the players. This creates challenge and fun. So basically you're spending all this time trying to think about ultimate optimization strategies for having a whole bunch of things flying around everywhere... but it's the
wrong question. The right question is, "what will players get to do that's fun" and "how can I create that fun within the limitations of modern processors and memory".
