Peering Into the Blackbox the Role of Digital Game

PEERING INTO THE BLACKBOX

THE ROLE OF DIGITAL GAME DEVELOPMENT IN GAME STUDIES

Luke Skye Bernfeld

APPROVED BY SUPERVISORY COMMITTEE:

______Monica Evans, Chair

______Timothy Christopher

______Kim Knight

______Roger Malina

Luke Skye Bernfeld

PEERING INTO THE BLACKBOX

THE ROLE OF DIGITAL GAME DEVELOPMENT IN GAME STUDIES

LUKE SKYE BERNFELD, BS, MA

DISSERTATION

Presented to the Faculty of

The University of Texas at Dallas

in Partial Fulfillment

of the Requirements

for the Degree of

DOCTOR OF PHILOSOPHY IN

ARTS, TECHNOLOGY, AND EMERGING COMMUNICATIONS

THE UNIVERSITY OF TEXAS AT DALLAS

December 2020

ACKNOWLEDGMENTS

I would like to acknowledge and express my gratitude to the many individuals who assisted me in this journey. Thanks to Dr. Monica Evans for being a mentor through my graduate program and for guiding me through the dissertation process. Thanks to Dr. Tim Christopher for helping me to learn how to develop digital games and helping to fine-tune my digital game for this dissertation. Thanks to Dr. Kim Knight for helping me see things from a different perspective and broadening my outlook on digital games. Thanks to Dr. Roger Malina for giving me great ideas to examine and for helping me to think about the side effects of my ideas. Thanks to Dr.

Oliva Banner and Dr. Josef Nguyen for helping me to find my focus. Thanks to Dr. Deb

Thornton, Professor of English at Utah Valley University, who helped me learn how to listen to myself and write it down.

I must acknowledge my wife, Liz Bernfeld, without whom I would not be here. Her faith and love kept me going when it was most difficult. Thanks to Eric Shad Miller and Stephen Mallory for all the time they devoted to editing this work. Thanks to Eva Wamsley for being a great mother and mentor in my academic pursuits. Thanks to Roger Shirley, Becky Ryser, and Katie

Apker for being editors and helpers in this process.

September 2020

PEERING INTO THE BLACKBOX

THE ROLE OF DIGITAL GAME DEVELOPMENT IN GAME STUDIES

Luke Bernfeld, PhD The University of Texas at Dallas, 2020

ABSTRACT

Supervising Professor: Monica Evans

Digital game development is a critical tool in game studies due to its ability to communicate and its academic value as a mode of understanding the medium. Understanding digital game development and gaining some appreciation of the complexities of development, whether by direct development experience or indirect observation of the process, must be a goal for game studies scholars. Blackboxing, according to Bruno Latour, is when a machine or process runs so efficiently that no one bothers to examine it (Latour, Pandora's Hope: Essays on The Reality of

Science Studies, 1986). While this is the goal of any good developer, game studies scholars should seek to look within the black box and understand development. Digital game scholars should understand the fundamentals of digital game development.

In my work, I have reviewed the existing literature produced by game studies scholars related to the process of development to explore the ways that scholars have discussed and utilized development. I also examined ways that developers write about and approach digital game development exploring how these related to game scholarship. I studied a strong example of digital game development in scholarship by approaching the text Metagaming, which utilizes

development at the end of each chapter. I examined the game Doki Doki Literature Club to further explore how development and development tools are used in the process of play, considering the ways that development itself can become a tool. I then explore The Art of Failure to examine the game developed in collaboration with Jesper Juul to see the benefits of collaborative development. I look at the games Super Meat Boy and Stardew Valley as examples of small team and solo development to better understand how scholars can utilize these development methodologies. I then used the methods of solo development and made a game. I documented the process of developing Game Lab Sim extensively to explore further scholarly development.

This work contributes to the growing body of literature approaching digital games as scholarly artifacts. It is the intent of this work to call to game studies scholars to open the black box and engage with the act of digital game development. This work does not intend to engage with other fields or act as a tool of gatekeeping; instead, it is the intention of this work to interact with game studies scholars and development scholars. This work recommends that scholars actively engage with and study the development process.

TABLE OF CONTENTS

ACKNOWLEDGMENTS…………………………………………………………….………….iv

ABSTRACT……………………………………………………………………………….….…..v

LIST OF FIGURES……………………………………………………………….……….……..ix

CHAPTER 1 INTRODUCTION ...... 1 1.1 Summary ...... 7

CHAPTER 2 SCHOLARS DISCUSSING DEVELOPMENT...... 14 2.1 State of the Field ...... 16 2.2 Scholars Discussing Development ...... 27 2.3 Conclusion ...... 34

CHAPTER 3 DEVELOPERS DISCUSSING DEVELOPMENT ...... 40 3.1 State of the Art ...... 41 3.2 Game Engines and Gamified Engines ...... 48 3.3 Conclusion ...... 59

CHAPTER 4 SCHOLARLY DEVELOPMENT IN METAGAMING ...... 64 4.1 Memento Mortem Mortis ...... 68 4.2 Triforce ...... 70 4.3 99 Exercises in Play ...... 73 4.4 Significance to the Field ...... 75 4.5 Conclusion ...... 78

CHAPTER 5 PLAYING WITH DEVELOPMENT TOOLS IN DOKI DOKI LITERATURE CLUB AND DREAMS...... 82 5.1 Doki Doki Literature Club ...... 82 5.2 Dreams ...... 90 5.3 Conclusion ...... 93

CHAPTER 6 COLLABORATIVE DEVELOPMENT IN THE ART OF FAILURE ...... 99 6.1 The Art of Failure ...... 99

vii

6.2 The Suicide Game ...... 103 6.3 Conclusion ...... 107

CHAPTER 7 METHODS AND PRACTICES FROM SOLO AND SMALL TEAM DEVELOPMENT ...... 112 7.1 Stardew Valley/ Solo Development ...... 112 7.2 Super Meat Boy/ Small Team Development ...... 121 7.3 Conclusion ...... 123

CHAPTER 8 DOCUMENTING SCHOLARLY GAME DEVELOPMENT ...... 125 8.1 Pre-Production ...... 126 8.2 Production ...... 134 8.3 Analysis of Development Practice ...... 143 8.4 Conclusion ...... 144

CHAPTER 9 CONCLUSION ...... 147

APPENDIX A GAME DESIGN DOCUMENT ...... 154

APPENDIX B CODE REFERENCE ...... 172 BIBLIOGRAPHY………………………………………………………………………………184

BIOGRAPHICAL SKETCH ...... 192

CURRICULUM VITAE ...... 193

viii

LIST OF FIGURES

Figure 1. Memento Mortem Mortis ...... 68

Figure 2. Triforce ...... 70

Figure 3. Triforce Fire Rate ...... 71

Figure 4. 99 Exercises in Play ...... 73

Figure 5. Doki Doki Literature Club...... 84

Figure 6. Doki Doki Literature Club Traumatic ...... 84

Figure 7. Dreams Code ...... 92

Figure 8. Flow Chart ...... 125

Figure 9. UI Sample ...... 126

Figure 10. Game Dev Tycoon ...... 127

Figure 11. Focus Edited ...... 131

Figure 12. Focus...... 131

Figure 13. Grant Edited...... 131

Figure 14. Grant ...... 131

Figure 15. Student Edited ...... 131

Figure 16. Student ...... 131

Figure 17. Topic Edited ...... 132

Figure 18. Topic ...... 132

Figure 19. Equipment...... 132

Figure 20. Equipment Edited ...... 132

Figure 21. Computer and Chair ...... 135

Figure 22. Start Button ...... 135

Figure 23. Student ...... 135

Figure 24. Student Info ...... 137

Figure 25. Grant Info ...... 140

Figure 26. Flow Chart Design Doc…………………………………………………………...... 157

Figure 27. Level Design………………………………………………………………………...165

Figure 28. Interaction…………………………………………………………………………...166

Figure 29. UI Game Dev Tycoon……………………………………………………………….168

Figure 30. UI Game Dev Story…………………………………………………………………168

Figure 31. Super Mario Bros. ………………………………………………………………….169

Figure 32. UI Mockup Design Document……………………………………………………...170

CHAPTER 1

INTRODUCTION

This work will demonstrate the clear need for scholars to examine digital game development and peer into the black box. Key aspects of this process are play and development.

These processes are significant to game studies scholarship and development. Game studies scholars have addressed the importance of play in many works, like Meta Gaming, Cybertext,

Persuasive Games, and many others (Aarseth, Bogost, Boluk and LeMieux, Murray). Scholars have focused, to a lesser degree, on digital game development as an object of study, means of communication, and creative process. The scholarly focus on production and interaction is not unique to the field of game studies. Film studies scholars must gain an understanding of the significance of stylistic aspects such as camera angle and film type, while literary scholars understand the significance of prose and meter. Given the importance of game development in play and production, it follows that the practice of development would be a critical point of discourse to the game studies space. Some scholarly works examine the uses of digital game development tools as academically worthwhile, but surprisingly few works consider digital game development practice as academically worthwhile.

Digital game development, as I define it, is the development of games by individuals who understand the melding of different aspects, such as code, visuals, and sound. Play, as defined by

Michael Nitsche, is the mediated interaction between a player and a game (Nitsche 15-16). While these definitions are not perfect, they are sufficient for the work performed in this dissertation.

Play is vital within digital game development; developers participate in a cycle of playing existing games, developing games, and playing their incomplete games. The interchange

between play and development is vital to the creation of new kinds of games as well as new ways of playing those games. As such, play is an integral part of the development process.

Digital game development is an area of study which needs further exploration, given its significance in the production and consumption of the medium. Early game studies scholars set the stage for this line of inquiry by suggesting a need to analyze games along multiple dimensions. Janet Murray, in her work Hamlet on the Holodeck, discusses the narrative capacity of digital games and media. Murray points to the ways that development of narrative is a part of the creative development process of making a digital game (Murray 38). Espen Aarseth is another early scholar in the field of digital game studies, which points to the importance of exploring development as an object of study. Aarseth, in his work Cybertext, suggests how humans and computers act as the author of digital texts. Aarseth points to a machine-human continuum that enables the existence of digital games (Aarseth 134-135). These authors began the discussion on the role of development in digital game analysis.

More recent work within the field of game studies promotes recognition of the importance of digital game development. As a part of this discourse, some scholars focus on the procedural aspects of human-computer interaction. Ian Bogost, in his work Unit Operations, discusses the ways that code and hardware interact to generate media interfaces. Bogost suggests that the focus of game analysis should be on “unit analysis,” a procedural approach to the converging of source code and machine (Bogost, Unit Operations 15). Similarly, Michael

Nitsche, in his book Video Game Spaces, suggests that more than the interface should be the focus of digital game studies. Nitsche advances the idea that digital games occur on five planes: rule-based, mediated, fictional, play, and social (Nitsche 15). The rule-based computational

system facilitates the interaction between the player and the screen. Nitsche also points to the need for analysis of these planes in total and not just the mediated plane (Nitsche 15). Alexander

Galloway, in his work The Interface Effect, more generally points to the ways that the interface becomes foregrounded to the exclusion of other aspects of media (Galloway 59). Galloway’s work builds upon that of Bogost and Nitsche in that they call for a more in-depth analysis of the technical aspects of media and a closer examination of the various planes of interaction.

Other scholars point to the need to expand the examination of digital games beyond play alone. Scholars like Steven E. Jones, in The Meaning of Video Games, discuss how production is part of what constitutes a digital game. Jones frames approaching digital games not as hermetically-sealed objects devoid of production and marketing, but as media with rich connections to the world around them (Jones 6). Jones asserts that digital games are products of their social contexts and that the process by which digital games are made should be a subject for further work. Robert F. Nideffer, in “Game Engines as Creative Frameworks,” discusses the ways that digital game engines can be artifacts for academic analysis (Nideffer 3). Like Jones,

Nideffer argues that digital game scholarship should include a focus on more than play, and instead examine more closely the means of digital game production. Nideffer argues that digital game engines should be considered artifacts as much as the games that they are used to produce.

The game engine is more than just a piece of software for Nideffer; it is a unique artifact embedded in the culture which created it. In Miguel Sicart’s article, “Against Procedurally,” he addresses how scholars treat digital games as if they exist in a vacuum, absent the systems (both technical and social) that create them (Sicart 13-14). Sicart, much like Nideffer and Jones, makes the point that digital games are much more than the procedures and coding that generate the

interface. Instead, digital games are a collection of many aspects of development. However, most of these scholars (except for Nideffer) discuss development in an ancillary fashion.

In addition to works by scholars who approach digital game development as a cultural artifact, or as an object generated by code and computational machines, some approach the process of creating digital games. One example of this approach is in Jesse Schell’s work, The

Art of Game Design: A Book of Lenses. In his work Schell focuses on teaching the process of digital game development (Schell 2-4). Several other works explore this aspect of digital game development. While texts like this are becoming common, they tend to remove the process of development from the social and technological realities that inform digital game development.

Although there has been an increase in scholarship about development, fewer use the act of development as a research method or rhetorical tool in their works to support their analyses. This work seeks to discover the various ways that scholarship can be affected by the inclusion of game development practice. It also seeks to illuminate how crucial digital game development is to digital game scholarship and how, when combining the two, there is a potential benefit to scholars.

Game studies as a field encompass games as a whole; this includes both analog and digital game types. It is important to note that for this work, the focus will be on scholarship and production of digital games exclusively. This focus provides a feasible scope and reflects the ubiquitous nature of digital games, and does not discount the importance of analog games.

Analog game development and its use in scholarship is a worthwhile pursuit; however, to cover both analog and digital games in this dissertation would be disadvantageous to one or the other.

Additionally, the issue of availability and ubiquity makes digital games a more reliable choice for the analysis of scholarship on game development.

In addition to limiting scope to digital games, this work will also limit the scope of case studies to scholarly and independent developers. These case studies provide different lenses to developer motivation while maintaining similar team sizes. The primary issue with attempting to examine large-scale production documents directly, and how they are similar and different from the writing of scholars, comes down to availability. While Scholars tend to make their process and writing publicly available, large digital game studios typically attempt to keep all in-house documents concealed. The most significant reason for the lack of publicly available documentation from studios is that these documents represent proprietary information that could cost the companies’ money if released to the general public. Independent developers, however, tend to make more of their process available to the public at large and are more open to direct questions about their process. For these reasons, this work will limit the scope of the study to scholarly and independent developers.

This research will employ qualitative methodologies that place practices of development in a Humanities framework that values context, theory, and history. Beginning with a lit review that explores the works in the field of game studies concentrating on those that speak to the development of digital games. Seeking especially places where the scholarship converges and diverges additionally examining works by developers, centering on scholarly development as well as independent game development. These reviews then generate a need for further examination of individual works, like Metagaming by Stephanie Boluk and Patrick LeMieux.

This work will also examine the digital games produced by the authors to further their scholarly work.

Further examining independent works like Doki Doki Literature Club, which provide an opportunity to examine how development practice can fold into a game narrative. Then focusing on Jesper Juul’s work The Art of Failure and the game created by Albert Dang and Kan Yang Li in conjunction with that work. Examining the methods used in the development of Suicide Game produced by Juul, Dang, and Li, which also provides the opportunity to examine collaborative development. I will explore Stardew Valley and Super Meat Boy, providing a look into the solo development process as well as small team development. Additionally, Stardew Valley and Super

Meat Boy provide a unique abundance of development documentation, granting the opportunity to explore differences in methods between independent developers and scholarly developers.

The examination of these different development methodologies and their role in game studies will extend the work of scholars such as Bogost, Jones, Sicart, Nitsche, and others. Finally, I will produce a game as an examination of documentation methods as well as solo development practices.

I will use several creative practice methods to examine how I develop the digital game portion of my work. For the game itself, I will use Game Maker Studio 2. This way, I will be able to perform development as a solo developer. I am familiar with the development tools found in Game Maker Studio 2 and should be able to develop the digital game at a decent pace. More importantly, my familiarity with all the tools will mean that I can develop the game portion of this work solo, thereby being able to examine the practice of solo development and to explore whether or not that is best for scholars.

This work will seek to demonstrate that there is a need within digital game scholarship to examine the potential of digital game development as a means to understand the medium with more exceptional lucidity. Besides, a better understanding of digital game development can only aid in removing the negative effects of screen essentialism and blackboxing. While good software and games should seek to achieve a black-box effect where the user does not think about the hardware and code making the game function, scholars must look into the black box and gain an understanding of its internal mechanisms.

It appears evident that digital game development is essential for game studies as a whole.

However, this work will explore the idea that digital game development is core to all game studies endeavors. Also, to examine further the point scholars gain benefits from digital game development. This work seeks to demonstrate that these benefits are far-reaching and attained by making minimal alterations to the preexisting methods for digital game studies.

1.1 Summary

Chapter 1 will show that several scholars call for additional exploration of digital games outside of the finished artifact. However, even these scholars shy away from addressing digital game development directly. Sicart, in his work, “Against Procedurality,” explains that digital games are more than the hardware and code that make them, and player agency is a crucial factor of play (Sicart 13-14). Sicart also points to the need for exploration of the development process; however, that investigation should not remove the importance of the player (Sicart 5-6). In their work, Metagaming, Boluk, and LeMieux discuss the ways that all digital games are metagames.

In the introduction, Boluk and Lemieux touch on the ways that development is a part of digital games (Boluk and LeMieux 4-5). They also state that digital games need to be approached more broadly by scholars (Boluk and LeMieux 6-8). In Ian Bogost’s work, Unit Operations, he stipulates that scholars should examine the code of a digital game. For Bogost, the best way to explore the connections between works was to explore the most basic unit of that work. In the case of digital games, he believed that this was code (Bogost 13-15).

The lack of interest that scholars have in exploring development further points to the issues discussed by both Kirschenbaum and Galloway. Kirschenbaum does not speak to digital game development or Game Studies directly. He does illuminate issues within screen essentialism and black-boxing of technology, problems which converge with digital game development, and its lack of prominence within scholarship (Kirschenbaum xi-xii). Alexander

Galloway, in his work, The Interface Effect, more generally points to the ways that the interface becomes elevated above other aspects of media (Galloway 59). These works are essential in that they demonstrate some of the pitfalls into which scholars can stumble when approaching digital media, including games. Scholars who do not take into account the physical nature of the digital further promote black boxing and screen essentialism. The scholars that take the time to recognize the developed nature of digital games take a step toward removing the black-box from technology.

The second chapter will focus on the documentation of development. In particular, developers themselves write about the development process. This idea was prefaced by looking at Eric Steven Raymond’s work, “The Cathedral and the Bazaar,” where he illustrates the differences between open development practices and closed practices, as well as the benefits and

drawbacks to each method. The Bazaar methodology includes opening the development of software up to the community to share all assets and allowing the community to aid in the process by coding and producing assets (Raymond 1-2). The Cathedral methodology is a closed system and frequently used in corporate situations. In this methodology, everything stays within the company, and the community is uninvolved with the development process. Typically this method is employed to protect the intellectual property (IP) of the developer.

Raymond discusses the Bazaar style of development and how including the user base in the process improves the overall product, as Raymond puts it, “Treating your users as co- developers is your least-hassle route to rapid code improvement and effective debugging”

(Raymond 6). Additionally, Raymond points to the need for frequent versions of the software to maintain user engagement with the project (Raymond 8). Raymond contends that the Bazaar method is a valid method for digital development, provided that the individual managing the workload is capable of organizing the volunteer coders (Raymond 25). Raymond’s work establishes what I assert should be the method of all scholarly developers, which is to be as open as possible and share the development process with other scholars. Improving the project and exploring further the scholarship presented in the digital game. Additionally, this philosophy aids in the creation of a criterion for exclusion when it comes to digital games featured in this work.

If the developers were unwilling to publicly discuss their development process, it made little sense to include their work in this research.

Another work that was important to the exploration of digital game development was

Casey O'Donnell’s work, Developer’s Dilemma. In his book, O’Donnell discusses the importance of language and terminology within the development of social hierarchy. “Language

