This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
From here, we can do a number of things:
1. As each of these effects is separated out, we're able to swap things in and out. This modularity helps us try new things and new patterns out of old ones.
2. Ugly Baby is about a connection between visuals and music. We can take advantage of the fact that we know where the player's going to be at any given point in the music, so we can take a look at the audio signal and construct things based on that.
For example, we've done this by constricting the tunnel during louder parts of a song or changing piece colors based on the high frequency components of the audio signal.
3. We can allow the player to tweak some of these values to create their own levels. What if, instead of six columns, they want two? Or, what if the pieces should all be extremely fat?
Small changes in mutator parameters led to understandable but tangible changes in the level. Here, we just played with number and scale of the columns, along with the base model that comprises the columns:
We then created a vocabulary of these (e.g. a grid of objects, below, to the left), and combined them (a grid plus a ring of objects, lower right).
That's worked well for more abstract things, but we also wanted to see if this worked with more organic structures.
In Ugly Baby, we complement the abstract, geometric level design with models that were more organic. To wit, we created a graphical, node-based utility within Maya, called DING. Here's the process of creating an insect within that environment.
We begin by generating a cylinder. Above are two screenshots -- the top one displays the graph (the left node creates a cylinder; the right node displays it).
The lower image displays the resulting model. DING creates the geometry, and Maya displays it (and later exports it to FBX).
We then apply a (non-destructive) taper to the cylinder, making it fatter in some places, and thinner in others. The graph you see is the taper's profile -- we set this manually, starting out fat, pulling in at the joint, and eventually tapering at the foot.
We toss in nodes (in red) to reorient the piece vertically, then add a "ring" node, which creates a ring of six of the shape.
We add in a sphere node, then merge that (boolean union node) with the ring. It's beginning to look something like a spider.
As we tapered the leg before, we now add a contour node to the entire thing. This pinches the whole model's middle. We also subdivide the mesh to make it smoother.
Finally, let's squash the heck out of the front, contouring along the perpendicular axis. The resulting shape looks something like a tick.
As the model's not generated at runtime, it's not reactive to the music, the way the level structure is. But it does satisfy two of our goals, in that it has allowed us to create interesting content quickly (this approach is accessible to our team members not familiar with Maya), and it allows us to experiment a great deal. Since all of these operations are nondestructive, we can increase decrease the number of legs in the ring; change the contour profile (below); or even swap out the cylinder or sphere primitives and see what happens. Next on our Christmas wishlist is a "randomize" button.
It's worth noting that graph-based tools exist for all sorts of uses. We went abstract for Ugly Baby's level design and organic for the enemies, but in our 2011 follow-up to Aaaaa! (called AaaaaAAaaaAAAaaAAAAaAAAAA!!! for the Awesome), we wanted realistic textures, for which we went with the excellent node-based Genetica by Spiral Graphics.
While "going modular" isn't new, and connecting nodes together hasn't magically solved all our level generation problems of intersecting objects or nonsensical output, it has helped us become more productive and "clip off the degenerate branches" of content generation while keeping the useful output.
As such, we've been able to retain PCG's strengths (quicker content generation, dynamic content, smaller on-disk footprint, and enhanced creativity through happy accidents) while mitigating their downsides (avoiding a spaghetti mass of code makes things more manageable, etc.). And while PCG isn't a panacea, we think we're using it to successfully create compelling content otherwise inaccessible to us.
So, that's that! We're not PCG experts, but we hope that this article has added a few more data points in your quest for the flying car.