Author : Drew Sikora
Page : << Previous 2 Next >>
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.
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.
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.
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.
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
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.
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.
You Have a Design Spec - Use It!
It’s quite common that not too
Page : << Previous 2 Next >>