Gameview scrolling styles

The gameview of Kaduria is based on a technical limitation from ancient past. With tiles you had a limited space for the gameview and games like Ultima solved the visibility problem by placing the player character at the center of the view and then scrolling the gameview after each step.

When I watch gameplay videos of DCSS (Dungeon Crawl) I've noticed that scrolling at each step is kind of irritating. It's not that obvious when you play yourself rather than just watch however. What I find interesting is that ADOM is also scrolling per move, but only if there is more level to be displayed. At the ends of the level ADOM's gameview is not scrolling which is soothing to eyes. Another trick that helps is smooth scrolling. In fact it may be a bigger factor to make scrolling easier to follow (especially when watching gameplay videos).

The other option to scroll is known as "push-scrolling" which means more level is displayed when a limit is reached. The problem with push-scrolling is that you have to handle visibility somehow, because it's not always the same distance you or enemies can see, unless you limit the vision in the currently displayed gameview also.

I'm planning to move from centered gameview to push-scrolling style in Kaduria. Yes, after more than 20 years of development. Yet now when there are less limits on resolution it's possible to use a large gameview with 32x32 pixel tiles (or even bigger) if the resolution requirement is the current full HD. Who knows when Kaduria is released the now full HD is a small resolution.

New tiles for automap

The tile size of automap is one of the special problems I have seen before during this project which is tiles getting too small for modern resolutions. The size of automap tile is 12 x 12 pixels and it's just slightly too small. Resizing to something like 16 x 16 could make a difference.

The automap routine is quite good at handling the change of size I think. It doesn't yet have any special features I'm planning, it's simply displaying the explored map. The automap could have some kind of world structure where you would select visited places and view the map of them. Writing comments on maps could also be a useful feature.

Flow

I've entered into a nice mood or flow in programming. I think it's the result of leaving Rogue Temple forums. Or it might be the vitamin D I've started to take. Currently I'm going through game object classes and checking out virtual functions. There is a kind of problem when letting virtual functions "to do" later. When designing a virtual function logic you should write all versions for derived classes as soon as possible to find out problems with function parameters etc. For example it looks like I have to add 'actor' parameter for Break function for game objects, but we'll see it when testing that functionality.

One of the funny things I've noticed when programming a large project like this is just calm down and work for couple of hours at a time to get into that flow. Also, I have started to write more comments rather than less. It's such an important part of programming, but often neglected as it seems when looking at some source codes of roguelike games. Writing good comments is a skill, because it usually has to be in a form of summary rather than explaining line-by-line what is happening when you should be able to read the source code itself to find it out.

Project update

After trying Visual Studio 2015 with Teemu and Brick Atelier it was a preferable solution to move Kaduria to it. I don't know why but it's somehow satisfying to compile the project with W4 warning level and pick up errors that were not catch by 2010 (or probably just using W3).

One of the warnings is unused parameters in base class functions which may sound like annoying warning, but it's actually useful. You should use base class parameters/function either to inform that base class routine was called (rather than leaving it empty) or improve the class hierarchy. In fact I have a hierarchy problem with containers which are a component part of game object classes while it probably should be a class to inherit from. The solution is either fill base class routines with some kind of detection if they are called or try to create a class hierarchy without pyramid inheritance problem.

It's odd how these technical details seem to be more interesting that trying to create the game itself, but I guess it doesn't matter a lot in this case.

Keyboard command design

I've tried to follow a plan in keyboard command design where keyboard commands have some kind of logic in them. Lower case letters are for commonly used commands and upper case letters for less used, but also some letters have similar kind of action with lower and upper case forms. This is done in some roguelike games, but I think it could be extended as much as possible.

For example I had 'q' to quaff as usual, but previously I also had it search for water sources from the environment first and if they were skipped then drink something from the inventory. However I started to think it was confusing and added a new command to drink from environmental sources with 'Q'. Even that command is often 'quit' in roguelike games it doesn't take a long time to adjust to that. There are also some other keyboard combinations in the same key with lower case for items and upper case for environmental sources. It's a nice, logical arrangement and easy to remember.

It's not particularly useful trying to cut down the amount of keyboard commands, because you still need some kind of way to activate commands. Menus can be ok in some situations, but worse in others. The design of keyboard commands actually takes some consideration that I believe developers of older roguelikes never did. That was the case with many other areas of design as well.

Avoiding work

I've tried to pick up development again, but it feels hard. When looking at a particular piece of source code all there is left is work... especially in game design. Not so much in technical implementation, but some of that is also needed. It may sound funny when I'm referring game design as work, but that's how I feel when I'm comparing it to "pure" programming (without creating game content).

Working is kind of boring when you don't get anything out of it, at least not money as in this case. I'm often wondering why I'm even doing this, because I don't like playing as I used to like when I was younger. Maybe the explanation is that it's became a strange kind of habit. I bet if I tried to quit it would feel like there is something missing.

Today I was checking out item code. It showcases the problem of getter/setters in class based programming, but it's just how it is. Sometimes you could in theory create methods that sit well inside a simpler datatype class, but most often you need to get pieces of atomic data and make determinations outside that class. Either way the stuff gets done and no one is giving you points from better OOP style.

Problems in item code are mostly related to classification of items and using item type to check out some properties. It's not a good idea, because you could add some new item that has the same properties, but would not get recognized by the game as that kind of item. In large systems you need to classify everything to a larger group of items, whatever it may be. Then use the group's data to detect item types in more abstract level.

Inheriting levels

Seeing how easy it was to inherit levels from Level class in Teemu I'm doing the same in Kaduria. The funny thing is that in Kaduria it's easier than it was in Teemu, because the level generation in Kaduria is more data-driven and relying less to specialized generation code. Splitting the gigantic Level class is useful also for a simple reason that you can concentrate on each level theme without having to worry about breaking up something elsewhere.

Other than that I've cleaned up messages. They are still giving me a lot of trouble, but it's starting to look like I'm able to remove last pieces of the old message code rather soon.

Improvement on keyboard commands

My intent for Kaduria was always keep it keyboard driven. It's a graphical roguelike, but I never liked mouse as input device for this type of game so I have focused on keyboard. When you think of typical roguelike experience with every key assigned to a command it's surely possible to make it better, but that's only because this game genre is so ancient. It's easy to improve that so there is nothing special in it.

The main thought in my design philosophy is that it's better if it's easier. But how to make it easier? It's not that simple always. There are many ways to use keyboard commands. The first step I did was move extremely rarely used commands to a menu. There are things like 'options' and 'save game' that could be easily stacked to a game menu. Not only there is no need to use a key for those commands, but it also saves more keys for more important commands related to gameplay itself.

Menus are an easy way to reduce keyboard commands, but sometimes they can be worse than direct keyboard commands. You need more keypresses to activate the command which is not what I'm looking for. My opinion is that there is nothing wrong with direct keyboard commands as long as they have some kind of logic in them.

One option to reduce the amount of commands is a context sensitive command like Use for using different type of objects (open door, loot container etc.). Somehow I don't like that context sensitivity. I do have use command, but I'm actually planning to limit the use to only specific type of objects that are switched on/off. Or maybe even completely get rid of it.

Some actions can be improved with simple UI tricks. For example when you open something with 'o' it's auto-selecting the nearby object. There is no need to press the direction key unless there are more than one similar object. Another option is bumping into a door to open it. I don't like it, because it should be 'attacking' the door in proper logical context. But I have included it as an option.

Dividing keyboard commands into logical groups (such as movement, inventory, combat) also helps when you are looking at the keyboard command list.

Lately I've been re-designing the keyboard command scheme and it's surprising how much you can improve it when you think hard. There is also going to be an option to re-define keys, but it's not a way to go around a good design. Keyboard commands should be designed so that the player has no need to change them.

Design of the gameview

I've been working on "small" stuff like the functionality of menus etc. but now attempting to tackle an important part of the UI design which is the main screen shown when playing the game.

Two usual ways to provide information is either display it all the time or preserve a space for it to display when something happens, or create a command to display some information. I think there are endless possibilities to weigh between easy access to information vs. displaying too much information at once. Also, everything you decide to display will take some space away from the game world area and increase the requirements for pixel resolution of the program.

Up to this day I have had some kind of vague idea how and what to display, but foolishly delayed the complete design in a thought that it will be decided when the RPG system is ready. It's of course nice to know what stats are displayed etc. but it doesn't really have a lot to do with the way you display things.

Design as motivation

When bored I'm doing what everyone else is - watching youtube videos. So I was watching this presentation by Scott Meyers (the author of Effective C++ book series) titled 'The Most Important Design Guideline'. I haven't read any of Effective books and I usually don't like these talkative guys, but he did say something interesting that made me realize something.

He is talking about the importance of designing programs to people. He mentions that if the user can't understand easily how to use the program it's not his fault, it's the designers fault. It's kind of obvious reasoning, but actually not that often thought in game design. Roguelikes for sure are notorious for having cryptic user interface solutions.

From that realization I had an idea to approach development from the design point of view. I've never thought of it that way, even I know design is important. But it can be even more, a motivation that drives the development. It's important to have motivation and it can go away when you spend years in developing something. For example Kaduria has practically removed my interest to play games. So finding another source of motivation is nice. It feels nice, that's all I can say.

This new motivation for design has already made a difference in the way I'm programming. I'm now focusing more on important stuff like content which can be seen as design. It also helps me to avoid dwelling in technical details of the source code which is one of my shortcomings in game development.

Paper and Bag

Last time I was talking about the difficulty of inheriting classes, but after all it was not that hard. Classes Paper and Bag were derived from Item class. Paper contains scroll functionality and Bag is a container item. Both these were previously in Item class, but for most items they were empty data. Moving that data and functionality to derived classes not only makes source code better (less chances for bugs), but saves both memory and save game space.

As I said deriving itself is actually quite easy, because container functionality was already in base class as virtual functions so they work automagically. The problem is in the way items are created and stored in lists. Since C++ doesn't as default support heterogeneous lists you can only put class instances of one type in a list. However this is not such a big problem than I thought, because in this case you can put all items in Item type list and when you need special functionality of Paper or Bag you simply cast Item to Paper or Bag, depending on the object type. It's kind of ugly, but in a way typical C++ solution.

The only real problem is something called object slicing, but it doesn't happen with list of pointers to instances.

Last thing is when you load object data you need to know what the object type is when using heterogeneous lists of objects. I've solved this in theory by using a trick to peek the saved object type (from loaded chunk of data that contains the entire list) before creating the object, since obviously you can't create the object until you know if it's a regular Item, Paper or Bag.

That pesky inheritance

I had an idea to test how easy it would be to inherit Paper class from Item class. The slight issue I have with scroll items that only they have a scroll component in Item class which is left empty when the item is not a scroll (or readable item).

Inheriting from Item is easy, but what happens next is not. The problem is that even if you could store Paper type items in a Item list and then cast it to Paper, there are even deeper problems. Perhaps the most difficult one is the way items are saved as a list of items. When you load items, an empty Item class is created and currently there is no way to tell what the next item is going to be. Obviously you would have to create Paper instance for readable items, but to do that you would need to save the type of object, then load if before loading the actual object data.

I don't know how people solve this. Maybe using some kind of obscure pattern trick who knows. Sometimes I'm dreaming of removing inheritance from game objects and creating one gigantic base class for all object types. Then everything could be placed everywhere without the fear of object slicing, you could stuff small monsters into your backpack, carry around a detached door and use it as weapons etc.

Splitting up classes

I have had a tendency to create big classes which are one of problems in this project. Along with SDL2 refactor I've started to split up big classes by removing some features to new classes. Things like automap displaying was previously in Gui class which is kind of thematically correct, because it only contains displaying, but at the same time it's adding up to complexity of the Gui class.

Sometimes creating extra classes can be more work (and code), but it's most likely a better option anyway. Classes can be split up by theme, but in deeper level it becomes easier to split small classes also with inheritance. This is sometimes a natural result of classes becoming small, because you can then either derive from that class or even derive to "upward" direction which means it's possible to create another base class for classes that have same kind of structure.

Being able to create a base class that way is great, because it's making the source code shorter and easier to manage, although in perfect world you should be able to design the class hierarchy before it's refactored this way. I think the way biggest problem with classes are the size and growing number of functions in the class. Yet it's always a trade-off. Big complex classes can do more than small simple classes, but they are much harder to use as classes. A big class can become more like a small program in the program and working with it can be difficult especially when you need to rewrite the code.

I hope the process of elimination becomes easier when I split classes by theme, because that is the way I'm programming this project.

SDL2 engine ready

Transition to SDL2 is now done more or less. There are some minor issues with keyboard (scancode confusion) and the way window background was saved and restored in previous version. Shortly described window backgrounds are not saved so the background is trashed. It can be fixed by drawing everything that was in the background.

Other than that I've done some good progress by cleaning up a lot of classes, sort of checking out them again to reduce "things to fix". I'm also starting to get a good idea where the most work should be concentrated which are fine details of level generation and RPG system as a whole.

The RPG system is the biggest problem I have in this project, because well.. it doesn't exist. Or it does in some sort of vague form with some random stats and stuff. But you need lot more than that for a working role-playing system. I did make a big mistake by trying to create it starting from the "wrong end" which means adding lots of stuff without knowing how they play together.

The great SDL2 adventure part 2

After working for about a week it's not yet over. The core graphics routines are quite ok, but there are lots of external routines calling gui routines that were largely rewritten. I try to keep perfectionist thoughts away and concentrate on replacing 1.2 stuff with 2.0. There are some annoying stuff like data types of SDL mixed with C++ data types of Kaduria. SDL has a rectangle "class" SDL_Rect which is less useful than C++ (OOP) rectangle class of Kaduria. Yet maybe I should have had pixel rectangles as SDL ones in the first place to avoid confusion and conversion routines.

It's quite depressing to remove and rewrite parts of the source code you thought were ok, but that kind of stuff happens when some external library is changed.

Updating to SDL2

This is a good time to update from 1.2 to 2.0. It's not a dramatic change, but the GUI is refactored in a way that there is a new class Graphics_Engine which has low level graphics routines which then are used by high level gui class. It's not required to have it this way, but I think it's much cleaner. Only "atomic" graphic display routines are in Graphics_Engine, such as displaying fonts, pieces of static graphics, tiles and other simple elements. Then the higher level gui is taking care of displaying windows, tombstones, stats and stuff like that.

I guess it could have been possible to continue with SDL 1.2, but I think SDL2 is better. It has better support for alpha channel, full screen and graphics rescaling (which may or may not look cool..).

The story of level theme

Many roguelikes have static levels that have something I call the story. In fact even random levels have their own "story", but it's less obvious. Static levels or places have an important role to bring something special to the basic random dungeon generation style, but they themselves can become rather boring, because they are always the same.

Some games try to solve this by randomly selecting different elements for the static level. Sokoban in Nethack has couple of variations for each level of the sokoban branch and I think the artifact can also be either bag of holding or amulet of reflection.

In Sokoban's case the next level would be changing parts of levels to create even more variations of the sokoban puzzle, but I don't know if it's even possible. The hard core solution would be a random sokoban puzzle generator that would create the level and solution using no static parts whatsoever. It could be possible to write such a routine, but I'm guessing it's quite difficult to do.

The story is an essential part of a level theme and more detailed story is more interesting one in theory. Sometimes the story can be as simple as some special type of monster(s) that live in some location. There may be also some treasure you can find either by killing the monster or the treasure is hidden and guarded by the monster. Without a story the level is just a bunch of rooms and corridors you have to explore. Well, nothing wrong with that either, it's just not that exciting.

Trying to find the way to the next level of storytelling is difficult, because you want to avoid static elements but at the same time try to create them using some kind of random or semi-random technique. Quests, artifacts and special monsters are ok I guess, but there could be other type of stories as well, it's just a matter of trying to think hard what could happen in a dungeon other than that.

Build style

I have started this year with a critical revisit to level generation from the ground up. First thing to check out was the overall style of level themes and other elements. Each theme has information about natural rock types of walls, floors etc. and then a build style which determines tiles for rooms and many other things.

I had already made a distinction between natural and build styles, but some build styles were removed, because they were actually just the natural style of the level which means rooms don't have artificial walls, they are only carved into the bedrock of the level. Also an important change is the ability to mix build styles so not everything is made with the same style per level. There will be a secondary style for most themes and also possibly random styles which still fit into the current style.

The idea of styles is that they make the dungeon generation abstract. Then there is no need to think about individual tiles and their roles in the dungeon generation. Everything is reduced to abstract walls and floors, artificial versions of those and other things needed in the creation. You can then add a style/theme and the new level theme is done just like that, at least what comes to the style of tiles.

Rooms also have their own type, because some rooms are special. Still, even room data could be retrieved from the build style and it's probably something I'm going to do, at least for some room types. The difficult part in "generic" room styles is that many rooms are quite special and would probably require some heavy data so that each room type looks different depending on the build style or even the level theme. It's probably much easier to plan what room types each theme has and then design room creation only for those types.