Rav's Amazing Newbie Guide, v1.1
ravuya(at)gmail.com || http://rav.realitybytes.tk

  1. Introduction
  2. Common Newbie Mistakes
    1. People don't care (AKA: "Put up or shut up" rule)
    2. Expecting too much
    3. Working with faulty tools
  3. Where to Start?
    1. But programming is scary and frightening.
    2. I'm not serious about this, though. What do I do?
  4. Recommended APIs and languages
  5. Stages of development
    1. First year
    2. Second year
    3. Third year
    4. Fourth year
  6. Schools
    1. "Game schools"
    2. Prestigious universities (and questionable community colleges)
  7. Conclusion

1.0: Introduction
Welcome to game development! You, like pretty much everyone else who has ever played a game in their life, are interested in building 'em.

This guide will attempt to teach you the best and simplest ways to get off the ground and into your first couple games; it doesn't advocate the "easy way out" at any point in time. If you are not willing to work, do not read this guide. In fact, don't read any game development guide. Go back to watching MTV.

2.0 Common Newbie Mistakes
If you spend any time on a game development message board, you'll be covered in these mistakes. They will annoy you to such a degree suicide seems like a viable option.

And yet so many people display them. This section attempts to dispel newbie myth and mistake and offer suggestions for the future.
2.1 People don't care, or the "Put up or shut up" rule
Hundreds of newbies flock each year to message boards to post their great idea about creating a new MMORPG, but the problem is they have no experience to offer. Even worse, some newbies believe that ideas are actually hard to come up with, and will attempt to pester established programmers or famous companies with terrible ideas that border on the criminally derivative. Fact: Nobody cares. Ideas are easy to come up with. If you want a team to work on your grand MMORPG idea, then you need to have something more than just "oh well I play them a lot and I have some really great ideas. Look at my list of ideas" in order to attract members. Usually, for indie teams this means you need to be a programmer and produce a testbed to attract others.

Will anyone spend their time labouring over a project even you won't work that hard on when they could be following their own dreams? Consider this before you ask for teammates, or how you can get a job as a "game designer" at a large company. There is no such job as game designer. You will work your way up in a large company for what seems like forever, or start your own company. Or... you could make homebrew games, which is what this guide is all about.
2.2 Don't expect too much from your games. Ever.
Your first 50 games will suck. Better get them over with.

Even if you have a killer game idea that can't fail, somewhere along the line you'll make a huge mistake that will make it suck.

Or, you won't have the ability to realize that idea and still keep a constant frame rate.

The point of this section is to tell you not to expect too much out of your homebrew games. If you think you are competing against million-dollar corporations with teams of highly-experienced developers, you're gonna be doing a lot of crying. Expect less. Deliver more. The same goes for hype... don't hype up your game if you know it'll be garbage.

It will be very discouraging at times; when you've been fighting a bug for weeks and have to end up stripping out a feature, it is one of the most painful things in the world. When you have no idea where to go next, or when you do and have no free time is often the defeat of many small projects. Keep focused, and keep positive! If something isn't working out, kill it and get started on something new. It's not like you're designing chips or anything else where an abandonment means the loss of money and physical resources; computers are meant to be played with.
2.3 Working with faulty/"easy" tools is painful.
A lot of newbies think that something like RPG Maker or Game Maker is all they need to get into the industry. That's completely wrong. Not only are these tools limited, they are also insulting to the people who work hard on developing their own engine when you show up and spam your creation made from someone else's code as if it's the Second Coming.

Not to mention you won't learn anything...

The same goes for when you're writing code on your own. If the tools you've made for installing content are painful, your life will be painful. Five minutes spent on making an editor nicer can save you five hundred minutes down the line.

3.0 Where to Start
You should start by learning to program, it doesn't necessarily matter what language though many are more suited to game development than others. The important part of learning to program is learning to solve problems; not syntax. Many newbies get hung up on the stress of having to memorize syntax, when they should be spending time to learn how to think logically and properly.

Think of it this way: if a chef spends all of his time worrying about how to use the spatula properly 100% of the time, he's not going to be making any cakes because he's not focusing on the procedure.

