Making Games The Hard Way:

How to Start a Garage Game Development Company

NOTE: most of these lessons are primarily aimed at aspiring game designers, but this one could apply to aspiring game programmers or artists as well- specifically, those who want to get an independent game development effort started themselves!

June, 2002

Please welcome guest lecturer Noah Decter-Jackson (exender@complexgames.com), Project Lead and Crate Master of ComplexGames.com (http://www.complexgames.com/), an independent game development company originally founded in March of 2001 by Adrian Cheater and Noah Decter-Jackson, and located in the frozen wastes of central Canada. Noah (using the screen name 'Exender') is an occasional contributor to the Game Design BB and has graciously offered his perspective in answer to the frequent request for information from aspiring Lone Wolves (those who wish to create an independent game). Tom is taking a seat with the rest of the class, and when he speaks up, he does so in red text.

Part 1: Getting Started

By Noah Decter-Jackson

Disclaimer: First and foremost, I would like to begin this paper by saying that I am not an expert in game design, game development, or company organization, although I intend on being such one day. I am just another guy trying to make his game design goals a reality. I do however think my experiences so far with my own garage development company are worth translating into some advice on how to get started in the wonderfully difficult and interesting world of Garage Game Development. Use any of the following suggestions at your own risk!

1 - Introduction:

This paper speaks directly to the aspiring professional Game Designer wanting to produce a game and ultimately publish it by forming a 'Garage Game Developer'. However it can similarly apply to any aspiring professional Game Artist or Programmer interested in doing the same thing. This paper will deal with general guidelines, and not get too involved in specific situations. Subsequent papers will try to deal with specific ideas, resolutions, or problems that may be useful to learn from.

The first thing I would encourage, if you haven't already done so, would be to read through Tom Sloper's site, particularly the Game Design Lessons in his advice column (click the links in the nav frame at left). Here you will find answers to what are probably your first questions, along with many others related to Game Design. One of the most common I will reiterate for effect right now:

Explanation: Ideas are a dime a dozen, fully developed Game Designs are more like a quarter a dozen, but that's still not saying much. Game Publishers are not interested in buying ideas, they have plenty of their own. What they are interested in is finding products they can sell for lots and lots of money. Not the concept, but an actual product. The only major exception to this rule lies with the already established industry professionals who have well proven records, high profitability prospects through previously shipped titles, and good self-marketing skills. Smart investors looking at any business venture will analyze the experience and reputation of the management team behind the product that they're pitching. If you send a design to a publisher/developer it will most often either be returned or shredded, this is because of legal issues surrounding creative property. They do not want to risk getting sued.

Explanation: Examine any similar commercial entertainment field, particularly those involving product oriented releases like book publishing, music recording, and film production. In all those examples there are established studios, authors, and groups who regularly receive large contracts from Publishers in order to produce the releases we see in the theatres, on the shelves, and in the local music stores. Why do they get these contracts? Because they have proven records or established professionals behind them. Just like it was mentioned in response to the first question: a reputation is often the most promising guarantee for future revenues as far as a publisher is concerned. And as much as it reportedly happens anyways, publishers don't actually want to waste money, they want to make lots of it...so looking at 'sure-things' like sequels and spinoffs, makes sense from an economic point of view. They aren't normally going to throw a pile of money at some guy off the street they've never heard of. Would you?

2 - Recording the Dream:

Alright, so you want to make a game, presumably you want to design it using your great idea, but you have to be able to do something with it to make an actual game. The best place to start is by working out a solid design for yourself, outlining exactly what it is you want to accomplish with the game, how it should look, feel, play. Once you have that down, you should consider flushing out an extensive Design Document from your basic ideas, detailing specifically how you want things to work in technical terms, how it should play, the objects involved, cause and effect relationships, scripts, content requirements, everything.

There are several resources on the internet with information on how to structure a Design Document, some even contain sample docs to look through. Again, Tom Sloper's site is an excellent resource for Design Documentation, and his Biz Links contain even further material. (See the nav frame at left.)

One thing to note is that assembling a complete design document takes time, lots of time, and a good document is one that is constantly refined (though not-rewritten) throughout the development process. It helps to have a clear vision of the goals required to produce your game, especially when you're looking to get help working on it. Finishing a Design Document is also a pretty reasonable indicator of your own dedication to your original idea. If you can't finish writing about your game in its entirety, how do you expect to produce it?

One key to a proper design is research. If you don't know much about what components make up a video game, then you'll have trouble writing about what you need. There are several websites and newsgroups about game design and development, some are frequented by people with a lot more knowledge on the subject than you or I possess. Send questions openly, but make sure to be polite, clear, and specific about what you want to know.

3 - Defining Your Needs:

Alright, you have your preliminary design, and hopefully you still feel confident and excited about creating your game. Unless you can design, program, produce art, and even compose some kind of music all on your own (and some people do), then you need a team of people who can help you with the parts you're missing. In this case, we're going to look at putting together something like a Garage Band, only minus the Rock & Roll (in most cases).

Before starting to look to other people however, you should seriously examine your own skills: Determine what it is you can offer to your project. At this point, game design is probably one of them, but do you have any other talents that will help your cause? Can you program, or produce concept/2D/3D art? Can you compose or produce music? Are you able to design web sites? Have you been in charge of a team in some way, or worked in any kind of management capacity before? Can you make clever impressions of Hollywood actors? If you have skill you can contribute in any form to your game development project, it's probably best to start thinking about how you can use them.

If you're just interested in creating a design and letting all the 'little people' do the work for you, it's a nice thought but you might as well stop reading here. If you want to produce your dream, you'll have to take an active role in your team (if you can recruit one). To get anywhere near having your game developed, you'll have to work harder than everyone else helping you, spend more time, and basically make an example of yourself for others to follow. A project without a strong and dedicated leader can crumble long before it's begun. Producing just about any kind of game will involve a lot of hard work, communication, and understanding on your part, and may well bring a great deal of frustration, desperation, and perhaps even anger to you as well. If you get very far into your project, you can become too attached, and when there are complications you may find it hard to deal with. Understand at the outset that you'll run into problems, that's natural, but try to be ready to master your own negative emotions before they interfere with progress. Dealing with difficulties rationally is one key to good leadership, and not the easiest thing to do when it involves your own creative designs.

If you still feel confident and eager to get your design off the ground, you should now start looking at putting together a team.

4 - Assembling the Team:

Take a long, hard look at your design and decide what kind of skills you'll need to produce your game. Break your design down into miniature projects/goals, what sort of skills do you need to produce your game's content? Also look at how quickly you expect to achieve those goals. If you want to build an entire game engine from scratch and have your game ready for release in a year, unless the scope of the design is very limited, it would be preposterous to think you could do so with a single programmer. If you don't have any programming skills yourself, it might be better to wait until you have recruited a programmer (which I'll get to in a minute) or at least done some informed research before setting up some programming milestones. Although these figures are supposed to be rough, the point is to guess roughly how many people you need for your core team to accomplish your required goals. It is important to have a good idea as to your capacity because:

