Author : Drew Sikora
Page : 1 Next >>
Part 4: The Development
by Drew Sikora
Recap
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.
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.
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.
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.
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.
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
Page : 1 Next >>