Abstract

gasownerΔιαχείριση Δεδομένων

31 Ιαν 2013 (πριν από 4 χρόνια και 6 μήνες)

150 εμφανίσεις





University of Washington
-

Bothell

Improving Game Design Quality through
Modularization

CSS
-
555 Evaluating Software Design

Charles J Pilgrim

5/15/2011








Abstract

Modularization improves a number of quality attributes including maintainability, comprehensibility and
extendibility.
Within a given computer game genre, such as Role
-
Playing Games (RPG), m
odularity in the
architectural design for computer
games also allows the reuse of the architectural design and the
metrics and m
easures derived for that design.





Discussion

Computer gaming represents one of the most, if not
the

most, popular

and prolific applications of
computer tech
nology
.

C
iting a 2004 study by Schaefer and Warren, Taylor et al (2007) state: “
t
he
computer gaming industry has today become bigger than the word
,

music and film industries.



Within
the various
genres

of compute
rized games, the action and adventure type of Role
-
Playing Game (RPG)
are almost certainly the most popular, and, except where otherwise noted, this discussion will center on
th
at

genre.

Given its popularity, examining the process of developing a computer
game, and improving those
processes

associated with developing computer games,
is a beneficial exercise for any company that
produces and sells computer games. Taylor et al (2007)
,

cit
ing

a previous st
udy that Taylor participated
in, say “computer games de
sign approaches typically appear to be less formalized than those used for
other types of software systems.”

Even with the increasing popularity of computer games and the
strength of the gaming industry, research of this genre of software development is st
ill in its infancy, as
stated by Ampatzoglou and Chatzigeorgiou (2007), “this fact leads game programming professionals to
demand better developing methodologies and software engineering techniques.”

Conceptually, the development of computer games follows
virtually identical
phases

from inception to
final product as do other types of software systems: requirements collection; architectur
al

design; detail
design; coding; testing;
and
implementation.
For computer game design and development the
differences ar
ise when digging into the details of each step.

For example, for other types of software
,

requirements are defined by the business and user needs
, often with the direct input from the
business

and users
; whereas, for computer games, rarely do the end
-
users directly provide the requirements of a
new game.

In many ways, the development of computer games
is more similar to the production of a movie than it
is developing software. Generally, RPG requirement
s are defined by a story
, and
the use of a
“storyboard,” a common technique of movie development, might be more useful for game development
than use cases in the UML
software
engineering model
.

As development progresses, the processes
diverge even more oft
en to

areas unique to computer games.

F
or example, as mentioned by

Ampatzoglou and Chatzigeorgiou (2007), gaming and
game

development is the first, and often the only,
market for advanced graphics.

This idea of game development possessing unique attributes

is further
described by

Ampatzoglou and
Chatzigeorgiou (2007)
when they explain

that the distinction of game design and development is not the
discrete roles of the involved personnel as might be found in business
-
oriented and other
areas of
software deve
lopment, but the teams include people with different fields of expertise, many of which
are not traditionally considered tied to software development. The roles

and basic functions

listed by
the authors

are:



Script Writer

Writes the game script and creates

a document typically called a “concept paper.”





Lead Game Designer

Converts the information from the concept paper to a “design document” which becomes the
guide throughout development of the game.



Programmers with Specializations
:

o

Engine and Graphics

o

Arti
ficial Intelligence

o

Sound

o

Tools



Musician/Sound Effects Specialist



Graphic Artists



3D Modelers



Texture Artists



Testers

S
ummariz
ing the

general state of game development
Ampatzoglou and Chatzigeorgiou (2007
) say
the
software is “divided, logically, into subprograms that are autonomously designed, programmed and
tested.”
Typically c
alled “modules
,
” the process
of
decomposing
the game design
into
these
modules is
an “important decision that plays a main role in th
e arch
itecture and further desig
n of the program.”


Citing

