Dark&Under - Level Designer

Games
#1

The Dark and Under Layout Editor allows you to create or modify custom dungeons for the ‘wildly popular’ Dark and Under game.

You can download the source code here > https://github.com/Garage-Collective/Dark-And-Under-Level-Editor
Or get a Windows Installer here >https://github.com/Garage-Collective/Dark-And-Under-Level-Editor/tree/master/distributable Copy the files into a temporary directory and run the setup.exe.

Building a new set of dungeons is simple:

Step 1: Define tiles

LevelEditor01
LevelEditor01.png918×620 36.3 KB

Step 2: Create levels

LevelEditor02
LevelEditor02.png918×620 51.6 KB

Step 3: Set enemy and player defaults

LevelEditor03
LevelEditor03.png918×620 69.4 KB

Step 4: Fix any errors

LevelEditor04
LevelEditor04.png918×620 33.7 KB

Step 5: Save the resultant configuration (File \ Save) as MapData in the \src\Levels subdirectory of the game.

Step 6: Play!

Limitations:

• Maximum number of tiles: 20
• Maximum number of levels: 10
• Maximum level size: 15 x 15 tiles / 225 x 225 cells.
• Enemies per level: 30
• Items per level: 30
• Doors per level: 8 (one must be a door to the next level)
• Memory. Even though you can create 10 maximum-sized, fully-populated levels using the designer, you will quickly run out of memory when you attempt to compile the application.

Design recommendations:

• Small dungeons can be just as challenging as large ones.
• Use ‘self-locking’ doors to promote inventory management. If there are a number of keys or potions on one side of a self-locking door, the player may need to pick up items and move them to the other side of the door without using all of the keys.

Hints and Tricks

• The outside perimeter of a maze will always be solid regardless of the tile design.
• Interior gates and level doors can be placed over the top of an existing wall or in a blank spot.
• Level doors should be placed in an alcove with walls adjacent to the left and right (the game didn’t have enough space for the many images it takes to render the door both open and closed and various distances).
• Maps are always rectangular. If you add a tile that increases the width or height of the map, the ‘blank’ locations in the new row or column will be defaulted to Tile 0.
• Allowing users to save a game adds additional code and reduces the space available for dungeons. At 958 bytes it’s a killer! I may revisit the code looking for space savings …
• Allowing the user to see a large map helps them navigate large dungeons. However, it ass 298 bytes.

Challenge to You!

Build a good set of dungeons and we will publish them with the game. Your name will be up in lights and you will receive the thanks and adulation of the team and the public!

4 Likes
Dark&Under - A Dungeon Crawler
Playdate Releases Pulp
Learning resources for C#?
Simple(?) inventory and item menu
#2

That’s the tool we used to build the current levels in-game: it works well!

2 Likes
#3

We have recently upgraded this tool inline with the new version of Dark and Under. As part of that the level data has changed making the old and the new incompatible. If you have designed levels, simply back up your MapData.h file and upgrade both the game and level designer.

Then simply edit the MapData.h file using notepad or similar.

The old level data looks like this:

const uint8_t PROGMEM tile_00[] = {
0xFF, 0x81, 0xED, 0x05, 0xF5, 0x95, 0xD5, 0x05, 0xDD, 0x85, 0xB1, 0xA5, 0xED, 0x01, 0x7F, 0x7F, 0x40, 0x5E, 0x52, 0x5A, 0x4A, 0x6A, 0x02, 0x6E, 0x42, 0x5E, 0x54, 0x55, 0x45, 0x7F, 
};

const uint8_t PROGMEM tile_01[] = {
0x7F, 0x55, 0x05, 0x7D, 0x41, 0x5D, 0x15, 0x54, 0x57, 0x51, 0xDD, 0x05, 0xFD, 0x01, 0x7F, 0x7F, 0x41, 0x5D, 0x57, 0x50, 0x55, 0x5D, 0x01, 0x7F, 0x40, 0x5F, 0x50, 0x5E, 0x42, 0x7F, 
};

… and so on.

Combine the data into a single tiles[] array as shown below:

const uint8_t PROGMEM tiles[] = {
0xFF, 0x81, 0xED, 0x05, 0xF5, 0x95, 0xD5, 0x05, 0xDD, 0x85, 0xB1, 0xA5, 0xED, 0x01, 0x7F, 0x7F, 0x40, 0x5E, 0x52, 0x5A, 0x4A, 0x6A, 0x02, 0x6E, 0x42, 0x5E, 0x54, 0x55, 0x45, 0x7F, 
0x7F, 0x55, 0x05, 0x7D, 0x41, 0x5D, 0x15, 0x54, 0x57, 0x51, 0xDD, 0x05, 0xFD, 0x01, 0x7F, 0x7F, 0x41, 0x5D, 0x57, 0x50, 0x55, 0x5D, 0x01, 0x7F, 0x40, 0x5F, 0x50, 0x5E, 0x42, 0x7F, 
..

Where each line is the data from a single tile. Remove any tiles that did not have data to begin with.

If you have any problems with this, shoot me a copy of the MapData.h file and I will do it for you!

1 Like
#4

Why are levels built out of tiles? Was that a RAM concern? If the whole level is in flash though why not just always reference it from there with only live objects living in RAM? Seems then you could have HUGE maps… or was the plan actually that tiles would be reusable and that would be a key part of some dungeons?

#5

The maps aren’t loaded into RAM, they’re all in progmem.
Only enemies, items and doors are loaded into RAM.

The ‘tiles’ aren’t the individual tiles that the player stands on, they’re metatiles - whole sections of map.
(I’d call them rooms, but they aren’t even that really, since the whole thing is a maze of corridors.)

Also the metatiles are stored per dungeon, not per floor, so each floor can use any of the metatiles,
and the metatiles can be rotated, so each metatile is effectively 4 metatiles (they’re big enough that it’s hard to notice the rotations while playing).
This allows the maps to be much smaller than they otherwise would be.

Have you played all the way to the end yet?
Most people find that level 3 is more than big enough, and that’s only 5x4 metatiles.

#6

Yeah, that part was clear, I was just asking WHY.

Ha, I had this idea just the other day for a “fixed map” game… where each level was static but every time you played you’d get a random rotation/transform of some type applied which would give the game more playability.

No. I can imagine though.

#7

Because it uses less memory.

#8

And possibly would be perfect to store even more maps using a flash chip for a sequel…

3 Likes