Here’s a summary of what I did in the last two weeks
Art
I wanted to make a dark/cinematic/creepy render with the robot model, so I did. I used foliage from Megascans, and most of the other stuff aside from the watch tower is from old models. I rendered it in Unreal instead of blender this time as an exercise, and I’m satisfied with the result. The volumetrics was a bit tricky at first, but I got the hang of it eventually.
Blockout
I made a few “cube decorators” like windows and walls and roof tops to help with the blockout process. I came to conclusion that blocking the environment out in Unreal is much better than doing it in Blender despite being a lot slower (at least for me), because the sense of scale is conveyed better in Unreal and navigation is better for large scale. Being slower is an acceptable downside if it means the quality and vision is better.
I used these to make a very small portion of the village. I’ll spend more time detailing it and expand bit by bit.
Save System
I spent more time on the save system. I wasn’t really happy with the performance, even in the worst case scenarios, so I spent some more time optimizing it. I managed to reduce the save time from 100ms to 25ms by moving all the logic into a centralized system inside Game Instance, therefore there are less checks and conflicts to perform. Now instead of the objects writing the save data directly, they send a request to the save system in the Game Instance, which will do the saving.
In addition to that, I implemented deferred savings, where the system keeps track of the save requests, but doesn’t write them immediately to the save file. Instead, writing the save will be triggered under certain conditions (eg. every 5 minutes, after cutscenes, when you exit from the menu, pressing a designated save button…etc). This means that operations that trigger a save (eg. door opening) will no longer cause a stutter.
There are a few more ideas I have in mind for the future, like implementing a “clean” and “dirty” save. Dirty saving will only add/update entries to the save file. It will be faster than clean saving, so it’s only useful after cutscenes and during gameplay, where stutters should be minimized. Clean saving will sort everything alphabetically (by identifier name) after finishing the save, so there’s an upfront additional performance cost. If the save file is flagged clean (therefore all entries are sorted alphabetically), a binary tree search can be performed on it, reducing future load time. Clean save should only be done when quitting the game or loading a new game, because it will stutter. This would only make sense with a lot of entries (+500 ?), which shouldn’t be the case. Realistically I don’t anticipate more than 200 entries at any given time, so I will not implement this unless I really need it.
Animations
I experimented a bit with Animation blueprints and State Machines. I added a “land” animation, which only triggers if the player’s velocity in the Z axis is large enough. Player movement is disabled when the landing animation plays, I used Anim Notifies to fire a “disable movement” and then “enable movement” events.
Jumping is now delayed by about half a second to allow for a jumping animation to play. It’s a bit awkward, but at least now I know how to animate a character in Unreal.
Another fun idea I had was the dizzy stars when the player gets dizzy. So here it is.
I restored the “look at” function again with the new model and rig. It was a lot more complicated than I had anticipated, because if the limited and weird mechanical movement of the character. I had to rewrite the entire logic for it and improve the behavior while I was at it. It wasn’t bug-free though
I fixed that, then I also added a few features that made it more natural : running disables looking at objects of interest, while walking reduces its intensity. When you stop running, the character will slowly look at the target.
As a side effect of the rewrite, the “head shake of disapproval” bug is no more. However, the “head shake of disapproval” feature is implemented. I just added code to check if FPS is below 5 and cause the head shake to happen.
NPC AI
I started experimenting with NPC Behavior/AI. It wasn’t as hard as I thought it would be. I created a blueprint for NPCs, which I will eventually use for all NPCs, and I added some AI logic to it. It’s nothing special right now, but I implemented a few types of behavior : follow, patrol, random patrol, idle, and lead.
Patrol means the NPC will go from waypoint to waypoint sequentially. The waypoints are just a custom blueprint actor with an array of coordinates, nothing fancy. There is a minimum and maximum wait time between waypoints. If the min is 1 and max is 10, the NPC will wait a random time between 1 and 10 seconds when they reach a waypoint before moving to the next. In the example below both values are 0 so there is no wait time.
“Random Patrol” is very similar, but instead of following the waypoints sequentially, it goes in random orders. THe min and max wait times are non-zero here.
The “follow” mode does what it says. In the example below, the first NPC follows the player, the 2nd follows the 1st, the 3rd follows the 2nd…etc. This creates a long (T-pose) conga line.
The previous tests were all using simple targeting, the NPCs only move in a straight line. But I experienced with navmeshes and changed the code a bit to work with it. The NPCs can now navigate complex layouts and avoid static obstacles.
With all that, I wanted to try having several actors with the “random patrol” AI mode and see how they’ll behave. It looks surprisingly natural for how simple all of this is.
I added a “set AI Behavior” interaction type, which will allow me to change set the current AI type of the actor by interacting with it. In the example you can tell the NPC to follow, patrol, or stop.
Of course I had to make a “backrooms” game, so I put several of these robots in the train station environment and set them to follow me around. I got stuck surrounded in a corner and it created this creepy scene. (I added the creepy audio and sound to add to the effect)
And another fun side effect of the AIs not being able to navigate around each other yet : it looks like they gathered together, which I found amusing.
That’s about it. I did more story writing and backgrounds for the NPCs, which I won’t share here for obvious reasons. Thanks for reading, and I hope to see you again next time!
2 thoughts on “Devlog Week 44-45”
Every now and again I kind of wish you’d cross post on hive so I can upvote so you know I’m reading even when I have nothing to say XD
Looks like things are toddling along nicely for you 😀
I barely even post on the social networks I’m “active” at anyway. I’m basically just treating this like my personal journal and casting it to the void lol
But I appreciate it! No need to comment or anything. Thanks!