So take a long hard look and write down your ideal personnel list for now, listing the people with the type of skills you need. Keep in mind that this will probably change greatly as you go and run into problems.

Finally you must decide exactly what kind of game you want to produce. Do you want to develop freeware or a MOD? Do you want to develop shareware in hopes of getting some kind of income out of your work, or do you want to go all the way and produce something that you plan to someday hit store shelves. This decision will guide how you try to draw skilled people onto your team. If you want to create freeware games, about all that you can offer your future collaborators is the experience of working on a game project and perhaps the recognition of that game's release. With the shareware option, you can offer the experience and recognition as well as a percentage of royalties from shareware sales as part of your incentive plan. Finally, by going all the way to a commercial product, you could offer experience and royalties, as well as potential future employment through a publishing contract for your game. There are many other options and incentives that you can likely think up, although probably too many to list here. Make sure however that you plan this ahead of time, write a tentative contract for all collaborators linked to their contributions, give them some reason to help you.

There are many online and book-based resources on writing contracts, putting together partnerships, and dealing with the legal details. Make use of them! One thing you should note however, is that if you are minor and/or dealing with other minors, contracts are not necessarily legally binding. I would personally advise any minors to stick to making games as freeware or at the most shareware, and not look seriously at putting together a game for a publishing contract before they're 18. Regardless of the skills, knowledge, or practicum you have, few companies will look at a minor seriously, nor will they hire or contract to a company run by people underage. Food for thought, you can always use that extra time to further develop your skills and/or games anyways.

Now that you know what you need to get your game started, you have to begin looking for people who will work with you, and not only that, people that will work with you for free. This is a system I used to put together my team:

Now that you've started to successfully recruit your team, you can look at how to organize yourself.

5 - Team Organization:

You have your team, you're all ready to get development going, what do you do now? The answer depends greatly on how your team is set up; Locally or Remotely. Now that you have some rough ideas on how to keep your team organized, we should take a look at how to keep your project itself organized.

6 - Progress Organization:

Once you are able to keep up communication with your team, you should take a closer look at how to keep that project organized. Games are made up essentially by three major components: Design, Code, and Art. These can all be broken down a good deal further of course, however for the sake of understanding we'll use this broader example.

Now that you've got everything organized, you're all set to get started and start making that game dream of yours into an actual reality. Things don't get any easier from here however. There will be tons of work to do, and plenty of difficulties and roadblocks along the way. In future articles I hope to address many of the problems Garage Game Developers commonly face, and some ideas on how to best resolve them without shooting yourself in the foot.

Tom adds: Then of course there's the question of what to do with your independent game after you finish it. You want to share your brainchild with the world - and make some money back to boot. There are lots of different models for how to proceed at that point. There are self-publishing routes, there are sites where they help promote indy games (see FAQ 60).

And, of course (as is discussed in Lesson 11) there is the publishing deal route. I myself have never done any of these (I've never created an independent game), but there are lots of places where you can find folks who have. You can post questions on our Game Design BB and you can check our Links Page to find other forums.

In October 2002 Brad Wardell gave a talk at his local IGDA chapter about his experiences as an indy game developer. http://www.joeuser.com/Articles/Onbeinganindependentgamed.html

Here's a book that'll help too. The Indie Game Development Survival Guide by David Michael is listed in FAQ 8.

Indie Games Con is "a fun, informal and informative gathering of independent game developers from around the world. IGC is designed to be a summit meeting of like-minded developers with the shared goal to focus on collaboration and building community. This is an unprecedented opportunity to meet other indie developers, professional guest developers, hardware manufactures as well as the GarageGames staff." The conference takes place in Eugene, Oregon, USA, on October 10-12, 2003. More info can be found at http://www.indiegamescon.com/.

A website that is both a software store (perhaps selling stuff made by garage gamers?) and a clearing house for garage gamers to meet one another and join or start indy projects is http://www.garagegames.com.

For European indies, there's The Independent Games Developers Association, whose overarching objective is to keep independent developers in the UK and Europe at the heart of the global Games industry.

For more ideas about how to handle the publishing problem, see FAQ 60.

I want to thank Noah for writing this article for us, and I hope you appreciate it too.

Also: Game Attorney Thomas H. Buscaglia has created http://gamedevkit.com/, chock full of Business and Legal Information and Forms for Start-Up Game Developers.

The GameDev.net "Business and Law" forum is an additional must-read. And after reading some posts for a while, join in the discussion and learn lots from your peers.

Another indie development discussion forum: http://forums.indiegamer.com/.

Got a question about this article? Click here to go to the bulletin board. You'll get answers!

Click here to go to the previous lesson.

Click here to proceed to the next lesson.

Click here to return to the School-A-Rama main page.

© 2002, 2005 Noah Decter-Jackson and Tom Sloper. All rights reserved. May not be re-published without written permission of the authors.