next »

[Derakon]

I've been working on a 2D exploration/platforming game in the Metroid/Castlevania style for awhile now, with the goal of having procedurally-generated levels. Progress on that front proceeded nicely until I got to the point where I had to figure out how to enforce needing a powerup to bypass some obstacle. Then I got a job and the entire project stalled.

Now I'm thinking of returning to the project and setting the whole procedural mapgen aspect to the side for a bit. I have most of the engine coded up, so why not try for a hand-made map instead? So I doodled this map. I'd like some feedback on the overall design. Note that it's not remotely drawn to scale, so here's the intended player path, as I see it:

The player lands on the far left side, and proceeds to the right. They encounter the moat, and are unable to jump high enough to cross it. Exploring more, they find the cave system underneath their landing zone (or perhaps they found this before the moat; either way), and find the high-jump upgrade. With this they can cross the moat and enter the base.

But whoops! A trapdoor opens beneath them, dropping them down into the abyss. They quickly find that they can't jump high enough to go upwards, and one of the passages they can reach is blocked by a solid barrier. They find a nearby room containing a boss and an upgrade that lets them break the barrier.

This lets them explore more of the abyssal area. To the upper right they find a room with magma pooled in the floor and a ledge they can't reach. Going across the shaft they originally fell down, they find a massive underground pool, which they can't navigate very well. However, they can make it to a room containing an upgrade that lets them move freely in water! And while they can't make it through the locked door at the bottom of the lake, they can go upwards into the moat they crossed over earlier on. They find a secret passage in that moat that they can now reach, letting them go back into the base.

This time they're able to explore more of the base. They fight their way across it, beating up some machinery and goons. Eventually they find the boiler room, which includes an armor upgrade that protects them from heat, and an elevator leading down into the abyss again. Now they can go through that hot room they found earlier, and down into a long corridor running beneath the entire sector. They fight their way through this, and eventually face down a boss to get some pitons. With these, they can climb along walls and ceilings. The door in the bottom of the lake unlocks, and they can now make it across the trapdoor in the base that defeated them so long ago.

From here, about all they can do is go up, climbing the mountain the base is built into. They proceed from the base into the aerie, an open, mountainous area with some tricky platforming. At the top, they face down a boss for a jetpack, which lets them fly! Now they have to traverse down a tunnel through the mountain, putting their new movement capabilities to the test to traverse several difficult rooms. This leads them back down into the base yet again, where they can fight the final boss of the game. Naturally he's a load-bearing boss, and the base starts collapsing, so the player then has to make their way out of the base and back to the landing zone so they can escape.

Does this seem reasonable? I've including a few nooks and crannies to hide non-essential powerups, and the actual maps should include more (in general, the maps are going to get stretched out and have more filler inserted; there's not really much actual exploration to be done as it stands currently). I don't want the map to be too small, but similarly it can't get too big or the project becomes unfeasible. As it stands I need to make tilesets and scenery for the following areas:

    * Landing zone
    * Cave beneath landing zone
    * Moat and watery abyss
    * Base
    * Magma abyss
    * Aerie outside
    * Aerie caves (possibly the same as landing zone caves)

That seems like a lot to me! Adding more zones on top of that will just make things harder. I've whipped up some simple tiles using Blender, and a function to import PNGs as if each pixel were one tile, which gets me something like this -- pretty clearly, I'll need to break up the obvious tiling of the terrain at some point.

Any feedback would be appreciated!

[Hempuli‽]

I'll comment more when I get home, but that (procedural?) map found from the game page is very very amazing!

[nihilocrat]

Procedurally-generated levels will give more variety and replayability than handmade ones ever will. Handmade levels will give more quality (maybe?) than procedurally-generated ones ever will. Take your pick.