is a precursor to many of the other barriers to entry or ‘secrets’ of the game industry” (O’Donnell

41). Digital game development is surrounded by terms that enable developers to communicate with one another. These terms also serve as a gatekeeping methodology to denote those that have authority within the space (O'Donnell 41-42). Language, in particular, is essential for the digital game scholarship field. As discussed in the chapter, the language used by developers is specialized, and so is commonly found in the documents produced by developers within the games industry. What is important to realize is that if a scholar does not know or is not familiar with this language, then their exploration of the development of digital games can suffer as a result.

Chapter 3 will examine Metagaming and its potential impact on the field. Metagaming is a proof of concept that digital game development can help with communication within the Game

Studies field. What it does not do is explore how digital game development can aid in the performance of Game Studies. At the time of this writing, there is no scholarly work that explores the ways that digital game development can be a tool for Game Studies scholarship.

Metagaming demonstrates that digital game development is key to the future of Game Studies.

The games that Boluk and LeMieux developed for their work act as a critical component of their scholarship. Game Studies ought to begin to utilize the availability of development tools and the decreasing barrier to entry when it comes to those tools as a means of research and communication. This development occurs in the field to develop new ways of communicating ideas and new means of understanding the digital game medium. It is crucial to Game Studies that works like Metagaming be explored, not only as a written academic artifact but also as a digital game artifact. As more scholars utilize development tools in their scholarly work, Game

Studies as a field should take notice of the ways digital game development can support scholarship.

In Chapter 4, this work will explore Doki Doki Literature Club and Dreams, both of which combine play and development, creating unique experiences. Doki Doki asks its players to be familiar with the computational side of digital games. The volume of narrative hidden behind code and other development tools and practices is virtually unheard of in the digital game space.

The depth of narrative integration between game and developmental practice provides an example of how digital games can focus on the computational nature of the digital medium.

When the game hides narrative in a log file or code, it pushes the player to get tools to decipher the code being presented. Dreams requires players to create their games using a gamified engine.

Dreams allows players to do everything from model creation to animation and voiceover work.

Games like Doki Doki Literature Club and Dreams act to demythologize digital game development. When players and scholars interact with games like these, they begin to understand how digital games are made and thereby start to see past the black-boxing. The player sees past the interface into the structure of the game, reducing the adverse effects of both black-boxing and screen essentialism.

Chapter 5 will examine the work of Jesper Juul. The Art of Failure features a game created by Albert Dang and Kan Yang Li, which utilizes gameplay to demonstrate, through interaction, the points made by Juul in his work. The Art of Failure focuses on the role of failure in digital games. Juul argues that failure is the defining characteristic of digital games since failure is a planned state in digital games. No other medium plans for those interacting with it to fail (Juul 69-70). This chapter served to function as an example that digital game scholars do not

need to be the individuals that developed the game as long as they are aware of the process. They can then point to how that process is accomplished and therefore continue the effort of demystifying the space between game interface and the hardware. While not as effective as the works by Boluk and LeMieux at communicating with the audience, Juul’s game does provide a beneficial proof of concept.

Chapter 6 will focus on the methods of development, which made the most sense for digital game scholars; solo and small team development. In terms of scholarly digital game development, solo development like that of Stardew Valley presents the opportunity for scholars to have complete control over their projects. This type of development allows for a more precise line of communication between the scholar's work and the game developed to support that work.

Small team development, on the other hand, as in the case of Super Meat Boy, provides some benefits not found in solo development. Super Meat Boy by Team Meat, a small team, made up of Edmund McMillen and Tommy Refenes. A similarity between small team development and solo development is that changes can be made to the game rapidly, and the vision of the final product altered to fit the designers’ vision. The critical difference between these styles of development is small team developers run ideas by their teammates and get immediate feedback.

Small team development also tends to cut down on development time, since development responsibilities are shared. Additionally, there is greater accountability for time spent developing in a small team. In terms of scholarly development, these two methodologies seem to be the best fit in that scholars will still be able to control the message of their games without the need to muddy ideas through a large group of people.

Chapter 7 will look on the process of development that I undertook, thoroughly documenting this process to provide a multitude of data to examine the process as a whole, and to examine how I performed solo development. This process leads to a better understanding of the issues which come from screen essentialism and black-boxing, which I explained within the chapter. I will seek to demonstrate that screen essentialism and black boxing of technology represent a significant hurdle to the advancement of digital game development. Scholars developing digital games enable further exploration of the technology behind games.

Technological black boxing becomes limited when a scholar has hands-on experience coding due to the visible interactions between hardware and software.

CHAPTER 2

SCHOLARS DISCUSSING DEVELOPMENT

This work seeks to explore the issues surrounding the development of digital games. To begin this work must examine what is begin done in the current field. By examining the works of other scholars this work will establish the need for scholars to examine more fully digital game development.

An area that is seldom explored academically within Game Studies is that of digital game development, meaning that I can expand the field. Also, that lack of established scholarship means I will need to pull all I can from what exists. Several scholars call for additional exploration of digital games outside of the finished artifact, but even these scholars shy away from addressing digital game development directly. Miguel Sicart, in his work “Against

Procedurality”, explains that digital games are more than the hardware and code that make them.

Player agency also needs to be taken into account when approaching digital games (Sicart 13-

14). Sicart also points to the need for exploration of the development process; however, that investigation should not remove the importance of the player (Sicart 5-6). Boluk and LeMieux in their work Metagaming discuss the ways that all digital games are metagames. In the introduction, Boluk and Lemieux touch on the ways that development is a part of digital games

(Boluk and LeMieux 4-5). They also state that digital games should be more broadly approached by scholars (Boluk and LeMieux 6-8). In Ian Bogost’s work, Unit Operations, he stipulates that scholars should examine the code of a digital game. For Bogost, the best way to explore the connections between works was to explore the most basic unit of that work, in the case of digital games, he believed that this was code (Bogost 13-15). All of these scholars have pointed to the

need for further exploration but only mention the development of digital games in passing. The subject of digital game development should be explored further.

Exploring the impact, process, and potential of digital game development is essential for scholarship. Digital games scholars should be given the most information about a digital game when approaching said game. Scholars like Casey O’Donnell, in his work Developer’s Dilemma argues that digital game development should be significant (O'Donnell 31-33). O’Donnell states,

“videogames are media and technology, both of which are constructed within extensive networks that have largely been ignored” (O'Donnell 33). It can be extrapolated from this information that development should not only be relevant to consumers, but also to those who study the medium.

The development of digital games is essential if for no other reason than it informs the remainder of the industry and leads to the development of similar games.

There are commonly perceived barriers to the exploration of digital game development, which may make scholars reticent to approach development. These stem from the visibility of

AAA games and the complexity that they represent. Teams of one hundred or more individuals develop the vast majority of AAA digital game titles. These games then give rise to the idea that digital game development is an enormous task and requires hundreds of people to accomplish.

The language used by digital game developers contributes to the perception that digital game development is inaccessible. Many digital game developers use industry jargon, which can make those unfamiliar with the process disinclined to engage in the process. Another perceived issue is that digital game development is expensive and would be a costly undertaking for any scholar.

The perception that cost is prohibitive stems from the development cost for the AAA games

industry, not from the independent games industry where cost and scale would be more analogous to scholarly development.

The majority of perceived barriers to digital game development are based mostly on gatekeeping rather than an actual challenge. For example, the language used by digital game developers is both a form of specialized communication and gatekeeping. Developers can quickly recognize when someone has used a particular software or has been a part of the development process by the language they use to describe the experience. In this way, developers can restrict access to their community via language. The use of language also proves to compound the perception that digital game development is highly specialized and inaccessible.

In Developer’s Dilemma, O’Donnell points to language as a means of gatekeeping in digital game development and how it proves to be more of a perceived issue with development rather than a real one (O'Donnell 41). Another contributing fact to the perceived inaccessibility of development stems from the visibility of some games over others. AAA gaming titles are highly visible due to advertising campaigns and numerous gameplay videos; these titles have gorgeous graphics and polished gameplay. To many, they present an unattainable level of development aptitude which prevents them from discovering that there are more clear means of digital game development and that a single developer can create a worthwhile game.

2.1 State of the Field

First, there must be an understanding of where the field is, at this current moment. It is for this reason that I will explore the current academic approaches to digital game development.

The scope of this discussion will center on the methods that scholars both perform and discuss their practice of digital game development, as well as, the ways that digital game scholars

approach the subject of digital game development. There are remarkably few scholars that discuss the matter of digital game development directly. Most scholars address digital game development in passing as they seek to discuss other important issues within digital game scholarship. For example, in Jesper Juul’s work Half-Real, Juul discusses the role development plays, but only in the context of seeking a definition for the term digital game. Likewise, Steven

Jones in his work, The Meaning of Video Games mentions the development of digital games to make a point about the lack of literature that examines the paratext of digital games.

I would define digital game development as an act which directly contributes to the production of a digital game artifact. Marketing and distribution models for digital games, while important to Game Studies, are not directly responsible for the creation of the game and as such will not be a focus of my work. The reasoning for this definition is in two parts. First, I wish to use the broadest terms for development to explore the various ways that development changes through time and how development could be applied in scholarship. For example, digital game development in the 1970s is very different from development methodologies now. As the techniques for digital game development have evolved so too have the ways that digital game development is performed. It is important to note that digital game development and the process by which games are created needs to change not just to meet the changes in technology, but also to maintain new and exciting experiences for players. There is an ecosystem of development that is in no way self-contained. The player drives the development process, with players both dictating the ways that developers market and produce their games, but also due to their input in the process itself.

The second reason that I will be utilizing this definition is that it offers the ability to explore the various methods of development that scholars might employ. The broad nature of my definition provides a telescoping method allowing scholars to focus on individual developers or large studios. As is the case with scholarly development, many of these scholars choose to develop games individually. Solo developers have great freedom when it comes to focusing their game on the topic that they wish to discuss. Incredibly, there are a few small team scholarly developers that develop games to communicate with an academic audience (Boluk and LeMieux,

Juul). Development is typically performed by scholars utilizing various development methodologies and technologies. The one unifying characteristic that these groups have is a desire to augment their scholarship using digital game development.

Scholars like Jesper Juul, Steven E. Jones, Robert F. Nideffer, and Mary Flanagan have all referenced the development of digital games. With each of their approaches to the development of digital games, some seek to use development as an example of how digital games exist outside of the finished game artifact, while other scholars try to explore ways that development could be performed by scholars to address social and academic issues. The unifying factor among these scholars is digital game development and its place within academic discourse.

The topic of digital game development has been touched on by many scholars including

Janet Murray and Espen Aarseth. For the most part, these scholars have not discussed development at length or the impact that digital game development has on scholarship. Instead, the vast majority of digital game development inclusion in academic discourse is rudimentary and hurried. They are referring briefly to the fact that these games come from designers and

developers and then quickly returning to the point being made. I am not stating that this practice is incorrect or that it lacks an understanding of the importance of digital game development.

Instead, I am asking; what would happen to the work if a broader approach to the process of digital game development was applied? Even though many texts skim over digital game development, there are some which examine more fully digital development either by utilizing the practice of digital game development or by discussing it directly. Additionally, some works point to a need for broader discussion when it comes to the analysis of digital games.

While exploring the works which point to a need for broader discussion when it comes to the analysis of digital games or reference development directly, I discovered two groups of writing. First the academic writing on the subject seeking to understand the digital game as a cultural artifact, within this group, scholars tend to seek out many ways that digital games can be approached looking at things like code or even advertising materials as a means of understanding digital games. For this reason, the work that these scholars do tends to glance on development in the search for more significant issues. These works lack the direct discussion of development and its role in the digital game artifact.

Secondly, and making up the bulk of work done by academics within the field of Game

Studies, is development textbooks. These books discuss the ways that development is accomplished in the industry and do not address strictly academic issues. Authors of these works include Jesse Schell and Jason Gregory. These works, while not focusing on the scholarly applications of digital game development, do write on the process of game making and discuss the many points of digital game development. While these works are important as examples of

digital game development texts, they are not the focus of this chapter since they do not explore the ways that digital game development can or does impact the work of digital game scholarship.

Mechanisms by Matthew G. Kirschenbaum is a New Media Studies text that is relevant to several issues concerning the development of digital games. Kirschenbaum does not speak to digital game development or digital Game Studies in a direct manner, however, he does illuminate issues within not exploring further the blackboxing of technology, issues which converge with digital game development and its lack of prominence within scholarship.

The first chapter of Mechanisms, “Every Contact Leaves a Trace” focuses on disputing screen essentialism, the valuing of the screen above all else, and illuminating the physicality of digital text. This chapter looks at how digital text resides on analog hardware. Kirschenbaum illuminates the ways that the screen masks the material reality of digital text. The borrowed term for this is black box, a reference to airline black boxes which are nearly impossible to open and retrieve the contents. As Kirschenbaum states, “compared to the pen, the typewriter or the printing press, the computer dematerializes the written trace” (Kirschenbaum 41). Digital text appears on a digital screen which makes the physical reality of the file being written to the hard drive opaque to the user. It requires the forensic imagination to imagine the words being written to RAM (Random Access Memory) or the hard drive. Even deleted files can be read on a hard drive. Data remain as a permanent part of the hard drive unless it is wiped from the system properly. All that a hard drive does is write; it is incapable of erasing. Files are just written over files when a file is deleted these new files act as a place marker for new files to write.

Chapter 3 of Mechanisms performs a reading of a disk image for the game Mystery

House. The disk image analyzed was a copy of a physical floppy disk used by Apple II

computers. Kirschenbaum points to the many types of data left on the disk after production and how the computer processes the written text of the game. The hardware is what makes the software text possible. The idea that the text of the game is less physical than the text of a novel is demonstrated to be erroneous. Kirshenbaum points out that “a computer cannot know that a title of a poem is a title or indeed that a poem is a poem without some specific mechanism for explicitly telling the system it is so” (Kirschenbaum 154). All text and interaction with the system must be computed by the hardware that makes up the system. The computer does not understand the words that it is displaying, nor does it react to the words being written, instead the computer responds to the code that tells it to react to the inputs from both the user and the hardware. By black boxing the hardware and making it so that the average user does not see the hard drive or the other components of the computer, there is an imagined disconnect between the text on the screen and the hardware reality of that text.

While Mechanisms is not directly referencing digital game development or even digital games, it does illustrate some of the base issues with approaching digital game development; namely that digital game development is a black boxed process. Developers rarely allow the community in on the development process, but when they do, it is commonly through heavily edited and curated stills and production videos. Artifacts like the design document or the code are typically hidden from the community. In this way, Kirschenbaum’s assertions about the forensic imagination are very useful as they provide an idea of how scholars could approach the decoding of the digital game development process. Kirschenbaum also helps to point out that approaching digital artifacts, such as digital games, cannot be based solely on the interface and

interactions with it. Instead, scholars must look more profoundly at the interaction space, of which digital games are a part.

Noah Wardrip-Fruin’s work Expressive Processing seeks to illuminate the processes between the hardware and the screen. The core of Fruin’s work is the idea of expressive processing which he defines as, “the possibility of creating new simulated machines, of defining new computational behaviors, as the great authoring opportunity that digital media offers”

(Wardrip-Fruin 7). Fruin looks at several games and AI (Artificial Intelligence) processes to support his thesis. I would say that the chapters entitled “The Eliza effect,” “The Tale-Spin

Effect,” and “The SimCity Effect” represent the core of Fruin’s work.

“The Eliza Effect” focuses on an AI program named Eliza. The program was designed as an AI therapist and would ask the user questions to keep a conversation going. As Fruin points out, the parameters of this program were rather simplistic, Eliza looks for certain keywords to know what to say in response. Fruin states as an example, “’well, you are very helpful,’ for instance, would become ‘well I are very helpful’” (Wardrip-Fruin 28). Despite the simplistic nature of the processes that Eliza performed, several users were convinced that the processes behind Eliza were complicated. It is the reaction of the users that Fruin names the Eliza effect. In this particular effect, Fruin is not examining the question of whether or not the processes are involved, but sooner or later the users perceive a complexity to the AI interaction. Fruin does point out the fact that this communication will break down if the user stops interacting with the

AI within the accepted parameters. Complexity does not guarantee that the user base will accept the AI interactions.

“The Tale-Spin Effect” discusses another process within a story generating AI. The processes for this AI were extraordinarily complex and reacted dynamically to inputs. However, due to the, at times, nonsensical outputs it was perceived to be too simplistic and was rejected by users. The process would output narratives where characters drown in a river while a friend was sitting nearby, or gravity would drown while Henry slipped into the river (Wardrip-Fruin 133).

These examples illustrate just how complicated the process was as opposed to how simple. In the first example, the friend was unable to get to the character in time to save him. In the second example, gravity was a character that acted on Henry, his friend saved him, but gravity had no one to save it, so it died. While Eliza benefited from simple processes, complex inputs, and seemingly complex outputs, Tale-Spin had the opposite effect. Tale-Spin’s simplistic and limited inputs and simplistic outputs hid an incredibly complex process underneath. Fruin points to how

Tale-Spin acts as an example of the need to understand digital artifacts as the simulation of a machine that they are and the process as the more delicate mechanisms of that machine. Both approaches to digital artifacts are essential for producers and scholars alike. These aspects of a digital artifact can be balanced as is the case with SimCity.

“The SimCity Effect” looks at how the complexity of processing and input and output can be simplified for users, while also reflecting the complexity of the process. SimCity works by simulating the running of a city. The user inputs numerical values into various boxes and places roads, utilities, and zones on a 3D map. The inputs range from simple drawing interactions where the user places roads and zones, to inputting the tax rates and allocating funds throughout the city. As Fruin points out, the processes are the game, “the process of play with

SimCity is one of learning to understand the system’s operations” (Wardrip-Fruin 300). Unlike

Eliza or Tale-Spin, SimCity does not attempt to conceal the nature of its processes. Instead,

SimCity wants its users to play with the process directly.

Expressive Processing is another example of a work that establishes the assumptions made due to veiling the processes that generate an interactive artifact. Digital game development is not directly discussed in this work, but the references to systems and code do evoke digital game development, especially chapter eight and its discussion of the game SimCity by referencing the game and its overt systems, Fruin makes it clear that design choices matter when it comes to the effect that processes have on the one interacting with them. Fruin begins to discuss the potential within examining digital game development as scholars by exploring the way that design choices help individuals recognize processes within their digital media.

Steven E. Jones illustrates throughout his book, The Meaning of Video Games, that outside texts and culture influence meaning-making for video games. The artificial inflation of play is due, in part, to digital games being approached as stand-alone works. Of this practice within Game

Studies, Jones states, “I think, in sympathy with the aim of ludology to do justice to the uniqueness of games as a form—but one that also refuses to cut games off from the larger culture” (Jones 6). Often digital games are treated as a medium that is represented by the finished digital game when, in reality, digital games are connected to their production as well as the world surrounding them.

A theme that is consistent throughout the book is that of paratextual analysis of digital games. According to Jones, paratext is “about the material conditions of a book's production, publication, and reception, how a book makes its way out into the world and comes to mean something to the public audience that receives it” (Jones 7). Here Jones is describing the process

as it relates to literature; however, this idea is extended to digital media. Jones seeks to reveal the connections between digital games and the greater world of influence surrounding them. He accomplishes this task by using texts that exist outside digital games themselves. For example, the text covers the connections between Lost and Myst, Punk and Katamari Damacy, Halo and fan-made content. These chapters are essential to Jones’ book and support his claims about the importance of paratext when approaching digital games.

An important idea to take from Jones’ work is the idea that digital game development and production should be increasingly examined within the field of Game Studies. It is essential to understand that the issues surrounding ludology and narratology are crucial in their context; these schools of thought both tend to explore the finished artifact and nothing else. As Jones has made clear in his work, there is more than enough room within the field to explore more than just the finished product and that discussion should include the larger body of social context as well as production.

The Meaning of Video Games builds from examples to directly communicating with significant works and authors within Game Studies. Jones repeatedly references scholars like

Espen Aarseth and Janet Murray. He both praises and challenges these figures by lauding their claims that further the field and testing their ideas that completely divorce digital games from other media. These chapters are essential to communicating with the field and establishing paratextual analysis as necessary. It is not until the sixth chapter that Jones presents his argument in the strongest possible way.

Jones’s analysis in Chapter 6, entitled “Anticipating Spore,” focuses entirely on the paratext surrounding Spore’s release to the general public. The game had not been released at the

time that the book was written and so all that could be analyzed was the paratextual elements. By approaching Spore without any ability to play it, Jones was able to demonstrate the ways that community and textuality are linked, and that paratext is important to analysis. “Anticipating

Spore” is by far the most critical chapter in the work, carrying everything that was discussed in prior chapters and combining them into a case study that illuminates the issues with assumptions made in previous scholarship. By analyzing a game that had not been released, Jones points directly to the flaws in the logic that digital games are stand-alone artifacts with no connection to paratextual media.

Digital games are products of various factors, community, development, and the advertisement media surrounding them. “Anticipating Spore” works to illustrate the importance of all these factors. By focusing on Will Wright, the lead developer of Spore, Jones illustrates the way that the developer impacts the digital game artifact. Through his investigation of the role that Wright plays in the development of the artifact and his way of interacting with other digital games, Jones demonstrates how paratext informs the game artifact. Jones discusses an example of Wright playing Grand Theft Auto: San Andreas where he uses the bike physics to perform tricks on a ramp, “Only the inventor of The Sims could turn even the gangster action game into a social sandbox” (Jones 157). Pointing to how Wright plays games demonstrates the ways that the community’s perception of the creator of the game impacts readings of that game. The narrative of Will Wright playing GTA as a BMX sandbox also connects to the open play embedded in his games. Spore, which had not yet been released, was already believed to be a sandbox game where the player could interact openly. The assumption that Spore would be open-world had a great deal to do with who was making the game.

2.2 Scholars Discussing Development

Jesper Juul in his work The Art of Failure developed, in conjunction with Albert Dang and Kan Yang Li, a digital game where the goal is to commit suicide. This game was made in order to demonstrate that failure can be the goal of a digital game. Juul spends the majority of this work arguing that the thing that sets digital games apart as a medium is that failure is factored into the experience. In order to more fully demonstrate how failure can be the goal of a digital game, Juul’s team developed a game to make their point. Juul’s central point for this game is to demonstrate that players would intentionally play a depressing game. Juul also wanted to demonstrate that players will put effort into completing the task. Juul demonstrates here the value of development for academic communication. Here Juul assisted in the development of a digital game to aid in the communication of ideas from his book. The goal of this game is to have the player commit suicide and in order to make this goal challenging the player must work against a timer as well as type in alphabetic codes to complete each of the four phases of the suicide attempt. Juul’s game and book act as an example of digital game development for scholarship.

Juul directly references digital game development as a potential tool in education in terms of motivation (118-121). Juul sees game designers as masters of motivating players and giving players optimal paths to achieve their goals. Due to the perceived ability that designers have to motivate, Juul asks if it is possible to utilize development in this way in education. Unlike others who discuss digital game development, Juul does not try to refer to issues within Game Studies concerning the lack of exploration outside play. Instead, Juul looks at what can be done with

development as a tool, which is fitting, considering his use of development to communicate within his work.

Stephanie Boluk and Patrick LeMieux in their work Metagaming, focus on how digital games act as a collection of metagames and that the perception of digital games as an isolated digital artifact is problematic (Boluk and LeMieux 8-9). Boluk and LeMieux in their work point to the issues with approaching digital games as “single-use software” (Boluk and LeMieux 25).

They point to the ways that digital games can be used as platforms for generating many metagames. Boluk and Lemieux do not mention digital game development or that the development of digital games is worth studying, however, their use of development in their metagames, which they state that they created, provides ample evidence that development is something that should be considered.

Boluk and LeMieux place their work into some logical traps that should be addressed.

Firstly, insistence on referring to games exclusively as metagames creates unnecessary issues with the games that they develop and reference. Most importantly, however, is the issue with the games that Boluk and LeMieux developed for the work. Within Metagaming Boluk and

LeMieux state that games are just rulesets designed for the creation of many metagames while they frame their games as metagames that have a point or path that the player should follow. As stated in their work, ”Difficult to design, impossible to predict, deeply collaborative, and always ephemeral, metagaming undermines the authority of videogames as authored objects, packaged products, intellectual property, and copyrighted code by transforming single-use software into materials for making many metagames“ (Boluk and LeMieux 25). The games that they create are called original metagames however they would require the player to accept that to become

metagames in the first place. The contradiction of the games presented for analysis and the games that they develop muddies the point that Boluk and LeMieux intend to make.

Notwithstanding Boluk and LeMieux’s issues, the core of their work is undoubtedly vital at this junction within the Games Studies landscape. It is essential to draw attention to the fact that digital games are not isolated artifacts divorced from their production. While Boluk and

LeMieux do not directly state that digital game development should be a focus within Game

Studies, they do infer such through the use of development within their text. Additionally, Boluk and LeMieux call for additional work within the field of Game Studies to explore the ways that digital games exist outside of their individualized artifacts. The use of digital game development furthers the idea that development can be a tool for scholars. Boluk and LeMieux help to articulate the need for further scholarship on the subject of digital game development and the connotations that the process has on the games or metagames that are a result of production.

Nideffer in his work creates many digital games as a means to communicate with others in the field of Game Studies. The majority of Nideffer’s work consists of social commentary or satire of the digital games community. Unlike Juul, Nideffer uses the digital game alone as a means to speak to academic issues within the field of Game Studies. Nideffer's written works like “Game

Engines as Creative Frameworks” pair with his preexisting digital works such as, WTF or Tomb

Raider 99’ to generate a body of creative scholarship that begins with digital work and connects in written work. Nideffer's particular focus on games as an expressive art form first and as an academic exercise second help him to build academic work from digital game development. As a contrast to Juul, Boluk, and LeMieux, Nideffer chooses to develop digital games as a means to explore scholarly and social questions then derives scholarship from his artistic practice.

In “Game Engines as Creative Frameworks” Nideffer states the importance of examining game engines as cultural artifacts. “In other places I’ve argued that it’s important to look at the game engine itself as a cultural artifact circulating within a specific social domain, in order to move beyond thinking of the game engine strictly in software engineering terms, and instead begin to think about it in social engineering terms” (Nideffer, Game Engines as Creative

Frameworks 3). Nideffer is referring here to his work “Game Engines as Embedded Systems” in which he states that the game engine is more than just a piece of software. “Hopefully it has become clear that the game engine is not simply software, it is software that reflects and embodies the cultural conditions symptomatic of the developers of the system, as well as the end users of that system”(Nideffer, Game Engines as Embedded Systems 8). Each of these works is an exploration of development, and in particular the game engine, by his creating works with these engines. Nideffer does not generate his works to explore ideas that he already has; instead, he utilizes his experience in creating to contribute to the Game Studies discussion.

There is also work being done examining the digital game development industry and how those that make games are treated. Casey O’Donnell’s work Developer’s Dilemma is an example of a work about the industry of development. In this work, O’Donnell utilizes an ethnographic methodology to gain a better understanding of the ways that digital games are made. This work offers a rare glimpse into the development process and the ways that those in authority mistreat digital development professionals. O’Donnell seldom discusses the academic approaches to digital games or development, instead, focusing on the process of digital game development and the exploitation of the labor that makes the medium possible. The work presents some of the

reasons why a focus on the development of digital games as a part of Game Studies should be important.

O’Donnell demonstrates that how a digital game comes into being are essential; if for no other reason than this process can be exploitive of those that make the games and therefore impact the artifact in the ways that it is perceived. While O’Donnell never directly addresses the lack of attention digital game development is paid in Game Studies, he does point to the need for greater scrutiny of the process as a whole. It can be extrapolated from this that the field of Game

Studies should likewise be more attentive to the development process.

Digital game development is an integral part of any digital game artifact. These artifacts are not solely what is played, but are a culmination of the efforts of designers, developers, and coders working as a development team in order to produce them. As such, the process of digital game development is core to both the understanding of any digital game and Game Studies analysis.

Mary Flanagan in her work, Critical Play discusses a new model for digital game development. Flanagan points to the ways that digital development and play can be used to communicate with players, in particular, communication centered on social and academic issues.

Flanagan theorizes that play and games can be developed with a focus on social issues and that these games will be better received and provide a stronger framework for communication.

Flanagan discusses play and the designing of it, “There is something about designing play, especially the process of conceptualizing and making games, that requires attention to possibility” (252). For Flanagan, there is a possibility space within play where the designer must account for all possibilities within the play space. The play space can be structured in such a way

that social and academic issues are brought to the forefront and confronted with the act of play.

While this process is undoubtedly difficult, Flanagan seeks to give the developer a set of tools and methodologies to make the development of academic games simpler. Flanagan outlines her method as follows, “Set a design goal, develop the minimum rules and assets for the goal, develop a playable prototype, playtest, revise, repeat” (254-255). While much of this development methodology is similar to many others, it is the focus on the development goal that sets this apart. When setting the goal to communicate an academic concept with the player, all other steps must conform to that goal or be revised until they do. Flanagan’s focus in her work is to alter the ways that development is performed and to propose a new methodology, however,

Flanagan points to the importance of development as a field of study by suggesting that development can be used for study.

Ian Bogost in his work Unit Operations seeks to find new ways of approaching digital game scholarship by focusing on the code of the game. Bogost states, “the field of ‘hardcore’

Game Studies is thus revealed to be essentialist and doctrinaire, its theorists hoping to reinvent a different kind of isolationist techno-textual criticism that privileges the ludic over the literary”

(Bogost 53). Bogost’s focus here is much the same as other scholars referenced, to counter the view of the game as an isolated artifact, Bogost seeks to place the artifact in conversation with the surrounding work. Bogost then goes on to explore how this can be done when looking at the code which makes the game function. While code analysis does provide an increased understanding of how digital games function and communicate with the hardware that plays them, this approach divorces itself from the development process that necessitates the code to begin with. It is unfortunate for Bogost’s work that it was situated within a period in Game

Studies where there was tension between narratological and ludic ideas about approaches to digital games. From exploring Bogost work, it becomes apparent that Bogost could have devoted more to the development of digital games had he not had to use these lenses to frame his work.

Unit Operations is an example of an earlier work that can be seen to lead to a better understanding of digital game development while calling for increased study in the area. Bogost like many others does not outright call for this study, however, in pointing to the fact that digital

Game Studies are often narrowed to ludic approaches, he is calling for other approaches to the medium. Additionally, code is a core part of the development process since without it there would not be digital games, as such Bogost could be seen as beginning a development-centered approach to digital game scholarship.

Scholarship examining the process of development is essential not only for the benefits that it possesses to the field of Game Studies, but also the importance of examining how popular media is produced. The book Developer’s Dilemma by Casey O’Donnell is an example of a scholar doing work on the process directly. O’Donnell’s book examines the production of digital games by placing the scholar within a development studio in order to examine the methodologies used to make games. This work, in particular, focuses on the treatment of those that make digital games and how the industry thinks and behaves toward those that do the work of making digital games. The exploration of digital game development from a social sciences perspective is not anything new, however, the exploration of this medium from an ethnographic standpoint embedding the scholar within the development team for a company is unique.

In Developer’s Dilemma, there is an exploration of the digital game development process.

The primary focus was to explore the environment of AAA development studios and to explore

the toll that style of development takes on those involved in it. The chronicle of mistreatment and an industry that has become comfortable with 80-hour work weeks illuminates some of the darker parts of the development industry. While this is important and eye-opening, this is not the work that I intend to explore. Instead, I will utilize this work to examine the development process and changes to that process over time. For example, O’Donnell describes the changes in engines over the time he spent developing games. Furthermore, O’Donnell explores the ways that digital game development is carried out giving scholars a better idea of just what goes into the development of digital games. Developer’s Dilemma is an example of one scholarly approach to the subject of digital games and is essential in that it illuminates some of the questions that have yet to be explored by scholarship.

2.3 Conclusion

Game Studies is a growing field of study globally with an ever-increasing body of literature devoted to digital games. As was stated by other scholars, digital game development should be a point of discussion within the field of Game Studies. Currently, digital game development stands as a lightly explored subject for scholars within the field of Game Studies. In

Language, Counter-Memory, Practice: Selected Essays and Interviews by Michel Foucault,

Foucault describes the exchange between theory and art and that each is driven by the other.

“Practice is a set of relays from one theoretical point to another, and theory is a relay from one practice to another. No theory can develop without eventually encountering a wall, and practice is necessary for piercing this wall” (Foucault 206). The act of digital game development is necessary for the theory to progress. Whether or not scholars participate in the practice of digital game development, both practice and theory are needed. As digital game scholars, it is crucial to

gain an understanding of development and how development tools shape the games that are created.

Digital games evolve with the technology on which they are played. Development likewise changes with the technology creating new ways to develop games and new tools to streamline that process. In the same way, the scholarship that surrounds digital games must evolve as the medium does. Jesper Juul in his work Half-Real offers six criteria for what a digital game can be. This definition was established in 2005, and since that time the medium has generated several games which act to challenge Juul’s definition. Juul’s attempt at defining what a digital game is became needed to explore more fully the existing digital games, however, by not including the development process and the fluctuation within the tools available to make games, Juul ultimately created a definition that was far too rigid. Juul did account for this potential change within his work. After defining digital games, Juul clarifies that this definition should change to accommodate changes due to new games. It is important to note that Juul does not discuss the changes in terms of technological or developmental change, rather in terms of new games being created that challenge his definition.

The example of Juul’s definition for digital games not factoring the changes in technology or development methodology illustrates the need for better understanding of digital game development. It is not for sure that Juul does not have that experience or that it would have changed the definition that he proposes. Instead, I make the hypothesis that the definition could be better understood as well as better suited to the changes through which development progresses through. By better understanding how digital game development changes and by understanding the ever-fluctuating nature of technical definitions for terms within the field can

be better contextualized. The understanding that game engines frequently change with updates and new features being added, changes opportunities for developers allowing scholars to better contextualize definitions for terms.

The interdisciplinary nature of digital game development provides a view to ways in which the more humanities-based approaches to digital games can be paired with the more computer science-based approaches. These disparate fields can be joined in much the same way that development teams can bring individuals with backgrounds in art, sound, and computer science together. There is an increasing number of Game Studies scholars calling for this kind of scholarship seeking to gain the benefits from working with others whose expertise differs from their own, however, these scholars, do not reference the need for this collaboration to explore digital game development either as a branch of study or as a shared creative practice. As was addressed earlier, scholars such as Jones, Boluk, and LeMieux have sought to demonstrate the need for scholarship focused on digital games to look outside the original game artifacts and seek to understand the surrounding culture and production of games. The lack of discussion on how this mode of interdisciplinary work can be accomplished and then modeled for academic prepossess provides the opportunity to illustrate how this practice could be used within the field.

As stated earlier, digital game studios are made up of individuals from several disciplines. These individuals can utilize methodologies to work together in order to make games. Within academic study and practice, there are constructed barriers to interdisciplinary collaboration that have too frequently led to the emergence of debate within the field.

Historically, these barriers can be seen in ludology and narratology. These differing viewpoints generated some of the most important work in the field of Game Studies, but it is not until these

viewpoints begin to be used in tandem that the full potential of either camps ideas can come to full fruition. The field of Game Studies would benefit greatly from coming to recognize that by working together and creating together the field can progress to unknown spaces. Digital game development can be utilized as space where creative collaboration can happen to explore more in-depth questions that the field poses.

When scholars produce digital games, they become a part of the medium that they seek to critique. Participating in multiple aspects of digital game scholarship broadens the potential for new lenses into how scholars could approach the medium. When the scholar is both producer and consumer of a medium, they can better understand the medium and potential approaches to understand its impact and contribution. Digital Game Studies scholars should have a working knowledge of the medium that they study. This statement appears to be a radical one until other mediums are examined and the process by which the scholars of those mediums gain their expertise. Within the field of film studies, scholars must learn the basics of film making including lighting and camera techniques. The practice of understanding media through criticism is not new, instead, the need to expressly state that the critique could understand the medium is new. Literary scholars did not need to discuss the importance of reading and writing because they were needed in order to practice in the field. Film studies scholars however needed to demonstrate the relevance of knowledge of production since anyone can go and watch a film, but not everyone understands the methods behind the production of the film that they are watching.

In much the same way for Game Studies, it needs to be expressly stated that knowledge of production methodology is needed to understand better the medium that the scholar is approaching.

Digital game development has been practiced by a few scholars to clarify their ideas or to explore the medium and generate ideas from practice. These scholars include Jesper Juul, Robert

F. Nideffer, Stephanie Boluk, and Patrick LeMieux. Each of these scholars developed games for their works in order to better communicate the topics presented in them. The latter two Boluk and LeMieux would argue that they were presenting meta-games that were not developed.

However, if these games are analyzed through the practice of play, it becomes evident that these are developed games and not only meta-games derived from some prior game. Boluk and

LeMieux developed the games themselves as an act of creative practice to better communicate their theories on metagames. The small team dynamic offered these scholars the ability to shift development priorities rapidly so they could shift focus from the art within the games to the scholarly messages to embed in ludic communication. Boluk and LeMieux were able to utilize the small development team in order to produce a few art games that play with the idea of play within their ludic framework. In their game Triforce, Boluk and LeMieux explore the ways games can be organized specially and how that organization offers a new way to play within a games meta. This example of development to deconstruct a particular means of play within the familiar gameplay of The Legend of Zelda makes the player interact with the game in a new way.

By reorganizing the visuals of this game, the player can see new ways of playing with space in games.

Further dialog and exploration of the subject of digital game development could lead to a variety of outcomes. While speculative, I have come to the understanding that digital game development could help create collaboration within the field of Game Studies between groups that would not usually work together. I would also speculate that gaining a greater understanding

of the modes and methods of digital game development will produce a greater ability to perform critical analysis of digital games as a medium. Development is a large part of what a digital game is, and so to have thoroughly brushed past this vital part of the game artifact does not serve the medium or the field. By including the process by which the digital game is created into the methodological considerations for analysis, the scholar gains a complete understanding of the artifact.

To accomplish the goal of approaching the digital game artifact through a better understanding of development, scholars have to examine more than just scholarly work on the matter. Digital game development is a thoroughly explored topic when approaching it from the production angle. There is an abundance of development textbooks exploring pipeline methodologies as well as exploring game engines and how to best utilize them. In addition to these texts, some companies publish their post-mortems on the development process, and in some rare cases, companies will publish their design documents from the development process.

Sources like these are rarely utilized by scholars when learning about digital games and should be something that the scholar can work with to better understand a game.

CHAPTER 3

DEVELOPERS DISCUSSING DEVELOPMENT

Literature that focuses on digital game development is varied and complex. There are works by scholars about the process of development itself, as is the case with Developer's

Dilemma. Additionally, there are the works that are written by developers themselves, as is the case with Post-mortems from Game Developer. Each of these works has a place within the field of game studies and should be regarded as a source of information for scholars. An issue that arises is the gaining of development documents from developers of AAA titles. These documents are almost always protected by non-disclosure agreements (NDA), and as such, are not made available to the public. There are examples of developers releasing these documents to interested fans, but these cases are few and far between. The only documents that are routinely published are the post-mortems written after the game has been released. It is worth noting that these documents are public-facing documents made by developers as a celebration of successful games. There are very few public post-mortems for unsuccessful games.

Defining development for my research is necessary. When I reference digital game development within the context of this work, I am focusing on the process by which a digital game comes to be. The process of digital game development frequently becomes conflated with the process of selling a digital game. I will not be focusing on the selling or marketing of any digital games as marketing, while related to the pre and post-production of a digital game, is not the process of developing a digital game. Marketing digital games can be a part of the pre- production of a digital game and influence the game's development process when marketability is the sole focus. However, this approach to the production of digital games only accounts for

those developers that produce digital games to fit within the market. In all cases, whether the digital game is being marketed, used as an example within games scholarship, or for personal use, there is a process that occurs to produce the digital game artifact. It is this process of making art, designing a digital space, and the coding of that space that is of interest to me in this work.

Development, as I would define it for this work, is the process of joining the disparate works of art and code into a unified digital game.

3.1 State of the Art

In Eric Steven Raymond's work, "The Cathedral and the Bazaar," he illustrates the differences between open development practices and closed practices, as well as the benefits and drawbacks of each method. The Bazaar methodology includes opening the development of software up to the community to share all assets and allowing the community to aid in the process by coding and producing assets (Raymond 1-2). The Cathedral methodology is a closed system and is frequently used in corporate situations. In this methodology, everything is done within the company, and the community is uninvolved with the development process. Typically this method is employed to protect the intellectual property (IP) of the developer.

Raymond goes on to discuss the Bazaar style of development and how including the user base in the process improves the overall product, as Raymond puts it, "Treating your users as co- developers is your least-hassle route to rapid code improvement and effective debugging"

method is preferable to the Cathedral method due to user engadgement and the effect it has on the programers developing the software (Raymond 30-31).

Raymond's work is relevant to game studies due to its two differing strategies utilized within the game development community. There are projects like Stardew Valley, where the solo developer behind the game communicates frequently and openly with the community seeking input on changes that would improve the game. Conversely, there are developers like most AAA studios, i.e., Naughty Dog, which seek to keep the process of development closed off from the community to protect intellectual property rights (IP).

There have been several works dedicated to teaching the reader about the digital game design process, and tend to focus solely on the process of digital game development. Jesse

Schell's The Art of Game Design focuses on how to think like a game designer in particular how to be aware of the development process. Schell suggests that a game designer be aware of animation, anthropology, architecture, brainstorming, business, cinematography, communication, creative writing, economics, engineering, games, history, management, mathematics, music, psychology, public speaking, sound design, technical writing, and visual arts (Schell 3-4). The long list of areas with which a developer should be familiar drives Schell's point that a digital game developer needs to be versed in the totality of the digital game making process. Schell speaks more to best practices for digital game designers and less the overall implementation of those ideas. Concerned much less with instructing individuals in coding games, Schell focuses on getting the reader to think like a game developer.

The Art of Game Design does communicate the role of the developer reasonably well and references game studies more than most development textbooks (Schell 158,296-300). While

these references are short and provide only a glance at scholarship Schell does acknowledge the importance of these endeavors. The focus of my work is not gender or the gendered spaces within digital game development. However, Schell does reference gender to state that female gamers should not be factored into the development process (Schell 120-126). Despite the limitations of the work when it comes to gender, Schell provides a fascinating look into the demands placed on developers, thus allowing scholars a better understanding of the complexity of the development process.

Digital game development textbooks can benefit scholars by offering the opportunity to gain a view into the development process. Instead of reading these to learn how to make games, scholars can read them to understand better the process by which a game has already been made and gain some insight into the multidisciplinary work that is digital game development.

Additionally, scholars can benefit from understanding the mistakes and successes made by digital game developers. By gaining an understanding of the mistakes made by other developers, scholars can learn how to better develop their work.

Examining the development process for digital games can be difficult due to how closely held the process is for the vast majority of digital games. One development document that is shared publicly with some consistency, however, is the post-mortem. A post-mortem is a document that acts as an examination of the process of developing a title and exploration of what went right and wrong during development. These short works typically are written from the perspective that they will be shared publicly, and as such, are not always the most accurate tools in exploring a games development from the perspective of what went wrong. Where these works do excel is their offering a small understanding of what the development process entails. Post-

mortems from Game Developer is an example of a work which contains several post-mortems examining the process of development for several popular titles.

An example of one such well-known game is Diablo II. Erich Schaefer, one of the lead developers for the game Diablo II, wrote the post-mortem. He describes the pressure of developing a sequel to a popular title and how they attempted to build on the success of the previous title (Grossman 79-80). What is important here is that Schaefer does discuss one of the shortcomings of the development of the game. In particular the creation and launch of Blizzard's online service battle.net in conjuction with Diablo II generating massive issues for players

(Grossman 87). The scope of what Blizzard was attempting to do here was too broad and, according to Schaefer, should have been a gradual rollout in order to get performance data on the servers.

Schaefer also describes issues with the tools used to make the game. The team was trying to marry the existing tools used to make the first game with a game engine that would not accept those inputs. In other words, the two systems did not communicate with each other and the team decided that integrating these tools would be too time-consuming, instead choosing to work around the issues instead of fixing them (Grossman 88-89). These decisions lead to long turnaround times for assets. Scholars can learn from this example by taking into account the various types and kinds of software that are utilized when developing a digital game and how different people utilize these aspects.

Moreover, there is a benefit in planning out the software needed for development, as well as how software integrates. In the current development landscape, many more tools integrate and make development far more streamlined than it was when Diablo II was in development;

however, there are still integration issues that can occur if a project is not well thought out. The majority of these issues resulted in the need for changes to the scope of the project and resulted in content being offloaded to downloadable content (Grossman 88-89). The issue of scoping projects is common for most developers.

Scholars would be best served by understanding how to scope for digital game development. Most scholars understand this process by creating criteria for exclusion within their scholarly works. When examining digital games, it is essential to remember that issues of scope are common and that not every feature that seems obvious should be included. Another post-mortem from the book Post-mortems from Game Developer discusses one way to avoid the issues that come with scoping. Warren Spector discusses the game Deus Ex examining some of the aspects of creating the game. Spector discusses one of the ways that they were able to combat the issue of scope by creating proto-missions (Grossman 200-201). These would be playable chunks of the game intended for the game's publisher or the video game press. A critical aspect of this is the ability to be self-critical and recognize the issues with one's work (Grossman 201).

Another way that this method helps scope the game is that the developer can understand better what can be accomplished in a set amount of time and when feature creep begins to set in.

Spector did point out that there are limitations to developing proto-missions. Later in the post-mortem, Spector points out that there are issues that arise with this kind of development.

Firstly, they had to decide how to implement this method of development best. One way to implement this method would be to focus on one mission at a time. Another would be to have teams working on missions and presenting their prototype at the same time as the other teams whether or not the mission was in a polished state (Grossman 205-206). Spector went with the

second method which ended up working for them. Spector also mentions the rough nature of some of the proto-missions. Since the development team was focused on producing these proto- missions at a rapid pace, there would be times that these would be unpolished and feature very rough mechanics (Grossman 205-206). In terms of scholarly development, the process of scoping games to better communicate with the player is necessary. This statement would seem to be self- evident; however, there is a skill to scoping a game properly; knowing how to maintain the goal of a game while streamlining the mechanical interactions is challenging. Exploring works like

Postmortem from Game Developer can aid scholars in better understanding the process of scoping games.

Post-mortems from Game Developer provides scholars with limited insight into the development process for a select few games. Even this limited exploration of digital game development can offer scholars with increased knowledge about the process by which a digital game is created. The knowledge gained can then inform scholars within their work and exploration of the digital game medium.

Casey O'Donnell's work Developer's Dilemma focuses on the process of developing games. Developer's Dilemma is an ethnographic study of development. By embedding himself in a development studio, O'Donnell can gain a better understanding of the process of development.

O'Donnell does not shy away from portraying some of the more exploitive practices within digital game development. O'Donnell's work is essential when exploring the development side of academic approaches to digital games due to the ways that O'Donnell factors development practice into his studies.

In Chapter 2 section 1, O'Donnell discusses the importance of language and terminology within the development social hierarchy. "Language is a precursor to many of the other barriers to entry or 'secrets' of the game industry" (O'Donnell 41). Digital game development is surrounded by terms that enable developers to communicate with one another. These terms also serve as a gatekeeping methodology to denote those that have authority within the space

(O'Donnell 41-42). These are terms that scholars should understand for several reasons; one example includes increased communication between scholars and developers. Once scholars understand the language of development, then they can gain a greater understanding concerning the process with which the terms are connected. For example, "balance" is typically related to weight or visual design in many fields; however, in digital games, it refers to the balancing of various code systems to produce the best gameplay. Once scholars understand the term within this context, then the term can be deconstructed or re-appropriated by scholars to explore the limitations and influence that are side effects of utilizing this term.

While O'Donnell describes language as a means of gatekeeping for the digital games industry, language also acts as a means to communicate between members of the same development team allowing them to solve issues rapidly. It is vital for scholars to understand the ways that language is utilized by developers to communicate. By better understanding the ways that developers communicate with one another, scholars can deconstruct the language and discover new connections within digital game artifacts. Knowledge of development terminology is necessary for scholarship to communicate more accurately concerning development and not as a means to gatekeep individual scholars. In much the same way that O'Donnell does not suggest that development terms and language are not exclusively for gatekeeping purposes (O'Donnell

43). Instead, I am suggesting that more information about the process and the language used to develop digital games can improve the overall scholarship, offering new avenues for criticism.

Developer's Dilemma acts as an exploration of the practical realities of digital game development. It provides a window into the day-to-day experiences of those responsible for developing AAA digital games. Additionally, the work provides an example of the potential consequences of the cathedral style of development, in which people are merely the tools needed to develop software instead of the community. For scholars, it is essential to remember what kind of development is being performed and how that development impacts those who make the game's artifacts. There are very few works that take into account the developers of digital games, but as has been pointed out by other scholars and myself, there is a need to explore the digital game beyond the final digital artifact and instead explore the process and social realities surrounding the digital game (Nideffer, Juul, Jones, Nitsche, Sicart). O'Donnell does just that in this work, by setting aside questions about the final game produced and instead examining the individuals that produce the digital game.

3.2 Game Engines and Gamified Engines

Game engines have evolved with the medium. Digital game engines began in the early

'80s as a means to continue the success of digital games and provide smaller development houses the ability to make games quickly and easily. These first engines were focused on specific kinds of games like Pinball Construction Set released in 1983 which solely made digital versions of pinball games. It was not until the Unreal and Quake (ID Tech) engines appeared in the late 90's that engines could be multipurpose. These engines focused on providing the code base for several standard and time-consuming functions like physics and rendering systems. The change

from engines being dedicated to one kind of game to an all-purpose development tool altered the ways that game developers could approach games.

In his work "Game Engines as Creative Frameworks," Robert Nideffer explains that game engines, while being tools for the creation of digital games, also act as a limiter on the kinds of games that can be made for both creative and economic reasons (Nideffer, Game

Engines as Creative Frameworks 1). For example, the Unreal engine was developed to make first person shooters which means that creatively utilizing the engine to make games that are not first person shooters will come with certain challenges. Additionally, Nideffer points to the ways that economic factors drive the focus of developers and engines (Nideffer, Game Engines as Creative

Frameworks 2). As an example within the landscape of current games, the battle royal genre is prevalent. Meaning that whatever game engine provides tools to make these kinds of games becomes more popular and therefore will change to meet this demand. Contemporary game engines operate much like the early engines in that they are made with a specific game type in mind for both creative and financial reasons. Recently Unreal and Unity engines have become free to the public, making game engines more diverse than ever. "Game Engines as Creative

Frameworks" was written in 2003, and over a decade later, some points remain the same, while others have fundamentally changed. Nideffer points to the prohibitive cost of engines as a means by which engines act as creative frameworks by making any development that will not make money risky. However, now both Unreal and Unity engines are free to use and only cost money once the developer crosses a set earning threshold (Epic Games, Unity Technologies). Financial forces still act as major factors for the engine and its users. However, limitations for users are not as strong as they were in 2003. The creative framework is still very much a financial one.

However, independent developers like The Fullbright Company utilize these engines to make artistic games like Gone Home, challenging the popular uses of the engine.

Independent developers commonly use the Gamemaker 2 engine. Gamemaker 2 provides tools for the development of 2D games. Gamemaker 2 is an example of an engine that bridges the gap between more complex engines like Unreal or Unity and single-use engines like the

Pinball Construction Set as mentioned above (YoYo Games Ltd.). This engine does provide a view into a development engine that does not easily fit within Nideffer's conclusions. Unlike the more famous game engines Gamemaker 2 is intended for mass use and does not cater to AAA studios. The code language for the engine can be set to a visual language which is easier to pick up and use than most coding languages while keeping a code option for more precise game creation. In doing this Gamemaker 2 establishes a lower entry level than most engines.

Gamemaker 2 was designed for the development of simple games by newer developers offering development opportunities to less experienced creators. The simplification of Gamemaker 2 does come with some issues, but overall the engine succeeds in its goal to provide a simplified platform to a broader base of developers.

Another variant from more established engines like Unity and Unreal is that Gamemaker

2 is not free. Gamemaker 2 is a one-time purchase of one hundred dollars; the reasoning for this cost is that unlike Unity and Unreal, Gamemaker 2 is designed for small groups that may not make a single game that is published and if it is it will not make a significant amount of money.

The idea that Nideffer presents concerning financial issues shaping engines do not fit with the model that Gamemaker 2 presents, instead Gamemaker 2 establishes that game engines can be used to subvert the norm of game engines being financially driven (YoYo Games Ltd.). Nideffer

does have a point in that the engine does shape the kinds of games that can be made within its context. For example, Gamemaker 2 would not be able to make a fully 3D open-world game due to the technical restraints of the engine and not the financial ones. Nideffer does point to the limitations or specialization of the engine contributing to the creative framework of the engine

(Nideffer, Game Engines as Creative Frameworks 3), and Gamemaker 2 is an example of that kind of framework. Where all of these ideas become truly muddled is when the engine and game are almost the same things.

Gamifying engines is when a game engine is simplified to the point that it becomes something that is intended to be played with, and made more widely available than most engines.

Engines like the RPG Maker series and Project Spark are just a few examples. These gamified engines provide the ability to generate games quickly. Gamified engines vary in their approaches to development with Project Spark being the most gamified of the group (Team Dakota). A gamified engine consists of premade assets and a hyper-simplified code language. In this way, the developer can play with the system to produce a game quickly. Another commonality between these gamified engines is the inability to add code interactions to the system. For example, in RPG Maker MV the developer cannot add any code that does not fit within the traditional JRPG functions (Kadokawa). The minimal coding ability of these gamified engines is core to how they enable simplistic development.

RPG Maker MV falls within the space between full engines and gamified engine. This engine is hyper-focused on their game types. RPG Maker MV is a tool to create 90's era JRPGs.

This tool is relatively popular among first-time developers and hobbyist developers. While not as sophisticated as any of the leading engines, RPG Maker MV does provide a simplistic view of

the development process and allow players the freedom to build games that they want to play.

RPG Maker MV allows for users to export their games into an installable executable which allows for the marketing and sharing of games developed utilizing the program. RPG Maker MV provides ways to explore digital game development conveniently. There are some basics of development that can be gleaned from the process without having to have coding experience or experience as an artist. RPG Maker MV provides examples of how to balance a game as well as the importance of level design and level art (Kadokawa). These simplistic engines can provide scholars with ample opportunity to explore digital game development without having extensive training or knowledge of code or design.

Additionally, scholars could use these tools to construct games designed to educate those that play them. A famous example of a game made using the RPG Maker platform is Always

Sometimes Monsters which was able to tell a deep and engaging story despite the engines technical limitations. This game acts as a proof of concept that shows how RPG Maker could be a platform for the construction of scholarly works intended to communicate with other scholars.

Project Spark, a free to play gamified engine, is an example of an engine which embraces the video game side of the engine and makes developing as simple as possible. Project Spark was developed with the idea that it would be a place for creators to play and players to create (Team

Dakota). Something that set Project Spark apart from anything else at the time was the utilization of controller inputs for any action. Users were able to utilize Xbox controller inputs to code and design their games. Nothing had presented the user with a deeper level of development interaction from a controller before. The use of controller inputs proved to be a double-edged sword as the barrier to entry was remarkably low, yet the number of fine-tuning interactions was

severely limited. The user could not change the base code, or import created assets. Instead, users had a minimal asset collection unless they were willing to pay for the expanded library.

Additionally, users could not export their creations and if they wanted to share the games that they made the other player had to have Project Spark themselves.

Unlike RPG Maker as mentioned earlier users were unable to distribute their creations or sell them on a marketplace widely, Project Spark is more like the creation system available within Doom in that the focus is on user-generated content. Additionally, in both Doom, and

Project Spark the implementation is so rudimentary that the user can create using a controller.

Why Project Spark is a gamified engine and not a level editor like in Doom is that the platform exhibited much the same qualities as an engine. Using Project Spark, the user was able to create the kind of game that they wanted to be it a first person shooter or third person flight simulator the depth of games created by this program where immense. Doom, on the other hand, presented players with the ability to generate content that was much the same as the existing game. What is most interesting about the Project Spark gamified engine is its short lifespan releasing on

October 7th, 2014 and shutting down entirely August 12th, 2016. In that short time Project Spark became incredibly popular among a specific group of gamers and was a tool for creation for those users. Incredibly the gamified engine would be used by Linkin Park to make the music video for their song "Guilty All The Same" (Linkin Park). The exciting thing was that the music video invited viewers to play the game in the video and invited them to edit the level themselves.

The short lifespan for the platform is what should be explored in terms of engines and the success and failure of those engines.

The first issue that Project Spark ran into was the cost of all the assets: to gain all the assets available at launch users had to spend over 100 dollars. On the other hand, RPG Maker sells all base content for 80 dollars, these assets are more than sufficient for any JRPG. Another drawback for Project Spark was the inability for people to work together on the same game file, which extended the time needed to make more complex games. Going back to "The Cathedral and the Bazaar" Raymond states that collaboration is critical within the bazaar style of development (Raymond 8) this is especially true when making digital games in a gamified engine. Project Spark, by removing the potential of collaboration, removed a large part of the development process expected by the user base. It was a combination of missed community expectations coupled with poor business choices such as launching beside Disney Infinity which promised similar development tools led to the downfall of Project Spark. The concept of Project

Spark worked, but in execution, it lacked what both the development hobbyists needed and what game players required.

Gamified engines like Project Spark and RPG Maker MV provide a view into the development process as well as an understanding that development can take many forms and does not have to be inaccessible. The more open a system is, the more likely novice developers will join in the discourse surrounding digital game development as was the case with Project

Spark. Gamified engines make it possible for scholars to gain a rudimentary understanding of the process of digital game development. However, it is also essential to understand the shortcomings of these platforms and why it is that they should not be seen as the same as traditional game engines. Each platform has different drawbacks. As discussed earlier, Project

Spark users cannot collaborate and does not allow for the universal export of the users game.

Additionally, Project Spark has been removed from marketplaces and is only available to those who owned it before the servers being shut down in May of 2016. RPG Maker MV does not allow the user to develop anything outside of a turn-based or narrative based JRPG, and users cannot effectively code outside the system embedded in the platform. The glimpse into development processes and practice that these platforms offer is unique and offers the scholarly developer opportunities to experiment with rapid prototyping.

Project Spark and RPG Maker MV offer excellent examples of the bazaar method of development with the way that they are intended for small teams or solo developers. In the case of Project Spark, everything that was developed and saved went to a central hub of community creations allowing anyone to play what you made and see how it was assembled. In a similar vein, the RPG Maker MV community is very open about how to best utilize the platform and routinely share code and creations. The platforms themselves, however, reflect the cathedral methodology in that they are incredibly sealed to the user base and frequently do not allow the user to see the underlying code that makes them operate, as opposed to most mainstream engines which allow users to change base code operations. For the scholar, these differences can be a boon to the development of small projects. The emphasis on bazaar methods of development offers the opportunity to work as a solo developer or with a small team to better understand the act of development. Having a more open community and fostering a culture of sharing ideas, code, and games helps everyone become better at development.

Raymond's design principles as presented in "The Cathedral and The Bazaar" can be explored in terms of the modding of digital games. Modding is the alteration of or addition to existing digital games. Some modders use existing tool sets, while others alter the game within

its code. There are games like Doom, Divinity Original Sin II, and Far Cry 5 which have built-in tools to create user-generated content (UGC). UGC can help to give game longevity and keep players engaged. These three games offer examples of games which offer the player modding tools inside the game itself and each of these examples offers various levels of freedom to users, as well as various levels of rewards to their users. In examining these built-in toolsets, it is imperative to consider the ways that each reflect the bazaar method of development.

Defining what the differences between mods and UGC is complex since all mods are user generated content for games. Instead of focusing on the differences between the types of content

I will instead focus on the differences in tools and the complexity of the toolset provided. As an example the difference between the toolset for Fallout 4 which contains the engine, assets and code for the full game allowing users to alter anything in game as well as port their own assets into the game (Bethesda Game Studios). While the SnapMap feature for Doom allows users to generate maps with highly limited access to assets and no access to the games code, instead offering an ultra-simplified visual code language ( id Software ).

Doom offers the player the ability to make maps for other players; these maps are limited to single-player or cooperative play. The limitation on the types of play for the maps enables players to focus on the player versus environment interactions and generate exciting content.

Lacking a competitive multiplayer component does limit the types of users willing to create content for the game and so limits the amount of content. Doom's UGC tool is called SnapMap and functions as a simplistic level builder with minor rudimentary code use. Users can place large chunks of the level down, and each piece can attach to others to form massive levels.

Additionally, users can use a tool that makes varying artifacts interact with logic circuits. These logic circuits can perform many tasks from opening doors to spawning waves of enemies ( id

Software ). The ability for the user to generate these simple logic circuits provides little depth for the user as opposed to the other UGC tools like those available for Divinity Original Sin II or Far

Cry 5. Tools like those found in Doom represent minimal user control over the created levels and instead give the user the chance to feel as though they are a part of the development process. In this way games like Doom offer players a glimpse into the development process. In terms of whether this is the cathedral or bazaar method of development, I would suggest that it meets in the middle. While the tools do not offer the user the ability to truly understand the development of the game they can better understand the design choices which were made.

Divinity Original Sin II's UGC tool is intended for the player to use as a replacement or augmentation of traditional tabletop gaming (Larian Studios). Users can generate content by creating maps and smaller scenes in order to generate content for players. The significant difference between this and other tools is that the user cannot create any code or behaviors for the objects or characters. Instead, the intent is that one player will perform the role of dungeon master (DM) in much the same way that a DM does in tabletop roleplaying games. The user that is in the DM role acts as the code making characters move and act in specific ways and adding or removing items and money from players. This game mode is intended to mimic the act of playing a tabletop RPG, and as such, leaves much of the game's interactions to be performed instead of coded (Larian Studios). In this way the UGC generated within this game is unfinished until the exact moment of play and can be performed live in front of the other players. Divinity

Original Sin 2 is an example that is not easily classified and as such proves to be useful. The tool

itself is an exemplification of the bazaar method of development since the campaigns that users create must be acted out with the assistance of the community. In terms of the developers of the game itself, the tool does not aid the player in better understanding the development process for the game itself. Instead, the UGC tools included help the player better understand rudimentary development procedures like balance and player engagement which are learned through playing traditional tabletop RPGs.

Far Cry 5 is different from the other two examples in that it allows players to generate content for multiplayer matches. Additionally, Far Cry 5 presents its users with the most in- depth modding tool of the other examples. What this means for players is that multiplayer maps are unlikely to become repetitive and players can continue to find new multiplayer maps. In addition to this variation for multiplayer, users can also gain experience and money can be gained for use in the single-player campaign (Ubisoft Montreal). Both the act of creating and the act of playing within the UGC economy is incentivized. Players are also given benefits for ranking user creations, and so the better maps will become featured. The use of in-game incentives helps to populate Far Cry 5 with additional content for players. The toolset itself is reasonably broad and helps users to make the most of what is given to them. The only thing that is lacking is the ability for users to code directly. Instead, users must create nodes and give behaviors to in-game characters and objects (Ubisoft Montreal). Far Cry 5 is very close to the tools found in Doom only this tool set offer the user a higher level of interaction with the level design as well as the ability to generate multiplayer content. Therefore the toolset stands somewhere between the cathedral and bazaar methods of development.

Fallout 4's creation toolset allows users to add their textures, 3D models, and code to the existing game. The Creation Kit which Bethesda released along with their game is the same engine that was used to create Fallout 4. Additionally, users can recode the game's interactions and develop new ones (Bethesda Game Studios). Unlike the tools mentioned before the Creation

Kit represents a deeper toolset for users to create content for the game. In terms of "The

Cathedral and The Bazaar," this represents a method of community interaction which most closely conforms to the bazaar method of development. The utilization of the bazaar method could explain why there is a large and devoted base of modders that create content for Fallout 4.

The modding community has created significant campaign expansions for the game and several mods which change the games fundamental inner workings. For the scholarly community,

Fallout 4 represents the most in-depth exploration of the development process of a digital game, by allowing users to interact directly with the development tool and assets. Scholars can use it to learn about the integration of assets into a digital game space and the balancing that occurs when developing a digital game. Modding a digital game does not offer the same benefits as developing a game directly with an engine, but it can offer smaller glimpses into the process and enable a lower barrier to entry.

3.3 Conclusion

Integrating scholarly work which has centered on digital game development, as well as development tools generates a complete image of digital game development. Adding to that just a small part of the work that has been done by the developers themselves and the principles of development integrate with scholarly work to provide an understanding of how scholars can utilize and study development practice. Development of digital games is intended to be

performed by groups of individuals. Likewise, scholars explore game studies in groups seeking to utilize other specialties to produce better knowledge. When examining works like Developer's

Dilemma scholars can see how large development teams and companies can remove the human element from the development process and reduce it to a sterilized and formulaic process.

Meanwhile, examples like Stardew Valley can stand out as a proof of concept that a single highly motivated developer can create a substantial game.

Digital game scholars should account for team size and scope of the project when examining digital game artifacts. By examining written works on development and the tools that can be utilized in game modification and development, it becomes increasingly apparent that more factors are present when developing digital titles and thus careful attention should be paid to the effect that process has on the artifact. As was apparent when examining the academic works on the development process, it is in the vested interest of digital game scholars to approach development and digital game artifacts as a unified whole and not as disparate parts.

Digital games do not exist outside the process by which they are made. Additionally, it is just as crucial for scholars to recognize that digital game development should be a consideration when approaching the study of digital games.

As demonstrated by the simplified development tools found in Far Cry 5, Doom, and

Divinity Original Sin II sometimes a portion of the development process becomes integrated with the game artifact itself. These integrated tools allow for a lower barrier to entry when it comes to providing scholars with experience in developing digital games. Far Cry 5 is an example of rewarding the player of in-game bonuses for creating and playing UGC. As far as scholarship is concerned, these tools provide ample opportunities to explore development without the need of

understanding coding or code languages, while also providing the opportunity to see assets and asset management within the context of AAA games.

Engines like Unity, Unreal, Gamemaker 2 each have their uses for academic development and study. As is pointed out by Robert Nideffer in “Game Engines as Creative

Frameworks”, digital game engines create the limitations on what can be made with them and in so doing generate limitations on the kinds of art that can be made. Each engine assumes something of its user, and so limits the games and gameplay that can be generated from the engine. These limitations are rarely explored by scholars when approaching digital games as a medium. As scholars continue to explore these engines and their limitations the field will gradually conclude that engines like these must be included when examining digital games scholarly. It is becoming increasingly apparent in the scholarship that approaching digital games as an isolated object does not do justice to the digital game as an artifact. Instead, scholars like

Sicart are calling for increased exploration of the social and political realities that surround the digital game. I would add that the manner in which a digital game is produced should be included in the call for a broader approach to the medium. When scholarship is limited than the results that scholars can come to are likewise limited. When scholarship broadens its approach to include development as well as societal factors, then the scholar can conceive of a more dynamic medium.

If the work of scholars is melded with the work of developers, then a complete picture of the medium is formed. When looking at the post-mortems that are available for several games and connecting them to the scholarship that already exist surrounding digital games scholars can gain increased knowledge about the medium. Melding literature from the studies and production

perspective has the potential to extend the lenses already applied to the medium of digital games.

As an example, the post-mortem for Diablo II illuminates the potential issues with a lack of integration testing as was the case with the launch of battle.net (Grossman). Knowledge about the importance of testing systems and features before the launch of a title can aid scholars in better testing their works or in better understanding common development practice.

Digital game scholars would be significantly served by including, as a part of their methodology, an understanding of development practice not to say that scholars should directly develop digital games. Instead, I am suggesting that scholars gain an understanding of what the process entails. The works cited here represent a beginning to that process. As scholars find and read more development documents they will gain a broader understanding of the development process. The benefit to scholars is that websites like gamasutra.com have several current post- mortems available as well as new ones coming to the site all the time. It is this wealth of work that can be the most beneficial to scholars seeking to add production knowledge to their methodologies.

Development-centered textbooks can be helpful to scholars seeking base development knowledge with works like The Art of Game Design. However, these books seldom convey anything other than the step-by-step core of how to develop a digital game or think like a game developer. The issue that arises for scholars is that these works rarely speak from the experience of a single title and instead focus on universal ideas concerning development without considering what might be lost from that generalization. In The Art of Game Design, for example, there is a base understanding of the process of development that can be gained, but Jesse Schell also includes many of his views. Schell’s book is utilized in many development schools for its various

ideas on digital game development despite statements concerning female gamers and development.

Once scholars gain a better understanding of digital game development, whether by direct interaction with engines like Unreal, Unity, or Gamemaker 2 or by using tools like those found in Doom, or Far Cry 5, scholars gain a glimpse into the BlackBox. At the minimum, digital game scholars should acquaint themselves with the literature on digital game development. Even public-facing works like post-mortems would be beneficial to scholars seeking knowledge about the game development process, and these works will enable scholars to gain a better understanding of just what might be within the BlackBox of game development.

CHAPTER 4

SCHOLARLY DEVELOPMENT IN METAGAMING

This chapter focuses on Metagaming (2017) by Stephanie Boluk and Patrick LeMieux.

Metagaming is an example of how development as applied Game Studies could be used to explore scholarly issues. In the case of Metagaming, scholarly work is exploring the ways that digital games are all metagames and how that challenges assumptions made about the medium.

Boluk and LeMieux’s work provides an ideal example for a case study into the benefits and drawbacks of digital game development for scholars.

Firstly, there needs to be a distinction between terms used by Boluk and LeMieux and those I use in this work. Boluk and LeMieux use the term original metagame to refer to their creations, and while within the context of Metagaming this functions. Within the framework I use, this terminology is not beneficial. Since I have defined digital game development in chapter one as “an act which directly contributes to the production of a digital game artifact,” I will stick with that definition. The core of what Boluk and LeMieux are asserting is that digital games are all metagames, which necessitates that they approach development with the same eye.

Meanwhile, I would frame digital game development as the creation of a set of computationally enforced laws which then facilitates the generation of metagames. Since all games require a player to agree to interact with the game as designed, then developers are left to create the laws of the digital space which cannot be altered unless players choose to change the code of the game.

Metagaming is a work concerning itself with the idea that all digital games are metagames since players can interact with digital spaces as they see fit. For Boluk and LeMieux they seek to define metagame as;

”Difficult to design, impossible to predict, deeply collaborative, and always ephemeral,

metagaming undermines the authority of videogames as authored objects, packaged

products, intellectual property, and copyrighted code by transforming single-use software

into materials for making many metagames“ (Boluk and LeMieux 25)

For Boluk and LeMieux, a game's code operates like the laws of physics in a baseball game; it limits the player’s capabilities. Rules and developer intended interactions, on the other hand, “are voluntary constraints and social contracts. They are pacts between players not to peek or move outside invisible boundaries. Mechanics, on the other hand, are ontological operations”

(8). In other words, if a baseball player decided to run from home plate into the outfield, there is no physical law preventing that action, but the action would violate several in-game rules. Boluk and LeMieux argue that code is the law, and rules are socially agreed upon (8-9).

Core to what Boluk and LeMieux do in their work is the definitions that they put forward for metagame. Boluk and LeMieux’s definition of metagame is varied and nuanced. For them, there are several kinds of metagame and they take care to define each. In this way, Boluk and

LeMieux distance themselves from the traditional definition of metagame. One important definition is the developer's intended metagame, which is the game that the developers intended the player to play, for example, playing Super Mario Bros. by collecting all the coins and eliminating all the enemies. Boluk and LeMieux assert that all play is a metagame due to the choice of the player to accept or reject the social contract behind the game. If the player of Super

Mario Bros. were to play the game by avoiding all enemies and coins, then that would be subverting the developer intended metagame, and the player would be generating a new metagame. As Boluk and LeMieux state, these interactions are social pacts and not enforced laws within the game, the player must choose whether or not to engage with the prescribed metagame.

It is this idea that they bring to all their games, Boluk and LeMieux present the player with a group of what they call original metagames. These games help to further the arguments that they make in their written work.

Boluk and LeMieux, unlike others in the field, developed games alongside their scholarly work, intended to be presented in tandem with the written work. While others have developed games for their scholarly work, these have been developed separately and then added to scholarship as they apply. Scholars like Jesper Juul in his work The Art of Failure use games as a means of communication of ideas, however, use the game after the fact and not in tandem with the writing of the work itself (Juul 95-96). Others, like Katie Salen and Eric Zimmerman, in their work Rules of Play: Game Design Fundamentals, commissioned the development of several games to use as examples of the development process (Salen and Zimmerman 106). Where

Boluk and LeMieux set themselves apart is they developed each game for the preceding chapter.

It is rare within Game Studies to find works that include development at all, let alone which integrate development into the approach to the subject matter.

I will focus on the games developed by Boluk and LeMieux and how they help or harm their overall argument. Since these games were developed in particular for this work, they provide a unique opportunity to examine them as a proof of concept for my work and provide a roadmap for how to include digital games in scholarly works. Additionally, while examining

these games, I intend to demonstrate how development practice can be utilized as a means of communication with an audience. The games developed by the pair are found at the end of the first five chapters and serve as an example of the themes of the chapters. These games range from completely original works to revised versions of existing games.

Stephanie Boluk and Patrick LeMieux focus on how digital games act as a collection of metagames and that the perception of digital games as an isolated digital artifact is problematic

(Boluk and LeMieux 7-9). Boluk and LeMieux in their work point to the issues with approaching digital games as “single-use software” (25), instead they point to the ways that digital games can be used as platforms for generating many metagames. Digital game development also points to the error of looking at digital games as single-use software. Boluk and LeMieux do not point to this fact directly and instead utilize development to further their other points. The core of Boluk and LeMieux’s work is undoubtedly vital at this junction in the games studies landscape.

It is essential to draw attention to the fact that digital games are not isolated artifacts divorced from their production. Boluk and LeMieux call for work within the field of Game

Studies to explore the ways that digital games exist outside of their individualized artifacts.

Boluk and LeMieux help to articulate the need for further scholarship on the subject of digital game development and the connotations that the process has on the games that are a result of development. The use of digital game development acts as a call to explore further the implications digital game development has in Game Studies and the idea of metagames in general.

4.1 Memento Mortem Mortis

Figure 1. Memento Mortem Mortis

Memento Mortem Mortis is the game found at the end of Chapter 2 of Boluk and

LeMieux’s work. The game presents the player with the ability to traverse a maze. The mechanics of the game are simple. The player uses the WASD keys to rotate the skull while the arrow keys are used to move the player through the maze (LeMieux and Boluk, Memento

Mortem Mortis). These mechanics work well enough to allow the player to move through space and interact with the digital space to gain an appreciation for the connections between game and chapter. The game illustrates the points made concerning anamorphic games by having the player interact with the game in a nontraditional manner. The effect is achieved by mapping the

3D maze onto the 3D model of a skull. This non-traditional means of play means that movement through the 3D maze is occasionally hindered by the places where the skull lacks a surface or where segments of the skull do not intersect properly. While challenging, this seems to add to the overall message about the illusionary nature of freedom within 3D digital spaces.

Memento Mortem Mortis demonstrates that the concept of the digital game as a communication method for games scholarship is practical. Within Chapter 2, Boluk and

LeMieux discuss the relative nature of space within the digital game. In particular, how a shift from 3D to 2D can affect the player and their understanding of the digital space (Boluk and

LeMieux 110-112). Memento Mortem Mortis helps to expand upon ideas concerning spatial awareness within the digital game by having the player experience spatial confusion when trying to navigate the maze. The ideas concerning the player experiencing spatial disassociation between shifts between 3D and 2D images prove to also apply to 3D spaces imprinted upon 3D images. This game alone acts as a proof of concept that digital game development can be helpful for scholars as well as communicate with other scholars.

The next two games that I will examine are modifications of existing games. The first

Triforce is a modification of the game The Legend of Zelda (1986). The Legend of Zelda follows the protagonist Link as he seeks to save the princess Zelda from the evil Gannon (Nintendo

R&D4). The player interacts with the game by exploring the various locations of the kingdom of

Hyrule, killing monsters, and solving puzzles. The second game, 99 Exercises in Play, is a mod of the game Super Mario Bros. (1983). Super Mario Bros. follows the titular plumber Mario as he seeks to save the Princess Peach from the evil Bowser (Nintendo R&D4). The player interacts with the game by moving and jumping over obstacles or onto enemies. These two games provide a known model for Boluk and LeMieux to build upon, making it possible for them to communicate more effectively. While utilizing known games makes some communication simpler, it can also give scholars more issues due to player expectations.

4.2 Triforce

Figure 2. Triforce The issues with scholarly development do become more apparent when examining

Triforce, the game attached to the first chapter in Metagaming. Triforce takes from the original

Legend of Zelda game and places parts of the game on 3D objects, adding a 3D manipulation mechanic to the original games content. Boluk and LeMieux, in their first chapter, seek to define metagames and metagaming. As they put it metagaming is, a social creation that serves as a subversion of the intended use of game artifacts (Boluk and LeMieux 25). The issue becomes that their first metagame Triforce acts to subvert some of their claims. Instead of giving the player a game seeking to undermine videogames as authored objects, Boluk and LeMieux give the player a defined game with defined goals and tell the player that the game intends to demonstrate how the 2D game was always mapped to a 3D space (25). The issue stems from the claim that metagames are generated by the player, either accepting the developer's social contract or creating new rules for the game. Having Boluk and LeMieux act as developers and as a player by claiming that their work is an original metagame problematizes the definition that they put

forward in the chapter. Unlike Memento Mortem Mortis, which also concerns itself with the 3D space, Triforce is not as effective in communicating the effect to the player.

Insistence on referring to games exclusively as metagames creates an additional hurdle with those they develop and reference. When it comes to Triforce, the insistence on not calling the games they develop games muddies the definition set forth in the chapter, especially when it comes to player choice. Instead, according to Boluk and LeMieux’s logic, it would be simpler to address their games as metagame platforms. At times this insistence can generate a disconnect between the game and chapter. It is important to note that these issues are minor when compared with the importance of the overall work performed by Boluk and LeMieux. I would have preferred metagame platforms to illustrate more fully the idea that it is acceptance or rejection of a metagame that completes it.

Figure 3. Triforce Fire Rate Triforce does not wholly fail in its execution; the game does play and is capable of communicating the open nature of metagames. The player is free to engage the content as they wish moving through the 2D and 3D spaces. (LeMieux and Boluk, Triforce). The use of texture

mapping again makes it possible to visualize the 2D game on 3D textures. The 3D shapes that the game is projected on vary depending on the type of level. The topography aids in driving home the point made about the differences between laws and rules (Boluk and LeMieux 35-36),

Triforce alters the laws of the game by utilizing the 3D space and making the player rotate the

3D objects to see the path forward for Link. As for the rules of the game, those have been set by

Boluk and LeMieux as with any other game, and the player can choose to obey or resist. As is pointed out by Boluk and LeMieux, metagames are what happens when the player breaks those rules, intentionally or unintentionally.

The gameplay of Triforce presents an interesting and engaging method for communication; however, the issues with the 3D space hinder that communication somewhat.

The rotation of 3D objects is sensitive, creating unnecessary confusion when playing through the

3D portions of the game. The rest of the mechanics function identically to The Legend of Zelda with a few exceptions. These exceptions include the fire rate of the enemies as well as the lack of a projectile when at full health. In particular, the fire rate of the enemies makes traversing the world more complicated than it needs to be and should be tuned to accommodate the alterations from 2D to 3D. Technical issues like these detract from the message of the game. When players can interact with the game space smoothly, then scholarly communication occurs more smoothly.

Games like Triforce suffer from an apparent lack of playtesting, and as such, become less playable by a broader audience. For this reason, it is essential to have playtesters from outside the development team play the game. Playability is critical in communication between the scholar and audience, and if a game has fundamental design flaws, those need to be addressed before they are released.

4.3 99 Exercises in Play

Figure 4. 99 Exercises in Play

99 Exercises in Play experiments with the first level of the popular Super Mario Bros. game. The game centers on getting Mario through the level while each time that the player does, the level is altered in one way or another (LeMieux and Boluk, 99 Exercises in Play). The level can be squished or layered onto a 3D object. Each of the alterations to the level provides the player with an increase in difficulty and a new way of approaching the classic level. Boluk and

LeMieux placed this particular game at the end of chapter 4. In this chapter, they focus on issues surrounding the context of play and how playing games with multiple settings can expand the metagames possible. For example, Boluk and LeMieux discuss playing various games at the same time or playing multiple instances of the same game at the same time (Boluk and LeMieux

186-187). 99 Exercises in Play helps the reader to experience this feeling by having levels 27-30 be increasing division of the level with multiple screens playable at the same time (LeMieux and

Boluk, 99 Exercises in Play).

Boluk and LeMieux also reference the various ways in which Mario games have been remade or turned into metagames. Examples range from mods like Kaizo Mario or mods that turn Mario into various famous Nintendo characters to levels made in Super Mario Maker. These examples all revolve around the idea that metagames can provide the user with new ways to experience older games like Super Mario Bros. They also demonstrate how there can be multiple inputs and outputs to a game (Boluk and LeMieux 192-194). These examples illustrate the effectiveness of manipulating inputs and outputs when it comes to playing and making metagames. Likewise, 99 Exercises in Play seems to be an amalgamation of all these in one game, allowing players to experience these effects.

99 Exercises in Play does an excellent job of driving home the point made in the chapter and gives the player an experience that the text cannot communicate. Play can communicate the mechanics of the kinds of games/mods that Boluk and LeMieux discuss in the chapter. This example demonstrates another benefit to the scholarly process by aiding others in experiencing something akin to what the scholar experienced in researching for their work. In much the same way that Memento Mortem Mortis provides insight into its chapter, likewise, 99 Exercises in

Play supports its chapter. Unlike Memento Mortem Mortis, however, 99 Exercises in Play becomes more integral to the chapter it is attached to by empowering the scholarship through interaction with referenced mechanics. 99 Exercises in Play is a proof of concept that digital games scholarship can utilize development to demonstrate the kinds of mechanics that are referenced when applying scholarship. Digital game development can be useful for scholars as long as that development is carefully approached, and the scholar sees development as a part of

the research methodology. When these factors are not a part of the development process, then scholars can create works that do not help but instead hinder their work.

4.4 Significance to the Field

Metagaming stands as an excellent example of scholars applying digital game development to their study. These examples are not always positive for the work, but they do illustrate the need for further study into the development of digital games. As of the time of writing, this Metagaming represents one of the most significant integrations between development and scholarship. The lack of reference to the development of digital games as scholarship is conspicuous, but understandable given the focus of the work. As far as this work is concerned, the focus is on the games themselves and how they contribute or detract from the overall work presented by Boluk and LeMieux. As stated earlier, 99 Exercises in Play and

Memento Mortem Mortis provide insight and depth to the chapters that they are attached to.

These provide proof of concept that the digital games developed can be a tool to further the ideas presented by scholars.

The games accompanying Metagaming were all developed using the Unity engine. It is important to note that this engine is popular among indie developers and is an excellent tool for the kinds of games featured in the work. Unity provides a more robust tool to make games in several genres, which is why Boluk and LeMieux can make games like Triforce and 99 Exercises in Play. The Unity engine provides users with tools for both 3D development and 2D development, unlike both Unreal and Game Maker. Since Boluk and LeMieux use 3D texture mapping of 2D games to make both Triforce and 99 Exercises in Play, the Unity engine would

be the best fit for that experience. Not to say that the only engine that scholars should use is

Unity. Instead, it is essential to factor in engine selection when developing digital games for scholarship. In this case, Boluk and LeMieux chose the correct engine and utilized it wonderfully to create the games that they sought to make.

More critical than engine selection is the subject matter that the scholar is approaching with their game. Boluk and LeMieux utilized their games to make the most of the scholarly topics that accompanied them. Triforce, while having some issues, did succeed in approaching the idea of metagames and what they can be while games like 99 Exercises in Play took the scholarly work further by allowing the reader to interact with the mechanics, which were being discussed.

Games like 99 Exercises in Play and Memento Mortem Mortis provide insights into how digital games can be utilized as a means of communicating mechanics. Digital game mechanics are difficult to describe or show to others. The simplest means to communicate a mechanic is to allow someone to play the game themselves. By interacting with the described mechanic, the user can gain a full understanding of the mechanic, which is difficult otherwise. 99 Exercises in

Play provides an excellent example of how a mechanic is communicated through a digital game.

Chapter four of Metagaming discusses metagames that utilize either multiple inputs or outputs to challenge the ideas prevailing within digital games. The game 99 Exercises in Play provides the opportunity to experience these effects by altering the play space of Super Mario Bros. world 1, level 1 (1-1). Boluk and LeMieux’s alterations to this iconic level and the alterations to gameplay work seamlessly to communicate the needed mechanics referred to within the chapter itself. 99

Exercises in Play provides a clear demonstration that digital game development can be useful within the scholarly context.

Digital game development has a place within scholarship, and Metagaming acts as a proof of concept that when game scholars utilize development tools and training that they can effectively communicate the core of their scholarship interactively. Mechanics can be the most difficult thing to relate to others. It is possible to communicate mechanics to another person effectively. However, these descriptions typically revolve around other mechanics. For example, the movement of a 2D character along a 2D plane with obstacles and enemies which the player must avoid by jumping is referred to as a platformer. The term platformer then becomes shorthand for a collection of mechanics, which the speaker assumes that the listener has experience. The issue arises when there is an individual who has never experienced these mechanics, then the term loses all meaning. Simple games like 99 Exercises in Play become invaluable since the game introduces the core mechanical loop of a platformer to the user. In this way, scholars will be able to communicate with each other more effectively through digital game development.

Digital game development should be strongly considered by scholars seeking to explore the mechanics of a digital game. The act of replicating mechanics allows for a deeper understanding of that mechanic. This idea becomes apparent when examining Boluk and

LeMieux’s work, Memento Mortem Mortis. The ideas explored in chapter two concerning the visuals of digital games and how one can manipulate those visuals are represented clearly in the game. Additionally, the mechanics utilized were able to communicate the ways that visual manipulation can create an unruly digital experience. In Memento Mortem Mortis, the player can

shift the direction that the central skull is facing as well as maneuver the internal camera around the maze. The dual controls explore notions of games utilizing both 2D and 3D dimensions.

The games developed by Boluk and LeMieux collectively serve as a proof of concept that digital game development can prove to be beneficial to digital game scholars. The model presented within Metagaming while helpful for understanding the potential for digital game development may not fit the scope of other scholars' work, Jesper Juul’s inclusion of one game in his work The Art of Failure, for example. I am not suggesting that scholars produce a game for each chapter of their work, or that they develop games at all. Instead, I am suggesting that scholars explore the benefits of utilizing digital game development for their scholarship. I understand that if a scholar were to be exploring the effects of violence in video games that developing a violent video game might not aid in their endeavor. However, perhaps in the development of that game, the scholar would discover new questions to ask in their scholarship.

4.5 Conclusion

As scholars approach digital game development as either a means of communication or as a means of exploration of scholarly hypothesis, a side effect will be that they gain a better understanding of the overall process of digital game development. The idea that scholars could gain a minor glimpse into AAA digital game development would be beneficial to the scholar.

Looking at disciplines like literary studies and film studies, it becomes clear that a basic understanding of the production of a medium is beneficial. Within film studies, scholars understand the technical processes to achieve specific camera effects and the desired outcome of those effects. Likewise, digital game scholars can benefit from exploring the means of executing digital game mechanics. Any digital game development at all will aid scholars in approaching

digital game mechanics. By engaging directly with the rules that make up a mechanic, scholars will better understand how that mechanic functions and how it can be executed. It follows that once a scholar gains an understanding that they would be better equipped to explore games featuring the same mechanic. When a scholar plays Super Mario Bros., and they jump from platform to platform, they experience that mechanic. However, when scholars like Boluk and

LeMieux make a game like 99 Exercises in Play, they must understand the code behind that mechanic and therefore gain a better understanding of its implementation. When scholars develop digital games, the understanding of how code interacts with the inputs and outputs helps to remove the black box from digital game development.

The reality is that digital game development and similar modding and UGC tools have made it simpler than ever to begin developing digital games. Tools like Unity and Unreal Engine

4 are free for users and have included some basic tutorials to give first-time developers a basic understanding of the way development works with their tools. Game Maker 2 is not free, but it does provide a very accessible start to digital game making. Then there are gamified engines like

Dreams and RPG Maker, which offer the user the ability to develop games without the need to understand complex code languages. The point is that these tools are accessible, and the underlying code and use of the tools can be taught through video tutorials. What this means for scholars is that they will be able to code and develop mechanics very similar to those found in other digital games. Once digital scholars begin to experiment with digital game development, they will discover new questions to explore within the field. The act of digital game development can and will expand the field as a whole.

Not every approach to digital games would benefit from digital game integration. For example, Developers Dilemma would very likely not benefit from the development of a digital game since the focus of the work is not the games developed or the use of development, but the effect that AAA development has on the human participants within that process. Meanwhile, The

Art of Failure utilizes one digital game as an example of the kind of games that Juul discusses in that work.

The development of digital games can benefit not every work as a means of communication. Digital game development as a means of research, however, can be beneficial for many Game Studies scholars. Digital game development can be used to understand better the theory explored by scholars. This method of approaching digital games is scarce within the field; during my research, I have found only Developer’s Dilemma as an example of digital game development being at the core of someone’s methodology. Even in this case, O’Donnell does not explore development as a means of testing or approaching scholarly hypothesis but instead utilizes development to approach those that practice development professionally. Game Studies scholarship could be benefitted by development as a means to test and explore theories within a methodological framework. I believe that this idea deserves further exploration than what I have been able to provide here within this chapter.

One of the most significant issues with the approach to digital game development for scholars is the black-boxing of development. Digital game development on the AAA level is incredibly obscured, making development something that is seen as inaccessible. When digital game scholars develop digital games for their scholarship but do not discuss the development process for the games utilized, they contribute to the black-boxing of development. I would

suggest that when digital game scholars develop a game to go along with their work that they include a small description of the development process1. The black-boxing of digital game development continues to contribute to the belief that digital game development is inaccessible and unknowable.

Metagaming is a proof of concept that digital game development can help with communication within the Game Studies field. What it does not do is explore how digital game development can aid in the performance of Game Studies. At the time of writing this, there is no scholarly work that explores the ways that digital game development can be a tool for Game

Studies scholarship. Metagaming demonstrates that digital game development is key to the future of Game Studies. The games that Boluk and LeMieux developed for their work act as a critical component of their scholarship. Game Studies ought to begin to utilize the availability of development tools and the decreasing barrier to entry when it comes to those tools as a means of research and communication. As this occurs the field to develop new ways of communicating ideas and new means of understanding the digital game medium. It is crucial to Game Studies that works like Metagaming be explored not only as a written academic artifact but also as a digital game artifact which is more complicated than it is credited. As more scholars utilize development tools in their scholarly work, Game Studies as a field should take notice of the ways digital game development can support scholarship.

1 An example of the kind of description I am referring to can be found in Chapter 7 of this work.

CHAPTER 5

PLAYING WITH DEVELOPMENT TOOLS IN DOKI DOKI LITERATURE CLUB AND

DREAMS

5.1 Doki Doki Literature Club

Doki Doki Literature Club utilizes development tools and practice to delve deeper into the game's narrative and asks the player to interact with the game’s root files. Additionally, the player is allowed access to files and folders typically hidden by developers; this provides unique access to the inner workings of the game. Dreams provides a further look into games that seek to reduce the space between digital development and the user. It is for these reasons that examining

Doki Doki Literature Club and Dreams in the context of independent development is helpful to the overall conversation about development.

Doki Doki Literature Club is a game by Team Salvato which follows the tropes of dating sim and virtual novel genres. The game features four anime girl archetypes commonly found in these types of games. Their names are Monika, Natsuki, Yuri, and Sayori (Team Salvato). The twist is that Monika becomes self-aware and makes it her mission to have the player choose her as her romantic interest. Monika achieves her goal by altering the other girls’ programming to make them less appealing to the player. After this fails, she decides to delete the characters outright, resulting in their deaths (Team Salvato). The game's narrative progresses in a helix style, allowing the player freedom at moments, but then collapsing in on itself at certain pivotal moments. Other games that are helix style would be The Walking Dead, Mass Effect, and many others. A helix narrative typically allows the player to make choices that impact the narrative in minor ways while the core narrative collapses down to a single narrative event. Once one of

these events is over, the player will then regain the ability to impact the game’s narrative until the next event. The player’s choices become increasingly limited as the pool of characters becomes whittled down, leaving only one character to interact with, ultimately collapsing the narrative into a single stream.

Where Doki Doki Literature Club becomes applicable for this work is in the fact that there is a considerable amount of narrative that lies outside the game. On the Steam page for the game, it states, “Hi, Monika here! Welcome to the Literature Club! It's always been a dream of mine to make something special out of the things I love” (Team Salvato). The game description ends with, “But I can tell already that you're a sweetheart—will you promise to spend the most time with me? ♥” (Team Salvato). Near the end of the game, Monika even references this page, saying, “I even told you right on the game’s download page didn’t I” (Team Salvato). Monika tells the player that she has been altering the game’s base code, and she has done so to be alone with the player. The section where the player and Monika are alone heavily references the developed and digital nature of the game. Monika points to the alterations she has made to the code, telling the player the location of the folder containing all of the characters’ files. These interactions are important in terms of this dissertation; this dissertation will focus less on the in- game interactions and more on the ways that the game encourages player interaction with the files of the game itself.

Figure 5. Doki Doki Literature Club For instance, the only way to proceed to the end of the game is to delete the Monika character file. Deleting her character file triggers the end game, Monika comes to the realization that the game needs to be destroyed, she corrupts the game's root files rendering the game unplayable (Team Salvato). While the main narrative of the game is progressing, there are several moments when new files appear in the game’s root folder. These files contain extra bits of narrative hidden within standard text created if a player were to debug a malfunctioning game.

These include a debug.txt file, a log.txt, and a traceback.txt file; these files become altered as the player engages with the game, adding new narrative and background for the choices Monika makes. In one example, the traceback.txt file appears and states,

“I'm sorry, but an uncaught exception occurred.

While running game code: File "game/script.rpy", line 67, in script call File

"game/script-ch5.rpy", line 290, in script File "renpy/common/00start.rpy", line 260, in

renpy.call_in_new_context("_main_menu")

JumpException: Oh jeez...I didn't break anything, did I? Hold on a sec, I can probably fix

this...I think... Actually, you know what? This would probably be a lot easier if I just

deleted her. She's the one who's making this so difficult. Ahaha! Well, here goes nothing”

(Team Salvato).

Figure 6. Doki Doki Literature Club Traumatic

The file reads like a typical debug note found during development, with the exception that the one making the note is Monika. Added notes from Monika, like this one, illuminate the character’s intentions within the narrative and her interactions with the code. There is also additional narrative content if the player looks at the lines of code referenced in these logs as they point to Monika’s alterations to the code of the game and just what systems she is targeting.

The deep interaction with the game’s files and the continuation of the narrative of the game is key to understanding the depth of development interaction expected of players.

After Monika kills Sayori, an image appears in the game’s root folder (Figure 5). The image appears to be a disfigured image of Sayori; as the story progresses, the image becomes removed. If the player takes the time to remove the corruption from the image, then a new and disturbing image appears (Figure 6). The disturbing imagery from the game’s interactions seems to spill out of the digital space and into the real world. In addition to the image, written objects continue Monika’s story outside of the game. Monika posts a poem about corrupting the other characters’ code after an intense segment with Yuri and Natsuki, titled CANYOUHEARME.txt.

"There's a little devil inside all of us."

Beneath their manufactured perception - their artificial reality - is a

writhing, twisted mess of dread. Loathing. Judgment. Elitism. Self-doubt.

All thrashing to escape the feeble hold of their host, seeping through every

little crevice they can find. Into their willpower, starving them of all

motivation and desire. Into their stomach, forcing them to drown their guilt in

comfort food. Or into a newly-opened gash in their skin, hidden only by the

sleeves of a cute new shirt.

Such a deplorable, tangled mass is already present in every single one of them.

That's why I choose not to blame myself for their actions.

All I did was untie the knot.

I hate this. (Team Salvato).

The poem provides both a connection to the other poems heavily featured in the game and a glimpse into the character Monika. She claims that she does not blame herself for the other characters’ actions and that she just accentuated existing personality traits. The last line, “I hate this” (Team Salvato) is telling, giving more depth to Monika than through the game itself.

Interactions like this one are why Doki Doki Literature Club is vital to understanding the ways that digital game development is present in digital game interactions. While all interactions within digital game spaces are developed and coded, Doki Doki Literature Club makes those connections apparent and utilizes them to tell a more engaging narrative.

Later, after Monika attempts to get the player to love her fail, another file titled iiiiiiiiiiiiiiiiiiii.txt appears in the games root folder.

“I CAN'T DO ANYTHING. NOTHING.

No matter how many times you play. It's all the same.

It would be really, really easy to kill myself right now. But that would mean I don't get to

talk to you anymore.

All I want is for you to hate them. Why is that so hard?” (Team Salvato)

Like the files mentioned earlier, this stays for only a small period before being removed from the folder. Monika does reference this particular file at the end of the game, stating that she considered killing herself at one point (Team Salvato). The interwoven nature of the game's narrative moving from one type to another is one of the most substantial reasons for its inclusion in this work. The game’s main narrative repeatedly references the digital nature of the game. It encourages the player to interact with the game's files and folders to discover a more in-depth narrative.

Doki Doki Literature Club asks its players to be familiar with the computational side of digital games. The volume of narrative hidden behind code and other development tools and practices is unusual in the digital game space. The depth of narrative integration between game and developmental practice provides an example of how digital games can focus on the computational nature of the digital medium. When the game hides narrative in a log file or code, it pushes the player to get tools to decipher the code presented. For example, at the end of Act 2 when Yuri dies, a file called “have a nice weekend” (Team Salvato) appears; if the player uses the password, libitina, the file becomes unlocked. After unlocking the file, the player has access to a jumble of characters which are Base64(a type of alphanumeric code used for binary to text encoding). When translated from Base64 into English, it reads, “What is a man without knowing the rich aroma of the future; the hot, complex balance of the present; and the bittersweet aftertaste of the past” (Team Salvato). The text then paired with the visual of sitting in a room with Yuri’s corpse all weekend illuminates Monika’s shock at the player experiencing that horror as disingenuous. This example demonstrates the lengths that the developer went to, to hide some of the game's narrative. Hiding some of the narratives behind layers of file interaction and development decoding helps the player to see the development process and better understand the inner workings of the game.

By engaging the player through file interaction, Doki Doki Literature Club incentivizes exploration of the development process; while discovering the many hidden clues to the game's narrative players gain some understanding of digital game development. Hiding clues to the more in-depth goings-on within the game can lead players to utilize more complex development tools. In my experience with the game, I downloaded the latest version of python code language

to gain access to the game's code, allowing me to continue tracking leads like, “File

"game/script.rpy", line 67, in script call File "game/script-ch5.rpy", line 290, in script File

"renpy/common/00start.rpy", line 260, in renpy.call_in_new_context("_main_menu")” (Team Salvato), as mentioned earlier. While not every player will interact with the game, in the same way, most will see the files in the root folder and notice references to lines of code and to the small changes Monika is making to the game. These minor references to the developed nature of digital games are important beginnings to understanding development as a process and narrative tool.

Doki Doki Literature Club demonstrates how digital games can utilize development tools to continue the game's narrative outside of the digital game artifact. There is also an added benefit by hiding some of the game's narrative behind code and development knowledge, some of the game’s players will seek out that knowledge, thereby removing some of the adverse effects of blackboxing. Team Salvato even included a note at the beginning of each code file,

“Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction”

(Team Salvato). As the player delves into the software to uncover more of the narrative of the game, they will also inevitably come in contact with the note granting the player free use of the code contained within. For some modders, the game maintains the cutesy charm of the first segment, becoming a full dating sim. However, by allowing players to modify the game freely, the developers grant other players the ability to extend into the darker bits of the game.

The open encouragement of modding the game down to its code opens the game up to unintended narratives. These narrative alterations are the natural consequence of allowing

players into the designed space of the digital game. Once the playerbase is allowed access to the interworkings of a digital game, they will alter the game to fit their ideas about the narrative and interactions. The open nature of Doki Doki Literature Club aids in removing the barriers to understanding digital game development. Adding the ability to change the game and how it functions allows the player to gain an even greater understanding of the digital development process. Doki Doki Literature Club provides an example of utilizing play to get individuals to see the development process and slowly choose to integrate themselves into that process. Doki

Doki Literature Club is not unique in its desire to bring players into the development process.

5.2 Dreams

As I have touched on earlier, gamified engines provide a lower barrier to entry into digital game development. These gamified engines provide a similar understanding of digital game development without the need for understanding coding languages. Doki Doki Literature

Club provides understanding only to a point. If the user does not understand how to access the game's code or the software to do so, that proves a barrier to player access to the full narrative of the game. Gamified engines, on the other hand, provide players with the ability to access development style tools without the need for complex coding actions.

Dreams released in 2019 for the Playstation 4(PS4), allows players an unequaled level of freedom when developing games. Users can choose what aspect of development they like the most and focus on that. The freedom to specialize results in teams unintentionally forming to put together larger projects (Media Molecule). Some users create portfolio-like spaces in order to attract others with whom they can collaborate on larger projects. One of the game's limitations is that it is only available on the PS4; this limitation means that a broader audience cannot interact

with the game. However, the console limitation does provide a preexisting structure for sharing content and collaboration. Dreams, at the time of writing this, has been available for a few months and already has some impressive creations within the game. While the majority of creations are not vast, the toolset has enabled many creators to craft remarkable content (Media

Molecule). Dreams gives users access to modeling and texturing tools, and there is a broad visual spectrum within the game as a result.

The open nature of Dreams helps to clarify digital game development and the kinds of processes that occur within that space. The need for a development pipeline becomes apparent when using Dreams. This gamified engine helps the user understand the specializations and experience needed to make something great. Many of the top games on Dreams were created by teams collaborating to bring a broader unified vision to life. Collaborators may not even know that they have helped another user make their game since many contributors create characters and upload them for public use. Many of the most popular games in dreams have “uses creations by” lists which contain hundreds of names, these can be a single art asset found on a wall or a significant amount of code (Media Molecule). For users who collaborate and credit each other for work directly are listed as “in collaboration with” (Media Molecule). These designations help to understand what users were directly involved with the decision and development process for the game while crediting those users who made assets for public use. Additionally, some users generate music and other assets, allowing the public to use those assets to make their games.

Something that connects Dreams to the larger game development field is the ability to specialize.

In development teams, some individuals specialize in one particular part of the development

process. The mix of specialization and frequent uploads of everything from characters to code makes Dreams a valuable tool for examining digital game development.

Much like Doki Doki Literature Club, Dreams utilizes play to entice users to learn more about the development process. However, Dreams goes further than Doki Doki; because the game revolves around development as users play with the vast array of systems, they learn how to model and texture characters. They also learn how to make those characters interact with the world around them.

Figure 7. Dreams Code

Dreams utilizes a visual coding language where players connect various nodes to facilitate the desired interaction (Figure 7). The visual code language is simple to grasp and complicated to execute. The need to draw connections between various items can lead to the creation space becoming cluttered with wires. The nodes allow for users to code very complex interactions without ever having to write a line of code, meaning that beginner developers can

make extraordinarily complicated games. Code is at the core of any digital game, and Dreams makes coding accessible to anyone wanting to use their game. The issue that arises by simplifying code is that fine tuning and focusing mechanics becomes increasingly difficult since the visual code language prevents editing just one line of code. Instead, if users want a sophisticated interaction, they need to create large canvases of visual code. Luckily, it seems as though Media Molecule has foreseen this issue and made it possible to condense code onto the games microchips (Figure 7), saving visual space.

5.3 Conclusion

Games like Doki Doki Literature Club and Dreams act to demythologize digital game development. When players and scholars interact with games like these, they begin to understand how digital games are made and thereby begin to see into the black box. When the development process becomes transparent, then more questions can be asked about development and how it can become beneficial to scholars. How an artifact comes into being is essential to understand the finished artifact better. There are many fruitful ways to analyze a digital game. However, all methods would benefit from a better understanding of the development process and acknowledging the developed nature of the medium. With games that aid in understanding digital game development, whether unintentionally like Doki Doki or intentionally like Dreams, digital game scholars can utilize these games as a launching point to understanding digital game development.

These games are by far, not alone in the marketplace. Many games provide players with the ability to generate content for their game. User-generated content is one way to prolong the longevity of a digital game. Games like Doom provide users with tools to generate new content

for the game. These tools are far less sophisticated than those found in Dreams, but they can be used to understand development and design principles better. Tools that scholars can look at for a better understanding of digital game development are found in games like Far Cry 5, Doom,

Super Mario Maker 2, and Project Spark, to name a few. The wide range of tools on multiple platforms gives scholars ample opportunity to experience a simplified version of digital game development.

It is important to note that gamified engines and user-generated content tools do not give a complete development experience. There are intricacies lost when translating code into something approachable by most audiences. Something like Dreams, which I would argue is the closest, is not the same as programs like Unreal or Unity. Instead, these games only offer the user a glimpse into the development process. Digital game development is a complex undertaking, requiring the user to understand multiple aspects of the development process. It is possible for one person to understand and perform each role, but it is incredibly challenging to produce quality games by oneself. With games like Dreams, it is possible for a single person to make a reasonably complex and visually appealing game with little to no expertise in the various aspects of game development.

There has been a rise of scholars calling for research to approach digital games as more than the artifact itself (Boluk and LeMieux, Jones, Sicart). These scholars frequently point to the need to examine digital games as produced objects. Games like Doki Doki Literature Club and

Dreams work to illuminate the produced nature of digital games. These games illuminate the importance of digital game development in the discussion on examining digital games outside of the single artifact. Digital games are beginning to be explored in a context outside of play alone.

However, there is little conversation on the importance of development within the context of the digital game artifact. With a game like Dreams, scholars can gain a simple understanding of the development process and as such, include development within their approaches to games.

Digital game development experience is not wholly universal; each engine and code system behaves differently. Gamified engines like Dreams are not a substitute for experience with the engine used to make the game. However, it does provide the user with a baseline understanding of the logic and planning required to create games. Instead, games like Dreams should be looked at as a tool to better understand digital game development as an overall process. If scholars wish to better understand the development process of a specific game, then they should explore the engine with which the game was made. A better way to understand a game would be to develop a mod for that same game, but very few games allow the player into the game’s full code and assets; thus, developing a mod can be a daunting task. Game studies scholars can utilize the tools found within Dreams to create games without the need to understand coding languages.

A game like Doki Doki Literature Club, unlike Dreams, does not want their users to make a new game. Instead, the player is encouraged to discover the methodologies used to make the game itself. The player is pushed to interact with the game's files and folders and as such the game is pointing the player toward the produced nature of the game itself. While scholars seek for ways to illustrate that digital games are not exclusively isolated artifacts but are instead complex works that exist within a larger world, Doki Doki Literature Club is itself pointing to the fact that the game exists outside of the interaction between player and game. Including narrative within the game's code and hidden behind developer interactions pushes the player into

the realization that games exist outside the game space. The aspect of the game existing outside the mediated space is one of the most horrifying aspects of the game. When Monika breaks the fourth wall and begins to refer to the game space and computational space, then the player is forced to recognize these different spaces. By pointing to the developed nature of the game and making the player interact with the computational components of the digital game space, the developers force the player to recognize the false dichotomy constructed around the game artifact.

Similarly, Dreams centers on digital game development; its players must interact with the reality of game development. By having players build their games, Dreams illuminates the constructed nature of digital games. Creating digital games and experiencing the process of development demonstrates just how much more there is to digital games than play. Just like recreational players, digital game scholars would also benefit from utilizing a game like Dreams to perform simplified development in order to realize that a game is much more than play. By recognizing that digital game artifacts do not exist inside a bubble, more significant questions about digital game artifacts can be asked. Questions regarding the development of digital game artifacts should become more commonplace as more scholars become acquainted with digital game development practice. Games like Dreams can help foster these questions and discussions.

When approaching digital game development, it is far too easy to be distracted by screen essentialism and forget that there is more to the game than interaction. Digital game interaction must be coded, planned, and designed. These processes are far too frequently dismissed or undervalued within digital game scholarship. Games like Dreams and Doki Doki Literature Club demonstrate that digital game development can be accessible and utilized within the context of

play. Scholars should pay attention to the development process and focus on how this process impacts the remainder of gaming scholarship. The lack of reference to development processes within most scholarship only serves to reinforce screen essentialism and the black boxing of development processes. If scholars would merely point to the developed nature of the digital games, they would emphasize the fact that digital games do not exist inside of a vacuum. Instead, far too many scholars brush past this critical facet of digital games and choose to focus entirely on the scholarship they wish to pursue. In itself, this approach is not flawed, and I am not asserting that these scholars wish to contribute to screen essentialism or black boxing. However, by not referencing development, the process becomes increasingly opaque. When scholars address the developed nature of digital games, they also illustrate the flawed nature of screen essentialism and the flaws in accepting black boxing as standard practice.

In exploring games that straddle the line between game and development tool, or games that lead the players to use and become cognizant of development, scholars can see the ways that knowledge of digital game development is beneficial. These games, especially Dreams, can be used to gain a rudimentary understanding of digital game development. Looking at something as simple as Super Mario Maker 2 can teach scholars some of the most basic tenets of digital game development. Playing these gamified engines can illuminate development in its most fundamental way, with little effort on the part of the scholar. For a scholar to understand the need for scholarship on development, it is in no way necessary to make a AAA level game in the

Unreal Engine. Instead, scholars may gain the basics of development from something like

Dreams, never even having to learn code language.

It is essential to understand code and code systems, and the more in-depth the knowledge of development, the better for the scholar choosing to utilize it. However, to claim that the only people qualified to approach digital games as a medium are those who have made AAA scale games and who have a deep understanding of code would be erroneous. Instead, I would suggest that scholars are better served in understanding the fundamentals of digital game development and that addressing the developed nature of digital games should be standard practice. With this as standard practice, more scholars would dismiss screen essentialism and proceduralism, demonstrating that the digital game artifact is a produced object and that production matters to analysis.

CHAPTER 6

COLLABORATIVE DEVELOPMENT IN THE ART OF FAILURE

The Art of Failure focuses on the role of failure in digital games. Juul argues that failure is the defining characteristic of digital games since, for him, failure is a planned state in digital games and that no other medium plans for those interacting with it to fail (Juul 69-70). Juul examines the various kinds of failure which are integral to all games, digital and analog.

Something like Super Mario Bros. incorporates failure in many ways; for example, Mario can die by hitting any of the enemy units, or the player can fail if the level timer runs out. Juul adds another type of failure where the player is successful in the mechanical task. However, narratively, the character fails; for Juul, these tragic endings are interesting intersections between mechanics and narrative (Juul 93-95). It is the concept of the tragic ending that Juul chooses to focus on as the premise for the game that he designed.

6.1 The Art of Failure

Jesper Juul, in his work The Art of Failure, developed, in conjunction with Albert Dang and Kan Yang Li, a digital game where the goal is to commit suicide. The purpose of this game was to demonstrate that failure can be the goal of a digital game. Juul spends the majority of this work, arguing that the thing that sets digital games apart as a medium is that failure is core to the experience. To more fully demonstrate how failure can be the goal of a digital game, Juul’s team developed a game to make their point. Juul’s central thesis for this game is to demonstrate that players would intentionally play a depressing game. Juul also wanted to prove that players will put effort into completing the task. Juul shows here the value of development for scholarly

communication. Here Juul assisted in the development of a digital game to further his scholarly argument from his work. The game accomplishes this by demonstrating that players will work toward the tragic ending to avoid mechanical failure. To accomplish this, Juul ensured that accomplishing the goal of the game was challenging. Juul’s game and book act as an example of digital game development for games scholarship.

121). Unlike others who discuss digital game development, Juul does not try to refer to issues within game studies concerning the lack of exploration outside play. Instead, Juul looks at what development can do as a tool which is fitting considering his use of development to communicate within his work.

The game itself is unusual in that the goal is for the player to commit suicide, which was

Juul’s point since the vast majority of people see that act as failing in some way. The mechanics of that interaction are in and of themselves interesting since the player must slowly traverse the space and then input complex codes to attempt suicide. There are three phases of the game, each requiring complex inputs before finally succeeding at killing the on-screen character. Juul did not create the game by himself. He had the help of Albert Dang and Kan Yang Li; the book does not say what role each played in the development process. What is essential for this work is that the three worked as a group to make the game. Digital game development is typically done in groups

100

or with the aid of a community; solo development is far less common due to the demands on the developer.

Juul uses the game to drive home the point he makes about the narrative uses for failure in games, as well as the need for failure to come as a result of the player's effort. Some games utilize tragic failure as a means to progress the game's narrative. In Star Wars Jedi Knight II:

Jedi Outcast, the player must lose a battle with the antagonist at the midpoint of the narrative, this section of the game does require player effort much like Juul’s Suicide Game. For the narrative to progress, the player must fail, and they must try to defeat the game's villain (Raven

Software). Juul’s game varies from this by making the player perform the act of suicide, which is seen as a failure in a much different context. Much like Juul’s game, failure in a moral aspect can be the focus of part of a game. In Grand Theft Auto V the player must torcher a character for information under the direction of one of the game villains, the player character seems to enjoy performing the torcher, and the player should feel uncomfortable in the situation. The player ultimately helps the victim escape and flee the situation, but only begrudgingly and doing as little to help the victim as possible (Rockstar North). While this example has the same core of moral failure, the violence performed is not directed at the player character, but instead at a random non-player character. Juul attempts to make the point that in digital games, there are multiple kinds of failure utilized to communicate both mechanically and narratively.

Juul’s work is essential in terms of digital game development for scholars due to the focus on failure. Mechanical failure has unrealized potential for narrative use. Some games have folded failure into the gameplay like the above examples, but far too many games have fail states, which only act as a point to correct the player and force them to play in the prescribed

101

manner. In Middle-earth: Shadow of Mordor, the player character is unable to die permanently; instead, when they die in combat, they resurrect at one of the designated respawn areas

(Monolith Productions). The game's world and characters remember this, and new nemesis enemies are created or strengthened. What this means gameplay-wise is that the game world reacts to the player as if they have died many times, and some enemy characters will address the player character as if they have killed them before (Monolith Productions). The kind of mechanics used here was seen as revolutionary because the game utilizes a ubiquitous mechanic like failure and made something new with it. Not to say that scholarly games will have death in them. Instead, I am saying that academic games could explore the ways that the failure mechanic works and what it communicates and how to evolve the mechanics of failure.

Scholars need to recognize the importance of failure in the digital game space. Failure is essential to the medium of digital games. At the same time, I would not go as far as Juul does in claiming that failure is the defining characteristic of digital games. I would say that failure is vital in digital game spaces and serves as a key mechanic in many games. As stated above, with the example from Middle-earth: Shadow of Mordor failure can be a narrative component. Failure also can function as a teaching tool, as in the case of Super Mario Bros. Juul’s game is all about the ways that failure can be used in digital games and how it works mechanically as well as narratively. By making the player commit suicide, Juul is communicating the various narrative uses for failure, and in this case, moral failure as success. However, Juul uses the mechanic of failure by having several fail states within the game. Each of the four sections of the suicide attempt requires the player to input a series of letters in the right order; if the player fails, a message urges them to try again. If the player reached the time limit, then the player fails the

102

game and is told to try harder next time (Dang and Li). The failure of the game’s intended goals is met with encouragement to work harder at morally failing by committing suicide.

When I refer to failure and development, I do not mean the games or versions that fail to be released or the times developers fail at tasks. I am referring to the lack of discussion on the ways that developers treat failure and develop a particular mechanic. Failures prevalence as a narrative device and mechanic make it a topic well known to those that play digital games. It is surprising then to have this topic have so little written about it in terms of digital games. If scholars were to explore this mechanic from the perspective of development, there would be more to say and do with the mechanic academically. Instead, scholars typically choose to gloss over the mechanic in favor of the designed narrative or more unique mechanics. In the case of

The Art of Failure, Juul focuses on failure but does not bring in the topic of development when discussing failure. It is especially surprising that Juul did not consider the developed nature of failure in digital games since he helped to make a game about failure.

6.2 The Suicide Game

The Art of Failure addresses the development of the suicide game in passing choosing to focus on the failure mechanic, stating, “the player exerts effort in order to commit suicide” (Juul

96). Juul goes into a little more detail about how the mechanic functions, but as far as development and development goals, there is nothing more on the development of the game,

Juul’s focus is not on the development of Dang and Li’s game but rather on the end product itself. Juul fails to explore the development of the game, mechanic, and how the mechanic was balanced, or what improvements occurred during the development process. The failure to delve into the development process for the game takes from other scholars of the opportunity to

103

replicate their methodology and to explore other avenues of development. Moreover, the failure to describe the development process negates any ability Juul had to learn from the act of development. Ultimately, those kinds of details get left out in favor of communicating one facet of failure within digital games.

It is choices like the ones made by Juul, which deprive digital game scholarship of the opportunity to explore more fully the development process. Besides the principal developers of the game, Dang and Li could have documented the process and choices made for the development of the game and included them in their scholarly work. Instead, the process of development was an afterthought to the scholarly process of utilizing the finished artifact.

Returning to a lesser degree to the issues of screen essentialism and black boxing of development discussed earlier. Here, however, the development process is addressed, and Juul makes clear that the game is a purposely developed artifact and does not entirely rely on the game without its developed context.

It is essential to explore the developed nature of games like The Suicide Game due to the choices that needed to be made in the development process. As an example, I will explore more fully the mechanic of killing the player character. The game requires the player to reach four objects scattered around the level two knives and two vials of poison. Once the player reaches these, they must input a series of alphabetical characters to match the row above. Once the player has done this, the game slows down, and the player must then repeat this pattern until they have completed the task of killing themselves (Dang and Li). There is no justification for the use of these mechanics, yet there are numerous ways that this same idea could be accomplished. The idea that the game requires the player to kill themselves could be hidden until near the end of the

104

game, with the player performing seeming unrelated tasks until it becomes clear that the player character's goal is to kill themselves. The mechanic could be the same but without any need for the alphabet codes. The player could only have to pick up one knife or bottle, and then they die.

There are so many more iterations of this mechanic; it remains to be seen why they chose this particular one.

The Art of Failure illustrates two critical factors of digital game development concerning scholarship. First, that development needs to be considered when utilizing digital games within scholarship. The power of acknowledging the developed nature of digital games as a medium can allow scholars to understand better the work they are performing. Juul could have in his work, delved into the process of developing a game about failure and how that failure can be a powerful narrative tool. Juul does reference development more than other scholars, referring to the goals of the game's development. However, there is no mention of the process to achieve those goals. One way that scholars could change this is if they have included digital game development to add a postmortem to their work. Including what went right and wrong in the development process would be helpful to scholars not only by including a look into their process but also by making clear what went wrong and right from a scholarly perspective.

Second, it is vital for scholars utilizing digital game development to make their decisions clear to other scholars so that they may better appreciate the digital game created. A strength of scholarly development should be that unlike AAA style development, scholars should be open and transparent about the games they develop. Other scholars should be able to access the documentation created from development, and they should be able to follow the process. If

105

scholars share their development methodologies and decisions made during the process, then other scholars can learn from them as well as understand their work better.

Juul, Dang, and Li demonstrate with The Suicide Game that failure can be used in a narrative context within digital games. What is essential for scholars to understand is that Juul’s team also demonstrates that the development of failure mechanics can be just as important. An example of using failure in both narrative and as a mechanic is Dys4ia. Dys4ia is an autobiographical game about transitioning genders by the developer Anna Anthropy. Anna uses the mechanic of failure to illustrate how transitioning feels and what it is like to be a transgender person (Anthropy). The mini-game that utilizes failure the best is the wall mechanic. In this mechanic, Anna has a brick wall that the player is instructed to pass, but the shape that the player is guiding is far too large to go inside. The player will fail this task no matter how they move the shape. Later in the game, this mini-game appears again, and this time the player's shape is different, but one part is changing rapidly while the player is moving. The player is faced with the same mini-game again near the end of the game. This time the player's shape is shifting rapidly but in ways that make it seem like the player can guide the shape past the wall, ultimately, the game stops before the player can get past the wall (Anthropy). Dys4ia is an example of how well-developed failure can add to a game's narrative and enable communication between developer and player.

There are many examples of how failure features in digital games. Games like Super

Meat Boy make failure a shared and quick experience, while in games like Sekiro: Shadows Die

Twice, failure is a slower experience and carries more weight. Players expect failure to be a part of their games; the question is how then can scholars utilize failure and development for their

106

scholarly work. The first step is for scholars to decide what kind of failure they are implementing in their work. For example, Gone Home is a narrative game where the player explores a large house looking for clues to where their family is and what happened in their absence. Gone Home has no traditional fail states. Instead, failure takes the form of not discovering all the game's narrative. While Super Meat Boy, with its fast-twitch platforming, has many fail states, which are less impactful, favoring getting the player back into gameplay. Extending this idea is the game made by Boluk and LeMieux, 99 Exercises in Play, which is similar in tone to Super Meat Boy, the developers' factor failure into the design, and player resets occur often. The focus of the game not being failure but the various puzzles that bring complexity and variation to the player interaction (LeMieux and Boluk, 99 Exercises in Play). Memento Mortem Mortis, on the other hand, does not contain fail states; instead, much like Gone Home, the player only fails by giving up on completing the maze (LeMieux and Boluk, Memento Mortem Mortis). Boluk and

LeMieux utilize failure in very different ways within their work, but they never reference the rationale for their development choices. The lack of presentation of the development process and choices by academic developers leaves the field lacking in the knowledge of the development process, take from future scholars the opportunity to learn from the process.

6.3 Conclusion

An essential part of development is learning from the successes and failures of other digital game developers. The majority of the time, this is done by playing other developers' games. Play is essential to development for a few reasons, chief among these is that developers can see what the field is making to avoid developing a game that is too similar to another.

Another is to see what new mechanics are being used to implement those into their work and

107

save time developing new mechanics when unnecessary. Play does not constitute all of a developer’s learning; the remainder comes from books, articles, post mortems, programming guides, and various interpersonal interactions with other developers. Scholarly developers can aid the field by generating documentation on the development process, thereby granting other scholarly developers the ability to learn from their work. Even with these documents, play will serve the scholar well. By playing games like The Suicide Game or 99 Exercises in Play, scholars can see what fellow academics are doing to communicate or perform research. By playing these games, scholars can also gain a base understanding of the kinds of mechanics needed to create similar games. For example, if another scholar wanted to explore the idea of tragic success in games like The Suicide Game, then playing the game to understand its mechanics would be beneficial. By playing other scholars' games, academics could gain new perspectives and ideas concerning the development and use of digital games.

The first important decision when developing any game is what engine to use. In the case of Boluk and LeMieux’s games, they used the Unity engine while Juul’s team used Macromedia

Flash to develop their game. Flash makes sense for this game since they planned to release the game online, making it widely playable. Every engine has benefits and drawbacks to it; some engines are very specialized while others try to be a catch-all. Unity tends to be a catch-all engine; it can perform well with 3D environments and 2D ones, as demonstrated by the work done by Boluk and LeMieux.

Meanwhile, if a scholar wants to create a 2D game, the Game Maker engine specializes in that type of digital game development. There are several considerations when deciding what game engine to use and what engines best work with the scholar’s strengths. Some

108

considerations might be coding knowledge and experience. If the scholar is not well versed in code, then something like Unity would be a poor choice since knowledge of C# is a must for that platform, while something like Game Maker or Unreal would be useable for someone with little to no code experience. That said both Unreal and Game Maker engines are best utilized by someone who understands code.

Engines like RPG Maker or Dreams do not require any knowledge of code to make games. A drawback of simplifying or removing code is there are extreme limitations to these engines. If the scholar wanted a more narrative focus with their work, then they could use engines like RPG Maker or Visual Novel Maker. These specialized engines have been used to make more narrative-focused games like Always Sometimes Monsters. Looking at The Suicide

Game, it is clear that Flash was the best fit since they needed to develop it to be widely available to other scholars with no need to download anything from a website. Meanwhile, for Boluk and

LeMieux, they needed to be able to disseminate the game widely, but their ideas required a more complex code interaction, so they needed to go with an engine like Unity.

Works like Juul’s The Art of Failure illustrate the potential for scholarly development as tools in academic study. Juul uses The Suicide Game both as a means of communication, but also as a tool to study failure in games. When examining the development of digital games for scholarship the subject of development should become apparent as a topic ripe for further study.

Juul, in his work, does not call for further research or use of development; instead, he chooses to focus on the topic at hand. Digital game development should be discussed mainly by those scholars that choose to utilize it in their scholarship. If scholars will not discuss how they developed work for their scholarly use, then why develop digital games as a scholar. Within the

109

corporate space, it is understandable that development processes are kept concealed; however, within scholarship, there is no excuse not to be as transparent as possible with development methodologies. Addressing the process helps other scholars and challenges those scholars who chose to focus purely on the digital game as an isolated artifact and not as a product of developers and society.

Digital game development is at the core of digital games, and failure is a large part of development and play. The Art of Failure points to the mechanic of failure and its narrative potentials. However, there is the real notion of failure as development occurs; this can be the failure to make a deadline or the failure of the current version of the game due to a game- breaking bug generated by the most recent iteration of the game's code. Failure is to be expected when developing digital games and is just as important if not more so than the mechanic of failure within digital games. When a developer fails to implement a mechanic they learn what is and is not possible within their game. They also learn how to implement the mechanic in the next attempt. Failure when developing digital games is not something that Juul discusses in his work, yet there is an importance in addressing the issues that accompany digital game development and especially scholarly digital development. It would be essential to know what issues arose in the development of The Suicide Game and how the team overcame those issues to produce the final game.

Failure can be avoided with experience and with shared knowledge. Developers routinely discuss issues with other members of their team or on online forums. While not all failure can be prevented in these ways, failure can be mitigated by interacting with a community. Due to the unique nature of scholarly development and the added issues that come along with working

110

within the academic structure building a community of academic developers to share what issues they have experienced would be beneficial to all involved. Post mortems act as a kind of document which can be utilized to explore the failures of production, most of the time. However, developers rarely share the real issues experienced when developing. Instead, most industry post mortems discuss the publicly known failures of the game and touch on them as learning opportunities for the development team. Rarely do developers address the behind the scenes issues with development. AAA developers tend to keep problems that occurred in development secret when they have not been made public this can keep their production teams looking suitable for future investments. There are some cases where a game’s post mortem is transparent and addresses these private issues, but they are almost always written by smaller development teams that do not need to maintain an image for a publisher.

Scholars can utilize digital game development as communication tools or as a means of research. Also, these games can be developed by small teams like Boluk and LeMieux or a small development team lead by a scholar, as is the case with Juul, Dang, and Li. It would also be possible for development to occur in the solo space, or a much larger team of 5 to 10 individuals.

All in all, development for scholars appears to be a task that adds considerable benefits to scholarly work. By no means should the development of digital games be a qualifier for participation in game studies discourse. However, if a scholar or scholars choose to implement digital game development into their work, then they should be writing about that experience and providing documentation on the full process so that other scholars may learn from them. Digital game development is so seldom discussed or utilized within scholarly work that it should be seen as a worthy addition to the discourse on digital game studies.

111

CHAPTER 7

METHODS AND PRACTICES FROM SOLO AND SMALL TEAM DEVELOPMENT

As a case study, Stardew Valley provides a wealth of documentation, with a blog that features documentation of the majority of development choices, as well as a glut of interviews with the developer, that the other case studies do not provide. Additionally, Stardew Valley offers an example of what is possible without game engines since the game was built purely with

C# coding. Super Meat Boy by Team Meat, comprised of Edmund McMillen and Tommy

Refenes, provides an example of what a small development team can do, illuminating the differences between solo and team development. While team meat does not have the same level of documentation as Eric Barone, they have been open about the development process in interviews and other documentation.

7.1 Stardew Valley/ Solo Development

Solo game development is a difficult undertaking requiring an individual to have the ability to focus on a single task for an extended period. Barone, the developer of the popular game Stardew Valley, not only developed the game solo over five years, but he did so without the aid of modern game engines. Instead, he utilized C# to code the game in its entirety (Barone).

Solo development also requires that the developer does all development tasks such as artwork, sound, and coding. Solo development could be a productive form of development for scholars, given that most are accustomed to working independently on scholarship.

Stardew Valley is a farming simulation wherein the player interacts with a small community to complete tasks, quests, and build their farm. The gameplay is simple, and the

112

game gives the player the freedom to perform its various activities and tasks in whatever way the player sees fit with little to no real consequence within the game. If the player so chooses, they can spend their time delving into the game’s mine, which is full of monsters and presents the player with more fast-paced action. Alternatively, the player may choose to spend their time building up their farm so they will accumulate more of the in-game currency. The game gives the player overarching goals but does not set a time limit to complete those objectives

(ConcernedApe ). Stardew Valley has a relaxed approach to play, as opposed to many other games within the same genre which require the player to meet precise deadlines. Stardew Valley does have a central goal represented by the player character’s dead grandfather to find “real connections with other people and nature” (ConcernedApe ). While the game never explicitly tells the player what this means if the player completes various tasks like getting married, completing town hall objectives, and befriending most people in town. When grandfather’s ghost visits the player in the third year, they will technically win the game. The win condition triggers a short cutscene and gives the player an artifact. The grandfather returning is not a one-time event either if the player fails their first attempt at pleasing grandfather’s ghost; they can summon him again. In other words, there is no way to lose the game, and when the player wins, it does not fundamentally alter the game in any meaningful way.

Stardew Valley intends to be a more free-flowing experience than other games like it. In particular, Eric Barone inspired by the Super Nintendo Entertainment System (SNES) title

Harvest Moon (Schreier 63-64). Harvest Moon, released in 1996, is similar in playstyle and narrative to Stardew Valley, with a few notable exceptions. In Harvest Moon, there is a one-year time limit to the game, and the player must achieve all the victory conditions, when not

113

accomplished within the time frame, the player loses the farm and game (Amccus). Harvest

Moon does not allow the player a choice in gender or the gender of the player’s love interest.

Harvest Moon has several fail states in which the player can lose their farm. These development decisions might have been due to the limited storage space and hardware capabilities of the

SNES. These development decisions could also be a reinforcement of social norms from the period, without documentation or a look into the development of the game, scholars are left to speculation based on other titles developed at the same time. Barone, while heavily influenced by

Harvest Moon, stated that he wanted his work to be more relaxed and freeform than his inspiration (Barone).

The core of Stardew Valley is player choice; the player can choose what activities to engage in and what activities the player does not like. If the player wants to achieve the perfect ending, they can, or they can choose to play their way. The player may interact with the town’s people and befriend them, or they can be a hermit, never leaving their farm except to buy supplies. Minute-by-minute gameplay varies greatly depending on the activity. The farming portions of the game are slow-paced and offer the player simple repetitive tasks to complete to grow plants and sell or give them away. Mining is fast-paced, with monsters attacking the player while they try to mine for various resources needed for selling, gifting, or crafting. Fishing is slow-paced while waiting for a bite. The pace picks up as the catching mini-game requires the player to keep a fish icon in the center of a bar (ConcernedApe ). The narrative of Stardew

Valley exists within the relationship mechanic.

As the player befriends the games non-player characters (NPCs), they gain access to new areas of the game along with cut scenes wherein the player learns about each of the town’s

114

citizens and their relationships. Some of these scenes discuss trauma and somber personal issues, and these narratives promote player engagement. The game features one character that is a struggling alcoholic incapable of functioning without her daughter to help her (ConcernedApe ).

There is another character who is trying to escape an abusive ex (ConcernedApe ). The games playful and straightforward exterior hides a much deeper and more meaningful game. The focus of this work is digital game development and scholarly use of development, Stardew Valley does provide scholars with an excellent example of solo development it also demonstrates how to use a game to approach serious topics.

Stardew Valley is vital to this works approach to scholarly development for several reasons. The game was developed by a solo developer, demonstrating that development does not need to be undertaken by teams. Barone is incredibly transparent with his fan base and has shared an immense amount about the development process for the game, as well as the thoughts behind making the game. Additionally, the game did not utilize an existing engine, Barone built the game from the C# coding language. When approaching methodologies for academic game development, solo development seemed to be a suitable method; therefore, Stardew Valley presented an excellent case study in practice.

Stardew Valley is a mechanically rich game, considering one person developed it. Eric

Barone developed the game over five years with the intent to release the game, but with no specific date for completion (Schreier 65-66). The driving factor for the development of the game was making a new Harvest Moon since it was tied up in licencing disputes and dipped significantly in quality since its original launch (Schreier 64). By developing solo, Barone enjoyed some freedoms that typical AAA developers do not enjoy. For example, Barone could

115

develop the game at his pace and never had to consider deadlines or experience crunch. Barone states that he did not trust others to get the game done the way that he wanted it done, deciding to work alone on the game. As Barone put it, “he could make decisions based on what he – and only he – thought was best” (Schreier 65). The type of solo development performed by Barone was a result of a desire for creative control. Scholarly developers, while wanting a semblance of creative control, would more than likely have a desire for control over the academic aspects of a digital game and, as such, seek solo development.

Additionally, Barone was able to make several sweeping changes throughout development, the characters in particular. In his blog, Barone discusses the ways that development of characters traits and sprites changed during development (Barone). Barone wanted to rely heavily on the game Harvest Moon as inspiration for his game. When he started, the game’s characters looked more like they were from Harvest Moon, as he continued development the game’s characters began to reflect his ideas (Schreier 65-66). As Barone continued development, he would get feedback from family and friends, and their feedback also contributed to the development of the game.

Stardew Valley is an example of how the development of a digital game can be accomplished by a single developer performing all necessary tasks. One of the many ways that digital game development is seen as challenging is the expectation in AAA development, in which hundreds of people perform development. Meanwhile, smaller indie game developers are beginning to challenge the notion that teams of hundreds must perform digital game development. Instead, they can be performed by smaller teams, or in the case of Stardew Valley, a single person.

116

Barone admits that there are some drawbacks to solo development, in contrast to the benefits of complete creative freedom without the oversight of publishers or other team members. A drawback resulting from this, however, is that there are no other individuals to bounce ideas off of to improve the development of the game’s features and mechanics. A key drawback mentioned by Barone is that there is no concrete schedule, and so he would develop a feature to near completion and get bored and move on (Schreier 75). The lack of schedule leads to the repeated delay of the project and would leave many features unfinished, as they would be thrown out in favor of others. In a development team, other developers would hold each other accountable for deadlines and completion of tasks, while as a solo developer, the only individual holding the developer responsible for their time is the developer. Another drawback mentioned by Barone is the feeling of loneliness which comes with full-time solo development (Schreier

75). As a full-time solo developer, Barone did not have others to talk to at work, since it was just him with his computer in a room. One of the side effects of developing solo is that there is not anyone to help when a feature becomes overly complicated or bloated. Barone mentions that there were several features that, once playtested by loved ones, needed to be cut entirely

(Schreier 75).

In terms of scholarly digital game development, solo development presents the opportunity for scholars to have complete control over their projects. This type of development allows for a more precise line of communication between the scholar’s work and the game developed to support that work. In terms of scholarly digital game development, the benefits of solo development are many. The scholar has full control of the development of the game and can make alterations quickly with little oversight or challenge. Scholars, accustomed to working

117

independently on their scholarly endeavors, are not as likely to be impacted by the isolation of solo development work.

Fundamental to development practice is playtesting to find issues and adjust gameplay.

Scholars should have others play the games that they create to scrutinize both the intended message of the game and to inspect the mechanical play of the game. The issue when performing solo development is that it is increasingly challenging to find playtesters. In AAA development, there are quality assurance departments tasked with playing the games, looking for bugs, and hiring playtesters to play the game for fun and give feedback. In a solo development methodology, there would be no ability to have permanent testers. Instead, the scholar developer would have to rely on other scholars or friends and family to test their games. Scholarly developers would have a slight advantage in this area over Barone as most scholars have networks of colleagues who would most likely support playtesting.

Solo development does provide challenges for scholars, in that development of games while performing rigorous scholarship is difficult. The act of development is time-consuming, and carrying out development alone means that the scholar must devote time to the creative process. As was the case with the development of Stardew Valley, which took Barone five years of solo development, the developer requires a considerable investment of time and effort. Small team development provides both accountability and other developers working on the same project, allowing that project to move forward at a faster pace. Solo development does possess several drawbacks that could interfere with scholarship. Jesper Juul had other scholars develop the game for his work, leaving him free to work exclusively on the accompanying scholarship

(Juul 96-67). While working as a producer for the game freed Juul from development, the

118

question should be posed about what was lost in that process. I would argue that Juul lost a great deal of creative control and the ability to develop the game precisely as he would have wanted.

Solo development provides drawbacks for scholars in much the same way that it does for any other developer. The isolation removes some of the quality control methods as well as some of the ability to work out ideas with other like-minded peers. It is easier for scholars to gain feedback on their work, since they often work with other scholars who are in the same field. As stated earlier, scholars also tend to work alone on their scholarship and so would experience or recognize less of the loneliness described by Barone. The other difference between scholars and developers like Barone is that most scholars are looking to create smaller games for more concise experiences (Juul 96-97). Development of smaller games would require far less development time than the five years it took Barone to develop Stardew Valley.

Additionally, scholarly games do not need to be extremely polished to get their point across. Games like those found in Metagaming were not extremely polished, and yet I would argue that Boluk and LeMieux’s games effectively communicated what was needed. Another difference between Barone and most scholarly developers is that he did not use a game engine to make Stardew Valley, instead opting to code the game in its entirety from C# (Barone). Game engines offer a more streamlined approach to digital game making, and for scholars, engines offer the ability to make games without having to know a considerable amount about code. What

Barone does demonstrate is that solo development can produce a well-made game, which acts as a proof of concept for scholarly game development.

The transparent development of Stardew Valley provides a model for scholars to follow.

Digital game development performed by scholars should be transparent. There should be

119

documentation for every step of the development process. By documenting the development process, scholars can better understand the development process and can gain feedback from other scholars to improve their work. Besides, scholars can examine their work to build their scholarship. Solo development makes tracking the development process more straightforward.

While in the later stages of development, Barone kept track of the progress and communicated with his growing fan base through a blog. Barone would publish significant development progress, patch notes, and changes to the games art style (Barone). The site has now ballooned into a full wiki containing everything from early mockups for the game’s characters to how-to guides for fishing (Chucklefish). Barone did an excellent job of cataloging and tracking the development process and justifying the changes made to the game, even if the reason was that he got bored with the mechanic.

If scholars were to be precise with their cataloging of development, it would go a long way to removing the screen essentialism found in digital game scholarship. Preserving the process will aid the scholar in their work and also those that do similar work in the future. As I have stated previously, the demythologizing of digital game development leads to distancing scholarship from black-boxing the development process. Solo game development makes tracking and maintaining logs of all changes to the game simpler than with a large team. Also, the scholar will have instant access to the files for review since the scholar is the only person generating the game files.

120

7.2 Super Meat Boy/ Small Team Development

Small team development, like in the case of Super Meat Boy, provides some benefits not found in solo development. Super Meat Boy was developed by Team Meat, made up of Edmund

McMillen and Tommy Refenes. A similarity between small team development and solo development is that changes can be made to the game rapidly and the vision of the final product can be altered to fit the designers’ vision. The critical difference between these styles of development is that small team developers can run ideas by their partners and get immediate feedback. Small team development also tends to cut down on development time since development responsibilities can be shared. Additionally, there is greater accountability for time spent developing in a small team.

Super Meat Boy is a platforming game where the player controls a little meat character as they traverse traps and enemies. The game tends to be fast-paced and incredibly unforgiving.

Team Meat worked on Super Meat Boy for three weeks before releasing the flash version onto a website called Newgrounds (McMillen and Refenes). Team Meat released this version titled

Meat Boy, but it was not until Nintendo and Microsoft got involved that the two developers gained the funding to develop a full version of the game. Development of the final version of

Super Meat Boy took Team Meat over a year. The development time of Super Meat Boy was still much shorter than the development time of Stardew Valley. There are a few reasons for this; one is the team size which plays a small part. However, it is the involvement of large corporate entities and their timelines imposed on the developers that made development significantly faster

(McMillen and Refenes). Barone did not have a publishing deal for the majority of his

121

development, instead securing a publishing deal with Chuckle Fish after the majority of development was completed.

Small team development for scholars can prove to be beneficial since there are others to work with; however, it can also be more limiting since there is pressure from the team to complete the game. Solo development does fit with representative scholarly work. However, it does not fit with good game development practices because having others play the game is a core principle of development. It is possible to offset this by utilizing others for playtesting and feedback, but the feedback of a fellow developer will be more technical and provide greater insight into possible solutions to issues due to experience with the medium. It is essential, however, to examine the examples provided of Juul’s team, as well as Boluk and LeMieux since the games developed by each are very different. The games developed by Boluk and LeMieux fit within their scholarship due in large part to the focus of those participating. Boluk and LeMieux were focused both on development and their scholarship. They did both as a team, making the unity between the games and text nearly seamless (Boluk and LeMieux 75). Scholarly development can benefit from small team development methodologies. However, there are drawbacks to this method. Juul’s Team developed the game as a group, but with different academic projects in mind (Juul 97,99). The minor deviation between Juul and his team members resulted in the game that was developed not being as effective as those found in Boluk and

LeMieux’s work. Juul’s work is less effective at communicating due to the multiuse nature of what was developed meaning that Juul and his team were unable to focus on a particular scholarly work while developing. That is not to say that their work is ineffective only that the

122

work of Boluk and LeMieux is able to be more focused than Juul’s. Scholarly development should be closely tied to the academic work performed.

When scholars develop in small teams, they have the disadvantage of having to work with others on scholarship and a game, making division of labor demanding. In the case of Boluk and LeMieux, it appears as though the labor was divided by development and scholarship. This may be inferred from the order they are listed concerning the work. As for the authoring of the text, the authors are listed as Boluk and LeMieux. But concerning the games found in their work, they are listed as LeMieux and Boluk (Boluk and LeMieux iv,75,383). From this information it becomes clear that each took the lead when it pertained to certain aspects of the work. This division of labor would be beneficial in each allowing the other to aid in the work, but having a majority of control over their chosen part. The division I am proposing here is speculative but would be an efficient method for small team development and scholarship. Other methods could be employed. For example, Boluk, and LeMieux could have alternated names but maintained a shared responsibility for the game as well as the scholarship, with each working on both with equal responsibility. Regardless of how the labor is divided, there must be a good working relationship to accomplish both scholarship and development at the level that they were able to achieve.

7.3 Conclusion

In the process of examining the development process in terms of solo or small team development, I concluded that solo development would function best with my work. Solo development would fit within the majority of scholars' work as it does not require collaboration with other scholars. As stated in the chapter, some issues arise from this methodology; however,

123

the benefits outweigh the drawbacks when it comes to scholarly work. Small team development can work for groups already working together on scholarship, as was the case with Boluk and

LeMieux. If scholars are not already working together on scholarship, then I would strongly recommend solo development.

Further research is needed to explore better the benefits and drawbacks of various methods of development for scholars. It would seem that solo development would be best suited to the existing work environment for most scholars, that said there are benefits to small-team development, which would help scholars by utilizing interdisciplinary approaches to scholarly development. When development occurs within a team structure, team members can get rapid feedback on their work. The team also provides structure to the development process and accountability. These are benefits to the small team method. However, for a scholar, that means that the work may not precisely reflect their scholarly work. The game developed may not be as precise or as connected as the scholar would like. When examining works by Boluk and

LeMieux, as compared with the work by Juul, Le, and Dang, there is a slight disconnect found in the work by Juul’s team. The disconnect could be attributed to the fact that the three were working on different scholarly objectives in conjunction with their game and so it does not precisely fit each work. Whereas Boluk and LeMieux worked together on both games and scholarship, making their games a better fit for the scholarship which accompanies them. These are incredibly limited inferences from a small data set. However, I would suggest that working as a small team on both scholarly work and digital game development would be a preferred methodology, compared to working on separate scholarly works driven from the same development.

124

CHAPTER 8

DOCUMENTING SCHOLARLY GAME DEVELOPMENT

Figure 8. Flow Chart

The development process for Game Lab Sim began by selecting a game type that would best fit with the work I performed in previous chapters. I decided to go with a simulation-style game. In particular, I made a management simulator focusing on a scholarly lab. This type of game seemed to fit with the overall message of looking into the black box and experiencing digital game development. After selecting the game type, I moved to the engine, GameMaker

Studio 2 seemed the best option for building a mouse-based game which relied on simple interactions. Based on my prior interactions with the engine, I also felt confident that I would be

125

able to develop the game alone and with minimal issues plaguing development. I then began the process of pre-production.

8.1 Pre-Production

Figure 9. UI Sample The goal of pre-production was to determine what the minute-to-minute gameplay would be, and how the games various systems would interact. The simplest way to achieve this was to generate a flow chart (Figure 8). By exploring the content of the game via a flow chart, it becomes easier to visualize the game's various interacting systems and to detail exactly what the player will be doing during the game. Flow charts represent a game's code interactions making it clear to the developer what systems will need to interact and how code will play a role in those interactions. Additionally, flow charts act as a means of understanding the player’s possible actions within the game space. Notably, flow charts are not representative of the final product,

126

and some features found in them are not present in the final product. For example, the function where the player can select a scholarly topic was cut from the final version of the game, as well as the ability to develop games without hiring students.

During the process of pre-production, I also sketched out possible game layouts. These initial mockups gave the basic idea of what the games screen would look like (Figure 9). As with the flow chart, these sketches and mockups would not resemble the assets in the game but were an asset for planning the production of the game. As is the way with the vast majority of digital games, the pre-production phase tends to be a rough approximation to the final game. During pre-production, ideas shift and are informed by existing games within the genre.

Game Lab Simulator takes inspiration from Game Dev Tycoon. This game was developed by a small team and centers around the management of a game development company as the player expands their game empire. The user interface of Game Lab Simulator takes from the UI of

Game Dev Tycoon (Figure 10).

Figure 10. Game Dev Tycoon

127

After modifying it to fit within the scope of the game that I was making the UI became quite different from its inspiration. There were other management games that I played to research the mechanics and UI for Game Lab Simulator. Games like Game Dev Studio, Game Dev Story were also inspirations. However, they were not as impactful as Game Dev Tycoon. An essential part of the development process is exploring what other games similar in genre and content exist and knowing how to make something different from those pre-existing games.

A large part of exploring the potential of a digital game is by writing a design document. As part of the development process, I wrote out how I imagined the game playing. To demonstrate the following is an excerpt from that document.

“The game will feature management mechanics similar to many within the genre. The

player will hire and assign grad students to develop a scholarly game. Students will have

various stats like semesters left till graduation, coding, art, and design skill. These skills

will determine the quality of the work performed by the student. The students’ skills will

grow as they develop more games, and as they go to classes. As the game progresses, the

students will graduate, requiring the player to hire new ones to continue the process of

development. As this will be a simulation of the ideal scholarly development situation,

there will be a budget for the player to hire students also, the students will not skip

development time and will not get sick. The game will be exceedingly forgiving since the

focus is not difficulty but rather the scholarly development process.

The above UI Mockup represents what the minute to minute layout will be. All

player interactions will be handled on the mouse. The player will press various buttons

on-screen to perform actions in-game. These might be the hiring of development students,

128

or it might be choosing a game that coincides with the scholarship the player is

performing.

Minute to Minute Gameplay

The player will begin by receiving a topic that will be a representation of what the

scholar is researching at the moment. The player will have the choice to accept or reject

this topic. The player upon selecting a topic they like will be able to choose to develop

their game solo or with a small team depending on the budget for their work. If the player

selects to work as a small team, the player will hire new procedurally generated team

members. Each time the player hires a student, they will be given a choice of three

students or a none of the above button. If the player chooses none of the above then they

will be given another selection of three. Once a student is hired, the process may be

repeated twice for a total of three student hires. Once the player begins the development

phase, they must select a game type. These will be provided based on the team size and

the experience of the developers. The development of the game will occur, and then

experience will be awarded to the group. If students have gained sufficient experience,

they will level up, allowing for new games and genres to emerge. Once leveling occurs,

then the process will begin again. The whole loop should take less than ten minutes.”

Documents like the above explore the ideas of what a player can do within the game space. They also improve the developer's ability to communicate with a team. In my case, there was not a team helping me develop the game. Instead, I used a game design document for two reasons. Firstly, the document acted as a means by which I could explore the design and

129

development process. Second, the design document helped me to explore a few ideas I had and put to writing the plan of the digital game.

It was at this point that I began development on a paper prototype. Paper prototyping is beneficial because it offers the developer the ability to experiment with how the game's systems interact and make changes very quickly with a pen and paper. In the case of Game Lab

Simulator, I made a card game where the player would allocate resources and gain points to get larger and larger grants, which translated to money to hire students and upgrade equipment. As I played the prototype, it became clear that some of the mechanics needed to be revised, and so I would write on the cards, modifying them as I needed (Figure 11). The original cards became heavily modified in the process. Changes were made to the students' stats as well as what stat they could use depending on the focus each student had.

130

Figure 11. Focus Edited Figure 12. Focus Figure 13. Grant Edited

Figure 14. Grant Figure 15. Student Edited Figure 16. Student

131

Figure 17. Topic Edited Figure 18. Topic Figure 19. Equipment

Figure 20. Equipment Edited

132

The cards marked major became focus cards, and the equipment altered so that instead of stating stats like Ram and GPU (Figure 19), they matched the code, art, and design stats (Figure

20). As the game evolved, it became clear that there was a need to change the year stat to semester and the range to be increased. These changes were never implemented into the paper version as digital development on the game was beginning, and the semester change would be implemented in the digital game.

The paper prototype was also helpful in gaining an understanding of the ways that each system would interact and just how these interactions could snowball. At first, the number of points needed to obtain the largest grant was 45. That amount was reached within the first four turns when played according to the original rules (Figure 14). This pace was much too fast and needed to be slowed down. I achieved this by both reducing the number of points gained by each of the student cards (Figure 11) and by focusing on specific stats using the focus cards (Figure

12). The focus cards were added to the students at random when the player purchased a student card. This mechanic controlled the stats used by the student and reduced the rapid accumulation of points.

The next change was to shift from a score and points methodology to a reputation method

(Figure 14, 13). This shift did not impact the game mechanically; instead, this change was implemented to illustrate the focus on scholarly development within academic labs. This shift was purely narrative-based and was simple to implement. The change was necessary as it made the game feel better and fit within the scope that I had established in the design document.

The paper prototype stage was essential to the overall development of the project as it allowed me to make the changes as mentioned above. I was able to test alterations and pace the

133

game effectively; the nature of the paper prototype allowed for rapid adjustments that would have taken much longer in digital development. After some more playtesting and tweaking of the paper prototype, I moved on to digital development.

8.2 Production

Digital game development requires a knowledge base in many interconnected disciplines.

The issue that I ran into was that it had been some time since I had used GameMaker Studio 2.

The result of my lack of practice was that it took me a few hours to adjust to Game Maker

Language (GML). Each game engine has their preferred or required code language. Game Maker

Studio 2 has its code language, which is a modified form of Java. When beginning the development process it was much slower than I would have liked due to my lack of practice when it came to GML. The positive thing here is that Game Maker Studio 2 has a large and devoted base of developers who are eager to help others and share code. Additionally, the engine itself has a large library of code definitions and examples so that if developers are lost, they can find the code they are searching for within the engine itself.

I began with the item that players were going to interact with the most, a clickable button.

I needed to code one so that when it was pressed, it would alter stats and change between rooms

(a room is the GameMaker equivalent of a level) within the game (Code 1). The process of getting a working button took me roughly an hour, which is longer than average. During this process, I became reminded of several development basics that slipped my mind due to a lack of practice. The most important of these basics is when stuck on a problem to reach out for help.

After I reached out to the GameMaker community I found the answers I was looking for. What took me an hour was resolved in a matter of minutes because I remembered to look for help.

134

Digital game development, much like game scholarship, is in large part, looking at the work of others and building off what they have done.

Figure 21. Computer Figure 22. Start Button and Chair Next, I choose to create the games start page. In retrospect, this was likely a waste of time since it was more important to make the working game levels than it was to make a working and visually appealing start screen. I began by choosing fonts for the menu buttons and the title

(Code 2). After selecting fonts, I moved on to create the visuals for the buttons and the background (Figure 21). Coding the buttons and the start menu took longer, but not as long as the initial button. The act of translating the initial button code to the other menu buttons was relatively smooth; I also looked up several functions within the code dictionary provided by the game maker platform. Utilizing the built-in code dictionary made making subsequent buttons, and their actions more straightforward, most coding from this point forward was simplified.

Figure 23. Student

135

My next task was creating visuals for the main game screen and the characters and desks.

There would be three desks and three computers along with three students, which would appear at each desk when hired (Figure 21,23). Designing the room and the desks became difficult due to initially generating the desks as part of the background. This caused problems due to the original computer’s capacity to be upgraded, meaning that the visuals for the desk would change.

Forgetting that the computer sprite needed to change, I designed the desk into the background complicating the needed sprite change. I needed to go back, remove the desks from the environment, and add them as an individual sprite, which could then be attached to the desks and upgraded through the upgrade menu. Most of the visuals are in the Alpha stage and do not contain the detail level that a final product would. In developing the visuals for the game, they became increasingly rudimentary to facilitate rapid development. The issue was spending too much time developing the visuals of the game and not enough on the code interactions.

During the process of coding the buttons, it became apparent that each button would need its sprite, which means that I would have to draw each button and write text on each button individually to make them look good. Fortunately, I was able to reuse the base image of the button for the majority of the buttons since they were the same size, shape, and color. After getting the buttons to look right, I then moved on to coding the buttons, utilizing what in

GameMaker is called global variables. A global variable is a variable that can be read across various objects, making it so that each object can communicate with the other via the global variable. Some examples of these global variables are global.rep, global.money, and global.funding. These Global variables enabled me to keep track of different stats as well as

136

alter these stats by changing one variable as opposed to multiple variables across multiple objects.

Figure 24. Student Info

Once I had most of the buttons working, I was able to move on from the buttons to the students and the student cards. Student cards were made up of similar stats to those found in the paper prototype, with the exception that the stats were randomly generated and could be more significant than those found on the cards (Code 3). One of the issues that I ran into was attempting to limit the total number of points allocated to each student, which means that each student was supposed to have six points except for the gifted student, which is nine and a below- average student, which was four. When I attempted to code in a limiting interaction, that code would impact other students’ stats and would result in most stats being reduced to twos and students never exceeding the minimum number. Ultimately, I decided to remove the limiter and instead focus on the range that the stats can be randomized, enabling average students to have an average of 7 points some a little bit higher, some a little bit lower depending on how the randomization worked. The above-average student then had a range that was closer to 9 or 10,

137

and this could max out at a potential of 11 points, but I never saw that in playtesting. The student cards were then created, which was mainly a backdrop, the cards were a sprite and then the text which was coded and would be written according to the aforementioned variables. It was at this point that the code became increasingly complex. Some examples of code events could reach up to 46 to 50 lines long, which is complicated for the simple game I set out to make. The positioning of the text and the width and size of the student cards were retouched and revise multiple times to fit all of the information within the borders of the card (Figure 24). Once the player chose a student and clicked on the card it would then spend the requisite amount of money to hire that student, and it would transfer the stats from the student to the student in the main game returning the player to the original game menu, requiring several lines of code and numerous attempts at making it work (Code 4). Some variations were more successful than others, but ultimately a rapid transfer between rooms was necessary to gain the desired effect in the main game room. Side effects to this rapid transit between rooms was that the existing student pool had to be wiped entirely, removing the intended mechanic of allowing the central student pool to upgrade along with the students that had already been hired.

The loss of the student pool mechanic was frustrating since it would enable the player to scout out potential students to hire for future projects. This mechanic would have added a layer to the student selection mechanic and would have interacted with other systems to create an illusion that these were students, and it was a campus and where they were learning and growing.

Instead, I needed to change the mechanic to make the original mechanic of hiring students function; otherwise, the students' data would not adequately transfer once hired. Also, students that have been in the pool for longer would graduate thereby being removed from the pool,

138

causing a glitch where other students' stats would clear to zero. These issues made it necessary to reduce the mechanic from picking one of a pool of candidates to selecting one of three possible candidates, either way, the core pool will decrease to zero once the player makes a selection or cancels (Code 5). These code interactions are facilitated by creating a code that would detect whether or not the player had the funds to hire a student and if they did, then once the frame was clicked on, their data would transfer to the main game area. Coding this interaction was achieved by using a mixture of plain variables and global variables to shift values between the plain variable to the global. Once I had the students functioning, it was time to move on to the grants.

Within the game, the grants are what give the player funding once every year within the game. Since the game's turns each take a semester, once every two turns, the player would receive the funding guaranteed by whatever grant they had attained. The starting grant was for

$800 a year, making the player have to use the $800 or receive a reputation penalty. At first, this is not a challenge because most of the students are $800 to hire, therefore using up the grant efficiently. Using the same methodology as I used with the student hiring section, I then applied that to the grants. The issue arose when the grants would not detect the number of students that I had hired. After taking a long time trying to find out why the student number was not being transmitted to the grants successfully, identify the number of objects in the room registering the student objects to the team number Global variable, which then allowed me to activate the grants without any further problems (Code 6). The other issue that came about with the grants was needing to create and modify a new Sprite fit the information from the grants on to the screen.

The solution was creating brand new sprites for the grants so that they differentiated themselves

139

from the player cards and made it so that the information would fit more smoothly on the grant cards (Figure 25).

Figure 25. Grant Info

One change from the paper prototype to the digital was randomizing the grant and the information on them. While developing, I decided that it would be beneficial to the player to have multiple grants with multiple requirements shifting within a designated range (Code 7).

Meaning that for players who had not been able to acquire as many students or had just lost his student or are in the middle of the year and did not have the funding necessary to get a new student could still move forward through the game by getting grants that were at their level. I was able to successfully code these grants to have a variable amount of money attached to them, and so the more accessible grants were lower range, and the more difficult grant had a higher range of funding available. The variable nature of these grants also increases the difficulty level since the money attached varied between them, meaning that the player would then be more likely to have leftover money at the end of the year and as stated earlier when that occurs, there

140

is a hit to the reputation score (Code 8). Ultimately I decided to keep the mechanic since it fixed the balance issues with getting the higher level grants and enabled the player to feel as though they were progressing.

It was at this point that I decided to work on the game's audio creating a clicking noise or rejection noise and also creating music for both the opening screen and the game itself. The sound effects were created using free software called BFXR. The music was created using for- purchase software called Rytmik Ultimate, allowing me to develop 8-bit sounding sound effects and music. BFXR is relatively simple, and its interactions select the type of sound effect desired and then modify that sound using sliders. Making the sound effects, it was vital that they sounded right but still had an 8-bit quality to them.

Meanwhile, for the music, I wanted there to be an 8-bit quality while still enabling myself to use a broader range of tones that was available during that console era. The creation of the music and sound effects was rather straightforward. There were no significant obstacles to the development of simply putting together what I thought sounded correct for the alpha. At this stage making the sounds music sound good is less of a concern than making the game functioning, so code and design superseded the art and artistry of games in terms of an alpha build.

While the art and artistry of the game are not as critical as the code, interaction, and mechanics when it comes to the game’s alpha, it is essential to have a general idea and direction for the art of a game in terms of Game Lab Simulator, the art style needed to be 8-bit or 16-bit.

Art direction is purely a personal choice. I enjoy the games of the 8-bit and 16-bit eras. Utilizing various tools within Game Maker itself and a tool called Aseprite I was able to mimic the visuals

141

found on consoles like the Nintendo Entertainment System (NES). One of the issues with solo development is that there is no need to communicate design choices like making the game in an

8-bit art style. What this means for me is that I did not write down in my design document or any other notes the choice to make the game 8-bit. It was not until I wrote this that I realized that I had not yet written that this was a design choice and was the direction for the art style of the game. It is important to note that when practicing development, scholars should be writing down, taking notes, and logging these conscious choices is vital for other scholars as well as the development process.

Once I was able to get all the systems functioning together, I then began playtesting the game, which resulted in finding a few bugs. When developing digital games, it is common to discover bugs when playtesting. One of the most significant bugs that I encountered was the hiring and firing bug. The game would catalog what students went where via a global variable, this global variable would be affected by hiring and firing. I realized that if I had all three students at once and then fired the second student, then tried to hire a new student. The game would hire a new student over the first student hired and not hire a new student in the slot for the second student, because there was no code to register that student two was missing. To resolve this, I had to communicate with the system via code to detect whether or not the first and third students existed in the room and then it would hire the second student. I needed to create code for all possible variations in the three students set up (Code 9). Another error that would occur frequently occurred when upgrading the computers, making it so that when a different model was selected, the original model would only go up one level instead of to the desired level that was selected. To save time I made the upgrade system into just one button, making it so the

142

player would upgrade the computers in steps. While this fixed the initial issue it did make upgrading more expensive since the player could no longer jump levels. Hopefully, I will be able to solve these issues and incorporate this system into the next build of Game Lab Simulator.

8.3 Analysis of Development Practice

The process of developing the alpha for Game Lab Sim was recorded for analysis and understanding of the development process. Ultimately for the alpha, I recorded 13 hours of footage. This footage was then used to both inform this chapter, but also to explore the ways that

I make games and explore how that process could have been made smoother. I hypothesize that if other scholars were to do the same thing that they would benefit from the experience as I have.

However, as stated many times is in this work, even if the recording and documenting of the development process does not edify the scholar, it does contribute to the body of work seeking to reduce screen essentialism and black boxing within the digital game scholarship space.

I am not offering my work as a perfect example of how scholarly development should be accomplished; instead, I am seeking to act as a proof of concept for scholars to understand how this can be done moving forward. In retrospect, I believe that recording every minute of development may have been more than was needed. However, it did make taking notes on the process simpler. Instead, it would be just as useful to take notes during the development process recording the critical changes to the game and the core ideas behind it.

Game Lab Sim demonstrates the methodology for digital game development can be adjusted to fit a scholarly approach to digital games. By developing a game alongside scholarship, the scholar is able to understand all the components within the development process to a greater degree. This demystifying of technology is the most apparent benefit to digital game

143

development for scholars, the ability to recognize the various elements that make a digital game.

Interacting in the space between screen and hardware makes both aspects of digital games readily apparent and as such benefits the scholar in the recognition of both.

The development of Game Lab Sim from start to alpha took approximately 13 hours the vast majority of that time was spent on code. Some time, roughly 5 hours, was spent on the games visuals and font. An additional 2 was spent on audio which included music and sound effects. These numbers demonstrate that digital game development for scholars can be approachable. Since I have little experience with art or sound design and was able to put together an alpha level game. The amount of time needed to develop the game could have been reduced if

I were to have developed the game in a small team dividing the labor among a group. Instead, I opted to develop the game solo to demonstrate to scholars that developing a game and documenting the process is a performable task.

8.4 Conclusion

As I have stated before, screen essentialism and black boxing of technology represent a significant hurdle to the advancement of digital game development. Scholars developing digital games enable further exploration of the technology behind games. Technological black boxing becomes limited when a scholar has hands-on experience coding due to the visible interactions between hardware and software. The primary way that this is accomplished is in recognition of physical input for digital interactions. As scholars code the inputs for a game they must become aware of how that interaction is executed. In Game Lab Sim, for instance, the mouse is the chief input methodology facilitating interaction with the game. I intended for the mouse to be the chief

144

means of interaction. By mapping all mechanics to the mouse, this limited the way that I was able to develop the game but also made it possible to make all interactions fluid.

I recommend that scholars take the time to engage directly with the development process.

From my experience, scholars should not document every moment of the process, but they should document large scale decisions and how those decisions affected the development process and finished artifact. It is by being transparent about the development process that scholars will be able to gain an understanding of the process as a whole. I would also recommend solo development for the ability to make changes and craft the digital game to fit within the scope of the game studies space. That said, I do not have any experience with development in a small team when crafting a game for scholarship. Since I do not have the needed small team experience, I am unable to speak directly to the benefits or drawbacks of such a methodology. In future research, I hope to remedy this and produce scholarly games with a small group. Scholars need to have a period of pre-production for their games so they might catch issues with the game's mechanics and with the game's scholarly message. One thing that I would strongly recommend is to have other people playtest the game while it is in development so changes can be made before the game reaches its final stages, I failed to do this and regret not devoting the time.

Scholarly game development can be a space where scholars can explore the physicality of digital games. By altering input methods, scholars could learn how input methodology impacts play. In the case of the game that I developed Game Lab Sim, if the interactions were mapped to a keyboard or controller, there would have to be alterations made to the core functionality of the game. Some of these alterations would make the game more playable and more accessible,

145

enabling faster movement between menus or quick keys to end a turn or to move between menus. While other interactions would become more complex, requiring multiple navigation presses to get from one point to another within the game, making things like hiring and firing more difficult. Additionally, utilizing other inputs could increase the chance of user error, enabling the player to fire a student accidentally or to hire a student inadvertently.

Ultimately, it is the experience of development and interaction with digital spaces that enable scholars to find and explore what it means to interact with a digital game. The act of developing something basic with simplistic code could allow scholars to further explore the ideas of screen essentialism and black boxing. If for no other reason than the practice of digital development for Games Studies scholars is beneficial in recognition of the space between screen and hardware, further exploration of this area of Game Studies should occur. There needs to be a larger exploration of how development can be used by scholars if for no other reason than to put forward the ideas that screen essentialism and the black-boxing of technology should be a thing of the past when it comes to Game Studies.

146

CHAPTER 9

CONCLUSION

In this work, I have come to several conclusions regarding the role and importance of digital game development in game studies scholarship. In Chapter 1, I concluded that the field of game studies is calling for a more in-depth examination of the medium and that paratext and production should be a part of that exploration. In Chapter 2, I concluded that scholars could gain a glimpse into the black box by reading and understanding the basics of development, which is achieved by examination of development industry texts and scholarly works on the subject.

Chapter 3 concluded that the developed works of Boluk and LeMieux served as a proof of concept in digital game development being viable for scholarship. Chapter 4 demonstrated how play could be factored into development to both instruct and give experience to players and scholars. Chapter 5 focused on The Art of Failure and the game developed by Juul’s team, demonstrating how small team development can be beneficial for scholars and that development practice needs to be a goal for all game studies scholars. Chapter 6 shows how small team and solo development work for independent developers and how scholars can utilize their methodologies as a method for their development. Chapter 7 acts as a proof of concept for all previous chapters as I employ creative practice and independent development methodologies to produce a game artifact, demonstrating the possibility of development by scholars as an academically worthwhile activity.

In the process of reading, writing, and developing for this dissertation, I have discovered that scholarly development is critical to the advancement of game studies. To what degree development practice and knowledge is beneficial is varied. For example, if a scholar were to be

147

exploring the impact of violence within digital media, making a game for that purpose may not directly aid in their scholarly endeavors. In this case, a basic understanding of development would aid the scholar in understanding the games in question as more than the visual interface of a developed medium. In the case of exploring the potential video games have as a communicative tool, digital development would prove instrumental for digital game scholars.

Every scholar must look at their work and methodology to see how digital game development falls within that scope. All scholarship that approaches digital games should have some reference to the produced nature of the medium and have a rudimentary understanding of how that process occurs. Scholars should be aware of development and reference to the importance of the development process to confront the issues of black boxing and screen essentialism.

As I have stated throughout the work, the issues of black boxing technology and screen essentialism create a knowledge gap for scholars if not addressed. The most significant conclusion from my work has been the understanding that knowledge of development and learning how development occurs will assist in decreasing or removing these aspects from game scholarship. When a scholar is aware of the process of development and how that process works, they can examine more fully the digital game space between hardware and screen. Several scholars have discussed the issues with black-boxing and with the interface effect. My work is building on the work of those scholars. If a scholar takes the time to explore more fully digital game development, then that process ceases to be black-boxed.

Technological black-boxing is a critical issue in my research. I have concluded that digital game development can be a means of reducing its effectiveness. Black boxing becomes an issue due to scholars deriving the entirety of their conclusions about a work purely from the

148

visual expression of the interactive medium. Hardware and input matter since games play drastically differently depending on the platform they are on or the input method used.

Understanding digital game development helps to remove some black boxing since, during the process of development, scholars would understand that hardware and input are vital components of development. If, within the process of the scholarly exploration of digital games, a scholar does not mention or discuss the process of development, then that aids in the black-boxing of the game technology. The further that digital game development is black-boxed, the more that digital game scholars turn to screen essentialism, forgetting the process of mediation in which hardware and screen become connected. The software is as necessary as the screen, as is the hardware, every piece of the process is necessary when addressing digital games. Digital game scholars, then, by understanding digital game development, better understand all the elements of the medium they study.

I am stating that scholars should be familiar with the tools and techniques utilized to make a game. Scholars can gain knowledge of digital game development by working with a team to make a game, working solo, leading a team of developers, or by reading books about the development process. What remains vital is that scholars refer to the development process when approaching a digital game. It should be standard practice within game scholarship to reference development and code, which would continue to resist the negative effects of screen essentialism and black boxing.

I will continue to develop digital games in a scholarly context to further explore the ways that development practice can shed light on digital games and their place in scholarship. I intend to explore further the ideas of exploring games via their development as an additional avenue for

149

critical analysis. This work is a beginning for many future works focused on the impact and academic usefulness of digital game development. An exploration of the development process as a means to communicate scholarly ideas needs to be addressed using human participants to examine the effectiveness of development as a scholarly tool. The work that is most needed coming from this is the need to explore the further impact that addressing the developed nature of digital games has on the field of digital game scholarship.

In addition to developing future games for scholarship, I will also continue to explore how other fields deal with direct interaction with the subject of study. Works like Laboratory

Life: the Social Construction of Scientific Facts are of particular interest as their argument is closely related to mine. Bruno Latour and Steve Woolgar argue that to examine laboratory science, scholars should practice laboratory science (Latour and Woolgar 63-65). The parallels between this work and the work of Latour and Woolgar are worth exploring, and since their work occurred in the 1970’s it would be beneficial to explore the reaction that the community had to their work and if it had a positive impact on scholarship.

This work has implications for various other fields of study within many disciplines. I do not intend on interacting with the many other fields which I am not well versed enough in to communicate. Instead, this dissertation is concerned with the field of game studies and how that field interacts with the means of production for the artifacts it critiques. As discussed in an earlier chapter, language is used by some developers as a means of gatekeeping when it comes to other developers. I have not asserted the importance of digital game development within scholarship as a means of gatekeeping against scholars who do not participate in the practice of development. Instead, the intent of this work is to communicate the benefits of an understanding

150

of development and that when scholars practice development they have the ability to explore further the medium, additionally when scholars perform development they peer into the black box and understand how to avoid the pitfalls that come with blackboxing the medium that they study. In future research I will explore the ways that my dissertation applies to other fields and the ways that other fields already implement similar ideas.

In my own experience, I would change a few things in this process to better approach digital game development by exploring it not in terms of thoroughly documenting the process, but instead approaching it in terms of understanding how the process impacts the final product. I would have created fewer documents and fewer steps in the documentation process and focused primarily on critical aspects of development and then documented those after the process was complete. By documenting everything as it occurred, I created a different data sample. That method illuminated some of the ways that digital game development can be used to help scholars. I believe that focusing on those critical moments of development instead of the smaller details of the moment to moment would produce a greater understanding of how development can help scholars. I do not believe that the way that I went about it would be a suitable methodology for future reference. Instead, a somewhat modified method would probably produce better results.

I regret that I am unable to accomplish all these tasks in this work. Instead, I must call for further research and further study within this focus of digital game studies. As I have stated previously in this work, some books and authors and articles touch on digital game development when it comes to game scholars. However, they do not profoundly explore or touch directly on its importance. I call for more scholars to examine and emphasize the importance of digital game

151

development. As scholars research and explore the topic of development to see how to perform the act of digital development, thereby communicating their findings with the field at large. I believe that the negative effects of screen essentialism would be drastically lessened, and the field will reap the benefits.

Screen essentialism and black boxing within the realm of game studies can lead to an increase in scholars viewing games as the final interactive product and not as created works by teams of dedicated artists, coders, level designers, riggers, modelers, animators, and others. By removing the process and focusing purely on what ends up on the screen, game scholars have lost the connection to the medium that they critique. Understanding a little of the development process by talking about, practicing, and examining development can help to chip away at the adverse consequences of screen essentialism and black boxing. Scholars should be talking about, reading about, and experiencing development in one of its many different forms better to understand the impact of screen essentialism and black boxing.

There is ample room for more exploration of this type of study. I would call on those within the game studies field to begin to reference development, start to research development, and experience development. All game studies scholars should experience development, whether through team or solo development, or reading about development. Game studies scholars would benefit from gaining an understanding of what is within the black box and would easily avoid the pitfalls of blackboxing and screen essentialism.

Digital games are a mediated play interaction between machines and humans. Hardware and software all play a role in this mediated interaction. It is just as important to have scholars look at and understand input, hardware, and code, as it is to understand the finished product

152

displayed on the screen. Digital game scholars, therefore, must understand the process of development. Scholars must recognize digital game development as an essential component of the digital game artifact, when scholars forget to include development in their approach; that is how the adverse effects of screen essentialism and black boxing can thrive. Digital game scholars must speak to development; they must recognize it; they must see it as an essential aspect of game studies so that the field may continue to grow and continue to understand better the medium which it studies. Digital game development must become a key aspect of game studies methodology and research in the future. This work seeks to invite all game scholars to open the black box.

153

APPENDIX A

GAME DESIGN DOCUMENT

Academic Game Development

Game Lab Sim

154

Game Analysis Game Lab Sim is a tycoon style game where the player controls a game development lab

at a university. The player will hire and fire students as well as manage money to build a

reputation and receive more substantial grants.

Mission Statement

This game is intended to be made as a companion to my dissertation, and as such, has

academic purposes as the driving force behind it.

Genre

Tycoon, Sim

Platforms

155

Gameplay

Overview of Gameplay

The game will feature management mechanics similar to many within the genre. The player will hire and assign grad students to develop a scholarly game. Students will have various stats like semesters left till graduation, coding, art, and design skill. These skills will determine the quality of the work performed by the student. The students’ skills will grow as they develop more titles, and as they go to classes. As the game progresses, the students will graduate requiring the player to hire new ones to continue the process of development. As this will be a simulation of the ideal scholarly development situation, there will be a budget for the player to hire students; also, the students will not skip development time and will not get sick. The game will be exceedingly forgiving since the focus is not the game’s difficulty but rather the scholarly development process. All player interactions will be handled on the mouse. The player will press various buttons on-screen to perform actions in-game. These might be the hiring of development students or it might be choosing a game that coincides with the scholarship the player is performing.

Player Experience

The player will begin by receiving a topic that will be a representation of what the scholar is researching at the moment. The player will have the choice to accept or reject this topic. The player upon selecting a topic they like will be able to choose to develop their game solo or with a small team depending on the budget for their work. If the player selects to work as a small team

156

the player will hire new team members. These will be procedurally generated. Each time the player hires a student they will be given a choice of three students or none of the above button. If the player chooses the none of the above option then they will be given another selection of three. Once a student is hired the process may be repeated twice for a total of three student hires.

Once the player begins the development phase, they must select a game type these will be provided based on the team size and the experience of the developers. The development of the game will occur and then experience will be awarded to the group. If students have gained sufficient experience, they will level up allowing for new games to be made. Once leveling occurs then the process will begin again. The whole loop should take less than ten minutes.

157

Figure 26. Flow Chart Design Doc

The above chart demonstrates how gameplay might be accomplished in the game. The intent is to have the player hiring new students and maintaining a flow of points into the game constantly.

158

Gameplay Guidelines

Since this game will be an academic game focusing on digital game development, there will be no violence, no strong language, and no objectionable content. The game will emphasize traditional Tycoon mechanics as well as the academic setting. Gameplay should be as simple as possible to be as accessible as possible to as many different player types.

Game Objectives & Rewards

The game will feature points which can go to getting larger Grand to give the player more money in that increase in money allows them to hire better students. The point system should be the driving force in the game. The game has a win state where if the player obtained the highest level grant, they win the game. Points can be lost if the player does not spend all of their allotment of money for the year. The lose state is triggered when the player has lost above a certain amount of points.

Rewards Penalties Difficulty Levels

The player is rewarded with a The player is docked points for The game will only have one larger budget to hire better going under budget. difficulty level. students.

159

Gameplay Mechanics

The game will be coded to Frames Per Second (FPS) which will always be set to 60 for each room. The chief interaction will be through clickable buttons. These should have a response time between 15 and 30 frames or whatever has the best feel. All buttons need to be standardized in terms of color and font to allow for rapid understanding by the player. These buttons should also be standardized in terms of reaction time.

The game’s interactions should be coded in a way that allows the player to both navigate the space and also go to have the correct feel. There should be a button created for the grant system the hiring system the firing system the store system and exiting the game. The button for the firing system interacts differently than the others as it will trigger a flag that allows the player to click on already hired students and remove them, this interaction is used for removing students to spend money to hire new students and avoid any penalty to the points which occurs if there is leftover money at the end of the year.

The game's scholarly topic system will give the overall score for the semester a buff or debuff depending on the students and on the current game studies climate. These will be randomly assigned to the group each semester. The player can choose to push a topic to the next semester or to keep the topic for the existing one. There needs to be a considerable amount of balancing so that the player does not feel like they are unfairly docked points because of a random mechanic. This mechanic, out of all others, has the highest likelihood of being troublesome to development and the player. As such, this is also the mechanic most likely to be cut from the final game.

160

The point system works as a gatekeeper to higher and better grants. The grants will have four basic levels, one being the starting grants which cannot be accepted or qualified for after the player moves beyond them. The point system will function via each student who has various attributes; those attributes have point values when a student is hired they are given a major that major reduces to a specific trait and then that is added at the end of each turn to the point total.

Each turn in-game is one semester. Other factors like upgrades to computers will increase or decrease this point total if the player has leftover money at the end of a year then that subtracts from the point total. The purpose of the points is to give the player the ability to get grants which increase the total amount of funds that they receive every year. These grants require the player to have a certain number of points before they can be accepted.

The grant system will be based on a combination of various elements. Grants are accepted based on the team size, the number of semesters completed, and points. These three factors will challenge the player and make the game playable. This aspect of the game will require the most amount of tweaking. There are aspects of this mechanic that will cause headaches if not implemented correctly. If the requirements are too high, then the player will become frustrated in the process and the game will last longer than is intended. If the requirements are too low, the game will be shorter than expected as well as being far too easy for most players. This mechanic will require the most balancing and should ultimately feel right when played.

The hiring mechanic will be the core way that a player gains points; it also will influence the team size score for the grants. When the player clicks on the hiring button on the main game

161

screen, it will take them to a new screen where they will be given a choice of three candidates to hire. If the player does not wish to hire any of the candidates or cannot afford to hire any of the candidates, they can return to the main screen and then click the higher button again to get a new pool of candidates. This process may be repeated up to three times to give the player the best chance at finding a suitable candidate for the amount of money that they have. There will be three levels of candidates — a poor, average, and superior. Poor candidates will have a lower score on each of their qualities; however, they will also cost less. The average candidate will have more points available than the poor candidates, and they will subsequently cost more. The superior candidates will have more points than the average and cost more than the average candidates.

Another factor that the candidates will have is the number of semesters in the program and the number of semesters left, and this will help players decide which candidates to hire based on how long they can work. The number of semesters left is also vital because students as each semester ends have a chance at leveling up in one of their particular qualities making them more valuable as time passes. This mechanic will balance out the cost-benefit for poor candidates or superior candidates if the player has a poor candidate with a low semester count then that means that they have a higher likelihood of leveling to the point that they become useful. While a great candidate that could have a higher semester count might be a less efficient way of spending money, then the lower cost and lower semester students.

The upgrade system is the least impactful of all systems. Each upgrade only adds one to the total points for the semester if the player upgrades four times then that's an additional four

162

points per semester which will not make a significant impact on gameplay but is an efficient way to use excess funds instead of being docked points at the end of the year. The upgrade system should include upgrades to the computer as well as the lab space, in general. There should be some form of mechanic where the player can allocate all-access funds at the end of the year. The player should have between two and three opportunities to do this. This mechanic saves the player but will not impact points; it will spend all of the player's access money and will give the player no benefit other than making it so they do not fail. This mechanic will function in the way that lives function in other games allowing the player to take a particularly tricky year and save themselves from losing points. There will be a limit however to the number of times that a player can use this mechanic to protect themselves. In terms of balancing this mechanic should require the least amount of balancing to get functioning correctly.

The game will feature a win and fail state. The fail state will occur when the player is between -100 and -300 points. This fail state will need to be balanced per the student mechanic, and the grant mechanic to figure out what an appropriate total is for the fail state. The win state will be achieved when the player can accept the highest bracket of grant. The games win state should be able to have the player select an option to reset the game, resume the game, or quit the game. The fail state should allow the player to reset the game or quit the game.

As a stretch goal, a save option should be incorporated so that players can continue going after winning the game. However, as the game is intended only to be played for 10 minutes, having a save feature is not a requirement. If the game were to go into further development or if it became apparent that the game needed to be between 30 minutes to an hour. Extending out

163

upgrades and the grant system, then a save mechanic would be necessary. As the game is planned right now a save mechanic would not be beneficial.

All of the mechanics of the game should be driven via the mouse. The players should be able to click various buttons to achieve their goals. Each system should be coded so that mouse interaction is the primary interface. The creation of hotkeys for multiple interactions should be a goal for later in production but not a primary goal. Instead, the mouse and mouse interactions within the game space should be the focus of development. Mouse interactions need to feel intuitive and natural, each button press should have a decent reaction time and as stated earlier, those should be between 15 and 30 frames. Because the player will be interacting with the mouse, each button should do have a clear signal to the player before that it has been clicked, and that it has been selected. A way that this could be achieved is by using a hover mechanic where the mouse goes over a button, and it changes color to let the player know that it has been highlighted.

Game Modes

Regular Regular mode is the original game up until the

win or lose state is achieved. Endless

The endless mode is selected once the player

achieves the win state and selects to resume the

game. Fundamentally there is no difference

between these two game modes just that one

164

never has an end.

Scoring System

Points How it’s Awarded & Benefits

The player will gain points. The player will be awarded points for every

semester they have a student hired. The quality

of student and equipment will modify this.

The player benefits by being able to accept

larger grants paying more and allowing for the

hiring of new students.

Level Design

There is only one level for the game and that will be the main game lab. This level will

provide the players base of operations and all menu interactions that lead away from this

screen will have quick recall buttons to return to this main level. The level will be from a

top-down view to make art development simpler as well as provide the player with a

high-level view of all the stats for the game.

165

Levels

Main Lab The main lab will be the only level for the

game and will feature three desks for three

potential hires.

Figure 27. Level Design

Control Scheme

All of the game's interactions will be mapped to the mouse, in particular the left mouse button. This input should feel natural with a tycoon type game. As a stretch goal, hotkeys could be coded to improve user interaction and allow for rapid player interaction.

166

Figure 28. Interaction

Button/ Touch Input Action it Performs

Left Mouse Button All interactions within the game are performed

by the mouse.

Stretch Goal Input

Button/ Touch Input Action it Performs

H A hotkey for the hire menu.

F A hotkey for the fire mechanic.

167

S A hotkey for the store menu.

Space Bar A hotkey for ending the turn.

ESC A hotkey for returning to the main menu, or to

the game lab level depending on context.

Game Aesthetics & User Interface

Figure 29. UI Game Dev Tycoon

168

Figure 30. UI Game Dev Story

The art direction of the game should be based primarily on the two screenshots at the beginning of the section. Game Dev Tycoon and Game Dev Story both are games focusing on game development, and those strongly inspire this game. Due to this inspiration, it would follow that the game's art style would be similar to those games. Unlike those games, this game's art style will be more 8-bit and more pixelated due to aesthetic and Technical desires. This project's art will be reminiscent of the NES Era. In other words, the artwork should be in an 8-bit art style.

The lower bit art style will both keep the file size low and maintain a smooth 60 frames per second no matter what machine is running it. Games like The Legend of Zelda, Super Mario

Bros. 3, and Kirby’s Adventure all play a role in the inspiration for the art style of this game by providing examples of artwork and color pallet.

169

Figure 31. Super Mario Bros. Music and Sound should reflect this 8-bit Style by utilizing chiptunes effects and music.

Maintaining the aesthetic through both Visual and auditory means will help to unify the project.

While it is essential to maintain the feel that the game will have using 8bit art and sound, it is also vital for the music and sounds not to be overly grating. In that vein, the music and sound could be more modern as long as the overall aesthetic isn’t dramatically affected.

170

Figure 32. UI Mockup Design Document

The UI will communicate to the player the students stats the player's progress toward the next goal. The UI will also feature the amount of money the player has left to spend as well as the total budget for the year. UI elements will also keep track of the points that the player has gained during the game. It is important that the player can distinguish how much money is left to spend to reduce the number of times that the player is penalized on accident.

171

APPENDIX B

CODE REFERENCE

Code 1

Button Code /create event timer=30 click=0

/left click event audio_play_sound(snd_button,1,false) click = 1

/step event if click = 1

{

timer=timer-1

} if timer = 0

{

audio_stop_all()

room_goto(rm_game)

}

172

Code 2

Title Code

/create event draw_set_font(fnt_menu) draw_set_color(c_black) audio_play_sound(snd_menumusic,1,true)

/draw GUI event draw_text(x,y,"Dissertation Game")

Code 3

Hire Card

/create event image_speed=0 image_index=0 click1=0 total=irandom_range(1,20) semester=irandom_range(2,5) art=0 design=0

173

code=0 qa=0 poor=0 average=0 great=0 namef=choose("Bill ","Nick ","Tim ","Tom ","Katie ","Mary ","Nicole ","Naomi ","Liz ","Steve ","Chris ","Spencer ","Monica ","Kim ","Rodger ","Luke ","Fran ") namel=choose("Campbell","Buckner","Templtin","Vigori","Pulson","Kunther","O'Dool","Goldb erg","Banks","Ferrel","Farnsworth","Gildner","Remerez","Guteraz") name=namef+namel cost=0 draw_set_font(fnt_card) if total<=2 { poor=1 cost=400 } if total>=19 { great=1 cost=1000 } if total<=18 and total>=3 { average=1 cost=800

174

} if poor=1 { art=1 design=1 qa=1 code=1 } if average=1 { art=irandom_range(1,2) design=irandom_range(1,2) qa=irandom_range(1,2) code=irandom_range(1,2)

} if great=1 { art=irandom_range(1,3) design=irandom_range(1,3) qa=irandom_range(1,3) code=irandom_range(1,3) }

Code 4 Stat Transfer

175

/step event if click1=1 { if global.staff<3 { click1=0 global.hire=1 global.staff=global.staff+1 global.art=self.art global.design=self.design global.code=self.code global.design=self.design global.qa=self.qa global.semester=self.semester global.name=self.name global.money=global.money-cost instance_destroy(obj_hirecard) room_goto(rm_game) } }

Code 5 Cancel Button

/create event

176

image_speed=0 image_index=0 click=0 timer=60 /left pressed event audio_play_sound(snd_button,1,false) click=1 /step event if click=1 { timer=timer-1 } if timer=0 { click=0 timer=30 instance_destroy(obj_grant) instance_destroy(obj_hirecard) room_goto(rm_game) }

Code 6

Grant Purchase

/left click event

177

if global.rep>=rep and global.semesterh>=experiance and global.team>=team { audio_play_sound(snd_button,1,false) click=1 } if global.rep

Code 7

178

Grant Randomization

/create event image_speed=0 image_index=0 click=0 timer=30 rep=0 money=choose(1200,1600,2400,3200) experiance=0 team=0 name=0 if money=1200 { name=choose("EGADS","FROLP","HUMSTA","PPLSAS","INTALSD","KLORPS") rep=irandom_range(10,15) experiance=choose(2,4) team=choose(1,2) } if money=1600 { name=choose("FRNT","HUND","JASL","PPLY","GJKH","VKHJ","GJWEK") rep=irandom_range(15,20) experiance=choose(4,6) team=choose(2,3) }

179

if money=2400 { name=choose("SDF","LJK","ESA","EWJ","WEF","WEC","WER") rep=irandom_range(20,25) experiance=choose(6,8) team=3 } if money=3200 { name=choose("JK","OP","AC","O","ES","IK") rep=irandom_range(25,35) experiance=choose(6,8) team=3 }

Code 8

Grant Penalty

/step event if global.year=2 { if global.money>0 { if global.money<=100 {

180

global.rep=global.rep-5 } if global.money>100 { global.rep=global.rep-10 } } global.year=0 global.money=global.funds }

Code 9

Student Spawn

/step event if click=1 { timer=timer-1 } if timer=0 { click=0 timer=30 room_goto(rm_hireselect) }

181

if global.staff =1 and instance_number(obj_worker1)=0 and global.fire=0 and global.hire=1 { instance_create_depth(546,212,-10,obj_worker1) global.team=global.team+1 global.hire=0 } if global.staff =2 and instance_number(obj_worker2)=0 and global.fire=0 and global.hire=1 { instance_create_depth(176,199,-10,obj_worker2) global.team=global.team+1 global.hire=0 } if global.staff =3 and instance_number(obj_worker3)=0 and global.fire=0 and global.hire=1 { instance_create_depth(276,466,-10,obj_worker3) global.team=global.team+1 global.hire=0 } if global.staff=1 and instance_number(obj_worker1)=1 and instance_number(obj_worker2)=1 and instance_number(obj_worker3)=0 { global.staff=2 } if global.staff=1 and instance_number(obj_worker1)=1 and instance_number(obj_worker2)=0 and instance_number(obj_worker3)=1 {

182

global.staff=1 } if global.staff=2 and instance_number(obj_worker1)=0 and instance_number(obj_worker2)=1 and instance_number(obj_worker3)=1 { global.staff=0 } if global.staff=2 and instance_number(obj_worker1)=1 and instance_number(obj_worker2)=1 and instance_number(obj_worker3)=0 { global.staff=2 } if global.staff=3 and instance_number(obj_worker1)=0 and instance_number(obj_worker2)=1 and instance_number(obj_worker3)=1 { global.staff=0 } if global.staff=3 and instance_number(obj_worker1)=1 and instance_number(obj_worker2)=0 and instance_number(obj_worker3)=1 { global.staff=1 } if instance_number(obj_worker1)=0 { global.staff=0 }

183

BIBLIOGRAPHY id Software . (2016). Doom. Bethesda Softworks.

Aarseth, E. J. (1997). Cybertext. Baltimore, MD: John's Hoppkins University Press.

Adams, E. (2014). Fundamentals of Game Design Third Edition. New Riders.

Amccus. (1997). Harvest Moon. Natsume.

Anthropy, A. (2012). Dys4ia. Newgrounds.

Bagdikian, B. (2003). The Endless Chain. In The New Media Reader (pp. 472-483). Cambridge: MIT Press.

Barlow, J. P. (1996, Febuary 8). A Declaration of the Independence of Cyberspace. Retrieved April 20, 2016, from https://www.eff.org/cyberspace-independence.

Barone, E. (2013, February 13). Stardew Valley Developer Blog. Retrieved 7 23, 2019, from https://www.stardewvalley.net/blog/.

Barr, P. (2008). Video Game Values:Play as Human-Computer Interaction. PhD Thesis.

Barthes, R. (1970). S/Z. New York: Hill and Wang.

Baudrillard, J. (1994). Simulacra and Simulation. Ann Arbor: The University of Michigan Press.

Berger, J. (1973). Ways of Seeing. London: Penguin.

Bernfeld, L. (2014). Constructing a Reality: A Post-Structural Analysis of Deus Ex. In M. E. Dawn Stobbart, Engaging with Videogames. Oxford: Inter-Disciplinary Press.

Bethesda Game Studios. (2015). Fallout 4. Bethesda Softworks.

Bethesda Game Studios. (2016). Creation Kit. Bethesda Game Studios.

Bogost, I. (2007). Persuasive Games: The Expressive Power of Videogames. Cambridge: MIT Press.

Bogost, I. (2008). Unit Operations. London, England: MIT Press.

Bolter, J. D. (2001). Writing Spaces: Computers, Hypertext, and the Remediation of Print. New York: Routledge.

184

Bolter, J. D., & Grusin, R. (1999). Remediation: Understanding New Media. Cambridge: MIT Press.

Boluk, S., & LeMieux, P. (2017). Metagaming: Playing, Competing, Spectating, Cheating, Trading, Making, and Breaking Videogames. Minneapolis: University of Minnesota Press.

Bush, V. (1945, July). As We May Think. The Atlantic Monthly.

Caillois, R. (2001). Man, Play and Games. Chicago, IL: University of Illinois Press.

Capybara Games. (2014, May). Super Time Force. Capybara Games.

Castronova, E. (2007). Exodus to the Virtual World: How Online Fun Is Changing Reality. New York: Palgrave MacMillian.

Choice of Games. (2010). Choice of the Dragon. Choice of Games.

Chucklefish. (2019, March 14). Official Stardew Valley Wiki. Retrieved August 24, 2019, from https://stardewvalleywiki.com/Stardew_Valley_Wiki.

Chun, W. H. (2008). Control and Freedom: Power and Paranoia in the Age of Fiber Optics. Cambridge: MIT Press.

Chun, W. H. (2011). Programmed Visions: Software and Memory. Cambride: The MIT Press.

Collins, K. (2008). Game Sound: An Introduction to the History, Theory, and Practice of Video Game Music and Sound Design. Cambridge: The MIT Press.

ConcernedApe . (2016). Stardew Valley. Chucklefish.

ConcernedApe. (2013, July 1). Game development and engine decision. Retrieved 12 5, 2016, from http://community.playstarbound.com/threads/game-development-and-engine- decision.25210/.

Costikyan, G. (2013). Uncertainty in Games. London, England: MIT Press.

Dang, A., & Li, K. Y. (2008). The Suicide Game.

Debord, G. (1994). The Society of the Spectacle. (D. Nicholson-Smith, Trans.) New York: Zone Books.

Dennaton Games. (2012). Hotline Miami. Devolver Digital.

Derrida, J. (1974). Of Grammatology. Baltimore: Johns Hoppkins Press.

185

Eco, U. (1976). A Theory of Semiotics. Bloomington: Indiana University Press.

Eidos Interactive. (2011, August). Deus Ex: Human Revolution. Eidos Montreal. Eidos Interactive.

Eidos Montréal. (2016). Deus Ex: Mankind Divided. Square Enix.

Epic Games. (1998). Unreal Engine. Epic Games.

Flanagan, M. (2013). Critical Play: Radical Game Design. London, England: MIT Press.

Foucault, M. (1977). Language, Counter-memory, Practice: Selected Essays and Interveiws. (D. F. Bouchard, Ed., & D. F. Bouchard, Trans.) New York: Cornell University Press.

Foucault, M. (1998). What is an Author? In M. Foucault, & J. D. Faubion (Ed.), Aesthetics, Method, and Epistemology (R. Hurley, Trans., pp. 205-222). New York: The New Press.

Frasca, G. (2003). Simulation versus Narrative: Introduction to Ludology. Video/Game/Theory.

Fuller, M. (2008). Software Studies: A Lexicon. Cambridge: MIT Press.

Galloway, A. R. (2006). Gaming: Essays on Algorithmic Culture. Minneapolis: University of Minnesota Press.

Galloway, A. R. (2012). The Interface Effect. Cambridge, UK: Polity Press.

Gitelman, L. (2006). Always Already New: Media, History, and the Data of Culture. Cambridge: The MIT Press.

Goldberg, H. (2011). All Your Base Are Belong To Us: How Fifty Years of Videogames Conquered Pop Culture. New York: Three Rivers Press.

Greenheart Games. (2012). Game Dev Tycoon. Greenheart Games.

Grossman, A. (2013). Postmortems from Game Developer. Burlington, MA: Focal Press.

Hayles, N. K. (2012). How We Think: Digital Media and Contemporary Technogenesis. Chicago: The University of Chicago Press.

Hello Games. (2016). No Man's Sky. Hello Games.

Huizinga, J. (1950). Homo Ludens. New York: Roy Publishers.

International Game Developers Association. (2014). Developer Satisfaction Survey (DSS) Summary - 2014. International Game Developers Association.

186

Isbister, K. (2017). How Games Move Us: Emotion by Design. Cambridge, MA: MIT Press.

Jones, S. E. (2008). The Meaning of Video Games: Gaming and Textual Strategies. New York: Routledge.

Juul, J. (2005). Half-Real. London, England: MIT Press.

Juul, J. (2013). The Art of Failure: An Essay on The Pain of Playing Video Games. London, England: MIT Press.

Kadokawa. (2015). RPG Maker: MV. Degica.

Katie, S., & Zimmerman, E. (2004). Rules of Play: Game Design Fundamentals. Cambridge: MIT Press.

Kelty, C. M. (2008). Two Bits: The Cultural Significance of Free Software. Durham: Duke University Press.

Kent, S. L. (2001). The Ultimate History of Video Games. New York: Three Rivers Press.

Kirschenbaum, M. G. (2008). Mechanisms: New Media and the Forensic Imagination. Cambridge: MIT Press.

Kittler, F. (1995, 10 18). There is No Software. Retrieved 2015, from http://www.ctheory.net/articles.aspx?id=74.

Kittler, F. (1999). Gramophone, Film, Typewriter. (G. Winthrop-Young, & M. Wutz, Trans.) Stanford: Stanford University Press.

Koster, R. (2005). Theory of Fun for Game Design. Scottsdale: Paragraph Press.

Landow, G. P. (1992). Hyper Text. Baltimore: Johns Hopkins University Press.

Larian Studios. (2015). Divinity: Original Sin. Larian Studios.

Larian Studios. (2015). Divinity: Original Sin Design Documents. Larian Studios.

Larian Studios. (2017). Divinity: Original Sin II. Larian Studios.

Latour, B. (1986). Pandora's Hope: Essays on The Reality of Science Studies. Cambridge: Harvard University Press.

Latour, B., & Woolgar, S. (1986). Laboratory Life: The Construction of Scientific Facts. Princeton: Princeton University Press.

Laurel, B. (2014). Computers as Theatre. New York: Addison Wesley.

187

LeMieux, P., & Boluk, S. (2017). Memento Mortem Mortis. University of Minnesota Press.

LeMieux, P., & Boluk, S. (2017). Triforce. University of Minnesota Press.

LeMieux, P., & Boluk, S. (2017). 99 Exercises in Play. University of Minnesota Press.

LeMieux, P., & Boluk, S. (2017). It Is Pitch Black. University of Minnesota Press.

LeMieux, P., & Boluk, S. (2017). Tide Hunter. University of Minnesota Press.

Lenoir, T. (2000). All but War Is Simulation: The Military-Entertainment Complex. Configurations, 289-335.

Lessig, L. (2006). Code: And Other Laws of Cyberspace, Version 2.0. New York: Basic Books.

Licklider, J. (1960). Man-Computer Symbiosis. IRE Transactions on Human Factors in Electronicm, 4-11.

Linkin Park. (2014, Mar 25). Guilty All The Same (feat. Rakim) (Project Spark Official Video). Retrieved Apr 24, 2019, from https://www.youtube.com/watch?v=IfnhGW2Q_y0

Liu, A. (2004). The Laws of Cool: Knowledge, Work and the Culture of Information. Chicago: The University of Chicago Press.

Manovich, L. (2001). The Language of New Media. Cambridge: MIT Press.

Mayer-Schonberger, V. (2009). Delete: The Virtue of Forgetting in the Digital Age. Princeton: Princeton University Press.

McGonigal, J. (2011). Reality Is Broken: Why Games Make Us Better and How They Can Change the World. New York: Penguin Books.

McLuhan, M. (2003). Understanding Media: The Extensions of Man. Berkley, CA: Gingko Press.

McMillen, E., & Refenes, T. (2011, April 14). Postmortem: Team Meat's Super Meat Boy. Retrieved 8 24, 2019, from https://www.gamasutra.com/view/feature/134717/postmortem_team_meats_super_meat_ .php.

Media Molecule. (2019). Dreams. Sony Interactive Entertainment.

Mitchell, W. (1986). Iconology: Image, Text, Ideology. Chicago: The University of Chicago Press.

Mitchell, W. (2005). What do Pictures Want? Chicago: The University of Chicago Press.

188

Mojang. (2009). Minecraft. Mojang.

Monolith Productions. (2014, September). Middle-earth: Shadow of Mordor. Warner Bros. Interactive Entertainment.

Morris, A. R. (2004). Game Architecture and Design: New Edition. Indianapolis, Indiana: New Riders.

Murray, J. H. (1997). Hamlet on the Holodeck. New York: Free Press.

Nelson, T. H. (2003). Literary Machines. In The New Media Reader (pp. 443-461). Cambridge: MIT Press.

Niantic. (2016). Pokémon GO. Niantic.

Nideffer, R. F. (2003). Game Engines as Social Networks. Retrieved May 15, 2018, from http://www.nideffer.net/promo/pub/ssrc.pdf.

Nideffer, R. F. (2007). Game Engines as Embedded Systems. In V. Vesna, Database Aesthetics (pp. 211-230). Minneapolis: University of Minnesota Press.

Nideffer, R. F. (2011). Game Engines as Creative Frameworks. In M. Lovejoy, C. Paul, & V. Vesna (Eds.), Context Providers: Conditions of Meaning in Media Arts (pp. 175-197). Chicago: University of Chicago Press.

Night School Studio. (2016). Oxenfree. Night School Studio.

Nintendo EAD. (1998). The Legend of Zelda: Ocarina of Time. Nintendo.

Nintendo EPD. (2019). Super Mario Maker 2. Nintendo.

Nintendo R&D4. (1985). Super Mario Bros. Nintendo.

Nintendo R&D4. (1986). The Legend of Zelda. Nintendo.

Nintendo R&D4. (1988). Super Mario Bros. 3. Nintendo.

Nitsche, M. (2008). Video Game Spaces. London, England: MIT Press.

Noah Wardrip-Fruin, P. H. (2004). First Person: New Media as Story, Performance, and Game. Cambridge: MIT Press.

Noah Wardrip-Fruin, P. H. (2010). Second Person: Role-playing and Story in Games and Playable Media. Cambridge: MIT Press.

189

O'Donnell, C. (2014). Developer's Dilemma: The Secret World of Videogame Creators. Cambridge: The MIT Press.

Ostherr, K. (Ed.). (2018). Applied Media Studies. New York: Routledge.

Playdead. (2016). Inside. Playdead.

Pope, L. (2013, August). Papers Please. 3909 LLC.

Raven Software. (2002). Star Wars Jedi Knight II: Jedi Outcast. LucasArts.

Raymond, E. S. (2001, August 22). The Cathedral and the Bazaar. Retrieved August 29, 2016, from www.unterstein.net/su/docs/CathBaz.pdf.

Rockstar North. (2013). Grand Theft Auto V. Rockstar Games.

Rollings, A., & Morris, D. (1999). Game Architecture and Design. Coriolis.

Rose, F. (2011). The Art of Immersion: How the Digital Generation Is Remaking Hollywood, Madison Avenue, and the Way We Tell Stories. New York: W.W. Norton & Company.

Salen, K., & Zimmerman, E. (2004). Rules of Play: Game Design Fundamentals. Cambridge: MIT Press.

Salter, A. (2014). What is Your Quest?: From Adventure Games to Interactive Books. Iowa City: University of Iowa Press.

Salvato, D. (2017). Doki Doki Literature Club: Concept Art Booklet.

Schell, J. (2008). The Art of Game Design: A Book of Lenses . Boston: Morgan Kaufmann Publishers.

Schreier, J. (2017). Blood, Sweat, and Pixels: The Triumphant, Turbulent Stories Behind How Video Games Are Made. New York: HarperCollins.

Sicart, M. (2011). Against Procedurality. Retrieved March 21, 2018, from http://gamestudies.org/1103/articles/sicart_ap/.

Sicart, M. (2011). The Ethics of Computer Games. London, England: MIT Press.

Sicart, M. (2014). Play Matters. London, England: MIT Press.

Stanton, R. (2015). A Brief History of Video Games. London: Robinson.

Starbreeze Studios. (2013, August). Brothers: A Tale of Two Sons. 505 Games.

190

Stefans, B. K. (2012). Language as Gameplay: Toward a Vocabulary for Describing Works of Electronic Literature. Retrieved Febuary 5, 2016, from http://www.electronicbookreview.com/thread/electropoetics/gameplay.

Supergiant Games. (2011). Bastion. Warner Bros. Interactive Entertainment.

Taylor, T. L. (2006). Play Between Worlds. Cambridge, Mass: MIT Press.

Team Dakota. (2014). Project Spark. Microsoft Studios.

Team Meat. (2010). Super Meat Boy. Team Meat.

Team Salvato. (2017). Doki Doki Literature Club. Team Salvato.

Thatgamecompany. (2012). Journey. Sony Interactive Entertainment.

The Fullbright Company. (2013, August 15). Gone Home. The Fullbright Company.

Tolstoy, L. (1996). What is Art? New York: Penguin Books.

Turner, F. (2006). From Counterculture to Cyberculture: Stewart Brand, the Whole Earth Network, and the Rise of Digital Utopianism. Chicago: The University of Chicago Press.

Ubisoft Montreal. (2018). Far Cry 5. Ubisoft.

Unity Technologies. (2005). Unity. Unity Technologies.

Valve Corporation. (2007, October). Portal. Valve Corporation.

Valve Corporation. (2011, April). Portal 2. Valve Corporation.

Wardrip-Fruin, N. (2009). Expressive Processing: Digital Fictions, Computer Games, and Software Studies. Cambridge: MIT Press.

Wardrip-Fruin, N., & Harrigan, P. (2009). Third Person: Authoring and Exploring Vast Narratives. Cambridge: MIT Press.

YoYo Games. (1999). GameMaker Studio. YoYo Games.

YoYo Games Ltd. (2017). GameMaker Studio 2. YoYo Games Ltd.

191

BIOGRAPHICAL SKETCH

Luke Bernfeld is a native of Pullman, Washington. He holds a Bachelor of Arts degree in

English Literature from Utah Valley University and a Master of Arts degree in Arts and

Technology from the University of Texas at Dallas. He has presented at numerous conferences, including Video Game Cultures and the Future of Interactive Entertainment Conference and had a paper published in Engaging with Videogames. With more than three years of post-secondary teaching experience, he thrives in the academic setting.

192

CURRICULUM VITAE

Luke S. Bernfeld

Education  The University of Texas at Dallas, PhD (ABD), Art and Technology, 2020

 The University of Texas at Dallas, Master of Arts, Art and Technology, 2014

 Utah Valley University, Bachelor of Science, English Literature, 2012

Instructional Experience  Instructor of Record: Computer Imaging, ATCM 2301, Spring 2019, Fall 2019, Spring 2020

 Teaching Assistant: Game Design Fundamentals, ATCM 2365, Fall 2017, Spring 2018, Fall 2018

 Instructor of Record: Game Studies, ATEC 3353, Fall 2015, Spring 2016, Fall 2016, Spring 2017

Presentations and Publications

International Conference Series in Games and Literary Theory, November 2015, New Orleans, LA

Presentation Title: Post-structuralism and Video Games: I’m Sorry, but Your Theory is in Another Paper

"Constructing a Reality: A Post-Structural Analysis of Deus Ex." Editors: Dawn Stobbart, Monica Evans. Engaging with

Videogames. Oxford: Inter-Disciplinary Press, 2014. eBook.

Video Game Cultures and the Future of Interactive Entertainment Conference, July 2013. Oxford, England, United Kingdom.

Presentation Title: Constructing a Reality: A Post-Structural Analysis of Deus Ex.

Popular Culture Association National Conference, April 2012. Boston, MA

Presentation Title: Constructing a Reality: A Post-Structural Analysis of Deus Ex.

Pacific Sociology Association Conference, March 2012. San Diego, CA

Presentation Title: Equal Opportunity Destruction: Gender Identity in Video Games.

Martin Luther King Jr. Celebration, January 2012. Utah Valley University, Orem, UT

Presentation Title: Slavery: Not Quite Abolished.

Contours of Knowledge Conference, December 2010. Utah Valley University, Orem, UT

Presentation Title: Equal Opportunity Destruction: Gender Identity in Video Games.