Christopher Alexander, who they say introduced the notion of design patterns, they describe
Alexander’s studies, and that “he dealt with the question whether quality in architecture can be
objective.


Continuing their discussion of Alexander’s study, they say that, after examining a number of
architectural artifacts, common ch
aracteristics of “g
ood” quality designs could be found.

They further state that “patterns can also be used in software architect
ure and, if applied properly, they
increase flexibility and reusability” of the developed modules and code.

Applying this concep
t to object
-
oriented design patterns
, these

patterns “specify the relationships between the participating classes and
determine
their collaboration.” This modularization of the design improves adaptability, and makes
future changes easier to implement.

Specific to computerized gaming, they say “design pattern usage in game development is an open
research field.” Two perspectives c
an be used to approach design patterns in gaming: “patterns used for
describing the game mechanics (gameplay and game rules)”; and “the use of object
-
oriented design
patterns in programming games.”

At a high level, the general structure of a game is a syst
em of modules based on
the

gaming

platform

(“X
-
Box,” “PlayStation,” etc.)
, and separat
es

the various functionality of the game into modules that
handle the game play, the

interactive

events from the platform, sound, and graphics.
Basing their
analysis on

a

generic game architecture devised by Bishop et al,
Ampatzoglou and Chatzigeorgiou

(2007)

demonstrate
th
e use of patterns to increase the

modularization of a game.

Increasing the
modularization is beneficial for increasing the maintainability and comprehen
sibility of software
, as well
as reducing complexity and coupling
,

and increasing cohesion.



To demonstrate the use of patterns in game design
, Ampatzoglou

and Chatzigeorgiou (2007) discuss
the
object
-
oriented

based
ideas of game “Strategy and Observer Pat
terns” and “State and Bridge pattern
concerning the 3D

aspects in the graphics module
,


and they describe each pattern as follows:



The
Strategy

pattern defines and encapsulates a family of algorithms making them
interchangeable. This concept
is

most easily
recognized in

strategy
-
based games such as chess
and backgammon.

With its discrete sub
-
classes, s
eparating strategy out as a class makes it more

understandable, more independently maintainable and more
extendible.

This c
las
s is most
adaptable t
o games that utilize artificial intelligence
, such as Role
-
Playing Games

(RPG)
, but can
be adapted to many other types of games.



The
Observer

pattern describes a one
-
to
-
many relationship between objects that allows the
changes to one object to cascade thro
ugh all dependencies. The
authors’
example was a football
m
anager game that hires trainers;

h
iring
a

trainer affects the attributes of the players at various
levels
and various times
while the game progresses. This pattern allows these changes in
attribute
s to be automatically updated during game play.



T
he
State

pattern
, for use in the game graphics,

manages
the behavior of an object when the
internal state changes. For example, the appearance of an object depending on its distance from
the camera or viewer

(player)

changes as the distance to that object changes
.

For example, i
n
an
RPG, a building or other object gains more clarity and detail as the player approaches the
object,
and the State pattern more easily manages this change of state and the impacts o
f it on play.



T
he
Bridge

pattern
, also for use in the game graphics, separates

the interface from the
implementation; that is,
the class allows
such things as resolution and color
to

be resolved at
run
-
time and not have to be “hardcoded” into the applicati
on.

For the purposes of their study, Ampatzoglou and Chatzigeorgiou (2007) used metrics
of

Size,
Complexity, Coupling and Cohesion as the basis of their analysis. Using two Open
-
Source games,
“Cannon Smash” and “Ice Hockey,” they compared measures of these metrics before applying their
patterns against the same metrics after applying their patt
erns.

Pattern instances
have been

identified using size, cohesion and coupling metrics, with the implication
that the presence of pattern affects the metric values. Coupling is an obvious measure since “the use of
abstractions in design pattern primarily a
ims at reducing the dependencies between classes.” It also is
reasonable to expect the use of patterns increases cohesion when patterns are appropriately used.

