Thursday, 13 October 2016


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.

Sunday, 25 September 2016

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.

Tuesday, 13 September 2016

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.

Wednesday, 24 August 2016

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.

Tuesday, 26 July 2016

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.

Thursday, 9 June 2016

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.

Sunday, 1 May 2016

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.