Wednesday, 8 November 2017

Teemu ARRP Diary 13/3: The new island

This is the second and final round going through level theme terrain. The first theme is the island and for that I decided to completely rewrite the island creation. The previous version had weird way to create the island using pieces of ellipses which was a crude and easy to way to create the island, but it did not scale well to different sizes.

For the pieces of island there already was a routine ready, the same used to create caverns. It's a simple seed fill routine with a random changes occasionally to make the blob more irregular. It just works, but sometimes it does create small "pockets" of water inside the island. It's not bad actually, because they are transformed into low water by the shallow water routine.

The way I made the mountain range and beach is quite smart I think. The routine is first scanning the coastline, then using those points to create a path (with new Topology_Path class). That shape can then moved and transformed by couple of ways. The nice thing about the path is that you can pick a point along the path to find stuff like entrances to dungeons, there is no need to manually scan for the mountain range.

The island is now easier to scale to different sizes, but I'm still keeping the size of island pretty much static at least for now. If there are bigger sizes there must be some kind of scale to food generation as well.

Monday, 23 October 2017

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.

Saturday, 14 October 2017

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.

Wednesday, 11 October 2017

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.

Monday, 9 October 2017

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.

Sunday, 1 October 2017

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.

Friday, 29 September 2017

Teemu ARRP Diary 8/3

Working on 'cave' level theme I noticed the list of rooms is not cleared when I re-create the level. It's very strange, because the routine to clear rooms sometimes work, but not always. The problem I guess here is the way I have made portals a "static" part of each level, but I think it's possible to change them. Portals come from World class where they are determined for each level, but they could be copied back to a level instance when it's re-created. When static portals are removed I could then simply delete the level instance and make a new one, rather than trying to clear parts of it.

Cave theme was also changed in a way that 'regular dungeon rooms' are now protected, so their tiles can't be destroyed by paths or caverns which seems like a better solution. Still I try to keep things simple just to proceed to next thing whatever it is.

I think my code is "clean" so to speak, but one thing that could be improved is the way I'm naming variables in member functions. They are probably often too short and not descriptive enough. I have mixed feelings about long variable names, but other than loop variables could be longer I think.