Personal Project, Testing by friends
Solo Project - Designer
2021
Inspired by Destiny’s Raids, I’ve been making a Cooperative mod for Half Life 2 Deathmatch. Built in the Source Engine, modifying Valve’s C++ code for Half Life 2, the mod allows players to select a class, and face challenges, from puzzles to enemies, requiring skill, communication and teamwork. Currently 1 encounter is being actively playtested, with a second under development. Once I have completed a third encounter, I will begin releasing the mod itself.
I am working on this project to create a longer project, as opposed to my short game Jams. It also allows me to focus on developing other aspects of my game design, from puzzles to systems, to balance, without having to invest time in artwork, or writing basic scripts such as player movement, network code, or character control.
The entire “raid” is made up of a series of levels, or “encounters”. Each encounter serves as a checkpoint, and failure will result in the entire encounter being restarted. Each encounter will also have a boss health bar, displaying how far through the players are.
You must be at least *this* cooperative to enter
Players are required to cooperate to complete challenges, using hidden information, and additional objectives, one player cannot be in two places at once, and cannot hold all the information to solve a puzzle. This forces communication, and prevents a single leader taking control. All tasks are somewhat involved, no task was ever intended to be “ad” duty, whereby the player doesn’t meaningfully engage with the mechanics or systems of the encounter.
The Process
I have broken my process up into smaller groups, to outline how I am making the mod, and how I have made previous levels.
Class Systems & Weapon Balance
In the Mod, there are 4 classes. Assault, Support, Heavy and Medic. Each class must feel unique, excelling at some form of combat, or requiring a certain gameplay style. As such, each class has 4 weapons, a primary, secondary, heavy and melee weapon. For the Assault class, this is a shotgun, automatic pistol, rocket launcher, and stun stick.
All these weapons were modified from their base Half Life 2 stats, and then placed in a spreadsheet to tweak their balance. These stats were then fed into the enemies hitpoints, to work out how long it would take to deal with any enemy. Due to Half Life 2’s inaccuracy of the weapons however, these values were imperfect, and required some tweaking to make them “feel” good. Boss enemies had their health values massively multiplied to ensure that a single person could not defeat them, and the entire team would need multiple damage phases to finally overcome the boss.
The balance sheet for all the weapon’s stats in their raw forms
The damage sheet of TTK against certain enemies.
Encounters
For an encounter, I focused predominantly on the roles, what each player would be doing during that encounter, and where they would be. Could they help another role, did they have vital information for another role? I laid out the core areas of each encounter in an area, then moved them around until they aided the flow of gameplay, and players all had something to do. Keeping the role jobs distinct and distanced from each other helped tell the players how they should deal with the encounter as well, as it could prevent them from mistaking a job for one person as a job for two individuals.
A first iteration of the jobs of the players in the encounter. Focusing on their paths, and how much players would interact with each other. After playtesting, being so separated from one another didn’t translate well, and left each player with a lot of load.
The second iteration nested the Overseer alongside the defender, and included more windows, and paths down to allow the codebreaker to assist as well with long range shots and the like.
The first encounter has 3 distinct roles, a code breaker, an overseer and a defender. The defender is the least interesting of the roles, and the closest to “ad duty”, wherein they simply must shoot mobs. They instead have to defend 3 generators from the enemies assault. This requires mobility and map understanding so I believe it is a little bit more advanced.
To prevent exhaustion, players are rewarded with down-time between waves of enemies. Once the code has been successfully entered, enemies stop spawning, allowing the remaining enemies to be finished off, and a well earned breather, before the next wave starts, spawning yet more enemies. This breaks up the intensity graph, creating a more varied and interesting encounter with clearly signposted highs and lows.
The Overseer spends time with the defender, and the two roles can be easily substituted. On occasions, the code breaker must enter a room and relay the symbols they see to the code breaker, who must then input them into the wall. These symbols are Intentionally vague, allowing players to ascribe names to them. This creates levity in the group as they think of 4 appropriate names, as well as tension when the names are forgotten or confused. These symbols have numerous distinct values, while obeying similar artistic cohesion.
Once the Overseer has relayed the three symbols to the Code Breaker, it is their job to insert the appropriate plugs into the walls. They must repeat this 4 times, each time it gets more challenging as their assumed familiarity increases. Initially it is simple, as shown below, however eventually they must do it with the symbols distanced from the plugs. All the while their two allies are defending generators.
The Overseer’s room, 6 monitors, they must relay 3 symbols to the code breaker.
The Codebreaker’s plugs, along with the symbols displayed to them.
The 4 symbols are all inspired by the original symbol, Valve’s Combine symbol seen multiple times throughout the game.
Puzzles
Half Life and Destiny are famous for their puzzles, and as such I wanted to keep them in, choosing the puzzle element of raids over the pure combat. I also enjoyed the aspect of solving puzzles under pressure. The time players spend relaying symbols and slowly inputing codes is time that the other teammates could well be getting overrun.
Additionally, I felt it was fair each encounter introducing a new puzzle to the players, puzzles are built upon, and climaxed at each encounter, with the next one introducing a new problem. This meant that I had to teach the mechanics to the players in such a way that either they were required to solve them before the encounter begins in earnest, or they could reasonably solve them under the pressure of combat.
Similar to Destiny then, encounter failure states were conveyed clearly through on-screen prompts.
AI and Enemies
Source Engine already has a very impressive implementation for enemies and AI in the system, so used this, avoiding making my own AI. From my initial level designs, I knew where enemies would spawn, and their direction of assault, choosing enemies to attack points farther away, ensuring they would almost always cross the player’s vision. What was then tweaked was the rate of spawning for these enemies, to ensure they didn’t overwhelm the players, while also ensuring they remained a threat. This was the hardest balance to walk as the skill of a group of 3 people can vary so wildly.
Combat
For the main combat, I wanted players to always have an idea of where the enemies were attacking, without constantly being exposed to them. I also liked the idea of limiting the player’s movement across a bridge, preventing full movement. This then had the issue of too large sightlines, and enemies constantly harassing players. As such the walls were placed to break up the sightlines of players and enemies alike. Encouraging players to take cover while their armor regenerated, and encouraging them to move to watch all 3 generators.
Playtesting and feedback.
I was well aware that this game was only as good as the playtests were. For that reason, I playtested early and frequently. One of the reasons all the assets above are placeholder and so basic is that the levels constantly move around. The Overseer’s code room shifted from the top floor to the ground floor in between map iterations, as well as another generator added. These choices were all in direct feedback from playtests. This also allowed me to test how long it would take players to understand encounters, was it possible to do without hints, and was it fun or frustrating to do so.
One lesson I learned quickly was that my game did not have the draw of Destiny (obviously), players would not spend several hours playing an encounter, and would rather go play a different game. As such, I could not have as obtuse encounters as some of Destiny’s. For this reason some encounters feel simple when explained, but were still fun and appropriately complex to playtesters.
Gameplay Video (One day)
As the game is updated, gameplay videos will be provided for each encounter, outlining the roles of players, and the systems of the encounter.
The Hammer Editor’s view, with all the entities, and enemy paths laid out.