Last issue, we talked about how to structure the design document so that it could be used as a development tool. I stated various reasons as to why this must be so and gave you an idea of how to create it so that it could fulfill this role. Nothing much from the last article applies here except for that sole idea - we'll mainly be drawing off of knowledge gleaned from Part 2, where we discussed issues that may trip us up during development.
Well, now here we are, ready to begin, and we have to try and remember what I told you back in The Design. Many of the problems discussed there will crop up again while you are developing the title, so keep you wits about you so you can spot them before they become malicious little buggers. In this article, I'll be discussing new topics related only to development, but a few will touch back upon what we discussed in part 2 - remember that.
Now, since it would be too long of an article to take you through every step of the developmental process, the topics following will discuss certain aspects of the process. After reading this, it won't be hard to fill in the blanks and churn out a beautiful game.
But enough talk. Let us begin.
[size="5"]The Team
Before we begin, or should I say, before you begin, I suggest you take some time to stop and consider the team you have assembled for the task at hand. Sure, there may be game bugs, or feature creep, or eye-candy or bad management - but nothing will throw a wrench into the gears better than a bad team member. And the worst thing is that some of them may not become bad apples until later on. Worse than that - some might go as far as to undermining the project without the management even realizing it, or you, for that matter.
How can you avoid this? Well, technically it's not your job. However, you would like to see your idea become a reality, so playing Mom is something you can do in your free time. Now, generally the problem with team members never arises. Usually teams are composed of old friends who know each other and what they can and can't do. However, some teams are assembled completely from scratch with no one knowing much about the other guys.
To be brief, you should always be on the look out for a wolf in sheep's clothing. And even if you feel safe with an experienced team, the famous and well-known "crunch-time" period could set in with devastating results. Of course, you have a great design doc so there's no way your project could come near to going over schedule. Uh-huh.
[size="5"]Team Roles & Assignments
Now that we know to keep our eyes peeled, we can assemble the team into its working form. Today, teams are huge and consist of many different types of people. Back in the day, it was one to three people taking on the jobs of designer, programmer, and artist. But the game industry is slowly but surely turning into something akin to Hollywood in terms of production. It's not a bad thing; it's just what's happening.
I've assembled a list of roles and divisions to present to you. This is my view on how the team architecture should be constructed. If you disagree, no problem - you can use this as a starting point for assembling the team you think would work best for your project. It's an exhaustive list, I know, but it gives you a lot of information. The list is broken into divisions, and further into job titles. Below each job title is whom that person answers to and whom he or she consults with on issues. It's best to keep your team nicely structured so that information is passed along set pipelines to reach its destination. If you do this, everyone who needs to know will know, and those who don't will remain contently oblivious.
[size="3"]Management Division
Software Planner
Answers to: Project Manager
Consults with: Game Designer, Lead Architect
The Software Planner has the job of thoroughly reading up the Design Document (a requirement of all Leads) and consults with the Game Designer and Lead Architect. The Software Planner is responsible for taking the game design and breaking it up into a set of technical requirements. These requirements will lead to the planning of the game engine, graphics engine, scripting engine, etc. It is up to the Software Planner to lay out these various technical aspects and estimate the amount of time needed to complete each.
Lead Architect
Answers to: Project Manager, Game Designer
Consults with: Lead Programmer, Software Planner, Lead QA
The Lead Architect has the job of laying out the general module structure of the game. He works with the Lead Programmer, who further breaks the modules down into functional aspects and assigns them to various programmers. The Lead Architect also reviews all code sent up from the Lead Programmer to ensure it is technically correct. The Lead Architect consults with the Lead QA in order to determine if there are any snags in the game, which he then reports to the Lead Programmer.
Project Manager
Goes through: Lead Programmer, Lead Artist, Composer
Consults with: Software Planner, Lead Architect
This is the head-honcho. To prevent the Project Manager from seeming more powerful than the other Leads, he cannot meddle directly with any Programmers, Artists or Musicians. Instead, he must go through the Lead assigned to that department and the Lead (much to his pleasure) can deny the change if he feels it will not benefit or may detract from the development based on his experience (which may or may not be shared by the Project Manager). The Project Manager also draws up a production schedule based on the estimates and technical specs derived by the Software Planner and Lead Architect.
Game Designer
Answers to: Project Manager
Consults with: Software Planner, various other Leads
The Game Designer is the one who prevails over the project's design document. He is the only one with the power to change the structure of the document and make any changes to it. The Game Designer oversees all aspects of the development process by consulting regularly with all the division Leads to ensure that all work outputted matches the idea set forth by the document.
[size="3"]Programming Division
Lead Programmer
Answers to: Project Manager, Game Designer, Lead Architect
Consults with: Project Manager, Software Planner
The Lead Programmer is the most technically skilled member of the programming team. He knows the most and has the most experience. In a large-scale project the Lead Programmer is expected to spend more time administrating than programming. It is the job of the Lead Programmer to consult regularly with the Project Manager to ensure that his programmers are on schedule. He consults with the Software Planner to discuss any problems that may have cropped up and if they need to be redone or dropped.
In a small-scale project with only a few programmers under his command, the Lead Programmer can spend equal time programming and administrating.
Programmer
Answers to: Lead Programmer
Consults with: Lead Programmer, other Programmers
The Programmer is basically in a world of his own. His project scope goes no farther than the Lead Programmer. Programmers have the responsibility of carrying out orders handed down from above. These include following technical specifications, guidelines, etc. A programmer in a large-scale project will usually be assigned a certain section of the program to work on throughout the project. In a small-scale project the programmer may be assigned varying areas within the project.
Programmers must be able to talk to one another in instances where their tasks overlap (such as integrating graphics with sound so that when the player hits a wall he says "Ouch!"). This means they have to code cleanly and comment all areas of the code. Depending on the Lead Programmer, Programmers will be required to know everything (including reading the design document) or learn things on a need-to-know basis.
[size="3"]Art Division
Lead Artist
Answers to: Project Manager
Consults with: Game Designer, Lead Programmer
Unlike other team roles, it is possible for the Lead Artist to be working on another project as well. A shortage of Artists to teams may require this. Since the detail and quality level of art is much more easily perceived than that of code, the Lead Artist can handle the task of managing multiple projects. Also, because of the ease involved in grading artwork, the Lead Artist should be spending most of his time drawing. He consults with the Lead Programmer to ensure that his images (and those of the Artists) are meeting the technical specifications handed down through him from the Lead Architect. He consults with the Game Designer to ensure that his artwork (and that of the Artists) is in the image the Designer finds suitable.
Artist
Answers to: Lead Artist
Consults with: Lead Artist, other Artists
Like the Programmer, the Artist is somewhat detached from the development and works only through the Lead Artist. Also like the Programmer, the Artists have to be able to talk to one another verbally and discuss aspects of the art design when their tasks overlap (like one Artist designing a house to fit in a setting designed by another Artist). Like the Lead Artist, an Artist can be working on various projects at the same time.
[size="3"]Music Division
Composer
Answers to: Project Manager
Consults with: Game Designer, Lead Programmer, Lead Artist
The Composer is the most talented musician on the team. He comes up with the scores and assigns them to his Musicians to produce. The Composer also determines what sound effects are needed throughout the game and assigns them to his Sound Effects Technician. The Composer does not have produce his own scores. Instead he should be watching what his Musicians are putting out and keeping tabs on the Sound Effects Technician while developing new scores. He consults with the Game Designer to determine score lengths and moods, and the Lead Programmer to determine technical guidelines on the music (format, bit rate, etc). He will also on occasion consult with the Lead Artist if he has any visuals (cut-scenes, images, etc) that the composer can use to help get a feel for the mood, action, and setting.
A Composer may also be required to compose interactive music, which changes with location, setting, mood, etc. This will require a closer interaction between the Music and Programming Departments.
Musician
Answers to: Composer
Consults with: Composer, other Musicians
Like any other person low on the ladder, the Musician only has to talk to the Composer. The Musician's job is to take compositions handed down from the Composer and actually create the musical scores. If this requires a real band or orchestra, the Musician may be able to conduct himself.
Sound Effects Technician
Answers to: Composer
Consults with: Composer
The Sound F/X Technician has the fun job. He gets to figure out how to make the sounds that will be heard while playing the game. These can include gunshots, explosions, background noise, ambient noise, footsteps, etc. Many sound effects are already made and stored in libraries that can be licensed out. It is the job of the Sound F/X Technician to locate and use these libraries if necessary. Since sound f/x production may require little thought, a Sound F/X Technician could be working with another project.
[size="3"]Support and Quality Assurance Division
Lead QA (Quality Assurance)
Answers to: Project Manager, Game Designer
Consults with: Project Manager
The Lead QA is the man in charge of testing the game and putting it through its paces. He comes up with testing plans to try and bring out bugs and assigns these plans to various QA Technicians. He then reports the empirical results of the tests to the Project Manager who in turn can alert various project members to any problems.
QA Technician
Answers to: Lead QA
Consults with: Lead QA, other QA Technicians
Another low rung that only goes through the Lead QA, the QA Technician is the person who gets to play the game again, and again, and again - until his eyes fall out. The QA Technicians take test sheets handed down from QA Leads and run the tests, writing their reports on the sheets during so many iterations. QA Technicians usually do not directly consult with each other unless they discover a bug that affects two or more areas of testing. The QA Technician is also responsible in the beginning to test out the code produced the programmers to ensure it is stable.
Support Technician
Answers to: Project Manager
Support Technicians can have many names. With the industry expanding so, these technicians may be called in to do FMV sequences or motion capturing for the game. The Support Technician could also be an office local in charge of taking care and administrating the company network and database.
[size="5"]The Project Schedule
If I may, allow me to describe a Dilbert comic that I found to be so true. Dilbert is sitting across from his boss, who says, "Can you explain why your project is behind schedule?" Dilbert replies, "Yes. A schedule is an artificial device created without knowledge of the future. Wild guesses are used as surrogates for knowledge. Project deadlines are tied to trade show dates instead of reality. Then management cuts the budget until failure is assured. I assume you called me here so you can apologize for your role in all this." His boss just stares at him, and he goes on to say, "Would you like to know how budgets are created?"
Well, I got a good chuckle out of that one. Basically Dilbert was exaggerating on how management can handle budgets and schedules. Well, I'm sure there are some cases that could prove he's not exaggerating, but we won't even go there. Basically, when a project schedule is created, it should be realistic. The general image of programmers pulling all-night shifts to meet a deadline certainly is real. It just isn't necessary. Padding should be in place to allow for small setbacks. Large setbacks should never happen if your project has a smooth architecture and your design and technical specs are up to date and detailed.
Dilbert also points out how schedules are created without knowledge of the future. There's really no clean way around this. Having a partial schedule will not please your investors, and creating a dynamic schedule can lead you around in circles. The best you can do is to realize that there will be setbacks, and that there will be changes, and that you will have to deal with them. The best time to do this is, of course, at the beginning. Coming up with a schedule that's both forgiving and pleasing (to your investors) is a tough job, but one well worth the time and effort.
[size="5"]Using Milestones and Checkpoints
Despite having a good schedule, you should always pause for a reality check. Stop and smell the roses. Milestones and checkpoints help you stay on track, but they must be used carefully. Too many milestones and it will feel as if you really aren't going anywhere. To few, and you may miss something crucial and not look back and realize it until a month or two later. Ouch. The same goes for checkpoints. If you decree a checkpoint every two days, the programmers and artists could feel weighed down by the burden. If you say checkpoints every two weeks, people may finish early and start lounging during work hours. Checkpoints and milestones should be spaced so that work is done in a timely manner, productivity remains high, and you can still play network games every know and then. (I mean, that's what it's all about right?) J
[size="3"]Milestones
Milestones are the big checkpoints. These you can space out to one every month or two months. A milestone shouldn't be assigned to something petty, like completing a batch of routines. Gee whiz, what an accomplishment. You should be able to do three things at every milestone.
- Look over the recently completed segment for any flaws in the code or in the design.
- Insert it into the game structure, build and then run the game to test for any conflicts with previously installed modules and segments.
- Celebrate and prove to your investors that you are making progress. As the above three requirements indicate, a milestone should be set on the completion of a game module or a segment of the actual game. You should be able to build the game in its current state and "play" it in its limited form. The main idea behind milestones is that it is a time where you can prove to your investors that the game is actually going somewhere. No investor will be satisfied upon hearing that you just completed designing new routines for various modules. They need to visually see progress being made. That is why milestones are so important.
[size="3"]Checkpoints
Checkpoints are generally reserved for the development team only. There may be some publishers out there that like to keep a finger on everything, but most can be satisfied with milestones. Checkpoints are usually spaced closer together than milestones, and for good reason. Unlike a milestone, a checkpoint is merely a time where you can take a quick look back and ensure that everything is on track as planned before moving on. Checkpoints should be placed at key points in the development process. Once a checkpoint has been passed, undoing the results of that checkpoint will become harder and harder as development progresses. For that reason, checkpoints should be seriously examined for flaws and defects before development is allowed to continue. If a faulty checkpoint is found, resources should be allocated to work on the problem while normal development is resumed. This may mean temporarily moving a few programmers, artist, etc onto this task.
If used correctly, milestones and checkpoints can help you sidestep a lot of problems as the game is created. In a reference to Part 2, you should have your bug list and feature creep list in hand as you review the checkpoint or milestone to determine whether or not anything is creeping in to wreak havoc in the future.
[size="5"]You Have a Design Spec - Use It!
It's quite common that not too many people like to read long, boring documents that tell them exactly what they have to do. Most people just like to go out, do it, and be done with it. I for one know plenty of people who either hate to read or complain that they fall asleep while reading. This line of thinking will endanger both the project and your well-written design spec.
To avoid the spec will have to be broken down so that it is accessible by related sections and topics. The best way to do this is by putting spec on the company intranet with search and sorting options. You could also go a step further and categorize the various sections by department and restrict access to areas that do not need to be seen by all team members. Doing this allows everyone to be able to read what they need to know, and not clutter up their heads with irrelevant information.
If a team member is angered by the fact that he does not have access to all information, he should be reminded of his role in the project. The more unneeded information a person had, the harder it will be to stay focused on his own task at hand and therefore decrease productivity.
[size="5"]Real-Time Development Part I - Dealing with Emergence
This is just a small mini-series that will cover aspects of the development cycle where problems may arise and have to be solved right then and there. In Part I, we will discuss the power of emergence. If you can't remember what emergence is and how it contributes to a game, go back to Part 2 of the series and read the section Rules and Emergence.
So what's the big deal? Can emergence really trip you up? Yes. Emergence does have the potential to stop development in its tracks, but that event is quite rare. How does emergence do it? Well, when a new game feature pops up out of nowhere, it brings up a decision - keep it or lose it?
Sometimes you may have no choice. If you take out the new feature, you may disable other features. If you change a rule, you may also affect other features and create more new features. Pretty annoying huh?
Other times the feature may not be too important to the game, and you can drop it without affecting anything else. This is good. However, just dropping a feature isn't as simple as it sounds. If your project does not have a malleable structure, removing a feature can cost money. A lot of it. This is why some games may have a few weird "bugs" that just don't seem right.
In the end it comes down to the choice of both the Designer and the Project Manager. If the new feature fits in and can be used, it should be kept. If the new feature interferes with the gameplay, it should be dropped or somehow hidden, no matter what the cost. If the feature does not quite belong and can be easily removed, it should. The amount of emergence you have to deal with is directly related to how well the game is designed.
[size="5"]Real-Time Development Part II - Feature Creep Ain't Dead Yet
Time for another flashback to Part 2 - The Design. Feature creep is probably the most annoying part of creating a game. The urge to add feature after feature is just too much for most people. I know I was once that way. I would imagine a game with huge worlds, beautiful graphics, voice control, massively online, human-like AI, and everything in between. Of course, everybody thinks like this, and one day I'm sure we could do it. But not today.
As the game is developed there may come times where you will be hit with a sudden idea on how to improve it. You'll say, "Gee, this is so much better than what I had before!" Sounds great right? Not really. If you start thinking like this you will lose the big picture. You must remember that a game is a whole, and that everything affects each other. If you were to spontaneously change something without taking the time to research its effects, the entire project could go down in flames. This is where feature creep is most dangerous. It was annoying in the Idea stage, irritating in the Design stage, hiding in the Document stage, and malevolent in the Development stage.
It's up to the Project Manager to reign in the Game Designer when he gets too excited over a new idea. This is because the Project Manager is the one who has his hands on the money, while the Game Designer does not. A Game Designer may not think about the cost of researching a design change because the idea is just to good to be true. The Project Manager, however, should realize that pausing development to decide whether to change this feature will cost money, and should try to deter the Designer in any way possible if the team decides not to change anything.
The thing to remember about feature creep is that it's hard to detect in all its forms, chrome and eye-candy. The thing never to forget about feature creep is to shrug it off as something that won't be an issue for your project. This is just stupid. No matter what, feature creep will always find a way to cre- I mean, *opens up thesaurus* sneak into your project.
[size="5"]Real-Time Development Part III - Adding/Removing Features
This is sort of a culmination of all the add/remove topics discussed so far. Basically, we have decided that adding and removing features is expensive. This is true. The further along in development, the more expensive the cost to change things around. This should definitely be taken into consideration. Hard data shows that a change can cost up to 50 times more towards the end of a project than at the beginning. This may seem like common sense, but you'd be surprised how many people don't think about it.
Removing features is a tough process, in terms of both time and attachment. Features may have to be dropped for many reasons, including meeting deadlines, lack of money, and lack of effort (or loss of productivity). When removing features, you must decide what overall impact it will have on the game. If you are removing a key feature of the game, it must be replaced with something akin to what's being taken out. If this is not possible, then the project must be scrapped so that money is not wasted on a financial black hole.
Adding features can also be tough, since you must recognize the fact that adding a feature could cost money and turn out to be chrome or eye-candy. Features must be thoroughly analyzed to determine how they will aid the gameplay before they can be included in the project. If the feature does not help out the gameplay, it should not be included, simple as that. This decision should come from the entire team, so that no one person can rationalize the feature to be helpful, when it is not.
Of course, if time and money allow, adding features is always a good thing. Enhancing the graphics, using multiple UIs, sticking in a few more NPCs - these are all things that can be added as an after thought, but never during production.
[size="5"]Polishing the Finished Product
After everything is said and done, there still come the Proving Grounds. All the while through development your team of testers should have been trying to break every build handed to them. Some people may like to save money by calling in the testing team late in the development, but this doesn't justify the financial benefit. As soon as you have a build of the game playable, it goes to the testers. Programmers can test their own creations, sure, but that takes time away from coding new program segments and modules. A testing team is not just there to proof the game; it's there to take a load of the programmer's shoulders.
Before you decide that a game is ready to be sent out to the publisher, you must be assured that the game runs smoothly. This post-production should be quick and dirty. If a problem is found, it should be fixed as quickly as possible. Post-production time is usually cramped due to past project delays and shortcomings. Also known as "Crunch Time", post-production is very, very stressful.
The deal with crunch time is that you have x amount of days or weeks to either finish the project or polish it. Ideally, the project should be finished and you should be spending all your time trying to break it on every system configuration you can think of. The amount of time you have to carry out post-production work is based on how well the project was architectured, managed, and scheduled. So you see, we've come in a full circle. What you decide at the very beginning will, of course, affect the way everything ends.
[size="5"]The Misuse of Patches
As a last note, the most recent cry among gamers today is the fact that many games are shoved out the door sideways and land in pieces. Games are buggy, annoying, and not fun to play. Of course, developers don't seem to panic much. They can just release patches of the game to fix up troubles. Despite this obvious abuse of power, patches should never be viewed as a way to complete a game. Never.
Patches serve the purpose of letting the developers add new features and tweaking existing ones. This is not bug fixing, because these are not problems. The polishing of a product can continue well past development, as cases can arise that were not or could not be foreseen in the testing runs. But patches should not be considered bug-killers. The only place you should be killing bugs is in the office, during development.
Blizzard is the only company that openly says that they will not release a game until it meets their own expectations. You'd think that because of their success, other companies would follow their lead. However, it's usually not the developers behind bad games, but the publishers. And even then, it may not be the publisher's fault. If you are going to take on the credo of "It's not done until we say so", you had better state that in any contract you sign with a publisher, and they had better know it. It would be perfectly logical for a publisher to not allow you extended time if you did not inform them or your outlook on game development. Be sure they know at the start, so they can anticipate the chance that your project may run over schedule.
[size="5"]Conclusion
Did I forget anything? I can't think at all anymore, writing out this entire article in one day can do that to you ya know? Hopefully the information gleaned from this series will help you better design and produce your games so that people can enjoy them. The views represented throughout this entire series were mine alone, and therefore you do not have to follow them. This series was about what I believe needs to be done to create a great game that is enjoyable, long lasting, and easy to play. I enforce impossible situations such as a perfect schedule and architecture as goals to shoot for, not necessarily achieve. Good luck to you all.
Questions? Comments? That's what email's for...
[email="drew@gamedev.net"]drew@gamedev.net[/email]
Further reading:
Game Architecture and Design
Code Complete
