Optimizing CPU drain.

[Red]

So, I'm curious what practices you use to keep your systems lean in terms of how much CPU power they require (so you can reduce the drain on the system resources.)

One that I've been using is to have basic calculations that are internal (and set manually by actions in each separate state) as "f" for float, "i" for ints, "g" for GameObjects, "c" for components (Unity objects,) etc... Rather than having separate variables declared for every possible use... This seems to help a bit but it does require a little more forethought so you aren't inadvertently passing values that you don't want to have passed... So, say I'm doing a basic iterative loop, I'll have "i" as the count... And when that state enters I'll manually set that variable (if the action that uses it doesn't do so already such as an "Int Operator.") And I tend to toss on a tooltip just to remind myself that it's a local value (just in case I forget or have to revisit that function later after it's no longer fresh in my mind.)

Another that I've been looking into is the template system... That said, I'm not totally sure if this IS saving me CPU resources, but it does allow me to clean up the FSMs themselves and make them much easier to follow at a glance (this is if they're self-contained as I'm still not sure the best way to transfer data out of them other than using globals.)

Another tip that I found on reddit is that it's a good idea not to have too many nested objects each with their own script components/FSMs where you can have one master component control them instead... But I think that's an over-all Unity thing and I'm unsure how much this would save in terms of CPU power (not having pro, I don't have access to the profiler... So, I can only really go on what the stats tell me in the game preview window.)

[Lane]

In terms of optimization, I generally figure if its running fine then there isn't any reason to optimize it. I keep a close eye on my FPS during development and if it sinks 5 to 10 fps while I'm working then I already know that something I've done recently is the cause of the tank. Keeping optimization inline with development makes it much easier to backtrack over prior work.

Other than that, sometimes you just need to track down some issue that only revealed itself by scaling up the game. From what I've seen, this is never the case of FSM complexity (unless you've just got some bad loop or unoptimized FSM...). Normally it ends up being batching, culling, shader or physics based problems, and sometimes polycounts.

Using the profiler makes narrowing down problems a lot easier, making scenes just for the sake of profiling things and slowly start isolating the problem while watching the profiler results seems to be a good workflow for me.

In the past I didn't think much about optimization, like maybe 'ill just do it later', but that only works on the very short term. Seems like you really need to backup often after you conclude that something is going to stay and just start optimizing how it works and interacts with the other systems or else you'll end up in a spaghetti bowl trying to find a bog down.

You can do some insane optimization, for instance using a single material and texture in place of doing it the easy way with bunches of materials on an object but it ends up being a lot more time to develop. There are some really cool examples of this sort of efficiency, one guy did a small room in UDK that looked amazing and used 1 shader and 1 texture but it was a great deal of work to make it happen.

[Red]

I think I know that UDK scene you're talking about (was it featured on Polycount in the last few months?)

And yeah, I've also used a couple tricks too... One such way is if I need a collection of "key items" where all you ever have is a boolean value of "have it/Don't have it" I've figured out a bit of an algorithm (in my head... not in practice yet) on stashing that as an int value. Basically, each item has a value of one or zero... Each item has it's own unique space in the inventory (so, say "Red key" is always the first item, "Blue key" is always the second.) Then take those boolean values, treat them as binary, collect them together and convert it to an int.

So, eg:

Red key, Blue key, Skeleton key, magic gem, magic book, macguffin.

Player has the Red key, Skeleton key and Macguffin...

So, 101001 would be the "binary" number... Then convert that to an int... 41

The process is a little complicated in encoding and decoding it to apply it to the inventory... And it's likely not the most ideal way of doing it I'd imagine...  but the theory is that it can cut down the costs of having a lot of boolean values for items the player will only ever have one of... Or of power-ups... that kinda thing. (And I'm sure there's probably a way to convert that int to a bin, take the raw value and go iteratively through each digit... So, instead of having to test for each possible combination you could just go "scan first digit... is it a one or a zero? scan second digit... is it a one or a zero?" kinda thing.