LESSON #16:
Making Games The Hard Way:

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!

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:

Q: I have this great game idea for �........ How can I sell it?
A: YOU CANNOT.

Q: That sucks! Why are things that way?
A: Well it doesn't make things any easier, no... But the best answer to your second question is: MONEY.

Q: Alright, alright! I can�t sell my idea, but I still think it will be the best thing since Pacman/Deus Ex/Sliced Bread, how do I go out there and make it?
A: If you�re really interested in actually designing and making a game, Tom Sloper has several articles on how to get into the game industry, and about game development and design (right here on this website). He covers many of the approaches one might take to try and develop your game idea. I am going to deal specifically with one: The Garage Game Developer.

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.

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.

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:

A) You want to be able to maintain a realistic set of goals/milestones for your group, and keep up with them. Being able to accomplish tasks on time and see their results is a great morale booster.
B) You do not want anyone in your team (especially those eager to participate) with nothing to do because you have too many people.

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:

1. Look to your Friends: The first and easiest source to look for potential project collaborators will probably be with your friends. The most important reasons are of course because you know them already, you probably have a pretty good idea as to what sort of skills they have, and they will probably be more willing to work with you because of your existing friendship. Similarly, if your friend is a programmer or artist for instance, there's a chance that they might know other programmers or artists who would also be interested. In my case, I had a friend who was an accomplished programmer, and once I had convinced him to join with me, he knew a whole other series of programmers who might be interested. After talking with some of them, and finding a few who seemed eager to participate, they also had some other contacts that were interested, and so on.

This is really the very basics of human networking, and should be considered a valuable secret weapon towards assembling your team. One danger however when looking to friends for help, is that you already have an existing relationship with them. Remember that as soon as a friendship becomes a working relationship, the dynamics may change drastically or the friendship might suffer. You and your collaborators have to recognize from the beginning that everyone is participating to fulfill a particular essential role on your team, where they must respect the relative positions and skills of others. Otherwise your local team is in danger of becoming some kind of game club, where everyone hangs around at meetings, and don't ultimately get much in the way done. Your goal should always be to assemble a Garage Game project that can succeed: Make sure that everyone involved takes what their doing seriously before they get started, and be sure they actually recognize that there will be lots real work involved.

2. Look to your Immediate Area: To my mind, it is always easier to start close,
branching out further and further away as you require. For a garage developer, finding all the necessary people may well necessitate going beyond your friend-base and social networking means. If you need a sketch artist, but don't know any, there's a good chance there are probably several in your area, and some might be interested in participating in a project like yours. Look for gaming, programming, and artistic communities already set up in your city. Often Universities will have several of varying kinds: student associations, clubs, online local interest groups. At the very least you might want to post up a 'Help Wanted' sign on some of the open university ad boards detailing who you are and what you're looking for. Make sure though to be straightforward that what you're offering is not a paid job: people might come breaking down your door with resumes for the chance to work for a 'game company'.

If you have any takers on the local scene, make sure to set up a time and place to meet for an interview first, don't just accept someone onto your team without knowing a little bit more about them and their interests. Even if someone seems to be a fantastic artist, if their personality or character would seem to conflict with yours or those of your current team, you should think twice about including them on your project. One idea would be to take some of your current team members with you, prepare questions ahead of time relevant to the skills and interests of the person you're interviewing for your team, and discuss the candidate amongst yourselves afterwards. Taking a professional doesn't hurt here!

Understand hoever, that you'll probably have to provide a lot of information on your project to the person to get them interested in any way beyond the initial inquiry. Be ready to pitch your idea, use your design as a reference, and its always a good idea to have a Non Disclosure Agreement at hand before talking about specifics on your game.

3. Look Beyond the Garage (Internet Sources): Once you've exhausted your local options, the internet presents a vast source of people interested in working on game projects. Just looking at the number of Mods, independent developers and the like online is astounding. They come in all colors and varieties, some much more professional, experienced, and overall devoted to their projects than others, but it is really a testament to the number of people around the world interested in getting experience in game development. All that said, the Internet provides some other complications to the aspiring development team. The main one as I see it, and the one which has most been a problem for me in the past is 'communication', and I'll get to how to deal with that shortly.

Recruiting online will require at the very least a nice looking website that you will update regularly. If you have already developed any content related to the release of your game, particularly visual content, you should create a section for conceptual work and screenshots to allow people to marvel at your progress. The more good quality content you have on your site generally, the more interest you will be able to draw to your project, and possibly more collaborators. When looking for people, scour the game art, programming, and music forums and sites and post your wanted add in the appropriate section (if they have one). Make sure to link your site and email address so that anyone who might even be remotely interested will have something to look at and be able to contact you directly. There are hundreds of such forums where interested people can be found. However make sure that you keep to the proper etiquette for these forums, especially in your 'help wanted' posts. Make it clear exactly what skills you're looking for, what other requirements you may have, what incentives you offer, and that the position is not a 'paid' one. This goes without saying, but do not spam forums with your posts either, we all know you're eager, but people won't respond any faster, and might just get annoyed. You have to sell yourself (your project) without looking or sounding like a salesman.

