Saturday, 30 November 2013

Quest for Avatar

Avatar, or the player class, is derived from Creature class. Then many functions can be used by the Avatar, but sometimes or more like usually it needs a check if the Creature is the player and do something strictly limited to player character.

It's a perfectly valid option, because it can work without problems. Still, I wonder if it could be possible to use Creature class "component" of the Avatar without Creature knowing about the derived Avatar. I guess what is often done is a common class where both Creature and Avatar derive, but it seems a bit difficult to implement. You can also use more generic Creature functions that return information to Avatar class which then decides how to process the data or whatever.

It may sound like this is irrelevant in game programming, but I have noticed that when I improve OOP features of my source code it also becomes easier to understand for me. And sometimes the result contains improved gameplay features as well.

I'm also more experienced as programmer to handle that kind of thing now.

Sunday, 3 November 2013

X marks the spot

The question of terrain or level topology is easy as it is hard. I can make a level theme incredibly fast with the current data-driven engine, but somehow those themes don't satisfy me as they are. Levels need more details and also variations that should be difficult to predict. The slightly predictable level themes in Nethack (and other roguelikes) was something I wanted to fix with this game. But creating such levels is not easy.

Back a while I let go of strict data-driven approach and added special level themes, but at the same time I feel the data-driven code can do more and it already does when I added a special-ish level theme containing lots of lava. If however the data-driven system can't create all stuff needed in a level theme it has to be removed and used a manual generation instead. Hopefully most level themes can be created with the engine.

Even getting all level themes in some kind of physical form seems to be difficult, but it's something that should be done now, because you need levels to navigate in the game world and interact with game objects and since climate and other features play such an important role there must be different kind of themes to try out to see how easy or hard they are simply as terrain.

Sunday, 27 October 2013

Refactoring Menu class

Menu class itself was surprisingly easy to change from raw text data to std::list. Item menu was rewritten earlier so I skipped checking it and moved on to refactor "regular" menus with simple text as items. It took a day to change all menus, because the constructor parameters changed and now you didn't pass a text buffer to menu but items one by one as const char data.

The data for menu items was available in data structures of most data-driven stuff so it made the source code better, because all those temporary text buffers were removed. The game doesn't actually have a lot of menus and most of them were mainly in debug routines.

I had a good feeling when I programmed today and hope it continues. I also think the best way for me to manage this project is to make a focused plan of something and then try to concentrate on it hard. It gives good results fast when I know what to do.

Thursday, 10 October 2013

Refactoring Window class

As a part of quite important menu refactoring Windows class had to be refactored. There were two classes, with regular and small fonts. They were merged into one. The resulted class was easy to refactor per se, but several windows initializations had to be refactored.

It's done, but something went wrong (as usual):

The window displaying help of option went bananas. I'm sure it's quite easy to fix.

The important refactoring is in the Menu class. It's going to be harder than this, but it has to be done. You would think there can't be anything left to refactor in a project like this, but you are wrong. The current Menu class is using simple text data with hard-set amount of items and a pointer to char* buffer. It's bad in several ways. What I need is ability to display each line of text in different colors (sometimes) and to do that you need a list of objects with text data and font color.

Fortunately I already have it, the Display_Message class that Message is now using to show a message. It's not designed for this, but later it can be replaced with any other class of same type.

Sometimes the menu list is changed, for example if you drop an item from inventory and that also is improved with list where only the selected item can be removed. With static char* buffer you need a complete re-build when the list is changed.

Later it could be also possible to create direct item menus (simply a list of items) without using a text based copy.

Let's hope I get it right this time...

Saturday, 5 October 2013

That pesky content - part 2

There has been a subtle but important change from engine programming to content creation in this project. A common misconception is that roguelikes don't require that much content, because they are random(ly generated). It's not that simple. Sometimes they do require a lot of content and randomness is only an extra layer on top of it.

An example is creating equipment for creatures. Today I started with helmets or headgear. For them the race and profession both determine the type of headgear. It's mostly the profession. Fighters and knights could wear a metal helmet, but wizards should wear a pointy hat. But if you always have the same decisions the gameplay becomes dull and predictable. There should be some kind of random variation, but in some kind of context. A knight could be wearing a crude helmet if he has lost his metal helmet and a wizard could be wearing a studded leather helmet. Helmets itself could have an importance value what comes to the decision how often they are created, because they were in reality the most important piece of armour.

The details of decisions can be complex and decisions or their "engine" itself are hand-picked content. More intelligent races and professions means more decisions. I already regret I made goblins an intelligent race like dwarves. Maybe they are removed or the amount of professions reduced.

