Level Design And "Level Data" file formats

Newbie & Debugging Questions
#1

Firstly, I apologize if I have not posted the under the correct topic. “Newbie & Debugging Questions” seemed the appropriate place, as I am Newbie and am unsure of the difficulty of this question.

I will try to frame the question as cleanly as I can:
Suppose that I have decided to create a game in which each level has been designed in advance; that is, drawn out on paper with colored markers or by some other method. These levels were designed in the aforedescribed manner by an artist, or someone with no regard whatsoever for the difficulty of implementing a particular design in code (I do not mean to offend any artists here). My question is this: Does there exist any sort of file format that works with some other utility to easily store representations of a designed “terrain” or “level”? More specifically does such a format and utility exist that is an improvement over the “brute force” method of specifying some “draw” and “render” function to create each level on a pixel by pixel basis with hard coded coordinates and things like that? Or is such a format and utility something that is typically implemented from the ground up by individual game programmers to meet there specific requirements? Also I will add: (Because maybe someone will find it useful for the question) I am mostly set on using Slick2D as a game engine for my project.

#2

This depends on what the nature of your design actually is. Grid based? Polygons?

Cas :slight_smile:

#3

This is going to depend on so many things, and it’s going to be more up to what fits into your brain instead of what other people think you should do.

Some common approaches are:

Use a grid. Think of Pac-Man (where the level and the player are both on a grid) , or Mario (where the level is on a grid and the player is “on top” of the grid). This also works for top-down games like Pokemon.

Use level objects. Think of how 2D physics-based games work, where the level is composed of different shapes put together. The player itself is just another shape that interacts with those other shapes. This is pretty easy if you’re using a physics engine.

Use pixel-perfect terrain. Think of how a game like Worms works, where you can blow holes into the terrain. A lot of novices go this route because it seems simple: you “just” make a grid where each cell is a pixel, and then you “just” use boolean values to represent whether that pixel has terrain there or not. This might sound simple, but it’s very processor-intensive and is overkill for a lot of games.

Use vectors. If you can translate your game into a series of lines, then you just need to do collision against those lines. You could go simpler and just use the height of a single line at a time. A lot of infinite runners go this route.

These are just off the top of my head, and there are probably a ton of other options. There isn’t a single best approach, especially for something as broad as translating physical art into game data. I suppose you could write a program that takes a scan of the art and outputs a data file, but again, that’s going to depend on so many things: What does the art look like? Is it black and white, or colored? What do those colors mean? What type of level design are you going for (grid, pixel-perfect, something else)? How are you rendering all of this? (You don’t actually have to answer any of these questions, but they are what you should be asking yourself.)

#4

Not completely sure I get your question 100%, but I’ll try…

So, if I understand correctly, you want to have your levels drawn out, as example, on paper as a large image that could be scanned in?

Well, there are programs like tiled, overlap2d and others out there that can be used by tiling or building the levels… personally I use tiled.

With tiled, you could take an image drawn out however, and put that as the back ground and then using the polygon tools to add the polygons of the level that will be the collision layer which would be a reflection of the level as its drawn out.

In that way there would be a separation between the graphics of the level and the physics layer of the level.

That’s how I’ve been working with the project I’m working on, in that I can program the physics responses / movement of the terrain, then separately work with the graphics… then when it comes to levels I just draw the level out how I like and then add the polygons for the physics over the terrain and put each part in its correct layer (ie; moving terrain gets linked to a polygon in the moving terrain layer, same with one way platforms, same with enemy spawn points, etc…)

I haven’t really worked with overlap2d, but it seems that comes more integrated with box2d in that sense of being able to lay out levels with how you want them to look as opposed to how they can be tiled together.

Hope that helps a little bit.

#5

Everyone, thank you for your quick, and helpful feedback (especially given the vagueness of my question). bmancfly, I hadn’t considered that approach; great stuff thank you. I am a bit green so I can’t be sure of the accuracy in saying this, but I believe my project will be “grid based”. Having an image as a background and setting up appropriate collision zones might be the route that I end up taking. That is a vast improvement over what I had in mind originally.

To help in my understanding: (this is to princec or anyone really) is tile-based, synonymous with grid-based?

I can at least say for certain, that the layout of my game and the movement within will be similar to the Gameboy Pokemon games.

#6

Here is how I do this , initially I setup an enum storing each obj/tile type with names and sprite positions along with an ID for it. Advantages of this? an object can have the same function and interaction however it will have a different appearance and can have a different name , this can of course be expanded for other things like bounds.
For instance my enum class looks like this :



public enum tileid {
	SPACE(new space(),"aaa"),
	METAL_WALL(new metal_wall(),"a"),
	METAL_FLOOR(new metal_floor(),"b");
	public tile type;
	public String id;
	tileid(tile t,String letter){
		type = t;
		id = letter;
	}
}

For loading the world it stores a list of all the ID’s next to their corresponding obj/tile and then iterate through a string which stores all the map data and create this.
Here is the code for loading/saving the map:


public void save_world(){
		String output = "";
		int x;
		int y;
		for(y = height - 1;y >= 0;y--){
			String x_output = "";
			for(x = 0;x < width ;x++){
				String y_output = "";
				tile t = world[x][y];
				if(t == null){
					y_output = "aaa";
				}
				else{
					obj[] objs = t.get_items();
					y_output = get_tile_id(t);
					for(obj o : objs){
						y_output += "#";
						y_output += get_obj_id(o);
					}
				}
				if(x != width - 1 ){
					y_output += ",";
				}
				x_output += y_output;
			}
			x_output += ";";
			output += x_output;
		}
		System.out.println(output);//the actual map
		
	}
	public void build_world(){
		String file = map_file.gettext("./src/com/maps/map1");
		String[] rows = file.split(";");
		int x = 0;
		int y = height - 1;
		for(String row : rows){
			x = 0;
			String[] columns = row.split(",");
			for(String column : columns){
				String[] point_data = column.split("#");
				boolean tile = false;
				for(String data : point_data){
					if(!tile){
						tile = true;
						tile t = getnew(tileset.get(data));
						if(t == null){
							t = new space(new Vertex2d(x,y));
							
						}else{
							t.init(new Vertex2d(x,y));
						}
						add_tile(t);
						continue;
					}
					obj o = getnewobj(objset.get(data));
					if(o == null){
						continue;
					}
					o.init(oh,new Vertex2d(x,y));
					add_obj(o);
				}
				x++;
			}
			y --;
		}
		for(x = 0; x < width;x++){
			for(y= 0;y < height;y++){
				if(world[x][y] == null){
					add_tile(new space(new Vertex2d(x,y)));
				}
			}
		}
		clear_paused_lights();
		update();
	}

So how does this work? Lets start with loading the world first , the code initially iterates through the input string and splits it into individual coordinates (each tile/obj has exact world coordinates) with rows being defined by ; and each individual index being split by , . This also stores items and it does so by splitting them from the tiles with #.

For example a world that is 4 by 4 with tile a on the top row and tile b the rest of the map with each alternating index storing an item with ID c would look like this :


a#c,a,a#c,a;b#c,b,b#c,b;b#c,b,b#c,b;b#c,b,b#c,b;

It’s quick it’s dirty but it does the job and doesn’t require serializable.

#7

Based on this, the Gameboy pokemon games, like FF1 (nes) are grid based maps with grid based movement… as in, you push up and the player moves 1 square up. This will be the simplest method, except, it seems that you would want your hand drawn maps to be hand drawn TILES, which, an approach like @Icass seems like it would be a good idea.

Collision detection in such a system is pretty simple, just “isTileBlocked” type of a routine.

I could be wrong on this part, but tile based and grid based, IMO, are similar concepts… grid based I take to mean that everything happens within a grid square, a player cannot be at 1.2x, 2.5y. Tile based, again, IMO, could be something like Zelda (snes) or ninja gaiden or megaman, where the maps are built of tiles, but that is just for the map layout, where the player movement is only restricted in movement by walls or other obstacles.

And, just a cautionary tale, since you seemed to like the sound of what I described on how I had decided to proceed on the first project that I intend to eventually release… I was unhappy with the idea of square maps, I wanted there to be more natural terrain of hills and slopes, etc… so, I went with the approach of using polygon defined terrain.

This has caused ALOT of headaches over the months, with concepts like collision detection that needs to determine if collisions happened with other polygons of different shapes, getting the player to walk along the terrain even when angles change instead of just following the ramp through the sky, etc… also, considerations need to be made because a person walking up hill will be moving slower than a player walking downhill, and will be impacted by the actual angle of ascent / descent.

On the other hand, once I get the system built and working, then the process of building levels will be greatly simplified because all the heavy lifting is handled in code.

I only say this so that you don’t eagerly decide that what I described was good, not that it’s bad, it’s just ALOT of extra work that can be avoided simply by sticking with a grid based map. Especially when you consider that in programming, I can’t imaging that I’m a whole lot less green than you are.

#8

Thanks again @bmanmcfly and thanks for the implementation @lcass. After a little bit more researching I found this which I think may be of use: http://www.mapeditor.org/

It saves tiled maps to a tmx file which can later be read in by Slick2D’s TiledMap class. At that point, based off of what I have read I would just have a collision layer on top of that with some bounding box’s corresponding to tile’s coordinates with a property like “blocked” or something. For this project I am not really shooting for pixel perfect collision accuracy.

#9

Actually, with tiled you can do better than that…

Tiled will allow you to define your tiles with custom properties (like blocked), then whenever you place your wall tile it will be defined as blocked, which you can then read from the tmx file.

It can also be used to add animated tiles, breaking tiles, etc…

For a simple tool, it’s got a good variety of functions and uses.

Also, there are many tutorials on youtube to get you acquainted.

Good luck.

#10

Seek out Tiled and you will need a converter which will convert the generated file into a format you want to support (yes, make your own format). Tiled is great. You will just need to support their crappy file formats available. I always translate the format to my own .map file, which is of course minimalized to what the core needs.

If you are looking to do pixel perfect level design, I would just draw a Texture and use the ALPHA channel - no booleans needed directly for this method, but you will have a backed table of data-less pixels, which ofc could be boolean, because you should update a table to make pixels invisible so that the shader can [icode]discard;[/icode] them. As for vector graphics, I have no experience dealing with them. You could create your own file format and add another file channel (photoshop could suffice) and strictly use it for this purpose if you desire alpha in your terrain (multi-layer terrain?).

#11

I hadn’t even considered making a custom map format, I’m lazy and just use tmx, something worth looking into.

Why I replied is about vector graphics; using vector graphics natively, as in svg files, with libgdx at least, is not directly supported… what I’ve done for myself with vector graphics is to draw out the graphics, then convert them into appropriately sized jpg or whatever files, and adding those. From what I’ve read thats the easiest way about it, and doesn’t require the frame by frame rendering of each vector and the regions…