University of Southern California Dissertations and Theses

GSML: Game System Modeling Language—spatializing play structures and interaction flow

(USC Thesis Other)

GSML: Game System Modeling Language—spatializing play structures and interaction flow

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content !
!
!
!
GSML: Game System Modeling Language!
Spatializing play structures and interaction flow!
!
!
Richard Emms!
!
!
!
!
!
!
!
!
CTIN-594B: Master’s Thesis!
Professor Dennis Wixon, Simon Wiscombe, Yasser Malaika!
1 April 2014 
Emms " ! i
! Abstract!
The purpose of this research is to investigate game design practice in order to
define a language and methodology that can be used to improve game systems design.
Through our user research, we determined that game designers gain clarity about their
game systems from externalizing and reflecting upon their games’ mechanical
structures and flow. We call our resulting language and approach the Game System
Modeling Language (GSML). Our research has shown that GSML provides a practical,
novel perspective that assists game designers in analyzing and refining their game
systems independently of prototyping and player feedback.!
!
Emms " ! ii
! Acknowledgments!
This project is a research project instead of a production project. The USC
Interactive Media MFA thesis project is typically production-oriented and often focuses
on completing a deliverable product that is interactive in nature. It is thanks to the
support of my advisory committee, the Interactive Media and Games Division faculty
and staff, and my peers that I recognized that this research effort was a viable (and
welcome) option as a capstone project for the Interactive Media MFA degree. This
research could not have progressed so far without their input and willingness to get
involved with the hands-on research approach I required.!
I also give thanks to the members of my team: Alexander Mathew, Sanghee Oh,
and Yuting Su. Their individual skills and their insights into game design were
invaluable contributions to the success of the Game System Modeling Language. The
time they spent testing with our participants helped us gather our extensive set of
results, from which we could draw such compelling conclusions. 
Table of Contents!
Acknowledgments! i! .........................................................................................................................
Abstract! ii! ..........................................................................................................................................
Introduction! 1! ...................................................................................................................................
Initial Concept and Goals! 5! ............................................................................................................
Defining the Language! 7! .................................................................................................................
Characteristics of the Game System Modeling Language! 10! ....................................................
Refining the Diagram Creation Process! 16! ...................................................................................
Researching the Benefits of Using GSML! 21! ................................................................................
Conclusions and Future Plans! 27! ...................................................................................................
Appendices! 31! ..................................................................................................................................
References! 34! .....................................................................................................................................
!
Emms " ! 1
Richard Emms!
Professor Dennis Wixon, Simon Wiscombe, Yasser Malaika!
CTIN-594B: Master’s Thesis!
1 April 2014!
GSML: Game System Modeling Language!
Spatializing play structures and interaction flow!
!
1.! Introduction!
Game System Modeling Language (GSML) is a domain-specific visual language
and notation process that assists game designers in externalizing, analyzing, and
communicating their game system concepts. It provides designers these capabilities
without the use of a hands-on prototype or requiring prior art references. GSML
diagrams resemble system flowcharts, but take advantage of a specialized grammar
targeted towards game mechanics and interaction design.!
Research into games and interactivity has continued to gain momentum in recent
years with numerous investigations into game studies and reflections on the practice of
game design. I recognized that game systems were a part of the field that I was eager to
dive into and investigate deeply. Research into representing such systems and the
Emms " ! 2
benefits of such a model has been sparse thus far, particularly from the perspective of
game design.!
During the early stages of game design, designers often use intuition-based
approaches to define and improve their game concepts. Game designers often spend
time “observing, evaluating, and describing [their] own experiences” to help “make
rapid, decisive judgments about what is and is not working in [their games]”. (Schell
15) Designers using this approach run the risk of “building up structures of
questionable logic to back up something that feels like it must be true”. (Schell 15)!
According to my observations, a common approach for game design is to begin
with a brainstorm from a seed idea, iterate in a subjective manner, and later improve
their designs according to player feedback and metrics. Game designers’ understanding
of game systems is largely implicit, meaning that they maintain an internal model of
their game that is not externalized in an exact form. Different designers on the same
team may have different internal models of a game’s design and this can hinder
communication. This internal model is also often unstructured, particularly during the
early stages of the design process. This means that the relationships and associations
between the elements of their game systems are not clearly specified. This can diminish
the mutability of game systems because it is difficult to determine the outcomes of
Emms " ! 3
changes to unstructured systems.!
Designers’ typical methodology often does not involve attempting to examine
their game system structures in a formalized way. As a result, game designers tend to
envision their game systems in a concrete manner. This means that they run the risk of
conflating game system details with other unrelated characteristics of their game, such
as player experience, strategy, aesthetics, and implementation details. An example of the
process of examining a game system at an abstract level is to investigate only the
platforming elements and mechanics of “Super Mario Bros”. This involves insulating
game system elements from the other traits of the game that would add unnecessary
complexity to such a representation, such as what Mario looks like, how levels are
designed, how the player feels as play progresses, or even the fact that “Super Mario
Bros” is a digital game. My hypothesis is that the ability to isolate the abstract
mechanical elements of a game system should offer greater clarity when attempting to
understand how a game system operates.!
I propose that game system design can benefit from an analytical and precise
process. I believed that it would be worth spending the year exploring design practice
and attempting to understand how designers think. Such research could help define a
specialized process that assists designers in understanding their game systems, and
Emms " ! 4
could help them uncover solutions to design challenges they might not otherwise have
been able to address.!
As an interactive designer, I am most concerned with engaging other
practitioners on an intellectual level and providing a useful, practicable method that
benefits people in the field. This is why the majority of the research conducted has been
user-oriented: performed with designers in the midst of design and development.!
In the first semester of this project we directed our efforts towards converging on
an adequate methodology for externalizing and drafting game systems. In the second
semester we focused on refining the process so it was more palatable, and gathered
qualitative data to better understand how this language can affect design thinking.
Though our research is still ongoing, we have come to a number of intriguing interim
conclusions from our results. We intend to continue conducting user research in order to
discover new outcomes and further confirm our current conclusions.!
!
Emms " ! 5
2.! Initial Concept and Goals!
The initial impetus behind this thesis project was to investigate how game
designers think about the systems they create. From examining how game designers
mentally structure and contemplate their design concepts, how they carry out their
practice, and how they communicate their ideas to their team, we then postulated that
we may be able to define a vocabulary that allows designers to externalize their ideas in
a systematic and structured manner. Our hypothesis was that doing so would aid in
understanding a game’s high concept as well as its details, and that it could reveal
unexpected solutions to design challenges one might encounter.!
Game designers in the field regularly examine and modify their designs through
building prototypes and testing with players. This allows them to describe and model
their concepts in a hands-on way that closely reflects the play experience in action.
Known as the playcentric approach, prototyping both physically and digitally are ways
to understand “the actual game experience the players are having” and to receive
“instant feedback on what players think of the game”. (Fullerton 11)!
During brainstorming, internal prototyping is helpful in teasing out the details of
the game experience and facilitating communication of ideas between team members in
a subjective manner. Once the game concept is relatively clear, iterative prototyping and
Emms " ! 6
playtesting enable game designers to “analyze the end result [of their games] to refine
implementation, and analyze the implementation to refine the result” (Hunicke,
LeBlanc, and Zubek 1).!
Prototyping and playtesting are limited game system design methods in the
sense that they illuminate problems and solutions in reaction to feedback from users.
They are well-suited for determining the effectiveness of implemented design decisions
in relation to intended experience goals, as well as for balancing the details of game
systems. These processes allow designers to gather evaluative information to help
determine what changes that will generally lead towards an improved play experience.!
I postulated that, by examining an externalization of their game systems
independent of player feedback, designers would be able to proactively compose and
refine them. This could allow designers to make deliberate iterations on high-level,
qualitative sections of their concept such as mechanics and overall game flow. Having
such a representative artifact on hand could also enable more effective communication
between team members during the process of game design and development.!
!
Emms " ! 7
3.! Defining the Language!
A process of rapid scoping and clarifying goals early in our research led us to
attempt to define a domain-specific language for modeling game systems. Initial
investigation revealed that, at the time of writing, there is little formal research into the
methodologies used to externalize game systems during the design process. The subject
matter is mentioned in a number of resources, but not as a primary focus.!
“Game Design Workshop” dedicates a chapter to design documentation.
Flowcharting is described as a useful early technique to clarify the player experience in
parallel with creating wireframes and writing game design documents (Fullerton
400-401). “The Art of Game Design” briefly encourages designers to “write down what
[they] think the relationships are between the things [they] are balancing” (Schell 202).
The “MDA” approach uses multiple visual models to express its hypotheses. It
recognizes the value of defining models because they “help us describe gameplay
dynamics and mechanics” (Hunicke, LeBlanc, and Zubek 3).!
Our first studies concerned the formal specification of game systems. We
explored a number of methods for illustrating game systems on paper by attempting to
represent various parts of existing games. We began by broadly exploring different
models which could be used to represent game systems. We constructed conceptual
Emms " ! 8
hierarchies of the user experience, we sketched play moments through simple
conceptual paper prototypes, and we built relationship charts that categorized and
connected various formal and dramatic elements of play.!
The goal of our early experimentation was to discover a visual language suitable
for expressing interaction flow in games. We started with flowcharting because it is a
common method used in systems design to represent procedures and decisions in
sequential order. It is a useful step in the early phases of game design to define and
“map out all sorts of processes within [a] game” and communicate ideas to teammates.
(Fullerton 400)!
We recognized that a diagram that could accurately communicate a game system
to another designer is sufficient to completely express its interaction flow. We created
our initial charts by following a very loose procedure: diagram rules were arbitrary and
structure was left organic and ambiguous. Our first experiments involved drawing up
interaction flowcharts for selected games. These charts grew out of our personal
impression of the games’ systems. We then offered those diagrams to another team
member for them to use in the reconstruction of the selected game design. The
hypothetical games we created were remarkably similar to the originally chosen games.
We could immediately see the value of our methodology because the diagrams
Emms " ! 9
comprehensively communicated the original game’s systematic structure without
requiring further explanation.!
Initially, we were interested in defining a small taxonomy of game design
language that would help standardize communication between designers. Inspired by
“A Pattern Language” (Alexander, et al), we began by investigating patterns in game
design language. A number of resources exist covering this subject matter including
“Patterns in Game Design” (Bjork, Holopainen). However, we quickly discovered that
participants tended to use conventional terminology to describe commonly-found game
mechanics and devised their own phrasing to describe new, innovative, or specialized
mechanics. We heard concerns from designers that imposing a standardized vocabulary
might inhibit the creative process and consequently opted to integrate as much as
possible into our participants’ chosen terminology.!
We proceeded to map out a number of existing physical and digital games. We
determined that our flowcharting method and our chosen diagram elements were
appropriate for representing a diverse range of game genres and types. We then
categorized the elements of the diagrams as entities, verbs, and events.!
!
Emms " ! 10
4.! Characteristics of the Game System Modeling Language!
We made the decision to intentionally design GSML to be distinct from code-like
logic or typical systems architecture approaches used in software engineering. There are
already many techniques available that aid in procedural thinking such as pseudocode,
UML, and systems flowcharts. We intend to promote exploratory design-oriented
thinking.!
The basic components of a GSML diagram are elements, connections, and
annotations. Elements are nodes that represent different features exhibited in a game
system. Connections are lines that define relationships between elements. Elements and
connections have no semantic connotations with respect to play experience, aesthetics,
or narrative. They pertain solely to the game system’s operation.!
Annotations are optional, unrestricted additions to a diagram (whether they are
user-defined notes, images, icons, or special connection types) that designers can
include as reminders for case-specific characteristics.!
GSML diagrams are qualitative, atemporal diagrams that map out possibility
spaces through which a game system can navigate. They are qualitative in that, unlike
typical system models, quantities and variables are not an integral feature of this
language. They are atemporal in that non-consecutive connections do not have any
Emms " ! 11
temporal relationship at all, and consecutive connections merely imply a simplistic
sequence of cause and effect.!
The most important parts of a game system when represented in GSML are the
catalysts that elicit change (whether they are game events or condition checks) and their
cascading relationships to the rest of the game. As a result, GSML provides designers
with a new perspective on their ideas by illuminating the important high-level
moments and interdependencies of their game systems.!
Though GSML diagrams represent dependencies and relationships in a way that
is visually similar to a flowchart, all connections on the diagram represent only the
possibility of an occurrence or relationship. Thus, all connections into and out of a given
element are read in parallel. The possibilistic nature of GSML diagrams is fairly unique
to the language and allows designers to easily examine all of the relationships
connected to a particular object or occurrence in their game system.!
!
Emms " ! 12
" !
Fig. 1: GSML diagram of Tetris!
Emms " ! 13
The basic categories of elements in GSML are listed below:!
■ Entities are elements that represent the “things” in a game. Their characteristics
and relationships are characterized by the connections that lead out of them.!
■ Verbs are elements that represent procedures that the game system or the player
can perform.!
■ Events are elements that represent outcomes of the game system. They can be
used to delineate game states, define external influences on entities, or perform
condition checks.!
!
Entities are the atomic constructs of a game system. They represent the “things”
in a game. These can range from the concrete (e.g. player character) to the abstract (e.g.
time, score). Physical components of a board, card, tabletop, or physical game also
count as entities (e.g. cards, tokens). Attributes of “things” are also defined as entities
themselves (e.g. player health). Subclasses or variations of entities are included as
separate entities (e.g. a monster is distinct from a flying monster), though annotations
can be used to relate them or group them together.!
Entities are abstract constructs that do not contain attributes, relationships, or
behaviors. With this definition of an entity, the properties of a “thing” are represented
Emms " ! 14
only by its external interfaces into the rest of the system. This affords precision when
describing a “thing” because its qualities are made explicit by its connections, avoiding
the confusion which might occur if entities had implicit properties.!
For example, we often informally define the player character in a first-person
shooter as an object that receives player input in order to activate its abilities to move,
shoot, and jump. In GSML, the “player character” entity is merely a structural node that
binds together those inputs and abilities in a logical manner. The “player character”
entity itself does not contain those characteristics. Instead, “move”, “shoot”, and
“jump” are separated out as independent elements and are connected back to the
“player character” entity in the diagram.!
Verbs represent actions performed by the player or parts of the game system.
Typically, entities connect to their potential verbs, or events connect to their resulting
verbs. In terms of systems architecture, verbs are the equivalent of system processes and
procedures.!
Events represent outcomes of the game system. They can either be game states
(e.g. the card draw phase of a card game), occurrences that extrinsically affect an entity
(e.g. an enemy is killed), or they can be condition checks (e.g. has the player collided
with lava?). Events are more narrative than entities and verbs, and often include the
Emms " ! 15
name of the relevant entity and an associated occurrence. In contrast to flowchart
decision points, condition events do not have distinct Yes/No outputs, but inspect all
output connections simultaneously and may activate one or more of them.!
GSML’s connections link two elements together in a unidirectional manner and
are characterized by a small number of words. These connections form simple
fragmented sentences when read from the origin element to the destination element. For
example, in the previous Tetris diagram, one connection reads, “gravity pull moves
active piece”. Another connection reads, “active piece can cause collide with block”.!
Through our testing, we found that game designers initially had difficulty
isolating their game system and mechanics from other aspects of their game. Many of
our test participants would consider player experience, meaning, aesthetics, and/or
narrative alongside play mechanics and would begin to put such details as elements in
their diagram. As they continued the mapping process, all of our recent participants
concluded that such details did not belong in the diagram they were creating. They
would typically then remove them or include them as annotations to the diagram
instead. It was encouraging to us that the specialized purpose of the diagrams was
being communicated effectively by our included instructions and the nature of the
maps that our participants were creating.!
Emms " ! 16
5.! Refining the Diagram Creation Process!
Early on, we discovered through testing with users that building GSML
diagrams was cumbersome and mentally taxing. In the first semester when we made
the discovery, we were still focusing on how to make the language as broadly applicable
yet specifically expressive as we could. We noted the difficulties our participants had
with the process, and initially postulated that the solution would be the creation of a
digital tool to help with diagram creation.!
As we progressed, we recognized that the development of a tool for an unproven
language could ultimately prove inconsequential. We thus directed our attention in the
second semester to ensuring the process of diagram creation was straightforward and
comfortable for our users. We also conducted a more rigorous study to determine the
specific benefits that participants found from creating and analyzing their GSML
diagrams.!
Our current research approach in the second semester involves inviting selected
designers to create diagrams in person. We are using purposive sampling based upon
the potential designers’ game concepts and level of familiarity with GSML. We provide
pre-test surveys inquiring about the nature of their game concept, their prior design
process, and the challenges they currently wish to overcome (see section 8.1). We
Emms " ! 17
observe and take notes during the diagramming session and perform an interview
when it is complete. Afterwards, we provide them with a copy of their work and ask
them to complete a post-test survey.!
The post-test survey is partially comprised of the same questions as the pre-test
survey. This allows us to make a direct comparison between how they perceived their
design before and after using GSML. The survey also includes questions about GSML
itself, inquiring about how they understand the language, any challenges they
encountered, and any improvements they would suggest (see section 8.2). The surveys
have provided us with rich, case-specific data that has revealed a great deal about how
our participants work and how they attempt to design towards their experience goals.
The survey results have also shown us how GSML causes them to reorient their
thoughts and, often, come to terms with unexpected aspects of their game concept.!
We are still collecting results and we are in the process of collating our data. We
continue to adapt and iterate on the diagramming process to better meet the
requirements and preferences of our participants. We have seen some tangible
improvements over the course of this semester that each subsequent participant benefits
from. At the end of the first semester participants required between 90 minutes and 2
hours to complete a diagram, and were exhausted by the end. They also expressed
Emms " ! 18
uncertainty about whether they would want to go through the process again. Presently,
diagrams take between 30 and 90 minutes, without participants exhibiting any strong
signs of being heavily mentally taxed. Our recent participants have expressed great
satisfaction with the language and process overall and wish to continue using GSML
diagrams as they continue working on their projects.!
In order to realize these improvements, we modified a number of the steps
required to create a GSML diagram. Firstly, we have introduced an iterative step that
requires designers to create a first draft of their design before committing to the final
artifact. This draft is highly organic and tends to end up fairly complete but with an
unsatisfactory structure (see fig. 2). When finished, this iteration is archived and
completely erased. The participants then use the exact same elements from the draft to
build the final iteration, but now they have the opportunity to deliberately structure
their diagram in a way that is consistent with their understanding of their game (see fig.
3).!
!
Emms " ! 19
" !
Fig. 2: Initial draft of a GSML diagram of a game!
" !
Fig. 3: Final version of the diagram shown in fig. 2!
Emms " ! 20
We also noticed a pattern of behavior that led to a great amount of inefficiency
and unnecessary stress: categorizing elements by type (entity, verb, or event). This was
originally performed at the very beginning of the process when deciding on the
elements of the game. However, this caused a great deal of hesitation since almost all
test participants were completely unfamiliar with GSML during that stage of the
session. We now have participants categorize elements at the end of their first draft,
once they are familiar with the language and how it works. We found that this is well
timed, since the review and categorization of elements also aided participants in the
setup for the second iteration.!
Finally, labeling connections was an unexpected source of hesitation. Participants
would often spend some time thinking about how to label each connection and this
slowed down the process significantly. Once labeled, participants were very reluctant to
change the connections. This was a major barrier to the structural revisions that are
often necessary when drawing a GSML diagram!
We decided that connections should remain ambiguous and unlabeled in the first
iteration of the diagram. This way, designers characterized the connection labels
internally, giving them the same level of understanding as if they had written them
down. They only finalized them in the second iteration. This change helped designers
Emms " ! 21
map out their systems much more efficiently.!
It is worth noting that these changes all reflect the value of creating a draft and
the importance of being able to avoid committing to system details early in the process.
We found that this philosophy allows designers to “brain dump” their game systems
much faster, reducing stress and speeding up the process. Furthermore, it encourages
designers to more readily edit and revise their diagrams during creation.!
!
6.! Researching the Benefits of Using GSML!
The language and diagramming process have improved to the point where we
have tackled most of the major issues that we encountered in terms of expressiveness
and usability. We have begun to shift our focus towards gathering data and performing
analyses about the benefits of using GSML. The preliminary results reported by our
participants are promising and some of our initial conclusions are included below.!
Participants in the study found that they gained the new ability to isolate
portions of their game systems in a practical way. They found they could more easily
observe, reflect upon, and analyze their intended game structures and better
comprehend their interdependencies. This enabled them to recognize the strengths and
weaknesses of their game systems with more fidelity. Furthermore, they could better
Emms " ! 22
articulate how their games are composed and could make better informed judgments
about how to solve high level issues with their game concepts.!
One unique advantage to creating a GSML diagram is that it enables designers to
explore various levels of abstraction in their game systems. GSML does not inherently
restrict designers to any particular level of specificity, and allows designers to
summarize or detail out portions of their design as they see fit. Our results have
repeatedly shown that GSML is a self-regulating, purpose-oriented language when used
for understanding and problem solving during the design process. Our participants
have almost always ended up building their diagrams to a degree of specificity that
assisted them in solving their design issues.!
By examining the relationships between parts of their games at a more abstract
level, many of our participants were able to come to new conclusions and potential
solutions for the challenges they were facing. For example, one participant was able to
summarize his game concept into a simple diamond shape and immediately recognized
that the weaknesses of his game lay in one of the edges of that diamond. That prompted
him to look at that particular relationship in more detail and to brainstorm relevant
mechanics and connections that might balance out the shape and structure of his
system.!
Emms " ! 23
Our participants found that the use of GSML offered them greater confidence in
their decisions. Before creating their diagram, participants commonly described their
design process as highly subjective, exploratory and organic, and requiring iteration
through hands-on prototyping and implementation. After using GSML, many of our
participants were able to qualify in detail where the problem areas of their games were,
and said that they were better equipped to tackle those problems.!
One surprising result of using GSML during preproduction is that it encourages
certain designers to think about their game concepts in terms of communication and
public presentation much earlier than they typically would. The process forces
designers to finalize terminology at a stage where some had left names ambiguous. One
participant who made a GSML diagram of a game he made for a game jam noted that
the name of certain key elements of his game (for example, one of his player characters)
had remained unspecified throughout his game’s development process. He expressed
greater confidence in his ability to communicate about his design to his team and to
players as a result of deciding how to refer to these elements.!
We found that GSML also encourages designers to interrogate the less defined
sections of their games. Some designers believed they had thought through certain parts
of their games and considered those sections to be strengths. However, in some cases
Emms " ! 24
they found those section lacking in detail when they were faced with the task of naming
elements and drawing relevant connections. Creating the diagram helped them
recognize areas where more consideration was required before prototyping could begin.!
We discovered that there is a particular window of time during preproduction
and production where GSML diagrams are most useful. It is definitely possible to
attempt to create a diagram too early in the design process. One of our participants
brought in a particularly vague concept and attempted to use GSML to brainstorm a
more complete, detailed idea. He reported that he felt that he was making arbitrary
decisions and was unsatisfied with the resulting design. Other tests confirmed that
designers must at least have a solid idea of how the game functions before they will find
a GSML diagram useful. We found that the best results occurred when our participants
wanted to gain clarity and new insights into an existing idea.!
Perhaps one of the most unexpected outcomes of GSML diagrams is that it is
intuitively clear what is missing in the diagram. If there are subsystems that the
designer has not previously considered, they will very often notice the absence of these
elements and relationships and correct their diagrams accordingly. This implies that
GSML encourages a reflective process that helps make the implicit aspects of their game
systems explicit. Designers find that they begin with an incomplete specification and are
Emms " ! 25
able to apply a series of refinements that lead to a more complete specification.!
For example, two of our participants were collaborating on a diagram and found
that their game’s core loop was too poorly defined for the purposes of creating a
complete, satisfactory diagram. After observing their diagram. they recognized that the
loop was missing certain phases that were key to achieving their experience goals. They
rectified this problem by identifying the missing procedures, ordering them, and then
inserting them into the diagram.!
Participants who aimed for emotional, experiential, or meaning-based goals
found that their GSML diagrams do not formally include such information. These
designers still found the diagrams useful, as they allowed them to clarify their
subjective goals from the game systems they had planned. They could then reflect on
how effective the systems were at achieving those goals. We found that certain
designers were able to mentally associate certain larger structures in their diagrams
with the different subjective aspects of their intended play experience. It appears that
these diagrams can contain implicit cues that designers can use to analyze the
effectiveness of their design. Annotation has proven to be a helpful method to archive
these details and associations for later review. This is a very intriguing vector for future
research.!
Emms " ! 26
Finally, though our research has primarily been directed towards assisting game
designers, we also recognized that this methodology can be applied to the critical
analysis of games on a systematic level. We performed a small number of investigations
into modeling existing games and gained surprising clarity about the games we
examined.!
! The testing process is ongoing and further results are being gathered during this
final semester. Each test this semester has revealed more details about the benefits of
using GSML. They have helped us to define ways to modify the instructions to improve
the diagramming process and offered confirmation of past results and conclusions.
There is still much to be learned and continued testing is necessary to construct a more
complete understanding of this game design language and its applications.!
!
Emms " ! 27
7.! Conclusions and Future Plans!
We plan on conducting a few more user tests to confirm that the newer iterative
process for creating a diagram is a valuable change. Once our research nears
completion, we intend to begin building a publicly-accessible website with information
about GSML, instructions, case studies, and an archive of past diagrams. We have
chosen this approach over publishing a research paper as we wish to engage directly
with designers in the industry. Our aims with this project have always been to help
improve the game design process in the field and to assist designers in understanding
their game systems. This website will hopefully be a useful resource for game designers
looking to improve their practice.!
Over the course of this project we have identified a number of further research
topics using GSML which are worth investigating in the future.!
New insights may emerge from applying spatial analysis and graph theory to
GSML. We have already identified a few common spatial characteristics of GSML
diagrams. We have observed that related elements tend to cluster together. We also
found that many designers tend to intentionally create axes of meaning on their
diagrams. A vertical axis exists in the Tetris diagram included in this paper. Elements
which are further down the diagram are generally less directly affected by player
Emms " ! 28
control. Another example is the horizontal axis that is formed by placing two opposing
players on different sides of a diagram. An analysis of the interfaces between those two
players can be performed by examining the elements along the horizontal axis which
separate them.!
We found that GSML helps designers to determine the core parts of their games
by revealing the game elements that have the greatest amount of influence over the
game system. This can be performed by identifying the elements that have the most
connections in a diagram. More detailed analysis might be performed by applying
graph theoretical concepts to GSML diagrams. In future studies we may find that there
is a relationship between the number of incoming connections and how “core” an
element is to a design.!
As another example, we could count the number of connections in a path
between a player character and its related win state. This might reveal information such
as player-apparent game complexity and how much direct control a player has over
winning.!
Exploring common structural patterns or templates that arise from GSML, would
be a worthwhile and interesting methodology to examine game design practice. By
looking for commonalities between similar games (for example, within a genre) we
Emms " ! 29
might be able to determine standardized structures and shapes that can be reused as
template patterns. Even more intriguing is how these templates could be remixed
together or modified for the purposes of innovation and experimentation. This would
require significant long-term research into existing games.!
Finally, GSML has shown time and again that it is a valuable communication tool
between designers and their team members. It has exhibited the ability to introduce or
strengthen common terminology amongst game development teams. Without GSML.
this is often difficult to achieve without lengthy discussion, a representative prototype,
or prior game references. GSML has also been a useful collaboration tool when used by
more than one designer simultaneously. We could gain insights into how game
developers collaborate on systems design through further research into the
communicative properties of GSML.!
Our initial research demonstrated the necessity of describing structure when
analyzing game systems. We discovered that game designers begin with an implicit,
unstructured, and concrete conception of their games. As a result, they often have
difficulty applying inductive reasoning to iteratively improve their game systems
without prototyping and user feedback. This discovery led us to develop GSML, which
addresses these challenges by making game systems explicit, structured, and abstract.
Emms " ! 30
Our research so far shows that GSML allows designers to isolate and directly
manipulate abstract representations of game elements, enabling them to make rapid
revisions to their game systems.!
!
Emms " ! 31
8.! Appendices!
8.1! Appendix: Pre-Test Survey Questions!
Maximum 250 word answers.!
1. Describe your game concept.!
2. Describe the strengths of your design.!
3. Describe the weaknesses of your design.!
4. Rate on a scale 1-5, the level of completion of your design. (1 very incomplete, 5 very
complete)!
5. Describe briefly what led you to give your previous rating.!
6. Outline your game design process up to this point.!
7. List and briefly describe design challenges you have previously solved.!
8. Describe the methods you used to solve the challenges you outlined in the previous
question.!
9. Rate on a scale 1-5, the difficulty of the design challenges you are currently facing. (1
very easy, 5 very difficult)!
10. Describe briefly what led you to give your previous rating.!
11. List and briefly describe these challenges.!
!
Emms " ! 32
8.2! Appendix: Post-Test Survey Questions!
Maximum 250 word answers.!
1. Describe your game concept.!
2. Describe the strengths of your design.!
3. Describe the weaknesses of your design.!
4. Rate on a scale 1-5, the level of completion of your design. (1 very incomplete, 5 very
complete)!
5. List and describe the currently unsolved challenges in your design.!
6. Rate on a scale 1-5, the difficulty of the design challenges you are currently facing. (1
very easy, 5 very difficult)!
7. Describe briefly what led you to give your previous rating.!
8. How would you describe the GSML system to another designer?!
9. Describe the impact of using GSML on your game concept or design.!
10. Describe your experiences with using GSML.!
11. Rate on a scale 1-5, your level of satisfaction with the GSML notation system. (1 very
dissatisfied, 5 very satisfied)!
12. Describe briefly what led to your previous rating.!
!
Emms " ! 33
13. List and describe any specific changes you would make to your design as a result of
using this process.!
14. Describe any challenges you faced while using GSML.!
15. Describe any improvements you would suggest for the GSML language/procedure.!
16. Would you use GSML again? Why or why not?!
!
Emms " ! 34
9.! References!
Schell, Jesse. The Art of Game Design: A Book of Lenses. Amsterdam: Elsevier/Morgan
Kaufmann, 2008. Print.!
Fullerton, Tracy, Christopher Swain, and Steven Hoffman. Game Design Workshop: A
Playcentric Approach to Creating Innovative Games. Amsterdam: Elsevier Morgan
Kaufmann, 2008. Print.!
Hunicke, Robin, Marc LeBlanc, and Robert Zubek. MDA: A Formal Approach to Game
Design and Game Research. Proceedings of the AAAI-04 Workshop on Challenges
in Game AI. July 2004. Web. 9 August 2013.!
Alexander, Christopher, Sara Ishikawa, and Murray Silverstein. A Pattern Language:
Towns, Buildings, Construction. New York: Oxford UP , 1977. Print.!
Bjork, Staffan, and Jussi Holopainen. Patterns in Game Design. Hingham, MA: Charles
River Media, 2005. Print.!

