Brandon Badger
Game Designer
[MONOCHROME]
*Demo shown is from a build that was showcased in October 2023
Role: Lead Designer/Producer
Team Size: 4 (3 Designers, one Programmer)
Project Duration: 1 year (personal project)
​
Link to the build shown in the demo above:
Note: You will need a steam account to be able to play multiplayer
Project Brief
[MONOCHROME] is a group project that a few friends of mine and I have been working on for a bit over a year. The build and video above shows a version of the game that was meant to become a multiplayer roguelike RPG where fallen allies can become enemies.
Responsibilities
-
Generating core design pillars along with the central thematic message for the game.
-
Leading design conversations weekly throughout development.
-
Implementing an Agile development strategy by creating biweekly sprints to keep the project moving.
-
Creating kanban board for task tracking, and generating tasks for all team members each sprint.
-
Maintaining design documentation as the project progressed to reflect any changes to any element of the game.
-
Creating technical documentation for our programmer on how to implement features for the designer to utilize in-engine.
-
Assisted with enemy, ability, and character creation.
-
Assisted with implementing and balancing enemies, abilities, and characters in Unreal Engine 5.
-
Mocking up any UI needed for the game.
Design Goals
We sought to create a combat-focused cooperative multiplayer game that emphasized kind and pro-social play. This stemmed from conversations that we had about how most of us on the team avoid multiplayer games due to their toxic nature. We wanted to attempt to create a game that would bring a hardcore audience to attempt to min/max and optimize their play. We wanted to set the game up to incentivize this playstyle, eventually leading them to realize that completing the game would be impossible without cooperation from other players. We were attempting to elicit this message through the gameplay alone, organically changing the behavior of players as they attempt to beat the game. We desired players to walk away from the game understanding the value of leaning on others for support, as some challenges can be too much to take on alone.
Given our goals, we also thought it best to not allow players to directly communicate with each other through the common means of communication: text or voice. We find non-verbal ways of communicating to be much more interesting of a design challenge and allow language barriers to not be a problem. Our ideal scenario for this game to deliver its themes and message would be through strangers playing the game together, so we wanted to focus on non-traditional communication.
We designed and implemented a meter (the white meter shown in the demo) that drains in various scenarios. The only way for the meter to fill again is through pro-social actions from other players, such as healing or buffing. If this meter runs out, the player loses their character. This character then becomes a powerful enemy for the remainder of the players to deal with. This meter is functional in the demo, but it isn't utilized or balanced in a way that forces players to pay attention to it.
​
We also wanted to take inspiration from games like Dark Souls and Hollow Knight and try to implement moments of reprieve and reflection after large chunks of intense gameplay. We all loved the idea of a group of strangers all sitting around a campfire or looking out at a grand vista after taking down a hard boss. We knew this specific goal would be difficult in a multiplayer game, as the fastest-paced player usually dictates how fast the group goes. It is hard to get players in a multiplayer game to sit down and reflect together, but this goal is central to the atmosphere we wanted to go for. This was not created in the demo above and would be a major focus going forward.
​
The demo above was more focused on nailing down the core loop without the head-fake or atmosphere we were going for. At the time, we felt it necessary to get the gameplay loop feeling intuitive and understandable before diving into any of the "transformational" goals we had. Given the nature of our project, we had quite a few features to playtest that could be seemingly unintuitive. These include:
​
-
A varied but quick character creation system that would theoretically be done often in a single playthrough as we expected player death to be a somewhat common occurrence.
-
Top-down third-person overworld transitioning to first-person RPG combat.
-
Ability to jump in and out of combat at any point, even if other players are fighting with you (players and enemies alike).
-
Various buffs, status effects, and DoTs that persist when moving between combat and the overworld.​
-
No text or voice options for players to communicate with teammates.
Development
Humble Turn-Based Origins
Our development began with implementing a rudimentary multiplayer turn-based system, with the ability for player to jump and out at any point. We tried to quickly prototype this system with simple enemy AI and a few abilities for the player to use, seen below:
​
​
​
​
​
​
​
​
​
​
​
​
​
​
It became apparent after the build shown in the video that using a turn-based system directly goes against the faster-paced system we wanted, along with disincentivizing the cool feeling of the player being able to jump in and out of combat at will. Waiting up to 1 minute before you could do an action seemed to betray how we wanted the game to feel. We decided to pivot and build an ATB system where each player is on their own "timer" so that players have much more control over their actions.
ATB
Our pivot to ATB had us essentially restructuring the entire combat system to accommodate everyone's separate timer. Thankfully, we had the foresight to not spend too much time in the backend for the turn-based system. This made the overhaul a lot less of a headache for us.
This system has each player be on their own timer (according to their speed stat), shown in the bar at the top right of the screen during combat. Players have to wait until their icon gets to the white bar. Upon reaching it, the combat options appear. They select an ability, select a target, and execute the ability before looping back to waiting until their next action. It is not shown in the video above, but players can jump out of combat whenever selecting an action to return to the overworld. This does not affect the other combatants whatsoever.
​
Digging into details (the good and bad)
​
It was at this point that we started building up the backend systems, generating classes, ideating on abilities, and fleshing out the prototype to give it the juice we wanted it to have. This ended up being a double-edged sword, causing a lot of time spent on elements of the game that were not important at the time.
​
As for the positives, our programmer Brendan (the guy who talked the most in the ATB video) developed a modular and robust system to allow designers to develop any ability for players or enemies in a matter of minutes. This system was an absolute lifesaver. The fact that we could design an ability on paper and script it in Unreal in a matter of 10-15 minutes increased our workflow tremendously! Our main combat designer David (the other person in the ATB video) had a field day playing around with abilities. He created unique playstyles for each class that gave all of them their unique feel, nailing the archetypes that we were going for. Elements of the ability that we were able to manipulate include:
​
-
Primary ability effect (Damage, Healing, Status).
-
Potency.
-
Hit chance (percent-based, stat-based, or guaranteed).
-
If status
-
Status type (buff DoT, etc.)​.
-
Duration of status.
-
Boolean of whether the status can be removed or replaced before the timer is up.
-
-
Repeat the above for each effect the ability has.
-
Examples of multiple effects are multi-hit moves or damaging attacks that also can buff/debuff/etc.​
-
-
Duration of the animation.
-
Visual of the animation.
-
At what point in the animation does each effect take place?
​
This was all fantastic. However, I mentioned above that there were downsides. It was shown a bit in the ATB demo above, but we began to focus on UI and visual/auditory juice for the game.
This. was. not. the. correct. play.
​
We should have immediately begun playtesting our game at the point it was above (or even slightly before it), just to get a feel for the information presented to a naive player. We instead went down a multi-month rabbit hole refining and polishing elements of the game that had no backing through playtests.
​
I completely take the blame for this approach, as I was leading the design, producing the team, and being the UI designer. I am honestly amazed that I did not have the foresight at the time to see the error in this approach. I personally made this worse from the first UI mockup of what combat could look like below:
Do you see the issues? I see quite a lot. The biggest ones from an implementation perspective are that those menu columns are:
​
-
Slanted
-
Centered on an option that doesn't have equivalent options above and below it
​
Regardless of the other visual issues presented here, the above two elements of the mockup caused a DRASTICALLY increased time investment to make work. I cannot believe that I gave the go-ahead to begin to implement this mockup. We soon followed this UI implementation with an overworld UI update as well, seen below:
​
These screens allow the player to look through their inventory, abilities, stats, and buffs. We specifically made it so that the menu does not cover much screen space as this is a live multiplayer game that does not pause
Creating, iterating, and refining what we believed to be the information we wanted to convey took months of time to do. We iterated on the text box beside the combat abilities to figure out a format that conveys all of the information that is needed for the ability and follows a modular enough format to fit the variance of the abilities that we had.
Our programmer also decided to lean in on the somewhat randomly decided style of move animations that we took from the game Hylics in our original turn-based prototype and go to town with it. He recorded his hand movements to match the first-person look of Hylic's abilities to have custom animations for each ability. We thought it would be cool, so we also added that work before testing with others.
To repeat, this was all being done over months BEFORE naive players had even played it. We had no idea what players needed to see. There is also the elephant in the room we have done nothing to begin to test out the second health bar mechanic or our desire to balance moments of high stress with moments of reprieve and reflection. You know, the mechanics that are supposed to be central to our game's design goals of pro-social behavior? That should have been a focus well before any of this in-depth UI or game juice.
​
After building all of this UI with an unfortunate focus on style instead of analyzing its substance, we ended up pivoting again in combat. We decided that in a fast-paced ATB system, we assumed players really wouldn't read ability descriptions much and would memorize what each ability did. We also believed the format of single-column options to be inhibiting gameplay more than helping. We decided to switch to players having only four abilities and one ultimate move, all mapped to a button on the controller. We assumed this would both be more readable, less daunting than the initial lists of abilities, and much easier to quickly select actions once the player knew what their options were. We also leaned on using iconography to showcase abilities and effects rather than the text we were relying on in the previous iteration. We also decided to temporarily get rid of all of the unique ability animations as they were large and obtrusive to the player's view of combat. It made things a lot more disorienting and overwhelming.
​
Mockup of the button-focused UI. We also changed the visuals for the buffs/debuffs to a timer wheel surrounding the icon rather than it being placed beside it (both formats shown above the left red circle)
Preparing for Bit Bridge
​
As October 2023 rolled around, we realized that there was a local showcase event called Bit Bridge happening mid-October. At the time we found this out, it was a bit under two weeks until the event. We decided to be crazy and try to showcase our project there. Why is that crazy? We decided to try to condense what we imagined to be 2-3 months of work done in a week. What we tried to build in that short amount of time included:
​
-
An overhaul to the character creation screens to look more "official"
-
Custom characters for each class are shown in character creation, overworld, and UI
-
Level generation showcasing what the gameplay flow could look like (we had basically not touched level design before this)
-
Environmental puzzles that involved multiple players (with no in-game method of communication)​
-
Intro area to learn the mechanics
-
A rest area to heal up
-
A boss room
-
-
Three enemy types to fight
-
A boss battle (we made two bosses)
-
Several updates to class abilities
-
Balancing the game to make it challenging but possible to win
-
Adding the functionality of that secondary bar below the health bar that turns players into enemies when drained to 0 and restores when players focus on a supportive mode of play with each other
-
Note: Another reminder that this should have been implemented much sooner, given that this mechanic is central to our game's long-term focus on pro-social behavior.
-
-
Adding usable consumable items
-
Adding additional bonus effects when players allocate stats to a certain higher threshold
-
Implementing a dynamic music system that transitions between the Overworld and Combat
-
A LOT of bug fixes that we had been putting off
​
Easy, right? It was insane to try to accomplish this much in that short of time. The crazy thing is, we did it. Every single bullet point written above was completed before we showed up at the event. It was mentally exhausting and required 16-hour work days for two of us the entire week (and still a lot more time investment than normal for the other two), but we did it. I would never want myself or anyone to go through that ever again, but I would be lying if I wasn't proud of the work we got done.
​
To make sure that we were best prepared for a showcase of random people circling to play the game, we did finally get a friend of ours to playtest our game. There were a good number of changes that we made from observations from her play session that saved us a ton of headaches. I would go more into detail here about everything that we accomplished, but the demo from the event is attached at the top of the page for you to experience yourself!
One-page info sheet that was created for the showcase to quickly reference when playing the game.
Lessons Learned from Bit Bridge​
​
Bit Bridge went over pretty well all things considered! There were a lot of issues with players not understanding certain mechanics, icons, etc. This is purely from the fact that we had a single playtester outside of our team after almost a year of development. We had added so much without getting a solid read on how naive players would interpret the information. It's not shocking that the one-sheets that we passed out above weren't used much as the event was very crowded and hectic. It was not the atmosphere to sit down and comprehend detailed mechanics. Other observations gathered from the showcase include:
​
-
It's probably best to bring players together immediately in a multiplayer mode before having any sort of separation since many players questioned the game being multiplayer
-
No one understands a bunch of the icons shown on the screen.
-
The visual for the ATB bar had some people assume it was a rhythm game (which is understandable)
-
Especially in a public showcase event, most people will not read text.
-
Not many people tried running out of combat or defending at all (both have unique properties compared to an average RPG). This is because no place taught players the benefits of it.
-
There was a lot of initial confusion when initially going into combat as people did not expect the game to be an ATB first-person combat system.
​
With all of the issues aside, those who sat down to try to understand the game got it! It was great to see people taking on supportive play, and utilizing the systems we created for them. Our favorite moment was watching a girl play the whole game alone and somehow beat the 2-player boss with ease. A lot of people commented on the cool moments of enemies joining in combat just like players can, and how good it feels to use some of the more visceral ultimate abilties.
Project Status after Bit Bridge
​
After doing a retrospective on the event, we decided to play around with other gameplay systems that could fit under our project's core pillars. We tried a weird hybrid of ATB and real-time with using the targeting and abilities of our ATB system when physically moving around the overworld space. You would hold down a trigger button to transition from an over the shoulder third-person camera to a first- person one. We also tried a quick prototype of a gameplay style mixing the movement of Dark Souls with the abilities of Overwatch. Ultimately, we decided that making a multiplayer game with the design goals we set out to make may be too big to tackle given our team size, along with some long-term goals seeming to directly conflict with the nature of the multiplayer game we were making. We all still believe that this game can be made as intended, but decided to ultimately pursue other tangential projects using MONOCHROME as a foundation for the future.
Wishlist for future add-ons
​
If we were to continue working on this specific project, there are several things that we would prioritize fixing and adding:
​​
-
Focus on how to further incentivize supportive and pro-social play with the secondary health bar, supportive actions that the players can use, etc.
-
Focus on nailing the atmosphere of the game.
-
Focus on nailing down how to accomplish our goal of having checkpoints that slow the player down after large sections of hectic gameplay to reflect in a multiplayer game (think bonfires in Dark Souls)
-
Figure out how to better convey what is happening during the transition to combat
-
Overhaul how information is conveyed to the player. Combat is still pretty overwhelming and confusing to a naive player. This includes combat UI, combat icons, ally actions, and many other little issues.
-
One solution we immediately thought about is overhauling the combat UI (again, I know) to make it both more diegetic to the world along with reducing the amount of information. We now have player feedback to dictate these changes. I did a mockup shortly after the showcase of what we were going to try next:
-
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​​
-
BRING BACK ABILITY ANIMATIONS (but tweak their size, duration, and opacity to reduce disorientation).
-
Explore methods of non-verbal/non-text communication between players, such as emotes or the like.
-
Iterate on the level layout to resolve the issues described above.
-
Update how the ATB bar is shown to stray away from player expectations of any rhythm-based mechanics.
Get rid of the abundance of iconography with abilities and lean on the idea that this is a first-person HUD