4 ms·

There have been a few attempts at communicating deep learning methodology for procedural generation specifically within the roguelike community to use a specifi

There have been a few attempts at communicating deep learning methodology for procedural generation specifically within the roguelike community to use a specific example. While there is typically some high-level interest, the interest quickly fades and developers go back to using traditional procgen methods. One of the hangups that I've observed is that many of the introductions for procgen deep learning (and deep learning in general) use SL, USL, and AL which require datasets containing many examples. The (time) cost associated with gathering or creating these examples is not appealing to procgen devs. Procgen devs continue using the procgen equivalent of symbolic AI. RL in procgen is largely avoided for the same reasons that RL is rare in other domains. Despite this, I believe there is a connection between the fields through the lens of optimization problems. Typically procgen practitioners have a handful of parameters which they hand-tune to arrive at their desired results. The number of parameters is kept low so as not to exceed the cognitive capabilities of the practitioner. I'm a believer that by turning many of the current discrete procgen algorithms into continuous-valued generators, the number of generator parameters can be increased a thousand or million-fold so long as an appropriate loss function can be crafted (in practice this isn't very hard and proxies can even be used in tricky cases). In a lot of ways this becomes a reparameterization in a way that makes for more salient generator parameters. For me one path forward is crafting continuous versions of existing discrete generators and using autodiff tools like JAX to optimize procgen parameters. This whole rant is pretty specific to the roguelike domain and probably doesn't carry over well to other spaces. Huge YMMV disclaimer.

mam2 6y ago
Yes I think the whole problem for procgen is that it's hard to find an optimisation problem to optimise related to it. if everything goes well with a "symbolic programming" there no reason to change. Its almost
- aaron-santos 6y ago
  > if everything goes well with a "symbolic programming" there no reason to change. Yes and no. The elephant in the procgen room is the "1000 bowls of oatmean" problem[1] ie: perceptual uniqueness. Many procgen practitioners want to maximize serendipity but don't see a path toward that. I expect that methods explored in academia will filter down to practitioners, but the speed at which this occurs is largely modulated by the number of people with a foot in each world and willing to communicate with both sides. The same kind of gap exists within programming language theory and design, though because it is a bigger field, it benefits from network effects to a greater extent. [1] https://galaxykate0.tumblr.com/post/139774965871/so-you-want-to-build-a-generator https://galaxykate0.tumblr.com/post/139774965871/so-you-want...
  - mam2 6y ago
    Well even the real world looks like oatmeal after 50+ countries...
munificent 6y ago
I'm skeptical that machine learning has much to offer the typical roguelike developer. Most roguelikes approach a player/developer ratio of zero. For every successful shipped roguelike with actual players, there are probably a thousand hobby roguelikes with no users but a happy developer or two wiling their time away. This is not a particularly lucrative corner of the gamedev world, so most are in it for the intrinsic motivation. Handcrafting a level generator is a lot of fun. Training an ML model might be fun too, but it seems like a very different sort of activity, and not necessarily one that appeals to roguelike devs. > so long as an appropriate loss function can be crafted (in practice this isn't very hard and proxies can even be used in tricky cases). I'm skeptical that this is as easy as you suggest. Everyone thinks making something "fun" is easy until they sit down to try. Fun is the knife-edge between familiarity and surprise. Optimizing for it is probably in the same order of difficulty as predicting the stock market: If you train your generator to be particularly fun in a certain way, players will quickly grow tired of it, which isn't fun.
- seg_lol 6y ago
  > Fun is the knife-edge between familiarity and surprise. If we can autogenerate infinite fun, the human race is doomed.
agar 6y ago
Perhaps a dumb question from one fairly unschooled in ML: Can't ML be used to augment traditional procgen methods to create unique ornamentation and art styles on top of traditionally procedurally generated level layouts? IMO, despite how interesting procgen levels themselves can be, they ultimately suffer from "sameness" - similar looking building facades, trees, stonework, etc. become boring fast. Couldn't one create separate training sets such as plants in varying biomes, unique architectural styles, and divergent cultural artwork, and then apply these sets to create new textures and primitives for decorating levels? This would keep different levels/environments/dungeons/whatever feeling fresh while saving on the laborious work of drawing "stone texture #43" or having the same painting in every tavern in the land. Obviously I'm thinking of graphical rogue-lites like One Must Fall or In Death, or RPGs with procedurally-generated elements, not classic text-based games like Rogue or Hack.
- meheleventyone 6y ago
  The problem here is that the differences have no meaning. Which is to say variation that is skin deep isn’t very interesting.
  - agar 6y ago
    I would counter-argue on three fronts: 1. A lack of variation, even skin deep, is even less interesting than only skin-deep variation. That is often the norm in large "open world" environments. 2. Much of what we find most interesting about the world is, in fact, skin deep. Take humans for example; all fit the same mold, but the range of human variation is endlessly fascinating to artists and audiences alike. Similarly, the layout of the Prati region of Rome and the Marina/Cow Hollow district of San Francisco is not wildly different. However, both are distinct, worthy of visiting, and unlikely to be confused with each other. 3. Current methods of procedural generation, without AI/ML, already result in fairly interesting maps. Could "true" AI do better? Perhaps, but I'm not sure that the delta is so great that the results would be noticeably better than a well constructed procedural algorithm (play "Tea for God" if you have a VR HMD and a lot of space). I could be wrong though - the gold standard remains hand-placed, human-built worlds filled with little surprises. If an AI approach resulted in a level design competing with the best of bespoke worlds, particularly at a lower development cost, then I'm all for it.
fenomas 6y ago
I gave a talk on procgen last year where one of my slides attempted to sum things up thusly: > In my experience good procgen is the creative application of boring algorithms. Your key weapons are imagination and iteration at the design stage - but the actual code tends to be simple, and fancier algos don't make your content any better. > In contrast with ML, you live or die by how magical your data and algorithms are, but you have little direct control over the output so it's not a very creative process. You tend to pull the levers and hope that what comes out will be suitable. To me that difference is why ML tends not to work well for procgen problems. With creative tasks we tend to have top-down design constraints that we want to impose (e.g. a minecraft village needs to fulfill various requirements for the game engine to treat it as a village), and the task is to make content "interesting" while meeting those constraints. With procgen this is straightforward - you start with the constraints, and creatively iterate on the "interesting". Whereas with ML you often get interesting for free, but if your output doesn't fulfill this or that constraint, it's not very obvious how to proceed.
entrep 6y ago
Without having read the paper, I believe the approach forward should be inspired by GPT-3. If the AI responsible for procedural generation can look at a very large set of existing games, then it might be able to generate the content given a few examples (i.e. few-shot).

mam2 6y ago

Yes I think the whole problem for procgen is that it's hard to find an optimisation problem to optimise related to it. if everything goes well with a "symbolic programming" there no reason to change. Its almost

aaron-santos 6y ago
> if everything goes well with a "symbolic programming" there no reason to change. Yes and no. The elephant in the procgen room is the "1000 bowls of oatmean" problem[1] ie: perceptual uniqueness. Many procgen practitioners want to maximize serendipity but don't see a path toward that. I expect that methods explored in academia will filter down to practitioners, but the speed at which this occurs is largely modulated by the number of people with a foot in each world and willing to communicate with both sides. The same kind of gap exists within programming language theory and design, though because it is a bigger field, it benefits from network effects to a greater extent. [1] https://galaxykate0.tumblr.com/post/139774965871/so-you-want-to-build-a-generator https://galaxykate0.tumblr.com/post/139774965871/so-you-want...
- mam2 6y ago
  Well even the real world looks like oatmeal after 50+ countries...

munificent 6y ago

