Some people are good at making things. Others are good at breaking them. I guess I’m a breaker.
As some long time players know, we’ve been trying to find ways to reduce the memory foot print of Kumquat (the engine behind Elemental). It’s a non-trivial thing to do, especially when long ago when we were specing this we were thinking of the day of 64-bit gaming when the 2 gigabyte memory limit was no longer a concern.
2 Gigs
Now, a quick thing about that. No matter how much memory is on your computer, a PC game will only be able to see 2 gigabytes of it unless the game itself is 64-bit which, to my knowledge, there are no major games that fit that yet. This is something pretty high on our priority list for the future but with most people still running 32-bit Windows, we have to focus on the here and now.
Crazy Games
Anyway, I have a saved game that upon loading would instantly crash the game because it was on a crazy sized maps with crazy sized cities with crazy numbers of units. The challenge to the team was to find a way to make this work.
Most games work around this problem with unit limits. That’s why Sins of a Solar Empire and Starcraft 2 (to name two examples) have very definite numbers of units in the game. War of Magic has no such limit. There’s nothing stopping someone from creating tens of thousands of unique units.
Multithreaded
The Kumquat engine is highly multithreaded. Now, what does that mean? It means that if you have multiple cores, execution of the game will occur on multiple cores. The AI has its own thread. The graphics engine has some threads the main game has a thread, the music has a thread and so on.
It’s the reason why, even on a relatively low end system, you can zoom out and see the world and then zoom in and see individual people living out their lives in one smooth, fluid motion. It’s a pretty impressive technical feat imo. But it comes at a cost – memory. The easiest, fastest way to implement this ability was to give each unit its own instance so that it could be threaded. That doesn’t mean each unit is its own thread, that would create a different set of problems. It’s a bit more complicated than that (ok, it’s a lot more complicated than that). But what it means is that the engine can choose to put different groups of units into their own thread in order to make sure everything remains smooth. But it means doubling up on memory – or tripling or quadrupling and so on.
Now, this isn’t something that was a mystery to us. We knew about this. The problem was, how do we have our cake and eat it. The solution basically boiled down to months of work to write a different system to do this. So for the past few months, that has been what Codecritter and the gang have been trying to do. Now, in v1.19, some people people have reported a performance drop so that’s being addressed presently as well.
But the good news is that, in theory, the next beta of v1.2 (v1.19c? d?) should largely eliminate the memory issue for most people.
Far Reaching effects
Most people don’t connect gameplay limitations to memory. But there’s a definite connection. Because when you’re fighting a memory limit, it greatly limits what you can add to the world. You end up having to bland things out because, frankly, adding more “stuff” becomes very problematic. Most people don’t make these connections (if you read forums they think the designers or developers are just oblivious or didn’t “see” some issue). But that is the challenge of designing a game – any game – on any platform is making guesses as to how much of a design can fit in. That’s another reason why sequels are so tempting. You already know the scope.
The bottom line is that it’s good news for War of Magic and great news for Fallen Enchantress.
