Project 4.18: Game Project Architecture Review Architect: Gary Pugliese Doug Kavendek Bret Kalva.

Project 4.18: Game ProjectArchitecture Review

Architect: Gary PuglieseDoug KavendekBret Kalva

Initial Architecture Design

Logical View

Logical View

● Graphics Module– Environment Sub-Module: static objects – Objects Sub-Module: characters and enemies,

projectiles, items– Renderer Sub-Module: camera, locked on

character while moving, separate feature to rotate around character when not moving.

– Effects Sub-Module: graphical particle, lighting, spell effects

– GUI Sub-Module: user interface (playing screen, inventory screen, stats/attribute screen)

Logical View

● Physics Module– Player Movement Sub-Module: how player

travels through environment, run/walk, fly– Collision Detection Sub-Module: comparing

against all things in local area– NPC/Creature Movement Sub-Module:

simplified character movement for creatures/NPCs

– Projectile Motion Sub-Module: how projectiles will function and travel

Logical View

● AI Module– Pathfinding Sub-Module: how

character/creature/npc gets to a location, shortest distance

– Basic Strategy/Skill Choice Sub-Module: skill choice for creature response to player character

● Input Module– Picking Sub-Module: identifies what user clicks on– Mouse/Keyboard Control Sub-Module:

character movement and input/output, use mouse clicks to move character

Logical View

● Gameplay Module– D20 Sub-Module: handles rules of the game (i.e.

damage, chance to hit, etc)- Movement Sub-Sub-Module: speed of

character- Combat Sub-Sub-Module: handles

mathematics and formulas behind combat (for computing damage,

chance to hit, etc)- Story Sub-Module: storyline, plots,

quest choice, player and npc dialogue interaction

Logical View

● Data Warehouse– A central store for all data structures.– Accessible by all modules.– The data in the Data Warehouse represents the

“game state”.

● Coupling:– 5 modules– 6 one way links– Coupling = num of one way links/num of mod.– Coupling = 1.2

Physical View

• The game system runs on a windows based machine with the OpenGL API installed. The same configuration has been used for development, testing, and deployment.

Process View

Process View

● Start Menu: This will be the first screen a user of the game will see. This screen allows the user to start a new game, load a saved game, visit an options screen, or exit the system.

● Character Creation: Allows the user to create their character which they will use during the game.

● Game Play: The main game screen. The user can pause the game to access the game settings.

● Settings: Allows the user to save a game, load a game, view the options of the game, return to game play, quit to start menu, or quit to windows.

Process View

● Load: Allows the user to load a previously saved game.

● Save: Allows the user to save their current game and settings.

● Options: Allows the user to change graphics options and controller setups. From the options the user can return to the settings screen, if accessed during a game, or return to the start menu, if accessed from the start menu.

● Controls: Allows the user to pick their control setup.

● Graphics: Allows user to adjust the current graphic settings.

● Exit: Allows user to exit the game system to Windows.

Development View

• The development environment for the Graphical Game consists of each developer’s workstation. Each workstation is running Windows XP, using Visual C++ and the OpenGL API. A graphics card of at least 128mb is required.

• In order to install the game system, a windows executable is used. The executable installs a local copy of all needed libraries and data files, such as the OpenGL libraries. Once the executable has completed, the game can be launched and played.

Use Case Scenarios

Use Case: Install Graphical Game

ID: UC1

Actor(s): User

Precondition: Graphical Game Installation file is downloaded

Flow of events:

1. Use case begins when the user runs the Graphical Game installer program.

2. Installer asks the user where to install Graphical Game and clicks ok.

3. Installer installs the program on the system.

Post condition:

1. Graphical Game is installed on the user’s system.

Exception(s):1. If the hard disk does not have enough space for the Graphical Game, the installer asks the user to create more disk space and stops the installation process.

2. If the user does not have adequate privileges to install programs onto disk, the installer does not install the Graphical Game onto the target system.

Use Case Scenarios

Use Case: Start Graphical Game

ID: UC2

Actor(s): User

Precondition: Graphical Game is installed on system (UC1)

Flow of events:

1. Use case begins when the user runs the Graphical Game executable.

2. Graphical Game is running.

Post condition:

1. Awaiting user interaction at start menu.

Exception(s):

1. If the config file is not found, Graphical Game uses the default settings.

Use Case Scenarios

Use Case: Play Graphical Game

ID: UC3

Actor(s): User

Precondition: UC1 and UC2 have completed successfully

Flow of events:

1. Use case begins when the user clicks on Start from the start menu.

2. User will be required to create their character.

3. User begins playing the game.

Post condition:

1. Graphical Game is in progress.

Exception(s):

1. If character is not created, user can not start playing the game, return to main

menu.

Use Case Scenarios

Use Case: Save Graphical Game

ID: UC4

Actor(s): User

Precondition: UC1, UC2, and UC3 completed successfully.

Flow of events:

1. Use case begins when the user chooses to save game from game menu.

2. Game is saved.

Post condition:

1. Current user’s game and settings are saved.

Exception(s):

1. If no progress has been made or settings have not been changed, game will

not be saved.

Use Case Scenarios

Use Case: Load Graphical Game

ID: UC5

Actor(s): User

Precondition: UC1, UC2, UC3, and UC4 completed successfully

Flow of events:

1. Use case begins when the user chooses to load game from start menu or game

menu.

2. Chosen game to be loaded is loaded.

Post condition:

1. A previously saved game, which is chosen by user, is loaded.

Exception(s):

1. If there are no previously saved games, game will continue as is.

Use Case Scenarios

Use Case: Change Graphical Game Options

ID: UC6

Actor(s): User

Precondition: UC1 and UC2 must be completed (UC3 is not required)

Flow of events:

1. Use case begins when the user chooses to view options from start menu, game

menu if UC3 is completed.

2. Options are displayed to be configured by user.

Post condition:

1. Options are configured to user’s choice.

Exception(s):

1. If user does not change options, default options are used.

Use Case Scenarios

Use Case: Quit Graphical Game

ID: UC7

Actor(s): User

Precondition: UC1 and UC2 completed successfully.

Flow of events:

1. Use case begins when the user chooses to exit the game.

2. Graphical Game quits.

Post condition:

1. Graphical Game is no longer running.

Exception(s):

1. If user does not save current game, that game’s data will be lost.

Use Case Scenarios

Use Case: Uninstall Graphical Game

ID: UC8

Actor(s): User

Precondition: UC1 completed successfully.

Flow of events:

1. Use case begins when the user runs the Graphical Game uninstaller program.

2. The Uninstaller program asks whether the user wants to remove the Graphical

Game from his or her system.

3. The user clicks yes and the Uninstaller removes the Graphical Game from the

system.

Post condition:

1. Graphical Game is removed from the user’s system.

Exception(s):

1. If the user does not have adequate privileges to remove programs, the

Uninstaller does not remove the Graphical Game.

2. If the Graphical Game is running, the Uninstaller will not continue. The

Graphical Game can only be installed if an instance is not running.

QFD

Input Module

Goals/Features Picking Mouse/Keyboard Sound/Music

Efficient 8 8 4

Response Time 8 8 8

Ease of Use 8 8 0

Cohesiveness 8 8 8

Accuracy 8 8 8

TOTAL 40 40 28

AI Module

Goals/Features Path Finding Enemy Strategy

Efficient 5 5

Response Time 7 7

Cohesiveness 5 5

Accuracy 5 5

TOTAL 22 22

QFD

Physics Module

Goals/Features Player/Enemy Movement Collision Detection Projectile Motion

Efficient 7 8 5

Response Time 8 8 7

Cohesiveness 6 7 4

Accuracy 7 6 7

TOTAL 28 29 23

Gameplay Module

Goals/Features D20 Rules Attribute/Skill Based Movement Story Combat Results

Efficient 7 5 8 8

Response Time 8 0 0 8

Cohesiveness 8 5 6 6

Accuracy 7 6 6 7

TOTAL 30 16 20 29

QFD

Graphics Module

Goals/Features GUI Terrain Render Indoor Render Model Render

Efficient 7 8 8 7

Response Time 8 8 8 8

Ease of Use 7 0 0 0

Cohesiveness 7 6 6 6

Accuracy 6 7 7 6

TOTAL 35 29 29 27

ICED-T

● Intuitive: 3● Consistent: 4● Efficient: 4● Durable: 4● Thoughtful: 5

ICED-T

● Intuitive – – Focused on game play element and user interface component.– Ease of use and learning curve of using the UI.– Learning curve of game play constructs such as quest system/skill

system/game rules.● Consistent –

– Focused on game engine component– Is the game engine generating consistent output throughout the game

playing experience?● Efficient -

– Focused on game engine component– Main focus is on response time.– Does the game engine respond fast enough to be real time interactive?

ICED-T

● Durable –– Focused on game engine component.– The game should not crash.

● Thoughtful – – Focused on game engine component.– Expandability of the game engine.– Can we easily maintain the code?– Can we easily add new game features?– Can we easily create role-playing games with this game engine?

Function Points

Data Files:

Name Type Complexity

Outdoor Environment Internal File High

User configuration Internal File Low

Graphics Module:

Requirement Outputs Inquiries Inputs Comments

# 1 1A 1A 1A GUI

# 2 1A 1A 0 Terrain Rendering

# 3 1A* 1A 0 Indoor Rendering

# 4 0* 0* 0 Model Rendering

Function Points

Input Module:


# 1 0 0 1A Picking

# 2 0 0 1A Mouse/Keyboard Control

# 3 1A 0 0 Sound/Music

AI Module:


# 1 1H 0 1A Pathfinding

# 2 1A 1A 0 Enemy Strategy

Physics Module:


# 1 1L 0 1L* Player/Enemy Movement

# 2 1L 0 1L* Collision Detection

# 3 1L 0 1L Projectile Motion

Function Points

Gameplay Module:


# 1 0 1L* 1L D20 Rules

# 2 1A 1A 0 Skill-based Character Movement

# 3 0 1A* 0 Story

# 4 1A* 0 0 Combat Results

Requirement Low Average High

Outputs 3 7 1

Inquiries 1 6 0

Inputs 4 4 0

Function Points

UFP(low) = 3I + 4O + 3F = 3(3) + 4(1) + 3(4) = 9 + 4 + 12 = 25*UFP(average) = 4I + 5O + 4F = 4(7) + 5(6) + 4(4) = 28 + 30 + 16 = 74*UFP(high) = 6I + 7O + 6F = 6(1) + 7(0) + 6(0) = 6 + 0 + 0 = 6*UFP(low file) = 7L = 7(1) = 7UFP(high file) = 15L = 15(1) = 15UFP(interface) = 7F = 7(0) = 0

UFP(total) = UFP(low) + UFP(average) + UFP(high) + UFP(low file) + UFP(high file) + UFP(interfaces) = 25 + 74 + 6 + 7 + 15 + 0= 127*

Old UFP = 167New UFP = 127*

Function Points

- Development effort influence (0-5)Data communication 3* (No operations module, data is just shared)Distributed data processing 0Performance 5Heavily used configuration 3Transaction rate 2Online data entry 0End user efficiency 4Online update 0Complex processing 3Reusability 2Installation ease 1*Operational ease 4Multiple sites 0Facilitate change 2Total (DI) 29*Adjustment Factor 0.65 + 0.01 * DI = 0.94*Old AFP Old UFP * 0.98 = 163.66New AFP New UFP * 0.94 = 119.38*

Gantt Chart

Test Plan

The plan for testing will be to perform all the test cases that are listed below. Tests will be performed using various machines that are running Windows XP with sufficient capabilities to run most graphics programs. After running through these tests, the program will be looked at by individuals, outside of the group to ensure that these tests have covered all aspects of the program.

Main Test Machine Specifications:

Windows XPPentium 4 3.4 GHz1 GB ramRadeon 9700 graphics card

Test Cases

Description Input Expected Output

Path Finding Non-player and player Movement The non-player and player will follow the shortest path to the desired location

Skill Choice for Non-player character (NPC) System The NPC will be able to interact with the player in the correctly desired manner (AI)

Mouse picking Mouse click The user can interact with the system via clicking on the screen

Keyboard input Keyboard Stroke The key pressed is handled correctly by the system

Player movement Player moves around the environment

