A decision on creature definitions

[Smilex]

So I've been looking into how OpenDungeons reads and writes the map files, and I've noticed that it writes the creature definitions to the map files.
Because I understand creature definitions as being constant, this method boggles my mind, which is why I'm posting this; in hope that someone here might know more than me about this. Why would creature definitions be written to the map file, instead of being associated to a creature by some sort of id?
Also, now that we have XML files for the creature definitions, shouldn't it work for me to have the game load all creature xml files separately from the map, and then when the individual creatures are loaded from the map file, I simple associate them with the creature definitions? This should work if the creature definitions are constant, as in, they don't vary per creature, if the creature if the same type of creature.

[oln]

I'm not sure what the original motivation was, maybe to allow maps to have custom creature types. Though, I think the main reason is simply that they haven't been moved out of it yet.

Loading the creature types separately from the map sounds good.

[charlie]

I would guess that creatures might eventually evolve to be somewhat independent of their definition - experience, tasks, AI flags etc. Then again, surely those characteristics could be saved independently too.

Perhaps, as oln suggests, it was easier to just [de]serialize like that with the intention of refining it later?

[paul424]

Unburing this thread,
I just want you know I started slowly moving Test.level into XML files.
Creatures are in XML directory .... Other Entities to be moved as well soon ....
What we should do with the map ? It's bag of triples : X Y tile_type ; There are not many of those lines in Test.level cause the default tile ( that is the Dirt tile ) is not being coded everywhere and that's the defuallt value of tile when initialized and map loading . So how do we compress the tiles layout AND use xml ? Any ideas ? I thought of making embeddable containers like <Rectangle type=Dirt begin_x=... begin_y> more rectangles to embed .... :P </Rectangle> ...
If we wannt more shapes ... than would be nice to make those figures be drawable in Editor.
Than to many nesting and shapes would make the layout file hard to read ....

[nido]

What we should do with the map ? It's bag of triples : X Y tile_type. There are not many of those lines in Test.level cause the default tile ( that is the Dirt tile ) is not being coded everywhere and that's the defuallt value of tile when initialized and map loading . So how do we compress the tiles layout AND use xml ?

There are also a limited numbers of tile_type. Some decidedly neutral; dirt, stone, undiggable, gold. Some not: claimed, and rooms. Still, it may make sense to save this information as a bitmap of sorts. I don't think it adds value to save the maps themselves as xml, but it may be advisable to use an encoding when including it in savefiles.

[Bertram]

Hi there,

Why not simply use an array for the map?
This would make it easier for quick-fix editing and is much more readable, IMHO.

E.g:
0: Empty dirt ground
1: Dirt wall
2: Lava
3: water
...

{l Code}: {l Select All Code}

<map sizeX="5"  sizeY="5">
1,1,1,1,1
1,2,0,0,1
1,2,0,0,1
1,0,3,3,1
1,1,1,1,1
</map>

This, btw, raises another flaw we should fix. We should make the engine not draw a ground under the room tile anymore since it makes glitches happen when you elevate the camera height.

Also, I do think rectangles shapes should be used only for rooms, but not for tiles as it would make this unreadable otherwise, IMHO.
Ah, and can we stop using negative tile coords? this would permit us to have the (0,0) top-left and this way we wouldn't need to define the tile coords anymore, would the array solution be taken.

Best regards,

[nido]

Why not simply use an array for the map?...

A few observations, your example map was 5x5 and already quite sizeable. Having a 40x40 map already takes roughly default sized text window in width (commas), and ~2 pages and the test map seems significantly larger already.

Also there may be more rooms then we can enumerate. adding water and lava to my list makes 6 'neutral' tiles, using a limit of 4 keepers, this would leave us with 0 rooms if you want to keep to a single digit, as there exists a 'claimed' tile for all keepers. using capitalised and noncapitalised letters, gives us ~16 possibilities. We can extend the number of characters used to describe a tile, but this would compound on the wideness problem described earlier.

Nevertheless, I do think it is a better idea then to enumerate every tile. or compose patches of nondefault tiles. Personally, I do not think such a map can be described textually in a more reasonable way, and am therefor partial to a binary format. But provided we want to do the map in xml I would consider this a good solution.

Also, I do think rectangles shapes should be used only for rooms, but not for tiles as it would make this unreadable otherwise, IMHO.

I am sorry, but I do not understand what you mean here.

Ah, and can we stop using negative tile coords? this would permit us to have the (0,0) top-left and this way we wouldn't need to define the tile coords anymore, would the array solution be taken.

sounds like a good idea to me.

[Bertram]

Hi Nido,

A few precisions maybe:

A few observations, your example map was 5x5 and already quite sizeable. Having a 40x40 map already takes roughly default sized text window in width (commas), and ~2 pages and the test map seems significantly larger already.

The format width doesn't really bother, as long you can visually decipher it.

Also there may be more rooms then we can enumerate.

Just a precision, for later discussion, let's not mix room tiles (forge beds, training) with standard tiles for now. I also do think claimed tiled should be seen as a sort of empty room tile, since it's the base of it.

I am sorry, but I do not understand what you mean here.

Np. based on what I said above, and as an answer to Paul, I was proposing to have standard tiles into an array (binary or not), and rooms (and claimed tiles) as patches (Rectangles as Paul said), just like that:

E.g:

{l Code}: {l Select All Code}

<!-- The map -->
<map sizeX="10"  sizeY="10">
1,1,1,1,1,1,1,1,1,1
1,2,0,0,1,0,0,0,0,1
1,2,0,0,1,0,0,0,0,1
1,0,3,3,1,1,0,0,0,1
1,1,1,1,1,1,0,0,0,1
1,1,1,1,1,1,0,0,0,1
1,2,0,0,1,0,0,0,0,1
1,2,0,0,1,0,0,0,0,1
1,0,3,3,1,0,0,0,0,1
1,1,1,1,1,1,1,1,1,1
</map>

<!-- Some claimed tiles -->
<room team="2" type="none">
    <Tile x="5" y="1" x_end="7" y_end="3" />
    <!-- ... -->
</room>

<!-- Temple -->
<room team="2" type="temple">
    <Tile x="5" y="4" x_end="7" y_end="7" />
</room>


Best regards,

[nido]

Just a precision, for later discussion, let's not mix room tiles (forge beds, training) with standard tiles for now. I also do think claimed tiled should be seen as a sort of empty room tile, since it's the base of it.

On the subject of beds, which creatures create in a lair, I would agree. On the latter, I shall comment further down.

Np. based on what I said above, and as an answer to Paul, I was proposing to have standard tiles into an array (binary or not), and rooms (and claimed tiles) as patches (Rectangles as Paul said), just like that:
<code>

Thank you for your explanation. I must admit though I am not a fan of the rectangles approach. tiles can be either dirt, or blue's training room, or red's hatchery, or any of the other possible rooms. whilst patches are a compact way of describing square rooms, which i admit would be the most desirable room configuration; it would allow for a myriad of different ways to represent the same room, as well as allowing the definition of illegal room configurations (e.g. a lavatile containing three diffferent red hatcheries, one of blues temple tiles, greens training room, and yellow has claimed it). Whilst these situations shouldn't happen, hand editing and programming errors make it very likely for these situations to appear and we should account for it in one way or another. Therefore, I propose we include all room types into the tile definition as well, so these situations would be impossible to begin with.

[Bertram]

I must admit though I am not a fan of the rectangles approach.

Me neither. Rectangles or zones are useful to set up a trigger but they don't cope well with map definition, from the reasons you gave.

tiles can be either dirt, or blue's training room, or red's hatchery, or any of the other possible rooms.
[...]
Therefore, I propose we include all room types into the tile definition as well, so these situations would be impossible to begin with.

Well, there is something that is still preventing me from fully agree yet, but it's a matter of finding a proper solution to it.

As you said, a tile can be a wall, ground or someone's ground or room. (and later, someone's wall if we add reinforced walls support).
With the array/bitmap approach, how can we setup potential ownership of a tile?

Best regards,

[nido]

With the array/bitmap approach, how can we setup potential ownership of a tile?

The simplest way is to consider blue's rooms and red's rooms totally different structures (e.g. blue's hatchery is tile type '6', red's hatchery tile type ' 7'). Advantage of this is that it would allow for the least amount of error as it is the most simple map representation.

Another way is to define the ownership as part of the type (e.g. blues hatchery is tile type b6, reds hatchery is r6). This approach would allow for certain illegal combinations (e.g. blue's inpenetratable rock), though we can ignore these quantifiers or error out with an 'illegal room type' error as well (effectively using the former model when parsing). With this, we can make 'reinforced walls' by making that particular rock tile owned by the reinforcing player; and it allows to easily add an arbitrary number of keepers whilst the former approach would need us to define the structures explicitly for each possible keeper

[oln]

If you store the tiles as e.g 32-bit integers in a binary array, you can use some bits for ownership, some bits for type, some bits for room type, etc. XML isn't ideal for storing raw data, such as map.

[nido]

If you store the tiles as e.g 32-bit integers in a binary array

Oh, another idea. Let us also begin with putting the actual map tiles at the beginning of the file. Next, use only 24, preferably 16 or 8 of those bits to define the room type; use the remaining to define the owner. You can now load the map as a raw 32 bit image (8 bit transparency on always-on). and edit it as such. Other possibilities include 8, 16 or 24 bit integers depending if we need more then 256, 65536 or 16777216 possible room types.

[Bertram]

The ideas given there are quite good, but there is something bothering me. Please, let's not fall once again in potential endianess problems using raw binary data, though.

Plus, I forgot, but we'll have to store the tile fullness, which can be either 0, 25, 50, 75 , or 100. (%)

In any case, I'd like to keep having the simple array solution, since it would make things much easier to debug, for everyone.

There are three solutions I'd see so far, from the most preferred to the least. Thanks for all the ideas about it, btw.

1. Use Nido's idea about having string-based tile value. (My favourite one so far, thanks Nido.). Eg:

The first digit is the team number ownership (0 for none).
The letter gives the tile type:
L: Lava
W: Water
D: Dirt
T: Temple
...
the second digit gives the fullness:
0: 0% (ground tile. I'd suggest to use 0 for rooms or maybe we could use this as a HP value?)
1: 25%
2: 50%
3: 75%
4: 100%

We'd have this, for instance:

{l Code}: {l Select All Code}

<!-- The map -->
<map sizeX="10"  sizeY="10">
0D4,0D4,0D4,0D4,0D4,0D4,0D4,0D4,0D4,0D4
0D4,0L4,0D0,0D0,0D4,0D0,1T0,1T0,1T0,0D4
0D4,0L4,0D0,0D0,0D4,0D0,1T0,1T0,1T0,0D4
0D4,0D0,0C4,0C4,0D4,0D4,1T0,1T0,1T0,0D4
0D4,0D4,0D4,0D4,0D4,0D4,0D0,0D0,0D0,0D4
0D4,0D4,0D4,0D4,0D4,0D4,0D0,0D0,0D0,0D4
0D4,0W4,0D0,0D0,0D4,0D0,0D0,0D0,0D0,0D4
0D4,0W4,0D0,0D0,0D4,0D0,0D0,0D0,0D0,0D4
0D4,0D0,0W3,0W3,0D4,0D0,0D0,0D0,0D0,0D4
0D4,0D4,0D4,0D4,0D4,0D4,0D4,0D4,0D4,0D4
</map>

2. an hybrid solution based on the binary approach keeping the array:

I'd propose to use bitmask values that we would merge and save as ints. Eg:

// Rooms/tiles bitmask values
int32 EMPTY = 0;
int32 DIRT = 1;
int32 ROCK = 2;
int32 CASTLE = 4;
int32 WATER = 8;
int32 LAVA = 16;
int32 TEMPLE = 32;
...

// Fullness
int32 ZERO = 0;
int32 25_ = 128;
int32 50_ = 256;
int32 75_ = 512;
int32 100_ = 1024;

// ownership bitmasks
int32 NO_OWNERSHIP = 0;
int32 PLAYER_1 = 2048;
int32 PLAYER_2 = 4096;
...

example of saved value:
int32 tileValue = CASTLE | PLAYER_1 | 100_;

{l Code}: {l Select All Code}

<!-- The map -->
<map sizeX="10"  sizeY="10">
1025,1025,1025,1025,1025,1025,1025,1025,1025,1025
1025,1026,0,0,1025,2080,2080,2080,0,1025
1025,1026,0,0,1025,2080,2080,2080,0,1025
1025,0,1027,1027,1025,1025,2080,2080,2080,1025
1025,1025,1025,1025,1025,1025,0,0,0,1025
1025,1025,1025,1025,1025,1025,0,0,0,1025
1025,1026,0,0,1025,0,0,0,0,1025
1025,1026,0,0,1025,0,0,0,0,1025
1025,0,1027,1027,1025,0,0,0,0,1025
1025,1025,1025,1025,1025,1025,1025,1025,1025,1025
</map>

I'm not sure about this one, though, especially when we add more room/tiles/traps.

3. Store the tile/room/trap id, the ownership, and the fullness in separate 'layers'. This means we wouldn't have one array, but three.
(The less optimized solution, and not really readable, unfortunately.)

What do you think?

Best regards,

[nido]

The ideas given there are quite good, but there is something bothering me. Please, let's not fall once again in potential endianess problems using raw binary data, though.

This is a valid concern which I think can be addressed by defining our data as a certain type of endianess. I believe instructions are available to read in data in a certain endianess regardless of that of the host system.

Plus, I forgot, but we'll have to store the tile fullness, which can be either 0, 25, 50, 75 , or 100. (%)

Good point. one observation though, there are 4 types of regular rock tiles (4/4 3/4 2/4 1/4) and dirt (0/4). However, we most likely want to know a lot bigger range of states for the gold tiles. If i am not mistaken, they hold 1020 gold in the original dungeon keeper. Whilst we can pick any number, I fear a maximum of 4, or taking the whole range, 9 gold tile states would not be enough.

The first digit is the team number ownership (0 for none).

in this i would like to suggest a space/nothing for no ownership, and keep 0 reserved for the neutral 'keeper'.

2. an hybrid solution based on the binary approach keeping the array: I'd propose to use bitmask values that we would merge and save as ints.
<snip>
// Fullness
int32 ZERO = 0;
int32 25_ = 128;
int32 50_ = 256;
int32 75_ = 512;
int32 100_ = 1024;

I like the idea of using these lower bits as the fullness, but rather then to create these macros, use the full range of the n bits we choose for this purpose and blow up the effect of the digging creature accordingly. This would also solve the gold problem as we can have up to 2^n gold in a gold tile before it breaks. Later, we could then easily decide that a creature doing excessive area damage may also damage the wall (a lot less then actual digging does).

[Bertram]

Hi nido,

This is a valid concern which I think can be addressed by defining our data as a certain type of endianess. I believe instructions are available to read in data in a certain endianess regardless of that of the host system.

Yep, but it's making it less readable for humans though.

Good point. one observation though, there are 4 types of regular rock tiles (4/4 3/4 2/4 1/4) and dirt (0/4).

Just in case, rock and dirt tiles are both wall types. Atm, rocks can't be dug.
When any wall type has got a 0% fullness, it turns into a ground tile, passable for creatures.

However, we most likely want to know a lot bigger range of states for the gold tiles. If i am not mistaken, they hold 1020 gold in the original dungeon keeper. Whilst we can pick any number, I fear a maximum of 4, or taking the whole range, 9 gold tile states would not be enough.

That's a good point. So instead of 0-4 values, we could have 0-100 (or even more in fact) values for tile fullness, and why not rooms/traps HP.
If I remember well, in DK there were crystal tiles that you could dig for a very long time. Those ones should be readded sometimes in the futures for more twisted scenario, IMHO.
Thus, implying we could have a scale from 0 to well, a lot, but 0-100 by default.

in this i would like to suggest a space/nothing for no ownership, and keep 0 reserved for the neutral 'keeper'.

Fine to me.

I like the idea of using these lower bits as the fullness, but rather then to create these macros, use the full range of the n bits we choose for this purpose and blow up the effect of the digging creature accordingly. This would also solve the gold problem as we can have up to 2^n gold in a gold tile before it breaks. Later, we could then easily decide that a creature doing excessive area damage may also damage the wall (a lot less then actual digging does).

I see your point, but this is far more limited in any case that the option of using <ownership digit><tile type letter><HP/fullness value>, IMHO.

Best regards,

[nido]

Yep, but it's making it less readable for humans though.

Since the actually representation does not change when you say "this data is big/little/network/whatever endian", and with that, the readability doesn't change in my opinion. I agree it will be harder to read this file as a text file then it would be.

Good point. one observation though, there are 4 types of regular rock tiles (4/4 3/4 2/4 1/4) and dirt (0/4). Just in case, rock and dirt tiles are both wall types. Atm, rocks can't be dug.
When any wall type has got a 0% fullness, it turns into a ground tile, passable for creatures

We can really use a dictionary to clearify these points. Sorry for mixing up tile types.

If I remember well, in DK there were crystal tiles that you could dig for a very long time.

Actually, these had infinite gold and were quite prevalent as your main gold source. If you dont want to model this explicitly; you can even add this as a gold tile with 0 gold remaining.

Those ones should be readded sometimes in the futures for more twisted scenario, IMHO. Thus, implying we could have a scale from 0 to well, a lot, but 0-100 by default.

I like the idea of a 'big' gold tile being a central point in one of the campaigns. I also don't think it would be a bad idea to have a semi-random amount of gold available in gold tiles, as opposed to each having exactly 1020 (or however many) gold.

I see your point, but this is far more limited in any case that the option of using <ownership digit><tile type letter><HP/fullness value>, IMHO.

Using n-bit numbers to represent tiles leave for 2^n possible tiles. <number><letter><number> has two numbers which can grow infinitely large, therefore indeed giving more possibilities. However, I doubt the amount of possibilite configurations for a 32bit or even 24 bit number would be a problematic limitation. Do realise too that we are already considering 4-digit fullness numbers in some cases (I really like the idea of optionally posessing a creature and kicking the shit out of walls or throwing stuff at it in order to destroy them). Nevertheless, textual representations can have their advantages.

[Bertram]

Ok, you're right. So if I try to sum up where the consensus is, the last main thing to decide is whether we go using binary values, or whether we'll use text based ones.

I'm not surprisingly voting to go text based, since it would make things easier to integrate to the current map format, for instance, and into the next one, btw,
and also because I 'd code it rather easily, would I have to do it myself.
But I'm not alone here. Anyone? Nido?

Best regards,

[nido]

I would have no objection against the text format.

This does leave me to make an observation though. The title of this thread is 'a decision on creature definitions', though we have hiked over to the (not unimportant) part of maps. Is creature definitions still the problem it was when this thread was posted first?

[Bertram]

Eh eh. It seems we're both quite some topic hi-jackers.

But the consensus about this topic was already approved. I mean it has already been decided to store into (and read creature definitions) from a different file.

But do not mix this with spawn pools that depends on each maps, even if for now, both concepts are merged within the creature definitions in the level file.