Local Team Organization: This should technically be the easy part, but I've found tends to provide the most regular difficulties. Find a time when all of your local team members can meet regularly (our team meets once a week and it's usually enough time to accomplish basic goals without losing too much in the way of direction), and make sure to stick to it! Finding a place to meet can often be difficult, this tends to be where the whole 'garage' aspect comes in. Someone usually has a house, garage, or basement that's large enough and relatively peaceful enough to conduct a meeting for a few hours. I would suggest that meeting in a caf� or some other kind of open area should be your last resort. Public places offer too many distractions, and it is difficult to conduct tutorials or give instructions to a large group in a public place without drawing some type of attention.

Once you do have a meeting place and time, it's important to prepare beforehand. Obviously, there will be a lot of things to say at the first meeting, introductions for everyone as well as a formal introduction to the project are a given. You should concentrate on organizing the layout and milestones of your project. Speak with your programmers before the meeting and discuss the essentials of what you will need to accomplish in code, speak with your artists and discuss what you need in content. Get some rough estimates on how long it would take one person to accomplish each task, and use them as a guideline for setting your goals. Bring all of this information to the meeting and lay it out for everyone on your local team. Discuss who is best suited to fulfill particular tasks, and above all who wants to take on certain types of work. Layout a timeline for your goals, encourage your team members to be honest about the amount of work time they contribute, and how quickly they feel they can achieve their assigned goal at the outset. Remember, just because you're spending all of your time on this doesn't mean that everyone else will, or are even likely to. Keep in mind that some help is better than no help, and that it will take time to get other people as enthusiastic about your idea as you are. The important thing is that you set your goals realistically, and that everyone sticks to them.

It's nice in these meetings to have some kind of black or white board to write on, so that various people on the team can illustrate goals, problems, or make explanations.

I personally think it's wise to have a designated secretary to take down the key points you go over during meetings. We originally had one of our team members as a secretary, who would take down the highlights of our meetings and then post them on an SSL encrypted server on the internet. A private team forum could serve just as well however, and would probably be less of a hassle overall.

Make sure that you give the opportunity for everyone to speak at a meeting, to voice their opinions , thoughts, and above all concerns on the status of the project. This is something you should always encourage as long as it is on topic (try to stop any conversation tangents as soon as they begin), and not obnoxious. Each team member has their own perspective, and it is valuable to have plenty of input. Be flexible with people's suggestions for changes, but make sure that their reasoning is well supported. I ask anyone on my team who feels something should be changed in the project to write down their argument for me, with reasons as to why they believe the change is necessary. This gives me time to think the whole suggestion through rationally, and respond with an agreement or disagreement and my reasons for it.

In most subsequent meetings, you should be encouraging everyone to explain what they've been working on since the last meeting, how much progress has been made (if any), and what they feel about the remaining challenges to finish their goal. Never use this as an opportunity to berate any member for being slow in their work. If a team member is having trouble with a particular goal, make sure to support them and encourage the rest of the team to do so as well; the last thing you want to do is lose someone to frustration. Also, be ready every meeting with the next series of projects/goals for your team to work on once they've accomplished their current one. You waste your and their time if you have nothing for them to do. Keep your progress in context, and use your steady accomplishments to help the morale of the team. If everyone knows that the work their doing is going somewhere, that helps to encourage them to continue working, and hopefully with rising enthusiasm.

Remote Team Organization: A remote team is a hard thing to manage, especially for one person. The largest hurdle is being able to maintain a consistent and clear level of communication between your local team and your online collaborators, who will likely be scattered across the globe. The internet fortunately provides us with several tools to keep contact, although most of them do not reach the level of effectiveness of talking to someone on the phone or in person. Since we're still pretty far off from the mountains of cash and free Ferraris, there are several cheap ways to keep in touch with your team effectively:

1. Email: One of the most readily available forms of communication
online, email will probably be your first tool. The important thing is to recognize its limits however: Email is great for detailing large project assignments, checking in on people's status, and updating your team with news. It is not very good however for detailed explanations or discussions, which will come up quite often during project development. Email will be a very valuable part of your remote communication network, just make sure that it isn't the only part!

2. ICQ and other Messaging Clients: I personally find messaging software to be valuable for dealing with the many problems and confusions that crop up around assigned projects. Making yourself, and your other project leaders directly accessible will allow for quick resolution of a lot of the simple problems and questions your remote team members may come up with. Having this kind of instant feedback will also make it easier to keep track of progress and projects as you need it, and is a much better way to gauge the feelings and general morale of your team members(in contrast to email at least).

3. IRC and Chat Programs: Another communication medium that provides a more direct back and forth approach is the IRC and other chat programs. This is one medium I have not used extensively for my remote team, simply because I've found the instant messaging clients to be a lot more convenient and appropriate for our team structure. However starting a dedicated chat room for your team will allow for easy and quick communication for a large number of people at once. Sometimes this may be difficult to manage, but is probably the best way to get your whole remote team together in one place.

