Labyrinth: a hack-and-slash with a shifting map

[Lukas_Palmer]

A few days ago I started development of a project called Labyrinth:

Labyrinth is, at its core something along the lines of a hack-and-slash or a dungeon crawler. The game takes place in a procedurally generated, underground world, hence the name. The world is set up as a grid of interconnected rooms. Some of these rooms will be empty, ideal for some sort of ‘base’; players will have the ability to build simple structures, although terrain won’t be destructible. Some rooms will contain enemies, with a reward if all enemies are cleared. Other rooms will have a similar reward, but be more puzzle-oriented with terrain full of traps with the player having to reach a certain spot to gain the reward. Then there’ll be boss fight rooms, like the one I’ve built here:

The way I’m designing the game, the workflow will require the player to navigate back and forth between different locations; that’s part of why I’m allowing for the player to build structures for storing items and other things. To make things more complicated, there will be occasional “earthquakes”: the screen will shake a little, some sound effects will play or something; as this happens, some rooms will be altered: terrain may shift a little, and sometimes rooms will even cave in making it impossible to reach one side from the other! Other times, the rooms will change to become completely different types, such as an innocent puzzle room becoming a boss fight. The earthquake mechanic is meant to make the game challenging on multiple levels, both as a combative hack-and-slash and a disorienting maze.

Right now, the one room I have created is the boss fight room shown above. There’s already a system for moving between rooms, they’re just all the same. Right now I’m working on procedural room generation and life - as you can see, the player is just a placeholder sprite right now. I started out planning to work with a generic pixel art palette but this sort of dichrome (maybe trichrome in the future, also is dichrome even a word?) palette turned up organically.

Thoughts so far? Constructive criticism and suggestions are welcome! By the next devlog post I should have a boss enemy of some sort.

For anyone who’s interested, my twitter handle is @lukaspalmerdev.

[sven]

Very interesting! Looking forward to see how this develops, I liked the idea of base building in a dungeon crawler.

[Lukas_Palmer]

Yeah, I’m curious to see what kind of strategies players come up with based on the base-building mechanic!

[Lukas_Palmer]

Alright, update 1 to my devlog:

I’ve made a lot of progress on a low-tier boss:

Does the forum support .gifs?

Apparently it does, cool.

As you can see, the player and boss sprites and animations are rather simple for now; I plan on keeping the game pretty minimalist so I will be improving sprites over time, but most likely not adding a ton of detail. This boss is probably not going to move around the arena but instead used ranged attacks from the middle, as it is meant to be one of the first, if not the first, bosses. The bosses’s tentacles and underside will do damage upon contact and the player probably won’t have ranged weapons until later in the game, so the only course of action for the player will probably be climbing the vines and jumping on the boss.

I’ve also made three additional room types, which are visible throughout my recent posts on twitter.

These rooms don’t have much function yet and are not a reflection of what rooms will look like closer to release, but they exist.

In the next update, I’ll either be posting about the UI, more room generation, new enemies, or a combination of those topics. There is a lot of work I need to do as far as the combat system.

[Hanz]

there will be occasional “earthquakes”

I like this idea! Curious to see how it’ll work out.

[Lukas_Palmer]

The earthquake idea has some neat implications I think. The map technically won’t be infinite in the sense that if you go too far in any direction you’ll wrap around to the other side, but earthquakes will constantly be wiping away old terrain such as used boss stages and replacing that terrain with new features, so in that sense the world will be infinite.

[Hanz]

That gave me an idea, hope you don’t mind I share it here: you have your map of the total world and a viewport on the current location aka room. Outside the viewport there are several rooms.

Now when an earthquake occurs then the room splits: this can be horizontal or vertical) and another room part (of the map) is pushed up (or down).

Same on the horizontal parts; they can be pushed left or right. Basically you divide the room in 4 parts and depending where the hero is you can shift the room around. Hope this makes senses

It think it would even be possible to have the hero never leave the room but constantly change it around. But then it would be another game I suppose

[Lukas_Palmer]

@Hanz: interesting, but not quite the concept of this game. Neat idea though!

Just a quick update, not a full-fledged post: I released a (very) primitive demo of what I’ve made so far. Feel free to download it here:

Dropbox - Error

If you have any feedback, I’d love to hear it. I haven’t released any full-fledged games before so I’m looking for all the constructive criticism I can get.

