Network Replication
New Drone Types
In our vision of the game, the Defender is able to spawn different kinds of drones, to adapt to his playstyle or to counter his opponent. Therefore, we needed some more drone prototypes to see where we can go:
Melee Drone
This one bases on the Sentry, but it has no ranged weapon. Instead of attacking from a distance or try to stay at least a few meters away, this drone is all about closing the distance and trigger its blast ability, an energy overcharge that damages any actor nearby. This overcharge kills the drone itself due to this process.
Turret
This one also bases on the Sentry, but without the capability to move at all. Instead of changing its location to investigate an area, this drone type changes its rotation to sweep the area with its “eyes”.
New Drone_Base Class
Creating all these new drones meant adding a lot of references in other classes by hand. I had the idea to insert another layer of abstraction, a new base class for EVERY drone. Before, each drone derived from APawn directly and a lot of the code needed to be copied to create a new drone type. The new hierarchy demands another in-between class:
APawn -> Drone_Base -> SentryDrone_Base -> SentryDrone_Balanced
|———— Programmer’s access ————| |— Designer’s access —|
This Drone_Base includes now everything that should be available for every drone: its movement component, the health component, possibility to take damage, updating the health points, sounds for spawning, and so on. That reduced copying code by a lot and speed up development in general.
Network Replication
Rebecca asked me about a way to speed up playtesting. Initially, she asked to restart the level in case one of the players has won the game. Because of our multiplayer environment and to keep the possibility to go with more than one level, I implemented “seamless travel”. But you cannot test the travel in the editor environment, these function only works within a complete build.
Creating different builds for Windows and Android, all the time, to test different things quickly became a time-consuming process. Especially at the end of our project, while we will try to balance every value of the game, we cannot waste half of a work day creating builds. The main problem is to playtest the game with two players at the same time. The “PlayInEditor” feature opens up two different windows, one for the server and one for the client, but you cannot have “input focus” on both screens. Only one can have active mouse control, which makes sense. But I spot a neat little trick in the Editor Preferences: the opportunity to map the controller always to the second window, while mouse and keyboard control the first one. Sadly, our GameMode creates the Attacker first and the Defender second, and controlling the mobile screen with a controller is not exactly what we had in mind. “Not a big deal”, I thought initially, but switching the roles uncovered every mistake Daniel and I made with replication.
Downgrading the Attacker from being the Server to become the Client caused trouble in nearly every Blueprint. Beforehand, the Attacker knows every bit of information about being a Client AND of being the Server, at the same time. And he had all the authority over almost every actor in the game which means unlimited access to every parameter. Now, there were bugs where we just missed to check the replication flag, e.g. a HUD that did not update its values anymore. But also more serious bugs that had to do with the remote procedure calls, e.g. there was not a single sound anymore for the Defender played, the Grapple quits functioning, the projectiles of the Attacker do no longer consider the pitch of the camera while being spawned and so on.
Daniel and I agreed on giving it a try, at least for one day. In the end, they became three in total. But continuing developing with a dedicated server and therefore force the Attacker AND the Defender to be a client helped me to keep the overview. It took me some time to experiment with different scenarios, especially for getting to know the different remote procedure calls. I was very aware of the questions “Who is calling the RPC and who is going to execute it?”, but I hadn’t considered the questions “Who owns this actor?”. Also, I totally ignored the No.1 replication rule: “Replication works FROM the server TO the client, ONLY”.
