Arcade Game Maker Pedagogical Product Line: Brickles Production Plan

Revision Control Table
Version Number	Date Revised	Revision Type A-Add, D-Delete, M-Modify	Description of Change	Person Responsible
1.0	7/03	A	Created document	JDMcGregor
2.0	12/03	A, M	Put in SEI format, made miscellaneous changes	LMNorthrop
2.1	4/04	M	Modified the AGM production strategy description	JDMcGregor
2.2	6/04	M	Modified in response to comments	JDMcGregor
3.0	4/05	M	Edited document	KERiley

Overview

Identification

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. For more details about the scope, see Arcade Game Maker Pedagogical Product Line: Scope.

Document Map

The AGM product line is described in a series of documents that are related as shown in the following figure. This map shows the order in which the documents should be read for the first time. After readers are familiar with the documents, they can go directly to the information needed.

Document Map

Using This Document

This document describes how the Brickles product will be produced in the AGM product line. Product line organizations use production plans to capture how the product teams will build a new product, and a product-specific plan is developed before each product is constructed. This plan follows the outline provided by Chastek and McGregor [Chastek 02a].

Concepts

For definitions of basic concepts, see Arcade Game Maker Pedagogical Product Line: Acronym/List Glossary.

Readership

This document provides a template for product-specific production plans and is intended primarily for product development teams. Managers can use the product-specific plan to determine the resources required to produce a product, and technical members can use it to actually produce a product.

Timeline

This document is a product of the Brickles product team. All base classes illustrated in the following figure have been implemented and are available to the product-specific development teams.

None of the Brickles-specific tasks have been performed.

We were planning to produce the Brickles product from these assets, and producing this document is part of the project planning.

Base Classes

Strategic View of Product Development

Assumptions

Two broad assumptions apply:

The company has an existing pool of software developers who are highly technical. They have fielded products on a variety of hardware platforms and are accustomed to being involved down to the driver level of the software.
The product line contains games that are similar in content but that differ in platform. Differences in platform translate into differences in graphics implementation, which is a major feature of these products.

Qualities

We will briefly describe two types of properties: (1) product and (2) production process.

Product Qualities

Players will enjoy the games if they have a colorful display and realistic action.

A new game element should add to the display quality and accurately portray the item it represents. Brickles will add three colorful graphics as game elements.
Game action must be fast enough to demand the player's attention. If the number of elements slows the game, alternatives must be investigated. After all game elements are added, the Brickles system test will verify the game speed.
Game action must meet the player's expectation. The motion and reactions of movable elements must be realistic. As elements are added to the game, their actions and boundaries must be correctly set through parameters so that collisions look real. The Brickles system test will verify that interactions of game elements look realistic.

Production Process Qualities

The production process in the AGM product line is largely manual. Developers are very technical, and the process allows for hands-on manipulation of the product. Providing a tool that automates the production process to a high degree would have frustrated developers and wasted development resources.

Products Possible From Available Assets

The products that are possible from the available assets are simple, animated games that involve moving and stationary objects. Each game has an area in which all play occurs and implements a set of physical rules that control movement. Using the incremental approach, the asset base is only developed to the extent needed to construct the current set of products. As additional increments are completed, the variety of possible games may increase.

Production Strategy

The production strategy includes a domain-based design approach and a manual construction approach. The requirements analysis and architecture development will be based on domain information. For each new product, software developers will manually specialize assets, gather other domain-based core assets, and then build an executable by running a compiler and linker.

Core assets are being built incrementally. Therefore, earlier product teams will have fewer available assets than later product teams. Earlier product teams (particularly the freeware development team) will identify core asset candidates for use in the later increments.

The formal statement of the strategy¹ is as follows:

We will position ourselves as the leading provider of rapidly customized, high-performance, low cost games by producing products that are easily modified, have better performance than our competitors, are sufficiently low cost to deter potential competitors from entering the market, and require sufficiently few resources to allow their use on any embedded computer. We will produce the initial products using a traditional iterative, incremental development process that uses a standard programming language, integrated development environment (IDE), and available libraries. We will create domain-based assets, including a product line architecture and software components, for the initial products in a manner that will support a migration to automatic generation of the second and third increment products.

Overview of Available Core Assets

Source Code Naming Conventions

The following naming conventions are used:

Game-specific classes begin with the name of the game and are created in a package devoted to that game.
Interface definitions end in "Interface."
Class names begin with capital letters.
Variable names begin with lowercase letters.
DotUnit test case suite methods begin with "test."

Analysis-Level Assets

The requirements document includes the following assets:

The domain analysis model organizes the concepts in the main domain (games) and provides the attributes and relationships of each concept. Developers who are new to the domain should study this asset to understand the product's background.
The feature model shows the features of products.
The use case model provides a superset of product requirements.
Select the appropriate use cases for your product.

High-Level Design Assets

The main high-level design asset is the software architecture, which is described in Arcade Game Maker Pedagogical Product Line - Architecture Documentation, Volume 1: Beyond Views and Volume 2: Software Architecture Views. The following figure shows the architecture's base classes. Product-specific versions of these classes should be defined at a high level in each product-specific production plan.

Base Classes

Source Code

Each interface in the existing architecture has been implemented. The C# components are named according to the guidelines in the Source Code Naming Conventions section.

Test Cases

This section describes existing test cases. Use an existing test case if it covers functionality or features included in the new product. Test cases are not yet available for all code assets.

Unit Tests

Individual unit tests are constructed using the DotNet testing framework and are available from the Unit Test icon on the Document Map. The source code is in the form of classes.

The following unit test classes are currently available:

Velocity/Speed/Direction cluster (part of our pilot effort)

Integration Tests

If integrating units result in a component, test it at the API level. (If it results in a GUI, see the following System Tests section.)

The following integration tests are currently available:

none

System Tests

System tests are currently done manually. Each system test is a scenario derived from a specific use case. When a use case is applied to more than one product, the related test cases can also be applied to that new product. These test cases are documented in the test plan for a product.

The following test plans are currently available:

Brickles (created as part of the Brickles planning process in parallel with this document)

Inputs and Dependencies

Inputs

Game inputs are as follows:

mouse and keyboard events
names of the files that save the score and the state of the game (when the change cases for saving are implemented)

Dependencies

Game dependencies are as follows:

graphics library of the programming language
operating system (when the change case for saving a game is implemented)

Variations

Absorbing vs. Reflecting

The stationary game elements participate in the game by providing collision behavior. Core assets include two major behaviors:

A stationary element may reflect the movable element according to the laws of physics.
A stationary element may absorb the movable element so that it is deleted from the game.

A parameter on each element determines which of these behaviors is performed.

Event Handling

The event-handling routines vary from one game to another. An implementation of the EventHandlerDefinitions interface is provided as a parameter to the GameBoard component. Each of the mouse and keyboard events is handled as defined in the implementation of the parameter.

Detailed Production Process

Product teams will use the following four-step production process that was developed as Brickles and Pong freeware games were built:

identify the product, define it, and analyze it incrementally
design the product
build the product
test the product

Identify, Define, and Analyze the Product Incrementally

This step includes the following tasks:

Identify products. (Products are already identified. Because each product is a single game, this was accomplished when you identified games during the product line planning.)
Define the rules of the game. There are several versions of most of these games so the product team must first decide on a set of rules to implement.
Analyze features for the new game that are variations from previous games, and identify existing features that must change for this game.

Design the Product

This step includes the following three tasks:

Plan how to provide those features from existing components.
Plan how to provide the remaining features from new assets.
Design the new implementation of the EventHandlerDefinitions interface.

Build the Product

This step includes the following 10 tasks:

Start a new ClassLibrary in a Visual Studio Project using Game_name Definitions as its name.
Use this class for all new classes except the game definition.
Start a new Windows Application in a Visual Studio Project using Game_name.
Copy form1.cs from a previous product line project.
Change the namespace name to Game_name.
Configure the new GameBoard.
Copy data.txt from a previous game's working directory. This is the resource file for the game.
Edit data.txt to reflect the new game.
Write the game-specific classes needed for the game.
Compile the resource file.
Copy the compiled resource file to the Debug directory.

Test the Product

This step includes the following six tasks:

Test each core asset, by inspection or execution, as it is created or revised.
If the asset is revised, revise the previous testing materials and reapply them to the new version of the asset.
For a code asset, code the unit test asset as a JUnit test class.
Revise the initial generic game system test set for each new game.
Create a game-specific system test set for each new game as shown in the following figure.
Maintain system test cases as text documents and apply them manually.

System Test Cases Related to Products

Tailoring the Production Plan to a Product-Specific Production Plan

Overall, the production plan template is very generic and applies to all products built using the current asset base. However, some parts of the plan must be modified for a specific product.

The next section, Management Information, includes the two most important and obvious sections that must be modified: the schedule and the bill of materials (BOM). Since we are using a manual product production approach, the schedule defines which personnel are needed when. The BOM provides a method for tracking the use of core assets.

Management Information

Schedule

The following table provides a schedule template that includes all the steps from the process described in the Detailed Production Process section. For the product-specific production plan, update the entries in the Performed By and Estimate/Date Performed columns.

Schedule Template
Process Step	Product-Specific Task	Performed By	Estimate/Date Performed
Product Identification	Done during product planning	Product planning	Done
Product Definition	Define the rules of the new game.	Analyst (Gary)	≅ 0.5 days (8/5/03)
Product Analysis	Analyze the rules of the new game.	Analyst (Gary)	≅ 0.5 days (8/5/03)
Product Design	Identify new elements needed by the game.	Designer (Jason)	≅ 2 hours (8/6/03)
	Identify changes to existing elements.	Designer (Jason)	≅ 0.5 days (8/6/03)
	Design product-specific implementation of the game interface.	Designer (Jason)	≅ 2 hours (8/7/03)
	Design product-specific implementation of EventHandlerDefinitions.	Designer (Jason)	≅ 2 hours (8/7/03)
Product Build	Create new implementations and make changes to existing classes.	Developer (Bob)	≅ 0.5 days (8/10/03)
	Create new .Net projects for libraries and the application.	Developer (Bob)	≅ 0.5 days (8/10/03)
	Create the new make file.	Automated/developer	≅ 0.5 days (8/10/03)
Product Test	Create unit tests for new elements.	Developer (Bob)	≅ 0.5 days (8/10/03)
	Modify existing unit tests for existing elements.	Developer (Bob)	≅ 0.5 days (8/11/03)
	Execute unit tests.	Developer (Bob)	≅ 0.5 days (8/11/03)
	Modify/extend the product test suite.	Tester (John)
	Execute the product tests.	Tester (John)	≅ 0.5 days (8/12/03)

Production Resources

The primary resources are the Visual Studio .Net environment and the organization's UML modeling tool.

During the analysis and design steps, extend the UML model to include any new elements that must be defined.

Use the .Net environment to create any new required components. After all components are created, use the environment to build an executable.

Bill of Materials (BOM)

The BOM allows you to track the use of core assets. The following table includes a high-level list of available code assets. For the product-specific plan, update the table with only those specific assets that will be used.

Bill of Materials (BOM) Template
Component	Source	Cost
Product-specific Game component	In-house	$1,000
The generic GameBoard	In-house	$ 500
Required Sprites: Puck, Paddle, Brick, BrickPile, Wall, Ceiling, Floor	In-house	$ 700
Implementation of EventHandlerDefinitions interface: BricklesEventHandlerDefinitions	In-house	$ 600

The senior personnel are billed at $75/hour, and junior personnel are billed at $50/hour. In the Schedule Template table, there are 18 hours of senior analyst and designer times and 29 hours of junior developer and tester time. All costs are in-house components, so the BOM has a total cost of $2,800 for the non-core assets.

Product-Specific Details

The rules of the game are the most unique parts of the product. Distribute them across the EventHandlerDefinitions and the Game component, which is the container for the entire game implementation. Most of the rules enforced by Sprites are common across most (if not all) of the games. Develop the EventHandlerDefinitions component (like the Game component) specifically for a game.

Pay attention to the animation loop, which is the single most important product-specific detail in the Game class. It defines the game's sequence of events.

Metrics

Use the following two metrics to evaluate the product production process: (1) the number of new lines of code and (2) the number of unique lines of code.

New Lines of Code

This metric describes the number of lines of new code that must be written for this product. This new code may or may not be used in another product later. A high value indicates more effort required to produce the product and impacts cost and schedule.

Unique Lines of Code

This metric describes the percentage of the lines of code that are unique to this product. This metric changes over time: it can be difficult to predict which code gets reused or remains unique. A high value indicates less similarity between products and indicates a longer payback time.

Attached Processes²

Constructing the Production Plan

The following figure shows a high-level version of building a production plan. For details, review Chastek and McGregor's work [Chastek 02a].

High-Level Process for Constructing a Production Plan

Changing the Production Plan

The next figure describes the change process. After each product is produced, data are collected and used to update the core asset base for the next increment's products. After those changes are reflected in the architecture documentation and the generic production plan, the plan is reviewed to identify inconsistencies between it and the core asset base. The core asset team member who owns the plan initiates the review.

Process to Change the Production Plan

References and Further Reading

For details about the references cited in this document, see Arcade Game Maker Pedagogical Product Line: Bibliography.

¹ For the complete rationale for this production strategy, see the "For the record" memorandum from the VPPD, Memo 04-01.

² This section is the "attached process" described by Clements and Northrop [Clements 02]. The process in Constructing the Production Plan defines how the production plan is initially built. The process in Changing the Production Plan focuses on modifying the existing production plan of the product line.