When it comes to developing a design, there is often a clash between what route to take, particularly whether to abide by the classic waterfall model or to undertake the more "trendy" iterative method.
With the waterfall model, it is assumed that software design progresses through strict stages, with each subsequent stage dependent upon its immediate predecessor. The sequential steps focus on: concepts, requirements, system design, detail design, coding, and finally testing. Whenever a problem or flaw is discovered with the overall design in a certain step, one would then go back as many steps as necessary, and make all changes necessary step by step again.
The waterfall model is the classic. However, as today's fast changing environment becomes the norm, the waterfall model is gradually becoming cumbersome and less applicable. In fact, it is now widely accepted that:
The only thing that won't change with today's application is change itself.
It is unrealistic in today's environment to require anyone to understand all there is to know about an application before development. Indeed, even the customers are usually just learning about their needs. In addition, marketing teams often make abrupt new demands for a product, and the hardware/infrastructure could also change faster than anticipated. How on earth can a development team expect a comprehensive and static specification then?
Iterative software design addresses this vital issue. There are right now several terms that carry similar connotations as that of "iterative design". Those include agile design, ultimate programming, ... Let us not delve on the jargon for the time being, and just focus on the aspect of designing/programming for change.
The common practice of iterative design proceed in the following steps:
With iterative design, development is decomposed into a series of small/manageable, fixed-length (one to four weeks) projects, called iterations or timeboxes. The crucial element is that the outcome of each timebox is a tested, integrated and executable system. Each timebox has its own requirement analysis, design, implementation and testing tasks.
Each timebox is not generating a complete system. However, it is vital to allow the clients (whoever defining the project whether it's your project manager or external customers) for early evaluation and feedback. Looking at this long enough, we should realize that most of the process is test-driven. Note that here the word "test" goes way beyond those that we run for debugging. It includes everything that would allow clients practical insights and an opportunity to modfy or adapt understanding of the REAL requirements or elegant design. Seeing a partical system/progress is way better than just speculating.
Fortunately, we have an entire semester to introduce and practice iterative design. By the end of the semester, we can come back to this subject and then try to summarize. Right now, let's just get the ball rolling by talking about the first task for you to do to develop a networked game.
The design document is important. In fact, it should be THE authoritative source for the entire team to go by. Unfortunately, often developers don't even reference it because part of it may already be obsolete 8 weeks into a project particularly when the waterfall model was assumed.
At this stage of the project, this draft of design document is mainly just about the overall story and based on that what timeboxes there should be. So, the first task for you is to develop such a guideline, to be due by January 24, Wednesday. Just plain English please. It should make sense. The following is a story that I conjured up for you to use as an example. Note, the following is not even talking about software yet!
Overview: The overall goal of this game is for each player to progress from a pupil towards a master in mermaid hunting skills. Over the process, the player must join a school of mermaid hunting, learn and practice skills, gain victories in the field, and pursue community-wide recognition.
Story of the Game: This game is a mixture of action, strategy, adventure and puzzle genres. The focus is on a community-wide experience. A typical example progression of a player is the following. A novice first joins a elementary hunting institute. Upon learning a technique, a laboratory environment is created for the student to practice the technique. Upon completion of this stage of study, a test is given so that the student can be admitted into the graduate program. Exceptional students will be provided with various kinds of financial assistants for purchasing tools, book of tricks, and paying for upgrades of various experiences. Tools and tips can be traded for money.
After becoming a graduate student, the player can then join the ICMH (International Congress of Mermaid Hunters) as a student member. Other ranks of ICMH members are: regular member, senior member, fellow and distinguished fellow. The study of graduate student primarily focus on developing specialty skills under the guidance of an advisor, usually higher ranked ICMH members. An advisor-student relationship can only be established upon mutual agreement. Every ICMH member gains reputation either by succeeding with great self-achievements (catching mermaids of precious kinds) or by producing highly successful students. A high-ranking ICMH member would typically do both.
Mermaid hunters are expected to work in teams. With each team, there are members of varying titles: assitant huntership, associate huntership and full huntership. Full huntership means that this member is considered the senior member and claims all success/catch by the team. Assitant and associate hunters advance by internal promotion, external career moves or piloting a new team. The full-grade hunter always provides all necessary resources. The resources can be either borrowed (bearing interest) or self-owned. Mermaid hunting trips bear risks, and the catch maybe worth a fortune or nothing.
Targeted Audience: General audience, whether casual or hardcore.
Expected Results (What Do You Want to See): At least two general scenes. A small town scene where students and ICMH members can interact. The characters are not necessarily full blown human-like. A player can appear as simple as a floating bubble. A under-water scene is also needed for hunting teams to practice skills or engage in actual hunting.
Evaluation: According to online game design literature on player type and three 30's, evaluate the prospect of the longetivity of the game and tabulate an initial feature list. (I don't have time to detail this part. You need to specifically discuss how would player progress in this game from one type to another, on the basis of the player development graph; and how your game will take players through the three 30's. With that discussion, list all technical needs/features, such as what takes place locally, between server-client, between client-client, and among a group of clients, etc.)
Initial List of Timeboxes
Each team should create your design document on the Wiki. The entire class will be given a chance to critique the document and the team will get to continuously improve the document. As we go through the semester, more and more details will be added to the document. Along each step you only add what you need, however.