I'm skeptical that machine learning has much to offer the typical roguelike developer. Most roguelikes approach a player/developer ratio of zero. For every successful shipped roguelike with actual players, there are probably a thousand hobby roguelikes with no users but a happy developer or two wiling their time away. This is not a particularly lucrative corner of the gamedev world, so most are in it for the intrinsic motivation. Handcrafting a level generator is a lot of fun. Training an ML model might be fun too, but it seems like a very different sort of activity, and not necessarily one that appeals to roguelike devs. > so long as an appropriate loss function can be crafted (in practice this isn't very hard and proxies can even be used in tricky cases). I'm skeptical that this is as easy as you suggest. Everyone thinks making something "fun" is easy until they sit down to try. Fun is the knife-edge between familiarity and surprise. Optimizing for it is probably in the same order of difficulty as predicting the stock market: If you train your generator to be particularly fun in a certain way, players will quickly grow tired of it, which isn't fun.

seg_lol 6y ago
> Fun is the knife-edge between familiarity and surprise. If we can autogenerate infinite fun, the human race is doomed.

agar 6y ago

Perhaps a dumb question from one fairly unschooled in ML: Can't ML be used to augment traditional procgen methods to create unique ornamentation and art styles on top of traditionally procedurally generated level layouts? IMO, despite how interesting procgen levels themselves can be, they ultimately suffer from "sameness" - similar looking building facades, trees, stonework, etc. become boring fast. Couldn't one create separate training sets such as plants in varying biomes, unique architectural styles, and divergent cultural artwork, and then apply these sets to create new textures and primitives for decorating levels? This would keep different levels/environments/dungeons/whatever feeling fresh while saving on the laborious work of drawing "stone texture #43" or having the same painting in every tavern in the land. Obviously I'm thinking of graphical rogue-lites like One Must Fall or In Death, or RPGs with procedurally-generated elements, not classic text-based games like Rogue or Hack.

meheleventyone 6y ago
The problem here is that the differences have no meaning. Which is to say variation that is skin deep isn’t very interesting.
- agar 6y ago
  I would counter-argue on three fronts: 1. A lack of variation, even skin deep, is even less interesting than only skin-deep variation. That is often the norm in large "open world" environments. 2. Much of what we find most interesting about the world is, in fact, skin deep. Take humans for example; all fit the same mold, but the range of human variation is endlessly fascinating to artists and audiences alike. Similarly, the layout of the Prati region of Rome and the Marina/Cow Hollow district of San Francisco is not wildly different. However, both are distinct, worthy of visiting, and unlikely to be confused with each other. 3. Current methods of procedural generation, without AI/ML, already result in fairly interesting maps. Could "true" AI do better? Perhaps, but I'm not sure that the delta is so great that the results would be noticeably better than a well constructed procedural algorithm (play "Tea for God" if you have a VR HMD and a lot of space). I could be wrong though - the gold standard remains hand-placed, human-built worlds filled with little surprises. If an AI approach resulted in a level design competing with the best of bespoke worlds, particularly at a lower development cost, then I'm all for it.

fenomas 6y ago

I gave a talk on procgen last year where one of my slides attempted to sum things up thusly: > In my experience good procgen is the creative application of boring algorithms. Your key weapons are imagination and iteration at the design stage - but the actual code tends to be simple, and fancier algos don't make your content any better. > In contrast with ML, you live or die by how magical your data and algorithms are, but you have little direct control over the output so it's not a very creative process. You tend to pull the levers and hope that what comes out will be suitable. To me that difference is why ML tends not to work well for procgen problems. With creative tasks we tend to have top-down design constraints that we want to impose (e.g. a minecraft village needs to fulfill various requirements for the game engine to treat it as a village), and the task is to make content "interesting" while meeting those constraints. With procgen this is straightforward - you start with the constraints, and creatively iterate on the "interesting". Whereas with ML you often get interesting for free, but if your output doesn't fulfill this or that constraint, it's not very obvious how to proceed.

entrep 6y ago

Without having read the paper, I believe the approach forward should be inspired by GPT-3. If the AI responsible for procedural generation can look at a very large set of existing games, then it might be able to generate the content given a few examples (i.e. few-shot).