Learn to program; it doesn't matter where. Then, you can start building your first, extremely rustic games.
3.1 But programming is scary and frightening
In case you missed my rant back up in 2.1, this section will fill you in again: It is extremely difficult to break into the indie games "cliques" without having any programming talent.

There is almost no way to get the game you want made unless you make it yourself. Artists will be following a programmer around making sprites according to what he writes; level designers will be using the programmers' tools to make levels for the game the programmer wrote.

If you're serious about building games, the only way to do it at this level is to become an everyman: even the best programmer can produce an unpopular game due to "programmer art". If you're good at art, become passable at programming. If you're good at programming, become passable at art.

A note, however: even great art and maps won't make up for a crap game. My personal opinion is that the programmer, through direct control of the gameworld, influences gameplay quality most directly. Tune your controls. Tune you engine. Make it solid. If your game crashes on my box, I most likely won't play it again.

Note how I didn't mention plot anywhere in here: do you remember being enraptured by the great plot of Super Mario Bros, or the fantastic cinema scenes in Tetris? Plot can be great for games, in fact set them apart from others, but at the indie level stories shouldn't be your primary focus. If you're not a great writer, your story will do more to embarrass you than help your game out anyway.
3.2 I'm not serious about this.. what should I do?
Well, this guide really isn't for you, then... I recommend grabbing something like Game Maker and amusing yourself for a half hour until you get bored of it.

Game development is hard, hard, hard work. It's not for people who can't take criticism or people who don't want to work at something for years on end.

4.0 Suggested programming languages and APIs
You're going to hear this from most developers, so get used to it right now: C++.

It's not a perfect language, and it's definitely not right for newbie developers. I would recommend starting off with something like Python, and then using the PyGame SDL bindings with it later.

However, once you graduate from Python University, it is virtually impossible to escape C++'s grasp. Most tutorials are in it, most programmers are versed in it, and most game jobs want you to know it. Learn it. It is my weapon of choice, and it should be yours too.

Recently, other favourites like C# and Java have come into the limelight; I don't recommend C# at this time due to its immaturity on platforms other than Windows, and Java is occasionally slow but makes for an excellent platform due to its built-in features and general safety.

In regards to APIs, SDL is a great starter. It's not fast, but it is portable and is great to write games with. You can find fantastic tutorials on the page; I used it for every game of mine up to and including CSRPG2.

The best way to learn pretty much everything (excluding SDL) is by going to your local bookstore or library and picking up a book. Books are your friend and although they're definitely not cheap, a good book will serve you extremely well over the years. I'd be lost without my copy of C++ for Game Programmers.

Handy Links:
a free C++ compiler (Dev-C++), For Windows only, Mac OS X and Linux should come with compilers pre-installed

5.0 Stages of Development
I've decided to show off some example games and screenshots to show you how far you'll get after x years of experience. These results might not be typical for you, but they are a general plan for what to reach for if you work hard, consistently, and often.
5.1 First Year
Newbie Game: First Year

Not much to look at, huh? A guess the number game is probably a good example to start with for your first year of game development. As you progress, you can make things like text-based RPGs, text-based shooters, and text adventures. So when do we get to the graphics, you ask?

When you've covered the essentials. In order to start with the next realm you should definitely know:
  • Basic geometry (coordinate systems, distance formulae)
  • Good program structure (avoiding global variables and copy-paste syndrome)
  • Object-oriented programming (classes, inheritance)
  • Basic optimization (simpler loops, using pointers and references instead of copy operations)
Average development time per game at this level: 1 week
5.2 Second Year
Newbie game, Year 2 (Skitter)

Now we're getting somewhere, right? In the second year, you can learn things about real time game programming that will help you to understand how games really function and "think" inside. In addition, you'll make a lot of mistakes. But hey, you'll get some graphics on the screen and impress your mates.

To progress to a third-year level of knowledge, you should know:
  • How to use a basic graphics API (SDL, ClanLib) to produce simple games
  • Collision detection and other essentials of an arcade game
  • Basic design of a game's inner loop, and how to handle problems
  • Basic debugging skills
Average development time per game at this level: 1 month
5.3 Third Year
Newbie game 3 (Heroes of Roswell)
Courtesy of Patrick Avella's Heroes of Roswell

