Hello All! Welcome to a very early December in Review. I’ll be covering the now, the next year, and the heartfelt speech we all expect from company updates at the turn of the year. Stay tuned.
In the wake of last month I still have quite a lot of AI work to still accomplish, fortunately, the general tone of the work is more about elevating the AI’s ability more-so than establishing any functionality at all. I hopped back in to prototype out a very needed, and always welcome in video games “Alert but not Engaged” behaviour with the AI. It’s a bit raw still, but works. When you fall into the awareness of an AI, they will become alerted to you, and do an alert action. Look at you, make their way over to where they saw you or heard you, and then if they maintain focus on you for long enough, they’ll finally recognize you and engage you as an enemy. Awesome, it paces things out, it allows you to try sneaking around, allows you to react to AI and break away before you’re found out. All the stuff that that functionality allows in game play. Turns out it’s a very common one because it serves a very specific purpose. And it does that here too.
Yeah… no… I still had something pressing that wouldn’t go away just from me ignoring it. One of the features of my navigation tool, navmesh cut, was non-functioning in the version of the Unity Engine I chose to upgrade to. This had been a looming pressure over me since I upgraded the engine last.
At first I implemented “Dynamic Avoidance” in my AI’s. This meant that they could coordinate with each other and alter their direct trajectory to move past their companion, or enemy, instead of just mushing against them ignorantly. This, however, did not work with static, un-moving, objects. They are dynamic when you pick them up and throw them, but if they lay there in the path, the dynamic box and the AI cannot coordinate passing by each other, and if the box is in the way point of the AI, it’ll struggle and press against the box to get inside of it to verify it got to it’s mark and then begin moving on to the next way point. AHHHHH!!
December, and the year end, is always a very turbulent time, of deep upheaval. Seeing the end of the years loop, and the promise of an entire following year, people are provoked to change things, end things, start new things, take action, or anything else to prevent the next year from being more of the same.
In honour of times of such massive change, I signed myself up to do ANOTHER engine upgrade. Right. Now.
In honour of really smashing everything apart and sacrificing the comfort of what has been, I opted to make the upgrade all the way from Unity 2021 to Unity 6. A.. 3? year hop forward. I was basically expecting my project to be burned to the ground.
But actually, surprisingly, the migration worked out FAIRLY well. Physics collision/triggering handling had changed since 2023. Cinemachine, Unities advanced camera system, stepped up a version to Cinemachine 3. And a bunch of my assets needed to be updated to support U6. After some fussing, I managed to get things pretty well in order. I was finally able to get obstacle avoidance working with my AIs.
So. The idea is. When you drop a block in front of an AI, and your block cuts a hole into the navmesh. In most cases your AI has already been given a path that doesn’t know about that newly cut hole. This means that your AI will STILL stupidly walk right into the block and become stuck. Argh! BUT. If you put a little probe that shoots out a tiny bit in front of them, when they stupidly walk into the block, this hair will touch the block and trigger a re-plan. This makes the AI plan a new goal, or at least a new path, and they’ll then walk past the block as though they knew they should have all along.
Yes! Finally. They can avoid each other, avoid random things in their way, get to where they need, and do things that actually make them feel kinda sensible. What an ordeal to get this far.
Yes, I’ll definitely need to return to the AI soon, but after over a month of prioritizing it above all else, I really need a break.
The reason I was grilling AI functionality so hard is because I have been inching towards doing the actual content, and substance, pass at the game world and gameplay. The stuff I hinted at back in October. However, with big gaps like AI not working at all, I’ve had to sideline the experience building for systemic building. No longer, it’s time to build some play! Almost…
Firstly, and very exciting..ly, the side effect of upgrading to Unity 6 was that my Navmesh system was massively improved performance wise. Additionally, I was able to utilize an updated form of my vegetation instancing system. This brought the world generating process time from 50 seconds, down to 20 seconds. I am now able to push the scale of the world even bigger to make for more of a sense of a journey, rather than a small sandbox you can walk from end to end in a few minutes. Yusss!
But with that world scale, new issues arose. Ones in the matter of what the industry calls making a feature able “to scale”.
It is common knowledge that you should never optimize before you need it. Optimizing too soon can spend a lot of time on something that may not stay in the form you were optimizing it for, you can over engineer it and make it either too generic, or too specific, because it may have not been tested against real use. It can also be as simple as, the project is small enough that anything that runs it can really deal with a sloppy game regardless of optimizing it or not.
There is always something you should do incrementally throughout development.
These two things will highlight major issues before they’ve been entrenched in new code and new contrivance in your project, and will also allow you to improve chunks of your systems that may be particularly non-optimal.
I had a pretty awful time early this month where my Terrains would not render in Build. The only solutions online are for an old issue with having your Terrain set to “Draw Instanced”, something you can only utilize if the material/shader you’re using is capable of doing instanced Terrain rendering. Apparently the default Unity terrain material does not. /shrug
BUT. This was something I resolved long ago with my previous engine update. So this new issue, a major blocker, was mine alone to resolve.
Of all things, an accident ended up revealing the issue, after 2 days of non stop problem solving. It turns out my Terrains would fail to render because I load in the level with most of it disabled, then activate portions of the level over time, and over the generation. For whatever reason, loading the terrain as one of the first things after loading the level would cause it to never be able to render… so by accident I left a terrain outside of my deactivated level chunk, enabled right off the load level bat, and it rendered fine.
This was one of the worst things that has cropped up in this project in recent memory, but it only appeared on my radar because I tried to do a build after I had mostly secured my engine upgrade. Exactly why you need to try builds regularly. In fact, professional studios are constantly building their games using automation, to reveal the exact updates that contributed to a build failing. QA (Quality Assurance) Teams test the rest for any runnable issues.
So my world actually renders. I can now actually play the build, move around, do whatever… And it feels a little stuttery. Not by much but not pleasant when looking through densely forested areas with tons of leaves, bushes, sticks, rocks… all that noisy stuff. Time to pop open the Unity Profiler.
In profiling, I finally started to see MY code floating to the top of things that were causing an enormous overhead to the per frame processing of the game. As a rule of thumb, 33ms frame times are considered comfortable, with 66ms a bit problematic but okay if you’re in a particularly high load situation. It’s where you’ll see your game stutter a bit when you’re scrubbing your camera across a part of the game with tons of particles, models, characters, or the vast majority of the volume of the level you’re in. Unfortunately for me, I was floating steady at 66ms.
So the first things that revealed themselves is, due to scaling up the size of the world, and doubling the mock “outposts” I had copy pasted all over the map, there were a couple thousand dynamic boxes and rocks and things that were updating every fixed update. “Fixed updates” are what is used in Unity for Physics. They run multiple times inside a single frame update to make for smoother more precise physics calculations. In most cases 60 physics updates per frame. Well, the physics updates were necessary when you are tossing a dynamic block off the ledge of a building onto the head of an unsuspecting enemy. But as they lie there, there’s no need for my systems to be updating that much. Well, turns out scaling that to 1700 dynamic blocks does a REAL number on your frame rate.
So first solution. I made a component that updates every Update, (once a frame). It checks to see if the physics are “asleep”, meaning they’re still and just sitting there. When that is the case, it will disable my various physics updating components. When the physics are awake again, it’ll turn the components back on. Sadly this solution still updates every frame because there was no way to receive an event for when the physics sleeps or awakens. But, taking 1700 objects with 2 components that update 60x a frame (1700 * 2 * 60 = 204,000 updates a frame) out of the mix does a lot better than the burden of 1 update a frame that this utility script fix causes.
The observer pattern is where a component can send out a message (an event) that says “Hey, I did this thing”. In other scripts and code, you can subscribe to getting e-mail updates about when that script did that thing. And when it comes in, you can respond by doing something related to that event happening.
In unity its called Actions, and UnityEvents. In Unreal it’s called Delegates (actually Delegates are the actual thing events are). In Open 3D Engine, the entire engine is built on events, with their ebus system, and script events.
Events are incredibly powerful. They allow you to only react when the thing is actually happening, rather than, as I indicated above, checking for a changes every update over and over when you’re only looking for a very precise moment that something will happen.
Because the other high load on the games frame rate was caused by the spawners that handle the thousands of items that generate into the world. They too were checking for changes to happen every update. In this case it was “Is the item picked up? That way I can start my respawn timer.” Pretty small and innocuous, but multiplied to thousands of items… it starts to get out of control. Fortunately in this case, I had power over both the spawners and the items they eventually spawn.
Returning code I had already implemented into Del Lago Layover back to Awakened Guardian, I created an “OnPickUp” event on the item, and now, upon spawning the item, the spawner would register to that event, and only handle its respawn logic when it fired. This cleaned out thousands of updates that run for tens of minutes of non-activity, waiting for the one moment that the item gets picked up. An incredible gain, and such a simple fix.
No no no no, optimization is so cool. So, where my game was running, in build, at 66ms per frame. I didn’t just reduce it to a comfortable 33ms, I dropped it all the way down to 16ms steady. That’s 16 milliseconds. 16 thousandths of a second to show a 2km squared game world, sky, thousands of trees, bushes, rocks, and grass, thousands of items, thousands of 3D models creating hundreds of outpost camps, our champion the guardian, and handling thousands of physics checks 60 times a frame. So 60 times every 16ms.
Now the only big load on the games performance was that of rendering the 3D models, which there were multiple thousands of due to me doubling the doubled Outposts. Something that I did simply to really exaggerate the graphical burden and navmesh processing burden. The level generation STILL takes 20 seconds to do.
So so so cool.
The game runs like greased lightning. The levels generate in the blink of an eye. I have a brand new loading screen with loading bar to share all this lovely progress right to your eyeballs. We can now build.
I am now in a position where I can begin to carve out a Vertical Slice of the game. Have an introduction to the world, a tutorial to get you familliar with acting within it, some plot to call the Guardian to action, and a world to begin exploring and acting within.
My vague Roadmap on the way to VS is this:
Lots to do, no ceiling to the amount of work I could be doing now, until then.. and beyond…
As I expressed above, this time of year is one of immense upheaval. Lives are changed, jobs are quit, or lost, life changes manifest in almost any way, even completely imposed by others experiencing their own changes.
Genome Studios has always been a mindset to me, it’s focus on creativity, and how that creativity strikes its audience with sincere emotions and experiences, is the genome of what I consider human art forms to be about. That humanity has always been the true reason for forming the company, and operating it as transparently as I’ve tried to. Expressing fallibility, showing the true complexities of the art forms, of acting in the business environment, and the toll it takes to take part in this career path, and industry, are an absolute necessity in showing that humans are behind making these projects, and humans are the intended audience for the media that we produce.
These past few years in the video games industry have been brutal. Massive culling of jobs, the unbelievable instability in AAA studios due to the complete lottery of what games reach critical reception, many of which are random indie projects that never intended to be big in the first place, the rise of new studios and collectives seeking finite funding sources stretched to their maximum, and more.
Likewise, the general world we all experience now weighs so heavily on us every day. It’s nothing that could be said is a first for humans throughout history, but because its in the here and now, its so tangible and burdensome. It’s devastating to see others struggle, to see opportunities shrink, to feel unable to contribute or help towards alleviating personal hardship, social injustices, less-than-just behaviour across so many human lines, and more.
So at this time, in light of these many forces that weigh on us today, and will certainly weigh on us in the new year, I ask you all to consider how this moment of upheaval and change can be skewed to the betterment of others, the evolution of yourself and others, the growth of opportunity, the support in the face of uncontrollable hardship and grief, and set our trajectory towards growth, nourishment, and thriving, deep into the new year and the next years to come.
Here’s to that kind of year.
Here’s to a year of more Months in Review.
Thanks for reading, and for your support.
See you January. Happy Northern Hemisphere Winter.
