Deep Learning for Procedural Content Generation – a survey
arxiv.org
arxiv.org
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.
Its almost
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...
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.
If we can autogenerate infinite fun, the human race is doomed.
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.
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.
2. I'm not sure these examples are skin deep to be honest in that I don't think it's just the visual variation that makes these comparisons interesting. There's some underlying meaning being glossed over.
For me the majority of AI generative/artistic projects just create facsimiles. They lack the spark of human input and often only really create mild interest when they get it through hand curation.
I see no reason why principles like this https://dl.acm.org/doi/10.1145/3306305.3332370
or this https://github.com/EvgenyKashin/stylegan2-distillation
couldn't be used to create much richer environments, at least in terms of media.
> 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.
There's no mechanical restriction from using it on text only (with OpenAI's ImageGPT being an extreme example), and it will be interesting to see how/if it competes with LSTMs for nontext domains.
To be clear, I'm describing using transformers as autoencoders
In the end, the results are what's important. It's cool to have fancy, new ways of doing things, but if something works and the new way isn't significantly better or easier than traditional ways and ends up being out of reach or significantly different than traditional wqys for little to no gain then, yeah, it's not likely to be widely adopted.
That all being said, it wouldn't surprise me if some day, some enterprising deep learning fan does come up with some new interesting or more efficient thing that sparks a new line of research and innovation.
It's the way with a lot of things, the early adopters and enthusiasts pave the way for the others.
I tend to regard a lot of machine learning, deep learning, ai kind of stuff as overblown, buzz wordy, euphemisms for fancy algorithms with internal memory and data analysis and manipulation capabilities.
But, that doesn't mean there aren't still innovative things that can be done with it.
Likely, someone will come along at some point with something easily accessible made with deep learning that revolutionizes procedural generation and helps in creating more realistic random environments. We're not there yet though, hence the general disregard for it.