Size
metrics care cal
culated using Lines of Code (LOC
) and Number of Classes (NOC).

From the
Ev
aluation of “Cannon Smash”
the authors
conclude that “the application of design patterns
leads to more comprehensible and maintainable code.” Th
is

analysis also demonstrated using patterns
in game design reduced coupling, increased cohesion and made unders
tanding, testing and maintaining
the game easier.

Evaluation of “Ice Hockey” demonstrated that using design patterns reduces the complexity of the
pattern participating classes, but that the additional functionality added to the game increased the
apparent

overall complexity of the game

design and coding
. Even at that, cohesion improved, and


coupling was reduced.

Th
is

curiosity of
the
results on the “Ice Hockey” game
is that the metrics indicate
an increase in complexity, but this increase appears primarily

center
ed

on an increase in the Lines of
Code (LOC). Considering the apparent improvement in the other metrics, this raises the specter of doubt
on the appropriateness of using the LOC metric to measure complexity in applications of
high
modularity;

that i
s,
low coupling and high
cohesion
.
Further analysis of this curiosity might be the basis
of future research.

Sarkar et al (2007) studied modularity and developed a series of architectural metrics that measure
modularity of software. The concept for modular
ity they used, as dictated by modern software
engineering principles, is that software be organized as modules that interact primarily through an
interface or API defined within each module. Citing a 1972 study by DL Parnas, modules capture “a set of
desig
n decisions which are hidden from other modules.”

They further define modules as “a set of functions or subprograms and data structures” that often
implement at least one business concept
; relative to computer games, these concepts might be the
rules of pl
ay within the game, or how the internals of the game interface with the platform
.


This grouping of functionality and data can be based on “similarity of purpose” or “commonality of
goal.” This form of grouping encourages and,
as Sarkar et al (2007)
claim,

promotes encapsulation
(hiding the internal structure of the module). Access to these internals is provided by the module
through a defined interface, often called an “Application Programming Interface” (API).

Although originally identified in the contex
t of Object
-
Oriented design, this encapsulation provided by
modularization improves the quality attribute dimensions of
understandability
,

testability
,
changeability
,

analyzability

and
maintainability
. Centering on these concepts, Sarkar et al identify the

following
collection of principles:



Principles Related to Similarity of Purpose

o

Maximization of Module Coherence on the Basis of Similarity and Singularity of Purpose

o

Minimization of Purpose Dispersion

o

Maximization of Module Coherence on the Basis of Comm
onality of Goals

o

Minimization of Goal Dispersion



Principles Related to Module Encapsulation

o

Maximization of API
-
Based Intermodule Call Traffic

o

Minimization of non
-
API
-
Based Intermodule Call Traffic



Principle Related to Module Compilability

o

Maximization of
the Stand
-
Alone Module Compilability



Principles Relating to Module Extendability

o

Maximization of the Stand
-
Alone Module Extendability



Principle Related to Module Testability

o

Maximization of the Stand
-
Alone Testability of Modules



Principles Related to Acycl
ic Dependencies

o

Principle of Minimization of Cyclic Dependencies Amongst Modules



o

Principle of Maximization of Unidirectionality of control flow in Layered Architectures



Principles Related to Module Size

o

Principle of Observance of Module Size Bounds

o

Princip
le of Maximization of Module Size Uniformity


Based on the above principles, Sarkar et al develop
ed

a set of metrics as defined in the following
classifications:



Coupling
-
Based Structural Metrics

o

Module Interaction Index

o

Non
-
API Function Closedness Index

o

A
PI Function Usage Index

o

Implicit Dependency Index



Size
-
Based Metrics

o

Module Size Uniformity Index

o

Module Size Boundedness Index



Architectural Metrics

o

Cyclic Dependency Index

o

Layer Organization Index

o

Module Interaction Stability Index

o

Testability Index



Metrics Based on Similarity of Purpose

o

