Getting Dangerous
This week marks the beginning of me finally biting the bullet and taking a first step into the waters of AI and enemies in Maintenance Crew. This week also involved fixing several bugs both related and unrelated to the shift to a Game Mode centric code, so lets talk about those first.
The first and maybe dumbest bug of them all is the emergency departure indicator, which I had working last week, but broke again when I transitioned everything to the Game Mode. This bug took me probably about an hour and a half of googling and mindless debugging to figure out exactly what was wrong. The sad part is the bug was extremely trivial. Before, the lever and the elevator both had a direct reference to each other so they could communicate. When transitioning to the Game Mode, I replaced this declaration on the lever with a reference to the Game Mode, which involved a cast and saving the reference as a variable. This code then further proceeded to get a reference to the Game State to be able to collect the information it needed for the emergency departure indicator. In this instance, I made an extremely easy to make but relatively hard to track down issue. Here’s the original, not functioning code — see if you can spot what’s wrong here:
The Lever Begin Play Event — thief of an hour and a half I’ll never get back
If you don’t see the problem here, I don’t blame you. The problem is that the Game Mode only exists on the server. The output of this code is that the server would see the changes to the indicator, but the clients would not. This is because when the Begin Play would be called on the lever, the server version of the lever would successfully find the Game Mode, make the cast, and move on. The clients, on the other hand, would fail this cast and never bind their events to the event dispatchers at the end there. This lead to the clients never getting their events to update objective progress or the emergency departure indicator called.
When I realized what was wrong here, I had to stand up for a moment and contemplate my competency… Anyways, here’s the fixed code:
Such a simple fix for my hour and a half…
Frankly, having casts that follow each other like that is usually something i try to avoid in this fashion anyways. I guess in the flow state of refactoring everything for the Game Mode I just sort of didn’t really think about what I was doing and it lead to a fairly major headache with perhaps the simplest solution ever. Luckily the other 3 bugs I fixed this week were way less of a hassle and pretty much took no time at all. The first and arguably most important of these bugs is related to how the floor generator populates events.
Before this week, each section of the floor would generate basically independently of every other one, i.e. they would have no information whatsoever of the structure of anything that cane before or after it. This was fine before I started spawning objectives. The problem arose when trying to spawn objectives for floors with multiple sections of varying size. The way the objectives would spawn is the generator would get the quota of the floor, multiply that by an excess multiplier (to ensure more objectives generate than are needed), then divide that by the number of sections. This would then be the threshold of “objective points” that section would need to meet or beat in order to be valid. This, however, would only work properly for floors with 1 section or floors with multiple similar sized sections. If, for example, I had a floor where the first section was 10-20 rooms and the second section was 60-80 rooms, with a quota of 100 for the floor (for the sake of this example we’ll ignore the excess multiplier), the generator would try to generate 50 points worth of objectives in both sections. This would lead to the first section frequently running out of valid locations to generate objectives and calling a failure state on the generator. Luckily, the solution to this problem was relatively trivial — it just required a minor rework of the beginning of the floor generator. Before, each section would randomly pick how many rooms it would generate in their range when that section started generating. All I had to do was change the system to generate all these values up front, before any section started. This allowed me to create a new variable to sum all the rooms together, which allows me to then find out what proportion of the floor’s rooms are in each section. The objective spawning portion of the code could then distribute objective points according to the size of each section. As you can see in the debug messages, this is working as expected now.
A snippet of debug messages from the floor generator — each section calls out the actual and targeted objective points for itself when finished
The final 2 bugs were fairly minor, so I’ll cover them both quickly before moving on. The first was that the player’s stamina bar would drain even if they weren’t moving, so long as they were holding the sprint button. I’ve tentatively fixed this problem by having the sprint logic check to see if the player is moving before draining any stamina, but this does mean the player can sprint in any direction. I’m not sure if I’ll change this yet, but now at least it’s function more as expected. The other bug was related to the objective bar at the top. Somewhere in moving everything to the Game Mode, I forgot to set it up to properly show and hide itself when the elevator doors open and when the lever is pulled. This now is functioning as it used to before the refactor. Now, on to the beginnings of enemies.
To be quite honest, AIs in general have always been an intimidating subject to be for some reason. I have a feeling this is part of why I tend to gravitate to multiplayer games, since in theory you don’t need to do AI if you design the right game, but obviously in this case that doesn’t quite hold true. The first major hurdle I was going to have to jump here was navigation. In a normal game with hand made content, you can just put a navigation mesh around the level and call it good. Procedurally generated games pose two problems for this approach. The first problem is that I don’t know what the extent of the level is going to be. Some people fix this problem by creating a volume that the generator is not allowed to generate outside of, giving a maximum distance in any one direction the generator can go. Personally, I haven’t done this for my generator. This means technically a level could generate entirely in one direction until it runs out of rooms. My floor generator also doesn’t know anything about the floor except for where door and point of interest markers are. I thought about using this data to decide how big the navigation mesh should be, but this wouldn’t fix the other problem here. Due to its nature, procedurally generated games have to use dynamically generated NavMeshes — the NavMesh can’t be precalculated because I don’t know what the level’s going to look up before it’s generated. Dynamically generated NavMeshes are a fairly significant performance hit when they’re fairly large. Luckily, Unreal Engine has a solution to both problems.
Digging around in the menus, I stumbled across Navigation Invokers. I had no idea what these were, so I went and watched a quick YouTube video about them. Essentially, they’re the solution for if your map is too big or unknown for a traditional NavMesh. The idea here is you enable dynamic NavMesh and enable a setting to only generate NavMeshes around an invoker. After this, you can put Navigation Invoker components on whatever Actors you like. These actors will then generate NavMeshes only around them.
These components have a tile generation radius and a tile deletion radius, so you can customize them however you like. In the example above, I have an invoker on a simple AI that wanders around. I’ve only just started to mess around with these as an idea, but in theory the radius of the Navigation Invoker only needs to be just larger than whatever range you’d like an enemy to be able to pursue a player at. These components aren’t strictly for Pawns, however. You could put these on static actors as well to create sign posts that generate a mesh around themselves. This, for example, could be used to create an enemy that only stays within a certain distance of a nest.
I’m still fairly early on in my research going into making the first prototype enemies for the game, but this early win has given me some hope that this chapter of the game’s development will go well. Stay tuned for hopefully some more good news on this front next week!