One way to manage the powerups is to treat them, for algorithmic purposes, as "keys" that provide access to divided portions of the map. For each powerup, construct a map feature (like a pair of platforms where you can't jump from one to another without double-jump, and the second one leads to a new section of map) that would act like a "door". Now, very early in map generation, structure the gameworld in terms of these locked areas with "door" features planted in between them.

Depending on how linear you want the acquiring of powerups to be, you can add dependencies between them; the player must obtain double-jump before obtaining wall jump, because the wall jump powerup is a double-jump area. Therefore, in a wall jump area you can generate double-jump features and assume the player can traverse the entire area with no problems. You might even assign these areas a "level", placing more difficult enemies in them because you know the player is at a certain level of progression in the game.

I think it's a tricky, yet interesting problem, and definitely doable with a good deal of planning and testing.

Also, I notice in the example screenshot that there are some dead ends in the map generation. This is entirely okay; just be sure to detect these dead ends and put a treasure at the end to reward the player for exploring.

If you can't tell, I'm a little more interested in the tech aspects than the game aspects, but if you do a handmade map I'm sure it would turn out well. I'm interested to see the game whichever way it goes.

[Derakon]

Hempuli: thanks! Yes, that map was procedurally-generated. It happened to turn out rather nicely, which is why it ended up on the front page. If you're curious, here's broadly how map generation works:

 * The universe is partitioned into different Zones (like a jungle, a hot zone, a lab, etc.), each of which is further divided up into Regions (like grassy hills, or a boiler room) which map directly to tilesets. Zones and Regions have configurable entries for how high they should be placed vertically and how strongly they should be weighted (thus, the jungle zone tends to have a higher altitude than the hot zone, and within the hot zone, technological tiles are slightly more common than rocky caves). You can see the partitioning in the fill tiles of the map.
 * A tree is overlaid on the universe, generated breadth-first and ensuring that no limbs come too close to other limbs. Once its generation is complete, a few loop branches are added to connect nodes that are spatially close but have a large node-node distance in the graph. Each branch in the tree is associated with a different tunnel type (with different regions having different available tunnel types, like straight, staircase, zigzag, maze, room, etc.).
 * To generate tunnels, the branches of the tree are used as the basis of a spacefilling cellular automaton. This automaton expands cells outwards until they run out of life or encounter a cell owned by a different branch of the tree. This breaks the map up into a bunch of disconnected rooms that looks like this. Non-leaf nodes in the tree then create open space around them to connect the rooms together.
 * The different tunnel types kick in to personalize each tunnel. Staircase tunnels fill themselves in, mazes are generated, etc. Note that some tunnel types also have different behavior when seeding the spacefilling automaton (for example, the room type uses unusually large seed values so that its cells can expand further before naturally expiring).
 * A Marching Squares algorithm walks along the walls, looking for places where it can fit in platforms. This is intended to ensure that the map is fully accessible. A variety of different platform placement systems are used depending on the topography and the tunnel type (for example, a patterned platform placement is used for straight vertical tunnels).
 * Finally, each cell in the map is examined to determine which kind of tile should be placed on it. Placement is based on the occupancy of its neighbors, with up to twenty different tile types being available. At this time, background scenery objects can attach themselves to the terrain (e.g. trees in the jungle, which can attach to any flat-topped tile, have a chance of being placed each time they find appropriate terrain).

Nihilocrat: I agree with you that procedurally-generated maps will give more replayability than handmade maps. That's why I started out with procedural generation, and made a lot of progress in that area, I might add. However, it's looking like it'll be a fairly long time before I can get an interesting playable game with procedural map generation, hence the shift, for now, towards handmade maps. I'd always intended to support handmade maps, anyway; they lend themselves to an "artistic vision" more readily, in my opinion. My thinking is that by doing this I can find out what items are missing in my overall engine (e.g. I know I'm missing support for background images; currently all I have is a black background over which are overlaid various scenery items. My support for creature placement is also very crude right now, and there's no respawning). Those items can then later be integrated into the procedural mapmaker.

Additionally, I figure that if I can get a small, but complete, game out there, then that will create more interest in the game, and maybe I'll get some people interested in contributing.

I've thought about having set pieces that act as locked doors, like you suggested; my difficulty there is that I don't really want the game to be a bunch of corridors linking various set pieces together. There's also the difficulty of orientation: you can't put the same lock into a horizontal corridor that you can into a vertical corridor. The problem of course if that if I reject set pieces as locks, then I have to come up with a way, for each key item, to write a function to procedurally generate locks for that item. This is decidedly nontrivial.

[Paul Jeffries]

Your tree generation routine and what you said about needing a powerup to bypass certain obstacles reminded me of this article:

http://www.squidi.net/three/entry.php?id=4

Personally, I'd urge you to carry on looking at the procedural generation side, since what you've done so far looks very impressive and if you could get it working correctly it could really stand out.  That said, the hand-drawn map you have looks fine too.  Obviously though it's hard to judge how well it will all work without playing the game!

[Derakon]

Oh, the procedural mapgen isn't dead. I do plan to have a procedural game mode. But for now, I want to try my hand at traditional mapmaking. They both have their strong points, and they're both fun to do. I just needed a change of pace.

The article you linked is a good analysis of the general concept, but it's pretty high-level. My major stumbling block isn't analysis of the game map (I have a graph of the map, after all); it's figuring out how to procedurally generate locks that aren't literal locked doors.

[Hempuli‽]

One thing that I have found hard in metroidvanias is the balance between having a straight line to follow, and making exploration required. For example, when you get a powerup, it opens X new paths in the game world. However, to make the game progress, one of those paths has to lead to a new powerup, and the others either lead to some unnecessary but interesting areas, or "hidden" fun stuff. The problem there is that the game shouldn't feel too much like following a set path from node to node, but instead finding new stuff through exploration.

One of my earlier games had really a set path, and you couldn't quite much go anywhere before you had followed it around for quite some time. Which was terrible.

[Derakon]

Metroid Prime had an excellent solution to that problem. Each time you got a new powerup that "unlocked a door" somewhere in the game world, the game gave you about fifteen minutes to get to that door and go through it. If you couldn't find it in time, then the hint system activated (assuming you hadn't turned it off) and told you "Hey, you know that snazzy new ability you just got? You can use it over here."

This would, naturally, be fairly trivial to implement in this project too.