New Frontiers in AI for Game Design

Our approach began with a direct one-to-one visual translation of an existing VGDL game: Aliens, into a set of icons. Each keyword in the VGDL source was assigned a corresponding image, and these were arranged according to the original code’s structure. Figure 7 shows this initial mapping. This prototype allowed us to evaluate readability, expressivity, and compression potential. The translation raised several interesting design questions:

• $\mathrm{■}$

  1. Compression vs. readability: How much of the original syntax could be omitted while maintaining intelligibility?

• $\mathrm{■}$

  2. Layout affordances: Could spatial arrangements (e.g. crossword-like layouts, scattered clusters) improve memorability or efficiency compared to linear text?

• $\mathrm{■}$

  3. Expressive gaps: How might empty space, annotations, or decorations function as part of the design medium?

To answer these questions we attempted to make another prototype using cut up paper icons. We tried to compress it to the size of a postcard and took some liberties with the syntax of VGDL. This prototype is shown in Figure 9.

Several interesting insights and potentials emerged from our exploration:

1. 1.

   Collaborative and Community Play: A visual system lends itself naturally to physical artifacts that can be shared, such as postcards, magnets, or cards. These could enable community-created games where rules are tangible, remixable, and collectively modified.

2. 2.

   Tags, Variables, and Modularity: Inspired by modular sprite systems, we considered tag-like extensions (e.g. small polymorphic icons) to represent properties and attributes.

3. 3.

   Spatial Memory and Arrangement: The two-dimensional arrangement of icons introduces new cognitive affordances. Crossword-like layouts may enhance recall through spatial memory, though at the cost of efficient space usage. This reflects a trade-off between memory and efficiency.

4. 4.

   Cultural Encodings and Localisation: Visual symbols are not universally interpreted. Cultural context shapes how icons are read, suggesting the need for localisation strategies or multiple representational layers.

5. 5.

   Material Affordances: Unlike text, physical or visual arrangements invite shuffling, cutting, enlarging, or remixing.

6. 6.

   Live Coding and Debugging: Since each visual token has a direct mapping to mechanics visible in gameplay, it becomes possible to highlight active rules in real-time. This creates opportunities for live coding experiences, teaching tools, and interactive debugging.

There are many things to still explore around this idea. We have already made a small prototype that can recognize full lines of VGDL from arranged icons. Besides making a digital version of the paper prototype we made during the seminar, there are plenty of directions in which to go, such as live debugging, tangible icons, and exploring automated game design through this.

Mario Kart World (MKW) was released by Nintendo as a launch title for the Nintendo Switch 2 on June 5, 2025[1]. The gameplay – like previous iterations in the Mario Kart series – involves Super Mario characters participating in go-kart races. The tracks include items that can be used against other characters or power-ups such as a speed boost for the kart racer. However, unlike prior iterations, Mario Kart World included a new mechanic of open-world driving and navigation. MKW allowed players to freely roam between tracks on the “world map” area and complete minigames or small quests in addition to the traditional track racing.

While the open-world navigation introduced an innovative mechanic for the series – the authors felt the new mechanic did not meet certain expectations of an open world – such as exploration, discovery, and player camaraderie that can be created from spontaneous multiplayer interactions [2]. We developed a prototype multiplayer racing game in 8 hours at Dagstuhl Seminar 25292 in an attempt to explore these missing experiences from MKW.

The prototype was originally intended to be a 2.5D billboard style multiplayer game using Mode7 graphics (taking inspiration from the first Mario Kart game on the Super Nintendo system.) The tracks would also be procedurally generated instead of the manually designed tracks used in Mario Kart games. This could allow for more diverse and unique experiences for the player as they drove on the track. See Figure 11 for an example of the procedurally made “Karticle” tracks developed for the prototype.

For the multiplayer capabilities, P5.js⁷⁷7https://p5js.org/ and Vue.js⁸⁸8https://vuejs.org/ were used to handle server and client connections as well as display the graphics via an HTML5 capable browser. We used the p5party multiplayer framework, hosting client relays heroku, and launched the demo publically using ngrok. This demo was made completely free and available to play. When a player connected to the game, they were given a randomly assigned car color and a randomly assigned emoji to represent their character. There were a possible 375 different emojis available for the player – 7 times more characters than the character roster in Mario Kart World. Players had the ability to “honk” at other players connected to the server which would play an audio clip on all players’ browsers. This would allow for more direct social connection with other players while they were playing the game.

While the Mode7 rendering was unsuccessful for the demo, the top-down view of the track still allowed players to drive and follow the procedurally made track. The server allowed the entire seminar group to connect to the game. With a session size of 30 people this was more than the maximum multiplayer limit of 24 players in Mario Kart World. The prototype did not include power-ups or quests like MKW. In terms of social interactions players could only honk at one another in the game, but playing with everyone in the same room afforded spontaneous interactions external in the game. As such, while we did not accomplish our original objective, we felt that we presented an innovative social player experience in a procedural racing game.

Like dragons sitting on vast hoards of data, we enjoy an unprecedented wealth of content today.

We have access to cultural content – every historical object from the world’s museums, all the posts on Wikipedia, all the assets on Itch.io, or all the slow-burn romances of Archive of Our Own.

We have amassed decades of personal content, a mountain of unsorted photos, social media threads, and algorithmically recorded logbooks of our relationships, playlists, physical locations, GitHub checkins, and heartbeat.

We have generative algorithms, large and small, that create new content on demand. We can create new game maps, text snippets, poems, images, novels, and films, at the press of a button.

Massive data is an important new technology – but humans love to invent new games to play with new technology! So what games can you play with massive content? And why do so many of them involve other people? ⁹⁹9For this paper, we use “games” loosely in the “playful experiences” sense used by game philosophers like Bernie De Koven. So for this paper, Pinterest is a game, as is making a mix-tape for your best friend.

In this Dagstuhl working group, we looked at many social experiences that use massive content sources, and we’ve discovered that they have many common design patterns. Below, we will explain a few of these patterns, and examine them in use cases. This paper is far from exhaustive – we believe there is more to be discovered.

To create a playful user experience with massive content, one needs three things:

• $\mathrm{■}$

  Sources – you’ll need a massive source of content

• $\mathrm{■}$

  Features – interaction design patterns for what the users will do with the content, like surfing, annotating, or sharing it with others

• $\mathrm{■}$

  Uses – why is interacting with this content meaningful? Are we motivated by the content, or about our journeys and exploration, or is the content just a tool to socialize with each other?

For example, the Library of Babel¹⁰¹⁰10https://libraryofbabel.info/ is a site where every possible book exists, as a reference to the Borges story [3]. Its source is a generator that can create any “possible combination of 1,312,000 characters” on demand. Its primary feature is that each book is represented by a unique URL. Of course, most are random character combinations. There is a small Reddit forum¹¹¹¹11https://www.reddit.com/r/BabelForum/ dedicated to finding and sharing occasional discoveries within it, partly as appreciation, and partly for humorous absurdity.

Sources fall into several categories:

• $\mathrm{■}$

  Personal data: Anything we produce in our daily lives, from emails, to photos, personal notes to shopping lists, the music or the crafts we created

• $\mathrm{■}$

  Shared data: where people collectively and intentionally create large amounts of data, for the shared good

• $\mathrm{■}$

  Cultural-collections data: (Museum images, literature) Museums are full of art, digitalized, amazing poems, to literature feasts