Concept Domination Metric (CDM)

o

Concept Coherency Metric

Their experiments used
a number of

Open
-
Source software systems (MySQL, Apache, Mozilla, GCC, the
Linux kernel and Postgresql). The results confirm that the met
rics they developed were able to detect

improvement in modularization, and an improvement in modularization reflect
s

improvements in the
quality attributes of
understandability, testability, changeability, analyzability and maintainability
.

In a study to identify potential security risks in software, Chowdhury and Zulkernine (2011) use
Complexity, Coupling and Cohesion (
CCC
)

metrics to map the
CCC

to potential security risks in the
software architecture. Citing a 2003 study by Bass, Clements
and Kaxman, Chowdhury and Zulkernine
state this association exists because “the software architecture of a system is the structure or structures
of the system, which comprises software elements, the externally visible properties of those elements,
and the
relationships among them.”

The design of CCC metrics is to measure the quality of the structure of software. Metrics related to
Coupling measure the relationships between entities; for example, a function or method that calls a
second function or method cr
eates a coupling between the two functions. If these two methods are
within the same module that module is tightly coupled, but if these two methods are in different
modules, the individual modules are loosely coupled and the two modules are tightly couple
d.



Although Chowdhury and Zulkernine centered on detecting threats to security, the demonstrated
success of their experiment raises the question of what other quality attributes can be enhanced using
similar analysis. Because it could be done for security,

the feasibility of developing these metrics to
improve, for example, performance increases. Performance of computerized games being a significant
expectation of the gaming market, improv
ed

performance might give a company a leg up on its
competitors.

Foc
using on game
-
play mechanics, Ip and Jacobs (2004) developed measurements that they used to
compare the features of several games. Their study used several previously marketed games in the
genre of rally or driving games,
and they selected certain features

within the games to compare.

These
selected features represented the expectations of a user who would be playing the game; for example,
among other features,
the average time to complete a stage (conceptually “level”) of the game, the
acceleration and bra
king of the vehicle being driven, and the gear speed of the vehicle.

Although their study used games that were already on the market, the study demonstrated that the use
of metrics for comparison can provide much information as to the design and quality
of a product.
Utilizing the concepts they present in earlier s
tages of design and development, metrics can be defined
for key elements or features of the game in the architecture of the game, and these metrics refined
and
applied
through the detail and cod
ing stages of development.

Likely t
he primary risk of such an activity would be
, during architectural design,

selecting the wrong
elements or features to measure.
This risk can be mitigated by doing exactly what Ip and Jacobs

did
:
analyze
products
currentl
y
on the
market

and develop metrics to measure the quality and features of
those products
.

Such analysis not only helps to develop the metrics to use during architectural and detail development
of a game but also gains some insight into the features the co
mpetition includes in their games. This
information can be of great assistance in develop
ing the requirements of the game. In addition, they
provide a measure on how well the original requirements and design of the game were achieved
. Also,
the metrics tha
t evolve from such a study may be incorporated into the design pattern for the game
genre.

In the light of developing and defining metrics, Weyuker (1988) developed a set of properties to
evaluate measures

and metrics
. Her properties
center on

Complexity m
easures, and she says of such
measures: “one of the difficulties in assessing complexity measures is that it is not always clear what the
measure is supposed to be measuring.”

Building on the work of Weyuker
,

Briand, Morasca and Basili
(1996)
extend these
properties to include evaluation of Coupling and Cohesion measures.

They describe Weyuker’s work as “one of the first attempts to formalize the fuzzy concept of program
complexity.” In that light Weyuker is highly referenced in similar studies, and
often
c
riticized
to
be
, as
summarized by Briand, Morasca and Basili (1996),

“inconsistent” and “incomplete.”

Be that as it may,
whatever problems her work may exhibit now, Weyuker
must be given credit for
broach
ing

the walls of
defining a

reasonabl
y

applicabl
y

means to validate the measures and metrics being used to measure


software quality.

In developing these properties, Weyuker based her analysis on the low
-
level detail and
resultant code of an application rather than the high
-
level, architectural design.

Asi
de from extending the properties to include Coupling and Cohesion, the properties developed by
Br
iand, Morasca and Basili (1996) also extended their use to allow

valida
tion of

the metrics used to
measure the quality of
the high
-
level
architectural design a
s much
as the low
-
level design and code
.

Enumerating these properties, as well as attempting to explain the mathematics behind them, is beyond
the scope of this discussion, but having such properties available is useful when attempting to develop
and valid
ate metrics to measure the quality of software architecture.


At the same time, it should be
kept in mind that these properties are still theoretical, and, as such, bound for further development,
analysis and refinement.

Briand, Morasca and Basili (2002)
d
evelop

a model to define measures
using

the Goal, Quality, Metric
(GQM) method. Their GQM/
Me
tric
D
efinition
A
pproach (GQM/MEDEA) is a guideline “to design and
reuse techni
cally sound and useful measures” that can provide a predictive measure of software qu
ality.
To validate their model and derived metrics, they apply the properties developed by Weyuker.
The high
level steps in their process they enumerate:

1.

Setting of the Empirical Study:

Measurement goals are refined from the objects based on the informatio
n provided by the
project teams

and

experience
; the processes and products that should be measured are
identified.

2.

Definition of Measures for the Independent Attributes:

Using sets of generic properties that characterize their measures, independent attribu
tes are
formalized. Abstractions are used to identify entities, independent attributes and generic
properties. Measures are defined or selected for the entity attributes.

3.

Definition of Measures for the Dependent Attributes:

Similar to step 2 but for the De
pendent Attributes, in the vernacular of experimental design, this
step and the previous step attempt to optimize the
construct

validity.

4.

Hypothesis Refinement and Verification:

Empirical hypothes
e
s are verified using the measures defined in steps 2 and 3,

and
ar
e refined
as required.

Briand, Morasca and Basili (2002) further state that t
he metrics and measures developed with this
technique are to be incorporated within the general architectural framework
that can be reused in later
projects
.
This implies

t
hat measures and metrics can be developed and integrated into the architectural
design framework
, reducing and possibly eliminating the need to define measures and metrics anew for
each application being developed
.


Briand, Daily and Wust (1999)
developed a facilitation
framework that: compares existing measures;
evaluates and empirically validates existing measures; and supports defining new measures and
selecting existing measures based on the goal of the measure.

Their method is specific to mea
surements
of
Coupling,

and ass
umes a high level of modularity.



In contrast, Chidamber and Kemerer (1994) develop
ed

a suite of metrics that can be applied to the
architectural design
, and

a
ll their metrics “satisfy the majority of properties prescribed by
Weyuker.”
The metrics, and especially explaining the mathematics behind the metrics, are beyond the scope of this
paper.

T
he GQM/MEDEA model developed by Briand, Morasca and Basili (2002) defines a
process to develop
metrics targeted to
measure

specific
ally selected

aspects of software
quality
.

T
he model allows for the
use of existing metrics such as those defined by Chidamber and Kemerer (1994),
as well as

those that
can be derived using the frameworks developed by Briand, Daily and Wust (1999)
,

and Bri
and, Daily and
Wust (1999). These
me
t
rics,
models and frameworks
base their validation on

Weyuker’s either directly
from Weyuker’s original study, or indirectly through the extended properties
developed by

Briand,
Morasca and Basili (1996)
.

Noting

that Wey
uker’s properties are a first attempt to formalize the properties that can be attributed
to well
-
defined and well
-
targeted measures and metrics,
they

likely have flaws in their modeling and
use. Given that, reviewing and refining these measures and metrics

not only should be expected but also
should be a standard practice in the architectural design and review processes.

With respect to game design, the discussion has demonstrated that increasing modularity of the game
enhances many of the key quality metri
cs for games, and
that methods
, guidelines and frameworks are
available
, or can be methodically developed,

to define metrics and measures
that

evaluate the
architectural design with respect to its modularity
, as well as
reasonably
validating the veracity o
f those
metrics and measures
.

Given an architectural design, deciding on the key quality attributes

to measure
is an important step in
ensuring the quality of the game design.
For example, a shrink
-
wrapped RPG is less likely to have
Security be a key concern, but more likely to have Testability
in the list
.

In a similar light, that same
shrink
-
wrapped RPG likely has
little
,

if no
,

requirement for maintenance upgrades, but a web
-
based,
multi
-
player version likely would
. Following this analysis of trade
-
offs and requirements, a set of key
attributes will be defined for the computer game being developed.

Because of the uniform structure of games within a given computer game genre, t
itles within a genre
would result in a nearly identical, if not identical, set of key quality attributes to be measured.
For the
purpose of game development, once this set of key quality attributes is defined, it can be reused for

future games of the same
genre, as well as feed into the architectural review.

Griman et al (2006) analyzed several architectural evaluation methods, “Architecture Tradeoff Analysis
Method” (ATAM), “Architectural Evaluation Method” (AEM) and “Design and Use of Software
Architectur
es” (DUSA), each had their strong points and weak points, and the authors sought to
determine the ideal method from their analysis.

Their analysis determined that ATAM had “the most complete and diverse evaluating team,” and, the
authors believed, was the
most precise of the methods analyzed because it applied scenario analysis.
DUSA, they found, might be costly when using the simulation technique, but was the only method


evaluated that guided the process “in order to improve the architecture through its tr
ansformation.” For
AEM, they state its main advantage is that it was modeled on th
e ISO/IEC 9126 quality standard.

The structure of game architecture and design is that the primary users of the product (game players)
are not only
not

part of the developmen
t team but, generally speaking, not a part of the company
producing the game software. Although it is possible that some game players might be invited to
participate in the development of a new game,
especially

in the testing phases, they generally do not
directly advise the development team on what makes a game good, or what features to include in a
game; this type of information is
typically

obtained using
marketing analysis or
analysis in the form
presented by Ip and Jacobs (2004).

These factors generall
y discourage the use of an architectural
evaluation method such as ATAM; the lack of the primary user’s participation limits the adaptability of
the method for game design and development.

As mentioned above, d
epending on the game genre, the requirements o
f the game are generally not
developed directly from the primary users of the product, the game players
. For some games, such as
chess,
backgammon

and the variety of other board
-
games
, a well
-
defined and known set of rules dictate
the play of the game, and
, as such, produce a set of requirements that likely
do not

vary significantly
between different companies that produce
those

games.
With the exception of cosmetics, the general
architecture of this genre of games can be evaluated using a
stricter

and

more

guided method such as
DUSA.

Other games, such as
the
RPG
s

that are
so

popular, possess a very high
-
level generic structure that does
not differ greatly within that genre and
within
the company

produc
ing

the game, but might vary
significantly between c
ompe
ting producers of the games. For example, one company that produces RPG
in a war scenario use a common generic structure for their product line; another company that also
produces RPG in a war scenario uses their own generic structure for their product lin
e, but the two
generic structures may greatly differ between the two companies.

In

that environment, to say one architectural evaluation method is better than another is like saying cats
are better than dogs

a discussion that tends to polarize even the
smallest of groups
.
Within that said
environment,

it
might

be better
, overall,

to defenestrate all architectural evaluation methods, and,
instead, use a framework such as ISO 9126 to model a custom method for the game or game genre
being designed.

Possibly

more than

most

other types of software development, computer games have
significant

potential for design and code reuse.
When a
dhering to the principles of modularization
, once the
modules are created for one game, for example, the
State
and
Bridge
patter
ns discussed earlier, those
patterns and that code can be reused to a large degree, if not completely, on future titles of that game
genre.


