Sunday, 19 March 2017

Object storage re-design

In the current engine game objects are stored in "raw" lists on Level class, a list per each object type. 2D maps have pointers to these objects. There are other ways to do it, like concentrating everything on a tile which means the tile owns all objects on it. The reason why I have a list for each object type is that when I was designing the system I had difficulties to understand how a base class list would work, but of course it's pretty trivial.

I'm planning to re-design the system with a container class that "hides" the base class list of objects and then has everything needed to work with the list. Then I could create an array of those classes each with a type of game object. I could even try tile-based approach or possibly a mix of both with stationary objects owned by tiles.

I know this is one of the things that people may get right the first time, but I wasn't that lucky. Even so, the re-design is not very big actually, because all it has to do is add and remove objects in the list, with couple of other routines. These days I'm quite careful not to reprogram things just because, but this one seems to be quite important to get rid of the object id confusion I'm having at the moment. If there is anything I have learned about programming it's to break large pieces of code to smaller pieces that then can be managed.

Wednesday, 1 March 2017

Unlimited level size

I've worked on level theme content and kind of frustrated about the rectangular level shape or space that you have to work with. I think it's limiting the way level generation is made, because you have to choose cavern sizes etc. to match the level size, but it should be the other way around. Level size should adapt to whatever is created in the level.

The big question is how to implement that kind of level map, because you still need a 2D grid to contain the level. One idea that could work is create a ridiculously big empty level and when the creation is done then remove areas "outside" the level that don't contain any features. If it's difficult to resize the grid then copy the content to another level that matches the size.

The way level is generated would change a lot, because everything would be created in relation to other features. With this kind of creation it would be possible to start from several "points" and create different kind of content until they meet. This is a problem I have now with themes that have more than one style of features such as a town level surrounded by generic cave-corridor -style. When you create the town you are limited by the outer edges of the level plus those extra caves. Without edges you could create the town of random size, add some caves to extend it and that's it. Not only that, even simple level themes sometimes position caves on the edges of the level which can be seen, because they are cut off by the edges, even the edge routine is including some random tiles to make it less obvious.

I think it's not too late to use an "unlimited" level size when creating the level, because the way levels are created in this game are not limited to any kind of grid. Yet this is not something I want to try now. Not until I have programmed all important features of level generation.

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


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


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.