The TekaTekiTech System for Automated Minigame Generation : First Steps

Automated generation of entire games is a challenging task in computational creativity. This paper presents some initial explorations with a system for generating small puzzle games with simple mechanics but complex emergent gameplay. Our system is designed to enable collaboration between human designers and creative computer agents, and to explore the notion of writing code which itself writes code. Our aim is to produce games in which deciphering the mechanics of the game is itself a meta-mechanic, and where some puzzles may be unsolvable (but not obviously so). We draw an analogy between unsolvable puzzles and unprovable mathematical conjectures: we are intrigued to see whether the same force that compels mathematicians to persevere with a possibly futile proof extends to the wider population of gamers. Introduction This paper introduces TekaTekiTech1, a system for the generation of puzzle minigames. Our work on this system has only just begun; this paper is a motivation and discussion of our recent, present and future work. Our aim is to create a design space which is both sufficiently flexible to admit a wide variety of games, and in which the density of interesting games is high enough to allow them to be found easily. To keep the density of games high enough, we chose to limit the space to puzzle-type games, of the type which exhibit fairly simple mechanics to test the player’s reactions, dexterity and/or problem solving abilities. We did not set out with specific existing games in mind for the game designer to produce; instead our aim was to make available a range of interesting mechanics and see how the designer combined them. The results so far, based on random generation and tweaking by hand, are quite unique puzzles which are difficult to classify in terms of existing commercial games; some are reminiscent of the minigames featured in the Mario Party and WarioWare series of games by Nintendo. However we are confident that games in the style of more traditional puzzle games such as Tetris, Minesweeper and Sokoban, as well as some arcade games such as Pacman and Frogger, are also present in the space. “Teka-teki” is Javanese for “puzzle”. Our wider aim in this work is to investigate how players respond to games which are discovered rather than created. If a human game designer produces a game which is impossible to win, or only winnable through superhuman dexterity, then the player might reasonably say that the designer has made a mistake. However if such a game is discovered by an automatic game generator, we conjecture that the player will be much more tolerant of the unwinnable game, and indeed that coming up with an explanation for why it is unwinnable might be a pleasure in itself. Ensuring solvability is often a concern when automatically generating game content (Smith, Butler, and Popović 2013); instead, we are interested in the region of design space where even the designer does not know whether the content is solvable. Determining solvability then becomes an objective for the player rather than the designer. Our work here fits into the context of automated whole game generation. Due to the complexity of constructing a multi-faceted object such as a game, only a few projects have studied how to automate the entire process of generating a game. An important project in this area is the work of Cook et al. on the ANGELINA system, which designs entire games in a variety of genres using a co-operative co-evolutionary programming approach (Cook, Colton, and Gow 2015a; 2015b). The ANGELINA system has been particularly influential in games communities, for instance, as the first automated system to enter a game jam (Cook and Colton 2014). Other important projects which address game generation include early work of Nelson and Mateas on generating games in the style of Nintendo’s WarioWare series (Nelson and Mateas 2007). The Game-O-Matic project2 enables people to automatically generate short, simple games by defining relationships, as described in (Treanor et al. 2012), and an approach to puzzle generation with simulated physics models was investigated in (Shaker et al. 2013). Further aspects of AI for game design are discussed in (Riedl and Zook 2013). Taking a higher level view, Liapis, Yannakakis, and Togelius (2014) describe the mutual benefits for Computational Creativity research with application to video game design. This paper is structured as follows. First we describe how games are specified in the TekaTekiTech system, and http://cartoonist.soe. ucsc.edu how a specification translates to a playable game. Next we give some illustrative examples of games generated by the system, in two categories: first, abstract games designed with minimal human input; second, games where a human designer intervened to create games with meaning. Next we frame the TekaTekiTech system in the wider context of Computational Creativity, discussing our goals for the project in both scientific and philosophical terms. Finally we outline future work on the project. The TekaTekiTech system The system has two GUI components: an interface for designing games, and an interface for playing them. See Figure 1. A game in the system is defined by a set of elements such as: input event handlers; collision detectors and handlers; object spawners, movers and killers; game progress trackers and displayers; and theme managers for graphical and audio assets. Many of the element types take parameters. Figure 1 (a) shows an example of a game element being edited in the designer GUI. The element is of type NumPiecesDraggedProgressMechanism, and takes two integer parameters: failurePenalty and maxNumPiecesDragged. This element implements a game mechanic where at most maxNumPiecesDragged can be touched in one game: if more than this number of pieces are touched, the player loses failurePenalty points. TekaTekiTech currently defines a large library of element types, each of which is a Java class; the system can easily be extended by adding more element types. The elements are building blocks of middling complexity, more complex than e.g. arithmetic operators but less complex than e.g. movement controllers for game characters. Excluding boilerplate code, the behaviour of a single element is defined by 5–20 lines of code on average. In this way TekaTekiTech has superficial similarities with PyVGDL (Schaul 2014), but there are also many differences in design. PyVGDL is intended as a human-readable game specification language for AI competitions, and includes some high-level constructs to this end; in TekaTekiTech the emphasis is much more on automated generation and mutation of games, which would only be made more difficult by adding complexity to the specification system. All element types implement a respondToTick method, which is called once per game update for every currently active element in sequence. There is also a shared pool of events, and elements may add or remove events from the pool. For example one element may add information on a collision event to the pool, and another element may then handle the event. Certain elements can also modify the list of active game elements whilst the game is in progress. The game definition itself is simply a list of element types and parameters. The game specification is a flat list of elements. (The hierarchy shown in Figure 1 (a) reflects the hierarchy of Java packages defining the element types, and is provided for user convenience; the underlying data structure being edited is flat. ) This flat structure is in contrast to some other game description languages where the specification is a hierarchy of elements (Schaul 2014) or a program in a declarative programming language (Love et al. 2006). This makes it easy to generate TekaTekiTech games at random or by simple evolutionary approaches, for instance. The current version of the editor GUI allows elements to be added and deleted, and their parameters to be adjusted by sliders. Once the game has been edited, it can be played with a single menu command or shortcut key, allowing rapid iteration of editing and testing. This simple interface is enough to allow simple editing of random games, and even design of games from scratch. It is easy to envisage how more advanced editing tools could be provided to allow for local search, better parameter visualisations etc. This is a subject for future work. At the beginning of the game, elements are instantiated according to the specification. On each frame of the game, all elements are updated. Gameplay emerges from complex interactions between the components. It is important to make a distinction between game elements and on-screen game objects: elements manage various aspects of gameplay, which may include the creation, update and deletion of on-screen objects, but elements are not themselves objects in the game world. We now describe some of the games currently implemented in the system. These games were designed by a (very simple) creative agent in collaboration with a human designer: the games were initially generated randomly, before being curated, tweaked and themed by hand. Only minor tweaks were made to the games to make them more playable, for example adjusting the numbers or movement speeds of pieces to tune the difficulty (some generated games were far too difficult, others were far too easy). Importantly, no changes were made that substantially changed the core mechanics of the games.