Making levels for games

Started by
4 comments, last by PhilLiu 12 years, 8 months ago
Hi! I would like to know how one goes about making levels for games? Does one need to use an editor or something?I've read some stuff about using text files to design the levels so how does one go about doing this? Thanks!
Advertisement
Are you making levels for an existing game?
If so, the game might have a level editor built in (so the players can create their own levels).

Or are you making levels for your original game?
If so, are you using an engine, or are you creating from scratch?
If you're using an engine, you use the engine to make the levels. If you're making it from scratch, you make the levels from scratch.

-- Tom Sloper -- sloperama.com

Well, What I usually see is, something like so...


111111111
100000001
100000001
111111111

Whereas, 1 could be a wall, and 0's open spaces, it's up to you to make the program interpret this from a file, If your a beginner you might want to just hard code your first game's levels, other wise good luck!

P.S, if you didn't know, you'll need to use another library to read from and write to files.
I take a screenshot from google earth of some cool waterway or feature I want as a basis, with my "Print Screen" button.

I open photoshop.

I paste my screenshot into a new file.

I use a combination of marquee, lasso, fill, and paint brush using black to fill water (lowest point), white for the highest part of mountains, and some shades of gray between the two.

I convert it to grayscale and save it as a tiff. From there you can cut, resize, rotate and paste various features from other grayscale maps you've created.

I import it into my game engine editor as a heightmap, blur sharp edges with a crossthatch movement of the cursor using a blur tool, then I apply textures, trees, plants etc from there.

I've made maps based off things like the great lakes, sweden, and from copying other games maps then cutting/resizing parts I like and make a new map from it.

Depending on what game engine you go with I'd google how to import "heightmaps" into that engine if it allows it.
Does one need to use an editor or something?
Sure. At the lowest-level, you write them using Hex editors. Or notepad, if you're lucky. All "complex" games typically have their own editors, as well as some way to mangle the output of other programs (often by using filters).
Some programs I've managed to use to make maps by using filters: SketchUp, Blender, QuArK, GtkRadiant, programs outputting common formats such as obj (i suppose that was mainly 3D Studio Max).


I've read some stuff about using text files to design the levels so how does one go about doing this? Thanks!
There are two main schools of concept here. The first is the text-driven, human-readable school. Proponents of this line of thought state that
  1. Users should be able to just open assets using notepad, and write in stuff
  2. Human readable is best, if you have a bug, you can see it directly. No need to wonder what a crazy bit pattern means such as 0x34AB1204.
  3. It is demonstrated that text can encode pretty much the same information as any other method.
  4. Formats are generally easy to parse.
  5. You can use XML!

At the other side of the ring, there are the binary guys. Those guys typically just go along and mind their business. I have set home here. Based on my experience (mileage might vary).
  1. To edit an asset, use the appropriate editor. Human brain can process graphical features much faster and more effectively than text.
  2. No need to see the bit patterns at all. Nonetheless, when you start having text files of over 1 MiB, pinpointing the problem is going to be really difficult, even with human-readable text. Text does not scale.
  3. Binary stream allow generally easier error detection, the encoding is typically more effective (example a float always takes 4 bytes, much less than its text representation).
  4. Parsing is performed when binary file is produced.

So, 1st: figure out what you need to encode (pixels? triangle data? collision volumes?)
2nd thing is to decide how to encode (text/binary)
3rd: figure out what to encode.

For example, some weeks ago I played with building a maze exploration game. I decided to give text a go. I needed to encode the maze entrance, the position of the maze in the world and how to connect the various maze rooms. I ended up with a thing similar to a CSV file.
[source]# Each text between ; is a room.
# Blank is no room. Each room has openings N,S,W,E.
# O is a closed room. Get there using teleporters.
# ! is the starting point. Filter will spit out an error if there's more than one. V is the goal.
!SE;WE;WS
NS;NSWE;NS
NE;WE;WNv
[/source]
This would load in OpenOffice calc as a CSV. It worked ok for the layout. But when I started adding enemies, teleporters, objects... it became a no-go.

Previously "Krohm"

The simplest way is to create your own file format to define your levels in a way that makes sense to you.

Usually, I suggest novice programmers create their own level editor for the experience.

However, it is completely legitmate to use some sort of third party level editor such as Tiled.

Depending on the architecture of your game, your file format may vary. For example, if my game was mainly composed of (relatively continuous) polygon shapes, I would probably construct my level to look like this:


name=LEVEL1;
size=(100,100);
player=(20,20);
polygon (1,1) (2,4) (3,6) (1,2);
circle (56,66) 6;


And this would define a 100x100 game map with the player starting at (20,20) and creating a polygon centered at ~(2,3) and a circle at (56,66) with radius 6.


If your program is tile based, the most readable format would be one character per tile

name=LEVEL1;
size=(16,16);
................
.............D..
....############
................
##..............
................
.....##.........
................
..........##....
................
..............##
................
...........##...
................
.P......##......
################


This would create a map with a bunch of blocks "#", player starting at the "P" position, and the door being at the "D" position. "." are open space.

After all this, if maps become large and space is a problem, you can always compress it with some basic compression such as:


####.......##...

compresses to

4#7.2#3.

This topic is closed to new replies.

Advertisement