How to Make a Game: Lessons from Building ‘Atomic Overdrive’

Every finished game tells two stories.

The first is the one players experience. They race through levels, master mechanics, overcome challenges, and (hopefully) have fun. The second story is largely invisible: months of experimentation behind the scenes, ideas that changed, mechanics that failed, features that were cut, and hundreds of decisions that shaped the final experience.

When programmer José Miguel Carrillo looks back on Atomic Overdrive, that's the story he remembers.

The multiplayer racing game his team eventually released wasn't the same game they originally pitched. Systems were redesigned, priorities shifted, and assumptions were challenged through constant playtesting.

That's the reality of game development.

Whether you're building your first student project or your tenth commercial title, making a game is rarely about executing a perfect plan. It's about discovering what works, understanding why something doesn't, and having the confidence to change direction when the evidence tells you to.

To explore what that process really looks like, we'll follow the development of Atomic Overdrive, created by students in Vancouver Film School’s Game Design program. Through interviews with José, instructor and game developer Christopher Mitchell – whose credits include The Simpsons: Hit & Run and Crash of the Titans, the latter earning him a Writers Guild of America nomination for Outstanding Achievement in Video Game Writing – and the team's production documents, including concept boards, design documents, pitch materials, and post-mortem reflections, we'll trace the game's evolution from its earliest ideas to its finished release.

Along the way, you'll discover lessons that apply to projects of every size: how to establish a clear creative vision, why prototypes matter more than perfect planning, what playtesting reveals that documentation never can, and why collaboration is often a team's greatest strength.

Before diving in, it's worth recognizing everyone who helped bring Atomic Overdrive to life:

Core Team

• Tomas Alvarez Martinez – Project Manager & Level Designer
• Beth Angarita Torres – 2D/3D Artist & UI/UX Designer
• José Miguel Carrillo – Programmer
• Jamie Dunn – 3D Modeler & Video Editor
• Kian Lynch – 3D Artist, Rigger & Animator
• Jayden Chambers – Programmer & Level Designer

External Collaborators

• Carlos Lopez – Concept Artist
• Valentina Castro – Concept Artist
• Cam Saldana – Audio Manager
• Eduardo Mohler – Music Composer
• João Picolo – Music Composer
• Jaime Bibiano – Sound Effects Designer
• Nicholas Donis – Sound Effects Designer
• Mike Guerra – Sound Effects Designer
• Jacqueline Galindo – Sound Effects Designer

Like most games, Atomic Overdrive wasn't built by a single discipline or a single person. Every design decision depended on collaboration between programmers, artists, designers, animators, audio specialists, composers, and producers – an experience that would ultimately become one of the team's biggest takeaways.

START WITH A STRONG CORE, NOT A LONG FEATURE LIST

Every game begins with an idea.

The challenge isn't coming up with one – it's deciding which ideas deserve to survive.

For the team behind Atomic Overdrive, the project began months before anyone wrote code or created 3D assets. During pre-production, they developed a concept document for a game called Screen Lines, a third-person racing platformer where players competed for the fastest times through a futuristic city. Many of the core ideas that defined the finished game were already there, including multiplayer racing and gravity-defying movement, but the experience looked noticeably different from what players would eventually download.

"The original two-sentence description was a third-person racing platformer, where you alone or with your friends would play as a cog bot and compete for the best race times in the dystopian city of Droid Void. I think the finished high concept is very similar except for the part that it's no longer a platformer. We changed around some words, the character, and even the city."

At first glance, those changes might seem cosmetic. In reality, they reflected one of the most important lessons in game development: your first concept isn't a contract.

As production progressed, the team continued returning to a simple question: what experience were they trying to create?

Initially, that experience leaned heavily into platforming. Inspired in part by Nintendo’s Super Mario Galaxy, players would race while navigating gravity-shifting environments, jumping between platforms, dashing through the air, and driving across walls and ceilings. The idea sounded exciting on paper and made for a compelling pitch.

But ideas don't become games until players get their hands on them.

As prototypes became playable, the team discovered that the extensive platforming wasn't creating the experience they had imagined. Constant camera shifts made navigation disorienting, and the emphasis on precision jumping distracted from what players enjoyed most: the speed and momentum of the race itself.