• $\mathrm{■}$

  Commercial data: data that is either gathered commercially or scraped from commercial enterprises

• $\mathrm{■}$

  The social data we share explicitly – to be consumed by others in the void – Itch.io

• $\mathrm{■}$

  The social data we share implicitly – the comments to your friends’ posts, or some blog that you share for bookkeeping

• $\mathrm{■}$

  Algorithmic generators: data which doesn’t exist until the moment that it is created

None of these categories presuppose the relationship between the owner or creator of the source and the creator of the game, and the players of the game may have any possible relation to each other. One could make a game for oneself out of one’s own data, or be paid by a big-data owner to make a game for others (a common form of digital humanities grant from museums)[4]. Some games are made with data that was not intended (or allowed) to be used for play, which can be a source of both conflict[6] and transgressive power.

Features are the interaction, interface, gameplay, visualization, or sharing features that enable different kinds of exploration and social interactions.

For example, Max Bittker’s “River”[1] is a page where players can explore images that people have posted to Are.na. Exploration is done by clicking on one image among many, which causes the page to refresh with other images that are closest to that one in a vector embedding space (more similar). When this happens, the URL changes to the ID of the clicked image. So, if a player finds a favorite “region” of the content, they can share it with others.¹²¹²12Example regions: https://river.maxbittker.com/?id=1747330, https://river.maxbittker.com/?id=2878636

We found many such features, and many were common across multiple experiences.

Some features enable or disable ways to navigate through the content. For example, River does not allow searching, to instead encourage serendipitous discovery by proximal exploration. Exploration can be implemented by many different algorithms and heuristics – similarity-based, curiosity-based, or collaborative filtering. We can direct players to parts of the space near things they like, or direct them to places they have not explored, or to places that no other user has explored yet. We can even leave footprints to tell them how many other players have been here,¹³¹³13https://www.whatbeatsrock.com/ or give small UI prizes for discovering new parts of the space.¹⁴¹⁴14https://neal.fun/infinite-craft/

We can consider each unique page with its “central” image to be a landmark that we can share via URL, but it also offers landmarks as collectibles and boundaries (“Obama eating ice cream,” “Heavy Metal Lettering”) that players can try to discover. This simple feature (it is just a text suggestion) turns the free-form browsing into a seeking game instead. Landmarks in a large generative space can enable navigation, social conversations, or gameplay challenges.[7][8]

Other features enable players to understand their movement through the space or create paths and trails for others to follow. Trails can serve as a memory of how someone has moved through a space or record a path to guide someone else. In River, when M Charity achieved the nearly-impossible feat of navigating to “Obama eating ice cream” they were able to use the browser’s back button to demonstrate the path they took, image by image. In experiences like Spotify, we see users curating and sharing unique paths as a new form of content itself, sometimes to take the listener on an unexpected sonic journey and sometimes to make art out of the titles.¹⁵¹⁵15https://www.reddit.com/r/weirdspotifyplaylists/

We expect curation sports to emerge as their own form of play, as users discover particularly interesting spots or become famous as guides or expert-explorers in the space [9]. We also speculated about heuristic curation pets as a feature – not monolithic algorithms to create the “best” choices, but “characters” with viewpoints on how to move through the space, like the Tumblr bots mentioned in the case studies below. Could you make a mix tape for a friend? Could you make a mix-tape-making pet to give them instead?

Trails, landmarks, heuristics and more can be reified into content themselves. Often these are by URL, but can also be embedded in a PNG (as the creatures in the game Spore). This lets the feature engage in the technological ecosystem in any way a URL or image does: A landmark in a generative space could be hidden as a QR code or NFC chip on a sticker or trading card, and physically gifted, swapped, or hidden in a castle!

The final component is the uses of these experiences. An experience can have any number of features and choose many kinds of content to explore. But what communities and social interactions arise from those choices? What external or artificial structures give them different meanings? We found many such emergent behaviors and social phenomena: showing off, games and challenges, surfing, making gifts, intellectual advancement (understanding/exploration/learning), collaborative mapping, inspiration, creating organized information and annotation (the urge to tidy up a space), self-reflection, and discovery.

When we looked at social experiences, we found two common kinds:

• $\mathrm{■}$

  Collective Experience (sharing the experience) – You go through the experience individually, but share the outcomes with others.

• $\mathrm{■}$

  Collaborative Experience (sharing the space) – You work together in the same environment, creating and contributing to a shared outcome.

Pinterest Boards – June and her friends have developed an annual tradition where they curate Pinterest boards for each other. These carefully crafted collections serve as gifts that keep giving: recipients discover new recommendations and inspirations based on their friends’ thoughtful curation choices.

Redactle – This daily word-guessing game presents players with a randomly selected Wikipedia article that has been completely redacted (blacked out). Players must uncover the content by guessing words, gradually revealing the hidden article. The shared daily challenge creates natural conversation points, as friends compare their strategies and discuss the surprising topics they have collectively uncovered.

Tumblr Bots – Automated accounts scan Tumblr posts to identify text strings that correspond to DNA sequences, then post about the organisms they represent. This creates an unexpected treasure hunt where the community celebrates rare biological discoveries hidden within everyday social media content. Users take pride in finding particularly unusual organisms embedded in casual posts.

PicBreeder – This evolutionary art platform demonstrates a complete cycle of generative content interaction:

1. 1.

   Generated Data: AI networks called CPPNs create diverse images

2. 2.

   Search: Users browse and select favorites from random assortments

3. 3.

   Discovery: The algorithm evolves new images by combining and mutating user selections

4. 4.

   Sharing: Each creation has a unique URL, allowing users to share both final images and the complete evolutionary lineage that produced them

When Antonios opens PicBreeder, he encounters a random collection of AI-generated images. By selecting his favorites, he guides an artificial evolution process that produces new images similar to his choices. This allows him to both discover the algorithm’s capabilities and share his creative journey with others through the platform’s URL-based sharing system.

As we discussed these areas, we found example after example that were relevant, each having a different set of features and emerging uses. During the seminar, we also created a zine and an experimental prototype¹⁶¹⁶16https://github.com/MasterMilkX/zoras-river to use the patterns in River for exploring Itch.io games. We hope that this will provide a starting point for others to explore this rich design space.

Games make us feel certain ways when we play them. But why? What in a game’s mechanics, or in the relations between the mechanics, makes a game feel the way it feels? Can we draw direct connections between mechanics, combinations of mechanics, and emotions, and formulate them in a language? What happens if we then use that language to make a game intended to feel a certain way? These were the questions we had set out to tackle in the workgroup originally titled Expressive Game Mechanics Building Blocks Language.

While discussing our objectives, it became clear that we were particularly interested in the effects of gameplay on the player’s emotions, as the gameplay is happening. In the context of the Mechanics, Dynamics, and Aesthetics framework, this means we wanted to concern ourselves with the Dynamics of games. This felt particularly compelling because there are already plenty of tools and methodologies around game mechanics, whereas dynamics are more of a grey area, yet also the gateway to aesthetics, meaning here, broadly speaking, the general impression of the player of a game. Besides, the MDA framework is often criticized for being too mechanically focused, but this may be in part because no-one knows precisely what “dynamics” is, and what happens there. Indeed, the Design, Dynamics, Experience model, which attempts to improve on the MDA framework, also features Dynamics, and leaves them as loosely defined as in the first framework. What definition there is tells us that dynamics are made of the interactions between the game and the player. While playing a game, players experience emotions over time, in reaction to what happens in the game, and in acting on the game through inputs, both, in theory, as designed by the game’s designer. To build off of this, to simplify our approach, and to delineate a helpful methodology, we will assume that players experience games in uninterrupted sessions with no other external stimuli.

