Dag / Day 2: Videogame's Devlog - Dungeon Generation and Camera

Created Wed, 05 Jun 2024 22:24:00 +0200 Modified Wed, 05 Jun 2024 22:24:00 +0200

Day 2 - Dungeon Generation

My original idea was to make a dungeon game.

“Damn bro, you just started and you already want to make a dungeon game?”

Yes, I know, but I love dungeon games, and I want to make my own since ever. The most fun part of a dungeon game is the dungeon itself: the rooms, the corridors, the monsters, the traps, the inventory. Everything is random, everything is different every time you play, and that’s addicting.

But, let’s go back to the game.

It is time to make my hands dirty on the actual dungeon creation. Where do I start?

Well, I had seen a video a while back on procedural dungeon map generation. The idea was that first you generated rooms, then you generated corridors. I then decide to set a scary size for the map, like 300x300 because I think it is a good size for a dungeon.

Let’s move on the dungeon generator part: it is slow and has problems.

The idea is to generate the whole map first by defining walkable and non-walkable areas, the player (always a yellow square), draw a green square for each “non walkable square”, then I can move on to fill the entire map with monsters, items, and traps… you know, the usual dungeon stuff.

It works but… the problem is also that I can’t see anything this way, because everything is too big.

I find out about the existence of the game “camera” which serves just as if it were a separate and detached window to the game world. Very pleased about this, I decide to postpone the problem of optimizing things and make them faster until the next day, not before adding some small debugging controls (W and S keys, zoom in or out the view)

I also implemented a small collider with walls, that does not seem to work properly and the classic directional arrow controls for moving my yellow square around.

Here’s the result: Dungeon image at the end of devlog 2, with corridors very stretchy or clumsy