Monday, 30 September 2013

Cloth armour fashion

Yesterday (Sunday) I had a headache that lasted the whole day. I took two regular ibuprofen pills, but they didn't help a lot so I took that day off. I tried hard to do nothing and almost succeeded in that. Today I feel much better, like almost sharp.

I've been reading about bronze age armour from the Bronze Age Military Equipment book and it has given me many ideas about how to use armour in more realistic way. Scale armours were probably most popular armour, because it allowed good mobility, enough protection and wasn't too heavy. Scales were made of almost any hard material. There were even bone scales and scales made of leather. It was also easy to fix a damaged scale mail by replacing damaged scales.

What I didn't realize before was that cloth armours were also very popular. They were usually made from linen that was layered even 14 times to create thick armour. You couldn't have endless amount of layers, because then moving became harder. Surprisingly, also felt was used as armour or more likely as pads.

Because I'm using more "realistic" physics I can use all those differences in armours to get trade-offs between mobility, weight and protection.

Sunday, 22 September 2013

Bronze age style

I'm reading "Bronze Age Military Equipment" by Dan Howard. It's a cool book, because not only it tells about weapons of that age, but also how they were used and tactics involved in warfare. I was always thinking Kaduria will be low fantasy, but now I'm more convinced that it could be even lower!

Bronze weapons could be the main stuff used in combat, or even stone age weapons. The setting could be in between fantasy style bronze and iron age, making iron weapons extremely rare and efficient. This was the case in real life when metal weapons were invented. First they were used by only few, rulers and their elite troops. This historical fact could be a source of interesting weapon distribution where a simple iron sword is hard to find.

In fantasy context low fantasy doesn't mean there is no magic. In fact magic could be a noticeable part of the gameplay, possibly making it even more important than in regular role-playing games.

Saturday, 24 August 2013

Over-scoped features

I thought it would be nice if you push something floating on water it would move in the stream. The movement was random, but then I realized it's silly. Of course rivers must have a direction where they flow, so it was something I added today. This feature was kind of easy to add. I just created four river tiles each with direction of flow and re-factored river creation which already had an orientation (horizontal or vertical) and direction where it was flowing.

I tried to test it with a barrel, but it didn't go into water. Sadly I had removed that feature for now, because I'm having difficulties with the terrain and object interations. But in theory it works and you can push stuff into river and watch it go downriver.

Another feature I still need to implement is a temperature map. I realized that if I have temperature it needs to be local and not in level scope. It would be funny to walk on lava in snowy mountain and still feel cold. Temperature map is going to have mixing between temperatures so near lava it's beginning to be hot and it could even melt snow and stuff like that. It's a good preparation for level events like lava eruptions.

Monday, 19 August 2013

Kickstarter roguelikes

There was a long post by URR (Ultima Ratio Regum) developer about Cult, a kickstarter RL project that now possibly has failed, because the developer can't create the game he was talking about.

What I find amazing is not why projects like Cult fails, but the way people are willing to support almost anything. In other words, let me phrase this carefully: people are idiots.

Well, there is nothing new in this, because people also buy poor commercial games. However they at least get something in return, an actual game.

Not just average developers try their luck with Kickstarter, but also old and young professional developers. One of the worst examples is Richard Garriott, one of my childhood heroes. He had the money to continue Ultima series when he wanted, but only when Kickstarter made it possible to ask money he did so.

Also, I want to correct something Darren Grey said about Kaduria in a comment. He included Kaduria to the list of big, over-scoped projects as he said. He is wrong. Kaduria was never an over-scoped project like, let's say, URR. The development time has been long for other reasons and rather than following the usual development history of a failed project it has followed a different path.

Wednesday, 7 August 2013

Theme park

Back to level themes. I have a plan to create quick versions of unfinished level themes, but even it seems to be hard. I need plans for my plan! I have a vague idea for each level theme, but it's not good enough. I think better way to handle this is plan each theme on paper as I have done for couple of them. Then it's easier to think how to implement features presented in the plan.

Level themes are difficult, because they involve content creation. Yes, that pesky content. I think even seasoned game developers can be surprised about the amount of content needed in a roguelike. No matter how random the creation process is you still need to design it. And the amount of design is multiplied by the number of level themes. On top of that I have ambitious ideas for level themes, most of them with special features.

Sunday, 4 August 2013

Stairs logic

Previously I had created a node system for levels which is a database of level themes and connections between them. After the introduction of "static" or special room types in some levels I had to re-think stairs creation in their actual form as objects in the level. This far the generation process found some empty floor and there you had it.

