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.

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.

While it may not be considered a major game any more, I believe there's a 64 bit version of Half Life 2.

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.

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.

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.

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.

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).

I'm pretty sure Crysis had a 64-bit version as well and that was a few years ago.

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).

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 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 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)