Abstract (if available)

Abstract The purpose of this research is to investigate game design practice in order to deﬁne a language and methodology that can be used to improve game systems design. Through our user research, we determined that game designers gain clarity about their game systems from externalizing and reﬂecting upon their games' mechanical structures and ﬂow. We call our resulting language and approach the Game System Modeling Language (GSML). Our research has shown that GSML provides a practical, novel perspective that assists game designers in analyzing and reﬁning their game systems independently of prototyping and player feedback.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Fall from Grace: an experiment in understanding and challenging player beliefs through games

PDF

Players play: extending the lexicon of games and designing for player interaction

PDF

Aesthetic driven design of Space Maestro

PDF

Ascension: an analysis of game design for speech recognition system usage and spatialized audio for virtual reality

PDF

Manjusaka

PDF

The Toymaker’s Bequest: a defense of narrative‐centric game design

PDF

FRKN WKND and video game mixtapes: developing talent and experience through video game mixtapes

PDF

The future of games and health: towards responsible interaction design

PDF

The Toymaker's Bequest

PDF

Reality ends here: environmental game design and participatory spectacle

PDF

Exit

PDF

Day[9]TV: How interactive Web television parallels game design

PDF

Life On A String: an ink painting narrative game

PDF

The Distance: a cooperative communication game to long-distance players

