Resurrected Entertainment

Game Development: Introduction

September 18, 2007

There are two sides to every coin. Game development can be hard or game development can be easy. These are relative terms, of course. Just because writing a game can be easy, doesn’t mean your grandmother could do it (although I wouldn’t hedge any bets, especially with mine). Personally, I think writing any finished application is an achievement for any programmer working alone. With the help of my colleagues, I have produced several applications which have made it onto store shelves, but I won’t take the credit since my part was just one piece to the puzzle. Of course, some applications cannot be programmed by just one person. Oh sure, one software developer could work for years or decades to achieve their goal, but who has the time and talent required to design and engineer something as complex as Metroid Prime, Photoshop, or the KDE Desktop on their own? It just doesn’t happen in the real world because life inevitably steps in and takes over.

However, all is not lost for the eager programmer setting out to create a game. It all boils down to following a few simple rules and having a few good resources available. For the next couple of weeks, we’ll look at some of the tricks of the trade and present a list of books which I have found very useful while exploring game development. So, without further procrastination, let’s dive right in to our first topic.

Game Design – The key difference between finishing a game and an unfinished hack is managing expectations. Yes, we would all love to design and build a game like Halo, but that’s not terribly likely and will almost certainly lead to failure. Instead, try and reduce the scope of the project by carefully choosing the characteristics of a game you wish to include. Care must be taken to use only those features which are absolutlely necessary. You should spell out how you want your game to work, what features need to be written, and any third party tools you plan to use which can save you time. In essence, you need to write a bit of documentation. Yes, I know, documentation is a bore and some of you may find it difficult. But you don’t need to write a best-selling novel, just outline what you want to do and how you want it to work.

By translating those exciting images and ideas you have into something concrete, you’ll be able to assess your goals and overall design much more easily. It also makes your game much easier to digest for other people. If you wanted to hire an artist, for example, you would need to describe the concept in fragmented conversations over the phone or via the Internet. It would make the job of the artist so much easier if you had the design for the game already completed. In fact, most artists (the smart ones anyway) won’t accept a contract without a working game design in place. Without this document, you would be unable to tell the artist which assets need to be produced now and what can wait until later. If you know all of the work which must be completed before the artist draws a single pixel, he/she will be able to commit to a schedule and a price.

Over the last few years, several good books have been written on designing (and managing) game development projects. However, these books tend to focus on many details which are only relevant or important to large scale projects. Naturally, there are excerpts which you will find useful, but don’t get overwhelmed by the sheer volume of information. Generally, you don’t need to concern yourself with all of those details; the object of this lesson is to finish a fun game you want to create in your spare time. If followed some of those books to the letter, it would take ages to complete a project and you may find your interest in the project begin to drift after a year or two.

Project Management – When you are creating a game by yourself and for free, I don’t recommend setting a schedule. Schedules are for people and companies who must release the game in a timely manner because their economic futures depend on it. The bottom line for you and me, however, is that schedules aren’t very accomodating for new game developers and they aren’t very much fun when you’re ten weeks behind your target date. If you don’t need to release a game in six months, then why would you care that your line drawing algorithm is taking twice as long to craft as expected?

On the other hand, you could always use the project as a way to enhance your project management skills, which is admirable but you may find the accuracy of your estimates vary considerably. This is partly due to life, who once again chooses to interfere with your project. As a programmer at work, I can count on having at least five or six hours a day for solid work. At home, my free time will vary wildly. If you only consider the cost (in time units) and forget about dates, then you may find your estimates more useful. If you really insist on reading a book to brush up, then I recommed:

  • Joel Spolsky’s book entitled Joel on Software. It’s a compilation of articles for novice program and projects managers. It has a number of good practical tips which can benefit almost any software project, including projects done by the hobbyist.

No Responses to “Game Development: Introduction”

Care to comment?