Since players’ emotions vary over time, it makes sense to draw 2D graphs showing the intensity of an emotion over time as a curve, with different curves for different emotions. These graphs would need to use different scales to provide a complete idea of how the dynamics evolve over the course of a game. We started by deciding on a micro scale, designating the moment-to-moment, like when a player presses a button or is presented with a new information, and a macro scale, representing the duration of the whole game. But we also felt the need for a middleground, and so we decided to also use a meso scale, which designates a short succession of events. For these different scales, we would draw curves for the emotions that seem the most relevant for the game. For example, in Tetris, emotions like anxiety and orderliness might be considered, whereas for a Sonic game, exhilaration and frustration may be more appropriate.

Naturally, playing a game involves more than just two emotions, and so when using the model experimentally to analyse the dynamics of Sonic, we started out with 5 different emotions: control, danger, mastery, frustration, and exhilaration. But when starting by analyzing the micro-scale dynamics of the game, we found that the sense of control followed the same trajectory as exhilaration. And indeed, in Sonic, the two feelings are interlinked, as playing well will usually mean getting a more exhilarating experience. Furthermore, we also found that the senses of danger and mastery did not evolve at all on the moment-to-moment scale. These higher scale notions could in fact be mapped to exhilaration and to the sense of control respectively, only over a wider slice of time. And so we continued our analysis on the meso-scale and macro-scale only considering exhilaration and frustration, and found this to be enough to efficiently pin down the broad dynamics of Sonic.

Additionally, while defining the emotion curves for the meso-scale and the macro-scale, we found it helpful to draw envelopes defining the space in which it would be acceptable for the designers that the player emotions would distance themselves from the emotion curves. For example, a player who is struggling with Sonic’s difficulty might get more frustration, but ideally only to a point, while their exhilaration may drop down to boredom occasionally to frequently. Conversely, a speedrunner might get little frustration, but would get a sustained high level of exhilaration.

Finally, while drawing all these curves, patterns emerged and we could note a variety of simple shapes coming again and again, and combining in ways that felt expressive. So we established a curve library that could be drawn upon.

Having successfully devised and used a graph-based language to express an existing game’s dynamics, we set out to use it in the opposite way, laying out a theoretical game’s dynamics, and then making a game that would meet those dynamics. To use the language, we first needed to come up with two emotions around which the game’s dynamics would revolve. We felt that those two emotions should contradict in an indirect way to produce interesting dynamics. We came up with playfulness and relaxation.

Trying to decide which curves we should try to draw first, it felt simpler to start with the micro curves for both emotions, and then the envelopes for those same curves. These describe the emotional evolutions that we would want to occur in moments of things happening: for example a player taking action, or a player observing an action taking place, or information being revealed. Even though we didn’t yet know what those things would be, we drew two curves for each emotion. We also didn’t shy away from going into the negatives in our graphs, especially for relaxation, on the understanding that this would translate to the opposite of relaxation: excitement.

After this we drew the envelopes for the macro curves, and then the curves themselves. It felt safer to establish envelopes first, and thus define our desired emotional space, before committing to a more precise emotional experience.

Then all that remained was the meso scale. Here we went back to drawing curves first and then envelopes. Doing this part last was very interesting because for the whole thing to make sense, the meso curves had to be built off of the micro curves, but also had to describe progressions that would allow us to build the macro curves off of them. Essentially we were making bigger puzzle pieces with our smaller puzzle pieces, with the constraint that the bigger puzzle pieces had to be usable to build the full puzzle.

With our curves all drawn out, it was finally time to design the actual game that would meet them. To make things easier for ourselves, we decided to make an analog game that could be played by two players with what we had on hand. As it happens, we had some coloured pencils and paper, and the emotions we had chosen at the start – playfulness and relaxation – inspired us to make a game with drawing-based mechanics and breathing-based mechanics.

Trying to match the different curves we had drawn, we progressively wrote up a set of game rules, imagining how the game would play out as we went and filling in zones of uncertainty with new rules or changes of rules. Eventually we played the game for ourselves and made additional refinements as we played.

The resulting game is called Breath Checkers and it is a drawing and breathing game where players take turns drawing in gridcells while always taking inspiration from the last thing the other player drew and respecting a checkered pattern in the distribution of grid cells between the players. Playing the game ourselves and observing other people play it, we felt that Breath Checkers managed to match our curves and envelopes fairly accurately, but we were likely biased, since we had just designed the game with that goal in mind. But, perhaps more importantly, we did manage to design a game starting from its dynamics, and the game itself felt novel and fun.

We’re very happy to report that this workgroup was successful in creating a new language which bridges game design to player emotions. This language does not establish a direct relation between a game mechanic and the emotions it provokes as originally intended, but it does help analyse and think about how a game impacts its players’ emotions, and it also helps laying out strong and workable intentions for creating a game that impacts its players’ emotions in a desired way. Additionally, using the language to create a game from scratch was unexpectedly easy. With at least some game design experience, it is fairly easy to intuit what game mechanics might match certain curves. So perhaps drawing a direct link between a mechanic and the emotion it evokes is not quite as interesting anyway.

Designing a game using the language was very inspiring. Interestingly, it felt like we could have come up with a different game with the same emotion curves and this theoretical other game would have had a similar emotional fingerprint. Designing the emotional fingerprint itself was a fun puzzle and surprisingly intuitive. Starting from the micro, meso or macro curve may result in different decisions with the other curves. The starting choice of the emotions one wants to work with is also critical. Finally, this group may not have had much to do with AI, but we believe it did open up possibilities to explore new design space by combining this new language and AI. For example a game prompt generator could use this language, or possibly a new playtesting workflow could be established where players might record their own emotional evolution and an AI tool might do the work or mapping their reported evolution to the correct micro, meso and macro curves. Either way, this language is an exciting new tool for making games.

Our working group began with a discussion around potential definitions for design intent. We discussed many definitions, including intent as a realization of a higher level goal, intent as a hierarchical, tree-like structure, and intent as simply “just messing around and finding out.” In the end, we settled on a couple of core analogies which helped us to discuss and define intent for the purposes of our pilot study. We consider intent to be an unknown (even to the creator) “guiding force” which drags a designer towards their goal like the pull of a magnetic field. We discussed in depth the “dark matter” of creativity, the off-task activities which actively contribute to the creative process, and how it is closely related to the unknowable true intent we wanted to get closer to measuring.

In order to get closer to measuring a notion of true intent, we came up with two potential avenues of measurement. The first is the discernment of intention through interaction directly. This would entail the design of a system intended to elicit intent, then change the underlying system based on a modeling of this intent gradually over time. The second was the discernment of intention through observation. In particular, this entailed a combination of observation and semi-structured, post-hoc interviews with either individuals or members of a group working on a creative project. The hope is that through a combination of both observation, think-alouds, and post-hoc clarification, we could somehow piece together an accurate portrait of a group member’s intention behind their creative decisions. While the first approach seemed promising to the group members, we decided that due to time constraints we would settle on the second for the remainder of the day.

