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.
Well unless Steam is lying to Valve...
And I wasnt suggesting they dont do 32 bit; though I am still wondering about that 64bit build and who's playing Elemental on what.
I also don't understand why the game doesn't have the LAA flag turned on, it seems to solve most of my OOM issues.
sa--WEET! Thanks for the continued commitment & informative post.
One of the more common ways of addressing memory use is by partitioning and streaming. While typically regarded as a graphics technology, I see no reason why it couldn't apply to gameplay as well, especially as procedural content is made more prevalent.
Say you have a person in your town who will go about his daily routine for you if you're zoomed in enough. This routine involves walking from a house to the town square, and from there to the library, and back.
Now, if you keep this guy, and all the other guys, in memory, yeah, that's going to be a huge problem. But you can eliminate a huge amount of the issue by taking the guy out of memory when you're not zoomed in. Keep a set of graphical elements for citizens handy, but make the city process completely procedural - timing, location, everything as a mathematical function - and you can recreate it at will, at any time, with no concern for loading or an abrupt pause in the processing when you zoom in.
Other things, particularly user-designed elements, involve disk access. I like the concept of adding a user-generated "change log" over the top of a procedurally-generated base.
For reference, in my spare time I'm working on simulating a 160-square-mile world (it might be as small as 40 square miles in the end; initial load times are approaching intolerable), complete with human civilizations and cities, and local interactivity. One of the goals is that the player should be able to steal everything from a random citizen, then come back later and find that, say, the citizen has resorted to thievery to make ends meet. Simultaneously, the player should be able to go to a random spot in the world, pick up a rock, and put it in his pack; then return later to find that same rock still missing.
So, I have the following structure:
* At the base is a procedurally-generated, yet constant terrain/foliage/climate map.
* This is extrapolated to produce everything from trees to rocks to flowers.
* When you enter an area, the game will look up a list of changes the player has made to the environment, and use them to supplement the procedural generation.
* On top of all of this is a timing/state system to represent citizens/cities/countries. It is run in a separate thread, and not in real-time (changing every in-game hour/day), so that it can change over time while not negatively impacting the framerate. It is linked to a procedurally-generated set of buildings and villages that the player can enter and interact with, and should be able to generate its own changes to the local environment.
The overall goal is to minimize memory use, speed deficit, and hard disk loading time by depending heavily on procedural content/activity.
I am curious as well. Maybe a hardware/software survey or poll for Elemental users. It would be awesome for Stardock to enter this brave new world of 64-bit games. I know it may not be an option mainstream games but it would be great for niche gaming. After all we know the desire is there.
https://forums.elementalgame.com/400378
While it may not be considered a major game any more, I believe there's a 64 bit version of Half Life 2.
Is there a chance that stardock shares this solution at some point? I would like to see some code being made open source (or whatever license) so everyone can benefit from your coding teams genius.
@omicron: do you have your little project online somewhere?
I think Frogboy meant that there's no games to his knowledge designed specifically for 64-bit... which is pretty different from just supporting, or even having a version optimized for, 64-bit.
Anyways, memory problems resolved/alleviated? Groovy. Maybe now I can finish that fun Extended Races game I had going.
Fact of the matter is, Micro$oft are the ones to blame for more computers not being 64 bit. Just about all computers in people's homes these days have 64 bit processors, but MS dithered in pushing out 64 bit OSs and allowed tons and tons of systems with 64 bit procs to ship preloaded with 32 bit OS.
Right on, this is one of the few major issues i'm still having with the game. Keep up the good work guys!
Microsoft has no legal say in what manufacters ship other than pricing and availability. Furthermore there are a wide variety of applications that do not work properly in a 64bit computing envriment (yes they are coded badly, no that does not magically make them irrelevant).
Edit: add licensing and distrobution restrictions on to that list, my point being that they can't force them to ship one product; it's an antitrust violation.
Yep. My comp is AMD 64 X2 Dual Core 4200+ 2.20 GHz with 2GB ram. Why only 2GB? At the time it was preloaded with Vista Home Premium 32bit. Cannot be arsed reinstalling 64bit version and upgrading ram. WAAAAAYY too much hassle. I would of done it years ago, but I am beyond putzing with computers anymore.
I want the "It Just Works" (TM) computer we have all been promised for the last 20 years. Seems to me that the technology industries of this planet are still stuck in the 2 year old tantrum throwing phase. We really need a MAJOR revolution in the way technology is handled.
I don't think this will occur until all the baby-boomers have left the building. Then maybe we can have a paradigm shift.
It begins with hardware. Then we need a new programming language NOT based on the C-family languages. Then will come the "It Just Works" (TM) philosophy. When this has been achieved, technology will have matured into adulthood.
I won't hold my breath, however.
Thanks for the update.
EFE sounds like it going to be very cool game play wise as well as performance wise.
Count me in on wanting a 64 bit version as well.
On the other hand, Sword of the Stars never crashes, even with huge galaxies and 100s of ships per faction.
On topic: Great read, tnx Frogboy. This explains some stuff (maybe even the drop in performance as my i5 when using all 4 cores makes each of them rather slow - 2.66)
Sorry, but this sounds very untrue to me. Both of them are RTSes, and limits are caused by real-timeness rather than memory limits.
It has to perform complex calculations each tick, which often cannot be optimized further than O(n log n), and most of the time are even O(n^2). With several ticks per second, you have to be very careful on total numbers, or game will be slow.
Typically instances are very cheap memory-wise, and even 10kb/instance is too much, which would still give us safe 100000 instances available. Usually you start getting problems with memory when object count goes beyond 1M instances, which is not the case in EWoM.
It would be interesting to see actual data on memory profiling of Elemental, with proper numbers for each category, including textures/models, 'game data' (stuff it gets from xml) and instances of that data.
- scratch that
I would second this. It might affect mods. If we can push ten times the amount of textures without causing any significant bump in memory usage, that would be useful (and so would being able to load more models as well).
"Realistically, what percentage of people playing Stardock games are still using 32-bit OS's? I"m curious."
Both my computers are running 32 bit OS, and I forced to use a 32 bit OS for my netbook anyway.
If you want to make a 64 bit version of the game, then why not make 2 different EXE.
For modding, one thing to consider could be to only load in memory what the game needs. So that creating a mod does not load all elemental stuff + all the mod stuff.
"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"
I am not really sure about that, let me see ... googleling ... Got it.
32 bit OS can address up to 4 Gig of ram. But since this is adressable memory, you must leave addresses for the video ram and other devices that need memory address. The the amount of memory you can have is 4 gig minus video ram and other stuff which gives in average 3.xx gig of ram.
"Most games work around this problem with unit limits."
I think your problem is that your unit data is too large because you keep the design of the unit within each unit. So each unit must keep track of the equipment and appearance it has.
Instead, you should use unit models which are stored in a separate table and add a unit entry which has a foreign key toward the unit model. This way, you will need to keep much lees information about each unit. In fact you only need to keep track of:
1- X/Y coordinates
2- Current movement points available (the maximum is in the unit design)
3- Current HP (maximum is in unit design)
4- Experience points
There might be a few other things, but as you can see, you only need a few bytes to record the information. The only feature you lose is being able to equip a unit while it's on the filed. But you generally want to reserve that privilege to heroes, not military units.
"The Kumquat engine is highly multithreaded. [...] But it comes at a cost – memory"
Personally, allowing players to change some options would be the best solution. For example, I dont care if there are people working in my city. I could simply deactivate that feature and I save memory and threading.
"Most people don’t connect gameplay limitations to memory."
There is always different solutions that can be used to optimized how the data organized to save memory. I remember when programming "wizardry legacy" that some information were coded in bits to maximize the amount of space required for each tile of the maze. For example the walls doors and grid were encoded on 8 bits:
there was 2 bits for each side : noreath, east south and west.
and the value of these 2 bits could be one of the following combination which means different things:
00 - No wall
10 - Wall
11 - Wall and door
01 - Grid
So in the example above, the first bit was for the wall and the 2nd bit was for the door. But there I realized that it would never happen to have a door without wall, so I changed the encoding to make the 01 combination become a grid-wall that you could see through.
I'm pretty sure Crysis had a 64-bit version as well and that was a few years ago.
Not at all trying to discourage you from optimizing memory usage, however that statement isn't entirely true. The 2GB user space limit is only true on 32-bit OSes, or on 64-bit OSes for non Large Address Aware applications. On a 64-bit OS, any 32-bit app flagged as Large Address Aware by the linker will be given access to a complete 4GB memory space.
You see this in the audio production world fairly frequently since lots of RAM is needed, but you run in to situations where you can't go 64-bit (because some of your plugins are 32-bit and 64-bit processes cannot load 32-bit DLLs) so many of the programs are large address aware. In fact it is something that gamers play with sometimes. The difference between a LAA and a non-LAA app is just a flag in the EXE header so you can get programs to flip it, like LAATiDo. People have used this one Fallout 3, for example, when using large texture addons.
In the case of program development, what you basically need to do before telling the linker to make the app Large Address Aware is to make sure there won't be any problems related to pointer math, that you don't make any assumptions in code that the high bit cannot be 1 in a pointer, for example. If that's all fine you can make the app LAA and it'll work well.
So you can do that is something of an interim solution. That'll give you 2GB of memory on a 32-bit OS, and 4GB of memory on a 64-bit OS (presuming the OS has access to sufficient memory of course). Not as nice as a full 64-bit version, of course, but it doesn't require any major changes, just re-linking the app as LAA.
While people walking around might be cool and immersive, it is only slightly more so than the looped animations we all know and love.
If it comes at the cost of noticeable additional memory and threads (not to mention dev+test times!), it's not worth it IMO.
Omicron1, sounds very cool. Do you have a demo? A detailed write-up of techniques you use in procedural generation + stats on performance. This is especially interesting vs. performance of the "standard OO" way.
Spore is the only game that comes to mind that used Procedural Generation successfully (it's the rest of the game that sucked).
A classic game that is very recent and very popular that uses procedural generation is Minecraft! At least in generating the maps.
Best regards,Steven.
Using RAM is for wusses. I get an enormous blackboard and a piece of chalk. Then I just write down all the bits I want to store. When I say enormous blackboard, it's the size of California. Also, i'd tend to agree with those saying that the unit limits in Starcraft 2 are nothing to do with memory. A mixture of gameplay strategy choice and processing power i'd argue. After all, look at an 8-player game with supcom with everybody at the 1000 unit cap. Yes that's hugely processor and general-resource intensive but supcom also has a rather advanced physics system. And it certainly manages all that on 2GB.
P.S. I'm not suggesting that supcom is the bee's knees. I think it's fun but it's not my favourite rts.
I 2nd Sycraft post.. It's not quite as clearly stated here http://stackoverflow.com/questions/2740308/why-2-gb-memory-limit-when-running-in-64-bit-windows but you can see that it may at least allow those of us with 64-bit systems to have the extra memory be used by elemental with a minimum of fuss (barring the pointer math code trick).
I never even zoom in far enough to see the little people that are using up some of my RAM. The game is not playable at the zoom level required, so why even bother with them?
Real men do their games on a piece of paper with a pencil and then fold the piece of paper over to see if they made their hits.
Real men use dice.
Or for that matter Sr2020 in which a normal game starts out with ~200 AI teams and over 10k units, but honestly its comparing apples to oranges, different graphic levels etc. (sr2020 is probably not the best thing to compare to since it pretty much ditches the majority of graphical memory issues, however every unit has its own calculations to go through in real time.. spotting values etc).
Although I do question in general why TBS games seem to be far more resource intensive than some RTS type games that seemingly deal with a similar number of data sets. This isn't just an issue with with EWOM but Civ.. IV.. and now V has similar (similar in that the mem usage eventually becomes too large and crashes the app) unfixed OOM issues.
Granted EWOM is unique in some aspects (The on the fly customization of troops etc) Maybe the fixed data sets in the games mentioned above(sr 2020 supcom) have a large bearing on it.. or some other dynamic(thats not readily apparent to those not diving into the code) that affects resource usage. But overall if i had to guess.. id say its simply teething issues.. custom engines take time to develop and optimize.
(If you haven't noticed i'm speculating and talking out my arse since my level of expertise on the subject is somewhere between nothing and almost nothing)
There are many great features available to you once you register, including:
Sign in or Create Account