4. Private Team Forum: If you've got a website up (you should!) then you should be able to put up a forum on your site, and designate part of that area private for your development team. There are some free forums available on the net, and they're reasonably straightforward to set up if you read the documentation. A forum can be a very good base for creating a strong community for your development team, both remote and local. By having a posting area exclusive to all team members, people can post art, and progress shots and discuss the game openly. This will help to keep up collective interest in your project, and contribute to the team's morale.

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.

1. Design: Represents the layout and plan of your game as you well know, it will probably also be the easiest to organize, since in most cases it will probably just be you. Remember that the role of design is to give the rest of the team a map, framework, and context to work with and towards, so make sure you fulfill your duties.

2. Code: Your game code represents the infrastructure and implementation of your design. Decide ahead of time whether you would like to work on your game using a pre-existing game engine that has its source code available, or whether you want to work on an entire engine from scratch. There are several advantages to using publicly released source code: First off, it will allow you to tinker with something that you know already works. Additionally, there will probably also be some form of technical documentation available on the code, and a public user group for other individuals using the same source, and no doubt running into many of the same problems that your team might. The main disadvantages to using a pre-existing engine is that rarely will it have been designed to support the exact type of game you're planning to make, it may well take just as long to understand the engine's code design as it would to build your own, and finally, most engines have limitations on using their code for commercial purposes. This will normally not be a problem if you plan on producing freeware games, but make sure you read the licensing agreements included with the code.

Organizing the code itself can also become complicated. One of the best ways I know to allow for multiple programmers to work on a single code-set is by setting up a CVS or similar server. CVS is a program that allows you to make your source code available online (publicly or privately), permitting other programmers with access to merge their code safely. CVS and other code-sharing programs have several fail-safe options to allow you to 'roll-back' your code in the case that a recent merge has caused it to be unstable. I would argue that if any of your programming team is based outside of your area, then a code sharing platform will be utterly necessary for keeping your programming developments organized and in one place. I have been fortunate to have the majority of my programming team in my local area, however we still find the use of CVS particularly valuable, as we do not have an office, and cannot always bring our computers together.

Finally, it is important that all of your programmers understand their role with regards to the code. The best way I've found to organize this is to build a programming team based around a Lead Programmer who not only has an understanding of your layout and the code-base you plan to use, but who also is very good at communicating and articulating ideas (this may be more difficult to find than you think). The role of the Lead Programmer is not to be the 'genius behind the code', but to be a director. The Lead should be able to understand what is involved in the project, predict what sort of coding goals will be necessary to achieve certain aspects of the project, and be able to lay them out and explain them in terms that other programmers can understand. As the Game Designer, it will be your responsibility to communicate constantly with your Lead to ensure that your headed in the right direction, and that you're making the right sort or progress. The Lead should also be responsible for establishing and enforcing a standard structure in your engine, so that everyone will be able to read and understand everyone else's work on the engine.

3. Art: Your art represents all the content, visual and aural, that you'll need to produce for your game. For organizational purposes, music, sound effects, and visual art tend to each represent an important segment of game art, however for the moment I'll just look at organizing graphic art since it often involves several people. Much like for programming, it would be a good idea to find someone responsible that you can designate as an Artistic Director.

Much like with programming standards, you will have to develop artistic standards for your project. If you have 10 different artists, all submitting various pieces for your game without any direction, you'd end up with a final product that probably looked like your 4th grade collage. You should find an artist with at least a general understanding of all the artistic tools that your team will be using, as well as an intimate knowledge of the themes and styles that will be employed in your game. Additionally, the Artistic Director should also be chosen for his/her ability to communicate with, and constructively advise all of the artists on the team.

When I began organizing our artistic team, we had recruited a conceptual artist who fit just about all of these requirements, but had little knowledge of 3D modeling. Because I did have a fair understand of the tools we were using, I took the major role of artistic director while deferring to him for advice and suggestions and encouraging him to research more on our 3d tools. Although this gave me a larger work load, it gave our future Artistic Director the time to learn what he needed to know to fulfill the job along with the chance to ease into an experience he wasn't familiar with. Not an option for everyone, but something to consider.

In addition to getting good artistic direction, it's helpful to develop file format and detail standards for your game.

When we just began assembling our art team, we had modelers working without any level of detail limitations, they didn't ask for a poly count restriction and we didn't think to give one. What we ended up with were some really beautiful models that would never be able to render on any of our video cards in real time. We have since learned to test our limitations for detail in engine before assigning too many ambitious art projects, and establish standards for everyone to achieve and follow.

Finally, when organizing your content, it goes without saying that art should be directed towards one source that will allow particular content to be easily accessible to those that need it. If you're a hands-on game designer, you may want to take in and organize all the art yourself, or have your Artistic Director keep things organized, however setting up some form of private file-sharing system, or FTP server to allow for easy access to files on your team might be ideal.