GameForgeA SPM Case

Study

-Presented by:
Ankit Kumar (1NT16IS021)
Supriya Hegde (1NT16IS178)
 Introduction
GameForge is a graphical tool used to aid programmers in the design and
creation of video games. A game designer with little or no experience with
Microsoft DirectX and/or Visual C++ programming can use GameForge to
construct his or her own 2D-arcade games. GameForge also assists experienced
programmers by generating the Microsoft DirectX code and Microsoft
Windows9x overhead necessary for basic game construction, allowing them to
concentrate on more detailed game design issues and implementation. The idea
is to limit the amount of actual code written by the game designer, while
providing an interface that is easy to use yet complete enough to remain
functional.
 Requirements
The software will consist of a number of inputs, graphically
assisting the user in creating on-screen objects including the
following:
User Created Objects (player character, creatures, static objects)
- Bitmaps (with animation)
- Collision Detection Areas
- Movement Routines
- Additional Object Attributes
• Backgrounds
• Input Device Setup
• Sound Events
• The software will also consist of a number of graphical
processing functionalities including the following:
• Defining/Editing Objects (including characteristics)
• Object Positioning
 Issues
Performance/Behavior Issues
• GameForge is designed to be compatible with the Microsoft Windows 9x
operating system. Microsoft Windows NT 4.0 and earlier versions will not be
supported.
•

• GameForge also requires Microsoft DirectX 7.0 or above. Users may also
want to obtain the DirectX 7.0 SDK if they plan on expanding the GameForge
library files beyond their original scope.
•

• GameForge also requires the Microsoft Visual C++ 6.0 compiler. GameForge’s
VC++ code may be compilable using Borland or some other VC++ compiler,
but functionality is not guaranteed.
 Management and Technical
Constraints
• GameForge has a drop-dead delivery date of 04/17/00.
• Projected Development Costs
Function Point estimations:
Interface: 243.04
• Engine: 303.45
Total FP: 546.49
• Reference FP calculations:
Demon Tree FP: 121.03
Demon Tree Person Months: 2.5
• Estimated Person Months:
Avg. FP per Person Month: 48.412
GameForge est. Person Months: 11.288
• Cost in Person months:
•

Industry average cost per Person Month: $8,000.00

 Project Risks

Project Risks

Major risks we have determined for this software are as follows:

- Equipment failure
- Late delivery of software
- Technology will not meet expectations
- End users resist system
Risks Category Probability Impact
- Changes in requirements
Equipment failure TI 70% 1
- Deviation from software engineering standards
Late delivery BU 30% 1
- Less reuse than planned
Technology will not meet expectations TE 25% 1
- Poor commenting ofEndsource
users resistcode
system BU 20% 1
Changes in requirements PS 20% 2
Deviation from software engineering PI 10% 3
standards
Less reuse than planned PS 60% 3
Poor comments in code TI 20% 4
 Project Schedule

Prototype GUI Prototype GUI

Requirements Design List of Revisions

GameForge Prototype
List of Revisions List of Revisions
Requirements System
Project Task Set
Prototype Engine Prototype Engine
Process Model Requirements Design Testing

PA Software will be using the Rapid Prototyping model during design and implementation: Deliver
GameForge
Framework Activities
• Customer Communication
• Planning/Design
• Risk Analysis
• Programming
• Testing
• Customer Evaluation

Task Set
 Project Schedule

List of deliverables

Documentation
System Requirements
Specification
Software Requirements
Specification
Design Document Functional Decomposition
Project Plan Interface Task Breakdown
• Level Editor construction
Software Quality Assurance Plan •

•
New Project wizard construction
New Sprite wizard construction
Database construction
Risk Mitigation, Monitoring, and
•

• Database communication with interface

• Exporting game files ability construction
Management Plan • Exporting .cpp files ability construction

Software Configuration Engine Task Breakdown

• Object Handler construction
Sprite Handler construction
Management Plan
•

• Image Handler construction (DirectDraw)

Requirements • Sound Handler construction (DirectSound)
GameForge
Specification
Test Plan • Input Handler construction (DirectInput)
• Text Handler construction
Logic Handler construction
Code
•

Interface Engine Help Testing ▪ Attribute Handling

▪ Unit Pathing
Engine Prototypes • File I/O Parser construction

Interface Mockups Help Task Breakdown

• Interface Help construction
 Proposed Plan

Testing Strategy
Unit Testing
All unit testing will be done in White Box fashion. Testing will be
conducted using Basis Path testing methods, because of its simplicity and
high effectiveness. Loop testing will also be conducted to compliment
the Basis Path testing.
Individual engine components (Draw Handler, Sound Handler, etc.) will
be tested separately. Due to the GameForge engine’s modular design,
there is no need for test beds. All components can be tested through the
Object Handler. The following engine components will be unit tested:
▪

▪ Object Handler / Engine Core