For our pilot study, we decided to embed ourselves (with permission) into another group for the afternoon. In particular, we chose to collaborate with the New Frontiers in Tamagochi group, as they were just beginning multiple creative projects at the start of the afternoon when we joined. We split into two subgroups: one observing the Dagochi group creating a multi-agent reinforcement learning environment, and the other observing the creation of the Rocking with Charisma TTRPG. For more details on the contents of these projects, please see the New Frontiers in Tamagochi section.

We observed each of these groups for roughly 90 minutes through their creative processes, then proceeded to conduct semi-structured interviews with each group member to ask follow-up questions about the reasoning behind certain decisions. After this interview process, our group re-convened to discuss our findings, and determine if the groups shared any characteristics.

The major finding of our analysis was that it is very difficult to intuit intention from just observation alone. In fact, it could be argued that we learned more about creative group dynamics than about the ability to discern any notion of intention behind each group member’s actions. In particular, we identified three major takeaways from our observations of the two groups.

The first is that aspects of each member’s initial intent were hidden to other group members. While group members each came into the project hoping to achieve something specific from the afternoon of creative work, those intentions were not necessarily communicated or shared among the entire group. For example, one group member who was particularly technically focused had a technically focused retelling, which matched their initial intent. The second is that ideas from group members tend to recombine in different, unexpected ways. For example, different mechanics in the Dagochi project such as breeding and killing emerged from group members’ preconceived notion of which mechanics were “obvious” given the multi-agent nature of the environment. The third is that chronology becomes fuzzy and unreliable throughout narrative recollection of events. This was very apparent in the Dagochi project, where each group member gave a different point in time regarding the inception of certain mechanics.

We believe there is still a lot of work to be done toward understanding, interpreting, and measuring intent. While this working group represents a very small step towards that understanding, we believe this problem is increasing relevant towards the design and analysis of co-creative systems and the co-creative process.

Expressive range analysis in its usual form involves the generation of a very large number of output artifacts from a single generative pipeline; the characterization of each generated artifact in terms of a set of domain-specific, computationally assessable metrics; and the visualization of the distribution of generated artifacts as a set of two-dimensional heatmaps, with each heatmap showing the distribution of generated artifacts in terms of a particular metric pair. The example output of a typical ERA process can be seen in Figure 21. Several extensions of ERA have also been proposed, for instance to support analysis of interaction dynamics in PCG-based mixed-initiative co-creation [11] and to improve the utility of the generator fingerprints captured by ERA in various ways [17].

Despite ERA’s broad uptake within PCG research, the question of how to define or select appropriate metrics for a particular class of artifacts remains an open problem [18]. Additionally, although some attempts have been made to integrate ERA directly into graphical game creation tools like Unity [6], few existing interfaces allow users to employ ERA without reimplementing all of the necessary components themselves.

We envision several potential user archetypes that might benefit from application of ERA:

• $\mathrm{■}$

  The computational author, who aims to craft a generative pipeline that achieves an envisioned output distribution or aesthetic outcome.

• $\mathrm{■}$

  The analytical researcher, who aims to better understand the expressive range of other people’s generators (e.g., to assess biases in large pretrained generative AI models).

• $\mathrm{■}$

  The educator, who seeks to broaden public understanding of generative pipelines as opinionated and probabilistic rather than unbiased and oracular.

• $\mathrm{■}$

  The exploratory tool user, who plays with generative pipelines in an exploratory or process-focused way but is not directly motivated by the desire to achieve a comprehensive understanding of a particular possibility space.

• $\mathrm{■}$

  The outcome-attached tool user, who attempts to use generative pipelines to achieve specific types of desired output but is only instrumentally interested in what the pipeline as a whole is capable of producing.

The boundaries between our envisioned user archetypes are not firmly fixed: people may gradually slide from one category to the next as their interests and needs evolve. For instance, an outcome-attached tool user may become more interested in making tool outputs that stand out from what they’ve generated before; an analytical researcher may try to address weaknesses they’ve previously identified in existing generative pipelines by developing new ones; and a computational author may decide to assert more direct curatorial control by selecting and publishing only a few specific artifacts from their generative pipeline’s full expressive range.

One of the main bottlenecks preventing broader application of ERA is the limited availability of appropriate, computationally assessable metrics that can be used to characterize artifacts in specific creative domains. This has manifested in the past in several important ways:

• $\mathrm{■}$

  Over-indexing in the published literature on narrow sets of metrics defined in prior work (e.g., linearity and leniency for game level generation)

• $\mathrm{■}$

  Non-extension of ERA to new artifact domains, due to the difficulty of coming up with an initial set of domain-specific metrics for a totally novel domain

• $\mathrm{■}$

  Overreliance on metrics that are easy to computationally define, rather than those that capture key aesthetic properties of relevant domains

• $\mathrm{■}$

  Non-application of ERA by potential users other than computer science researchers, due to the difficulty of encoding intuitively salient metrics as procedural code

Notably, many of our envisioned user archetypes will not necessarily have a strong sense of what metrics they’re interested in before interacting with a generative pipeline; some of them may not know how to code; and even those who both know what metrics they’re initially interested in and know how to code may struggle to meaningfully formalize the metrics they care about. How can we support these users?

We believe the answer may take the form of an approachable workbench for conducting expressive range analyses, with built-in support for the definition and iterative revision of “sketchy” example-based metrics, as well as the publication, retrieval, and adaptation of metrics defined by the community of workbench users. Such a workbench might be modeled on Wekinator [8], an approachable toolkit for the example-based definition of simple domain-specific classifiers and other machine learning models for artistic use cases (e.g., novel musical instrument design). Metrics might initially be defined in terms of “general-purpose” embedding or language models (as in, e.g., Luminate [16] or Patchview [4]); refined through the specification of additional examples; and perhaps translated into a more domain-specific ML model or explicit procedural function as the user develops a more specific sense of what they want their metric to capture.

Our working group attempted to apply ERA in several new contexts: to the outputs of a pre-existing textual expansion grammar, with new candidate metrics defined in terms of LLM queries rather than procedural code; to a character generator building on the Dagstyle visual language introduced earlier in the seminar; to a large number of Dungeons & Dragons oneshot scenario concepts generated by the large language model Claude Sonnet 4; and to an automatically generated space of possible playthroughs of the storylet-based interactive narrative Bee [14]. In each case, we encountered new difficulties that might need to be addressed in the extension of ERA.

For Case 1, we wanted to leave the maximum creative freedom to the AI, focusing only on our subjective comments about the game’s playability rather than about the creative decisions. To maximize the end-to-end ideation, we followed a game jam format [7] and generated one theme using an online (non-LLM) theme generator: the resulting theme was “islands”. After this, we relied on Anthropic’s Claude as our LLM of choice for all concept and code generation phases.

Using the generated theme “islands”, we prompted Claude for game ideas for this theme “that will wow the other participants”, which returned 6 game ideas. We then asked Claude to rank these ideas on which “will generate the most buzz”; the response ranked Island Genesis first, which we then used for the rest of the game generation pipeline. The original description of Island Genesis in Claude’s first response for Case 1 was:

A reverse city-builder where you play as a volcanic island that’s slowly sinking. You must strategically grow land masses and guide the last inhabitants to safety before you’re completely submerged. Time pressure with emotional storytelling.

Following this description, we followed the iterative cycle of Fig. 23 to produce a game using first the PICO-8 [9] engine and then the Godot [12] game engine.

Using the PICO-8 engine, the first LLM response already added the very basics of the game (see Fig. 24; top left): a visualization of an island, the people to be saved, and a basic game state display; the island also already slowly sinks. However, cursor interaction did not work and the game was unplayable. Follow-up iterations involve a human playing the game and producing feedback, with Claude listing possible improvements and then picking the (LLM-perceived) best one to work on. Improvements over ten iterations, lasting around 2 hours, resulted in visual polish (e.g. particle effects, progress bars) and game design additions (e.g. better villager pathfinding, slowly renewing materials used for growing land). The resulting game is playable (see Fig. 24; top right) and, at times, even engaging. The visuals are polished enough for a PICO-8 game.

Following the relative success of the PICO-8 Island Genesis, we tried replicating the process (with the same high-level description) with the Godot [12] game engine, which is more complex. Given the same time and effort, the resulting game (see Fig. 24; bottom) is much worse than the PICO-8 game. Likely reasons include the more complex visuals (high-resolution textures) and complex file structures (compared to the single script used in PICO-8). The former increases the expectation for visual quality and increases the challenge of image generation, while the latter poses challenges for the LLM to process (given limited context length) and to create responses for (which takes far more time than for PICO-8). This suggests that a game with a much larger scope – regardless if that scope comes from more complex software or more complex game mechanics – will result in worse results using only GenAI planning and programming.

While the other two cases explored the balance of creative decisions between LLM and human co-creators, Case 2 explores how this game development process works when neither human nor LLM have creative agency. All creative decisions are already taken in advance, by someone else: in our case, the creator of an existing game. Another benefit of this approach is that we already have available the description, screenshots, and access to the original game to play and assess intended gameplay when giving feedback to the LLM. This is unlike the other two cases where, to use the creative journey as a metaphor, neither LLM nor human know the destination (instead, they explore together) and it is unclear what constitutes the end of the journey.

Given the success of Claude at generating PICO-8 games in Case 1 (see Section 3.8.1), we browsed recent high-ranking PICO-8 games on itch.io and chose the game SuperHotRoids¹⁸¹⁸18https://ghettobastler.itch.io/superhotroids to replicate. Among our selection criteria, we considered that the game’s recent release would make it less likely that the LLM is trained on information about the actual game. SuperHotRoids mixes up the mechanics of Superhot¹⁹¹⁹19https://superhotgame.com/ and Asteroids²⁰²⁰20https://en.wikipedia.org/wiki/Asteroids_(video_game): a spaceship attempts to shoot down asteroids while time slows when the player does not interact with the game’s controls. We will use the title SuperHotRoids to refer to our own GenAI-made game in Case 2, since we try to replicate it in full.

Given an initial description of the game mechanics and screenshots from the original game, we prompted OpenAI’s GPT-4o to reproduce the game. The returned code was entered into PICO-8, and feedback was given to the LLM. Such feedback contained information on missing mechanics, misrepresented graphics, balancing constraints, or errors in the returned code. Over the course of 30 queries, the basic game loop, as well as a main menu and a high-score screen, had been replicated. We show snapshots of the process in Fig. 25. The overall process took about 3 hours. While the final product looks similar to the original game, it still needs polish in balancing and mechanics.

This case raises several ethical considerations regarding the reproduction of an existing game. We doubt that the LLM had prior access to the SuperHotRoids game code; the reproduction was based solely on textual descriptions and screenshots provided by us. However, the resulting game is very much a derivative of the original. We therefore refrain from publishing the resulting game so as not to infringe on the game developers’ copyright of SuperHotRoids. While this experiment demonstrates technical feasibility, similar methods could be misused to clone or imitate original works without consent, thus undermining the value of human creative labor.

For Case 3, we followed a more traditional pipeline for co-creative tools: a human creator taking the initiative and the AI following [10]. We consider Case 3 a closer approximation of how GenAI will be used by indie developers, novices and students [4]. Specifically, the game was produced with entirely human game design decisions, and entirely AI-authored code. Using this process, we created a simple camera-based game (named Webcam Island Builder by the human author) connected to the “islands” theme of Case 1 (see Section 3.8.1). The LLM of choice was Google’s Gemini 2.5 Flash via Cursor, and the game engine was Pygame (with Pymunk for physics).

The game concept revolves around webcam tracking: real-time footage of the player is used to physically interact with the game world. The player uses their hands, which act as rigid bodies in the game’s physics, to guide randomly selected shapes onto a moving platform before time runs out. At the end, the player sees the “island” they created (see Fig. 26). The application is more of a toy, with no scoring or losing conditions.

This high-level concept was decided before engaging at all with GenAI systems. While first prompts were exploratory (e.g. to list appropriate libraries for game physics and webcam tracking), subsequent prompts were much more specific (e.g. “implement a timer that ends the game after 60 seconds”). A point was made to not allow creative decisions or design changes from the LLM. All prompts were designed to limit the LLMs’ contributions to purely implementing clearly outlined functions.

The game was functional within an hour of this process, and only minor adjustments were needed after this. Overall, the game (while simple in terms of game logic) does what the designer expected and thus satisfies the – human – brief. Micro-adjustments were made after testing the game, on a minor scale (e.g. move speed of platforms), but they always followed the human designer’s intuition and preferences.

Abiding by the intents of this working group, four games were created within a day²¹²¹21Technically, each game took a couple of hours to make., all with some degree of playability. We explored how three different LLMs handle game development tasks, and used three different game engines to make the games.

In terms of technical feasibility, PICO-8 seemed better suited for the LLM of choice (Claude) to design for, compared to Godot. We hypothesize on the reasons for this disparity in Section 3.8.1. More broadly, however, we can argue that lower-fidelity games with limited assets (graphics, audio, logic, interface, narrative) are easier for GenAI to produce. Such types of games are most often generated by a single indie developer over the course of a couple of days. This could suggest that GenAI can assist novices (who do not have a team or technical skills) to make a game faster, during a game jam. On the other hand, such indie developers are most vulnerable to GenAI misuse as “simple” games such as SuperHotRoids (see Section 3.8.2) can be easily reproduced causing Intellectual Property theft.

In terms of perceived creator agency, it was observed that engaging even superficially with the work-in-progress game and suggesting feedback to the LLM did increase the sense of ownership on the part of the human co-creator. However, we hypothesize that this sense of ownership is not how a game developer feels about their game; rather, it’s closer to how a Quality Assurance tester (or fan) whose feedback has been heard feels about a product that is ultimately not theirs. Ethical issues of creativity, authorship [13], and intellectual property (especially regarding Case 2) remain critical in this new era of GenAI. Moreover, it was surprising to find out that games made in a day seemed to us²²²²22We chose purposefully game development tools in which we were unskilled in. to be “good enough”. It is as exciting as it is worrying to speculate on what “good enough” will be perceived as in a year or a decade from now, and whether this shift will be due to a leap in Artificial Intelligence or due to a stagnation in human skill, appreciation and imagination [2].

As Generative AI has surged in both popularity and cultural relevance, the various flaws of GenAI systems has also been dragged into the limelight. While various terms can describe these failures of generative systems, we adopt well known term from the gaming community, “Jank”, to describe a certain subclass of erroneous outputs. In our working group, we first seek to examine what makes certain outputs entertaining, and then explore potential ways we can leverage these typically discarded janky creations in order to create something entertaining.

In the midst of widespread adoption of AI-generated content, as well as culutral opposition to “AI slop”, there arises a form of nostalgia for the janky outputs of early image generation models. Legendary musician Brian Eno once said “Whatever you now find weird, ugly, uncomfortable and nasty about a new medium will surely become its signature. CD distortion, the jitteriness of digital video, the crap sound of 8-bit – all of these will be cherished and emulated as soon as they can be avoided”[1].

Our study of Jank serves to both categorize the emerging medium of “good Jank”, as well as an attempt at intentionally leveraging it to create a game-like experience where Jank serves as the core mechanic.

Janky outputs exist in nearly every modality that Generative AI is applied to: text, image, video, etc. Funny examples are often widely spread on social media. For example, Apple’s AI text summary feature made headlines due to it’s humerous misinterpretations of text messages. For example, one summary reads “Multiple emergencies including house break-in, fire, and losing a Fornite match.”

Google’s AI integration with search has also produced notable and widely-shared fails. One search for “cheese won’t stick to pizza” results in Google’s LLM assistant suggesting the user mix some Elmer’s glue into their cheese to add tackiness.

Jank is not exclusive to generative AI, and is a well known concept in video games, where it typically refers to frequently buggy game systems. Some games lean into janky game systems for comedic effect. A notable example is Goat Simulator, published in 2014 by Coffee Stain Studios. Described as a “chaotic sandbox”, the buggy physics engine is the central component of the game loop, with players being encouraged to epxloid physics glitches to accomplish goals.

AI Jank comes in as many forms as there are modalities for Generative AI, and we faced difficulty trying to assign a single canonical definition to the phenomenon. Our working group focused on identifying key properties of a generated output that Jank must have.

As a basis, a janky output is a (somehow) incorrect output of a system. The challenge comes in differentiating Jank from a typical error that may arise from insufficient training, lack of generalization, or a misconfigured system.

We identified five properties that help distinguish Jank from typical errors:

• $\mathrm{■}$

  Unintended: The viewer has some sense of what the intended, non-janky output of the system would have been like.

• $\mathrm{■}$

  Unreproducible: The system doesn’t always produce Jank, it might do something like that again.

• $\mathrm{■}$

  Inhuman: It doesn’t feel like you, as a human, could figure out how to practically reproduce the behavior even if it was your intention.

• $\mathrm{■}$

  In-group specificity: It is plausible that general audiences would not notice what’s going wrong with the output.

• $\mathrm{■}$

  Provocative: The output is remarkable in some way, and evokes some emotional response in the viewer.

These properties aim to distinguish the type of Jank that may be fun and potentially useful, rather than simple failures of a generative system. When combining all of these features, we find that Jank first requires a capable and understandable generative model, where janky outputs are a subversion of the expected quality and subject matter of the typical output.

Because the janky behavior is unreproducible, you often experience it through a reliably captured recording of the original behavior. If the original intent is not obvious, people may not perceive it as a satisfactory Jank. Once we find ways to humanly reproduce it on purpose, even the original example of the Jank becomes less remarkable.

We attempted to further explore how Jank can be leveraged for entertainment, creating a humorous look at the failures of text-to-image generation.

We first captured real world images of the rooms at Dagstuhl, as well as an image of the floorplan. Our goal is to create an alternate “Jank-dimension” version of the space we occupied.

First, we utilize the “recursive ChatGPT image” method to introduce spelling errors and layour errors in the image of the floorplan. After 10 iterations, we obtained some interesting mis-spellings of existing rooms to serve as the map for our exploration game.

Then, we tried to match the hallucinated room titles to their original rooms, selecting a picture to use as the basis for each room. We then used Midjourney’s image editing feature to generate Jank variations of each image based on the room name.

We chose Midjourney as our image model because of the optional “chaos” parameter they expose in the interface, a scalar value that can be set when generating or editing an image. This parameter “lets you add more variety to the image results you get from each prompt”, though they warn “higher values mean the images can be quite different and may not stick as closely to your prompt, giving you unpredictable results”. We find that this approximately serves as a Jank parameter, with higher values often resulting in bizarre and hilarious results.

For each room, we masked out certain regions of the source image to replace using the model, and provided the text prompt “A group of researchers at the New Frontiers in AI for Game Design seminar at Schloss Dagstuhl. A big sign on the wall says “<room name>””. We set the chaos parameter to 100 each time, and continued generation until we got an image met our Provocative criteria.

We have identified five key properties that distinguish entertaining “jank” from simple errors in generative AI: unintended, unreproducible, inhuman, in-group specific, and provocative outputs. Our experimental project – creating a jank-dimension Dagstuhl using Midjourney’s chaos parameter – demonstrates that these typically discarded outputs can be leveraged as a creative resource. Rather than viewing jank as failure, we propose embracing it as an emerging aesthetic that, as Eno predicted, may become a cherished signature of early generative AI. Future work could explore tools specifically designed to produce controlled jank or investigate how audiences’ perception of these artifacts evolves as AI systems mature.

Our initial motivation for this working group was to explore how we could recreate the process of Automated Game Design without involving any computers. Many of us were motivated by a sense of disillusionment with the trajectory of games AI, and analogue prototyping offered a way to foster surprise, emergence, and playfulness outside of computational constraints. Our guiding reference was Blaseball: a cryptic simulation video game which left a lot of room for audience participation and, like an improvised performance, constantly felt like it could truly go anywhere. Some of the reasons why Blaseball had to be brought to an end were the increasing logistical and technical costs of maintaining this setup at that scale. The question we set to investigate was: What can we do in that design space, at a local scale and with little to no computation?

Not all members of the session were familiar with Blaseball and similar community-driven games [1]. As such, we began by overviewing the area to ensure all members of the discussion were on the same page. Due in no small part to the makeup of the group, the conversation quickly shifted to automated game design and how one could accomplish this in an analogue (i.e., non-digital) fashion.

We quickly proposed an initial version with very simple rules, namely:

• $\mathrm{■}$

  Assumptions: board, pieces, turns

• $\mathrm{■}$

  Step 0: Lines, veils, wishes for game design

• $\mathrm{■}$

  Step 1: Come up with number of players collaboratively

• $\mathrm{■}$

  Step 2: Assign 1+ to each player:

  • –

    Board gen rules (give 1 example board)

  • –

    Piece gen rules (give 1 example piece)

  • –

    Piece defining rules (give n example teams)

  • –

    Piece placement on board rules (give 1 example board with pieces)

• $\mathrm{■}$

  Step 3: Generating your game.

• $\mathrm{■}$

  Step 4: Assign 1+ to each remaining player:

  • –

    Win conditions

  • –

    Turn start

  • –

    Turn end

  • –

    Arbitration

We nicknamed this “Four G’s” or “Four Gees” as it was a Game Generator Generator Game. The idea was that some parts of the game would happen in secret (Step 2) but each person would give some information (a specific output from their generative rules) to allow for cohesion. We played an initial narrative-driven chess-like game that we collaboratively created and then reflected on this process.

After playing the chess-like game, we reflected on the experience, with each member having different takeaways. Some members wanted more iterations on the design, others felt that iteration was a trap. Some wanted more simplicity, others wanted more chaos. As such, we split up and each member created their own variants independently.

We lack the space to fully overview all of the seven game creation variants. Many were simple variations on the initial game described above, such as adding more explicit instructions [2] naming every game component or picking an explicit theme.

We focus our attention on three variants that were more strenuously tested at Dagstuhl, Michael Cook’s “Blank Page Boogie-Woogie” [4], Claus Aranha’s “Variation 5” [3] and Rémy Devaux’s unnamed variant.