[Lukas_Palmer]

Alright, update 2 to the devlog:

For quite a while, player physics have been pretty buggy. The player is, of course, kinematic, and the script that I’ve been running on it is quite similar to the endless runner tutorial’s physics. The main problem I’ve had is that the player is capable of clinging… into? the wall, which makes blunders like falling into lava easy to correct by jumping back up walls. Here’s the problem:

The player, while attempting to move to the left, is cutting slightly into the wall. This wouldn’t be a problem, except that the tiny corner of the tile below that the player hits is able to act as a support. I’m working on a fix for this, Defold’s debug physics feature has been helpful, I was suspecting some other issue with kinematic physics, being able to graphically see the normals made it easy to clarify the issue.

[Ragnar_Svensson]

How do you place physics? If you’re using a tilemap for graphics, you can use the tilemap itself as a collision shape in the collision object, which will stitch all neighbouring tiles together to cleverly avoid issues like that.

[Hanz]

I played the demo and I found this clinging to the wall fun
If you solve it you can keep the “problem” as a way to climb the wall.

[Lukas_Palmer]

I don’t use a tilemap, primarily so that I can have different collider types and more customization over tiles. Unfortunately, as you mentioned, not using a tilemap prevents me from stitching together the colliders to prevent the issue. I ended up fixing the bug in a little bit of a hacky way: if math.abs(normal.y) > 0.7 and the difference in the player’s x and the colliding tile’s x is above a certain value, I have the collision ignored. The player still doesn’t phase into the wall since it’s colliding with the sides where math.abs(normal.y) = 0. If the player’s collider was extremely narrow, this would have some complications, but luckily the player is wide enough that this hack solves the problem quite well.

[Lukas_Palmer]

@Hanz sorry, clinging to the wall is kinda fun, but it doesn’t work with the way the game is designed, so I’m removing that. Also the behavior is too unpredictable (sometimes it works, sometimes the player slips by) so it wouldn’t work that well. I might add wall jumping though, it’ll just be a little more refined than that.

[Ragnar_Svensson]

Alright, sounds good! Just in case you did not know, you can paint collision groups in the tile source (used by the tile map), which will transfer over to the collision shapes. But the collision object can only have one type of course, e.g. static.

[Lukas_Palmer]

Interesting, I was not aware of that! I’m most likely going to still use separate objects to allow for scripts to be attached to certain tiles if necessary, but that’s good to know!

[Lukas_Palmer]

Alright, update 3 to the devlog:

I’ve made a lot of progress in several areas:

• For one, the kinematic physics controller has been much improved. After I fixed the aforementioned problems with the wall, I also added a “terminal velocity” at which the player cannot move faster than. This fixes some problems that would occur in situations where the player fell long distances, such as the transition to a boss fight room from the drop room above it.
• The boss also can attack now: instead of directly doing damage, the boss will occasionally swing down towards the player, repelling them towards the edge of the fight platform and into the lava.
• I also added some graphical effects to the player; now the player distorts when respawning, jumping and contacting the ground.
• Proper physics have been added to lava. When the player falls into lava, a “splash” of lava particles appears where the player fell in and then the player shortly respawns.

Things I’m working on in the future:

• Code cleanup. The player and the boss have separate physics controllers, I’m going to make one unified “entity” script that can be extended on through responses to messages.
• Once entity code is organized, I can work on a generic “enemy” and also build experience and inventory systems.
• After that I plan to work on a global “map” of data on room types and some other information, which will give me a chance to test good ways to connect various room types and start working on the earthquake mechanic.

That’s a lot to do, I definitely won’t have it all done by next update, but i should have some progress.

[Lukas_Palmer]

I made a decent amount of progress today, so here’s update 4:

• There’s now a central entity script. This script governs entities’ kinematic physics colliders and handles a few other things such as deleting enemies that have moved out of range. It sends a few messages which can be used by extending scripts such as boss, player, and enemy scripts. A simple example would be making an enemy bounce by setting its velocity to <0, 700, 0> upon receiving the message for contacting the ground.

• There’s an experimental inventory UI. I spent a decent amount of time today creating it and fine-tuning it, and it seems to be coming along quite well. Here’s the concept for the inventory UI:

• Inventory contents are spread across the bottom edge of the screen in a sort of hotbar.

• This hotbar continues beyond the edges of the screen, and contains all contents of the inventory.

• The item in the middle of the hotbar is the one currently being used, and is magnified to show this.

• The player can tab between items using specified keys, maybe by scrolling at some point. The current keys are the left and right arrow keys, which will make sense by the end of the post.

• Over time, as the player’s inventory grows, it will most likely become somewhat difficult to manage with the hotbar. Instead of an “inventory” menu that pops up like most games have to solve this issue, the inventory UI can be switched into a different mode. When the up arrow key is pressed, the hotbar pops up into the center of the screen and curls into a circle. In this form, item sprites are scaled down enough that the entire inventory is visible.

• This ‘radial’ mode of the UI allows the player to view the entire inventory, as would a standard pop up inventory UI. The player can continue to switch the selected item in this mode with the left & right arrow keys, and also rearrange items by clicking and dragging them to group items that are often used one after the other.

• In addition to allowing the player to view their entire inventory, the radial UI mode also displays information about the active item in the center of the ring.

• The player will also be able to set numeric hotkeys by selecting items in the radial mode and pressing number keys to associate them, and then press those keys in the hotbar mode to select those items.

• Wow, it’s really difficult to explain the UI. Going back and reading that, I can understand it, but it’s really awkwardly worded. Sorry. When I took the concept and put it into code, I got some interesting results. Not everything I mentioned is implemented yet, namely clicking and dragging items to rearrange them does not work, hotkeys can’t be set yet, and there isn’t a detailed description of items. However, I did get the concept to work the way that I hoped it would, and it seems like it will be quite interesting to use once actual enemies, combat mechanics and items are created. Words aren’t working that well to describe the UI, so here’s a better explanation:

I should have some more progress by tomorrow.

[Lukas_Palmer]

Progress on Labyrinth has been a little slower than I’d prefer, but I’ve gotten a little progress done recently, primarily some map-related stuff. Nothing super exciting yet, but I laid the framework so I should be able to create some neat content near in the future. Update 5:

Until recently, rooms generated in a hard-coded, repeating pattern only useful for testing some features. There was a string of rooms that would repeat left and right, from an initial room through some basic obstacles through a stage for a boss fight. In order to give the game’s map the mazelike quality intended, there will have to be a wide variety of rooms with various types of connections. Part of the challenge of the game is supposed to be the navigation: on occasion some situations will require you to travel between several locations spread across the map, possibly requiring some creative manuevering around obstacles and barriers that you are not (or at least not at the time) able to pass. Also, there will be “depth” to the map: a separate layer of rooms will contain a network of tunnels that act as shortcuts between certain places. I’m not sure exactly what I want the function of these tunnels to be yet, so I’m experimenting with some different ideas. One possibility is that tunnels could be used as a strategically placed shortcut by players: using some tool, a player could create a tunnel between two rooms for faster and safer travel. Whatever the use of tunnels, they’ll probably be quite difficult to gain access to, with entrances perhaps being hidden in areas locked by keys obtained by beating certain bosses. As I mentioned from the beginning, earthquakes are going to occasionally alter the map, changing some rooms to connect in different ways to make navigation more challenging. I’m not to the point where I can start working on that quite yet, but I’m thinking about how that might work.

This is a very, very unrefined concept of what tunnels might be like in Labyrinth. Actual tunnels will probably have turns, connecting rooms vertically and having more smooth geometry than that example, as well as being thinner and more… ‘scenic’?

You probably noticed the small door accessible by a vine that was ignored: that connects to a room that’s a layer deeper ‘in’ relative to the tunnels as opposed to the core maze which is a layer ‘out’. I’m considering having a boss nested deep within the tunnel system, so I was testing how I might differentiate between layers if there are a decent (3-6?) number of them - I made the scene progressively darker with each layer ‘in’, so the interior of that room looks like this:

All of that being said, any suggestions, constructive criticism, or really any input, even if it’s just “that’s a good idea” or “that’s a bad idea” without any rationale, on the game mechanics and designs that I’ve proposed so far would be much appreciated.

[Hanz]

What do you plan to do with sounds? Already ideas?

[Lukas_Palmer]

I’m pretty new to the world of creating sfx/music, so I’m still trying to figure out what I want to do there. Probably going for a ‘retro’ style for audio.