PDF

Wetware: designing for a contemporary dilemma

PDF

Your presence is present enough: a thesis project postpartum

PDF

The Death Mask: a study in interactive mystery

PDF

Moloch: creating games with alternative mental state goals to move beyond flow

PDF

Kinesthesia: a multi-sensory gesture driven playground of the future

PDF

On the shoulders of giants

Asset Metadata

Creator Emms, Richard (author)

Core Title GSML: Game System Modeling Language—spatializing play structures and interaction flow

School School of Cinematic Arts

Degree Master of Fine Arts

Degree Program Interactive Media

Publication Date 04/23/2014

Defense Date 04/18/2014

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag analysis,charts,computer games,design,diagrams,flowcharts,game design,game development,game systems,Games,GSML,interaction,iteration,Language,mechanics,Modeling,OAI-PMH Harvest,Play,prototyping,spatial analysis,structural analysis,systems,video games,visual language

Format application/pdf (imt)

Language English

Contributor Electronically uploaded by the author (provenance)

Advisor Wixon, Dennis (committee chair), Malaika, Yasser (committee member), Wiscombe, Simon (committee member)

Creator Email richard.emms@gmail.com

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c3-383101

Unique identifier UC11296573

Identifier etd-EmmsRichar-2405.pdf (filename),usctheses-c3-383101 (legacy record id)

Legacy Identifier etd-EmmsRichar-2405.pdf

Dmrecord 383101

Document Type Thesis

Format application/pdf (imt)

Rights Emms, Richard

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA