Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 29, 2014
arrowPress Releases
July 29, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Level Design in Procedural Generation
by Tanya X Short on 02/04/14 07:30:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Tanya X. Short is the creative director of Kitfox Games. A version of this article was originally published on the Kitfox Games blog. Any and all relationship between this article and their new game, Moon Hunters, is pure speculation.

Introduction

I'm a level designer by trade and training. I've done system design, game design, and narrative design, but my heart is that of a content designer. Whether it was Lovecraftian whisperings in The Secret World or friendly slimes in Dungeons of Fayte, I seem to get the most joy out of creating hand-crafted player experiences. So when Kitfox decided that, as a small team looking to compete in an increasingly crowded market, we would invest in procedurally generated content, I was initially a little nervous.

One of the dangers of procedural generation is that you end up with a smooth blend of samey content that's essentially predictable in flavor and tone. The singular advantage that proc-gen has over "couture content" is unpredictability, so it's essential that this not become diluted. This article is a retrospective, reflecting on how we tried to avoid that trap, and made me glad we decided as we did.

I'll talk a bit about our data structure, I'll show a little bit about how we use Unity to create designer "tools", and demonstrate how the complexity grew quite naturally over time from a simple premise. Keep in mind that I am a designer - I didn't write a single line of the procedural generation code in Shattered Planet. All programmer high-fives and awe-struck eye-shinings should be directed towards Mike Ditchburn, Jongwoo Kim, and Greg Londish.

pocgen3

As the designer, it's my job to define the intended player experience, and work with the programmers to translate that into workable rules for the game's engine to follow. Meanwhile, Xin Ran Liu (the artist) and I worked together to use those same rules to generate aesthetically pleasing environment designs from modular pieces. So this is a rather high-level look at the logic behind the system, rather than the code that actually runs the system, or the actual sprites it uses to render it. 

If you're interested in the actual code, let us know and we'll see what we can do!

So without further ado... let's start at the beginning.

The Goal

We started work in the beginning of June, 2013. After two weeks, we had finished with our little prototype and we our gameplay was essentially a turn-based RPG in procedurally generated levels. We knew we would be using Unity.

Not long after, we decided on three design pillars to inform all of our design decisions (with some art direction impact as well):

* Intriguing: entices the player to be curious, and rewards experimentation & exploration
* Strategic: rewards tactical play -- various different ways to achieve combat superiority, resulting in difficult decisions
* Accessible: immediately engaging, with lots of feedback, encouragement, and opt-in information

These each, of course, had their own risks if any one aspect became unbalanced or poorly implemented. If the 'intriguing' content is too mysterious, it may be invisible to players, or downright bewildering. If the strategic component is too strong, it may be off-putting or intimidating for players, especially on tablets (unless we think we can subsist on poaching Paradox fans). On the other end of the spectrum, if there's accessibility without strategy or mystery, it will feel like an empty shell of a game with nothing worth engaging with in the first place, especially for more hardcore gamers like myself.

But before you have a level, you need the building blocks.

Room Structure

We wanted to be able to learn from the reams and reams of information online about procedural generation of game levels. Most of these involve "dungeons" assembled from tile-based, rectangular "rooms" and "corridors". We read and absorbed these as much as we could. However, to keep with the "shattered planet" feel, Xin directed that from an art perspective, it was essential that our rooms would be more organic in shape. This is cool, but made it so we generally couldn't use someone else's algorithm. (Though a few months later, someone wrote this neat cave generator.)

So, we give each room a minimum and maximum height and width, using square tiles. For example, a room might be a minimum of 2x2 but a maximum of 4x4. This results in a variety of possible sizes. Here's an actual shot of what my design tool looks like, for determining the room size potentials (each level set has 4-5 room definitions):

roomdata

(Note, since it's not obvious from context: Min and Max "Num Rooms" actually refers to how many of this particular room definition are allowed to appear in a level.

The level designer in me chose different sizes of rooms to cause different emotional reactions in the player. Small (2x2) rooms or Lake rooms are more claustrophobic, but also allow more tactical maneuvers to overcome A.I., by blocking and trapping them in corridors. Conversely, larger rooms feel more expansive and filled with potential, but also can cause the player to become surrounded on all sides. Ensuring that different levels have different feels (tight or loose) keeps the algorithm unpredictable.

The above is a snippet from the "RoomsBasic" level set, as opposed to the "NoLakes" level set, etc.) Using those width & height & lake rules results in something like this:

level generation design

As you can see, each also has the possibility of internal "holes", or "lakes" to be generated. This is handled entirely by the engine -- as the designer, I merely specify whether or not a given room can have a lake or not. Depending on the theme (desert, laboratory, etc), the "lake" may look like water, lasers, acid, etc. I can also decide per-theme which tiles rooms should use (Dirt and brush? Or stone and grass? Or a combination?), and which obstacles (rocks, mushrooms, a combination, etc). Another tools screenshot:

themedata

(Gen Dirt = Generic Dirt, Des Sandstone = Desert Sandstone, StoneDirt is half of each, naturally forming a border between the primary & secondary tile types)

Each room also has (thanks to our lead programmer, Mike Ditchburn) 2-4 tiles set aside as potential "door" tiles, one on each side. Once these are actually connected to other rooms, the game uses a pathfinding algorithm to decide where it's "safe" to place obstacles -- i.e. where it won't block the player from traversing the room or accessing treasure. 

obstacles

So, taking these rooms and my experience in traditional level design, we built the initial algorithm for how our levels would be generated, which was all about the Critical Path.

Critical Path

If you're a level designer, you know that the 'critical path' is the way the player MUST go, in order to complete the level, with no side-tracks, distractions, or mishaps. Typically, to encourage players to continue on the 'correct' path, designers place rewards such as coins (similar to an enticing trail of Reese's Pieces)... but also enemies. This seems unintuitive, but assuming combat is a fun, central feature of your game (i.e. not a stealth game), players look forward to an opportunity to engage with your combat. This pulls the player forward.

So, in Shattered Planet, one of the first rules of level generation we established was that the engine would establish a "critical path" of rooms, which contains the player's starting "room", the final "teleporter" room, where the player escapes the level, and all rooms directly in between. Here's a hand-built mockup I made in June 2013, to communicate my design intent to the programmers:

criticalpath

We then treat these rooms differently than side-rooms. Where critical path rooms get lots of little piles of coins to lead the player forward, side-rooms get "treasure piles" -- fewer but larger coin-heaps. Similarly, where critical path rooms get fairly average-difficulty monsters, wandering off to the side-rooms may result in occasional monsters of greater difficulty. This is supposed to create a sense of risk for reward -- generally, going the opposite direction from a big baddie will result in finding the teleporter, but also in avoiding treasure.

So at this point, without any further improvements, this is what the maps looked like in the editor (circa July 2013). You can see the first one includes some fancier decorations like crumbly tiles and those half-tile transitions mentioned above, while the bottom two are a bit earlier:

pocgentriptych

Locked Doors

To add a bit of variety and reason to explore the corners, we added locked doors, with keycards scattered somewhere else in the level. Rather than block the player's progress (or frustrate them if they're in a hurry, with the Blight on their tail!), we decided to use the locked doors only for optional bonus treasures (and monsters!). So, we wanted to make sure the locked doors never appear on the critical path. Since we know which rooms are on the critical path and not, it was an easy enough upgrade to remove one corridor from an off-path room temporarily and replace it with:

(You can also see a locked door in the first panel of the triptych above, if you squint hard)

desert

We still have a couple of algorithm improvements left to implement with this, to make it feel right. We want to make sure, for example, that the locked room has a high chance of extra treasure, and that the keycard spawns in a room other than the one with the door in it.

Alternate paths

And yet almost as soon as we had the critical path and side-rooms laid out, even with locked doors, we realised the levels were pretty boring. They had a lot of dead-ends, which resulted in lots of back-tracking, especially for treasure-hunters... far from the Zen flow of a good level. In fact, a room could only have a maximum number of 2 exits, in the above maps! Not a whole lot of choice going on there.

