How do I get Started

From GDWiki

Jump to: navigation, search

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

Image:40px-broom.png This section repeats, in whole or part, the text of other article(s) or section(s).
Please discuss this issue on the talk page.

When you first begin to learn about game programming, it can be difficult to know where and how to start. Every game programmer has their own views, derived from their own, first-hand experiences, about the best way to learn about game design and about the best way to design a game. If you tried to follow all of their advice, and gave each programmer's opinion equal weight, you would quickly discover that you were going nowhere. You wouldn't even be able to pick a programming language to write in.

The very first thing you need to learn as a programmer is that it is up to you to decide what kind of game you are going to make. Ultimately, you are going to have to make all of these decisions yourself (or with the aid of your teammates), and it is the aim of this article to give you the confidence and direction you need to make those decisions.

Contents

[edit] Rule One: Know yourself

Before you type one word in your design document you have to stop and ask yourself a question: What are you willing to do to make this game?

Not all game programmers are created equal, so it's natural that different programmers will be willing to do different things to get the job done. But these differences in temperament can lead to drastically different design paths. Before you start working on your game, think about the following types of programmer stereotypes and see how you fit in.

[edit] Programmer stereotypes

  • The hardcore techie: the techie is the kind of programmer who seems like they were born to program computers. They love to tackle arcane programming problems and thrive on making computers do things that other programmers wouldn't even consider possible. Their main objective is to master the technology and pioneer new fields of research. This kind of programmer is good to have on your team, if you're not one yourself, but they tend to get bogged down in details and veer off on unrelated tangents. They are also prone to a tendency to reinvent the wheel merely for the pleasure of doing it. If you are a hard core techie, you may need to team up with a visionary who can keep you on track or learn to nurture your own creative vision through creative writing, music or visual art.
  • The visionary: the visionary is the kind of programmer who can see the end results of a program vividly in their mind's eye, but not always the means to get there. They can see every menu option, every HUD element, and every feature of a game clearly, exactly how it should look, and how it should be used, and how much fun it would be to play. They tend to be good writers, artists, or musicians as well. This kind of programmer is good to have your team too, but is more likely to contribute through ideas and enthusiasm than through original code. If you are a visionary yourself, you will probably want to team up with a hard core techie who can solve the kinds of unusual problems that your ideas will inevitably create or force yourself to spend some time every day learning more about computer science.
  • The tinkerer: the tinkerer is the kind of programmer who likes to take programs written by other people and see how they can be made to work together, or how they can be expanded and improved. They are firm believers in the adage that there is no use in reinventing the wheel, and tend to stick to improving on the work of others. They often know a lot about a lot of different programs and file formats, though they may not have written any complete programs themselves. These kinds of programmers are especially good to have on your team in modern game design where so many powerful and robust solutions to common problems have already been written. The problem with tinkerers is that they less likely to implement a truly original idea themselves, preferring to restrict themselves to existing technologies. A lot of modders fall into this category. If you are a tinkerer yourself, you may want to gather a team of like-minded enthusiasts and get into game design via the modding game design path.

Every programmer falls somewhere on this spectrum from techie to tinkerer to visionary, and their position on this spectrum probably changes every day depending on their mood and their level of sleep deprivation. The important thing to understand is that these are all valid and necessary approaches to game design. The more fully that you can embody the positive aspects of each of these stereotypes and curtail the negative, the more effective you will be as a game programmer.

[edit] Rule Two: Know your objective

The next thing you need to learn is that there is no right way to design a game. Every game makes its own demands and defines its own limits.

The important thing you need to keep in mind when you are designing your game, and throughout the game's entire development cycle, is that you need to design around the core features that make the game fun to play. If fun gameplay is not your first priority, then you might want to consider a career in an alternate field, like 3D imaging or artificial intelligence. The point is, you have to be clear about your real goals and intentions. Creating video games isn't the only way to contribute to this field. If your sole motivation in designing a game is to demonstrate some new technical feature, cut the gameplay elements and focus on the feature instead.

Here are a couple of different paths to game design that you may want to consider before beginning your own project.

[edit] Programming paths

  • Climbing the mountain: this is the 'starting from scratch' approach to game design, and the one most likely to appeal to hard core techies. This approach takes a look at the tools that could be needed to create a game and sets about creating them. It does not necessarily look at the specific features required for a particular game, so much as the kinds of tools that would be required for games in general. This approach will give you the most control over your final product, but at the expense of a much longer development time. These days, a powerful, robust 3D game engine usually cannot be created by a single person, so be prepared to shop around for a lot of talented teammates.
  • Game first, technique second: this is the end-product, or top-down approach to game design, and the one most likely to appeal to visionaries. This approach takes a look at the specific gameplay features that are needed to make a fun game and designs the game engine around these features. This path is indifferent to the actual tools that are employed in creating the final product and will use off the shelf products or custom, in-house solutions depending on time and budget constraints. This approach will give you the best compromise between control and fidelity to your vision.
  • Standing on the shoulders of giants: this is the 'no use reinventing the wheel' approach to game design, and the one most likely to appeal to tinkerers. This approach takes a look at existing game technologies and tries to find the best fit to the original concept with the minimal amount of development time and effort. This approach gives you the least amount of control over your final product, but gives you the fastest development time and the best features with the least amount of effort. This is probably the easiest approach to take for a new game programmer (though the learning curve is still quite steep).

Like the programmer stereotypes, each of these paths to game design has its own strengths and weaknesses and you will probably find yourself preferring different paths at different stages in the design phases of your game development cycle. Remember, there is no one right way to make a game, but the path you ultimately end up choosing will have a profound impact on the difficulty and length of the development cycle. Here is where you need to take another good hard look at yourself and decide what you are willing to do to bring your vision to life.

For some excellent advice on starting your first game project, see the section Tips on Designing Your First Game.

[edit] Tips on designing your first 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. Perhaps pick your favorite and really flesh it out with all the bells and whistles and fantastic features you can think of. You'll run into enough trouble trying to design these simple games 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.
  • Know your options. If you are the type of person that would like to see results quickly and are interested in avoiding as many complicated and frustrating scenarios as possible (they will always be there), 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.

[edit] Choosing a programming language

If this is your first time programming, then the first thing you need to do is take a look at the programming languages and programming environments you will be using. The specific language that you use will, of course, depend to some degree on your background, and on the needs of the game.

There are a couple of different ways you can go about choosing a language:

  • 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.

The reason why your choice of a language may depend on the development environment is that not all languages support equally robust environments on all systems. If you are a new programmer, the last thing you want to worry about is setting up a complex command line build environment! Even though you may think that some obscure little language would be cool to learn, do yourself a favor and start by using a popular and well-supported environment. Unless, of course, you're the hard core techie type who finds that kind of trouble-shooting appealing.

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.

[edit] Choosing a library/API

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?

[edit] Educating yourself

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. Immerse yourself. Read everything you can. If you don't understand something, 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.

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] 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 tips

  • 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] Future considerations

While it might seem a little early to be talking about releasing your game and supporting your fans, it's never too early to start thinking about the big picture.

[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: Find a publisher, or publish 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. Contrary to popular belief, it is not only possible to make money selling FOSS, doing so is making money for many developers, such as Linden Labs. See Selling Free Software.

[edit] Getting more 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. After all, we were all newbies once!

[edit] External links

Retrieved from "http://wiki.gamedev.net/index.php/How_do_I_get_Started"
Personal tools
Categories