What I needed was some kind of way to tell stairs creation about static places for stairs. For that purpose it was easy to set up a list of "clues" for stairs. It's a coordinate set during the creation process and then retrieved when creating stairs. There could have been many ways to do this, but I chose this way, because you browse through node connections which then can be matched with the clue.

At first it returned a wrong location. It was a bit of a mystery, but finally I realized the location was not set correctly, because the room interior was created later than stairs clue was pushed into the list. Some of the interior was terrain generation (with Blueprint class) which I then moved to the routine which is creating the actual shape and terrain of the room.

Now it works and I can set up special locations for stairs. Of course, it's not yet done. Even random generation needs better "clues" where stairs should be created.

As this example is showing. The sign of stairs is created next to door. It should be quite easy to prevent this by removing that place from possible creation locations. The same also need to be done for walls, because doors also could be created into poor place, next to something that's in the room against the wall.

Wednesday, 31 July 2013

What I think about bugs

Good old captain told me "there will always be bugs". Those words ring in my ears. I think not, captain. In reality bugs are always a result of what you do. There are rare compiler bugs, but they are also often caused by stretching the limits of the language by using unneccessary complex programming style.

Programmers are egoistic people. They don't want to admit their own errors, but instead use excuses like "there will always be bugs". Programming languages like C have played a big role in this mess, because it lets you write poor quality code. However it's still you who suck, not the language.

When I look at some open source projects I can already tell why there are lots of bugs and developers spend huge amount of time trying to fix them. The problem is always how you could tell these people to learn better programming practices? It never works that way. It's always up to personal interest to learn more and try not to pretend like you know everything better which you don't if you produce large number of bugs.

Kaduria has four open bugs at the moment. Yes. Four, as in 4. I want to keep the number of bugs low, but also prevent them with strict programming rules. You can never rely on yourself as some kind of machine who never make mistakes, so it's important to follow rules that, if not always prevent, at least reduces errors. What those rules are depend on personal programming style and language, because some languages have features which almost always explain bugs.

I find it easier to become a better programmer, because then you spend far less time hunting those bugs you could have prevented. So keep this in mind: if your project has lots of bugs you suck.

Monday, 29 July 2013

It's a trap

There was this bug I wanted to fix. When you looked at a trap it was telling the name of the trap, like poison gas trap. But how could the player know that before stepping onto it? I had to fix that by adding "identified" flag in Trap class and returning a generic name like "pressure plate" if the trap was not identified.

Following the new std::string message style I wanted to make the generic name const. In C++ const is a immutable variable, something that can't be changed once it's set. The problem was that Get_Name() returned plain char* and it is a virtual function of 15 total game object classes. So there was some of that good old const correctness when I changed all those routines to return const char*. It wasn't that bad and at least now it's done.

I've had my personal issues with const correctness, because it's sometimes difficult to grasp the concept of const. It's not that I don't use const. I'm using it almost always when setting up local pre-calculated variables etc. because it really eliminates one way (a subtle one) to create bugs. But when using const in data it can create a long chain where everything else must also be const. However lately I've started to use const in my framework routines etc. so it's becoming easier to be correct.

The bug was fixed, but I started to think about how messages work in Creature class and I guess there are some things to consider. Sometimes messages are constructed for all creatures when in fact only player can generate the message. The message output can be limited to the player, but the message itself can be constructed for all actors and it can slow down the game when there is a large number of creatures in the level. It's something I have to remember when I get into details of the Creature class routines.

Saturday, 27 July 2013

The palace

Small room item creation bug was fixed. Rooms are now in a list which also means I can create the interior later. It's an idea I've had for rooms to form "houses" by checking out where a room is connected and then determining the room interior.

There was also a bug in a return value of one routine. I used int return value with -1 as failure and 0 as success. It doesn't sound bad, but it can be since I was thinking zero was failure when I called the routine. It's easy to make that mistake since I'm using zero for failure in routines that return object handle. In cases like this it's much safer to use bool as return value. This bug was only telling that there was no room to create item in a small room. It didn't do anything else.

The actual bug was in the search routine which had no room mask id included so the area of search could include tiles outside the room. In theory, because the room rectangle should be good enough. So this is one of the few bugs that were fixed by an accident. I don't know what happened.

I'm reading a booklet The Oxford Handbook of The Bronze Age Aegean. The famous Knossos palace is interesting, because it was kind of a labyrinth with no clear floor plan. Maybe it was also a castle of some sort, planned to make it easier to defend and confuse enemies. Or maybe it was built like that for religious reasons. Who knows, but the important thing is that it's like made for a roguelike level theme. What could be better than random placement of rooms without apparent logic? An ancient palace with hidden rooms, long corridors, mazes and stuff. And it's an idea from the real life.

