No, it's not OK that the game crashes.

[Buttons840]

AI War has always been very stable for me, but in a recent game AI War suddenly minimized and I was presented with a dialog box stating that the game had crashed.  And yet... I could still hear the game running in the background, so I just left the dialog open and switched back to the game, played for a few more minutes (the game was still working fine).  Then I made a backup save, tabbed back to the crash dialog, clicked OK, then the game "crashed."

I wish more applications were so polite.
App: "May I please crash?"
User: "Just give me a few more minutes to finish this fight and make a backup save."
App: "Ok, no problem."

[x4000]

That's wild!  It must have been some component of the unity engine that crashed, but clearly it wasn't impacting the actual gameplay logic.  Did the sound cut out or something?  Maybe it just had the sound subsystem die?

That's one of the things I like most about unity, is how compartmentalized a lot of their subsystems are: when we start having unhandled exceptions in game logic it rarely completely crashes the game; it takes an out of memory exception or infinite loop to really kill it with no way to back out, usually.  But most of the time if you're getting some sort of external popup (which is unity, not us, by the way), then that's a sign that it's really bit it bad and is toast.  This is the first exception I've ever heard to that.

[Buttons840]

Interesting.  Well, I was amused by it anyways. 

Here's the dump from the crash. 

[x4000]

Looks like some form of out of memory error.

[TechSY730]

Looks like some form of out of memory error.

...
Is this the secret to huge AI war games, just ignore the out of memory error? 


(OK, I know that would be a terrible idea, as you can't really trust the runtime environment after something like that gets thrown, but it can help you get out of a bind)

[Solarity]

No, I think the secret is to buy more RAM, since is so cheap these days, I remember when 8 meg cost nearly £90

[Mánagarmr]

No, I think the secret is to buy more RAM, since is so cheap these days, I remember when 8 meg cost nearly £90

AI War is a 32 bit executable, and as such can only utilize around 2 Gb. Unless you're doing a TON of multitasking, or use 64 bit programs, 6 Gb will never run out. Even a 64 bit process cannot allocate more than 4 Gb at most.

So having 12 Gb or RAM just means you can have 6 32 bit applications fully allocated. Not one process using 12 Gb. Simple doesn't work that way.

[Hearteater]

Unity limits them to an 800 meg heap if I recall correctly.  So extra ram doesn't let you play 12-HW High Cap sadly.

[Eternaly_Lost]

No, I think the secret is to buy more RAM, since is so cheap these days, I remember when 8 meg cost nearly £90

AI War is a 32 bit executable, and as such can only utilize around 2 Gb. Unless you're doing a TON of multitasking, or use 64 bit programs, 6 Gb will never run out. Even a 64 bit process cannot allocate more than 4 Gb at most.

So having 12 Gb or RAM just means you can have 6 32 bit applications fully allocated. Not one process using 12 Gb. Simple doesn't work that way.

I am not sure where you got that information as it is clearly wrong.

32 bit executables can address up to 4 GB, but due to the fact that windows reserves 2GB for it own use, they are capped at 2 GB. You can make them Large Address aware and get 4GB in a 64 bit version of windows and 3GB in a 32 bit of windows, but only the first is recommended as the second is stealing memory away from windows itself.

Currently the limit in windows for 64 bit executables is 8 TB unless they explicitly cleared the large address aware flag then it capped at 2 GB, and that is not recommended either as if you are a 64 bit executable, you should know how to handle 64 bit memory addresses.

Physical hardware is not quite at 64 bits, so you are limited to only 4 petabytes of Physical memory. And to put that number to scale, AT&T transfers about 19 petabytes of data through their networks each day.

Also we should throw in the fact that due to the unity engine they used as I found out, they are limited in heap size to well I don't remember exactly, I think it was 500 MB, and that heap is what runs out in large games. And 500 MB is a lot easier to hit then 4 GB, if they were a proper 32 bit executable running on windows x64. They don't have the large address aware flag set, so they are limited to only 2GB, should be more then enough if it was not for Unity's own design issues. 2GB is a lot of data, and it not as easy as you think to fill it up with things that are not textures, video or extremely baddy handled music. Provided you do proper garbage collection that is.

[Mánagarmr]

*lots of hard facts*

*schooled*

[x4000]

Also we should throw in the fact that due to the unity engine they used as I found out, they are limited in heap size to well I don't remember exactly, I think it was 500 MB, and that heap is what runs out in large games. And 500 MB is a lot easier to hit then 4 GB, if they were a proper 32 bit executable running on windows x64. They don't have the large address aware flag set, so they are limited to only 2GB, should be more then enough if it was not for Unity's own design issues. 2GB is a lot of data, and it not as easy as you think to fill it up with things that are not textures, video or extremely baddy handled music. Provided you do proper garbage collection that is.

Couple of notes:

1. It's about 800-900 MB of heap space that we get before unity cracks up.  That's referring to the mono runtime and just things like strings, game data structures, etc.

2. Unmanaged memory in unity actually does use the large address space extensions, and so can address 3GB+ depending on your OS.  That's where all the graphics, sound, music, and so on go.  That part is nowhere near problematic on most machines, unless you simply have very little RAM and also don't have swap space set up so that windows can shuffle it's own RAM usage into the background while you play.

3. For a superlarge game of AI War with lots of data structures, more RAM indeed would not help, as you say.  Unity would have to increase the effective max heap size in mono.  A simple doubling of it would work wonders, because there's a certain heap overhead that is always used (about 200MB), and then the rest is just whatever is used by the game at the time.

4. However, even more to the point, unity could just solve most of our problems by making the GC not suicidal.  It's almost never the case that we try to use more heap than is allowed in terms of permanent allocations.  The problem is that when unity tries to allocate more than the allowed amount of heap, its response is not to do a GC collection and then allocate -- it's response is to crash.  Which is, of course, insane.  It has the RAM right there and free, if only it would do a GC collection before the allocation occurs.  So instead of unity seamlessly handling that, we basically have to run interference on the GC and do manual collections when we see that the transient allocation is high enough and we're about to do something that requests a big block of transient memory.