The Danger Crew RPG: Lessons Learned by Drew Conley on CodePen

The day is finally here. The Danger Crew, an RPG game built with React and Redux, is ready to play!

I made a Celebration Pen for it:

Intro and Background

I started The Danger Crew with two friends in October 2015. It's built with React and Redux. It's mostly all DOM elements and CSS trickery, but I've also updated part of it to use canvas. We published our first demo on CodePen in March 2016.

There have been other demos since, like our Battle Demo and a few public prototypes. (I also have a Private Collection of over 100 "draft" Private Pens of the game. See the bottom of this post for my favorites.) I gave a conference talk about it at React Rally in August 2016. Many other cool things have happened around the project, but it all came down to this moment, the full blown demo is READY!

Every part of the game has been revisited and beefed up since last time I wrote. While it looks pretty similar on first glance, we've added way more depth. Customizable characters, revamped battles, upgradeable character laptops, and way more.

I'd like to share a few lessons I've learned in the last ~15 months from bringing this side project to life. These lessons have helped me grow as a developer, product owner, team leader. They certainly apply to our game, but I think they will help with YOUR game or big project too.

1. Want to build your first game? Start with whatever tech you know

I started the project without <canvas>, because I was basically afraid of it. I'd never used it and the "cool" demos around were scary mazes of math and numbers. I only know how to count to four. It seems like every article about game development on the web assumes that games require canvas.

We had the idea for the game, we wanted to get started Now Now Now, and didn't want to lose that spark of inspiration. Moving DOM Elements around with translate3d seemed to work fine, and I'm really comfortable with React, so we just went with that.

Somewhere along the way, I started tinkering with canvas and totally fell in love. I made this little Mega Man demo to practice the concepts. I'm glad I learned it. It's actually not scary at all!

It's okay to get started with whatever you already know. You don't necessarily need React, Vue, Redux, Angular, {insert other tech everybody is talking about}, whatever. Knowing a specific framework or tool should not be a barrier to entry. Just start building your vision with whatever you know. Make adjustments when the tech doesn't meet your needs. (By all means, if you are hungry and wanting to learn new things, go learn them! Just don't say "I don't know X so I can't make this thing.")

If your game idea is big and ambitious, drill it down to the most important mechanics and nail those first. For me, the most important parts were Overworld walking and Battles. I used CodePen to prototype them both separately. (Links are available at the bottom of this post.) The rest will naturally come as the project grows.

2. Know your content before you build too much

My smart friends and mentors call it defining the "WHAT" before jumping to "HOW".

We released our first demo then immediately reevaluated everything we had build. It was time to tear the project apart so we could make it better. Two major areas for growth were identified:

Needed deeper battle mechanics
Needed a pause menu that supported player's decisions for these new battle mechanics

Seems pretty clear which one should be worked on first, right? I had a shiny idea of what a new pause menu layout could look like, so I jumped straight in to that. Doh!

I wasted four weeks designing and developing a complicated pause menu that ended up getting trashed. I didn't know the purpose it was going to serve. We hadn't figured out the true battle mechanics, so the project wasn't ready for this fancy new menu.

I had awkward layout space to fill, so I started adding options that "would be cool" but ended up adding no value to the core of the game. I introduced UI styles that weren't seen anywhere else in the game yet... it was an identity crisis because I was trying to build and design for content that WASN'T THERE yet.

I hate showing these painful screenshots, but I'm writing here to share the journey's ugly parts too:

First Pause Menu Screenshot from first demo. Humble beginnings. The game was really simple back then, so these minimal pages were good enough.

Early screen capture of the version I wasted a ton of time on. You could fully customize your battle laptop, sell upgrade parts, change your attack loadouts, and more. There were fancy page transitions, but the interactions were weird and content was disconnected from the game. After finishing the new battle mechanics, Laptop parts needed to serve a totally different purpose than what is pictured here. This all got trashed and I nearly gave up.

Beta Pause Menu Here is where I ended up AFTER deciding on new battle mechanics. The content within each page supports decisions a player will make in the game.

It seems like common sense, but sometimes we jump into code (or a design program, or whatever) before knowing WHAT we are really trying to make. It feels productive at the time but it might just contribute to burn out.

3. Build tools for yourself to make the game better

One key to sustaining a big project is to defend against little time-sucks. Here are the tedious things that came up for me:

Lots of dialog to test: As the story grew, more and more variations of conversations with NPCs could occur. Character dialog is driven by a mechanism called Story Pointing: simple flags that indicate you've done something. Dialog will change based on your collected story points. I made this simple text input that edits Story Point flags for testing dialog changes on the fly. This makes it easier to recreate a player's progress for debugging.

[Dialog changes based on your collection of story points.]

The dialog text is driven by your collection of story points. This simple textbox makes it easy to quickly add Story Points to test dialog changes.

Complicated battle possibilities: There are TONS of moves that can be executed in battle. It took forever to test all of the combinations that could happen because the battles are long sequences of animation and scrolling text. I made a Console View that displayed the battle in a high level "admin" mode. It includes time-travel rewinding, and on-the-fly stat adjustments. I could now test any battle situation very easily.

Console View

Quest visibility: The Danger Crew has a main story with supporting side quests for the player to complete. I built a simple dashboard that tracks user progress through each quest. This helped me figure out which ones were being skipped (or never found) by play testers.

Pena Progress

This is a cropped screenshot of our quest completion dashboard. Almost all play testers triggered the beginning of Problems With Pena quest but didn't get any further into it. It wasn't very clear where to go or what to do.

Travis Pena NPC

Placing NPC dialog here introduced players to the Pena side quest, making them more likely to associate this location with the quest.

Tools don't have to be big or fancy... they just need to save you and your team a few steps in the testing or creation process. Every morsel of saved time can be put towards more quality and detail for the game.

4. Let people help you

Games are big projects because they require SO MANY THINGS. Stories, graphics, sound, programming. It's the ultimate art form. If you're stuck, find people who can help. CodePen is a great place for that.

One of my favorite parts of The Danger Crew has been seeing the work contributed by my friends. Henry Leacock is an amazing musician (and developer) who contributed a KILLER soundtrack and sound effects. David Stout did the original character sprites and handwritten bits. Brett Banning contributed some branding direction and a few sprites for interactive objects in the world.

I think loneliness is the most common reason people quit ambitious side projects. It sucks to put your heart into something and feel totally alone when enthusiasm dries out, or negative comments come up. Don't feel like you have to do it alone.

The Danger Crew RPG: Lessons Learned

Intro and Background

1. Want to build your first game? Start with whatever tech you know

2. Know your content before you build too much

3. Build tools for yourself to make the game better

4. Let people help you

More Links:

I've shared some thoughts about game concepts before on CodePen. Here are my previous posts:

Here are some Private Pen links to some of my favorite prototype concepts: