LÖVE

Bridges and large room in action

As you should be able to see in the picture, the player can walk underneath and on top of bridges. The bridge even casts a shadow (a cheap sloppy shadow, but a shadow none the less). The picture also shows the large room that I mentioned earlier (a block of 4 rooms).

Invisible "Bridge-Start" markers indicate when a player is transferring onto a bridge, and "Bridge" markers then indicate which area is considered the bridge. While on top of a bridge, the player renders in front of all foreground objects.

Player movement changes

You can now walk around while holding out your sword and keeping it charged up.

Wall tapping

You can now tap the walls with your sword, to test if the wall is weak. Breakable walls make a hollow sound when tapped. Secret doors do not make a hollow sound, it only works with walls that can be blown up.

Improved door rendering

Doors now render through the sprite batch, instead of being directly rendered to the screen. This means a big improvement in performance, plus the doors no longer tend to shift a few pixels when the camera moves.

Improved background object rendering

Background objects, such as doors, vases, pressure plates and buttons, are now refreshed with a call to a separate draw function. This means that not everything on the screen is refreshed when a background object needs to be animated. For camera transitions, the game still refreshes everything (as it should). But overall this is a bit more resource friendly, and clean. We don't want to redraw the entire scene if we don't have to.


(^ I'm open to suggestions regarding the above problem)

Fully functional sub screen map

Up till this point I had to rely on the mini map for everything (which draws only a portion of the map, your immediate surroundings). But now when you go to your sub screen, you can see the entire map. This also revealed that when the game generates a dungeon, it doesn't often fully utilize the space that was made available to it. Sometimes more than half of the available space is left unused. Obviously this needs to be be addressed. And I've thought of two solutions:

Insert black rooms

If I randomly create black-rooms that the crawler must go around, this will create more space in between the corridors. Right now the dungeon is very clumped together, like a massive block. I want it to be more like an octopus. Of course it only makes sense to have black-rooms where the crawler can run into them. So maybe I should first run the main crawler (which builds the main corridor from start to finish), then place random black-rooms adjacent to it, and then run the mini crawlers(which build the other corridors).

Build more than one floor

I've been thinking of adding secret floors to the dungeons. Perhaps when the dungeon uses less than half of the available space, it should create a warp to another floor, and then continue building there. I've already added a floor-attribute to all of the rooms to facilitate this.

Future ideas

A few times I noticed that the dungeon sometimes creates a large room, that had no doors to the outside on one side of the room, which looked really odd. Imagine a large room that is the size of 4 rooms. It only has doors to the east, but no doors to the west, north or south. So basically the entire western half of the room is pointless.

While I love the randomness, I don't want players to think that it looks random or pointless. So I think that maybe I should create alternate large room types, for those situations. Perhaps a special type of large room, that is fully decorated on the western side (a throne room of sorts), yet leaves the eastern side open for door placement? And obviously then I'd have to create variations for the other directions as well.

Tiny update

The player can now pull objects, and lift vases. Unfortunately you can't lift them over your head and throw them yet, they kind of just disappear. But that will be added later this week (hopefully). You can also pull walls and other objects, which is completely pointless. But you will see a neat pulling animation when you do so. Lifting objects is kind of tricky. The game checks if there are any vases in front of you, according to the collision. It then changes the collision to a regular floor, and removes the vase graphic from the background overlay.

The next part is to then render the object that you've grabbed, over the head of the player, while the player switches to a new animation set. Any action buttons at that point, should make the player throw the object. However, that is when the object becomes a projectile. So there's about three stages to this simple gimmick. And its a lot more complex than it seems at first glance.

I'll also have to update the projectile code, so that objects can move in an arc.

Cool project, pretty interesting to read about what you've added and how you did that.
Keep rockin' !

I want to play this so bad DX, It's like taking the best part of zelda LTTP and expand it x10.
Keep up the good work!

Thanks everyone for taking an interest in the project!

Small update again

Warps are now working. The game looks for the longest chain, and places a mini boss room at the end, with a warp back to the entrance. I don't really have any fancy shader effects going on yet. So now the screen just fades to white, and when it fades out again, you are standing at the entrance. It also places a warp-exit tile at the entrance.

I'm thinking of also adding warps from one side of the map, to the other. But I'm not yet sure how to implement this. Because I don't want warps to just bypass all of the locked doors that the dungeon generates. Ideally, the warp leads to a section of the dungeon that you could otherwise not reach.

Perhaps the latter only works, if I create the warp zone along with a new chain. Here is how that might work:

The dungeon creator starts in an existing room, where it places warp entrance A. It then connects that warp to a random room outside the level, and starts creating a new chain of rooms from there, where it also places warp entrance B. However, I don't want the level to become a disjointed mess. So I think it's best if the new chain of rooms is adjacent to the rest of the level. I just got to make sure that it isn't just one corridor. So other crawlers should be able to start from one of the rooms outside the level too. I just got to make sure that the topology remains consistent, in regards to keys and locked doors.

The art style

A friend of mine is a really good graphic artist, who has done graphics for games before (and he's an ex colleague of mine). He did a quick paint over, to create an impression of what the game could look like. He also pasted in some screenshots from other games, which were his inspiration. You'll probably recognize Dragon's Lair, Plants Versus Zombies and Metal Slug in there. We're thinking of going for a slightly exaggerated cartoony style, with a lot of humor. We talked a bit about giving the rooms more purpose. In classic Zelda, dungeons are just empty rooms and corridors. But I'd like to see actual rooms with a purpose, such as a study, library, kitchen, or prison. So we'll probably create all sorts of furniture to dress the rooms with. I'd like this to be the ultimate dungeon crawler experience, with nasty traps, devious secrets, fiendish monsters, and lots and lots to explore.

Item throwing is working!

The player can now lift up vases, and smash them. First you must push against an object, and then hold the attack button. This makes the character grab hold of the object instead of swing his sword. Then, while still holding the attack button, press in the opposite direction. This makes the main character pull on the object. The game then checks if the object in front of you is a vase. If it is, you pick it up. If it isn't, the character simply does a pulling animation.

As explained earlier, the game updates the tiles and the collision, so that the vase is no longer there. The vase is rendered above the head of the character (using the same code that makes items from chests appear above you), while the player switches to a different move set for carrying an object. While this move set is in use, any attack will make the main character throw the object, and switch back to his regular movement. The vase when thrown, is a projectile. It spawns the standard break effect upon 'death'.

Bow strafing is working

While you are charging your bow, you can now also move around. I changed the way in which arrows are fired, so that they are now only fired upon release of the attack button. This allows you to charge up an arrow, without wasting a normal arrow first. The idea is to allow the player to move around while charging his bow, for that charged shot right on the weak spot of a boss.

The combat system

The more I work on the weapons, the more thought I need to put into the combat system. I want a combat system that has more depth than Zelda. And I want there to be very good reasons to switch to a particular weapon during a battle. I also want to remain consistent. So I think you should be able to charge up every weapon, and every weapon should have a special role in combat.

So how do we make each weapon unique? Well I've been thinking of various effects that attacks can have. Weapons basically differ in:

-Attack range (short,moderate,long)
-Hit radius (direct, aoe)
-Damage
-Effect (stun,shieldbash,shieldbreak, poison, burning,knockback)

Attack range, is simply how close you need to get to an enemy to hit it. The normal sword attacks are close range, but it will have a charge attack with a moderate range, which ignores shields, and knocks them back. The bow is obviously long range, with low damage, but a high firing rate. And its charge attack could have a stun effect with high damage, but low firing rate (because you need to charge it first). Likewise, I will be adding a new weapon called the flail, which hits enemies surrounding the player with a wide AOE effect, but has a moderately ranged charge attack that can permanently destroy enemy shields, and knock them away.

So picture this:

You face a swarm of bats, so you swing the flail around to prevent them from hitting you from any direction.
You face a large group of charging enemies, so you spam your arrows to hit them all and keep them at bay.
You face a tough opponent with a shield, so you first break his shield with a charged attack from the flail, and then spam your arrows at him.
You face a group of strong enemies, so you charge up your sword, and knock the group apart.
You face multiple strong opponents, so you first poison them, or burn them, with a magical wand, and then finish them off with another weapon.

This is the sort of combat I am thinking of. But this means that weapon swapping should be quick, and that each weapon must be balanced. No weapon should outclass another, and each one should have a unique role to play in combat.

Better level transitions

The game now fades to black upon leaving the level, and fades back in after loading the next dungeon. I also fixed some crashes regarding the player going out of bounds. Currently an out-of-bounds should always prompt the game to immediately fade out and build a new dungeon. I just have to be careful that the game never gets stuck in a build-loop. But hopefully that possibility has now been eliminated.

All hail the amazing overpass

I've added four new room types. The horizontal and vertical overpass, and the horizontal and vertical drop down overpass, with a balcony you can drop down from. This new room type is an amazing addition to the dungeon generator. Here is how it works. If the crawler is creating a new chain of rooms, but gets stuck against other rooms, then it checks if it can skip over that room. For that to work, the room targeted for an overpass is not allowed to be a part of the chain that we're building, and there must be an empty room on the other side. It then creates a bridge to the other side.

If the room that we're skipping over, also has an origin that is lower than that of the chain we're building, then the player is also allowed to drop down. It will thus create a variant of the overpass that includes a drop down spot.

The code isn't yet perfect though. On plenty of occasions I've seen the dungeon builder generate paths that would put an essential item in a spot where you could not possibly get to. So I need to make the rules for building an overpass more strict. Because you should always be able to complete a dungeon. I suspect this problem lies in the way the code selects a starting point for a new chain of rooms.

If I manage to fix the problems, this new room type will actually solve a lot of problems. It will allow more meandering of the tunnels, provide more shortcuts, and thus reduce backtracking. I also like having rooms that give a hint of what the rest of the lay out of the dungeon is like. When you enter a room that has an overpass, that makes you want to seek out the origin of that route.

This keeps getting more and more awesome each post. I love your dev log and I really, really want a playable demo.

Thanks for keeping track of this project, and taking an interest!

BTW, I may have tracked the issue that was causing invalid room formations. It seems like the crawler may have been retracing its steps when building an overpass.

Basically, what I think it was doing is this: It starts at a chain of rooms, and creates a new room adjacent to it, to form a new chain. It creates a door on both sides, so that the two rooms are connected. However, when building the next room, it doubles back the way it came, and thus overwrites the door that it made. So now you're stuck with a door up on a bridge that no one can reach, with a dead end on both sides of the bridge. So I've added an extra rule, that makes it impossible for the crawler to do a 180 turn.

Now you may be wondering, why was the crawler allowed to do this in the first place? Well, in essence the issue never came up in the normal code, because the crawler always expands to an adjacent empty room. But since the overpass is an exception to that creation method, the problem was introduced where it didn't originally exist.

EDIT:

It seems this problem is a little bit more persistent than I anticipated. I suspect that perhaps the crawler does not yet remember what direction it came from, upon starting a new chain. This would explain the doubling back problem. So I'll now also add a check to see if the room we are passing over, already has doors in the direction we're heading. Because I don't want doors being overwritten.

I've been putting the code to the test a bit, and made some screens of the various mazes the dungeon generator comes up with. I saved screenshots of only the most interesting mazes that had the new overpass in them (which were about 1 out of 4 dungeons). So the overpass isn't extremely common, but that is not unlike the long hallway or the large room. Sometimes you'll see two or even three overpasses spawn in one dungeon. And they are often close to each other, for what ever reason. You'll also notice a nice distribution of all the colored doors. And these new rooms also make the lay out of the dungeon a lot less predictable, since rooms can now overlap.

A: I think figure A is the ideal type of maze. There's a lot of tunnels that break off from the main maze, but they don't go on for too long. Not only did it spawn three overpasses, but also one long hallway, and three large rooms! (which must be a new record) It also has plenty of open space where secret rooms can spawn. And it would not have surprised me if this particular maze was stuffed with secrets. This is what I like to see! The three large rooms are a very rare thing, although it looks a bit odd.

B: This one has a cool uneven shape. I like how a bit just wanders off to the west. And its a fair bet that one of the rooms of that fork at the end, is the so-called special room type. It also has three overpasses.

C: A bit compact, but not bad. There are some meandering tunnels, but I prefer more spaces where secret rooms can spawn naturally.

D: This one was oddly shaped like a face. None of the dungeons need to resemble anything, but I thought this was interesting.

E: I like it when the game spawns these little open spaces, which no doubt will contain secret rooms.

F: This one has some nice formations that loop back on themselves.

G: These sort of flat dungeons are interesting to look at, but aren't usually as interesting to play.

H: I like the open spaces, which allow for secret rooms. But this dungeon does show the phenomenon of having this sharp 90 degree corner to it. According to the map layout, the dungeon isn't even all the way in the top left corner of the map, so there's no reason for the game to do this. I suppose it is simply a random occurrence, and random stuff is fine. But I prefer dungeons that fan out more. I also dislike how it leaves so much unused space in the bottom right. Fortunately the player will not notice all this wasted space.

I: Excellent placement of the long hallway in this one. But I dislike the long row of vertical rooms in the bottom left part of the maze. These are the sort of room formations that usually also get merged into long hallways. I suppose it got disallowed because there's a T-junction in the middle of it. There's some good meandering though, and some open spaces where secrets can be spawned.