Tracery is a tool for generating text from a grammar. This is a project near and dear to my heart, because I did the same thing for one of my first Java applets. Sadly, "The Technobabble Generator: a Recursive Random Grammar Unparser" has been lost to the mists of time, and not even the Internet Archive can attest to its existence. To me, this is sort of an object lesson in how much the world has changed. In 1996 we didn't have Github or even much of a Javascript ecosystem, and those are what has allowed Tracery to go from a personal project to a reusable facility.

Tracery's language is JSON-based and pretty easy to use. Kate pointed out that SVG is just text, and has some very cool procedurally-generated dresses and spaceships. JSON is just text, so people have even created tracery-generating tracery schemas. A Twitter bot hosting service, CheapBotsDoneQuick, uses tracery. And it's been ported to other languages from its original Javascript implementation. I put together "Your Next Roguelike" using this hosted service: https://twitter.com/NextRoguelike

The larger point she made is that when each piece of content requires its own code, STOP AND THINK first. What can you do instead to turn code into data, or use a tool? "Don't whittle your own screws". An example she gave was how, in the Sims, furniture actions and effects were all controlled by attributes which made it very easy to launch expansions.

(Did I mention Kate did the planets in Spore? She's gone back to school for her PhD.)

Examples of finding artificial intelligence "parts" out in the world: * Finite State Machines: build an interpreter, not a FSM in code * Decision Trees: once we have the tree as a data object separate from its implementation, it can be manipulated on its own. Examples: log which paths are being taken, evolve/modify/apply machine learning to the tree * Constraint Sets/Solvers: e.g., Clingo (https://github.com/potassco/clingo) can be used once you cast your problem in this form. see "A Map Generation Speedrun with Answer Set Programming" https://eis-blog.soe.ucsc.edu/2011/10/map-generation-speedrun/ * Visualization tools. She mentioned an interesting effort in visualizing game logic which can be found here: http://ice-bound.com/news/visualizing-the-combinatorial/ While I got a pitch and demo from the author of "The Ice-Bound Concordat" later in the day, it didn't really click with me.

"Markov By Candelight" by Caves of Qud author Jason Grinblat. He described Markov text generators (like those behind Erowid Recruiter https://twitter.com/erowidrecruiter) and wanted to find a way to use them to generate in-game book content for his game, which actually tied back into the plot.

To do this sort of thing well you need to curate your training corpus well. Fortunately, Caves of Qud already has a lot of text in terms of in-game books, NPC dialogue, help files, quest text, object descriptions--- totaling about 45,000 words. So he mixed that with a couple of 19th century physics texts available on Project Gutenberg, about another 45K words. That produced a mix he was happy with, definitely game-relevant but also coming across like there had been centuries of linguistic drift, data corruption, and unknown referents.

Titles are hard, because they have extra structure. After trying a "mad lib" style templating approach he went back to Markov generation but chopped off undesirable words (about 30 of them.) Then he added some extra variation by sometimes including an author's or editor's note, appending "volume 1" to the title, making the book extra-long, etc. These were meant to combat the feeling after a while that all the Markov text looks "just about the same."

How to turn this into a game mechanic? He looked for common prefixes which turned out to be combinations like "in the", "of the", "to the". Then he can bury a secret in the books by making it one of the generated text options that follows these common prefixes (but as an indivisible unit.) So a book might have "... of the {something cool} which I hid six miles east of {place}." The frequency can be tuned; he aimed for about one such secret in every four books.

How Brogue Tells Stories by Brian Walker. What makes a situation in a game exciting? And how to you generate those experiences? The biggest reason roguelikes get stale is because it's not longer cognitively interesting to optimize (because the crowdsourced guide tells you how to do so.) So how do you get the most bang from new content? Classes probably aren't balanced, and there is probably also a dominant build within each class, so probably enhancing the environment is a better payoff.

Brogue does "improvised item-based advancement" where your character gets better because of equipment, rather than experience. But you're essentially on a budget of reusable "skill items" (weapons, staves, charms) and disposable "skill point items" (scrolls of enchantment.) You only see a subset of the available skills per game, so you have to improvise--- and commit before you know the whole set. So advancement != combat, enabling different play styles. The game rewards trickiness, a *player* skill not a character skill. And each dungeon produces subtly different character types.

The fallout from this decision is that effects can be intensified, and indeed should be because you want different builds to really feel different. The way he balances power is with situationality. For example, autohit is much more fun than a "-4" bonus for webbing. But that really only matters if the monster was hard to hit anyway! Axes don't just attack three adjacent characters, they attack *all* surrounding characters.

One way to create "situationality" is by making spaces interesting. Brogue does this with combinatorially overlapping zones, each with its own advantage and disadvantage. Terrain is more interesting than monsters, and is more self-explanatory and easier to plan around. This leads to emergent narrative from the player! (I have played some Brogue since his talk and this really happens--- one of the most fun things is figuring out how to use a trap or bridge or chasm against the monsters.) The interaction between terrain types and between monsters and terrain creates different "zones": for example, light of sight, a monster constrained to a terrain type, area of effect, vertical/horizonal effects, light levels, monsters avoiding chokepoints, etc.

(I asked one of the questions here; I was trying to get at whether guides also "up level" by becoming interactive--- there's still some optimal decision path to be found, it's just no longer static. He talked about the evolutionary race in general terms, but there's no "solver" for Brogue out there yet. There are, however, interactive guides for other games, though I forget the example I learned at the conference.)

This really tied back to other talks I'd heard about managing and exploiting combinatorial explosions. In my day job, I try very hard to make sure that combinatorial effects *don't* happen. Using feature A and feature B together should not cause a surprising interaction. But in a game, that's what you want! That provides novelty, it provides the opportunity for "wit", it gives a game a depth of behavior that would be hard to build piece by piece.

I'm not likely to rush out an build a roguelike, but maybe I'll participate in the 7DRL challenge next year. (My teenage attempt to write something Nethack-like in C++ was buried under the weight of its own ambitions.) But the conference was very thought-provoking and gave me a bunch of new games to try: Brogue, Rimworld, Caves of Qud, Strange Adventures in Infinite Space, DungeonMans, Transcendence. All the talks I attended were great, and I really encourage you to watch the videos. Drew Streib's talk on running a public Nethack server in particular is worth a listen to get the "ops" perspective instead of the "dev": https://www.youtube.com/watch?v=z3jwPszSgwg