Arcade Game Maker Pedagogical Product Line: Scope
|Revision Control Table|
|Version Number||Date Revised||
|Description of Change||Person Responsible|
|2.0||12/03||A, M||Put in SEI format, made miscellaneous changes||LMNorthrop|
The Arcade Game Maker (AGM) product line will produce a series of arcade games. Each game is a one-player game in which the player controls, to some degree, the moving objects. The objective is to score points by hitting stationary obstacles. The games range from low obstacle count to high and will be available on a variety of platforms.
The AGM product line is described in a series of documents that are related to each other 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 is the scope document. Its purpose is to define the boundaries of the product line. Design and implementation decisions are made to address the full scope of the product line but with no concern for any characteristics outside the product line.
This document establishes the high-level context for work in the product line. In a product line, components are designed to be reusable within the context of the product line. That is, no attempt is made to make a component "as general as possible." Each design decision is made with regard to the extent of the products in the product line. The architecture further refines the context defined in this document.
This document is intended to provide some level of information to all the stakeholders in the AGM software product line. Managers will find information that supports product planning, architects will find information that supports commonality and variability analysis, and product developers will find the rationale for each product's membership in the product line.
Use in Product Production
This document is used in the earliest stages of product production. It is used when the product production process seeks to determine whether it is feasible to build the proposed product as part of the product line. The lists of common features and variations are used to determine the fit between the proposed product and the product line. Later, assets such as the architecture can be used to provide more detailed information about product fit with the product line.
Product Line Context
The context of the AGM product line is illustrated in the following figure. The four games shown inside the circle constitute the current definition of the product line. Those shown outside the circle are out of scope and will not be constructed from the assets built for the product line.
Each product in the product line
- is a game with specified game elements
- is for a single player
- offers a graphical view of a game or games
- has animation-driven games
- uses moving and stationary objects
- follows certain rules about the interaction of game pieces
The games may have multiple players, but only one is active for a particular match. For example, having a computerized player is useful for testing purposes.
Product Line Variation
The principle variations in the AGM product line are the
- rules of the game
- types and numbers of pieces involved
- behavior of those pieces
- physical environment in which the game operates
These variations are elaborated on in the Arcade Game Maker Pedagogical Product Line - Architecture Documentation, Volume 1: Beyond Views and Volume 2: Software Architecture Views.
The AGM product line does not include traditional "board" games. A framework1 for this type of game was provided by McGregor and Sykes [McGregor 92] but is out of scope for this product line. These games contain an element of strategy not included in the current product line. Board games usually allow multiple players. Strategy games are also out of scope. Dungeons and Dragons and other more recent games will not fit in the AGM product line.
Each product will provide the user (called a player) with the ability to interact with the game and to control some portion of the action. The product will operate according to the usual rules of each game and provide a graphical representation of the state of the game.
Each product will control hardware through an existing operating environment so variations in hardware will be handled by the operating system
The above sections have provided a first level of data capture for scoping the product line. The previous figure provides a functional context. The attribute/product matrix shown in the following table gives a market view of the scope. In this table, the products are divided into three high-level categories, which correspond to three different markets. As the product line expands into commercial products, we should do a more in-depth analysis using a technique such as PuLSE-ECO [DeBaud 99].
|Example Attribute/Increment Matrix|
|Feature||Freeware Arcade Games||Commercial PC Games||Commercial Wireless Games|
|display||standard bitmaps||vector graphics||wireless access protocol WAP bitmap|
|game pieces||simple icons||dynamic icons||dynamic icons|
|scoring||high scores stored locally||local storage/scores shared with subscription||scores stored on network/subscription required|
In this section, we present a high-level feature model of the arcade game domain. This model captures the product features that are necessary to compete in the market and satisfy our existing customers. It includes all features in all products.
Top-Level Feature Model
Determining Product Fit2
For a new product to be created using the assets of the product line, the product must be judged to be within the scope of the product line. The process for determining whether a product is in scope will depend on how formally the scope is defined.
For the AGM product line, the scope is partially defined by the attribute/product matrix shown in the previous table. As the process diagrammed in the following figure shows, the new product is compared to each column in the matrix. If the new product fits the first column, the new product may belong in the product line. Next, the proposed product would next be evaluated against the architecture description for a more technical match. If the proposed product fits one of the other columns or does not match any of the columns, additional market analysis should be performed to determine whether the product line scope should be expanded to include the proposed product.
Process Flow for Adding a Product to a Product Line
For information about the references in this document, see another document in the Arcade Game Maker Product Line series: Arcade Game Maker Pedagogical Product Line: Bibliography.
2 This section is the "attached process" described by Clements and Northrop [Clements 02]. For the product line scope, this process focuses mainly on determining whether a particular product could be produced profitably using the assets of the product line.