End of the-year-that-shall-not-be-named Recap + Operation: Optimization-Complication Amelioration

Unfortunately, there really isn’t a whole lot to recap for this, the-year-that-shall-not-be-named. Which isn’t to say I didn’t get anything done, I actually accomplished some pretty important stuff, most of which was optimization.

I mentioned last devlog that getting a whole island’s worth of stuff running was causing optimization problems, which wasn’t unexpected. I had a little over 1300 tree objects all running random timers that then spawn some other object (leaves, fruit, etc..). It was eating a ton of memory and killing the frame rate.

Since then, I’ve started switching the relevant systems from an OOP (object-oriented programming) approach to something more ECS (entity-component-system) based, which I figured would happen eventually.
(For now, I’m using my own approach which leverages asset blackboards from the visual-scripting asset I use (Flowcanvas), but at some point, I may end up using Unity’s built-in stuff, or more likely, rewriting my own (twice).)

What that means, is that instead of trying to draw 1300 tree meshes and run 1300 spawn-timer scripts, there is now ONE tree mesh being drawn 1300 times and ONE spawn-timer script running 1300 times.
Now all the game objects have NO scripts- they’re simply collections of variables for various systems to use, which makes them super light in memory and makes it so increasing their numbers has almost no effect on performance.

Here’s 1300 timed spawners, all spawning in the same location for fun testing

But that can still get kinda heavy, especially if I want to have more than just this set of trees in my game (and I do!). So I’ve also implemented a distance-based update system (similar in concept to a LOD rendering system) so that objects near the player are updated constantly, but objects farther away take turns updating far less often. In this way, only the nearest 20 or so trees, plus maybe 20-100 others at various distances, are having their scripts run each frame. (An object’s actual update speed is used to calculate any changes, so from the player’s standpoint, it’s no different than if all 1300 scripts were running every frame.)

Currently, I’m working on applying this same distance-updated setup to all the relevant systems and I’ve already applied the same concept to rendering large numbers of objects using Unity’s DrawMeshInstanced.

All of this is pretty huge for the development of Elle, as I’ve kinda had this dark cloud over my head, not knowing if, when I got to this point, I’d be capable of having so many objects running, or if I’d have to find some way to ‘fake it’ (which isn’t at all uncommon for games to do). It was super frustrating and took me forever to wrap my head around (I was supposed to be writing this 2 weeks ago) but I finally did and it’s as good a way as any to wrap up this shit year. And hopefully it means this thing gets into a playable state of sorts sometime next year.

Anyway, I just keep running into things. And then I just keep solving/accomplishing those things…
Supposedly, I just keep doing that and eventually there’s a game. I’ll let ya know how it goes.

Thanks for reading. If you like what you see, give us a follow:
facebook.com/StonewoodGames
twitter.com/StonewoodGames
instagram.com/StonewoodGames

Leave a comment