So, to add variety and 'flow', we tacked on room connections, after the critical path and side-rooms have been positioned. Remember how in the "Room Structure" section above I said we mark out a few "doors" per room? Well, we use those again! We (by which I mean Mike tells the engine to) find a couple of doors near each other, and draw a straight line between them, as best it can, turning at right angles if needed.

junction

This added a much-needed refreshment to the dead-end problem, and makes exploration that much more interesting.

Exceptions

As with any rules, there are always exceptions. Even in game design. Maybe especially in game design.

Although most of our game is proc-gen, we also needed to support a few "hand-crafted" levels, including the space-ship that serves as the player's hub, as well as potentially other, secret special levels, boss fights, etc. We tried to re-use the same data as much as possible. So, for tiles, I use the same TerrainData cubes as in the examples above -- see, here's a peek at the hub, only in this screenshot I've taken a normal tile and replaced one with the old familiar "Gen Dirt" from before.

tilehub

I can also place the usual enemies, items, and obstacle data objects I use to populate themes.

We also need to occasionally make tweaks based on powers we add to the game. When we added the "setting fire" mechanic, for example, we made organic tile types (grass, brush, moss) flammable, so the fire would spread organically. So we now have an environment design rule that unless there's a very good reason, gameplay environments should have a chance of organic tiles appearing. Of course, the average proportion of organic tiles vs inorganic can vary wildly, to increase/decrease that usefulness and danger accordingly, and challenge the player to change their strategy on the fly... but if fire were only useful in one environment, it would be an ineffective mechanic. 

Similar tweaks and exceptions need to be made whenever you add a new tool to the player's toolbox -- teleportation, jumping, camouflage, sneaking, invisibility, etc. Assuming you want the power to be genuinely useful in a flexible, user-directed way, your level design algorithm has to take it into consideration.

Future Changes and Lessons Learned

There's always more to do! The level design for Shattered Planet is aaalmost done, but we want (as you may have noticed in the Critical Path illustration) alternate teleporters that can let you skip to special/secret level themes, special ways for the player to creatively make their own paths to floating rooms, maybe even a swimming ability.

But if we've learned anything from all this experimentation from the last few months, it's:
* Apply traditional level design principles, with flexibility -- they're still useful!
* Procedural generation takes a crazy amount of testing! Just figuring out how to replicate a bug can take hours of loading and re-loading, to isolate the part of the algorithm that is misbehaving.
* Stay open-minded to possible improvements, after you've "finished" implementing your procedural generation. As with every other aspect of design, you'll probably never be "finished".

Shattered Planet comes out for free on tablets in March, with a PC/Mac version after. If you're interested in being notified when it launches, join our newsletter or watch our blog for regular updates.

We're also likely to apply these learnings to our next project, Moon Hunters, even though it's a different genre, perspective, gameplay style, and target platform. The benefits of procedural generation to a small team continue to outweigh the risks -- we're unlikely to give up on that anytime soon.

All comments and suggestions welcome, either in the comments here on Gamasutra or personally to me on Twitter. Thanks for reading!


Related Jobs

Turbine Inc.
Turbine Inc. — Needham, Massachusetts, United States
[07.29.14]

Cloud Solution Architect
2K
2K — Novato, California, United States
[07.29.14]

Senior Animation Engineer
2K
2K — Novato, California, United States
[07.29.14]

Graphics/Rendering Engineer
2K
2K — Novato, California, United States
[07.29.14]

Senior Tools Programmer






Comments


Emerick Aussignac
profile image
Nice article, I find the idea for the different types of "doors" linkind islands very interesting.

Concerning the debugging problems that comes whith procedural generation, if it's not already the case, having the current random seed displayed in the inspector would help a lot.
Having the ability to reproduce any wanted situation/placement/random sequence makes balancing and debugging much easier.

Will Hendrickson
profile image
Very interesting article!

I do like the take from a level designer's perspective. Of course, in my own work in procedural generation this has been a big topic for me. Like you mentioned earlier, it is relatively easy to make very boring level generators!

Thanks!

Jesse Tucker
profile image
Interesting article, thanks for sharing.

