Hello once again. I am back, and what better project to sink my teeth into with Tales From the Herd than perhaps one of the most boring and frustrating: optimizing the game. So if talking about framerates, distributing work loads, and ironing out "frame spikes" sounds like fun to you: buckle up. And if it doesn't... see you next month lol.
As a reminder, this Patreon does not charge monthly, but only after the release of "Milestone Builds", of which I am currently working on the 2nd. Expect that build in at least 4 or 5 months, yet.
So – what are some of the ways you can optimize a game? You can streamline inefficient code, minimize read/writing to the hard drive (save/load operations), use lower detail models when far away from the camera or cull them out completely; there are of course many, many ways to improve the efficiency of a game's code and graphics.
In May, I began playing around with and utilizing one technique in particular:
As you probably already know, a game usually attempts to run at a fixed framerate of something like 30, 60, or even 120 frames per second. This means during any one of those given frames, many tasks are performed, math crunched for physics, and visuals rendered to the monitor for the player to see. Ideally, you don't want to overcrowd a frame with too much work, which is where the first problem I identified with Tales From the Herd is:
(Excuse my quickly and roughly drawn demonstration here)
When entering a new scene in the game (like the Village), TFtH would normally process a ton of information and work on literally the first frame, effectively freezing the game up for at least 6 seconds or more on the loading screen. You can observe this by watching the "loading" text at the bottom right corner, and how it would pause animating for that duration. This is because as soon as you'd enter this new scene, the game would read save data from the hard drive, find or spawn every character into the scene and enable all of their behaviors, generate the entire village, etc.. And it would cram all of this into just one frame.
The "simple" solution then is to break up this process, so that each task is performed on a separate frame, like so:
Now, that 6 second spike where the game freezes might be broken up into a dozen or so much smaller (and hopefully less annoying) bumps in the framerate. Tasks are no longer competing so much for each others' time, essentially.
The IDEAL world would be one where there are no spikes at all, and every step you take in the village, and every loading process that happens with or without your knowledge happens so efficiently that your experience is completely unimpeded. But unfortunately, some of these tasks are brutal enough on the hardware that even by themselves they cause a hitch in the framerate. This will require more individual attention on how I'm performing them in the future, and if there is a cleaner alternative I can replace them with all together (that's probably a yes, considering I've never gotten this far with a coding project before).
It's funny, this by itself was days of work, and required restructuring at almost every level of the game's logic – and its effects I imagine will go completely unnoticed. But the game is just going to get bigger and bigger, and so I think it's important to lay out this groundwork before the task of optimization seems almost hopeless.
Similarly, I've applied this logic to actually rendering the village acres (or chunks), as well. Now when your camera is nearing them, they will load in the objects and other visual elements bit-by-bit, instead of all at once. In slow motion, it appears like this:
Again, though, if it's doing its job right, you would never actually physically witness this. You just might notice its effects, smoothing out the framerate a little while running around in the village.
Once more, the same distribution has been applied to sticks you buck out of trees. Previously if you had spawned in like, over a hundred of these things, it would make a pretty substantial hitch in the frame pacing when you got close enough for them to render in. Now however, these hitches should be almost entirely removed.
I noticed items like this were also making redundant save calls, which itself can cause some gross performance issues. Now, these sticks only have their data saved when absolutely necessary, such as when the player changes their position by picking them up.
Just another trap a lot of new Unity devs fall into from what I've read. But a few functions that seem really easy and convenient at first, are actually quite taxing and should be avoided wherever possible. One of these is GameObject.Find, which searches the entire scene for the requested game object and allows you to save a reference of it. I don't know exactly how it works, but I'm guessing the clue is there in "entire scene", meaning it looks through a lot of unrelated objects before getting the right one.
Instead, most objects in the game are now properly given specific assignments by "managers", fancy overlord scripts that have a better understanding of the scene, and communicate with one another to find what they need without greedy operations like GameObject.Find.
A few players mentioned not liking that the game still tracked your mouse position while you're tabbed out – so now you can actually change your fullscreen mode to "exclusive" in the game's visual settings. When tabbed out with this enabled, the window will be entirely minimized, and ignore the mouse completely. Using this mode might also help squeeze a little extra performance out for you, as well.
Oh and if you've downloaded patch 1.1.12 in the past few days, before patch 1.1.13 was launched, I would recommend upgrading. It's nothing major, but I fixed a really annoying bug in 1.1.12 where the talk icons would not properly display for some reason.
I know it might be frustrating to not see any new gameplay additions this month, but like I said, this kind of stuff does need to be handled at some point. I'm sure I'll go back and streamline these processes even more in the future, but for now, I also would like the opportunity to work on something "fun".
This is the last major patch for Milestone Build 1. There may yet be bug fixes made, especially if players discover critical ones, but any new gameplay additions will be saved for the upcoming Milestone Build 2.
And what's first on that list? I think I'd like our little ponies have gone long enough without food, and would like to give them some snacks to eat. I believe I have some neat ideas on how food will interact with other systems in the game, but as promised I'm not turning this into a survival sim or anything. There will be no punishment for fasting, as I'm much more interested in enticing players with rewards, more than frightening them with consequences.
Zv'n
2025-06-08 15:43:03 +0000 UTCZv'n
2025-06-08 15:41:35 +0000 UTCGolden Stem
2025-06-08 01:36:23 +0000 UTCGolden Stem
2025-06-08 01:33:49 +0000 UTC