“For thou shalt eat the labor of thine hands: thou shalt be happy, and shall be well with thee.”
Psalms 128: 2 – King James Bible
One of the things I enjoy doing when I’m developing a game is the level design. I can do a lot of fun things for my players: challenges, puzzles, skill tests, etc., always taking into account their fun and competitiveness. When Lode Runner was released in 1983, the first level editor in a video game appeared. LR’s level editor allowed everyone to create new maps/levels for the game. It was therefore possible to bring new resources for a video game. DOOM in 1993/94 paved the way for the first user-created modifications (mods) and its community of players created a number of cool things for it. However, the process of designing levels in many people’s minds is a bunch of drawings with some code and a lot of stranger things. In many cases, there’s a lack of information about the process.
Level design comprehends a set of elements, challenges, mathematics, and maps that our player is going to interact with in a game. In it, ideas are applied and translated into “digital mode”, in the most faithfully possible to the original concept. Many level designers work with extensive documentation in the form of a pre-set game script, from game encounters, mobs, puzzles, punishments/rewards, and hooks that allow you to work on continuity and game flow.
It is a very arduous process and requires a lot of experience on what you are creating. Many level designers start their work in quite different ways, by testing different approaches to a certain problem. I remember that I started to understand what level design really is quite earlier in my life. I started quite young; it was something I did with my friends for fun, mostly writing RPG adventures and making new maps for video games. Yes, the old paper and pencil RPGs can teach us a lot about level design. When a game master creates an adventure, it is nothing more than designing a level, with maps, events, mobs, treasures, etc. The old Dungeon Master Guide and the Monster Manuals I and II of AD & D 1st Edition (yes, you can call me old man!) were my first lesson in level designing.
Many games (remembering again the pioneer Lode Runner) had editors for the creating of maps, scenarios, objects, etc. It is a very nice way to understand concepts such as “game balance”, game flow and goals. For beginners, this type of tool is very useful. I created a lot of things (maps, scenarios, mobs) in several different games and I remember that I began to see the first problems involved in that kind of process.
Those two methods were fundamental to my level design experience. I must have made some mistakes, but when I started to design and study the aspects of different games, I gained more confidence and discovered how these “tools” would provide me with satisfactory solutions. However, I only legitimately grew up by making/designing games; by building new levels for them with specific challenges for each situation.
Building a 2D Framework for Level Design
Unlike many, I started to make a kind of 2D framework from scratch. It’s not an easy way to go, but these ideas were born as a result of a series of study cases that were never finished or abandoned. I’ve designed a lot of things, routines, codes, and put all together in a game template. The first challenge has brought up these elements ready for my work toolbox, in this particular case, Construct 2. Some problems came to the surface in most situations because of my lack of capacity and experience, but after some time I fixed many things and my framework was born.
The main idea behind it was the creation of an easy way to build levels and maps, similar to what old game editors do but made for my specifications and needs. For a game designer, it’s the best of both worlds. I have always dreamed about that kind of tool, and I turned it into a reality. My focus in such framework were platform games and I started up with these elements:
- 3 types of mobs
- 2 types of turrets
- 6 types of obstacles
- 2 types of keys and doors
- 2 types of gauntlets*
- 3 types of walls
- 2 types of weapon (melee and ranged)
The answer is simple: because I designed and made a lot of “fail projects”.
I’ve had two projects with a lot of ideas, but also with a lot of problems. Those 2 projects were the main base for my framework. I coded a lot of things, including bosses. Some of them were used in my game Fields of Gore. My new project ASCDungeon was the first platform game developed by me using that framework, and the results have overcome the expectations in all possible ways. In one day, I could make 2 to 3 levels, test them out work on their game balance. For that, I only need to drag and drop items, put each game element in their levels and voilá, the magic happens. The level comes to reality in a small fraction of the time and it gets ready for a real test.
For any regular developer, that would seem too good to be true. Anyway, I’ve spent 5 months working on some details, optimizations and fixing small problems. It’s something that takes time and patience. Nevertheless, in the end, the benefits were worth the whole effort:
– Code reuse and maintenance became extremely simple and with a high capacity for expansion. It really works!
- Object-orientation is your friend here!
– You may test your game in REAL TIME!
– A new mechanic, an asset can be incorporated into the framework and for being reused at any time in a future project. Think about it.
What do we need to know to make our first framework?
As I said earlier on this post, it is not a simple task and you will soon find out why. In the first place, good and bad experiences give to you the comfort you need for starting up your project. However, some recommendations are important, and I’d like to talk about them:
– Knowledge of game programming and object orientation is fundamental. The whole building process will go beyond the basics and you (with more time working in your framework) will have to deal with sepcific needs for some custom modifications in your application (expert mobs behavior, gamepad controls, bosses). These concepts are the basis for understanding a lot of things behind a game project.
– Knowledge about the functionality and resources of map editors, level editors, and game “mod tools” is very important. It’s necessary to understand the working method and the concepts behind them.
– START FROM THE EASIEST, ALWAYS! The KISS (Keep It Simple Stupid) rule must be written on stone and set on your desk. It’s useless to start an XML-based quest system if you didn’t make a simple mob walk on the screen in one simple direction!
– Start building a framework based on your NEEDS! The new features will appear naturally as they are demanded, don’t worry about them.
– Pick a game style you enjoy playing to begin with. A previous knowledge of the chosen game style will help you a lot and it will give you very important game design lessons.
– Be patient!
– Talking about game balancing in level design: is the theme for a complete article, but in this case, I’d like to say: GAME BALANCING is the key to success for a good level of play. So study hard enough.
That’s it, let’s move on! If you’d like to build your framework, it’s time to begin!
*A gauntlet is an event, usually in an instance, that includes fighting against waves of mobs. Killing a (usually) named mob or reaching the end of the gauntlet will stop such event (extracted from Wowpedia – http://wow.gamepedia.com/Gauntlet_(event))