1

Pier436 RequirementsDefinition Document v2.0

Common Infrastructure Team

Pier436

RequirementsDefinition Document

Common Infrastructure Team

6 March 2007

Matthew Bensley

Zachary Patterson

Troy Ruths

Jared Stein

Introduction and Main Objective / 3
Project Extension and Dependency / 3
Feature List / 4
  1. Game Engine
  2. World Model
  3. Communication Manager
  4. Graphics
/ 4
4
5
5
Feature Dependency / 6
Use Case / 6
Glossary / 7

Table of Contents

Introduction

The common infrastructure team seeks to specify a type of application, and to provide a platform on which an application of this type could be built. The platform is motivated by three needed applications: the Building Security Simulation, the Island/Planet Exploration, and the Traffic Flow Simulation. This initial specification for the common infrastructure is initially conceived from the common aspects and possible dependencies of these applications.

Main Objective

Provide a platform implementing the most common features of the three applications, and a framework that can be used in developing applications that will use the platform.

Project Extension and Dependency

  • Pier436 will provide a platform for game development, giving collaborative and graphic abilities to applications.
  • The development of other teams depends heavily on this product, and we will allow for communication with other teams to better define project scope.
  • Dependencies that are common among all teams will be provided as library features.
  • We will also provide assistance and tutorials to use this product more effectively.
  • Tutorials will include a set of drivers that use the various parts of the platform design.

Survey Results

The infrastructure team created a list of initial considerations for the Pier436 product, and submitted them for review by the three applications teams. The application teams indicated their preferences, and the results below are used to frame the most important requirements for the Pier436 product.

  1. Development Language Preference
  2. Building Team -- C++, Java
  3. Island Team -- C/C++/Java
  4. Traffic Team -- C++
  5. Development OS Preference
  6. Building Team -- Linux, Windows
  7. Island Team -- OS X, XP
  8. Traffic Team -- Windows, Linux
  9. Supported OS Preference
  10. Building Team -- Linux, Windows
  11. Island Team -- All
  12. Traffic Team -- Windows, Linux
  13. Portability
  14. Building Team -- Yes
  15. Island Team -- Nice to have
  16. Traffic Team -- No
  17. 3D Support
  18. Building Team -- Peripheral
  19. Island Team -- No
  20. Traffic Team -- No
  21. 3D Effects Support
  22. Building Team -- No
  23. Island Team -- NA
  24. Traffic Team -- NA
  25. Number of Users in Collaborative Environment
  26. Building Team -- at least 4
  27. Island Team -- 1, Nice to have more.
  28. Traffic Team -- 1

From these survey results, we determined that the Pier436 product should at least support the following:

  • The teams should be able to develop their applications in Java.
  • The Pier436 platform should allow for development on both the Windows and Linux operating systems.
  • The Pier436 platform should be accessible by applications on both the Windows and Linux operating systems.
  • Multiple instances of an application must be able to collaborate with each other.

Feature List

1Game Engine

1.12D support

The game engine must support the following common 2D graphics libraries:

1.1.1Camera draw canvas

1.1.2Drawing utilities

1.1.3Sprite rendering

1.1.42D Sound

1.1.5Collision Detection

1.1.6Entity Picking

1.23D objects and scene support

1.2.13D view of 2D game world

1.2.22D Libraries Crossover

1.3User Interface (UI) support

2World Model

2.1The platform will maintain game state of the application, providing specifically the following:

2.1.1Time---A clock that can be used by the application, which can run as slow as real time and as fast as the application mandates.

2.1.2Load/Reset---The ability for the application to initialize and reset the world model.

2.1.3Entity Registration---To applications the ability to create and add entities to the world model maintained by the platform.

2.2The application will have the ability to define an environment in which the entities exist. The implementation of the map will support:

2.2.1Graphical viewer---A means for the user to view the state of the map, which supports:

2.2.2Zoom levels---The ability to view higher detail of a smaller area, or view more of the map at lower detail.

2.2.3Entity representation---The entities will be viewable superimposed onto the map.

2.2.4Uncover newly explored areas---Representation of entities with limited sight distance.

3Communication Manager

3.1Standard interface for communication over a network.

3.1.1The platform will provide near real-time message exchange over a network.

3.1.2The messages will be handled by a message controller in the platform.

3.1.3The platform will support guaranteed message delivery.

3.2The platform will support the capability of receiving and broadcasting world state changes.

3.2.1The application must have an event handler and event creators (including sprite interaction and UI interaction)

3.2.2Changes must be broadcast back to all client systems to keep systems in sync with each other

3.2.3The platform will maintain an event controller to update world state and dispatch messages to clients.

3.3The platform will provide an interface for manipulating entities that exist in the global world model.

3.3.1The platform will support entities that are shared to other clients on the network.

3.3.2The platform will support entities that are not shared to other clients on the network.

3.3.3The platform will support human and computer controlled entities that affect world state.

4Graphics

4.1Base Entity Hierarchy

The product will provide an entity hierarchy such that entities inherit behavior and are easily extensible. It will provide several commonly used entities, such as:

4.1.1Static entities---a non-interactive, non-colliding world object that do not respond to encounters or collisions.

4.1.2Dynamic (Impassible and Passable) entities---an interactive, colliding world object that respond to encounters and collisions with plugged-in event actions.

4.1.3Movable entities---an entity whose position state can be changed.

4.1.4Controlled entity---an entity that has pluggable control logic, either from a human or computer source (AI).

4.2Control Logic Hierarchy

The product will provide a hierarchy for control logic for controllable entities, such that they are responsible for the entities movement.

4.2.1Random movement---a parameter-based random walk.

4.2.2Constrained movement---a random movement in a confined space.

4.2.3Patterned movement---movement in a recurring sequence of steps.

4.3User Interface

The product must provide the application developer with a base user interface, which includes at least the following:

4.3.1Map Controls---Implement controls that change the view state of the map in the user interface.

4.3.2Implements UI behavior including buttons, text areas, and menus.

4.3.3Framework must be able to process and interpret user input, including keyboard and mouse events.

4.3.4The product must allow the application developer to add components to the user interface, as necessary for that application's specific concerns.

4.4Sprite Library---The product will provide a set of 2D sprites for the application teams.

4.5Message Protocol---The product will provide a standard message protocol to the application teams.

4.6Color Palette---The product will provide a color palette for the application teams.

Feature Dependency

The Pier436 product is a common platform for applications. It is essential that no part of Pier436 depends on the implementation of any of the applications. To be clear:

  1. The platform shall be independent of any other teams' project.
  2. The framework libraries will be dependent on the platform.
  3. Programming Language---the framework must communicate with the platform and the applications.
  4. Functionality---the framework provides applications access to the platform.

Use Case

In developing an application that uses the Pier436 product, the application developer extends the base simulation implementation that will be provided by Pier436. This removes the responsibility of generic UI implementation, and allows the application developer to focus on the logic of their team's particular game.

The platform supports collaboration, so the application developer can provide or deny access to other clients running instances of the application, and allow for two way communication between platform instances. This suggests the enforcement of a concrete messaging protocol, which will be supported by the product.

The uniform messaging protocol will enable users of the finished applications to operate collaboratively, transparent to the application's implementation.

Glossary

Entity - object in the game world that is tracked and kept current across all application clients

Framework - set of modules common across 2 or more applications.

Pier436 - the final delivery including the Framework, the Platform, and Documentation.

Platform - set of modules necessary in every application.

Product – (See Pier436)

Region - sub area of display space. Regions may be rectangular, ovoid, polygonal, or a conglomeration of the previous three basic types.

World Model - the environment in which the game is operating in.

WorldState - the state of all entities under the jurisdiction of the platform.