Friday, 26 July 2013


It's often important to know exactly what is going on with routines, but it's also tedious to add debug information. I guess I need it now when I'm fixing a bug with room item creation. For some unknown reason the search is including areas outside the room. The bug has been there for a while and I noticed it only when removing all item creation other than when it creates junk items in "small" rooms.

Bugs like this are annoying, because you know the room is made into that spot. You can see it in the mask map and in the level. Nevertheless something is wrong. Maybe the room rectangle is stored incorrectly. Since small rooms are temporary objects I have to change it and store them in a list to view the data later and compare it to the actual level.

Monday, 22 July 2013

Paper Mario

This project has some features that have been unfinished for a long time - for various reasons. I thought this message count thing was going to be the next one, but in just a few minutes ago it was fixed. What I now often do when I get a difficult problem is that I close my computer and get some paper to plan how to fix it. Surprisingly it works often than it doesn't. Planning on paper is free from any distractions and you can literally visualize the problem by drawing it if it's something you need to do.

When I look at the list of unfinished features I have to evaluate them again. And again.. but it's difficult to make a decision to delay the feature or even worse - remove it.

Friday, 19 July 2013

Ducks & Barrels

Refactoring the message routine was easier than I thought. I had already changed old c-style msg()-function to use message "event", a list where messages per turn were stored. It was essential, because there are zillions of calls to msg(). In fact, I'm not even planning to replace them, unless a part of code is refactored for other reason.

I made a clever choice to create a dedicated class for messages that are displayed and stored in the list. It's storing the message itself, color (for future use) and amount of repeats. Everything else went well, but there is a bug or more like logic error in the repeat or count of a message.

So, when you get messages like this:

It's convenient to display first two messages like this:
Duck. [2]

But when you store messages in the list there are only two actual messages, not three. This wouldn't be a problem during a turn, but the glitch happens between turns: if there is no new message added to the list, the message is not displayed at all.

I was in shower when I had an idea that might work. It could be possible to store the count of the last message and check if it's different than before and display the message as an extra one before the messages that were added in the list during the turn.

Tuesday, 16 July 2013

Leaving a message

For some time I have planned to refactor the way message routine works. Since the data was largely centralized to the message class I had difficult time figuring out how to proceed. Then suddenly I had an idea while I was doing deadlifts in the gym. Who said weight training and roguelike programming can't co-exist?

It would be extremely hard to discard everything done this far. Rather than that I'll try to slowly include the new routine inside the message class so it can work at the same time with the old routine. I think it can be done and it's not even that difficult. However it may be somewhat difficult to distribute the centralized data, but in return it will give better modular structure for the message data as well.

I'm also trying to replace C-style variable parameter routine with std::string. I don't yet know how hard it will be, but I think it's worth a try.

What I hope to achieve with the rewrite is more flexible message routine which is less responsible for creating complex messages, but at the same time taking care of things that could be tedious to handle in the routine which is displaying messages.

Sunday, 7 July 2013

Puzzle adventure

As the source code has grown and also the scope of the project it looks like all I have to do is solve puzzles. They are unfinished features or some part of source code I've marked.

These days I try to find some kind of quick solution to these puzzles, just to get somewhere. It's also tempting to simply remove the feature for now, but then you go back to simpler gameplay and finally reach a game that has complexity of a 7DRL. All that in 30 years of development.

Wednesday, 5 June 2013

Rethinking artificial intelligence

A while back I removed AI system I had been developing for some time and merged it to a command structure. Maybe I was looking for a simpler solution, but after some thinking it's obvious that there must be a separate AI logic with the original primary/secondary task idea.

How tasks will be organized is not yet clear, but each of the creature has to keep something in mind, a goal to which it is reaching. A number of things can change the goal, but not secondary tasks which involve things like swimming or some other circumstance as a temporary block between the creature and its target or goal.

I'm too dumb to use any sophisticated AI algorithms, but I think you don't need any of that to make creatures do what you want. Also, algorithms tend to produce predictable patterns that can be exploited. I intend to create an unpredictable AI that can sometimes make huge mistakes or forget something important. If I can make it so that the player will see those mistakes then it's going to be cool.

Sunday, 5 May 2013

Mountains of snow

I find myself again at the snow top. This level theme requires some new routines, but if I keep myself calm I can possibly create a brief sketch for each level theme per week or two. Anything new made in a theme can be used later and most of the time consuming stuff is creating things that don't yet exist.