Modularizing, for example, the drivers for the game platforms a company produces games for can
simplify converting
a given title to the multiple platforms.
Assuming the module or modules supporting
the platform interface are loosely coupled from the rest of the game modules, and that module is highly
cohesive within its own structure, converting a
computer
game from, f
or example, “X
-
Box” to


“PlayStation” or vice versa, theoretically
could be
a simple matter of changing the platform interface
module.

Within a game genre, t
his
concept of
reuse extends
to

the
set of key quality attributes, to the
architectural design

and

t
o
the metrics defined to measure the effects on the
key

quality attributes.
When an architectural design is created for a game of a given genre (assuming the
game
platforms have
not changed measurably), this design will likely not change significantly betw
een titles within the same
genre that are produced by the same development team or company. What this means is, once an
architectural design is created, as well as the metrics associated with that design,
they

can be reused for
each subsequent title within

that genre.

Reusing the architectural design and associated metrics can save effort and resources when developing
multiple games within a genre, but blindly reusing without reviewing their appropriateness and value
may result in a reduction of quality. Ch
ange being the only constant, the assumptions and decisions
made for the previous compute game may not be consistent with the current

game
.

Additionally, the
models used for defining both metrics and architecture are imperfect which may cause inaccuracies
to
form in the defined metrics and architecture.

Under these circumstances, reviewing the architectural
design and metrics should be a standard process in the architectural design of a computer game.

Many, if not most, of the studies cited in this discussi
on analyzed object
-
oriented designs, but the
principles and results of those studies apply equally to modular designs of low coupling and high
cohesion. Conceptually, increasing modularity in a design, that is decreasing coupling and increasing
cohesion, i
ncreasingly approaches the object
-
oriented model; it might be safely said that a module of
0% coupling and 100% cohesion is, in face, an object
-
oriented module.






Summary

Although standards and metrics relative to the architecture and design of games is
still in its infancy
some practices stand
-
out as highly beneficial to the desire of producing high
-
quality game software.

Modularization provides a means to improve several quality attributes, and also increase the reusability
of the metrics, measures and
architectural design from one computer game to another.


Some
of the practices that

stand
-
out are
:



Modularize the Design
:

As demo
nstrated by Ampatzoglou and Chatzigeorgiou (2007), modularizing the design of a
computer game increases maintainability, compre
hensibility and cohesion, as well as reduces
complexity and coupling.



Develop Metrics to Measure Design and Software Quality
:

For a genre of computer games, decide on the key quality attributes to measure, and develop
the metrics to measure the quality o
f those attributes. Using models such as the GQM/MEDEA
developed by Briand, Morasca and Basili (2002), metric suites as developed by
Chidamber and
Kemerer (1994), and frameworks as developed by Briand, Daily and Wust (1999) can be used as
a basis for these

metrics, or in defining these metrics.



Reuse the Architectural Design, Metrics and Code
:

As indicated in the development of the GQM/MEDEA model, Briand, Morasca and Basili (2002)
indicate that these metrics and the associated architectural design can be r
eused.
Reuse reduces
replication of effort, and increases consistency within a computer game genre.



Review and Refine
:

Changes in circumstances the environment or virtually anything associated with game design
can invalidate the assumptions and choices mad
e in the development of the architectural design
and metrics. In addition, the bases of the previously defined
architectural design and metrics
have their inherent flaws which impact the accuracy of the artifacts.
With each new game
developed, review the

m
etrics and design to ensure they are still appropriate for the current
development effort, and refine them as needed.






Conclusion

Numerous studies on object
-
oriented designs demonstrate that modularization improves
the quality
attributes of maintainability, comprehensibility and extendibility, as well as making modification
easier
.
In addition

to these features
, the reusability of the metrics, measures and architectural design of a
compute
r game within a genre
increases so that other computer games within that genre can utilize the
same metrics, measures and design.

