The Process
The Idea
After the theme was announced, brainstorming began immediately (my boyfriend was a good sport and helped by letting me bounce ideas off him, despite being violently ill a few hours before the beginning of Ludum Dare and only waking up 30 min before the start). We wrote down twenty different genres on a dry erase board and rolled a D20 until we had 8 pairs. From the 8 pairs, we dropped 4 that felt like immediate duds. From that 4, I wrote a very short potential design document and risk assessment to figure out which idea I would pick.
I only ended up writing two of these up, as I ended up falling in love with the final idea very quickly. I had also considered making a tower-defense/visual novel where your performance in a cursed, crappy tower defense game determined what would happen in a visual novel, but decided against it as making enough content to make a visual novel interesting in 48 hours would have been too much for a first jam. Still think it’s a cute idea.
Pure chicken scratch
The original concept was a Racing/Roguelike, where you are a teenager borrowing your parents’ car to race competitively, and damaging your car would result in your parents “totally killing you” and you have to start all over with a new teenager and stats. These stats were going to influence things like how well you drive, how hard the distractions would be, and whether you were able to repair damage to your car yourself.
Prototyping
I first started with a paper prototype, which mostly just served as a visual prototype. Cam drew a level and I cut out a window from another piece of paper to act as the camera view. We used a cake board game piece from the Portal board game, and a 4-Sided Die and a metronome. We moved the camera view to the metronome beat, and randomly I would put a “distraction” on the board, then roll the 4 sided die to determine how long the distraction would be in the way. This probably didn’t help identify how the car would actually move, but it did help establish some mechanics, like answering texts as you drive, and how the car is in constant motion and you cannot stop. The original window was also much too large and revealed too much of the level at once, so I made it smaller. While you can only paper prototype a driving game but so much, it was still very helpful!
This is probably the most useless looking paper prototype ever made
Day 1
I started with the basics – getting the car moving in a way I felt worked well. I decided early on that, since the main character is supposed to be a teenager, the driving probably shouldn’t be super tight and precise (less work for me!). Narratively, having the driving feel like you’re a professional driver wouldn’t make much sense.
Once the base driving was there, I had to start establishing the rules such as what happens when the player collides with walls? To simplify things for myself, and prevent people from being disoriented when hitting the wall, I went for the “don’t touch the sides” approach. It was the simplest solution for handling the failure state, but this decision ended up being a factor in changing the theme. At this point, the game was already pretty fun! The driving was a bit sloppy, but it made navigating these very simple test levels feel more challenging. I spent too much time just playing in this phase I think.
I also made a quick model for a teenage girl to get ready for the procedurally-generated teens. I use Illustrator to make the base with the intention of putting her in After Effects using the DUIK plugin to rig her, then put her in various poses and exporting as a single frame. This would let me make multiple poses for one female model quickly and also swap out color palettes for her skin quickly too.
This never made it into the game, but she’s there to be rigged later if I ever need it.
Day 2
I basically woke up realizing I wasn’t into the roguelike theme anymore. I felt that there wasn’t enough of an incompatibility in the genres (because yeah, if you total your car, you lose that car. That’s just real life) but I still liked the distractions that were meant to make the game harder. I also realized other decisions I made would have made the roguelike portion very slow, and annoying, having to reroll for a new character after every death. (Also, did not have time left for procedural generation. Was already cutting it). So, I decided to scrap the genre entirely and focus on what I already had – minigames!
I had already programmed the first minigame and created the mechanism to generate them, and it completely changed how the game felt. Now I was desperately trying not to touch the walls and what was originally a decent driving game was now an anxiety-filled gauntlet...I kind of fell in love with it.
I decided to run with this, and maintain the games difficulty. I added 3 other minigames, some more polished than others, and built a few more levels. I didn’t have any time left to polish the graphics, and I had Cam search for free music and generate sound effects from bfxr.net. Cam had an idea of the walls changing color to emphasize the “don’t touch the sides” feel. I went a little further with this, having the walls change from yellow, orange, and red, depending on how close the player got. I also added a siren sound when getting to close. These visual and audio cues seemed to help offset these crazy large distractions completely blocking the view. I had considered making these distractions partially transparent, but that made the challenges a bit too easy and defeated the purpose. So now, players can listen to the audio cues to correct themselves or see the crazy amount of red on the walls.
What Went Right
The blend was surprisingly great (I think) – for two incompatible genres, this was actually pretty fun. By dropping the roguelike theme, the game basically became a “Distracted Driving PSA”, which is great since my day job is making educational material (and eventually educational games) and it was great practicing making a game where the mechanics had to serve the message. While it’s not foolproof, play testers were immediately able to pick up on the theme and message without it having to be shoved in their face, which is always ideal!
The simple graphics and levels helped – While I was upset I didn’t get to use my artistic skills in this project but so much, I think it worked to the games favor. Watching play testers, most enter the game not expecting much of a challenge. Somewhere around level 3 is where things start to click for people. Suddenly they’re cursing at the screen and having very physical reactions to crashing the car. From the playtesting, I’ve watched personally, people get INTO it. I felt like a proud mama. I think the readability was also helped by the very basic colors and details, especially considering how the screen is literally blocked for portions of the game.
The little things – The visual and audio feedback for walls, the placement of event tripwires, not putting a point incentive to the distractions so players to choose to ignore them (Which you SHOULD be doing. You’re driving!) and that the car moves forward on its own. That last one is honestly important. It keeps players from having this moment of “what am I supposed to do?” and turns it into “oh god I’m moving!” and helps with the immediate engagement as well as adds a layer of urgency to the entire experience.
My design instincts are better than I expected – This could just be good luck, but I think my instincts have improved a lot from my studying. I’ve spent months studying game design preparing for the initiative to bring game-based learning to my day-job and I feel like I learned a lot. That being said, the best thing for me to do is to keep making games, and that’s what I intend to do with help from game jams like these!
What I Probably Should Have Done (But Didn’t)
I need a team, I think – While I’m glad I took my first one on alone, I would have been infinitely more productive with a team to take on different tasks. There was a meetup in my area, but with my boyfriend getting sick, I sort of used that as an excuse for my anxiety to talk me out of going. I will most likely push myself to actually go next time (or remote work, there’s options).
Better scheduling – So I didn’t take Monday off work and I regretted it. I would have loved to have that extra day to go back in and polish things, but I’ve learned my lesson for next time. Also, I probably slept a little too much (who needs 7 hours of sleep? Wasteful!) and there was some procrastination. Now that I’ve been through my first, I’ll know what to plan for next time.
The little things again – A lap counter, skipping the tutorial on level one, probably should have built a level 1 with no distractions to let players get used to the driving controls, etc.
What I Took Away
This was my very first game jam, and I may be hooked on them now. The adrenaline of coming up with my idea, the workflow of throwing a prototype together, the satisfaction of watching people playtest my game, there’s nothing like it.
Whether I’m going to do much more with this prototype is still up in the air, but even if I don’t, I feel like I learned so much from this project I’m ready to start building even more!
Also, I friggen love this little prototype. It’s like my baby now. My very infuriating baby.
What I Used
GameMaker Studio 2 for programming, art, and animation
Bfxr.net for sound effects
You Should Play!
You can play the game here: I have enough votes for a final score, but I would love additional feedback in case I do pick this back up and polish it into a game teaching kids to pay attention to the friggen road or something.
Have fun!
https://ldjam.com/events/ludum-dare/41/minigame-racing
Pure chicken scratch
This is probably the most useless looking paper prototype ever made
I started with the basics – getting the car moving in a way I felt worked well. I decided early on that, since the main character is supposed to be a teenager, the driving probably shouldn’t be super tight and precise (less work for me!). Narratively, having the driving feel like you’re a professional driver wouldn’t make much sense.
Once the base driving was there, I had to start establishing the rules such as what happens when the player collides with walls? To simplify things for myself, and prevent people from being disoriented when hitting the wall, I went for the “don’t touch the sides” approach. It was the simplest solution for handling the failure state, but this decision ended up being a factor in changing the theme. At this point, the game was already pretty fun! The driving was a bit sloppy, but it made navigating these very simple test levels feel more challenging. I spent too much time just playing in this phase I think. 
This never made it into the game, but she’s there to be rigged later if I ever need it.
I decided to run with this, and maintain the games difficulty. I added 3 other minigames, some more polished than others, and built a few more levels. I didn’t have any time left to polish the graphics, and I had Cam search for free music and generate sound effects from bfxr.net. Cam had an idea of the walls changing color to emphasize the “don’t touch the sides” feel. I went a little further with this, having the walls change from yellow, orange, and red, depending on how close the player got. I also added a siren sound when getting to close. These visual and audio cues seemed to help offset these crazy large distractions completely blocking the view. I had considered making these distractions partially transparent, but that made the challenges a bit too easy and defeated the purpose. So now, players can listen to the audio cues to correct themselves or see the crazy amount of red on the walls. 
It's still frustratingly hard, but I've gotten slightly better with practice
_Here is a little dance I accidentally animated
I still rather like the cryptid pokemon snap game idea, but I'll save that for another time.
I also created multiple heads with different faces I can swap between
Dem Bones
Wiggle, wiggle