When most level themes of Kaduria are quite static with some random structures it has made me think what I'm actually trying to do. It's like Teemu, I can't call it a roguelike. It's too static and more like adventure game. Still it has permadeath which even I find annoying. The interesting thing is that some people like the challenge permadeath is creating. Even when the game design is poor and often your character dies in a random situation which could not be avoided. This has made possible to create games that have quite poor game design, but some people still like them. ADOM is a great example. It never was really good as a game, but its difficulty became a feature some hard core players like anyway.

I know it's funny when you remember my strict opinion about what a roguelike should be, but I have to think about removing permadeath from Kaduria. I want to create a large game world and more static content. It's not good combined with permadeath. I think pure roguelikes should have relatively small game world and almost completely random level generation. However Kaduria will most likely be a fusion of "static" RPG and a roguelike. Maybe it could be a good idea to include an iron man mode with permadeath for hard core players.

Wednesday, 1 May 2013

Caverns of doom

In the next phase caverns or more like passages connecting them went through everything else as was expected. Passages wider than 1 tile were removed temporarily, since there is no routine to check rooms with the ellipse routine drawing passages. It's a minor problem to be fixed later.

Caverns itself were too small for some reason. Fixed that with proper data for the level theme. That way I can control the size on each level theme if needed.

Both actual rooms and caverns are separate "layers" so it's possible that sometimes those two don't have a connection between them. It's rare, but possible. I'm going to check that with flood fill and then searching a place where a corridor can be made without breaking anything else.

When looking at cavern interior generation I started to think too much again. There are 11 different interiors now and some of them are unfinished, but I realized that I can and should leave some of them to do later, namely those I don't need right now in this level theme. It may be even possible that caverns can't do something I need later and I have to create another more specific routine for that task.

Next I'm going to add small rooms which is the last feature for this level theme. After that I'm going to move on next level theme. The idea of the new plan is first create the physical structure of each level theme and only then add details.

Saturday, 27 April 2013

Plan B, part 2, phase 2

Connections between "rogue" rooms work now, in the simple form without any complex routes for corridors. Some room types prefer to have a centered doorway and it also works, but with the assumption that rooms always start from the edge of the room space. Also, there is a need for a new type of space searching routines which understands different room shapes (the current one checks a rectangular area).

Now I can move to the next phase which is generating other stuff in the level beside the important theme rooms. I have not tried it yet, but I think it's going to be interesting. The manual generation process will hopefully make it easier to control the generation, but I have a feeling that I need to change something. The good thing is that I have sanded the parts of the generation to such a perfection that there is hardly anything left to do but connect the dots.

I also realized that I can change the way small "auxiliary" rooms are connected to other parts of the dungeon. There can be different rules to produce complex houses with room types logically connected to each other. Let's say a shop can have a small storeroom and also a bedroom where the shopkeeper is staying. The storeroom can be connected to the bedroom as well so if you sneak into the storeroom you need to go past the sleeping shopkeeper.

Friday, 19 April 2013

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.

Thursday, 11 April 2013

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.

Thursday, 21 March 2013

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.

Thursday, 14 March 2013

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.

Tuesday, 5 March 2013

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.

Friday, 8 February 2013


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.

Sunday, 3 February 2013


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.

Sunday, 27 January 2013

Special theme rooms

Some level themes have important rooms which has to be created. I was thinking of returning a room type from the order of rooms made, but it failed. The reason is the way I'm creating corridors first, then rooms in the center of corridor nodes. Sometimes nodes are too close each other and one (or both) of the rooms is not made. This kind of creation makes it impossible to make sure that the first room theme is created.

So it's back to planning. I do have special rooms which are created after other room types. I had planned it for shops and rooms like that. But it can't be used in this case, because important rooms must come first and everything else created around them. In best case scenario I'm able to use old special room routine, just place it first before other rooms are created. All that and more will be revealed in the next episode of Kaduria - The Blog.

Wednesday, 23 January 2013

Annual LOC report

This LOC chart is recorded from random points of the last year. It shows some kind of progress in lines of code, but is not equivalent to real progress (which is slower). The problem areas in the source code are now kind of distilled to a number of difficult puzzles I have to solve one at a time. It's slow, slower than any regular game development. If there is one thing I'm happy about it's the extremely low number of bugs, thanks to my ridiculously strict and ultraprofessional programming style. Unlike many developers I don't have to waste my time fixing bugs, but I do have more problems with algorithms and larger program flows than any regular math-aware programmer. In the next exciting blog text I'm hopefully going to tell good news about level themes.