Tips for a One Man Gamedev Team: What to Do Before Even Touching a Computer

Tips for a One Man Gamedev Team: What to Do Before Even Touching a Computer

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.

Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • http://jinxed.com.hr Jinxed

    Yes… all this sounds very familiar. To late for me to learn from this. Already got it the hard way.

  • http://blog.sklambert.com/ Steven Lambert

    Great post. I totally agree that knowing the core mechanics and details about a game first before coding one line of code is super important. I’ve been working on a game idea/concept for a few years now just fleshing out all the details. I haven’t coded anything yet because I’m still lacking details in the game and how everything will fit together. Because of this, the game is still very much interesting to me and will be once I start programming it.

  • http://cowfacegames.com/ Desi Quintans

    Something I did when I was planning my first game was to write a design document. Not an extravagant 30-page affair, but a simple one in a wiki outlining the very basics of implementing the game, short of going into code. I’d start with some broad idea like “random world” and then work my way through what I’d need to do to achieve it: how will I generate a landscape? How will I generate believable buildings? How do the buildings get placed in the landscape? How can I place items randomly inside those randomly-generated houses? How could I store all of this stuff in a save file?

    Doing this kind of top-down planning is, I think, great for whittling down your ambitions and reminding you of what you’re capable of. “Randomly-generated open-world FPS” sounds really simple until you start wondering about details like how you’d make NPCs move around in it, how you’d make them take cover, and so on.

  • http://www.marek-knows.com Marek

    Design, design, design up front before coding! Make sure you understand all the aspects of your game before you write the first line of code and you will save so much time down the road. When I was developing my 3D dungeon crawler game called Ghost Toast (http://www.marek-knows.com/phpBB3/viewtopic.php?f=30&t=531) from scratch things went very smoothly.

    The other piece of advice I can give is start with a simple game. Don’t try to make a game that have 100′s of different features and elements in it to play because you’ll never get it all done in a reasonable amount of time. Focus one a very small set of rules (player can move and shoot, enemy’s can move and shoot). That’s it. Once you can get that working you will have a “game”. If you are not tired after implementing the basics, then start adding other parts like keeping score, changing weapons, adding a different enemy etc.

  • Mudmarox

    Wow, that’s incredible !!! It’s the same thing that happened to me in a warm summer :D

  • hu

    yeah, thank you, great post!.
    i found a mistake from quote:
    The first 90 percent of the code accounts for the first 10 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

    • http://gamedev.tutsplus.com Michael James Williams

      That’s actually intentional – it’s a bit of a joke :)

      • Matou

        Ooooooh! Thanks for telling this! As I am not a native english speaker I didn’t understand it was a joke! But now you say it, it’s really well expressed. Brilliant :)

  • http://www.megageorge.com George

    I don’t think there’s a right way to make games. Doesn’t matter how you do it, just have fun and make cool engaging games!

    • http://soherearemyideas.blogspot.com Paul Suddaby
      Author

      I agree, but there are always tips that can help along the process of making a game cool and engaging rather than not-cool and not-engaging.

  • http://cansurmeli.com C@N

    Realy nice piece of writing. Enjoyed it a lot. :)

  • Mc

    Great article. Gives a fresh look in the middle of creating concepts and planning development. Keep it up! Cheers

  • Antonio Carlos

    Hi! I really would like to say THANKS! It had helped me alot!

    Well, I’ve translated it to Portuguese, if you want to share it to others, I can send the text.

    Thansk alot! =D

  • Kevin Glass

    Nice article though I think you’re missing the organic nature of design when you’re a one man band. Protyping is the core of everything, design is valid until you start coding, it normally then mostly goes in the trash. The sooner you build something the sooner you’ll know whether it works or not.

    Not to say design isn’t important bit remember that anything you esign or decide before the first version is playable is likely to change so don’t let designs be set in stone.

  • http://www.facebook.com/vincent.piel.18 Vincent Piel

    I don’t know if this is a ‘detail’, but i think it is worth reminding that a good way
    to prototype a game (and to code it also, btw) is to have it data driven as much
    as possible :
    so for instance in the main loop method of a racer game we can have :
    1) x += 10; // nope
    or 2) x += trainSpeed ; // better
    or 3) x += GameConstants.trainSpeed; // better, but…
    or 4) x+= GameConstants.trainSpeed * timeInterval ; // good : now trainSpeed is framerate independant.
    // so it is really is a game constant.

    So do not hard-code (evil), but give clear name to data, and keep all game data
    in the same place (or in several well structured places). This is *not* something
    you should do in a second time (“later”), but need being done even for a prototype
    code that won’t be reused.
    Imagine you have in the same file (and in the same object):

    trainMaxSpeed = 150; trainHealth = 1000;
    carMaxSpeed = 220; carHealth = 100;
    truckMaxSpeed = 180; truckHealth = 300;
    vehiculeLevel = [ 'car', 'car', 'truck', 'truck', 'train' ]; // tells which vehicule to use for each level
    roadLevel= ['road1', 'road2', 'road1', 'road2', 'road3']; // which road per level

    Now you have under your eyes all what you need to change the

    gameplay. Here we will play with car on road 1 and 2, then with truck on those roads
    again, and then the train on road3.
    Do it for everything : level change, bonus frequency, … so it is very easy
    to fine-tune the gameplay for the game to be challenging but interesting.
    Another interest of this is that is become simple to make several game difficulties
    (easy/medium/hard) just by changing some values.