How do I get Started

From GPWiki

The Game Programming Wiki has moved!

The wiki is now hosted by GameDev.NET at wiki.gamedev.net. All gpwiki.org content has been moved to the new server.

However, the GPWiki forums are still active! Come say hello.

Introduction: Main Page >> What is game programming? | How do I get started? | FAQ for new game programmers

When beginning to learn about game programming, finding a place to start can be intimidating and difficult. This article aims to help point you in the right direction, by giving you the tips and resources you need.

[edit]

The Approach: How do I get started?

The answer to this question can depend on many things, one of them being your personality.

Are you the type of self-motivated person that can flow through difficult and even frustrating puzzles and problems to reach a goal? If so and you have a game idea that you dream about every night, then it would be wise (and you probably have the determination) to begin with the information given in the following sections.

Or are you the type of person that would like to see results quickly and are perhaps interested in avoiding as many complicated and frustrating scenarios as possible (they will always be there) at least for now? If so it could be ideal for you to take up programming by working with a pre-made game engine, as you would likely get faster results that way than you would with a traditional programming language/gaming library combination.

Perhaps it would be best to find a development environment and begin programming as many small games (Pong, Tetris, Breakout, etc...) as you can just to get a feel for how they are done. Perhaps pick your favorite and really flesh it out with all the bells and whistles and fantastic features you can think of.

This page is to help you determine the best approach for you. This page even gets you thinking about distributing or releasing your game to the public, which is admittedly beyond a 'Getting Started' issue for a beginning programmer, but could be considered a 'Getting Started' issue for a programmer who is just beginning game development.

Whatever you do, don't get overwhelmed, or frustrated. Scope out some of this information, then roll up your sleeves and try some of it out, there's certainly something here that will fit your needs and your personality.

[edit]

First Steps

The first thing to do is to decide which programming language or programming environment you would like to use.

You can go about this in several ways:

You can begin by choosing which language you wish to program in and then find a suitable development environment for that language.
You can begin by choosing a development environment and work with the language options your chosen development environment gives you.

If you are already proficient in a particular programming language, it is likely best to begin there since game programming is difficult enough on its own; learning a whole new language will only compound the difficulty.

If you are not familiar with any particular programming language, you'll need to decide which one you'd like to learn, but you are also in a unique and fortuitous scenario; you can pick the programming environment and language that is best for you.

When researching languages, you should consider:

How easy is the language to learn?
Is the language suitable for making games? (Is it fast and powerful enough?)
Does the language work with suitable game development libraries or APIs?
What platforms (Operating systems/processor architectures) will the language run on?
Will I be able to find support when I run in to problems? Is there adequate documentation available?

There is an entire tutorial devoted to picking a first language here.

Once you've decided on a language, you'll need to choose a game development library or API. Game libraries may provide you with functions for displaying graphics, playing sounds, getting input, and more. See the Wiki's Libraries for a list of libraries from which you can choose. This is another huge decision. Consider the following:

Is the library compatible with my language?
Is the library suited to my skill level?
Will the library work with the kind of games I plan on making?
Is adequate documentation available so that I can learn the library?
Do I understand and agree to the library's license?

Now that you've got a language and library in mind, it's time to read tutorials! This is the most important step in the whole process. You now learn to use your selected language and library. Immerse yourself. Read everything you can. If you don't understand, ask for help. Above all, do not give up. The languages page will lead you to a number of game programming tutorials for your language of choice, and your library should have documentation for you to read. When you're ready to try writing some code of your own, you'll need an IDE, or "Integrated Development Environment," which is a program that supplies, among other advanced features, a place to write code and a way to compile it. With many languages, a full-blown IDE is not strictly necessary, but it still might be easier for a beginner to use one.

[edit]

Gathering Your Tools

The Programming Tools page has a list of tutorials, with appropriate media development tools that can be found over on the content tools page. This should be useful for you.

[edit]

Designing Your Game

Caution! Yes, caution is definitely called for when designing a game. Avoid newbie mistakes! Follow this advice:

Start small. Most newbie game programmers dream of making the next hit game. If you're just starting out, this is an impossible goal! It will only lead to frustration and defeat. You must start small; the only way to learn game programming is to be a game programmer. Try making a simple Tetris-style game, a breakout clone, or something of that nature. You'll run into enough trouble with Tetris if you're just starting out. If you have a little more experience you may wish to visit the game genres page to help decide on a game type.

