代写游戏Zombiquarium，对软件设计方法论进行实践。
Introduction
This is the Software Design Description (SDD) for the Zombiquarium mini-game application. Note that this document format is based on the IEEE Standard 1016-2009 recommendation for software design.
Purpose
This document is to serve as the blueprint for the construction of the Zombiquarium application. This design will use UML class diagrams to provide complete detail regarding all packages, classes, instance variables, class variables, and method signatures needed to build the application. In addition, UML Sequence diagrams will be used to specify object interactions post-initialization of the application, meaning in response to user interactions or timed events.
Scope
Zombiquarium will be one mini-game among many to be included in the Plants vs. Zombies application. Tools for its construction should be developed with this in mind such that additional mini-games may avoid duplication of work. As such, a framework called the MiniGame Framework, will be designed and constructed along with the Zombiquarium game such that it may be used to build additional mini-games. So, this design contains design descriptions for the development of both the framework and game. Note that Java is the target language for this software design.
Definitions, acronyms, and abbreviations
Class Diagram - A UML document format that describes classes graphically. Specifically, it describes their instance variables, method headers, and relationships to other classes.
IEEE - Institute of Electrical and Electronics Engineers, the “world’s largest professional association for the advancement of technology”.
Framework - In an object-oriented language, a collection of classes and interfaces that collectively provide a service for building applications or additional frameworks all with a common need.
Java - A high-level programming language that uses a virtual machine layer between the Java application and the hardware to provide program portability.
Mini-Game - A standalone game that is a subset of a larger game application, typically sharing the primary game theme with that parent game application.
Mini Game Framework - The software framework to be developed in tandem with the Zombiquarium game such that additional mini-games can easily be constructed. Note that in the Zombiquarium SRS this was sometimes called the “Mini Zombie Game Framework”, but has been renamed the “Mini Game Framework”, since it’s not Zombie-specific.
Plants vs. Zombies - The PopCap Games game that is the parent application of our Zombiquarium mini-game. Note that Zombiquarium is to be distributed as part of that program.
Sequence Diagram - A UML document format that specifies how object methods interact with one another.
Sprite - a renderable, and sometimes movable or clickable image in the game. Each Sun, Zombie, and Brain will be its own Sprite, as will GUI controls.
SpriteType - a type of Sprite, meaning all the artwork and states corresponding to a category of sprite. We do this because all the suns share artwork, so we will load all their artwork into a common Sprite Type, but each Sprite has its own position and velocity, so each will be its own Sprite that knows what Sprite Type it belongs to.
UML - Unified Modeling Language, a standard set of document formats for designing software graphically.
Zombie - An undead creature, meaning something that has died and then come back to life. These beings are typically slow moving and love to eat brains.
Zombiquarium - The title of the mini-game described by this document. Again, note that this game will be distributed as part of the Plants vs. Zombies application.
References
IEEE Std 830-1998 (R2009) - IEEE Standard for Information Technology - Systems Design - Software Design Descriptions
ZombiquariumTM SRS - Debugging Enterprises’ Software Requirements Specification for the Zombiquarium mini-game application.
Overview
This Software Design Description document provides a working design for the Zombiquarium software application as described in the Zombiquarium Software Requirements Specification. Note that all parties in the implementation stage must agree upon all connections between components before proceeding with the implementation stage. Section 2 of this document will provide the Package-Level Viewpoint, specifying the packages and frameworks to be designed. Section 3 will provide the Class-Level Viewpoint, using UML Class Diagrams to specify how the classes should be constructed. Section 4 will provide the Method-Level System Viewpoint, describing how methods will interact with one another. Section 5 provides deployment information like file structures and formats to use. Section 6 provides a Table of Contents, an Index, and References. Note that all UML Diagrams in this document were created using the VioletUML editor.
Package-Level Design Viewpoint
As mentioned, this design will encompass both the Zombiquarium game application and the Mini-Game Framework to be used in its construction. In building both we will heavily rely on the Java API to provide services. Following are descriptions of the components to be built, as well as how the Java API will be used to build them.
Zombiquarium and Mini Game overview
The Zombiquarium and MiniGame framework will be designed and developed in tandem. Figure 2.1 specifies all the components to be developed and places all classes in home packages.
Java API Usage
Both the framework and the mini-game application will be developed using the Java programming languages. As such, this design will make use of the classes specified in Figure 2.2.
Class-Level Design Viewpoint
As mentioned, this design will encompass both the Zombiquarium game application and the Mini-Game Framework. The following UML Class Diagrams reflect this. Note that due to the complexity of the project, we present the class designs using a series of diagrams going from overview diagrams down to detailed ones.
Method-Level Design Viewpoint
Now that the general architecture of the classes has been determined, it is time to specify how data will flow through the system. The following UML Sequence Diagrams describe the methods called within the code to be developed in order to provide the appropriate event responses.
File Structure and Formats
Note that the Mini Game Framework will be provided inside MiniGameFramework.jar, a Java ARchive file that will encapsulate the entire framework. This should be imported into the necessary project for the Zombiquarium application and will be included in the deployment of a single, executable JAR file titled Zombiquarium.jar. Note that all necessary data and art files must accompany this program. Figure 5.1 specifies the necessary file structure the launched application should use. Note that all necessary images should of course go in the image directory.
The ZombiquariumGameData.txt provides the file and state names for all sprite states in the game. The file is a raw text file that can be used to describe M Sprite Types, each with their own N states as follows:
NumSpriteTypes
SpriteType_1|NumStatesFor_1
SpriteType_1STATE_1|SpriteType_1STATE_1_FileNameAndPath
SpriteType_1STATE_N1|SpriteType_1STATE_N1_FileNameAndPath
SpriteType_M|NumStatesFor_M
SpriteType_MSTATE_1|SpriteType_MSTATE_1_FileNameAndPath
SpriteType_MSTATE_N2|SpriteType_MSTATE_N2_FileNameAndPath
We can describe these values as follows:
NumSpriteTypes - an integer that lists the total number of Sprite Types to be loaded. Note that this value must correspond to the number of Sprite Types that will be described by the file using the proper format.
SpriteType_X - the textual name of a type of sprite, which should correspond to a Zombiquarium named constant.
NumStatesFor_X - an integer that lists the total number of states for Sprite Type #X. Note that this value must correspond to the number of states for that Sprite Type that will be described by the file using the proper format.
SpriteTye_X_Y - the textual name of a state for sprite X. Note that this value must correspond to a Zombiquarium named constant.
SpriteType_XSTATE_Y_FileNameAndPath - the textual relative path (from the game’s home directory) and file name for the image to be used to represent sprite type X when it is in state Y.
Supporting Information
Note that this document should serve as a reference for those implementing the code, so we’ll provide a table of contents to help quickly find important sections.