"Originally, we wanted to push way more on platforming. We had a level design with a lot of jumps, and very quickly we realized it was really hard to play. The camera was shifting around a lot, it was easy to get disoriented, and in the end it just didn't feel right. We ended up focusing more on the racing aspect of it – specifically, going fast."

Rather than forcing the original concept to work, the team let the game evolve. Platforming was scaled back, racing became the primary focus, and Screen Lines gradually transformed into Atomic Overdrive.

Interestingly, not every early idea disappeared. Some simply became less visible to players. The fictional city was renamed, characters evolved, and pieces of worldbuilding remained behind the scenes, quietly informing the game's identity even if players never explicitly encountered them.

As Christopher Mitchell, Head of Game Development at Vancouver Film School, points out, that's often how game worlds are built.

"The developer knows a lot of stuff that the user never does, but it still kind of subtly informs the world that you create."

That's an important distinction for aspiring developers. A strong concept document isn't valuable because every idea survives production. It's valuable because it gives the team a foundation to iterate from. As new information emerges through prototyping and playtesting, the details can change while the core vision stays intact.

Lesson Learned: Don't fall in love with every feature in your original concept. Fall in love with the experience you're trying to create. The mechanics that best support that experience will reveal themselves as you build and test your game.

BUILD THE HARDEST THING FIRST

One of the biggest misconceptions about making a game is that your first playable version should look impressive. In reality, its job is much simpler.

A prototype answers questions: Can this mechanic work? Is this system fun? Can we actually build the technology we've envisioned? The sooner you answer those questions, the sooner you know whether your project has a future.

For the Atomic Overdrive team, there was one question that overshadowed everything else.

Could they make online multiplayer work? It wasn't just another feature on a checklist – it was the foundation the entire game depended on. Without it, there was no multiplayer racing experience to build.

José remembers that concern shaping the team's priorities from the very beginning.

"Our first build was actually pretty complete for what was asked for. We needed to demonstrate certain technical feasibilities, like our online multiplayer. It was a concern for a lot of our instructors whether we could actually pull it off. So for our first prototype, we decided to focus on that and get it working."

Rather than spending months polishing environments or refining visual effects, the team concentrated on proving their greatest technical risk. Using the multiplayer networking solution Coherence, they built a prototype where multiple players could successfully connect and race together.

"It was really cool to see that it would just work."

That early success changed everything.

Once multiplayer was proven, the team knew they weren't chasing an impossible idea. They could stop asking Can we build this? and start asking How do we make it better?

It's a lesson Christopher Mitchell sees repeatedly across student projects.

Too often, new developers spend their early production time chasing the newest technology or experimenting with advanced tools before they've proven that the fundamentals of their game actually work.

"Fundamentals honestly do matter. I want you learning the fundamentals of programming before you're trying higher-end programming... I want you to learn 3D art production before you start mucking around with Houdini proceduralism."

Interestingly, Atomic Overdrive gave the team an opportunity to experience that lesson firsthand.

During pre-production, José explored using Houdini to generate procedural race tracks – a powerful tool widely used in visual effects and increasingly in game development. He spent weeks researching the software, getting it integrated with Unity, and experimenting with procedural workflows.

Technically, it worked. Practically, it wasn't the right choice. Unity already offered tools capable of achieving similar results, and continuing down the Houdini path would have required significantly more development time for relatively little benefit.

"I spent a couple of weeks... learning how to use Houdini. I did get something working with Houdini in Unity, but at the end of the day it wasn't up to standard. More importantly, we already had a different tool in Unity that would do about the same thing. Houdini was just going to take way longer, so we decided to cut it."

It's an easy trap to fall into.

Every game developer wants to experiment with exciting new tools and technologies. But production often rewards the solution that is reliable, understandable, and appropriate for the scope of the project – not necessarily the most technically impressive one.

By validating multiplayer first and letting go of unnecessary complexity elsewhere, the Atomic Overdrive team gave themselves something every project needs: a stable foundation to build upon.

Lesson Learned: Your first playable doesn't need polished graphics or finished content. It needs to answer the biggest questions about your game. Identify your highest-risk feature first, prove that it works, and let everything else grow from there.

YOUR FIRST IDEA WON’T SURVIVE CONTACT WITH PLAYERS

No matter how experienced a game developer is, there are some questions that can't be answered in a design document. Will players understand the controls? Will they use a feature the way you imagined? Most importantly: Will they have fun?