▪ Draw Handler
▪ Sound Handler
▪ Input Handler
▪ Text Handler
 Project Estimates

Interface Simple Average Complex

Number of User Inputs 12 3 4

Number of User Outputs 8 5 2

Number of User Inquiries 10 3

Number of Files 2 3 1

Number of External Interfaces 1

Estimation Techniques Applied and Results

The following is a breakdown of the numbers used in estimating the Function Point for GameForge:

Estimation Technique: Function Point Engine Simple Average Complex

Number of User Inputs 4 2

Number of User Outputs 1

Number of User Inquiries 15

Number of Files 6 3 10

Number of External Interfaces 1 1

14-Point Questionnaire: 34
Estimation Technique: Constructive Cost Model (CoCoMo)
The CoCoMo model was also used to verify the estimate
calculated by using the Function Point metric.
GameForge assumes itself to be an Intermediate, Semi-Detached
software project.
Effort = a (KLOC) b
Duration = c (Effort) d
Equation values for Effort calculation:
a = 3.0
b = 1.12
Equation values for Duration calculation:
c = 2.5
d = 0.35
 Software Configuration
Management Plan
• The primary focus of the Software Configuration Management (SCM) is to identify
and control major software changes, ensure that change is being properly
implemented, and report changes to any other personnel or clients who may have
an interest.

• The objective of SCM is to limit the impact changes may have on the entire system.
This will help to eliminate unnecessary changes, and to monitor and control any
necessary changes. This allows software development to continue, despite large
and/or insignificant changes without significant backtracking, lessening
development time and resulting in a higher-quality product.

 Software Quality Assurance Plan

• The SQA team’s objective is to ensure that the product does not
deviate far from the original design specifications. If it is discovered
that deviation has occurred, the SQA team will notify the
development team to prevent future deviations and to correct the
previous deviations. Also, the SQA team will perform a
walkthrough to analyze the product’s quality at any particular stage
of development. Error detection and possible enhancements are also
expressed to the development team.
 Problem Reporting and Corrective
Action/Follow-up
Reporting mechanisms

• All defects or enhancements are referred to the SQA leader.

Most often, this will be completed in every SQA review held.
If a defect occurs between SQA meetings, the defect will be
reported to the SQA promptly, so that the SQA leader can
analyze the defect and assign a priority level to it. This can
occur either by word of mouth (so long as the SQA leader is
taking note), email, or a hand written report.

Data collection and evaluation

• The SQA leader is responsible for all data collection and

evaluation. Any product defect or enhancement will be
reported to the SQA leader so that he can record the problem
 Tracking and Control Mechanisms
Quality Assurance and Control
• The SQA team’s objective is to ensure that the product does not
deviate far from the original design specifications. If it is discovered
that deviation has occurred, the SQA team will notify the
development team to prevent future deviations and to correct the
previous deviations.
Change Management and Control
• The primary focus of the Software Configuration Management
(SCM) is to identify and control major software changes, ensure that
change is being properly implemented, and to report changes to any
other personnel or clients who may have an interest.
•

• The objective of SCM is to limit the impact changes may have on the
entire system.
•

• The SCM team will oversee these activities, and any changes to
existing code or architectural design must pass their inspection before
they are carried out.
 Reports/Solutions
Test Metrics
• Function Point: this metric will be used when calculating statistics pertaining to
the complete testing process.
•

• Bang Metric: this metric will be used to provide an indication of the number of
test cases required.
•

• Cyclomatic Complexity: this metric will be used to target modules as candidates

for extensive unit testing. Modules with high cyclomatic complexity are likely to
be more error-prone.
•

• Breadth of Testing: this metric provides an indication of testing completeness.

•

• Depth of Testing: this metric provides a measure of the percentage of independent

basis paths covered by the testing versus the total number of basis paths in the
program.
•

• Fault Profiles: this metric is used to prioritize and categorize uncovered errors.
•

• Frames per second: this metric is used to gauge the performance of the game
 Conclusion/Graphs

• System Architecture
Test schedu
 Relationships

Sprite Library User Interface Data File

Image Library
Project File

Sound Library

C++ Engine C++ File

Header Files

System Modeling and Simulation Results

Description of System Modeling Prototype GUI Prototype GUI

Approach Requirements Design List of Revisions

System modeling takes place during early team

GameForge Prototype
meetings. No special tools will be used. The Requirements
List of Revisions List of Revisions
System

model will be developed on paper. Prototype Engine Prototype Engine

Requirements Design Testing

Simulation Results
No simulations were used. Deliver
GameForge

Special Performance Issues

Refresh rate of 30 frames per second.

Prototyping Requirements
The interface prototype will be created using
Microsoft Visual Basic. The C++ portion will
 Bibliography

https://grafana.com/grafana/gameforge
• http://gfl.gameforge.com
• http://www.mhhe.com/engcs/compsci/pressman/graphics/Pressman5sepa/common/cs2/design.pdf
• http://gameforge.com