There is no reason, in 2018, not to make a video game.
The kids and I made their mom a pretty awesome Christmas present that I haven’t taken the time to tell you about until now. It turns out that it’s a story that’s longer in the making than I realized.
Some years back I made a bold claim, as I’m known to do from time to time. It was made on this blog, publicly, in an attempt to keep myself honest.
2012 is the year I make a video game… to challenge myself, to put something together in a medium that will tax my writing and artistic abilities, my direction and my ability to create something complete.
Well, 2012 wasn’t the year I made a game. Neither was 2013. Neither were the three years after that. It wasn’t a total loss, as the general concept for the 2012 adventure game eventually became my novel The Amundsen Effect, four years later.
But then, totally unexpectedly, five years later, 2017 became the year I made a video game.
The RPG Maker software has been around in various forms for two decades, and innumerable games have been built using its tools. Those who played classic Final Fantasy games and other JRPGs know the style of game well – top-down open-world adventures, starring a party of characters who level up as you progress through the (usually epic) story. Back in October 2017, Humble Bundle sold a bunch of RPG Maker stuff for pennies, and I and nearly 47 000 others picked up one or more versions of the software, some asset packs, and a handful of games. And as we approached the holidays, I had a silly idea. And so I broached it with the kids: What if we made your mama a game?
Pretty much every holiday, as we spend some time with her family, NJ reminisces about how she and her dad would play the original Legend of Zelda on the NES. She has a lot of fond memories of working out the puzzles as her dad controlled the action. It wasn’t a JRPG, exactly, not in the style that RPG Maker lends it to, but it was close. And so the kids and I hunkered down and outlined a short game, which ended up with the title Mama vs. the Monsters.
It was a ridiculous thing, half video-game and half scavenger hunt. She’d have to solve puzzles in the game, follow clues in the real world, and use the solutions and clues in both the real world and the virtual one to beat the game. Monsters had taken over the house, and NJ would have to reassemble the scattered family to defeat the monsters and their boss and save Christmas.
It meant a lot of late nights (both for me and the kids) as we built environments, wrote dialogue and descriptive text, tweaked combat difficulty, and tested the game. But when we finally revealed it, NJ enjoyed solving the puzzles and was struck by how personalized it was. “And,” she said, when I asked her about it for this piece, “honestly, it was nice having a game in this style that I could actually sit down and beat” – the hour-long experience didn’t overstay its welcome. The kids were thrilled to unveil our project, and were so excited they could barely keep from spoiling the puzzles.
And on my end, not only had I seen those three faces light up as they played, but five years since declaring I would I had suddenly actually made a video game. Not dabbled with the tools, not sketched out a design doc – made an honest-to-goodness game, start to finish.
Look, there are so many non-programmer-friendly tools out there – whether it’s RPG Maker, Adventure Game Studio, Construct, Game Maker, whatever – that there’s no reason to not make a video game. If you want to learn to code and need a game engine, Unity and Unreal are both free. There’s a Humble Bundle which, at time of writing, has a couple of days left on a deal to get coding books for as little as a buck. There’s no reason to not make a video game.
In the interest of our mission here to encourage and promote project-based learning, there were some lessons learned about our project, so instead of just telling the story, we want to leave you with some of the things that worked well for us as we started making our game.
Scope your game small.
This means not just a tight, limited narrative, but keeping the maps relatively small and the combat relatively sparse. By scoping a small project, you can focus on adding density and depth in your limited amount of development time instead of stretching to try and make something expansive. Focusing on density makes the small environments of your small game feel more real and more explorable than a large empty world would. Mama vs. the Monsters had only eight relatively small maps (outside our house, garage, main floor, basement, upstairs hallway, kids’ rooms, and master bedroom), all of which had some interesting stuff going on.
Outline. Know where the game starts, where it will end, and how you get there.
Without planning, getting from one story point to the next is a chore. It’s already not easy to build the logic of your game to get from point A to B. If you’re making up point B on the fly, it’ll be far more difficult to get there. So, in short, outline your game. We wrote a one-page outline that was essentially the objective > puzzle > solution loop, repeated until we got to the end of the game, and it made building the progression of the game much, much easier.
Don’t be afraid to go a little bit off-book.
A couple of our favourite moments and jokes in the game came from riffing in the writing as we were building the game. We never deviated from our outline, but we improvised big chunks of the actual script as we went along. Just because things were outlined in a bare-bones way didn’t mean we couldn’t fill in those outlines with colour and texture!
It’s okay to use stock assets while you’re learning.
Colour and texture doesn’t mean that you have to create it all from scratch. We used the standard, built-in graphics and sound for RPG Maker when we built Mama vs. The Monsters. The point was the process of building the game and crafting an experience for the player. Your next project can be a masterpiece – your first just needs to teach you the ropes.
Bug testing is never enough. Be afraid of bugs. Sometimes, they end up being terrible.
In spite of countless playtests, we still managed to miss things in our game. There was a Christmas morning re-upload of the game files to fix things, including a game-breaking bit of bugginess that would have kept us from completing the puzzle.
Also: don’t be afraid of bugs. Bugs are teachers, and sometimes they’re not bugs at all.
Until you ship your game, bugs are good. Fixing bugs is an excellent way to learn the ins and outs of whatever system you’re using. I certainly know way more about RPG Maker now than when we started, and I’d venture that most of the fine-detail learning I did was in the back half of bug testing – not during development.
But sometimes, to paraphrase Bob Ross, a bug isn’t a bug – it’s just a happy little accident. In our game, when the player enters the house, we have our dog Leo running around, greeting you and following you around. At one point we accidentally set his speed and the randomness of his running around way higher than it should have been – and it totally worked! It looked exactly like his approach and behaviour when we come home after hours away. It was a total goof, and we laughed so hard we had to take a break. It’s still one of my favourite parts of the game, and one of my favourite memories from development.
It’s okay to be personal.
The thing that propelled us – other than a Christmas Eve deadline – was the fact that we had a solid, intrinsic reason for building our game. We weren’t trying to build something for market, we weren’t looking at what’s hot on Twitch, we weren’t looking at anything happening on rpgmaker.net. We just wanted to make someone smile, and to make ourselves smile too. That’s it. And we nailed it.
When you start to develop your first game, just do your thing. Do the thing that feels good for you, and ignore the rest. Because if you get this first thing done – complete a game that means something to you – it won’t just be a finished project, it’ll be a victory.