Practical Game Design Tool: State Explorer Rokas Volkovas Michael Fairbank John R. Woodward Simon Lucas QMUL University of Essex QMUL QMUL London, UK Colchester, UK London, UK London, UK [email protected] [email protected] [email protected] [email protected] Abstract—This paper introduces a computer-game design tool B. Problem Scope which enables game designers to explore and develop game mechanics for arbitrary game systems. The tool is implemented To approach solving the problem of shortening the iteration as a plugin for the Godot game engine. It allows the designer to cycle of designing and building systems for games, we first view an abstraction of a game’s states while in active development narrow down its domain and define the scope of the problem and to quickly view and explore which states are navigable from in question. which other states. This information is used to rapidly explore, Our idealized set of features to address the problem of slow validate and improve the design of the game. The tool is most practical for game systems which are computer-explorable within video-game design iteration speed were identified. Conceptu- roughly 2000 states. The tool is demonstrated by presenting how ally, these were the ability to: it was used to create a small, yet complete, commercial game. • navigate game states manually • navigate game states automatically I. INTRODUCTION • to identify states of interest A. Video Game Design is Tedious • examine the explored states At their very core, games are systems built for human Given a tool with these features, a video game designer can interaction. Building these systems is the art form game delay manually play-testing the game for longer by using the designers specialize in, driving the evolution of game types. information provided by the tool. Boolean questions, such However, we argue, that in terms of the development support, “is this Sokoban level completeable?” or “can the player modern video game design is nowhere near as advanced as the move through a door without getting the key?” are answered secondary skills associated with game development. In other immediately, avoiding unnecessary play-testing. words, the premise of this paper is that designing systems for While there are many more features that can potentially video games is a tedious process and some of the tedium could cut down on the design iteration cycle time, these were be alleviated by exploiting available computational power. identified as the crucial foundation ones, upon which further The specific problem identified is that a significant amount improvements can be constructed. of game development time is consumed by play-testing. While some of that time is fundamentally inseparable from game C. Problem Domain development, we argue that a considerable amount of it is Having defined the conceptual requirements of the tool, wasted navigating through the game states to inform the next the specific technologies used are still in question. While the design-iteration decisions. This information could be in the individual approach to designing a game may vary drastically form of ensuring that a state of a game is accessible or not, from person to person, inevitably, in order to be playable on guaranteeing some values of the game state are consistently a computer, all video games have to be programmed on a reached, and other similar variants. computer in some way. Examples of wasted time are the playthroughs to make sure From the programming level, any type of further scope that a level in a puzzle game (e.g Sokoban) is solvable, reduction leads to sacrifices in ability to express some system playing a level of a Match-3 game (e.g Candy Crush) a descriptions. In order to maintain the generality of being able few times to get the idea of the average number of moves to program any system (not necessarily a game) and show needed to solve it or navigating dialog trees in text-based the viability of the developed tool, a language was selected to adventure games (e.g. A Dark Room). In all these cases, implement the tool for. Language generality is a particularly the information being extracted through the play-testing is important feature, as iterations in game designs might fluctuate technical in that it does not rely on the human experience. wildly between different types of system behaviour. In other words, these types of information extraction can The selected language was chosen to be GDScript, which be evaluated by writing specialized tests. However, from is the scripting language used in the Godot game engine. the authors’ experience, manual play-testing is usually faster Same language was used to implement the tool as a plugin than writing and maintaining specialised test code. This is for the engine editor. With this setup, the built plugin can highlighted by the fact that the tests would only be valid for be thought of as another tool in the engine toolbox. All the as long as a system is present in the game. Writing tests when language features used in this project can be readily converted design alterations are common is not a good use of time. Can to other languages, the primary reason for using this specific this issue be circumvented? setup was the authors’ familiarity with the environment. 1 D. Game vs Mechanics analysis sought after reinforces the perceived lack of tools supporting Given the nature of the task of speeding up game design, the process of (video) game design. it is important to stress the difference between supporting B. Machinations games and their mechanics. Arguably, non-trivial games are never conceived as a whole. Instead, they are constructed While there is no tool which would would ubiquitously from systems the player can interact with. These systems, used or at least known by game designers, there are defi- or mechanics, are not necessarily games, but are essential nitely practical and research attempts at establishing one and components of games. These include the ability to play a card, Machinations [3] is arguably the most prominent example. shoot monsters or steer a car. Many games share mechanics, Figure 1 shows the basic visuals of the program - a dedicated but differ in the way they are used in combination with other design application with a UML diagram-like interface. mechanics. As such, they can be viewed as the building blocks The primary goal the program attempts to achieve is the of games. This is to say that designing games first requires separation of the system development from games as much, if the design of mechanics; and so a tool, built to support game not more, as you would with 3D modeling software. It does design, should fundamentally support design of mechanics. To this through the creation of a whole ecosystem for mechanics rephrase, the goal of this project was to produce a tool which development. It can be argued that this is both its greatest would be useful even in designing mechanics such as moving advantage and disadvantage. on a 2D grid, where there is no winning or losing. Through isolation it can make assumptions, allowing quick access to features not easily integrate-able in traditional pro- II. RELATED WORK gramming. On the other hand, the relative iteration speed A. (Lack of) Game Design Support comes at the cost of a large up-front knowledge load for the person learning the tool and a lack of generality: constructing In a 2012 paper [1] Katherine Neil identifies a deeply a game in machinations can be seen as building a model of the related issue of lack of tools for game design: game, not the actual game itself. This is the most significant “While nobody would expect an architect, for example, area where the introduced tool differs. We argue that a self- to design a building with Microsoft Word, using natural contained development environment is a milestone that is to be language to communicate the layout of a building prior to reached eventually, but at the same time feel that reaching that construction, game designers are required to do something milestone must step through a series of cornerstones, bridging somewhat analogous to this.“ the available technology with that of self-containment. She argues that in order to overcome the hurdle and advance Much like Blender (3D modelling software) exports to the research in the field of game design support, real world many different standardized 3D model representations that data of how game design is conducted in practice is necessary. game engines can take and interpret, a tool created for the In the eight years since the analysis, little has changed. She purpose of building mechanics must integrate with the most goes into more depth in the topic in [2]. prominent tools used already; all without a human involved, Notably, game design suffers from being not only a rela- as is the case currently. To achieve this, a programming tively new art form, but also a tremendously time-consuming language library like interface with the developed prototype one. Specifically, while the introduced tool uses the design should provide a lesser barrier of entry for the designer already of a single game as a data point to show how game design programming prototypes and introduce the concepts necessary is done by some portion of smaller developers, it nowhere to make the transition to standalone tools. near represents the entire industry. Furthermore, the design and development of the game, by a single person, took roughly three months of full-time work with some experience in game development. Design taking roughly 70% of the work, about 30% of it mechanical, other 40% being the visual design, which also contributed to the mechanical design decisions.