In my experience, sprinkling hand-made elements into primarily random areas adds a lot to overcoming the feeling of samey-ness that comes from generated areas. Beings you had the technology to do this for things like boss rooms and secret areas, did you include handcrafted islands that combined with the procedurally created ones to add extra variety and utilize design methods that may not be covered by the procedural algorithms?

Jonnathan Hilliard
profile image
Nice article, thanks.
As Emerick mentioned:- to reduce the need for "crazy amount of testing....to replicate a bug" You should display, debug print/log, and maybe store the 'random seed' value used to generate a level during play. Then its easy to re-generate the exact same level to replicate the bug.

Jesse Tucker
profile image
This is what we did for Torchlight 2.

Ed Alexander
profile image
This article made me happy. Thanks for sharing!

Leszek Lisowski
profile image
Nice article, we are working on a 4X strategy game with procedurally generated terrain and in the near future planning to implement various types of created land masses, like archipelagos or super-continents.

Dave Hoskins
profile image
I think procedural generation is often shied away from because of the lack of artistic input. But we're getting to the point where a lot of the in game content can be FOUND rather than created from scratch, saving a lot of resources.
A bit like when doing a movie like LOTR, they just have to go up in helicopters and find the best scenery to film with, not spend exhaustive time and money creating it.

Lihim Sidhe
profile image
"Keep in mind that I am a designer - I didn't write a single line of the procedural generation code in Shattered Planet. All programmer high-fives and awe-struck eye-shinings should be directed towards Mike Ditchburn, Jongwoo Kim, and Greg Londish."

To Everyone: If Person A has background and associate's degree in illustration, what would be (in your opinion) the best bachelor's to combine with that to be the type of designer that authored this article?

I choose to ask this here because this article shows a fine display of logic and raw design. I adore the principles exemplified here. I know computer science is pretty much the default safe bet of degrees but is it the best pursuit for raw design discussed here? There is such a fine display of relationships between different elements, the logic systems, connecting principles, and my favorite - Critical Path.

9/10 I would prefer a game with procedural generation as the main sculptor of the world around me. That's just how I am. DMC3 Bloody Palace arena with Minecraft seeds anyone? Ha, anyway this was just a great article and I would really appreciate any advice for academic pursuit. I worked my ass off for my G.I. Bill so I definitely am going to use it. :)

Jesse Tucker
profile image
As a level designer I don't do programming, but I do a significant amount of scripting. A programming background will help you understand underlying systems and work better with programmers because you'll have a better idea of what they can do in terms of creating tools for you to use. In this article, I would assume that even though the author didn't outright program the procedural systems, she had tremendous input on how the systems were designed. Having a programming background is very helpful in a role such as that.
I personally have a computer engineering degree and do program in C#/Unity in my spare time. I wouldn't say you would need that much training, but some programming background would be tremendously helpful as a designer.

Lihim Sidhe
profile image
From your point of view would a designer who is skilled in javascript, php, and Unity3D be enough to bridge the gap between the realms of design and development?

Tanya X Short
profile image
Hi Lihim!

I had a bachelor's degree in English Literature, but took (multiple) classes in computer science and psychology. But there's lots of ways to study design, and they all come down to:

* making lots of games and levels
* reading design theory
* making more games and levels

You don't need a degree to do that, just like you don't need a degree to be an amazing painter. Schooling just helps in terms of giving you deadlines, peer pressure, and structure, for those of us who aren't super-disciplined on their own (like me). My design expertise and level design portfolio came from getting a master's in level design from the Guildhall at SMU. It's an expensive program, but if you apply yourself, it's an amazing place you can flourish in.

Lihim Sidhe
profile image
Thanks for the response. :)

I'm not a coder with anything beyond javascript but I understood everything you said describing the systems you used in this game. That's why it was so awesome to read this article. As I read I felt myself agreeing with the decisions you made and the underlying logic behind them.

Thanks for your advice. I'll look into SMU. And thanks for writing such a great article!

David Verney
profile image
This has been an interesting, useful and important post from someone who is obviously very experienced in level design. Thanks for writing it.

David Verney
Games Design Student

Ashkan Saeedi Mazdeh
profile image
Awesome post!
I hope everyone from community shares his/her stuff like you.

Easy and useful read.


none
 
Comment: