The thought of making a video game can be daunting. There’s code to write, 3D assets to model and texture, sound design, music, gameplay, voice acting, multiplayer, platform integration, marketing, bugs to patch… The list never seems to end.
It might seem like any game, even something simple, requires millions of dollars and a giant team of people. However, lots of modern games are built and released by small teams; often a team of one. How can the cross-disciplinary nature of games and the sheer volume of work be managed by just one or two people? Let me tell you how I do it.
Contents
Use Creative Constraints
How can you do it all when making a game by yourself? The answer is simple:
You can’t do it all.
When you’re starting a new project, whether it’s a simple game you put together in a weekend at a game jam or an epic multi-year endeavor, you should pick a few key creative constraints and stick to them. By cutting out large portions of the process that typically take a long time, you open yourself up to new creative opportunities that you might not have considered previously. It also makes your game more unique. I’ll give you a few examples.
I’m working on a big game right now called Neptune Flux, and I decided early on that I would not do any human character modeling or animation. That’s a big area of most games that takes a tremendous amount of time, so by cutting it out, I was able to spend more time focusing on environmental story telling. This created a unique atmosphere for the game, and made the game’s development timeline achievable.
One example that I enjoyed recently is A Dark Room for web and mobile. A Dark Room tells a surprisingly deep story with a minimal interface and almost no graphics, but it managed to grab a top spot on the iOS App Store for weeks. I strongly believe that if the game did feature graphics, it would not have achieved the same popularity, because the power of the game comes from the imagination of the player.
Don’t Reinvent the Wheel
This might seem obvious, but if your game is going to include a feature or a 3D model that’s in dozens of other games, don’t do it yourself. You might get a sense of pride by doing it all, but it’s better to focus on the unique aspects of your game that will make a big impact on the players.
If you’re using the Unity engine, you should browse the Unity Asset Store any time you start on a feature or a game asset. Chances are good that someone else is selling the thing you need for an affordable price (or for free). If you’re using the Unreal engine, the Unreal Marketplace is very similar. I use AudioJungle and Sound Snap for music and sound, even if I think I might replace it later.
You can also modify downloaded assets to suit your needs. Sometimes I’ll remix sounds or I’ll download a 3D model and redo the textures myself. A mediocre 3D model with great textures can often look much better than a detailed model with terrible textures. A game is not about a single asset; rather, it’s about the sum of its parts. Focus on the things that will make the maximum amount of impact on the overall experience.
Keep It Simple
Even if you start out a game with humble ambitions and think, “This time, I’ll keep things simple!” you can still end up with a complex mess by the end. It’s easy to start out simple, but it’s hard to keep it simple, because there’s always the temptation of, “Wouldn’t it be cool if…”
This does not mean your game can’t change and evolve as you progress. In fact, it should, because in most cases you’ll throw out 90% of your original design as soon as you play your game for the first time. However, when you do play test your game throughout development, always look for the simplest solution first. Sometimes the most fun solution would be the most complicated, but it’s really the least fun if it means you can’t ever ship your game.
Build simple mechanics first and then try not to add any complexity until you know you’ve “found the fun” in your game.
Reuse and Recycle
Any time I code, I don’t think about how I’m going to create one interaction or design one quest. Scripting things individually takes too long when compared to the amount of play time that a player actually gets out of it. Instead, I try to think about simple systems that interact with one another to create a much larger whole. Once I’ve prototyped some gameplay that I think is fun, I’ll go back and spend time turning them into more generalized systems. For example, if you discover that it’s more fun to play your game if you can shoot magic fireballs, then maybe you can turn that into a “magic system” where you can also shoot frost bolts or lightning that all run on the same code. Each spell would just use different numerical values and artwork.
Along the same lines, never go for a 1-dimensional mechanic like “The player can fight with a sword.” Instead, think about how the player can fight with a sword, but also how it’s perhaps not as effective against some types of enemies. That’s a relatively simple thing to do that suddenly gives the player something to discover and simultaneously introduces some strategic decisions.
When it comes to artwork, try to think of clever ways to reuse the art you already have. Maybe the same player model with a different texture could work as a power-up. Or perhaps a player could reach the end of a maze only to discover that something has changed and they must fight their way back out with new challenges.
Clever programming, art direction, and game design can all work together to stretch your time spent making things more fun for the player.
Never Stop Learning
Whether you’re a new game developer or you’re in the middle of your 100th project, you have to believe in your ability to learn and conquer. When I first started making video games several years ago, I had about 15 years of web experience to lean on, but that didn’t help me as much as I thought it would. I had to get back to basics and relearn a lot of what I thought I already understood. I also had to dig into 3D applications (like Maya and 3Dsmax), which can feel like sitting in the cockpit of a space shuttle at first. But I tried, I stumbled, and I learned. Then the next 3D model was easier than the first, and the next line of code was written with a deeper understanding than the previous.
Let me give you a more specific example. Unless I’m really crunching, I like to participate in game jams. These are typically one-day or weekend-long events where people get together and make games. The goal is to deliver a game within 24-48 hours, which forces you and your team to create clever designs that can meet the deadline. I like game jams because they harden your skills by fire. You come out of them with more confidence and a new understanding that helps you on important projects. This might seem like time that could have been spent working on more important projects, but learning has a big return on investment. When you learn something new, the next time you go to do that thing, you’re faster and better.
There’s a lot more I could say about my specific workflow, but that’s a high level overview of how I think when approaching a project. Different methods work for different people, so if you have something you’d like to share, I’d love to hear about it in the comments!