Arcade Game Maker Pedagogical Product Line: Architecture Documentation, Volume 1 - Beyond Views
|Revision Control Table|
|Version Number||Date Revised||
|Description of Change||Person Responsible|
|1.0||7/03||A||Created new document||JDMcGregor|
|2.0||6/04||M||Modified in response to review comments||JDMcGregor|
The Arcade Game Maker (AGM) product line organization will produce a series of arcade games ranging from low to high obstacle count with a range of interaction effects and will be available on a variety of platforms. For more details about AGM products, see Arcade Game Maker Pedagogical Product Line: Scope.
The Arcade Game Maker (AGM) product line is described in a series of documents that are related as shown in the following figure. This interactive map shows the order in which the documents should be read for the first time. Once readers are familiar with the documents, they can go directly to the information needed.
This document describes the architecture used by AGM for its product line. It follows the format defined by Clements and colleagues [Clements 03] and supports the architectural model described in Arcade Game Maker Pedagogical Product Line: Architecture Documentation, Volume 2 - Software Architecture Views.
The product line consists of nine products: three games (Brickles, Pong, and Bowling) on three platforms (Win32, Linux on wireless devices, and a platform-independent version). The games are graphical and depend heavily on the graphical nature of the environment. How this is handled across different environments will be a key architecture decision.
For definitions of basic concepts, see Arcade Game Maker Pedagogical Product Line: Acronym List/Glossary.
AGM System Overview
A chronology for the company's development efforts can be found in Arcade Game Maker Pedagogical Product Line: Overview, which is accessed from AGM's online introductory page.
The AGM product line began when the vice president for products was looking for techniques that would significantly speed up production. He found software product lines to be a promising practice. He assigned a small team to do a new technology study and, if possible, build a business case for adopting the product line approach (see Arcade Game Maker Pedagogical Product Line: Business Case).
The product line comprises three games: Brickles, Pong, and Bowling. Each is a single-player game in which the player scores or loses points by controlling a moving object.
Pong and Bowling are new. Brickles has been available since 1994 in various formats for various platforms.
The games in the AGM product line all have a long history as computer programs. They are simple animations of a few items that interact with a larger number of stationary objects. The games run continuously until the player pauses or ends them.
Each game has a different set of rules. Some of the games have a simple won/lost scoring system, while others award points for certain actions.
Each game has a different set of moving and stationary items.
AGM Architecture View Packet Template
We adopted the view packet template presented by Clements and colleagues [Clements 03]. In this section, we briefly describe each part of it. The template is used in Arcade Game Maker Pedagogical Product Line: Architecture Documentation, Volume 2 - Software Architecture Views to organize each view packet.
View Packet Template Description
This presentation provides the basic model for this part of the architecture.
The element catalog includes a description of each element included in a view. The items that are "elements" in a particular view are the atomic items that characterize that view. For example, in the module view, the elements are modules.
Properties of the elements. The element's properties determine its impact on the quality attributes. For example, an element may have a large negative impact on the performance of the overall system.
Relations and their properties. The element's relations determine how they are associated with each other. For example, an element may aggregate or be a specialization of another element.
Element interfaces. The element's interface shows its publicly available services using method signatures.
Element behavior. UML diagrams show the element's dynamic behavior. For example, behavior is shown with UML sequence and activity diagrams.
This presentation places the elements contained in a view packet in the overall architecture.
This section describes the variations for each element included in a view.
This section describes architectural decisions.
Rationale. The rationale documents decisions that resulted in the
architecture shown in the view.
Analysis results. The analysis results provide the data that back up the decisions.
Assumptions. The assumptions include data that underlie the decisions.
This section includes miscellaneous information that didn't fit into another section.
Related View Packets
This section describes the following types of related view packets:
- ones that surround the current view packet at the same level of detail
- ones that include the current view packet at a higher level
- ones that describe additional elements with the current view packet
Mapping Between Views
In general, we use UML to document the architecture. In UML, there are static diagrams that describe definitional units, such as classes, and dynamic diagrams that describe operational units, such as objects. Any operational unit that is used must correspond to a definitional unit. Therefore, there is a general mapping from dynamic diagrams to static diagrams.
Because the underlying development paradigm is object oriented, the architecture has both horizontal and vertical dimensions.
The vertical dimension corresponds to the specialization relation. There are several inheritance hierarchies, and the specialization relation is a major organizing principle for defining components within the product line.
The horizontal dimension corresponds to the association relation and forms the main operational structure of each product. Messages follow the association relation links and, in some cases, exceptions flow back over those links.
Rationale, Background, and Design Constraints
In this section, we document several architecture decisions that resulted in the current architecture.
Display and Data Separation
In an earlier version of the Brickles game, we used the model-view-controller (MVC) architecture. This approach allows for separation of the state of the system from the logic that presents some of that state to the player. The alternative we have considered is a more monolithic architecture that does not separate the data from their presentation.
Controllers provide input to the system. The input is routed to the view or the model as appropriate. In Brickles, the keyboard and mouse serve as controllers.
The views present information to the player in a variety of forms. In Brickles, the graphical interface has several fixed items and two movable ones, the puck and the paddle. The mouse controller allows the player to move the paddle, while the system determines the movement of the puck. The view has the responsibility to ask the model for the data it needs to build its presentation. Each view maintains a copy of the game state that is needed for its particular requirements and contains the graphical data to place the game data on the screen.
The model is the computation engine for the game. The model fuels the game by generating animation, recomputing the new location of the puck, receiving mouse events, and computing where to place the paddle. The model is obligated to inform all views when its state has changed.
The MVC pattern focuses on adding an arbitrary number of views to a given model. Tabular and graphical views of a data table might be useful, for example. The tradeoff is that a view updates itself by querying the model for the information it needs after the model has notified the view of a state change. The update operation is shown in a sequence diagram in the following figure.
Model-View-Controller (MVC) Update Operation
An alternative architecture, part of which is shown in the next figure, was proposed as we started to develop the product line. In this alternative, the states of the game and the view are blended in various components. Knowledge of the graphics elements, which are usually platform independent, is distributed across the system's entities. Each object knows how to participate in the game, draw itself on the screen, and maintain its own data about the game and graphics. To update the display, each object is asked to paint itself to the screen. The container for all the game elements maintains overall control and sequences the screen updates.
The update of the screen operation is shown in the following figure. This architecture is compared to the MVC architecture in the next table.
Monolithic Update Operation
The advantages and disadvantages of each design are shown in the following table.
|Comparison of MVC and Monolithic Approaches|
|MVC||Multiple views can be added.
Knowledge of the platform's graphical capabilities is isolated and straightforward to change.
|Much messaging is needed at every update.
State is replicated among all views and the model.
|Monolithic||Additional views are difficult to add.
State is in one place only.
|No messaging is needed to update view.
Knowledge of platform's graphical capabilities is distributed and thus harder to change for a new platform.
After reviewing the table, the team chose to use the monolithic version of the architecture. In particular, they rated performance as a high priority and adding views to an existing game as a very low priority.
Separating Moving and Non-Moving Items
A major distinction among game items is whether they move. By discriminating between moving and non-moving, the number of items that must be checked and updated every time is greatly reduced.
The generalization hierarchy shown in the next figure shows one design for the various items that will participate in a game. Sprite is the most general game item. A Sprite has a location, a bounding box based on that location, and a bitmap that is the visible representation of the element. Two additional items are specialized from Sprite: MovableSprite and StationarySprite. The MovableSprite item adds fields and methods that record whether the item is currently moving or not. The new item also adds the ability to receive clock ticks that drive the animation. The following figure shows additional items that are specialized from MovableSprite. Each new item defines its own move method so that each item can behave according to its role.
Top-Level Generalization Hierarchy
The following figure illustrates a single item solution in which a single class has all the fields and methods that represent all the items' attributes. When an instance is constructed, parameters are provided to the constructor to make the item behave as needed. When a new "type" of item is needed, this one class is modified to provide the new behavior. One of the parameters provided to the ParameterizedSprite is an instance of a movement algorithm. For moving items, the ParameterizedSprite delegates the movement to this object.
The advantages and disadvantages of each design are shown in the following table.
|Comparison of Generalization/Specialization and Parameters Approaches|
|Each item contains just what it needs for
The types are related polymorphically, which allows flexible architectures.
|New item types must be defined at compile
Changes to more general items cause more specific items to change.
|Parameters||New types of items can be made dynamically if the parameter objects are already defined.||Each item is the size of all the items
Different items cannot be distinguished automatically.
The team decided to use a combination of these approaches. The GameBoard container is instantiated by passing a number of parameters, and individual game items are defined by specializing existing abstract definitions.
Because games must be enjoyable for the players, their graphical design is constrained by usability studies and guidelines. Since three of the products are to be sited on wireless devices, we will use guidelines from that domain. Two that we are following closely are found at the following Web sites:
Process for Modifying the Architecture
There are several reasons for architecture changes. The following figure describes a process that can be used for any architecture change, but we describe it using a requirements change.
Attached Process for Requirements Change
When a requirement is added or modified, the impact of that change to the requirements model is determined. The architecture is reviewed to determine whether the current architecture can satisfy the new requirement. If not, existing items are examined to determine whether they can satisfy the behaviors. If not, new items are designed with responsibility for the new behavior. Any new items are placed in the same operational context as the other items (i.e., within the context provided by the GameBoard).
Process for Using the Architecture to Produce a Product
This process becomes a portion of the production plan for a product.
References and Further Reading
For details about the references cited in this document, see Arcade Game Maker Pedagogical Product Line: Bibliography.