Teemu ARRP Diary 12/3

I was sick for a week, but I'm getting better. I rarely have flu to be honest, but it's often harder than usual when it hits. Must be my age, I'm old.

Last time I recall talking about the new level theme and new requirements for it. A generic routine related to that I have been programming is a path/corridor routine with a funny kind of twist. I had an idea to store possible door places into the path class when the path is crossing a room wall. Just a side note, the path itself is also stored, because then it's easy to find midpoint from it and make new paths from that location.

When door places are stored you don't need to find them later with another type of routine. The way paths cross the room's wall is finding possible door places in "automatic" way since the path has to cross the room it's travelling through. The routine isn't perfect yet, it has problems with corners of rooms, but I'm planning to fix that by making the path routine go around corners. Also, of course for this to work rooms has to have at least one space between them. So I might ditch the idea for close proximity rooms I had before. 'Small' rooms can be used for that since they can be attached to other features.

Winter is quite early this year. The first snow has already fallen, but the climate change has made winters unpredictable for the fall to winter transition time.

Is a roguelike user interface bad?

The user interface issue is more complex than it appears. Lot of players and even developers say that when there is a key for every command it's bad design. But is it? I think the answer is somewhere between extreme solutions. Less often used keyboard commands could be moved in a menu or something like that and there are many ways to reduce keyboard commands and make the user interface easier, because in many cases you can automate tedious, repetitive tasks. A simple example is open command (o) for doors, you could make the door open when bumping into it or remove direction key question if there is only one door near the player.

If the game has lots of commands then it can have a large number of keyboard bindings to them. I think it's not "bad design", it's just how it is. I've been following ADOM's development and difficulties it has with "new" players that possibly have never even played a roguelike. It's kind of hilarious to think that you would even try to make a complex roguelike more accessible to casual players, but I guess some people try it anyway when trying to reach the maximum commercial potential. Yet it may work, because a traditional UI of a roguelike could be improved for sure.

The reason why UI is so hard to get right is that it simply is a difficult problem that requires lot of thinking and design (=work) not copied from existing games which has been a kind of trademark in roguelikes. ADOM for example is very much like Nethack so it carries the load of Nethack's ancient UI. In attempt to keep the familiar ADOM experience for old players it could end up staying in some kind of limbo where too drastic changes are discarded as a possibility.

I'm not afraid to use lots of keyboard commands in my roguelikes, but there are those repetitive tasks which could be made easier somehow or even removed in some cases. A great way to handle these issues also is make them optional for people who actually like to perform them.

Teemu ARRP Diary 11/3

I'm working on a new theme and found out that the room creation has to be different than it is now. At the moment room spaces are destroyed by anything created on it like corridors. It's a simple way to make sure everything is connected. But the new theme requires that rooms are preserved, so... Luckily I have lot of experience from this type of creation schemes.

The way I plan to approach this is using "path point" locations for rooms and other places. When paths are created they are outside the room area and need to be connected with doorways. The search requires stuff like checking out existing connections (to avoid stuff like several doors on the same wall) and also checking for "double wall" situations where rooms are created next to each other. This could be also avoided by checking out rooms and giving it some space between them, but I think it's better just check for double walls and punch a hole to connect two rooms that way.

Teemu ARRP Diary 10/3

Changed some things in lighthouse levels, but still not sure how to handle the terrain situation with bottom and the top levels of the lighthouse. Maybe it could be copied in dynamic way always from bottom level to top, because the bottom level exists before the top level is visited. It would also remove kind of hacky routine to copy the map to world class to store it there. The only problem are objects, but the top level could have another set of objects anyway and you couldn't "see" the objects from up the lighthouse.

Working with the ancient cave theme I was using a new routine to create caves. It's a simple "drunkard" algorithm, but it can be used in levels the same way 'small' rooms, mixed with other types of creation. It's really simple, but effective way to create natural looking caverns. And with small percentage value of coverage I think it looks even better, because when it covers less areas it's somehow nicer than trying to create more coverage, then it becomes kind of messy. So I think it works best when used with other features.

Next themes to check out are all new, so they require more work than the others. I think expanding the game world has been fun, when you try to think possible places you could still fit into the theme of the game and in the environment of the island.

Teemu ARRP Diary 9/3

The room generation bug had a surprising source: the level was created twice. I forgot that when the level is visited first time it's created and then I also called Create() for second time. It wasn't clear even there were surprisingly lot of items created on second time. I was searching the bug from room creation for a while before figuring it out.

I'm now halfway of level themes. Some themes are easier than others. There are also shared features that could use some improving like the way 'small' rooms are created. At the moment the routine is scrolling through the entire level and creating rooms where it finds empty space for them. A better alternative is find one place at a time randomly, so you could give levels a limit for small rooms and also for their size.

Next I'm going to tackle lighthouse levels which are pesky ones. The top level is ridiculous, because it has to be also the bottom level. I'm trying to think could it be somehow possible to use the same level for base terrain, but only replace the lighthouse itself, because when you are at the top it should be the same level when you look at it (same objects on bottom level). I guess one way to solve this could be true 3D levels, but I really don't want to go there, at least not right now.