The player follows the terrain when moving, and is able to walk and run

Collision Detection Objects colliding If two objects collide, i.e. a player and a wall, a realistic reaction will take place

Projectile Motion Object in flight An object in flight will obey the laws of physics and fly accordingly

Environment View System All NPC’s, player, and objects are displayed relative to their position in the world

Rules are obeyed System Rules for interaction, and combat are followed

Camera Movement User The user will be able to move the camera based on input

Camera View User The camera will move based on the user’s movement

Unit Test Cases

Test Cases


Starting up the Game User The Game will begin and the user will be able to play the game

Loading Saved Game User Status of the user’s and world’s status is correctly retrieved

Saving Game User Status of the user’s character and world attributes are successfully saved

Shutdown The Game User The Game will correctly shutdown in a timely manner

Installing the Game User The Game will install itself correctly

Functional Test Cases

Test Cases


Clicking on the screen Mouse Click Object that click is over is interacted with

Clicking on screen for 30 seconds without stop Mouse Click for 30 seconds Interaction/selection changes appropriately

Clicking on screen for 60 seconds without stop Mouse Click for 60 seconds Interaction/selection changes appropriately

Interacting with one Non Player Character(NPC)/Monster on the screen

Mouse Click/Keyboard Input Movement remains smooth and interaction is not slowed down

Interacting with 5 Non Player Character(NPC)/Monster on the screen






Game Runs without Crashing for 1 hour Game is left on with periodic interaction for an hour

System does not crash, and no irregularities with the system are detected

Game Runs without Crashing for 5 hours Game is left on with periodic interaction for 5 hours


Game Runs without Crashing for 10 hours Game is left on with periodic interaction for 10 hours


Stress Test Cases

Test Cases


Memory Leaks System There should be no memory leaks when the Game is being run

Memory Corruption System The files affected by the Game should be intact and uncorrupted while the Game is in progress

System/Hardware Flexibility System The speed and stability of the Game do not change

Reliability Test Cases

Design for Testability

● The primary output is simply the graphical visualization of the game world itself, which is used in testing such features as gameplay, by seeing how various objects and locations are represented and located.

● The error log, in addition to printing errors and warnings that may occur, also is used for simply outputting general information about the execution of the program, during the development of the program.

● The on-screen display presents a few key bits of information, such as the frames-per-second (FPS), which is critical for performance issues. The engine also records the max, min, and average FPS, so that comparisons in performance of different methods are easily measured.

● The announcement structure prints a large message to the middle of the screen when selected key events occur, so that the exact time that certain events occur can be determined. These structures are critical for testing purposes. The announcement structure will remain in the final game because they can serve further purposes besides testing; for example, the announcement structure can be used to give the player information about when they have entered certain locations or have achieved a new experience level.

Design Simplifications

● Reuse: platforms, COTS, components, tools– Gameplay Module

- Use of set Role-playing Rule System (d20 system) for combat,

abilities, and levels.

– Physics Module- Uses a physics library for the low-level calculations

involved in collisions and projectile motion.

● Algorithms– AI Module

- A* algorithm used to simplify pathfinding.

● Refactoring– Graphics Module

- Model rendering handled with previously implemented code.

COCOMO

● E = b(KLOC)^c● Our COCOMO estimation is based upon a semidetached

project. Our team consists of experienced and inexperienced members, who are taking on a fairly large project. Development will be taking place in a Windows environment using C++. According to the Caper Jones values, it was estimated that the current LOC, lines of code, per FP, function point, would be 53. There are an estimated 119 function points.

● KLOC (in thousands) = (53 LOC/FP) * (119 FP) = 6.307● E = 3.0 (6.307)^1.12 = 23.60 (effort in staff months)● The team consists of 8 developers each with 5 months

development time. A 40 staff month time is allotted which equates to 160 student months. Therefore, according to the COCOMO estimate, the project should not be able to be completed in time disregarding the ability to add extra features.

Demonstration

Project 4.18: Game Project Architecture Review Architect: Gary Pugliese Doug Kavendek Bret Kalva.

Documents

Transcript of Project 4.18: Game Project Architecture Review Architect: Gary Pugliese Doug Kavendek Bret Kalva.