|Green wireframes indicate colliders.|
|My list of systems that had physics colliders, and what they interacted with.|
Colliders that don't touch other colliders, or don't move, don't cost much to maintain. However, the more contact points colliders have, the more expensive the calculations get. In Eon Altar, before optimizations, an average level would have upwards of 2000 active colliders, with over 8000 contact points every frame. This bogged the system down to about 10 FPS on a good machine. It dipped to 2 - 5 FPS on crappy machines.
|This is a small piece of E1S2, The Portal Obstinate. You can see the actors, plus colliders all over the place.|
Unity has a pretty handy feature where you can tell it to only have colliders on specific layers contact colliders on other specific layers. For example, the UI colliders need never interact with say, camera colliders because those two systems never interact with each other. Below you can see the default setting in Unity: everything colliding with everything else.
|This is the default, and the default is dumb.|
However, making it system-wide that only certain layers interact with other layers was easy, once I figured out what layers had to interact with what other layers (which was seriously the hard part, as it required a lot of thinking/designing/researching code). Add to that code to ensure certain components are on specific layers to make them designer-proof--because you don't want to rely on the designers (or programmers for that matter) remembering "rules", that path leads to bugs and heartbreak--and boom, you've significantly reduced the number of contact points even for colliders that are overlapping, as they may not contact at all if their layers don't interact.
|A much more sparse physics layer setup. This is slightly evolved from the above diagram, so they may not match 1:1.|
The second trick was to create "Encounter Zones". Giant colliders that turned a bunch of objects in the hierarchy on or off when the party encountered them. The idea being we don't need a bunch of AI or colliders running if the party is nowhere near them. So everything from enemies to traps to loot to interaction points get grouped up in these Encounter Zones, and when the party gets close enough, voila, everything appears!
This caused some other issues, like having to create a method to slowly load NPCs over time (because initializing an actor is really expensive, and if you initialize 15 actors in a single frame, that frame is going to last on the order of seconds), but for the most part it did the job rather admirably.
Adding in that gave us another 200% - 400% performance increase depending on the level, so in theory, in the worst levels, we could have been looking at upwards of a 6400% total framerate increase, but in practice I measured a 3200% increase in some of the worst parts of some levels.
Granted, these are things we probably should have implemented off the bat, so it's not quite as impressive as I'm making it out to be, but that's sort of the breaks when you only had 2 - 3 programmers making an indie game and way too much to do to keep other people like design unblocked.
Sadly, these sorts of optimizations took a backseat to feature work until design was all, "WTF the game runs so slow!" and engineering was all, "Whelp, time to put features on hold/cut them and fix this issue instead."
Not that the situation was anyone's fault per se, but the reason we got into situations like that was partly because we had not enough programmers and not enough time to finish infrastructure versus feature work, and partly that nobody on the team at the time had shipped a product from scratch, so we didn't necessarily know we'd hit these situations--though I'll be honest, the physics overhaul had been on my list for months and it was just a matter of waiting until it was unbearable such that I could tell folks to leave me alone while I worked my magic. It also ended up being easier, I think, that most of the systems had been implemented and I could holistically solve the system instead of doing it piecemeal over time.
But at the end of the day, it got fixed up, and it's super solid now. Programmers have to remember that new components with colliders need to have their layers thought about (and we have a wiki with guidelines and instructions), but designers can just use the tools and it all does the right thing, which is pretty awesome.
#IndieDev #EonAltar #GameDevelopment