That's where playtesting becomes invaluable.

Before Atomic Overdrive entered production, the team imagined it as a highly social multiplayer experience. Inspired by the popularity of cooperative and party games, they envisioned players laughing together over proximity voice chat, reacting in real time as competitors bumped each other off the track or narrowly escaped obstacles.

On paper, it sounded like one of the game's defining features. In reality, almost nobody used it.

"We wanted to make something that was social. We wanted proximity voice chat. We imagined funny moments where you'd bump someone off the track and hear them screaming. But over time we realized that players were so focused on racing and getting a better time that they wouldn't say anything."

The feature itself wasn't broken. The assumption behind it was.

For a long time, the team also lacked catch-up mechanics, meaning racers naturally spread farther apart as each match progressed. Players often couldn't even see one another, making conversation less likely. Even after catch-up systems were introduced, competitors remained intensely focused on shaving seconds off their lap times rather than chatting with friends.

Voice chat stayed in the game.

It simply stopped being a feature the team actively designed around. Interestingly, the surprise wasn't limited to the students. Christopher Mitchell expected voice chat to become one of the game's defining mechanics as well.

"I thought it would be a huge deal – a core part of the game. But when you're actually in the thick of playing, everybody's so laser focused on driving, they don't say a word."

That's exactly why playtesting matters. It doesn't just expose bugs, it exposes flawed assumptions. Sometimes the feature you're most excited about turns out to be the one players care about least. Other times, a mechanic you viewed as secondary unexpectedly becomes the heart of the experience.

The only reliable way to know the difference is to put your game in front of players – and pay attention to what they actually do instead of what you hoped they would do.

Key Takeaway: Don't test whether players like your ideas. Test whether they behave the way you expect. The difference between those two questions can completely change your game.

PLAYERS DON’T READ DESIGN DOCUMENTS

By the time Atomic Overdrive reached regular playtesting, the team had already made one major shift, moving away from platforming in favour of a more focused racing experience. But that didn't mean the game was finished teaching them lessons.

One of the team's later track designs featured a tight S-shaped section that demanded precise drifting. If players wanted to maintain their speed, they had to use the drift mechanic exactly as intended. On paper, it created an exciting technical challenge.

Then they handed controllers to new players and something unexpected happened – many players never drifted at all.

"We wouldn't tell them anything – just grab the controller and play. They wouldn't realize there was a drift, or they wouldn't realize there was a jump."

For experienced developers, the controls felt obvious because they had spent months building them. New players didn't have that advantage. They approached the game with no context, no tutorial, and no understanding of the mechanics hidden beneath the surface.

That's exactly what made the playtests so valuable. Instead of concluding that players were "doing it wrong," the team asked a different question: Why wasn't the game teaching them what they needed to know?

Their solution wasn't to force players into mastering drifting, it was to redesign the track.

The team added subtle lips to the corners that naturally guided vehicles onto the walls. Skilled players could still drift through the section for maximum efficiency, but newcomers could navigate it successfully without immediately understanding every mechanic.

"Eventually we decided that instead of forcing players to drift, the track would have a little lip on the corner. If you didn't drift, it would snap you onto the wall. You wouldn't lose that much speed and you wouldn't crash – you'd just drive onto the wall instead."

It's a deceptively simple change. The drift mechanic didn't disappear, the track simply became better at teaching players how to interact with it.

Good game design often works this way. Rather than relying on lengthy tutorials or pop-up instructions, great games communicate through level design, visual cues, and player behaviour. They let players discover mechanics naturally instead of demanding they memorize controls before they can have fun.

Atomic Overdrive may not have become easier, but it became more intuitive.

What This Means for Your Own Game: Players won't experience your game the way you imagine they will. If a mechanic is consistently misunderstood, don't just ask whether the player is paying attention. Ask whether the game is communicating clearly enough.

SOMETIMES THE BEST FEEDBACK ISN’T THE FEEDBACK YOU LISTEN TO

Playtesting doesn't always produce obvious answers. Sometimes it produces conflicting ones.

One player wants more challenge, another wants less. One player loves a mechanic, another ignores it completely.

Learning which feedback to act on (and which to leave behind) is one of the hardest skills a designer can develop. For Atomic Overdrive, one playtester became particularly fascinated with the game's aerial dash mechanic.

