Weekly update MS04x21

I had some troubles related to other planes (foreground, background) when I added generation of them. Well, generation itself revealed couple of issues that I solved immediately and added few features - most minor, but one - blocking other connectors if one is chosen - works now pretty well and allows more freedom when designing pieces for generation.

But the biggest issue was how to move other planes in relation to main plane - room's interior. First I added something obvious, that was based on how perspective works. If character/camera moved to bottom, which is closer wall of room, it was just like camera would go to ground. User could see elements in foreground and in background. It looked quite ok, but problem arose when I moved character/camera to top - further wall of room. Then foreground moved further away and disappeared below edge of screen (just like in original), but top did same thing. After little bit of thinking I decided to do something that may feel weird when you start to think about it (but you can also rationalise it) - when camera is at bottom, foreground elements are in line with closer edge of room and you almost can't see background, but when camera is at top, background elemenst come closer to further edge of room, while foreground goes away.

There are some minor things that I'd like to do here, but they may wait a little bit. I want to focus now on vertical doors and then on travel system.

And why two weeks? I had few busy days as I changed job. I'll be still doing same thing (well, almost) but somewhere else :) I wonder how it will turn out, but in case it would be horrible, I can still go back. I hope ;)

Weekly update MS04x20

Alright, I started to work on foreground generation and got distracted with room types.

One of things that I really want to have in Dragontorc is ease of adding new content by random people. If someone wants to add new type of wall for castle rooms, they should only need to define that particular piece, give info about it and game should learn about it, where it should be used and use it only there. That's why I have tag system and tag conditions. With them, you can define room types (or regions, more on that later) that they are described as "medieval castle" (two tags, "medieval" "castle") and that that room type accepts pieces that have both of these tags. Actually tag condition can be used in more advanced way, making it possible to write "(darkage or medieval) castle". And with "disallow" tag condition it can avoid using fantasy elements (put "fantasy" in right place and all pieces tagged as fantasy won't be used).

And pieces may define kind of rooms. For example bookshelf may tell that it should be in "library" and new room will be defined that tells what "library" is. And if user wants, they may define "library" with given room type.

Stop. Room type? Kind of room? That's what is my problem here that naming is quite problematic. I will probably change it, but for now it is:

1. Region Type - region is area of similar graphics/mood in game. It might be castle, forest, village, stone henge and so on. It contains room of different types (kitchen, corridor, clearing, etc). Is defined with tags, collects pieces of similar tags
2. Room Type - I am considering to rename it to Room Template. It might be more general description of room, kitchen, library, that is not dependent on region (so it might be kitchen in castle or in space base).
3. Room (Kind) - I have no idea how to name it, it is just plain name of kind of room - kitchen, corridor, clearing and it used to differentiate various rooms within Region Type.
4. Room Pieces - various room pieces that are building blocks of each room. They may define Room (Kinds) within Room Type.

This sounds complicated when I try to write it quickly and some documentation will be required to describe it properly. But on the other hand, with examples (xml files with graphics) it should be very easy to understand and to use.

By the way, yes I am using lots of xml files and at the moment I have no need for editor but I'd like to see one being done in future - maybe even not by me :) This will of course require some tools to test stuff that could be run from commandline or integrated into actual editor, but that should not be complicated thing to do (not the commandline version).

Weekly update MS04x19

I had one week where I couldn't do anything.

But I did few things last week. Floor generation mostly that showed how many problems there are (well, were) with room generation. Were, because I fixed them this week, but I'll write about that here.

Room generation now creates walls, doors and floor (which was not present in original game). There are two ways to generate floor:

1. Start with boundary pieces, attached to walls, then fill rest with "tiles".
2. Fill everything with "tiles".

Tiles are not actual tiles, they are just pieces as anything else, so they don't have actually to tile :) This looks simple as an idea, but I really couldn't decide what to do with this, as I wanted to have floor connected to walls but at the same time, I wanted to have lots of pieces filling floor. Solution now seems obvious but it wasn't few weeks ago.

There are also starting pieces that land right in the middle of line closest to camera in the room that can limit tiles in nice way. I still need to add code not to clip them, so they can extend down in nice way.

And now bad things: when I run it (and it finally worked, as there were few minor issues, one of them related to my incorrect use of vala :( with c++ I would not do such thing in first place and I am more and more tempted to switch to c++) it took more than half a minute to generate 7 rooms. More than half a minute. That's way too long. I was logging a lot, so I cut some logs to be optional and it was still too long. I compiled without logging and debug info and it turned out to generate in less than a second (I didn't even try to measure it).

Why it was taking so long? I don't exactly know. I know that I did lots of things completely unnecessary. When room generator added new piece, its location was updated and then madness was beginning. Every piece was disconnected from each other and then reconnected basing on their location. And everything was checked if it intersects with each other. And while for walls and doors there were maybe 20 elements top, with floor it started to be 60 and most of checks were done against each other. Twice (because I was too lazy to do it properly in first place). I changed it to only do most of that stuff for last element added.

I did that to properly rebuild connections when something is removed and for removing pieces it still goes through that madness. But here's why. Some of connectors might be closed due to state of other connectors and while they are being closed when something is added, it seems to be fine, but when something is removed, it is much more trivial to disconnect everything and rebuild it. Of course it isn't right way and if I find room generation working too slow, I might decide to change that. But as it works now and there's no need to do anything more complex, I'd rather keep it as simple as possible.

What's for next (well, this) week? I'd like to add foreground and background generation and introduce subtypes for rooms. For now, without properly choosing them for map - this will have to wait for next milestone.

I hoped to do more during last few days but: a) I started to get addicted from War Thunder and already spend 30 hours flying - which is great way to relax and round time that lasts up to 30 minutes seems to be better choice to spend limited amount of time than coding, as this can easily extend to few hours. But then, after each round I have "one more" issue :( b) I actually didn't spend too much time next to computer, and when I did, I had other stuff to code (book-keeping app that recently made it possible for us to get rid of mortgage but as we want to keep some money just-in-any-case and maybe start a little business, we still have mortgage) c) we were going to restaurants almost every day last week and it was great :D and we should do this now, as soon we're going to have baby and with such small fellow we won't be able to go to few places for some time.