For “Blank Page Boogie-Woogie” the aim was to develop a process that felt very easy to follow, almost like a folk game that you could describe to someone verbally and pass on that way too. The game required the use of pens and paper, along with the optional inclusion of other objects. The game included an explicit ‘fix the design’ phase in order to lessen the concerns of producing something playable initially. Based on the playtesting this seemed very effective.

“Variation 5” was more explicitly inspired by the author’s prior experience with Role Playing games and Board Games. Thus it ended up with explicit turn taking rules, and explicit separation of responsibility between the players, to try to make sure that all players have a fair chance to contribute to the design, even if they are unfamiliar with this kind of exercise. It also included a more abstract rule about “naming” the rules previously described, both to add a touch of whimsy to the process, as well as to allow a chance to review the final design.

In Rémy’s variant, all assumptions in the game were chosen collaboratively, with rules designed simultaneously due to card draws. Finally at the end, the game permitted two changes to the design as an explicit reflection.

After presenting all seven games to one another, we selected the three variants above to playtest, using Variation 5 twice and the others once to create a total of four games. With Variation 5 we produced “Fruits”, a physical game about getting a piece of fruit as high as possible and “Heaven or Hell”, a game about playing out Christian theology. With Blank Page Boogie-Woogie we created an unnamed game about rolling dice and drawing ghosts. With Rémy’s variant we created an analogue game simulating animals escaped from a zoo.

We found a number of interesting observations when discussing the process of designing the game generators, creating the games, and playing the games. First was the importance of differentiating what we meant in terms of the different roles that people took on in these experiences, whether we meant a designer of a generator, a designer of a game, or a player of a game. We opted to use the term “performer” in several instances due to the ambiguity of “player” in this context.

Second, across these game variations we had a spectrum of information sharing between participants in the game generation process. When participants did not have access to the other designer’s rules, they often trended towards making “game agnostic” rules that could have functioned in any game. In comparison, when rule creation was public, individuals could more easily build on top of one another’s design.

Third, an effect we dubbed the “Ouija Board” effect during the session, but is more closely related to the notion of sensemaking from psychology [5]. In this case we repeatedly found ourselves, apparently by happenstance, having designed a game that had interesting things going on in it, despite the fact that the components of that game were designed independently. We called this the “Ouija Board” effect as it felt as though we had subconsciously manipulated the game together to produce a coherent outcome.

In reflection on this session we found that there was definitely something compelling about the process of designing these analogue game generators, designing the specific games collaboratively and performing them in front of an audience. We feel that there are likely connections here to improv, informal game design, dadaist games such as exquisite corpse and folk games. We believe there is potential in encouraging the same group to continue iterating on the same generator over multiple sessions, allowing them to build their own meta-narrative and leaving room for a communal emergent narrative. We think these game generators may also be useful vectors for studying game design processes, and hope that future researchers can more fully investigate this possibility.

During the first part of the morning, the working group focused on surveying the different types of gameplay that can be considered playfully transgressive. This initial mapping produced an expansive list that included speedrunning, ROM hacking, playground rules, modding, game corruptions, the use of cheat codes, and save scumming. Examining these diverse playstyles highlighted the many ways in which players depart from the conventional play patterns anticipated by a game’s design. This discussion immediately raised a critical question: what, precisely, is being subverted or transgressed through these practices? We identified that beyond the formal rules of a game, certain playstyles also transgress its coded affordances, as well as the legal, moral, and even political frameworks that games may inherently embed. Developing this landscape offered a clearer view of the vast potential for new systems and methods to support such unconventional modes of play.

We developed a theoretical framework for defining playful transgressions by identifying three key dimensions: Players, Designers, and the Computational Medium. Within this framework, we defined normal play as activity that falls within the intended or allowed range across all three dimensions. Considering only the Player and Designer dimensions, there exist experiences that are acceptable and desirable to both but constrained by technical limitations, such as bandwidth or storage; these are not considered transgressive play. In contrast, when focusing on the Player and Medium dimensions while excluding the Designer, leveraging the medium to create exo-designed experiences, such as mods, hacks, or house rules, constitutes transgressive play. Finally, considering the Designer and Medium dimensions without accounting for the Player highlights practices that manipulate or restrict the player, such as inserting ads or extracting private data. We also stretched the framework by looking at each dimension on its own. To make these ideas more tangible, we created a zine that illustrated the theory and shared it with seminar attendees.

We approached the space of playful transgressions from a game designer’s perspective and mapped out ways in which designers could intentionally structure their games and systems to support versatile playstyles. From this exploration, we identified five key considerations and highlighted examples of systems that embody each principle: choice of platform (e.g., Skyrim on PC vs. Xbox), modular and data-driven system design (e.g., Caves of Qud), explicit mod hooks (e.g., Minecraft), documenting the design process (e.g., Balatro), and observing, learning from, and supporting the community (e.g., Stardew Valley). To disseminate these ideas, we designed a zine that encapsulated these concepts and distributed it to the attendees of the remainder of the seminar at the conclusion of the workshop.

Game modding and ROM hacking present themselves as spaces where players require substantial programming expertise, as well as significant time or resources to outsource technical work. These barriers restrict access to the creative potential of modifying and reimagining games. In our discussions, we drew inspiration from two important sources: the Game Genie [3] and Blockly [4] (Figure 31). The Game Genie [3], a hardware device popular in the 1990s, exemplified how cheat codes and memory manipulation could offer everyday players accessible ways to alter a game’s behavior without requiring direct interaction with its source code. It made the act of “rewriting” a game approachable, playful, and within reach of a broad audience. Blockly [4], in contrast, demonstrates the power of visual, block-based programming to lower the threshold of entry into computational thinking. Its drag-and-drop interface to construct logic and behavior in intuitive, modular ways. Additionally, many ROMs are thoroughly mapped by fan communities (for example, see [5]), whose documentation makes hidden game structures easier to interpret. These mappings could be valuable for creating accessible tools, since they transform opaque technical details into interpretable knowledge. By combining the accessible nature of Game Genie, the visual programming paradigms of Blockly, and the ROM mapping provided by the community, this UI (Figure 33) design and the potential system powering it could make modding approachable to a wider range of players.

This working group highlights the considerable potential for creating more accessible systems that enable a wide range of playful and transgressive gameplay. Future work could involve developing a full prototype of the GUI system for ROM hacking in a single game, or designing an AI-powered tool capable of supporting multiple games and playstyles. Beyond tool creation, there remains substantial research to be done in understanding how players engage in these unconventional forms of play and the rich communities that emerge around them, such as those on Twitch and other social platforms. Exploring these communities and practices more deeply will provide valuable insights into the ways games can be expanded and experienced across a variety of playstyles.

There has been limited explicit academic engagement with Khor’s concept of keepsake games. One clear outlier to this is a chapter in The Routledge Handbook of Role-Playing Game Studies within the context of text-based role-playing games [2]. Though the term “keepsake game” was coined recently, arguably games that could fall into this category have a longer history. A 1997 paper published in the Proceedings of the International Conference on Cognitive Technology [3], for example, discusses digital augmentation of “keepsake objects.” Sullivan et al’s Loominary captured narrative choices in a digital Twine game by having players use a loom as a controller, thus producing a physical artefact as part of the gameplay process [4].

