The Hero’s Journey and the 2D Game
Disclaimer: Any similarities to persons, living or dead, is entirely coincidental.
Part 1: The Hero’s Journey
The hero sits at their computer, staring at a blank canvas. They’ve finally graduated and landed a junior developer role at a company that prides itself on providing healthcare and “being cool.”
It’s finally time to do something fun. No more coding classes! No more being told what to do! (Except 8 hours a day, five days a week).
Our hero downloads MonoGame. After poking around, installing a few frameworks and this strange, strange mammoth —known as Visual Studio — they finally see their empty game project staring back at them, eager for more.
As the weekends go on, their little game becomes more and more sophisticated. Life is good. Their peers on Discord are excited to see what they’ve added to their little project. But then the swarm comes.
The Bugs.
At first, it’s just one here and one buried over there. Most of them are already half dead by the time they’re discovered, laying on their backs underneath the fluorescent glow of the monitor. Nothing to swat a fly at. But they won’t go away. The just keep crawling in, one by one. The become bigger, more time consuming. As the codebase grows larger, so too do the bugs. Eventually, the bugs seem bigger than the project. Why is the player running through walls? What is line tracing for collisions? Is this why people use physics engines? It’s all starting to make sense — all those forum threads the hero glossed over about dependency injection, physics engines, and testing are starting to make sense. If only they’d noticed the graves of the fallen heroes that tried to warn them!
But it’s too late. The bugs won’t go away.
The hero sinks into a dark depression. They know what’s wrong with their game. Things that should be inter-module dependencies are baked into their classes, coupling unrelated pieces of code together. They should have extracted more interfaces or used virtual classes to make game-loop update logic simpler.
They try to refactor a class, but are met with hundreds of errors as every other class in the project suddenly breaks. “Okay,” the hero thinks, “I will at least add one of these unit tests I’ve heard so much about.” But it doesn’t work. Because their game code is practically tied to a single platform, it can’t even run in the testing environment.
They know what’s wrong but they don’t know how to fix it. Should they just rewrite the whole project? Our hero no longer has the energy. The once youthful look has left their face. All that’s left is a pair of hollow eyes staring back at the dim glow of the darkly themed code editor.
The story wasn’t that good anyways…maybe game development is best left to the professionals, or maybe they can be happy just playing Stardew Valley. We can’t all be ConcernedApe, after all.
Dismayed, the hero pushes the last commit up and resigns themselves to being a programmer by day. When they see any pixel art anywhere — even hanging in a GameStop window on a promotional piece of advertising — it stings. Game development is hard.
The quest is over —
Part 2: The Hero Strikes Back
Nope! It’s been a year and our hero — now a mid-level front-end developer who’s happily chugging away at tickets on a project they didn’t create — has a much better idea for a game. This one is worth braving the dragons, er, bugs of yore! The quest is on!
Things are different. Their job has slowed down enough to write the occasional unit test…they are no longer scared by the idea of testing code, although it is a bit of a hassle. This “mocking thing,” however, seems like a lot of work.
Our hero takes care in setting up the project this time. “I will setup unit tests,” they say. As they go deeper into the cave, they hear a snarl of the vilest creature they will ever encounter — a deep, dark roar echoing throughout the cave’s many chambers. Is this what they had heard their senior developer colleagues muttering about as they slept with their heads against their keyboards, ever waiting on the build to compile?
Undeterred, they press further. Eventually, they reach the ominous roar. As they come around the corner, they see it in the light — the viscous, awful creature known as The Tools! It stands there, glaring at them with smoke seeping from its nostrils, ready to devour them.
Why won’t this CLI tool setup the project correctly? Aren’t these templates supposed to work out of the box? Why did autocomplete stop working in my code editor? Why is it telling me the project is out of date right after I created it? What is dependency resolution, exactly, anyways? What! My code editor just crashed…again?!?!
How many command line tools must I vanquish? Why are all the project files in…XML? Will I ever get to code again? Wait, how did I do that last time? Was I supposed to be taking notes? I’ll just delete the project and start over. Surely the template generator will work this time…is this what the rest of my career will be like? Is this what they tried to warn me about?
This is nothing like the spark of joy the hero first felt when hacking away on their buggy, platform-dependent 2D project in years past! Game development is not fun — it’s objectively awful! It’s serious work, even! If The Tools are always trying to fight you, how are you supposed to get anything done?
Time to go back to playing Stardew Valley. Maybe they can stifle this stupid itch to make something once and for all. Perhaps they can extinguish the fire burning inside them…the Eternal Flame of Game Development. Eventually, the fire dwindles to a small, sputtering candle, locked in the darkest parts of their heart — never to be seen again.
Part 3: The Master Magician
Years have gone by. The hero, now with an aged, worn face, emerges from their commute and settles down into their dwelling. Their skin has been worn down from years of squinting in dim monitor light, a few wrinkles are beginning to distract from their once youthful face.
A decade of of programming has taught them how much they actually don’t know, and the hero has finally accepted that programming is not about the languages or tools involved, but about problem solving in general. Revered by their colleagues as a master witch or wizard, the hero, now a senior engineer, can be seen quietly coding away at their job, occasionally turning on their webcam to laugh with coworkers or give dirty looks to a project manager.
When approached by others, they play down their skills — not out of humility, but to avoid being given more responsibility. They have enough to do. When asked by younger coworkers to help with hobby projects, they offer helpful architectural advice but refuse to commit.
One day the hero wonders…why do I keep refusing to help with other people’s passion projects when I finally have the skills to help someone succeed?
It’s at this moment they realize: the call of the quest still lives inside them! The Eternal Flame of Game Development never died! They still want to do their own project! It all makes sense!
They look in the mirror for the first time in years. They cut their overgrown, neglected hair…or perhaps trim their beard. It’s time to try again.
This time, they are immediately greeted by their old enemy, The Tools, before they’ve even left the tutorial grounds. With a twinkle in their eye, the master magician pats his lap and invites the much smaller, less scarier looking pet version of The Tools to sit in their lap while they find a solution that works for both of them.
When they realize their Omnisharp C# plugin won’t generate launch.json files for them because of a bug in a recent extension, they patiently uninstall the current version, hunt the correct version down on the extension’s GitHub release page, install it, generate the files, and update back to the newest version. Instead of being afraid of The Tools, they make Git commits they can easily revert to. They know the road is long and painful, and few there be that survive it. The hero uncovers the sacred documents that describe proper project setup, buried on an obscure branch of a personal project by the creator of MonoGame itself. Little by little, they keep tunneling through the dark dungeon until they reach the light of day:
A beautiful, multi-project C# solution with testing, shared platform independent code, and platform dependent projects. Everything runs in the debugger, everything was setup carefully by hand using the dotnet command line utilities. A tear slides down their face. They look up just in time to see Mufasa smiling down at them.
From here, making a game seems too easy. It’s almost a little overwhelming. With stubs in place for game code, tests, and mocks, there’s nothing left to do but build the actual game. And build they do. The spark of hacking away at a 2D game comes back, tempered by the grind of writing tests. Little by little, they finally construct the 2D game of their dreams.
Because they’ve setup the project so well, publishing it isn’t all that hard. Sure, there’s a learning curve, but it’s a whole lot smoother than it could have been — would have been.
After over a year of development, our master magician releases their game. They’ve poured their life, their soul — their heart — into it. It would win awards. The world has never seen anything like it!
But no one buys it.
Part 4: Becoming the Villain
How could this happen? I spent years on this! I didn’t work for years to become an indie game developer for my work to go unnoticed! Those are the type of thoughts that fill our hero’s head.
As the hero expresses their dismay to friends, one of their more evil friends who actually helps businesses sell products (rather than the chumps who build products) informs them that they failed to market their game.
At first, the hero doesn’t believe it. How could so many other people successfully build a game when it’s SO HARD? After some googling, it turns out that everyone else actually use game engines, like sane people, rather than just a framework like MonoGame that lets you do everything yourself. Some of them even used GameMaker! What double-dealing imposters! They didn’t earn it! I made this game with my blood, sweat, and tears!
As the googling continues, the master magician realizes their mistake. They didn’t start a Discord server and post developer updates. They didn’t pay for ads on Facebook, or even start a Facebook Page. They’re not even on Facebook anymore! So many missed opportunities! They could have started a patreon, streamed development on Twitch, or made a YouTube game development log. But no, they coded away in silence.
Frustrated, they forget about their game and leave it on Steam. It gets a few players who love it. After a few months, they check on it and realize that there’s a handful of people who actually like it. But then our hero realizes something:
The game could be so much better. What they’ve created is really just the start of something much bigger.
Frantically, our hero scrambles to start a Discord server. They post game development updates. They take community requests. They create more art, expand the lore, and refactor the code. A following emerges. Regular updates begin flying out. They integrate SteamWorks and begin pondering a multiplayer option. Their code wouldn’t need to be changed all that much to squeeze it in…Other people offer to help them. The hero hires someone with the game’s sales to manage the marketing aspect. They form a small game studio.
As the months go on, the hero, now a mastermind marketing manipulator who’s started their own game development studio, has become the very thing the indie developer inside of them hated: a game development business.
The End.
