Size matters

Could not really follow my new development strategy. It was too harsh. I try to code as much as possible though and spend less time trolling on internet.

One of the difficult things in item data (and in generic level) is the size. I'm using relative abstract sizes for objects but even then editing data is hard: how to determine the size differences between items? For that purpose I made a visual debug routine which is simply showing items in different abstract size groups. That way I can visualize which items should belong to which group (instead of looking at the item data and get confused). Sizes are relative between object types so a big item is smaller than big monster.

What I hope to achieve from abstact sizes is still a good result to calculate stuff like weight without actually adding any static data for weight itself. The weight is calculated from material and size, plus maybe some other things like item type.

New development strategy

Back a while I tried to spend every other day programming which didn't work at all. So now I made a new rule that when I want to troll internet I first have to code something. Anything, even just refactor one function. I think it's actually working. I get stuff done and I can also troll internets. Even before I wrote this entry I refactored hidden item creation to check out if there are matching amount of places with intended amount of items.

Independent mask map

I'm using a mask map to mark generic tile types to mask values. The mask map is independent which means a mask value can be different than the usual value for that tile type. I think it's actually required, because rooms and caverns are different yet they of course share common tile types so there is no way to link masks to tile types itself. When I look at how room masks are determined it's a small miracle that it actually seems to work - in its own way. Room generation is still a task that needs work to be done, mostly in interior design but also in big complex room types.