Loominary’s hybrid digital/analogue interface was a key inspiration for the session. The first author was interested in exploring the possibility space of such hybrid keepsake games, especially in conjunction with procedural systems. Procedural content generation (hereafter PCG) is, broadly speaking, the generation of content algorithmically. Given that keepsake games often include human-authored algorithms for play through creative prompts, it was theorised that incorporating PCG systems would be complementary. Furthermore, we were interested in exploring how the uncanny poetics and texture of PCG [5] might contribute to keepsake game design.

The first author chose the “no generative AI content” category for this working group.

During the first part of the session, we discussed several different aspects of keepsake game design as a group. This discussion is summarised in the three subsections below.

• $\mathrm{■}$

  Keepsake Typology. In terms of different types of keepsake, we came up with the most examples under the sub-category of “crafted items.” Crafted items are material agnostic, the emphasis is more on the process of physically creating a piece, such as paper weaving and even edible crafts. Crafted keepsakes are complimentary to the idea of keepsakes as a gift, which would be broadly applicable to other personalised keepsakes, such as postcards. We also discussed digital keepsakes, such as character creators and USB drives.

• $\mathrm{■}$

  Complementary Procedural Systems. We discussed both digital and analogue procedural systems that could be incorporated into keepsake games. In terms of the former, existing digital games with PCG such as Minecraft were suggested. Another system was the Tracery text generation tool. We also had suggestions for analogue PCG, such as dice rolls, Tarot cards and the cut-up method.

• $\mathrm{■}$

  Design Constraints. Potential design constraints for keepsake games fell mainly under the following areas; theme, material, duration, number of players, location and familiarity. Familiarity was particularly applicable in terms of the aforementioned crafting techniques, as potential players may need to learn a new skill as part of crafting a keepsake. In addition, players might need access to specific craft materials. Though we did not extensively explore this in our discussion, it is important to point out that accessibility is thus a key concern in terms of keepsake design.

In the second part of the session, we split into four subgroups to rapidly prototype keepsake games. Each of these prototypes, and the design considerations that went into them, are summarised below.

A Sending²⁴²⁴24https://florencesmithnicholls.itch.io/a-sending is a postcard keepsake game (the name riffs on Shing Yin Khor’s keepsake game A Mending²⁵²⁵25https://sawdustbear.itch.io/a-mending). Players use an online village generator tool to create the map of a fictional village, are instructed to design a stamp based on it, and write an accompanying postcard with details of their trip to this fantasy place.

A-Zine (pronounced “A-to-Zine”) is a collection of 26 pocket zines. Each zine has a front-page with a fixed title, an empty square and a field to write the author’s name. Each zine is empty, containing only two words written in red, in different pages. Red words are hyperlinks leading to the zine with that same title. Readers are invited to pick the zine they like, read its short story and follow hyperlinks to other zines. If the zine they opened is empty, they are invited to fill it using its title as an inspiration. They’re invited to include the fixed red words within its content – as part of a text, for example.

Each zine has a title starting with a different letter of the English alphabet. The first one, titled Atlas, explains how to read and fill the zines.

Color Collector is a collage and connection game played with a smartphone. In the beginning, each participant is prompted to photograph an object that has a color they like. This color is extracted from the image and becomes their starter color. From then on, participants can either:

After the event, each participant has created their very own collage of little moments and hopefully has found new friends or connections during the color mixing process.

Postcards for Dagstuhl is a physical game dedicated to the seminars that are held at Dagstuhl, although it could easily be adapted for other gathering spaces. The output of the game is a hand-decorated postcard which reflects something about the player and their time at Dagstuhl. Inspired by instructional art, during the game the player is given three sets of prompts to choose from with instructions on how to decorate their postcard. The first table has prompts which reflect the player’s own research or personality, the second table has prompts about the player’s experience at Dagstuhl, and the final table has prompts about who to give the postcard to when they are done, if they don’t choose to keep it for themselves.

Four prototype keepsake games were made as part of this working group. While the initial prompt was to create physical keepsakes games that used digital PCG systems in some way, many of the prototypes ended up exploring forms of analogue PCG [6]. Overall, there was a concern for accessibility in terms of both artistic and gaming experience and availability of specific digital platforms. We believe there is great potential for further exploring and experimenting with PCG keepsake games, especially in terms of creating bespoke generators for this purpose.

Visual systems are a defined set of rules for creating consistent assets, layouts and designs. They are often used by companies, brands and products to be easily recognized and remembered in the minds of consumers. Visual systems can be thought of as individual components, which are arranged into assemblies, which are finally placed into applications.

Benefits of visual systems include their ease of use, their flexibility to scale across media and audiences, and a tendency for their constraints to cultivate creativity. In a time when Gen AI disrupts the status quo in the pursuit of high fidelity, simple limited systems can also provide a space for all to experiment.

In addition to brand design, visual systems can be found in many places, such as national flags, the pixel art of classic video games, tangrams, Nintendo Miis and even the brickwork in Victorian townhouses. Dr. Martin Lorenz advocates for a move away from logos and towards flexible visual systems that can be easily scaled across different audiences and in different media.

In preparation for the seminar, the author was inspired by the visual language of DROPS²⁷²⁷27https://drops.dagstuhl.de/ (The Dagstuhl Research Online Publication Server), which is optimized for text and icons with a pixel and line drawing style. A limited colour palette of four colours allows for clear contrast between white, grey and yellow, with blue for hyperlinks. Could this be extended to allow for a wider expressive range, to create a simple and accessible visual system for the seminar attendees to use and further develop during the week?

Early exploration pushed the limits of the DROPS style, and endeavoured to define the shapes, colours and grid rules that form the foundation of Dagstyle.

Shapes – The allowable shapes were expanded from pixels to include squares, circles, triangles and quadrants.

Colours – The allowable colours were expanded from four to six; White, Grey, Yellow, Blue, Pink and Green. While the four colour map theorem states that only four colours are needed to colour regions so that no adjacent regions share the same colour, the addition of Pink and Green introduce new possibilities to represent nature and more colourful ideas.

Grid – All Dagstyleimages should be limited to placement on 8x8 or 16x16 grids, with the option for layering and shapes to be rotated by 90 degree increments. Assemblies can also be used as Components, allowing for fractal details.

After defining these simple rules, it was then possible to play with the system to create patterns, fonts, flags and 100 interesting things.

The Dagstyle visual system consisted of the following components, which were provided to seminar attendees as inspiration and use during the seminar.

Dagstamp – A 2D Building system of icons and assets, that could be used in presentations and prototypes. Assembly sheets for hundreds of individual assets were provided, in addition to PNG and SVG images.

Dagslide – A Google Slides presentation template that could be used for sharing the results of workgroups throughout the week.

Dagscript – An OpenType font and writing system.

Dagzine – A self-publication zine template to introduce zine making.

Daggame – An invitation was given to seminar attendees to consider how the Dagstyle visual system and principles could be extended into an interactive video game format.

With the hopes of providing a fun icebreaker activity, assets from Dagstamp and Dagscript were curated into an array of name tag building components. When supplemented by scissors, markers, glue and thermal photo printers, these symbol symbols were transformed by seminar attendees into a dazzling array of colourful name badges. The author was thrilled by the collective creativity and how well everyone worked together, many of whom were meeting each other and attending this seminar for the first time.

The Dagstyle visual system was well received, and served its purpose of inspiring a playful prototyping approach during the seminar. It was used, extended and subverted in numerous instances, and most notably applied as a prototype for a visual programming language in Visual Representation for Video Game Description Language. The author invites any future Dagstuhl Seminar or reader to use it in their own work. Have fun and make it your own!