Jesse Saunders

During the first stages of development in this game we knew that we were going to need a networking solution and were a bit torn between a few options. We decided on Photon Unity Networking (PUN) and continued early development steps working with this system as our networking solution. It presented some particularly frustrating issues that Photon’s initial documentation didn’t have answers for. We knew that this might be a problem going into it, because PUN was a newer tool by a smaller developer.

However, as with many new software solutions, Photon came out with a newer version of their tool: Photon Fusion. And with this, depreciated PUN and limited support using the old version. We decided to upgrade to Fusion, losing lots of time to refactoring code to fit with the new system.

At this point, there were some areas of code that were giving us lots of problems because we had a communication break down. This led us to have some parts of the project that were still using the old solution and some that were using the new ones. This was a major issue because the old system relied on Remote Procedure Calls (RPCs) from the client to the host, and the new system had a more rigid host validation of networked variables.

Finding and fixing these differences became one of my areas of expertise during the middle and towards the end of this project. I became responsible for refactoring eccentrically the whole project to utilize the new system. Through long hours and determination I managed to get the project in a stable position for multiplayer, and learned quite a bit about networking and its optimization in the process.

Starting off, the vision of the game had very few weapons and consumables throughout the gameplay loop. And for this I implemented the basic weapons and their capabilities. I created two basic types of weapons that had variables to create different types of weapons: Raycast weapons and Projectile weapons.

Raycast weapons came with a few notable variables that allowed them to evolve into weapons like a semiautomatic rifle, or a shotgun. The first was “pellet count” which was the number of raycasts that were produced at once in order to simulate multiple bullets. Using this in tandem with the “spread” variable allowed me to create multiple bullets coming out of the weapon in a cone with a certain diameter.

Projectile weapons also had variables like “pellet count” and “spread” but the way that these were applied was very different. For projectiles, the weapon spawns in a projectile like an arrow and hands it information. This information contains variables like “projectile speed”, “fall rate”, and “prediction distance.” Since the projectile is its own entity that interacts with enemies by colliding with them we needed a few solutions to ensure that the projectile didn’t go through the target without hitting it. This is were I applied the “prediction distance” which created a raycast forwards from the arrow the length of “prediction distance” which would validate the collision that would otherwise be missed by the engine’s physics calculations.

As the weapons system evolved and we created more types of weapons that branched off of these basic types, more and more variables became necessary to fine tune the balance of each weapon. We eventually had requirements for grenade launchers, Aim Down Sight (ADS) weapons, and throwable grenades all of which required new additions to the weapon system and their own challenges. Variables that controlled spread concentration, recoil, accuracy decay, and movement sway were all additions that made this system more complex.

This is where I learned the value of UML and visual design. The system was getting so bloated that I couldn’t manage the whole thing in my head and the various aspects of each weapon and how they connected to different systems became dizzying. I had constructed my own visual design map on paper because I didn’t know about UML tools at this point, and once I learned about it, the need for it was over. Though the necessity for those tools was not lost on me, there were many points were updated UML designs could have helped the team in dramatic ways.

During the second half of development, we were focused on the campaign of the game. We had most of the multiplayer aspects already done, but we didn’t have non-player enemies in the game. We spent some time to figure out the requirements of each of the enemies and how they were supposed to operate, and landed on some lofty goals for around 6 different types of enemies. We also landed on one boss fight for the ending of the game.

For implementation I decided to go with a state machine to control the different states that the AI could be in, which allowed me to individually define the behaviors in each state for the different enemy types. For basic implementation, I started off with a controller that contained code that executed the current behaviors task and then check for a transition signal.

From there I developed behaviors that easily interfaced with the main controller. These behaviors ranged widely in function. Some were simple like moving towards the player utilizing the NavMesh tools that Unity provided. Others were more complex, handling a patrol system that utilized enemy vision and shifted them between different attack modes and styles.

This was also during the time were we made the transition from Photon Unity Networking to Photon Fusion, so the networking systems that the AI were using to ensure that they synced with clients needed major refactoring. This took a particularly long time because the state machine relied on RPCs to function properly. Subsequently each behavior also needed a rework, and in doing so introduced new issues that took a while to figure out.

All together, the ending product was really smooth AI enemy behavior that had many different abilities that created interesting combat scenarios for players. The boss fight was created separately from the other types of AI because the normal state machine didn’t allow for environmental triggers that we wanted in the boss fight. So utilizing similar practices I developed the Boss fight with the addition of lane-type attacks and other environmental attacks. I also implemented the ability for the boss to spawn in other types of enemies.

During the initial stages of development in this game we didn’t have that many mechanics to contend with. We had the ability to die and respawn, move around our previous body, spike traps and traversal puzzles that had more than just one solution. It soon became obvious to the team that we needed more mechanics so that we could create interesting levels that challenged our players.

First was the development of more environmental hazards. Things that made our player have to utilize skill, timing, and the body mechanic to overcome. We thought up a number of these, and I was in charge of bringing them to life. One particularly fun implementation was the button maze. Like in Indiana Jones I created a hallway of buttons that you had to traverse in order to unlock the next section. Each of these buttons revealed traps of various kinds: turrets, spikes, etc. The particularly difficult part was blocking the turrets once they had been activated, making this puzzle too difficult for players.

Instead of scraping the mechanics, we built a new one that allowed the player to use the gun they had to form new shapes with the bodies they had instead of just ragdolls. Now with the addition of cube bodies, this puzzle was less tedious to complete as you could block the turrets and spikes easily.

However, once we did this it opened up the possibilities for the players to really break the game. Now the players could build towers, and fly on top of the cubes if they picked them up while on top of them. This “solution” while providing us more interesting mechanics introduced design problems that we didn’t anticipate.

The rest of the development went similarly to the previous story. If we had an idea, the team quickly married it into the project without thinking of implications for the mechanics that we already had. Thus designing levels and utilizing the mechanics in meaningful ways became harder and harder. I did my best to catch these edge cases and handle them according to what would make sense in the scope of our game, but some fixes weren’t possible with other mechanical requirements.

This beautifully illustrates the need for proper planning and testing. After the project, we discussed how the initial mechanics were more than enough to develop a fully polished game. We could have utilized clever level design and pacing to properly build into other mechanics as the game progressed, slowly building into more mechanics as the pacing demanded. Along with this idea, we could have had more time with each of the new mechanics to really see how they would interact with previous ones. We did the testing phase after big additions without making sure that they were going to fit well with the other mechanics.

One of the biggest problems that we had during the development of Lab Rags was the ability for the player to spawn infinite amounts of bodies. We discovered that one particularly impatient play tester would pile bodies in front of the ending area in order to make these kinds of stairs they could walk on to reach the goal. Not only was this not the intended path, it was also causing frame drops on this players computer.

In order to solve this, I implemented an asset pool, which allowed for a specific amount of bodies to be present in the scene at one time. By reusing a set number of bodies in the scene, this improved performance dramatically. It also stopped players from abusing the idea of mass spawning bodies to solve puzzles. However, this introduced a new problem: players didn’t like bodies just de-spawning.

We found that players were confused when bodies they placed earlier would disappear, sometimes ruining structures they build to traverse areas. I decided to create a narrative solution that gave a reason for the bodies to disappear. I created the cleaning robots that would come from specified places in the levels and like a flying Rumba, it would collect the oldest bodies and recycle them.

This solution provided a little narrative to the players situation and some humor as the ragdolls would act in random ways when picked up. Applying this to the asset pool was simple enough, and the game felt more alive because of it.