Here's where gameplay starts to come together. By the end of year three, you should have built a fairly complicated arcade-style game with pseudo-intelligent enemies and some nice animation.

People willing to move to a fourth-year level should have:
  • At least two "finished" games that can be played end-to-end under their belt
  • Great knowledge of collision detection and other game algorithms
  • Excellent knowledge of their API and programming language of choice, as well as good problem-solving knowledge, allowing them to move to new APIs and programming languages
  • Good knowledge of how to make a fun game; smart control design and decent AI.
  • Basic "programmer art" skills, i.e. making test sprites in GIMP or Photoshop
  • Great debugging skills, and knowledge of common afflictions such as memory leaks and slowdown and how to counter them
Average development time per game at this level: 1/2 year
5.4 Fourth Year
The Omega Initiative
Shot from The Omega Initiative courtesy of Laz
(Click to see full version -- it's worth it!)

Here is the cream of the crop; the single-person or team games that not only play great but look amazing as well. You can fully expect to see complicated gameplay or stunning graphics; sometimes together in a single game. Games here are only separate from commercial releases in terms of length, or mass amount of content.

People willing to move past here need:
  • Some programming knowledge or "talent" that will separate you from other developers; i.e. a focus on controls, physics, or graphics programming
  • Loads of experience, and many completed games, with a rich portfolio to show off
  • A deep understanding of how games are built, and how to work to get the most game done for the least amount of effort
  • Lots of free time and a good source of caffeine
  • Many contacts, or potentially teammates, that know what they're doing
Average development time per game at this level: 1 year

6.0 Schools
Many people wonder if they can just go to Digipen, Full Sail, or any of the other dodgy "game colleges" advertised on TechTV or in EGM, and then learn all this crap that way. Here's the reality.
6.1 "Game Schools"
While game schools are great if you already know what you're doing in regards to writing games, places like Digipen and Full Sail are almost universally money-traps. You will work through it to receive a limited degree. Based on reputation, the degree might be usable at a game company, or it might be worth less than toilet paper.

In addition, if the game industry goes into a recession, you will find it extremely difficult to find a non-game job with a "game degree". Some owners will likely assume you sat on your ass and played Final Fantasy for four years. If you already have a computer science degree, and want to do nothing else than games, a spin at a game school degree might give you a head up on the competition, but I wouldn't recommend it for your sole source of post-secondary education.

Update 12/26/04: I am told Digipen and Full Sail are now accredited, but until they can get over the "game school" stigma it will be incredibly difficult to find non-game work. I do not know about any other "game schools". My original point still stands: if a recession hits, your game degree might be worth less than nothing if you can't find an interviewer who understands the school's reputation. Given the relatively high cost of tuition, you might be better served with a generic university degree (see 6.2).

Not to say that Full Sail and the like are useless: the example game for year 4 was built at a Full Sail course. However, I do encourage you to do your own research instead of just assuming that Digipen and the like are the only ways into a game job.
6.2 Prestigious universities (and questionable community colleges)
You're better off to go here for your first degree. Some accredited universities are starting to get game design courses, and even if the game industry explodes you have a standard computer-science degree from a trusted university (instead of some fly-by-night technical college) to back you up. There are also some great co-op programs that will land you a job (at places like Simon Fraser University) and experience.

When it comes to academia, play it safe. Do your research and consider the future.

7.0 Conclusion
This document serves only as a simple introduction to independent game development and the quality to be expected from it; it is by no means a complete technical document to starting out in the game industry. Consult GameDev.net for this information.

As always, do your own research. I think I've created a decent starting guide, but this is extremely light on technical details. I plan to perhaps do an SDL guide later on to get people started on the technical side of game development, along with some links on where to get tools for free like Gimp and Dev-C++.

In addition, if you can think of something that should be here, feel free to contact me:
  • AIM: ravuya
  • Yahoo! IM: mr_seigen
  • MSN IM/e-mail: ravuya(at)gmail.com

I will try my hardest to get it into a future revision of the document.
You can also ask introductory newbie questions on the forum for this article.

Post comments here

Copyright 2004-05 Rav; screenshots used under permission of respective authors