Originally introduced to support the heavier platforming focus of Screen Lines, the dash allowed players to quickly correct their trajectory while airborne. By this point in development, however, the team had already shifted away from platforming and toward high-speed racing.

One player hadn't gotten that memo.

"He was really excited about the dashing mechanic. He was constantly dashing all the time – even on the flattest sections of the track. Jumping and dashing, jumping and dashing."

At first glance, that might sound like a reason to redesign the game around aerial movement again. Instead, the team looked deeper. The player wasn't enjoying the mechanic everywhere –

they were enjoying it in one very specific part of the course.

A section of the track formed a square tube, allowing skilled players to leap between walls while preserving momentum. Once the developers understood where the fun was occurring, they leaned into it. Rather than expanding the mechanic across the entire game, they refined that section of the track, strategically placing boost pads on certain walls to reward players who mastered the dash.

"If you know where the boost pads are, you can dash onto those walls and get a little more speed."

Christopher Mitchell says this is a common challenge in game development.

"You're always hearing good ideas. You think you're sorting good ideas from bad ideas, but there are tons of good ideas—and you're sort of drowning in good ideas."

That's an important distinction. The goal of playtesting isn't to implement every suggestion players make, it's to understand the behaviour behind those suggestions.

Sometimes a piece of feedback reveals a much larger truth about what players find enjoyable. Other times, it reflects a preference that's exciting for one player but doesn't support the broader experience you're trying to create.

For the Atomic Overdrive team, the answer wasn't to bring back heavy platforming.

It was to preserve the moments where that mechanic genuinely elevated the race.

What This Means for Your Own Game: Don't design your game around individual opinions. Design it around observable patterns. One player's feedback might not represent your audience—but their behaviour can reveal opportunities you never expected.

THE HARDEST PART OF GAME DEVELOPMENT IS LETTING GO

Ask developers what they regret about a finished game, and many won't mention the bugs – they'll talk about the features that never made it.

Every game contains ideas that were exciting, technically impressive, or simply fun to build, but ultimately didn't belong in the finished experience. Knowing when to let those ideas go is one of the most difficult skills a developer can learn.

By the midpoint of Atomic Overdrive's development, the team had already made several significant cuts. The heavier platforming focus was gone. The procedural track workflow using Houdini had been abandoned. Proximity voice chat remained in the game but was no longer treated as one of its defining features.

Those weren't the only ideas left behind.

One of the team's more ambitious concepts connected the game's lobby directly to the race track. Instead of navigating menus, players could simply drive out of the social hub, explore the course, practice sections of the track, and then return to the lobby whenever they wanted – all without loading screens.

It was an elegant idea, but it also came at a cost.

"Because we really had this social game idea, we actually had the track connected with the lobby. You could go onto the track and explore it and practice, then at any point go back into the lobby without loading screens or menus."

As development continued, however, the team realized their priorities had changed. The more they refined the racing experience, the clearer it became that players weren't looking for a social sandbox – they wanted to race. That realization made the decision easier.

It's a pattern Christopher Mitchell sees in nearly every student project.

"Students will often try to make 100 different things and shove them in all at once. Then they see the result of that and often have to winnow the project down into something that's got more cadence and pace – a more polished experience."

That's one of the biggest mindset shifts aspiring developers have to make. Adding features feels like progress, but removing them often feels like failure. In reality, the opposite is frequently true.

Every feature increases the amount of code that must be maintained, the number of interactions that must be tested, the user interface that must communicate with players, and the time required to polish the experience. Cutting a mechanic isn't just removing work, but instead creating more room to make the remaining mechanics exceptional.

For Atomic Overdrive, every feature that disappeared sharpened the identity of the game that remained. The final experience wasn't smaller because the team had failed to achieve its original vision – it was stronger because they had discovered what truly mattered.

Key Takeaway: Every feature has a cost. Don't judge an idea by how exciting it sounds – judge it by how much it contributes to the experience you're trying to create. Sometimes the fastest way to improve a game is by removing something from it.

GREAT GAMES ARE BUILT THROUGH BETTER COMMUNICATION

By the time Atomic Overdrive was taking shape, the team had solved countless technical problems. Multiplayer worked, the racing felt fast, the track was becoming more refined with every playtest.

Ironically, one of the biggest remaining challenges wasn't technical at all – it was getting everyone to picture the same game. Early in development, the team spent a surprising amount of time discussing something that seemed straightforward: their main character.

