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
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. I posted about our previous demo back in January. I got to talk about it on CodePen Radio earlier this summer. I’m happy to be back today with another big installment.
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.
Here’s what I wanted to accomplish in this demo:
- Add more depth to the battles
- Try Multiplayer
- Evolve the artwork
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.
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:
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.
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.
All in all, Multiplayer is a ton of fun. I highly recommend sending an Invite Link to a friend or coworker so you can witness the real time tension. (Or me! Send me an Invite Link! Description below!) I’m still unsure how multiplayer fits into the future of The Danger Crew, but I think creating this pilot was worth the effort.
Evolving the Artwork
A really great artist friend of mine originally started the project with me, but he got busy with other stuff and had to drop out. I tried to create more assets imitating his style, but I’m not exactly a great artist. The holistic world view of artwork in The Danger Crew started to feel like a bad night of karaoke. I was really bummed about this until my friends AJ and Mollie stepped in to help.
AJ and Mollie honored the original art and pushed it in a new direction with more detail and better consistency on object perspective. They also increased emphasis on the characters’ laptops because the game is a story about being a developer. I’m really stoked about it!
These character sprite assets are created with Aesprite then later converted to SVGs. (I’m working on another quick post about using Aesprite to create SVGs out of pixel art. I’ll update this post with a link when it’s live.)
The new art style helps the project feel fresh and new for me. It’s the same humor and spirit of The Danger Crew with a fresh coat of paint. I’m excited to see where it goes from here.
I want to give credit to a few amazingly smart and talented people who have provided their talents and ideas to this part of the project:
Glenn LaBarre for TONS of feedback, testing, and moral support. Glenn is also a developer and RPG fan. He was instrumental in helping me focus on the right things and bounce ideas around. He also holds the record for most battles played. I bet he will destroy you if you ever battle him. Any challengers? :D
AJ Manker and Mollie Spencer for the new art and design direction. AJ helped establish a flow for the matchmaking and provided lots of design consultation. Mollie created the lovely new character sprites discussed above. The characters are the lifeblood of The Danger Crew, so this is the most important part!
These people are amazing - I hope you reach out to them high fives on social media.
I made a video walkthrough of the Battle Demo:
Thanks for reading! I can’t wait to report back soon with this battle system incorporated into the full game.
Send me a battle Invite link on Twitter and we'll play! @drewconley13