Plan. If you have nothing more than some vague notion of making a "really cool RTS game" you are likely going to run into trouble about halfway through your project, when you realize that your initial assumptions were incorrect. Try to be as thorough as possible in the designing phase; it'll save you countless hours in the end. Create a design document for your game, and include a structured version of all of your gameplay and technical design notes. Think through your game from beginning to end, and document every gameplay feature, and how you plan to implement it technically. Having said that, I'll now suggest that no design document is perfect. Something unanticipated will always come up, no matter how thorough you've been. Just do your best!

Wait. I've always found that my ideas seem brilliant to me when I first come up with them, but a few weeks down the road they don't always seem quite so interesting. Be sure that you've given yourself ample time to mull an idea over, before committing yourself to it. You don't want to get bored with your game after investing hours in its development!

Get feedback. Find a group of gamers and pitch your idea to them. If they're not excited and interested by your idea when you're enthusiastically describing it to them, they'll surely not be excited and interested by the end result. Get feedback, and re-work your idea.

[edit]

Creating Game Media

For many game developers, this is the hardest part! After perusing the content tools page and deciding on a set of tools, it's time to get down to the business of creating your game's media. If you aren't an artist, you may need to search around for partners who are skilled in this area. For beginner games, there isn't anything at all wrong with so-called "programmer art," however. You can also try some of the freely available art resources that can be found on the Internet.

See the Game Content Resources page.

[edit]

Coding Your Game

Code flexibly. Changes happen, no matter how well you plan. If your game's structure is too rigid, you may find that a single oversight in the design phase could necessitate a re-write of some of your game's engine.

Prototype. Try to get your game to a quick-and-dirty playable state as soon as possible. The graphics need not be complete, and the bells-and-whistles need not be implemented, but it is important to get an early idea of how your game will play. It's possible that you'll try it and say, "Wow, this is no fun at all." Thankfully, if you've made this discovery early enough, you'll be able to re-work the gameplay and try again without much trouble. Seeing your game in action, even if in a rudimentary state, could also motivate you very effectively.

Don't optimize early. Spending your time optimizing code before you even know how the game as a whole will perform is pointless. Code flexibly, yes, such that future optimization will be possible, but early optimization can be a big time waster. You won't know where your bottlenecks will be until the game approaches its final state. If you spend days honing your blitting routines, only to find out later that your pathfinding routines are the bottleneck, you've wasted your time! (In the words of Donald Knuth, "Premature optimization is the root of all evil.")

Try not to throw away well tested code. The principle of code reuse is very important for large projects. You may think throwing away all of your code and starting from scratch is a good idea, but it may not be. Think of the weeks, months, and even years you have spent writing and testing that code. Read more on this philosophy at Joel On Software.

[edit]

Deploying Your Game

So, your game is complete and ready for the masses, but how do you get it to them? That's where deployment comes in. Be sure to read our deployment page for a full description of the options you have.

[edit]

Selling Your Game

If you have created a game that you feel could be sold, you really have two options: Trying to find a publisher, or publishing the game yourself.

There are a number of independent game publishers out there on the internet. Some of them will require that you sign an exclusive contract with them, which means that they will be the sole distributors of your game. Other publishers may give you the option of signing a non-exclusive agreement, although for a lower rate of pay.

Self-publishing will ensure that a greater percentage of the total earnings will go into your pockets, but the twin burdens of marketing and sales will then fall squarely upon your shoulders.

Some truly excellent articles for independent game developers can be found on Dexterity Software's website.

Of course, if you're programming games for the joy of it, or you feel that it would be best for the future of the game and its players, it's always possible you'd like to release the games as Free Software/Open Source Software (FOSS). If so, it's advantageous to decide this early; A number of sites such as Sourceforge give free web-hosting to FOSS projects, and using a FOSS license allows you to reuse code from existing FOSS games with a compatible license. However, while it's theoretically possible to make money selling FOSS, it is not currently a good choice if you hope to be paid for developing your game.

[edit]

Getting Help

As always, if you aren't sure how to proceed, or are stuck in any way, visit the forums and ask for help! We're all friendly here, and are quite willing to lend newcomers a hand. Afterall, we were all newbies once!

[edit]