     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
| |
Structuring Key Design Elements Methods and the Unified Development ProcessMicrosoft, the most successful software development organization on the planet, sells a lot of games. Microsoft is perhaps best known for its Flight Simulator franchise, but MS now owns Ensemble (Age of Empires franchise), Bungie (Halo and Myth, formerly the premier Macintosh development house), FASA Interactive, and Digital Anvil (the former Chris Roberts company working on Freelancer), as well as being the publisher for a host of externally developed titles such as Dungeon Siege. Microsoft is a large organization with many layers of development procedures that other publishers do not employ. The first thing Microsoft does when evaluating a developer is to send a small team of game development leads comprised of production, design, programming, and art to evaluate the strength of the team. A large part of this evaluation is to also evaluate the developer's methods to determine if they are compatible with Microsoft's and if these methods give Microsoft confidence that the developer has thought through their project and will deliver a great game, on budget and on time. Development methods must be good things judging by Microsoft's success. What Is a Development Method? meth·od noun-A means or manner of procedure, especially a regular and systematic way of accomplishing something. We do want systematic game development; this whole book is dedicated to the presentation of various game development methods. Systematic and repeatable methods allow us to retain what worked and improve upon what did not work well. The alternative to using a method is employing ad hoc techniques over and over again and being successful only by good fortune. I rather like to make my own luck, thank you very much. The first method we need to nail down is how to reconcile your game idea and business parameters. I advocate using a comfortable subset of the Unified Software Development Process developed by the three amigos Ivar Jacobson, Grady Booch, and James Rumbaugh. Why Use the Unified Software Development Process? The simple reason is that the Unified Process is quickly becoming the software industry standard. The Unified Process has a long legacy dating back to at least 1967; at this time Ivar Jacobson worked for the telecom giant Ericsson. Jacobson had a radical idea for the design of the next generation telephone switching equipment at the time, a method we would now call component-based development. For this project Ericsson modeled the whole switch system and subsystems as interconnected blocks. The relationships between these blocks was then articulated and revised. The dynamic processes of the switch were identified and modeled. Every message passing back and forth from each object was included in this model. This software architecture and object message compilation was probably the best technical design document of the time. This was a radical concept because software customers at the time were not accustomed to seeing a blueprint of the software before the software engineering began. This method was not chosen on a whim; rather it met the demand that the software be robust enough for the telephone switching equipment to remain operating while receiving upgrades and patches to the software components of the switch in real-time. I will skip the middle part of the history behind the Unified Process; the point is that 35 years ago a repeatable method of creating great software was developed, and despite this, most software organizations have weak methodology. The Unified Modeling Language is the standardized text and visual language for the articulation of software design supporting the Unified Process. Beyond the development of Ivar Jacobson, Grady Booch, and James Rumbaugh, UML enjoyed broad support and major companies such as IBM, HP, and Microsoft joined in the development and standardization of UML. Requirements Capture The purpose of a software development process is to take the user's requirements and transform them into a functional software system. That transform stage is what we game developers are doing when we make games. We take the vision of the gameplay-how it should play-and turn that into a finished game. JARGON: Requirements capture- articulating the requirements the functional software must satisfy, such as to be fun or to run at 30 frames per second. What is the first step in the development process? Figuring out what we are supposed to do. There is a neat formalized term for this: requirements capture. Requirements capture is something you have already started. Your business constraints are some of the requirements the software must satisfy. How do we methodically discover the rest of our game's requirements? The short answer is that there is no quick, magical method to sit down and write up in a single sitting all of the requirements your game must fulfill. Wait, don't go away, I am still going to show you how to do it; it just involves several iterative steps.
Use Cases First, if you have not already done this, write down your game idea on a single sheet of paper. Write two or three sentences that describe your game in the center of the piece of paper. Now in no particular order write down the major functionality of the game in an outward, radial manner from the game idea in the center. The larger, chunkier aspects of the game should be close to the center and the detailed ideas farther away. For example if you are designing a role-playing game, you have characters; write that down. Characters have stats; write that down. Characters have names; creating the characters' names is a feature. What you are doing is brainstorming the gross feature set of your game. This particular method of putting the game idea down at the center of the page is good to get you started if you have not put a lot of effort into your game design document yet. The immediate goal is to identify all of the core activities the player can perform in your game. Each of these core activities is composed of many individual actions the player performs. Each of these actions is called a use case in the Unified Modeling Language.
JARGON: Use case-an interaction between an actor and the software system. A fully articulated use case is composed of both text describing a sequence of actions and a graphical diagram showing the relationship of this particular use case with others in the system. Collecting these use cases and writing them down will drive our process to identify the requirements of our software. The software requirements will then help us develop the architecture for our software. The use cases represent function, and the architecture represents form. The Unified Process is called use case driven because it is the effort to capture our use cases that drives the development. All of our future efforts in the construction of our software are to further the realization of these use cases into a functioning software system. Now, what exactly does a use case look like?
It turns out one of the fundamental tenants of UML is that the language shall be extensible, flexible, and ultimately serve only to aid the process of distilling and communicating the system requirements. This ATM transaction diagram uses only three UML symbols: the oval use case, the stick figure actor, and the relationship line. The stick figure is called an actor. Actors represented by a stick figure are most often users of your software, or players of your game, who are interacting with the game. It is better to use the abstract term "actor" so you will see all of the external users of your game system such as the single-player player, the multiplayer player, the system administrator, and the database server of your online component. After identifying your actors, the use cases will flow rapidly. The use cases are the unique interactions between the actors and the software system (game). The use cases are represented by a simple oval with an active verb phrase such as "withdraw cash" or "analyze risk." JARGON: An actor is a user, either human or another external system, that is interacting with the system under analysis. JARGON: A relationship is a line drawn between actors and use cases, sometimes with extra notation that further describes the type of relationship, such as <<extends>> and <<uses>>. The level of articulated rigor in a diagram should be reasonably proportional to your needs. For example, if it is important to describe the relationship line in better detail, use a one-word descriptor between the less than and greater than symbols. Common examples are the relationship descriptor of <<extends>>, <<uses>>, where extends would communicate that a particular use case is really a special case of a simpler base use case, and uses would indicate that a particular use case employs another use case as part of its action.
We can also take a higher-level view of Pac-Man and combine these low-level use case diagrams into a generalized use case view of the software package as a whole. See the diagram to the right. see only four roles: a programmer for the 2D display system, a programmer for the game mechanics, an artist, and some audio. This of course is a very small game, and a solid Pac-Man clone could happen inside a weekend for a two- to four-person team. This process of understanding how something else was put together has a fancy name-reverse engineering. I highly encourage you to perform some reverse engineering on other games that you are familiar with. We continue with some sketches from other games.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|