I am developing an XNA game for Windows and have it available on Steam Early Access. I have a problem where the largest of my sandbox maps always run out of memory at one point and crash.

Since I am at the end of the road with optimizing, and the maps are popular, I have made a plan to migrate the project to MonoGame and offer a 64 bit version that will include larger maps than the 32 bit version, since a 64 bit program has a lot more memory available.

Visual Studio Express can compile to x86 (32 bit), x64 (64 bit) and "Any CPU".

My guess is I should avoid "Any CPU" and instead compile 2 times, one for x86 and one for x64?

On Steam, should I make the 64 bit version the default, and offer a 32 bit version as a separate branch, that can only be accessed from the "betas" menu? Or can the Steam store offer separate links for 32 bit and 64 bit, like they do for different OS versions?

You can do either, as I imagine most of your customer base is using 64-bit OS.

But if you plan on keeping the 32-bit version around as an option you will need to fix your underlying issue of using more than your address space.

PC games frequently rely heavily on virtual memory and it lets programmers get lazy when it comes to resource management. You need to keep your memory under control so it fits in available space. Exactly how you end up doing that is up to you, probably using methods to stream content in and out as needed, flushing old or unused data.

This is a simulation game where the entire world is simulated at all times. So it is not possible to get rid of content. The only feasible way is to limit the size of maps and/or entities/agents.

Are you saying it is possible to compile 1 version instead of 2? Because that would make many things easier.

I found this discussion on compiling for "Any CPU" vs. 64/32 bit:

http://stackoverflow.com/questions/516730/what-does-the-visual-studio-any-cpu-target-mean

It seems I can get away with offering 1 version. I just have to detect the system ingame so I can restrict the large maps to 64 bit systems and thereby prevent out of memory crashes.

This is a simulation game where the entire world is simulated at all times. So it is not possible to get rid of content.

I would be surprised at any game that could generate that much world simulation data. I can easily imagine models and textures crossing that, as we routinely do. Models and textures are among the easiest things to swap out.

But you say your simulation is huge. The size of our largest world segments with several hundred thousand objects is double-digit megabytes, most stay in single-digit megabytes.

If your simulator objects are a significant volume on a PC game I'm certain you just discovered an area where a little cleanup could go a long way. Keeping the game world small and streamlined doesn't just save memory, but also reduces processing time and improves cache effects.

I found this discussion on compiling for "Any CPU" vs. 64/32 bit:

http://stackoverflow.com/questions/516730/what-does-the-visual-studio-any-cpu-target-mean

It seems I can get away with offering 1 version. I just have to detect the system ingame so I can restrict the large maps to 64 bit systems and thereby prevent out of memory crashes.

I tested "Any CPU", then looked at Environment.Is64BitProcess in the debugger and it shows the process is a 32 bit process. It probably prefers 32 bit because it gives higher performance.

I unchecked the "Prefer 32 bit" option, so it now runs in 64 bit. But now the Steamworks.NET dll fails to load with a BadImageFormatException.

If your game doesn't actually run in 32-bit mode, shipping a 32-bit client doesn't make any sense. It's just going to generate negative reviews, refund requests, and cost you new customers/goodwill with existing customers. If you aren't going to fix your memory usage, just don't ship an x86 client.

I believe you indicated you are targeting windows-only. If so, an easy solution might be to enable PAE. However, that's a band-aid.

I would be surprised at any game that could generate that much world simulation data. I can easily imagine models and textures crossing that, as we routinely do. Models and textures are among the easiest things to swap out.

I echo this sentiment. Unload your geo, and leave only your simulation in memory. If you can't do that, separate your render targets from your simulation targets, and then do it.

For expensive simulations that can't be maintained in real-time, it's pretty common to to execute interleaved updates; IE - even frames only update half of the world, and odd frames update the other half. You get half as many updates, so use twice as big of a time-slice per update (and obviously you could split that into 3, 4, n... groups as needed). It's also a common practice for exceptionally large simulations to save off parts of the simulation to disk which are not currently interactive (in your case, not visible on the screen), and stream those in periodically for their update. You may only get one update per second on a given section of the simulation, but the end user isn't going to notice that for things that aren't currently interactive anyways.