Several models and frameworks are available to enable the definitions of metrics and measures, as well
as properties defined for their validation. C
aution should be practiced when using these models,
frameworks and properties in that they are still theoretical, and, as such, the practice of reviewing and
refining the metrics and measures derived using the models should be incorporated in the architect
ural
design and review processes.

While deriving the metrics and measures, some thought should be made as to the appropriateness of
the metric or measure for the attributes being analyzed. For example, the use of the Lines Of Code (LOC)
metric for complexi
ty in an application with modules that have low coupling and high cohesion may
improperly increase the complexity measure of the application. This could be further analyzed in a
future study.





References


Ampatzoglou, Apostolos, and Alexander
Chatzigeorgiou. "Evaluation of Object
-
Oriented Design Patterns
in Game Development."
DTP Information & Software Technology

49.5 (2007): 445
.

Briand, Lionel C., John W. Daly, and Jürgen K. Wüst. "A Unified Framework for Coupling Measurement in
Object
-
Orien
ted Systems."
IEEE Transactions on Software Engineering

25.1 (1999).

Briand, Lionel C., Sandro Morasca, and Victor R. Basili. "An Operational Process for Goal
-
Driven
Definition of Measures."
ISO IEEE Transactions on Software Engineering

28.12 (2002): 1106
-
25.

Briand, Lionel C., Sandro Morasca, and Victor R. Basili.

"Property
-
Based Software Engineering
Measurement."
IEEE Transactions on Software Engineering

22.1 (1996).

Chidamber, Shyam R., and Chris F. Kemerer. "A Metrics Suite for Object Oriented Design
."
IEEE
Transactions on Software Engineering

20.6 (1994).

Chowdhury, I., M. Zulkernine, and Special Issue on Security and Dependability Assurance of Software
Architectures. "Using Complexity, Coupling, and Cohesion Metrics as Early Indicators of
Vulnerabi
lities."
Journal of Systems Architecture

57.3 (2011): 294
-
313
.

Griman, A., M. Perez, and L. Mendoza. "Feature Analysis for Architectural Evaluation Methods."
J Syst
Softw Journal of Systems and Software

79.6 (2006): 871
-
88.

Ip, B., and G. Jacobs. "Quanti
fying Game Design."
Design studies.

25.6 (2004): 607
-
24.

Sarkar, Santonu, Girish Maskeri Rama, and Avinash C. Kak. "API
-
Based and Information
-
Theoretic
Metrics for Measuring the Quality of Software Modularization."
IEEE Transactions on Software
Engineerin
g

33.1 (2007).



Taylor, M. J., Basket M., Hughes G.D, and Wade S.J. "Using Soft Systems Methodology for Computer
Game Design."
Systems research and behavioral science.

24.3 (2007): 359.

Weyuker, Elaine J. "Evaluating Software Complexity Measures."
IEEE Tra
nsactions on Software
Engineering

14.9 (1988).

Additional Reading

Dickey M.D. "World of Warcraft and the Impact of Game Culture and Play in an Undergraduate Game
Design Course."
Comput Educ Computers and Education

56.1 (2011): 200
-
9.

Dickey, Michele D. "Game Design Narrative for Learning: Appropriating Adventure Game Design
Narrative Devices and Techniques for the Design of Interactive Learning Environments."
Educational Technology Research and Development

54.3 (2006): 245
-
63.

Hummes, Jakob, and Bernard Merialdo. "Design of Extensible Component
-
Based Groupware."
Computer
Supported Cooperative Work

9.1 (2000): 53
-
74.

Schaefer, S., and J. Warren. "Teaching Computer Game Design and Construction."
Computer aided
design.

36.14 (2004
): 1501
-
10.

Sipper, M., et al. "Designing an Evolutionary Strategizing Machine for Game Playing and Beyond."
Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on

37.4 (2007):
583
-
93.