The Replication Revelation

So this week did not quite go how I expected it to. Despite that, I think I’ve come out of this with a new perspective on how the core game loop should be coded. Lets talk about that.

For a while now, I’ve been sort of struggling to understand what the Game Mode and Game State actors are meant for in Unreal Engine. Intuitively, I know the meanings of the words, but I never quite grasped their purpose in the greater code of a game. For me, the Game Mode ended up pretty much just being where I declared my controller and pawn class for the player and the Game State gathered cobwebs. Doing some research online yielded some results, but they were very vague and not terribly helpful. The main points of interest I found this way was that the Game Mode only exists on the server and should be used for the game logic, whereas the Game State exists on the server and all clients, making it useful for holding information about, well, the state of the game. Makes sense, but without concrete examples, it was hard to figure out what exactly to do with that information. In this project, I figured that meant stuff like the floor number, seed, and objective information should be held in the Game State, but the Game Mode continued to elude me. This was until earlier this week when I was starting to try and add more features to the interaction system — specifically multiple interaction points on a single actor as well as timed interactions — and I was starting to have problems with proper replication. This got so bad that eventually I decided the system was too far gone and I should revert the project to the last revision (thank you version control) and try again later. That later ended up being today, where I decided to implement something a bit easier while I mull over the interaction system problems. The thing I decided to work on was the Emergency Departure system. As a refresher, this is the system that, if the players decide to leave the floor before their objective is complete, they will leave the floor early, lose an Emergency Departure charge, and generate a new floor of the same floor number. Almost all of this ended up being implemented just fine first try — everything but the indicator on the lever to show players how many charges are left. Frustrated with what seemed like yet another replication issue in the same week, I turned to ChatGPT for help figuring out what I’m doing wrong.

Now, to preface, in general I do not like the direction generative AI is going in. AI art in particular really grinds my gears not because it looks bad or even really necessarily because it’s stealing from artists to train on (which, mind you, is still really bad). The main reason I dislike it is because it seems to aim to replace humans in pursuits that we enjoy, such as art. That said, I’ve found a lot of value in turning to ChatGPT to either use as a rubber duck for figuring out problems or to explain a concept in an easy to parse way. This lead to me fixing the issue with the indicator, which of course I was overcomplicating. After fixing that problem, however, I was curious if it’d be able to explain to me exactly what the point of the Game Mode and Game State actors were, in layman’s terms, all in once place. As a quick aside, when I first started using Unreal Engine, I remember being extremely pleased with how well documented it was and being able to find information on the engine quickly and effectively. I don’t know what happened, but I feel like this is no longer the case with Unreal Engine, especially Unreal Engine 5. Most documentation I find is either extremely barebones or from someone making a video about the concept, and when I want quick information on a topic, the last thing I want is to watch a video about it. ChatGPT was able to explain to me perfectly what the whole point of the Game Mode and Game State was. Full stop.

To give a brief overview of how the game functions right now, the lever in the elevator is step one of the process. When it’s pulled it figures out exactly what should be going on in the game based on information it has from the Game State as well as a few other sources. It then tells the elevator to close its doors. The elevator then does that, starts playing sounds, turning on lights, shaking the camera, but then critically is responsible for unloading the surface level and spawning the level generator. The level generator then does its magic, then when it’s done, calls an event dispatcher to say it’s finished. The elevator then finishes its sequence, opens its door, and then tells the level it can re-enable itself. This logic is extremely interdependent. All of these parts rely heavily on the process remaining the same every time, and a lot of the game logic exists on actors that exist on both the client and the server, leaving it vulnerable to potential cheating.

The simplified game flow as it exists currently

What really should happen is each of these elements should only contain its most basic functionality, ideally things that need to be seen by the clients, and should communicate with the Game Mode, which can then act as the arbiter of what happens in the game. To explain this, I’ll outline the same system as above but with the use of the Game Mode. The very first thing the players do is pull the lever. The lever no longer has any functionality in it except for its visual movement and just being an interactable in general. When the lever is pulled, the lever tells the Game Mode that. The game mode can now decide what’s supposed to happen following the lever being pulled depending on the current state of the game. On the surface or on a floor when the objective is complete, it would simply close the doors and send the players to the next floor. If the objective isn’t complete, the game mode can decrement the Emergency Departure charges and regenerate the same floor number. All of this logic currently occurs on the lever, but can now be put on the Game Mode. The game mode would then also be responsible for telling the elevator to close or open its doors at the appropriate times. Furthermore, the elevator would no longer be responsible for clearing out the old level, spawning the floor generator, or setting several variables on the Game State. Ultimately this refactor leaves us in a position where you can visualize the whole game flow in a single event graph as with the freedom to easily adjust the flow or remove elements entirely without breaking the functionality of the individual pieces.

The new version of the game flow, utilizing the Game Mode actor

This allows all the important game flow code to be in the server where it’s protected. The game mode can then make changes to the state of the game via the Game State. These Game State variables can then be replicated with a notify function. For those unaware, there’s 2 types of replication a variable can have in Unreal Engine. The first of these is regular replication. This simply synchronizes a variable across all clients, which is useful, but can run into problems with timing. The other type is called RepNotify. This creates a function for the variable that gets called on all clients whenever the variable changes. This means that we can use this to update things on the clients only once they’ve noticed the variable is different. With that out of the way, we’ve finally come full circle.

The problem I was having before with the Emergency Departure wasn’t that it wasn’t working per se, but that I was calling the event to update the visuals on the lever before the clients even realized that the variable had changed, meaning the clients wouldn’t see any update. I was able to band-aid fix this problem with a short delay, proving the system was otherwise working as intended, but I wasn’t satisfied with this. What if a player had a large lag spike right when the event was called, which then caused the delay to be insufficient for them? We needed to use this RepNotify function to fix this. This means that whenever the client received the update to the variable, no matter how long it took, they would eventually see the change reflected in the lever’s display.

With all that learning out of the way, I’m happy to report that the Emergency Departure system functions properly and, more importantly, I’ve come out of this week with a much better understanding of replication, multiplayer, and the game structure in general.