My first game jam build became my first commercial release - and it's very weird.

I participated in my first ever jam during April's Ludum Dare 41.  I took off that Friday from work, and mentally prepared myself. That night, the theme was announced - Incompatible Game Genres. I jumped into brainstorm mode, having my  boyfriend help me list out genres, then rolling dice to smash them together and see what sticks.

The concept that I chose was a racing-roguelike. The original idea was to make a racing game where you can't crash your car, otherwise your parents "are totally going to kill you." then you are actually murdered by your parents and you have to start from the beginning with a new car, a new teen, and new stats.

I realized quickly that the roguelike elements weren't my style, and that the play wasn't forgiving enough to make it very much fun. I ended up dropping the roguelike elements and swapped it for another genre: Mini-game rush. Distractions like your mom constantly texting you which originally served as a small obstacle became THE obstacle. When a distraction happens, it physically blocks your view. Trying to solve the prompts to make it go away will force you to look at your keyboard to find the keys, which can cause you to crash.

I liked this concept. I'm a huge fan of having mechanics serve the overall message of the game. I also spend my day-job It just seemed like a good fit for me. I decided to develop the game further into a full-blown distracted driving PSA that would (hopefully) still be fun in it's own right. Here are some lessons I was able to take away from my development cycle:

Mechanical spoilers ahead - I recommend trying the game yourself first if you haven't already!

The Mechanic is the Message:

For a game that serves as an educational value, it's incredibly important that the message you're trying to tell is supported by the mechanics of the game. For example - if you're using a game to teach empathy that involves shooting people in the face, you probably won't see behavior change (or worse, see the opposite).

I started by setting the context: the player can't stop the distractions from happening at all, and they can't stop their car when distractions happen. This is contextualized as putting the player in the role of a teenager with their first car. The player character is reckless, a poor driver, and extremely easy to distract. It's the goal of the player to try to keep focused enough to survive each level.

Next, I had to balance the controls. I decided the game had to be hard, otherwise it would make it look like driving distracted is no big deal. Even worse, I didn't want players to think they could "get good" at driving distracted. To prevent this, I designed the prompts to be possible but with RNG elements. Distractions will block specific sections of the screen at random, and the keys needed for the prompt are chosen at random too. This prevents players from remembering key placement and forces them to look away to solve the prompts.

There are some things to ease the difficulty, however; distractions have a slight transparency, so if the player focuses, they can look beyond the distraction to see their car and avoid crashing. Players can also use visual and audio queues, as the sidewalk will glow yellow and play a soft siren sound when the player is too close. This was designed to encourage players to use environmental awareness while driving.

I designed these distractions and audio queues in a way that can make the player feel clever for avoiding them. So far, I've had players report workarounds to try to "cheat" at the game; by abusing the slight transparency of the distractions to see their car, turning off the music but leaving the audio on in the settings, pausing the game to try to find the keys to press for the prompts before starting the game again, having a friend solve the prompts while they drive, all of these attempts to cheat the game actually service the message further. It forces the player to be even more mindful of their surroundings and perform healthy driving habits such as: turning down loud music, having a passenger help you while you're driving, and stopping their car when they absolutely have to answer a text message.

I had to be sure I was rewarding the right behaviors. The conclusion I wanted players to reach in game is that interacting with the distraction actually makes the game harder, and they need to find a way around it. I made the decision early to never incentivise the distractions. Giving a point bonus or an achievement would have weakened the overall message, and can delay the time it takes for this to click with players. I also made sure that players face the reality of things after each level. They are rewarded for finishing a level with facts about accident rates and other grim (but not too grim) reminders. Players that make it all the way to the end are rewarded with a bill of all the property damage, medical bills, and repair costs they gathered as they constantly crashed into people's yards and other cars. Players that complete a level without touching a distraction are granted a "Safe Driver Bonus" which subtracts from their bill at the end to reward safe play.

Without an academic study of this game, I can't say for sure that this will have an impact on teens or adults when driving. Behavior change is a tricky subject. I know that I personally have seen the behaviors in myself and corrected them since I started development (though I feel that's partly because the irony of me dying while playing Pokemon Go while driving shouldn't be the last thing I leave this world with).

This behavior change I've seen in myself is most likely due to repetitive play, which is shown to have more of an impact on behavior change. Because my game was designed to be played in just one or a few sittings, I suspect any behavior change would be temporary.

Lessons Learned:

It's not a post-mortem without some introspection. Overall, I'm happy with how my first commercial release came out, but here are some lessons I'm taking with me into my next build:

Making a game educational and fun is a bigger challenge than it sounds - The game as it is now suffers from the internal struggle of making the mechanic stay on message, and keeping the game fun for general audiences that don't care about the message at all. This could have been solved for in a couple ways - such as making separate versions for educators and general players, or scaling the difficulty at a slower pace. The game could have benefited from even more playtesting to allow me to find that balance. 

HTML5 is fickle, but essential, and needs extra care - I was concerned I wouldn't even have an HTML5 version of my game ready by my decided launch day, but was thankfully able to get it up and running just in time. However, I encountered functionality issues with HTML5 all the way to the end, and still experience issues depending on the machine it's being played on. Having a corporate computer, I know all too well that company and school firewalls can absolutely wreck a browser-based game by blocking essential elements that prevent it from performing across all machines. While I can't control for every instance, if you ever plan to launch for HTML5 to reach a larger audience, plan for this early in your development. It will save you a lot of headache if you prepare for it up front.

Overall, I just wanted to make a game that was short, to the point, and fun. I've crafted a facilitator's guide to help teachers include this into their classrooms, while providing additional context that may be lost on solo play. While I hope it can have an influence on preventing dangerous behaviors, I'm happy with the final result regardless.