Shrugger! Unity!

[x4000]

Well... in general C# coding practices, that would not be great.  In Unity, I think it's not that efficient.  Ideally you want fewer GetComponent calls, mainly.  It's okay to be calling House.Dog.Hair.Fleas.Kill() or whatever, although usually there has to be a REALLY good reason for that many chains.  But it's not exactly inefficient or something, it's just long code.  In your case, I'm pretty sure there is a nontrivial cost to every call of GetComponent, though, and so depending on how many times that gets called per second, it might even hurt your framerate.

[Shrugging Khan]

So long chains are ugly but acceptable, whereas GetComponent() calls are to be avoided where possible. Got it!

There's gonna be a lot more pointers from now on, I suppose.

[x4000]

Yep!

[Draco18s]

So long chains are ugly but acceptable, whereas GetComponent() calls are to be avoided where possible. Got it!

GetComponent, GetDefinitionByName, etc. are generally fairly intensive calls.  I'm using GetDefinitionByName in one of my (Flash) projects right now, but it's a once-off per-run thing to simplify the code for me to write (so instead of saying new Level01(); new Level02(); new Level03(); etc up to Level50, I can just put it in a loop, new GetDefinitionByName("Level"+i)()

Did I also list some of the other things I have for Unity for optimization?

As few particle systems as possible
Texture size (smaller better; sprite sheets better than smaller individual files)
Remove empty animations (this has to do with imported models)
Avoid mesh colliders (if it moves in Unity at all, Unity has to recalculate the mesh every frame when its moving)

[Shrugging Khan]

About the Mesh Colliders; would they be less troublesome if all my meshes consisted of geometrically simple shapes; i.e. a few cubes and tetrahedrons stuck together?

[Draco18s]

About the Mesh Colliders; would they be less troublesome if all my meshes consisted of geometrically simple shapes; i.e. a few cubes and tetrahedrons stuck together?

Combined collission meshes made up of handful of cubes is the way to go about it whenever possible.  Spheres never need recalculation (rotation is irrelevant to them) and cubes are very fast.



Mesh colliders, regardless of how many verts, are very slow to recompute because Unity can't take advantage of the known shortcuts for the simple (cube, sphere, cylindrical) colliders.  It's always best to remove the mesh collider and replace it with a simple collider, even if the mesh is identical to one of them.

[Shrugging Khan]

Alright, I'll take it to heart.

[Shrugging Khan]

So, after another lot of playing around with everything, creating a simple but functional ecosystem and a somewhat crude simulation of plate tectonics, I think I've learned a few things.

More questions!

What's the best way to create a Save Game?
What's the best way to store information that is not needed at present, but might come in handy again later in the future?

And how generously can I initialise variables, lists and arrays without it becoming a resource issue?

[x4000]

Save game: some form of serialization, either binary or via custom string serialization.  Binary serialization can be brittle in my opinion.  So most likely it's like creating a form of flat file where you write out data in a textual format.  There are various approaches, though, ranging from more to less sophisticated.  We use two separate ones in our games, one for high performance and the other that allows hand-editing (aka settings files on the latter).

In terms of your second question, I'm not really sure what you mean.  Storing any information would be via some sort of variable, somewhere.  Either on an object, or on a singleton class, or whatever.  When you need to use the data is irrelevant; how it is logically organized is what matters most.

In terms of initializing variables, lists, and arrays, that's again a pretty broad question.  It depends on what kind of stuff you are doing.  The primitive types all have fixed sizes which you can look up details on in a general C# reference.  Strings are interned, and string interning in general is something worth reading up on.  Arrays vary as to what they are based on if they are primitive arrays or object arrays or lists.

It takes a goodly while to run out of data space, but AI War has managed to do it from time to time.  It's tracking an obscene amount of data compared to any other game I know, though, so I doubt you will have problems.  Things like textures and other graphical data is not stored in the mono memory space unless you have it opened for read/write access on a texture or whatever.  Which is not the usual thing.

[Shrugging Khan]

Regarding the second question, my problem is storing information on procedurally generated bits of world (geology, biosphere and atmosphere, for example, so it could amount to quite a large amount), that the player is not currently close to.  They'd need to be saved in case the player returns there, and parts of that data would occasionally need to be read in order to calculate things like global weather patterns (yeah, I know, not really practical...but let me dream a bit), but otherwise they wouldn't need to be kept around.

Now, I know fairly little of the distinction between hard drive, RAM, virtual memory and god knows what else, so I'll just turn this into an utterly unprofessional metaphor: If a save game is putting something into a chest and burying, so that it's safe and unchanging until needed again, then how could I just put something into the shed, where the smell doesn't bother me, but I could still occasionally check its temperature?

Wait, I don't think that metaphor helped at all.
Never mind, some sleep might be in order.

[keith.lamothe]

Regarding the second question, my problem is storing information on procedurally generated bits of world (geology, biosphere and atmosphere, for example, so it could amount to quite a large amount), that the player is not currently close to.

You can save it to disk and read it back in as needed.  That's what we did in AVWW1/Valley2 with one file for each "chunk" (contiguous side-view space).

That said, I'm really happy our more recent games don't require such a model.  FWIW.


As far as tiers of storage and whatnot:

1) Registers: these are the literal sets of latches (or whatever they're called) in the CPU's arithmetic logic unit (ALU) that are directly connected to the Adder circuit and other such things that perform machine instructions.  So adding two numbers already in registers is generally a single-cycle operation.

2) L1 Cache: this is a small pool of RAM-like (iirc) memory on the CPU itself, physically close to the action and very high-speed design/tech for minimal latency of retrieval.

