Repost: Danger Crew's Multiplayer Battle Prototype

The Danger Crew Battle Demo is live! I’ve been working on it for a few months and am super excited to share some behind the scenes details of the project.

You can play it here: battle.thedangercrew.com

2022 Update: It's not really playable on this domain anymore, but we'll fix it if enough people ask. (It will take a good bit of work, and I'm not sure how many people are actually interested.) Use the Contact Us page!

The quick pitch: The Danger Crew is an adventure RPG in the browser. It’s about being a developer and getting in silly hack battles with other developers.

The Danger Crew Battle Demo is an excerpt of one key aspect of The Danger Crew: the battles! Players spend the majority of time in these battle sequences, so it’s important that they are engaging, exciting, and dynamic. The old system was pretty solid, but it had some fundamental limitations for providing enough variety for a long form game.

I had big changes in mind, so I set out to create a stand-alone demo just for battling. This demo helps gather feedback on a very specific element of the game before rolling it into the rest of the walking/talking adventure.

Adding more depth to the Battles

The most obvious change here is that battles are no longer one developer vs one developer. Battles are now team based - a team of 1 to 3 people vs another team of 1 to 3 people. We’re finally putting the “Crew” in Danger Crew. One on one battling worked great for the first chapter of the game, but it was evident that we needed more variety for chapters two, three, and beyond. Crews enable the player to customize multiple combatants and approach challenges with more creativity.

One new medium of creativity is the Class system. A Class is a category that describes a character’s function on a team. For example, the Hackalete class is designed to deal lots of damage really quickly while the Scrum Master class is in charge of keeping team defense and productivity high. They have fun tech names, too.

Classes complement each other. Teamwork is necessary to win. These specialties are made possible by expanding the battles to be team vs team, where a solo Scrum Master would struggle head to head against an enemy Hackalete, but a team combination of Hackalete and Scrum Master are a synergistic threat. Classes can stack, too. There’s nothing quite as stressful as facing off against 3 Quality Assurance engineers at once.

One of my favorite parts - Each Class has a Super Charge move that relates to its role. These explosive moves are intended to cause turning points in battle - like a healer reviving all dead teammates or a disrupter setting all enemy laptops on fire. Tensions get high after a few turns when you know the opponent team is ready to unleash their Supers.

All of these new elements allow the game to put the player in many different situations.

Multiplayer

It’s gotta be the most common question I get about the game. It seems like an obvious add: it fits well with turn based style and is right at home in a web game.

I’ve always been hesitant to add multiplayer for two reasons:

1. I wanted to keep the game’s focus really clear. The classic RPGs that inspire The Danger Crew [mostly] didn’t have multiplayer. They were focused on the single player narrative. I wanted to follow in those footsteps and never rely on the presence of multiplayer.

2. Online multiplayer adds technical overhead. I’d have to think about servers, real time events, security, etc.

The exact scope of multiplayer is an open question, too. It could be a big extensive open world MMORPG where you see other players walking around or as simple as a single one-vs-one battle game. I’m still unsure if and how multiplayer will fit into the full game, but this particular battle-only demo offered an easy opportunity to try it out.

The demo has two multiplayer modes: Versus and Rally. Versus is one human vs one human: each player controls a team of combatants. It’s just like solo play where the player controls the entire friendly team, but the enemy team is controlled by another human. Rally lets up to 6 players join a game room. Each person controls one combatant. The room’s creator can also add bots to the match. This mode is nuts! Having two modes helps answer the question: is it more fun to control a whole team? or is it more fun to control one person as co-op with other humans?

Like I mentioned, the reality of servers and backend stuff had me hesitant. I enjoy backend work, but I really want to only focus on gameplay and storytelling in this project. I also don’t want to stress about downtime or scaling. Firebase to the rescue!

So how does it work?

(This part assumes a tiny bit of knowledge about Firebase, but don’t worry if you’re not familiar.)

The Firebase database has a top level node called rooms. Each multiplayer game session is a node inside rooms. Two to six players connect to a single game room, each person having a key in a “connections” node of the room. We use Firebase’s anonymous login to make sure users are authenticated before having access to write data to a room.

The state of a battle is stored as an object in a Redux store. When a player submits an event, they calculate changes to the Redux state locally then send up 1) the updated state and 2) a description of what happened. For example, if I use “Scope Bomb” against Betty, my browser will calculate how much damage I did to Betty and subtract from her total HP. I’ll send up an updated object with Betty’s new HP value as well as “Drew used Scope Bomb!” readable text messages. I call these rollouts. I talk more about them in a previous post (link below). The other clients will see my message, display the rollout, and update their local Redux stores.

One client is designated as the “master” who reads the state and sends the updates of which player gets to choose next. Once all players have seen the “Drew used Scope Bomb!” message and are loaded up with the updated state in their browsers, the master enables the next person in line to make their move. The cycle repeats from there until all combatants on one side are out of HP.

What went well?

The turn cycle system fundamentally supports multiple players. It works the same way online as it does offline. In single player, all enemies are combatants with isBot: true. This flag means that the combatant goes through the same turn process, but the browser makes a decision for them right away so it feels automatic. In multiplayer, players marked as isBot:false manually fill out the attack menu before the cycle proceeds.

What was tricky?

This system is all client to client, so source of truth of the battle state is being shared and passed around. I’d prefer to do calculation of next state on a server so nobody can intercept and cheat on the client. Also, don’t store arrays in Firebase. You’re going to have a bad time. :D (I initially reached for arrays for item inventory, etc) We use the same battle system for both local and multiplayer, so we’re stuck with Firebase’s opinions on arrays even when not using Firebase. You also have to think through transferring ownership of the “master” role if the “master” client disconnects.

I’m still unsure how multiplayer fits into the future of The Danger Crew, but I think creating this pilot was worth the effort.

These character sprite assets are created with Aesprite then later converted to SVGs.

More content

I made a video walkthrough of the Battle Demo here: Battle Demo YouTube Walkthrough

CodePen Radio podcast episode: CodePen Radio episode

Thanks for reading! I can’t wait to report back soon with this battle system incorporated into the full game.