Arcade Game Maker Pedagogical Product Line: Brickles Wireless Tier Production Plan
|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|
|2.1||4/04||M||Modified the AGM production strategy description||JDMcGregor|
|2.2||6/04||M||Modified in response to comments||JDMcGregor|
|2.5||10/04||A, M||Cloned the Brickles freeware tier production plan||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. For more details about the scope, see Arcade Game Maker Pedagogical Product Line: Scope.
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.
Using This Document
This document describes how the Brickles wireless tier 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].
For definitions of basic concepts, see Arcade Game Maker Pedagogical Product Line: Acronym List/Glossary.
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.
This document is a product of the Brickles wireless tier product team. All of the base classes illustrated in the Base Classes figure have been implemented and are available to the product-specific development teams.
The Brickles-specific tasks had been performed for the freeware tier product. None of the product-specific tasks have been carried out yet for the wireless tier.
We were planning to produce the Brickles product for the wireless tier from these assets. Unfortunately, the freeware tier products used C#, which has no Mobile Information Device Profile (MIDP) API and forced us to switch to Java. Doing so required porting the code assets to Java and revising the Java APIs.
Producing this document is part of the project planning.
Strategic View of Product Development
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.
We will briefly describe two types of properties: (1) product and (2) production process.
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.
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 strategy1 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
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.
- JUnit test case suite methods begin with "test."
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.
Each interface in the existing architecture has been implemented. The C# components are named according to the guidelines in Source Code Naming Conventions section.
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.
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)
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:
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
Game inputs are as follows:
- stylus events (this is a variation point among products: in the freeware tier products, events were mouse and keyboard)
- names of the files that save the score and the state of the game (when the change cases for saving are implemented)
Game dependencies are as follows:
- graphics library of the programming language (choosing one was problematic: the wireless tier must use the MIDP API, which is different from that of standard C# or Java)
- MIDP and subsequently Palm operating system
- operating system (when the change case for saving a game is implemented)
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.
The event-handling routines needed vary from one game to another and from one tier to another.
For the wireless tier, a set of Palm hardware events is handled using the WABI library for Java.
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 task 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.
Port from C# to Java, class by class, and then replace C#-specific APIs with Java APIs.
- Plan how to provide the remaining features from new assets.
Derive newly required assets from the newly ported Java assets.
- Design the new implementation of the EventHandlerDefinitions
Replace mouse and keyboard events with the stylus event handlers.
Build the Product
This step includes the following nine tasks:
- Start a new Eclipse project using Game_name Definitions as its name.
Use this class for all new classes except the game definition.
- Start a new class using Game_name.
- 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 directory containing the classes.
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.
Tailoring the Production Plan to a Product-Specific Production Plan
This is the specialized version of the generic production plan. The details below are for informational purposes only.
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 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.
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.
|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 day (10/5/04)|
|Product Analysis||Analyze the features.||Analyst (Gary)||≅ 0.5 day (10/5/04)|
|Product Design||Identify new elements needed by the game.||Designer (Jason)||≅ 2 hours (10/6/04)|
|Identify changes to existing elements.||Designer (Jason)||≅ 6 hours (10/6/04)|
|Design product-specific implementation of the game interface.||Designer (Jason)||≅ 1 day (10/7/04)|
|Design product-specific implementation of EventHandlerDefinitions.||Designer (Jason)||≅ 1 day (10/8/04)|
|Product Build||Create new implementations and make changes to existing classes.||Developer (Bob)||≅ 2 days (10/9/04)|
|Create new Eclipse projects for libraries and the application.||Developer (Bob)||≅ 0.5 hour (10/10/04)|
|Create the new make file.||Automated/developer||≅ 2 days (10/10/04)|
|Product Test||Create unit tests for new elements.||Developer (Bob)||≅ 2 days (10/11/04)|
|Modify existing unit tests for existing elements.||Developer (Bob)||≅ 1 day (10/13/04)|
|Execute unit tests.||Developer (Bob)||≅1 day (10/14/04)|
|Modify/extend the product test suite.||Tester (John)||≅1 day (10/15/04)|
|Execute the product tests.||Tester (John)||≅ 1 day (10/16/04)|
The primary resources are the Eclipse JDT 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 Eclipse environment to create any new required components. After all components are created, 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|
|Product-specific Game component||In-house||$1,000|
|Generic GameBoard||In-house||$ 725|
|Required Sprites: Puck, Paddle, Brick, BrickPile, Wall, Ceiling, Floor||In-house||$1,950|
|Implementation of EventHandlerDefinitions interface: BricklesEventHandlerDefinitions||In-house||$2,050|
The senior personnel are billed at $75/hour, and junior personnel are billed at $50/hour. In the first table, there are 32 hours of senior analyst and designer times and 66.5 hours of junior developer and tester time. All costs are in-house components, so the BOM has a total cost of $5,725 for the assets needed for this product.
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.
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.
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
The following 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.
1 For the complete
rationale for this production strategy, see the "For the record" memorandum
from the VPPD, Memo
2 This section is the "attached process" described by Clements and Northrop [Clements 02]. The process in the Constructing the Production Plan section defines how the production plan is initially built. The process in the Changing the Production Plan section focuses on modifying the existing production plan of the product line.