3) Generally there's an L2 cache that's bigger and slower than the L1.  Some machines have an L3 cache that's even bigger and even slower, iirc.

4) RAM: these are the sticks you actually plug into your machine when building it.  They're much slower than cache (iirc) but can be much bigger.  Nowadays most applications can run entirely in RAM on a decent machine (with 8+ GB of it), though this has not always been the case.  So generally in an app you don't have to worry about anything "lower" than this for actual operation.  But if you need more than, say, 1.4GB of actual data you need to investigate a 64-bit app (not possible with Unity right now, iirc) or some kind of disk-saving shenanigans like we did with AVWW1/Valley2.

5) Disk: the catch-all.  Could be platter-based HDDs or solid state drives, or some combination.  Platter-based drives (the standard until SSDs came around) are sloooooooooow.  Retrieval of information involves actual physical motion of the platter.  They've gotten really good at doing that quickly in the relative sense, but it just can't compare with normal electrical signals that generally move around near c (iirc).  So Solid State Drives are rather nicer in this regard, though they are not without their many foibles (and they can't compete with decent RAM speed-wise, nor are they really intended to in terms of the bus architecture and so on).

I didn't list Virtual Memory separately since that's just a chunk of your disk (HDD/SSD) space carved out to serve essentially as an "overflow room" for your RAM.  So if all the applications currently running on your machine need more total memory than you have RAM, your OS "pages out" parts of RAM it doesn't think you'll need soon to this virtual memory "pagefile".  If your RAM is full and you don't _have_ a pagefile (disabling it is common practice with an SSD, to extend drive life), or your pagefile is also full, expect some fairly messy crashes.  Generally doesn't happen nowadays though.


Edit: whoops, meant to add that as a programmer in many environments (including Unity's available languages), you have neither the ability nor the need to have any idea of or control of what happens with the Registers or Caches.  That's all handled for you, for better or worse.  Your choices entail how much stuff you create (that goes in RAM), and what you write to or read from disk.

[Shrugging Khan]

Well, that's some interesting information either way. So I take it my only real option with Unity and C# is to create storage files on the hard drive, and read from those when necessary?

[keith.lamothe]

Well, that's some interesting information either way. So I take it my only real option with Unity and C# is to create storage files on the hard drive, and read from those when necessary?

For loads of data that you don't think will fit in your available RAM?  Yea, disk.

First thing, though, is to analyze whether you really need that much memory.

[athros]

What's the best way to create a Save Game?
What's the best way to store information that is not needed at present, but might come in handy again later in the future?

And how generously can I initialise variables, lists and arrays without it becoming a resource issue?

Well, that's some interesting information either way. So I take it my only real option with Unity and C# is to create storage files on the hard drive, and read from those when necessary?

I'm writing a roguelike (prototype phase), and I do all of my generation at the start. I serialize all of that into a flat JSON text file, and read it back in floor by floor for persistence. It loads relatively quickly (1-2 seconds) on my iPad, but generation can take upwards of 3 minutes (almost unacceptable - I'm still working on tightening the generation code). Once all of that is done, that's the save file for the game. I don't really know Unity that well. All of this is using Python, and coding on my iPad in an app.

Because the JSON is the save game, I can serialize the state of the game after every action taken, ensuring a consistent state even if the player has to exit for a phone call, different app, whatever. There is no discernible slowdown, and profiling shows it takes way less than a second.

I can't load the entire file without crashing the iPad, so I have to work with a file. If this is for the PC, you might want to look at what you need to store in memory, and then determine how much you want to store above and beyond that.

[Shrugging Khan]

I'm going to have to ask; what is a JSON file?