Everyone agreed on the broad direction. It would be a robot. Beyond that, however, every team member imagined something slightly different.

"Some of us pictured it more humanoid, some of us pictured it more cartoony, and some of us pictured it more mechanical."

Nobody was wrong. They were simply imagining different versions of the same description.

To bridge that gap, the team worked closely with several concept artists, exploring multiple visual directions before gradually converging on the spherical robot that appears in the finished game.

"We actually had a lot of help from the concept art collaboration. They helped us with quite a few concepts... and finally from those concept arts, we honed in on what is now the robot."

For Christopher Mitchell, it's one of the most common – and most important – lessons students encounter.

"The listener is always wrong."

He laughs before explaining what he means.

"No matter how well you're trying to describe something, the other person's imagining something else because they bring their own biases to the table."

It's an observation that extends far beyond character design. Programmers imagine systems differently than artists, designers visualize mechanics differently than animators, composers hear an emotional tone that might never have been written down.

Everyone is working toward the same goal, but each discipline naturally fills in the blanks through its own experience. That's why concept art, prototypes, whiteboards, mock-ups, and playable builds are so valuable. They go beyond production assets – they're communication tools.

Every sketch, prototype, and iteration reduces the gap between what one person imagines and what the rest of the team understands.

That collaboration extended well beyond the six core developers on Atomic Overdrive. Concept artists helped define the game's visual identity, while composers and sound designers shaped its atmosphere and sense of momentum. As the project grew, specialists from different disciplines weren't simply contributing assets – they were helping the team discover what the game should become.

Even seemingly small contributions could have an outsized impact. Mitchell points to the project's UI work as an example.

"They had a very, very good UI person... I was very impressed with the UI artist and the way they managed to draw people's attention to useful information at the right time. That's a career, never mind a job."

It's an easy reminder that players rarely experience programming, art, audio, or design in isolation. They experience all of it at once. A successful game isn't built when every discipline individually does great work, it's built when those disciplines successfully communicate with one another.

What This Means for Your Own Game: The larger your project becomes, the more important communication becomes. Don't assume everyone shares the same mental picture of your game. Draw it. Prototype it. Play it. The faster you can turn ideas into something tangible, the easier it becomes for an entire team to move in the same direction.

FINISHING THE GAME IS THE GREATEST LESSON OF ALL

For José, the biggest takeaway wasn't learning a particular programming technique or mastering a new tool, it was understanding what game development actually demands.

"There's only so much you can learn from tutorials or working on your own. Working with a team teaches you things you don't even realize you need to know until you're actually doing it."

It's a transformation Christopher Mitchell sees every year.

Students often arrive believing game development is primarily about programming, art, or design. By graduation, they understand it's something much larger: production, planning, iteration, communication, and learning how to balance competing priorities without losing sight of the player experience.

One lesson, in particular, stands out: knowing when a game is finished. Not perfect, but finished.

"At some point you have to stop adding and start polishing. Otherwise you'll just keep making the game forever."

Looking back, it's clear that many of the mechanics changed, features were cut, and ideas evolved throughout development. Rather than representing setbacks, those decisions became part of the team's education.

For José, the lasting lesson was the experience of building something alongside artists, designers, programmers, and audio specialists – learning not just how to make a game, but how to make one as a team.

The finished version of Atomic Overdrive represents more than a student project. It represents months of iteration, collaboration, difficult decisions, and constant learning – the same journey every game developer embarks on, whether they're building their first prototype or their next commercial release.

EVERY GAME STARTS SOMEWHERE

No two games are built the same way. Some begin with a sketch on a napkin, while others start with a game jam prototype, a classroom assignment, or a conversation between friends.

But whether you're developing your first game or your fiftieth, the process is remarkably similar. You'll test ideas that don't work. You'll remove mechanics you once loved. You'll rely on teammates with completely different skills. You'll discover that players interact with your game in ways you never expected.

The team behind Atomic Overdrive experienced all of those moments during development, and each challenge ultimately made the game stronger.

For aspiring developers, that's perhaps the most encouraging lesson of all; making a game isn't about getting everything right the first time, it's about staying curious, embracing iteration, and continuing to build.

Because every finished game, whether it's created by students, indie developers, or AAA studios, begins exactly the same way: With an idea that's willing to change.

Back to THE BLOG homepage