- Jan 3, 2013
- Reaction score
- First Language
- Primarily Uses
Hello Game Design pupils. Today we're heading to the next leg of our journey. Level Design.
A lot of people jump right into mapping when it comes to RPG Maker. This isn't always a bad thing, and people can create a long series of great maps with little design pre-planning. But the level structure can quickly become complex and the design choices made previously can become muddled as the project goes on. If you aim to have a decent sized game, it's smart to design your levels before hand and make sure they're in working order.
After that, passing them on to your mapper or doing them yourself will be a cake walk.
As well, having the barebones information infront of you can help you make informed game design decisions that can improve the quality of your game.
So with that, lets get into it.
1. The Necessities
To start we need some good flowcharting software. You can use anything you like, but for me I'll be using Diagram Designer. A free, simple, and useful tool that fits our needs just fine. If you have your own software suggestion feel free to leave it in the thread.
With that, we also need a good art program to use. Something with layer control. There's plenty of options, GIMP, Paint Shop Pro, Pixia, and a huge list of other things. Take your pick.
2. The Process
The next step after getting our software in order is to start creating a level. Levels come in many different sizes, and there's many ways to do it. For our example I wanted to use something iconic and familiar to the masses. I went with Viridian Forest.
Viridian Forest is the first "dungeon" in Pokemon. It's very simple and compact. It's also flawed, which gives us plenty of room to build up on it.
Lets start by looking at a breakdown of the Viridian Forest level:
The number represent trainers and the letters represent items.
A barebones information chart may look like this:
This was my end result after breaking down Viridian Forest and reconstructing it as a level design in it's most basic format. I purposefully omitted some information that I'm hoping you as a designer may pick up and add to your own work. Before continuing, think of what you might do to improve this design. You will notice I add several improvements as we go.
It's not meant to be flashy or beautiful. It's meant to be informative and controllable. Remember that.
Lets break it down. I'll begin by showing you my first step.
We need an entry point into this room, as well as an exit point. So lets begin.
Next, we need to create a path from the entry to the exit:
This is the most basic method of level design. Create an entry and exit and then plot out the path to the exit. From there we can design extra corridors and branching paths. It's important to make sure that all extra corridors serve a purpose, and that the player always has a reason to explore. We reward players for their exploration.
With the branching paths added, we can start putting in extra data. We can put item locations and enemy locations in. It's always good to label and number these things. (An omission from the original)
From here we can add the palette. I used a color picker and pulled some colors off the base image from Viridian Forest. But because it's a forest, we obviously want greens and browns, and that reflects in the palette we pulled. We also want those greens and browns to change slightly in terms of hue.
We also need some forms of contrast to build up our color palette and add variance. In this case there was flowers which had bits of blue. This helped make the area a bit more colorful in some places.
Because the level is so straightforward and simple, the palette also was straightforward and simple. There was no need to communicate to the player that anything of great importance lay ahead.
If there was a boss, what might you add to the palette and design to help tip the player off that a boss fight is incoming?
For me, it would be a shift in the palette. A dominance of some color in the palette should take place, or a shift or change in the palette or assets.
In color design, we have interesting ways to tip the player off when something dangerous is coming up by playing on our most primitive instincts. I won't go into this, as it's a discussion of the abstract, a separate head of the design monster.
If you didn't catch it, go back to the Introduction Workshop and check out the article on Color Theory and color in video games. It's worth researching color to understand it's significance in your game. I'll try to bring it up as much as I can, but it's such an indepth and abstract discussion I'll be saving it for it's own section.
We can use the A, B, C, D labeling system to indicate on the side of the diagram what each letter is. We can also put pointers on the entry and exit to show what map they connect to. Something like "Level 3-1" or "Overworld Map R1 M2" can be ways to point to other maps or documents that can be looked up.
The best thing about this quick rough draft design is that it can be manipulated freely. We can move and alter a lot of the elements here without disrupting anything or having to do major work for those alterations. We can largely see how the game plays out.
After working on say our most complex and concrete systems that would influence this first level the most, we can do a mock up play-through using our imagination or some paper-doll cutouts and step ourselves through what a player might endure through a standard playthrough of this level. We simply plug in the variables as we play and experience it with a quick iteration.
Iterative testing is one of the most crucial parts of video games, and helps us gain the most feedback about how the game may feel or play.
Further, we can do a mock up of the dungeon, as seen here:
This mockup could be used as a parallax to place trees and tiles onto, and then removed when the layout is complete. We can alternatively use it as a future iteration to test the level before we place the heavier draft down.
Regardless, we have a working concept we can manipulate before it's committed to the game.
At this point we can string together a series of levels and compare them side by side. We can see if we're becoming too repetitive, have too many confusing branching paths, need to space out our items better, or could use something to break up parts of the dungeon.
As well, when levels become more complex we can use these flow charts to keep track of complex systems and puzzles we're designing, and we can rearrange our levels to make those systems as intuitive for the player as possible.
In the following examples, I will link several flow charts from www.garethrees.org and discuss them with you.
This lovely image shows us two incorrect ways to structure a dungeon and one far better way.
Lets look at the middle. This design is linear, and provides the player with no agency or control over their journey.
The left design has too many choices, which may diminish the players sense of accomplishment, or may cause them to break immersion and repeat the game's cycle in order to find fulfillment. Further, it leaves a lot of assets unused by the game, wasting time and space, if the player chooses not to explore them.
The right design has both choice and agency, but not so much as to make the player feel like another choice must be explored. (Barring completionists) It contains the best of both worlds.
We take the design further and look at the first level of Legend of Zelda, the Deku Tree:
This simple breakdown shows the flow of the game, and brings us to some interesting design discoveries. We see minor branching in the tree. Go back and compare this to Viridian Forest's flowchart we made earlier. They're both Nintendo games, and it shows in the similarity of design decisions.
Now lets get some more information out of this. We'll apply this to the floor plans of the dungeon and analyze the data further.
This reverse design shows the flow of each room and the level as a whole. But it's a reverse design, and we could certainly make a better design using the tools we just created. Even the first level of Legend of Zelda, Ocarina of Time, is fairly complex, and best kept track of with a good level design flowchart.
Because this design is solid, there's no major issue. But during flowcharting you may realize that some part of your dungeon is unsolvable due to a mistake a player might make. A good flowchart can help us identify and correct that issue before you commit the design into your game.
3. Putting It All Together
This is by no means the only way to set up and design your levels. But it's certainly a useful method, and a powerful way to design. As you explore and use the design tools at your disposal think of other games with first levels you could break down and learn from. How you can structure your own first levels in this way. We want them to be simple, and we cant to keep our branching low. Later on, we can get more complex. Try taking a look in this spoiler at the LoZ Water Temple that Garethrees has laid out for us:
This is a very complex and interesting beast. Not something we'd want for a first level.
And for that matter, lets look deeper into the first level of Viridian Forest and think about how we could come up with a better design. Maybe more informative NPCs leading up to the dungeon, or an explanation of trainers or something otherwise important. Think of non-verbal ways you can teach the player about the mechanics they'll find in your game right in the first dungeon or leading up to it.
If you want a marvelous example of Level Design, Portal is a great example. This nice video explains a handful of principles a good level designer can take with them in their journey through Game Dev. This isn't the only breakdown of Portal, and it's a good idea to check out at least one breakdown of Portal. Try reverse designing Portal's Levels and recreating them yourself in a flow chart to fully understand them.
Lets also look at our overarching design. If we string together our levels, we can access a lot of information. It's good to look into the Interest Curve and make sure our levels follow it. We need to put the right breaks in at the right times, to contrast with the big highs in our game. We need to make sure our palette is gaining growth and momentum, and giving way to the design of the game. The player should feel the world changing around them, and a sense of purpose and agency should be rising. Conflicts should be resolved, only to lead to new conflicts. As the game progresses, the player should be juggling multiple conflicts throughout the game.
There's a lot that the game needs to be doing, and these designs allow us to see if they're doing that.
Lastly, I want to talk about structuring and storing your documents.
4. Structure and Storage
If I was you, I would get a Cloud Drive, a Dropbox, or a Repository. Somewhere safe to store your files. From here, create a folder with your game name on it. Create different folders for each part of design. Things like Concept Art, Palettes, Level Designs, Story, Mechanics, Item Lists, Skill Lists. All the valuable information about your game. Create folders inside those as well which will contain your important documents. The better your file structure the easier it will be to gather information about your game when you need it.
In the case of level designs, I suggest creating a folder called Level Design. Inside that folder, create another with the Region, World, or Dungeon name.From here you can either drop off the document or create one more folder with the Level Number, Level Name, or Reference Name for your level. You can then put all relevant documents in that folder with that file, such as the separate palette, the tileset, the level outline, monster list, item list, puzzle structures or anything else that makes up that level.
It may seem like a lot of work, but it's actually very simple and easy. The document I created took little time, and is easily manipulated to change the design of my level. I can pull a lot more info out of it than I could a map in RPG Maker. A Mapper or Eventer could also take the information provided and create a map in no time flat using this info.
By having this info strung together, I can them see the overall affect my design has on my game. I can alter things freely before I take my game into the production phase, allowing multiple iterations that will weed out the biggest flaws of my game without making major overhauls between each iteration.
A good design can cut down costs on the final product as well. Many programmers and artists charge extra to design your ideas for you, and their design may not be inline with the design of your game. This could lead to a broken experience, where immersion is quickly lost for the player as they notice inconsistency after inconsistency.
Remember, good design is meant to be the crutch of your game.
Thank you for taking another journey with me through the art of design. We have plenty more things to discuss, and I hope to see you guys in the next Workshop!