Room refactoring

Yesterday was a bit depressed, because I have to refactor rooms - again. How long it's going to take to get this right? The plan requires a new kind of connection scheme for rooms which are generated "rogue" without corridor nodes. Of course I started to think all sorts of ways to connect rooms - with other rooms, caverns or whatever. I'm thinking too much.

Today it seems to be easier to start with simple tasks. First, rooms need more detailed connection data which means they know exactly where they are connected and how. The second task is creating manual connection routine between rooms and checking out existing connections. After that it starts to get complicated, but I can only test it to see how everything else works with rooms.

It may be not that difficult as it seems, because I have created a lot of routines and most of the refactoring is using those routines slightly different way.

Planning on paper

Planning on paper works really well. Yes, even when you plan random generated levels. It's easier to think what types of rooms or other features you need in that level theme.

Of course I ran into problems when a new shape for specific type of room was needed. The way walls are created works only for rectangle shapes and it's possibly difficult to fix so I'm doing it the easy way with blueprint tech developed for Teemu.

I also came to a conclusion that it's simply impossible to create all level themes with a single routine and data input. It's not that bad, I just need to write routines for each level theme using tools that already exist. That way I can do all types of funny stuff to create special themes. The order of creation plays an important role here, because changing the order makes funny level themes possible.

Another big thing is also the amount of randomness in some level themes. I was thinking that a long time and wondering how I could make level themes random enough. It's not the issue really. I could make endless number of variations or then I could start to finish level themes and make them less random. If it's creating too static themes I'm changing the game from a roguelike to RPG with save/load game and removing permadeath.

Weapon research

The RPG system of Kaduria is more physically based. It means there is more research to do with weapons and armours. I like doing research, but I don't want to dig too deep into that stuff. However it's interesting to realize how little we modern people know about medieval type weapons. Why they were like that and how they were used. In fact I think even actual scientists don't know everything yet, because the practical knowledge was lost when firearms were invented.

The techniques that were used had been developed during thousands of years. Imagine all that fighting and the history of weapon development to become better at killing. It's so revealing and tells a lot about us humans.

When I read about medieval weapons there is always something I didn't know or realize. Let's take an example of arrows. I knew they have a pointy end, but I didn't realize there were so many types of heads. Each of them had specific use. What I'm going to do is take essential head types and model them in Kaduria. It's something else compared to just having a regular arrow.

Item class design

Item class hierarchy is divided into three layers: main class, item datatype and subtype datatypes. The main class is almost ready actually, only trap handling is undecided. Item datatype is the main class for data-driven section of the whole system. But the interesting stuff happens in subtype classes which now are under heavy development. Data-driven approach is something that is not only modular, but it also creates a kind of order in programming which I find helpful.

Some subtypes are already there, but I think most of the subtypes need a dedicated class. In fact many parts of the item system is still unfinished, but subtype classes are very similar to each other and it's quite easy to create them from technical point of view. The difficult thing is the game design in them. What properties items have? How you can use them? Things like that.

Decisions in game design

One of the big problems in development for me is the game design. I have a habit to leave some things later and then realize it has been two or three years since I tried to solve some design problem. In roguelikes there are lots of problems related to RPG system and how to create interactions between objects. I think we all would like to create complex interactions, but it requires more generic and able engine. Limited actions are much easier to do, but it's including a decision to create a limited gameplay rule. I know that I have to make those decisions or this game will never be released.

45K

The room interior development is increasing LOC fast, it's now over 45 000 lines. Room interiors are interesting and fun to create, because there are lots of options to add in any room type and you can really start to think where all those game objects you invented earlier can be used. I have the basic creation tools ready so it's also quite easy to work with rooms. There is a lot of source code needed for special rooms like shops and other more complex types. However I don't want to limit my imagination here but create all the room types no matter how many is required.

Blueprint

Another piece of tech taken from Teemu is Blueprint class. It's plotting pre-defined (non-random) shapes of structures in the level or mostly inside rooms. Kaduria's version of Blueprint will be more random including various game objects such as lamps, doors, plants etc. But it's practically the same simple routine. Sometimes it's better just use static structures and admit that generating them with some sophisticated routine is too hard or would require more work than you actually need to make it convincing. It's also possible to use several static shapes and randomly select one of them.

I haven't yet solved how to connect pre-created important rooms to the rest of level but I would imagine it's not that hard. Also I noticed that my complex corridor finding routine is smashing through room walls so it's another problem to solve.