The pursuit of phase Paranormal Pickle continues as I round off another development milestone this evening and creep closer to something that is actually, really, starting to look like a game.

I will preface all of this with a bit of an anecdote on digital frugality.

In this era of the robust availability of processing capacity it is easy to find people discussing frame rates and generous graphical outputs derived from access to huge quantities of processing power. The advantage to using a game engine is that I can work under the assumption that the people who built both Rust and Bevy have considered things like memory management and processing pipelines so that I don’t need to think too much about either.

I mean, a little bit. I need to think about it some.

But I was overthinking it and as I develop this game which has a very retro architecture and two-dimensional 8-bit vibe, I may have been leaning into those thoughts a little too agressively. 

I found myself doing some back-of-a-napkin calculations about what a very conservative number of simultaneous processes and active game systems might be. Then I searched for something similar, looking for confirmation of my math maybe. And then I outright asked an AI bot what a modest number of live processes and spawned objects and active systems might be for a game written in Bevy and Rust.

See, I had opened up my inspector tool and having spawned these generous tile-based rooms and layered those rooms with decorative objects and then animated those objects and then added collision to a bunch of those objects and then added a bunch more UI objects on top of that and all that was just to show the world and not actually calculate the game mechanics itself, I had come up with a number that to me looked daunting. At any given time, it turns out, I had somewhere between 1500 and 2000 spawned objects and systems.

To be clear each of those systems might be very, very small. Displaying a 64×64 pixel sprite at position X,Y on the screen. Doing a simple geometric calculation. Incrementing a number in a counter. Saving something to the database. All small, but add them all up and you have (a) a game and (b) a lot of systems that run in a continual loop about a couple hundred times per second each.

So how many are too many? I mean, I keep adding stuff and hoping that the game doesn’t suddenly drop to three frames per second because I’ve hit some limit.

Well, the answer I got back from my back-of the napkin calculations suggested that I could probably run the game at 120 fps if I kept that spawned number under 25,000. 

If I got up to 100,000 I was going to start noticing it eating up the processor, and if I happened to hit a million I may want to consider doing some optimization.

The internet, AI, and everything else vaguely confirmed this.

So, to be clear, even at my biggest, sprite-filled, action-packed room state, I was running at about 8% of my most conservative everything-is-humming-along estimate.  I mean, the proof is in the pudding, but the moral of this story is that I can probably stop being so digitally frugal and add a bit more life to the game.

Which is exactly what I’ve been doing.

I wrote a whole post on building my menu system (which to run compared to the game-proper processing power requirements is like comparing a pedal bike to a Harley motorcycle) so I won’t go into detail on that here.

But I have also been doing a lot of design work. This phase was about furnishing and decorating and I’ve added a whole couple of categories for Things That Appear on the Screen (TM) like simple A/B state decorative objects  and this thing I’ve called lively decorations which are actively animated as part of the universe (slurping up some of that spare processing power, of course.) 

In the background and to facilitate all these things I’ve had to implement and polish up a bunch of actual game systems, too. I mean, I wrote already about the game state stuff which facilitates the switching around between menus and the game, but I also added a clock to the game. The clock, of course, has a game built in, but it doesn’t specifically track anything besides a kind of this-app-has-been-running-for-this-long seconds counter. I added a clock in the sense that the game now tracks a 24-hour game cycle of days, hours and minutes. And not only does that time clock save routinely as part of the game state database save file, but it now makes the game feel like time is actually passing. You can open the menu and it now says something like “it’s 8:43 on day 2” of the game—which having a time clock might be important to things like having a store with open hours.  My kid asked me if I was going to make it so you need to sleep (a’la Stardew Valley, which I admit is a bit of a back-of-mind influence on a few of my design choices) and this is starting to make more and more sense, particularly if I will need to have a bunch of “nightly” calculations happen to my grocery inventory.

So as you can see, things are taking some real shape here and chugging along a game is almost, kinda, sorta appearing. That feels real nice.