{"content":[{"text":"ture Work I discuss the long-term goals for automated game \n design, and why I think continuous approaches are impor- \n tant. \n Automated game design is hard, and we are unlikely to \n see it have huge impact on mainstream game development \n any time soon. Nevertheless, it is a rich and exciting area to \n research in, and there are many unanswered questions and \n early ground still to be covered. It has the potential to shed \n a light on the broader ﬁeld of generative software too, by \n providing opportunity to reﬂect on development and design \n processes, and to understand how people respond to game \n content created by machines. It is more than another subﬁeld \n of procedural generation: automated game design lets us ask \n important questions about the involvement of AI in creative \n practices, in a medium that is inherently digital, interactive \n and ﬂuid. This paper is a short roadmap for some important \n goals I see on the horizon, but more than anything else we \n need more people and perspectives (particularly outside of \n hard AI) on this multifaceted and complex problem.","bbox":{"left":0.088235,"top":0.069138,"width":0.38975699999999996,"height":0.26422999999999996}},{"text":"Ostensibly developed as a mixed-initiative tool for journal- \n ists to rapidly create newsgames, the Game-O-Matic is ef- \n fectively an entirely autonomous game designer, with a very \n broad understanding of game mechanics and also how to \n convey messages through the combination of game rules. \n This meaning-driven game design is reinforced by several \n mechanisms that allow the Game-O-Matic to retrieve artistic \n assets to reinforce the game’s systems visually. Along simi- \n lar lines, work by Nelson and Mateas in (Nelson and Mateas \n 2008) also shows a concerted effort to build a system which \n can combine systems, meaning and visuals to convey some- \n thing through an interactive experience. \n There are also a range of tools that, while not built as au- \n tonomous designers, are sufﬁciently close in nature that they \n might only be a few small changes from being such. Tools \n like Tanagra (Smith, Whitehead, and Mateas 2010) use a lot \n of automation and self-analysis to provide support to a hu- \n man user, or the Sentient Sketchbook (Liapis, Yannakakis, \n and Togelius 2013) which ampliﬁes smaller creative inputs \n with embellishments and analysis, and Ropossum (Shaker, \n Shaker, and Togelius 2013), a similar tool targeting physics- \n based mobile games like Cut The Rope. These tools are per- \n forming a lot of the design work going on in their domain, \n even if the project’s intention is not to fully automate the \n task. Often, the need to support humans in any part of a cre- \n ative tasks means the system must, by deﬁnition, be able \n to perform every part of the task on its own. Such systems \n are usually only lacking in some higher-level control and \n production, and are otherwise very close to automated game \n design tools.","bbox":{"left":0.522059,"top":0.06914,"width":0.38975799999999994,"height":0.41644000000000003}},{"text":"Related Work \n Automated game design is often conﬂated with the notion of \n ruleset design. One explanation for this is the bias in games \n research towards a particular ‘classical’ concept of what a \n game is. Early research in AI focused on abstract games \n that are almost entirely described by a set of rules and noth- \n ing else (Checkers, Chess and Go being the best examples \n here). As games research moved more into digital games, \n classic arcade stereotypes replaced this notion; games with \n very strong notions of winning, losing, scoring. We can see \n this trend continuing to the modern day in the design and in- \n ﬂuences of the Video Game Description Language, VGDL \n (Schaul 2013). \n As a result of this conﬂation, a lot of automated game de- \n sign works pays homage to work on physical games, like \n the invention of Chess variants by Pell in (Pell 1992). This \n pioneering work was extremely safe in many ways: starting \n off from a solid foundation of human design, searching the \n nearby ruleset space with no other design elements to con- \n sider. Nevertheless, it represents an important step in appre- \n ciating that all game content can be generated or changed by \n a computer, not merely surface-level consumable content. \n The line of work on ruleset invention carries through to \n work on systems like Ludi, by Cameron Browne, which \n invented a broader variety of abstract games played with \n counter on grid boards (Browne 2008). Ludi is a compelling \n example of impacting a creative space – one of its game de- \n signs was published successfully, and has a good ranking on \n BoardGameGeek’s comprehensive and vast index of games. \n At the time of writing it is ranked #3,637 (out of over 90,000 \n games) and ranked #104 in Abstract Games. Like the Chess \n variants, Ludi works only on rulesets - it doesn’t distinguish \n between different design tasks, or consider any artistic qual- \n ities in its work. This doesn’t in any way diminish its sig- \n niﬁcant achievements - we mention it here only to underline \n the many other tasks we see in the ﬁeld of automated game \n design distinct from designing rulesets. \n In terms of digital games, the Game-O-Matic is a vital \n part of automated game design history (Treanor et al. 2012).","bbox":{"left":0.088235,"top":0.343332,"width":0.38978799999999997,"height":0.5465690000000001}},{"text":"ANGELINA \n Between 2010 and 2016, several versions of ANGELINA \n were developed. Most of them followed a similar modular \n development structure which broke the process of designing \n games into several processes which ran concurrently (Cook \n 2015). For example, the third iteration of ANGELINA – \n ANGELINA3 – had systems for designing levels, tuning the \n design of in-game upgrades, and laying out art and sound as- \n sets for maximum impact (Cook, Colton, and Pease 2012). \n All ANGELINA versions were designed as single-run pro- \n ductions, meaning that the system was turned on, given in- \n put, worked for a time, produced a game, and then stopped. \n Between runs, very little information was retained. The \n amount of data ANGELINA retained did increase over time, \n but even later versions only kept information relating to cul- \n tural knowledge and art assets. For example, ANGELINA5 \n built a list of cultural information and affective texture la- \n bels (a texture of grass gained labels like bright, nature, fresh \n over time) so that it could make better design decisions when \n it designed games in the future. \n A key goal with ANGELINA was presenting the system \n as a plausible and respectable creative entity. That is, a sys- \n tem which could engage with its peers in a creative com- \n munity, produce work that people engaged with and were \n interested in; a system which could show growth, justify its \n decisions and explain its process. Most of the later versions \n of ANGELINA wrote commentaries to explain their game \n designs, and ANGELINA entered game jams and exhibited","bbox":{"left":0.522057,"top":0.495538,"width":0.389767,"height":0.3943630000000001}},{"text":"55","bbox":{"left":0.492941,"top":0.934523,"width":0.01411800000000002,"height":0.015329999999999955}}],"images_bbox":[],"images_bbox_not_text_overlap":[]}