This Cyber Monday Tuts+ courses will be reduced to just $3 (usually $15). Don't miss out.
So you've decided you want to make a video game as a hobbyist. You've picked a development platform, read some tutorials, and you've got a cool game idea in mind. You're all set up, time to get started, let's hit the computer, right? Wrong.
Can You Make This Game?
Video game development studios are companies; money defines what they can and can't do. But you are not a company, and things aren't so straightforward for you.
An assumption many lone hobbyist developers make is that their development will work in the same way as a studio's. That they don't need to pay themselves a salary, and they aren't depending on their game for money, so they can take as long as they want to finish it; they can do anything they set their minds to.
Unfortunately, this is not how it really works. As a one man team, you are limited by your current skills and the skills you will be able to acquire during development. This may seem obvious, but it's something that ambitious new developers often gloss over. Many new hobbyists, myself included, got teary eyed the first time they started making a game, thinking about the amazing experience they would create, and completely lost sight of what they could realistically accomplish.
Making a video game is complicated work, especially alone. From design to programming to art, not everyone can do everything, and it's not always easy to learn. You may be willing to learn how to make your very own rigid-body physics engine, but getting it done without losing interest in your project can be difficult - and who knows, maybe the math behind the physics just doesn't agree with your brain.
As much as you might want to, this sequel is one game you can't make.
Don't challenge yourself with your concept, especially if this is your first game. Whether it looks like it or not, there will always be obstacles you hadn't expected, even in the most simple of designs, and you will be challenged and learn something during development. Even if you don't seek that out, it'll happen on its own.
Another thing to keep in mind: scope. Games always take longer to make than you think they will, so adjust your designs accordingly. As the ninety-ninety rule states:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. Tom Cargill of Bell Labs
This rule is humorous, but it does describe the typical development cycle of a game. You'll get everything seemingly running perfectly and think you're almost done... and suddenly realize you still have a ton of work to do polishing your game. Things like UI, sound and last minute glitches require a lot more of your time than you'd think.
The bigger your game, the more of these little things there will be to fix - so always keep scope in mind.
Cool Idea, but What About Your Game?
Got a concept you're sure you can execute on? Great - but don't start yet. You can't code a concept; no programming language or game development tool allows developers to create games in vague, broad strokes. You need to know the specifics of what you're making.
Suppose you're making a 2D puzzle platformer that takes place underwater with a cool weight mechanic. That sounds awesome, but you can't code a “cool weight mechanic”, you need to break down how it works on a very specific level.
- How does the player get heavier or lighter?
- How does this change the interactions between him and the enemies?
- What are the enemies?
- What are their movement patterns?
- Can they interact with the scenery?
- What kind of objects are in the levels?
- How do they interact with the player and the enemies?
You must consider all of these aspects before starting to create the content. Of course, many things will change over the course of development - you'll come up with new ideas and scrap old ones - but it's crucial to have a good idea of what you're doing before you hit the computer.
I'm not alone in this mentality. The entire map for Shadow Complex was made on graph paper before anybody even touched a computer. Now this is definitely an unusual development style, and I'm not saying everybody should replicate it, but the team over at Chair Entertainment definitely understood the value of understanding your game before building it.
Part of the paper map for Shadow Complex.
I'm adamant about this point because it's a struggle I came across myself recently, and I'd like to use myself as an example of what not to do.
I was excited to start developing a game during summer break, when I was guaranteed to have lots of free time. I came up with a concept I thought was pretty cool, got some good feedback about a tech demo I built and started coding. The problem was, all I had was a concept. I had a primary player ability that I thought was interesting: you could shoot any tile in the level to make it ascend or descend, letting you move around and squish enemies. Apart from that all I had was a genre and general vibe of how I wanted my game to feel.
This was disastrous and stupid. I was so eager to get going that I had no idea what I was trying to make. I ended up coding features haphazardly, hoping my game would crystalize into something cool. What I got was a very messy codebase, art that looked like my game took place in a jungle (and maybe it did; I drew art before I had a setting - go figure) and no inspiration whatsoever.
After all that, I completely lost interest in the project because it was so difficult to make. The design wasn't particularly complicated and it was nothing I hadn't done before, but I still found development painstaking, arduous and not at all stimulating.
Use me as an example - you can read more about my abandoned project at my blog. Know what you want to make before you start making it.
But Isn't All That What Prototyping Is For?
Almost every gamedev post mortem discusses prototypes. "Just prototype and playtest; rinse and repeat until you have something you like."
I've never made a game as part of a large team, but I do have experience working in small teams and on my own, and I can tell you: prototyping isn't as fast and easy as you may think. When you are only one person working on a game, getting even just a small section of it working can take quite a while, and using this as a method of figuring out primary game concepts is quite a tedious experience.
But prototyping and playtesting have their place in a one-man team's development cycle - you just need to go about it in a different way.
Prototypes were talked about a lot during interviews with the developers of this game.
When figuring out whether a game idea is as great as you think it is, nothing is more effective than actually sitting down and playing it. This doesn't change when you're working alone, but because prototyping can take so long, it does need a bit of tweaking. Don't go blindly into prototyping, thinking of it as a time where you'll test one thing and come up with a bunch of cool new ideas. Rather, think of prototyping as a space where you can refine the ideas you already have, ironing out the details of your existing plan.
You may get hit by a wave of inspiration once you start getting things running, but don't count on it. When you do start prototyping, it's effective to make a vertical slice of your game, a short hacked-together playable section that represents as best you can what you want a part of the final product to be. You don't need to reuse any of this code later, so just get it up and running as fast as you can to get a good gauge of what you're really making. You could even use a different engine for this than you plan to use for the actual game.
This will help give you a goal to work towards as well as a really good idea of how your design is going to work. This experience adds context to the rest of your development and allows work to be done very efficiently. Always having the final product at the back of your mind really helps minimize the amount of art and code you scrap later.
Of course, all of this depends on your development platform. If you're making your game in something with a lot of groundwork done for you, like GameMaker or even the LittleBigPlanet level editor, then prototyping can be fast even though you're just one person. In that case, build as many prototypes as you like!
Can I Start Now?
When you've got a design that's achievable, you've hammered out the specifics of how things are going to work, and you know exactly how you're going to tackle prototyping, then you're all set!
Thanks for reading. Go ahead and get make that game - I look forward to seeing it.