Saturday 31 March 2012

Dungeon generator examples

Testing with three rooms it's already clear that there are problems.


Doors are not created when there is cavern outside it. It's easy to fix I guess, but might cause confusion if two separate caverns are next to the room. The possible solution to that is giving caverns also a unique mask id.


Here is another run with the same level theme. The long narrow corridor is actually a passage, which is a special kind of corridor. It seems to have problems to turn around without backing up and generating extra dead end blocks, but it should be easy to fix.

Return to the caves

I have changed my perspective from tweaking the source code to more practical development. It means I could now get stuff done. I've started from level creation which has lot of problems. The building blocks are there, but needs to be connected to create levels the way I want. I think the level generation has been difficult to me, because I was thinking in too complex way. Creating a good, consistent town level is still a complex task, but anything other than that is easier. At least I hope so.

Monday 26 March 2012

Checking level code

Sometimes when looking at the source code everything seems a huge mess, but then there are moments of clear vision of how to proceed. I guess today was more of that clear minded side. I'm going through functions of Level class which is huge, possibly the biggest class in the project. Most of the problems come from the fact that stuff depends on other stuff. That's why I think it's essential to learn how to write modular code (as much as possible) because then different parts can be implemented without having to worry about how compatible they are or will be in the future (when some other part changes its shape).

It's not that hopeless. The source code is getting really solid actually and maybe some day everything will just fit together.

Monday 5 March 2012

Rooms and houses

Working on level themes and needed a special type of room. When I looked at the room routines there was room for improvement. Rooms like many other parts of the source code have simpler data type classes like Room_Type and Room_Shape. Placing decisions (data) in small simple data type classes has been really good for the generic readability and keeping the source code clean.

The actual Room class is quite bad actually. It's a result of not planning the stuff clearly. However I think it will be useful when problems are fixed. It helps to think rooms as single units that can later possibly form houses. For now I have to think only how singular rooms are created and connected. There is plenty of things to solve and there are lots of room types with all different kind of creation methods.

Sunday 4 March 2012

Randomness

The requirement of randomness is one of the big questions in roguelike development. How random you can or should get? When you look at a classic like Nethack you'll notice that it's not that random after all. The structure of the game world is quite static with designed locations that don't often change.

I've struggled with the same requirements myself. It's difficult to produce random content and still create something that's themed. Like level themes for locations in the dungeon. It looks like the best you can do is offer some random changes in the typical theme content. But you simply can't get too random in the context of the theme. Dry sand levels can't be populated with winter wolves or some other cold environment creatures, if you try to stay in theme based content.

Then again, does it have to be that random? Well, mainly it does. There are good examples of static content that quickly becomes tedious if you replay often. Something like the main "village" in Angband/Moria or Terinyo in ADOM. Maybe there could be couple of different starting points to reduce that kind of dull, repeating experience. Something like several entrances to the dungeon, each leading to different part at first. Or maybe you could sometimes start from deeper levels with better equipment, like in middle of the story.