Sunday, 5 February 2017

Graphics design

I'm trying to design the placeholder elements on the main gameview. You would think I had all the time to do that, but "stuff" keeps changing. In my opinion you only have to show the player stats and other things that have some direct meaning to the character's condition. Other stats can be hidden to reach with keyboard command etc.

Drawing is a strange experience to me, because I'm supposed to be a graphic designer, but I'm really not that good as one. Or at least it takes time to do something that looks decent. But my first goal is placeholders which for those who don't know are the location and size of elements on the screen filled with some quickly made sketch.

As usual if I look at the past I made a mistake with tiles, not really knowing that technology would change in the future and I would have to remake tiles again. This time I'm just keeping what I have as it is and when the game is ready only then it's time to think about graphics. I would like to have someone to draw tiles for this game, but then again it would feel weird, because I've been creating this game alone for such a long time.

Other than that I think the project is starting to run out of unfinished parts of source code. Everything seems to be narrowing down to couple of issues, although the largely unfinished RPG system is a complex subject.

Sunday, 8 January 2017

Gadgets

As a new year's resolution I have started to find solutions to difficult problems which are often left to be "done later". One of those was traps that had the trap effect and mechanism in the same class. For a long time I planned to create separate classes for those and currently implementing it.

The new Gadget class is the visible part of the trap, like pressure plate or holes on ground. Gadgets are not always traps, the pressure plate can open a nearby door for example. Traps can be also attached to other items than gadgets. This was the reason I had to move traps from game object system to a composite class. The procedure or refactoring is anything but simple. I don't think there is a nice, clean way to determine which gadgets or target objects can be attached to which traps. It's probably going to be a manual list of traps for each type of game object which simply means I have to forget data-driven approach in this case.

With a gadget or other host mechanism the traps could be changed to more abstract form such as gases, spikes, falling objects etc. so for example you could have a classic water bucket placed on top of a door.

Sunday, 20 November 2016

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.

Sunday, 30 October 2016

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.

Thursday, 13 October 2016

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.

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.