Current state of text based levelformats

Discussion around programming R'n'D, its source code and its tools.

Moderators: Zomis, Flumminator

dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave » Sat Jan 05, 2008 9:32 pm

Steffest wrote:I updated http://www3.stef.be/projects/boulderflash/bdcff/ again with structures for the Yam content, notes, and several scores and times for the EM objects.
i have posted some files which you might find useful.
http://www.geocities.com/atwukonn/
it is information on the structure used when loading emerald mine caves. currently in my player, only binary EMC caves are converted to this structure, but when i develop an ascii-based level format, that will also be converted to this struct.

note it is not 100% compatible with EMC caves, so i will keep supporting the binary format too.

cheers,
dave

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Sun Jan 06, 2008 9:06 am

Hm, the RND_ID can change at any time, so we should take the "element_name"!!!
Like as for Dave's engine or for other. I think Dave mean this in his last post.
For the (old) engines its may be usefull to have the internal id,
when it is sure that nobody delelop on it.
Ok the internal id is nice to have if someone what to write a converter.


-------------------------------------------------

Some problems to convert element names.
In your proposal you use this:

Code: Select all

     1;SPACE                              ; ;  ;BD;empty_space;
     2;DIRT                               ;.;..;BD;sand;
     3;WALL                               ;w;Ww;BD;wall;
     4;MAGICWALL                          ;M;WM;BD;magic_wall;
     5;OUTBOX                             ;X;XX;BD;exit_closed;
     6;OUTBOXopen                         ;Y;XY;BD;exit_open;
     7;HIDDENOUTBOX                       ;H;XH;BD;;#unknown;
     8;HIDDENOUTBOXopen                   ;I;XI;BD;;#unknown;
     9;STEELWALL                          ;W;Ws;BD;steelwall;
    10;FIREFLYl                           ;Q;ol;BD;bd_firefly.left;
    11;FIREFLYd                           ;o;od;BD;bd_firefly.down;
    12;FIREFLYu                           ;O;ou;BD;bd_firefly.up;
    13;FIREFLYr                           ;q;or;BD;bd_firefly.right;
    14;BOULDER                            ;r;rr;BD;bd_rock;
    15;DIAMOND                            ;d;dd;BD;bd_diamond;
    16;INBOX                              ;P;P1;BD;player_1;
    17;HEXPANDINGWALL                     ;x;Wx;BD;expandable_wall_horizontal;
    18;VEXPANDINGWALL                     ;v;Wv;BD;expandable_wall_vertical;
    19;EXPANDINGWALL                      ;V;WV;BD;expandable_wall_any;
    20;BUTTERFLYd                         ;c;bd;BD;bd_firefly.down;
    21;BUTTERFLYl                         ;C;bl;BD;bd_butterfly.left;
    22;BUTTERFLYu                         ;b;bu;BD;bd_butterfly.up;
    23;BUTTERFLYr                         ;B;br;BD;bd_butterfly.right;
    24;AMOEBA                             ;a;am;BD;amoeba_dry;
    25;SLIME                              ;s;sl;BD;;#unknown;
   132;DUMMY                              ;F;PF;BD;;#unknown;
In RND this is IMHO better matching (Replacement in uppercase is no real BD element):

Code: Select all

     1;SPACE                              ; ;  ;BD;empty_space;
     2;DIRT                               ;.;..;BD;sand;
     3;WALL                               ;w;Ww;BD;bd_wall;
     4;MAGICWALL                          ;M;WM;BD;bd_magic_wall;
     5;OUTBOX                             ;X;XX;BD;EM_EXIT_CLOSED;
     6;OUTBOXopen                         ;Y;XY;BD;EM_EXIT_OPEN;
     7;HIDDENOUTBOX                       ;H;XH;BD;EM_STEEL_EXIT_CLOSED;
     8;HIDDENOUTBOXopen                   ;I;XI;BD;EM_STEEL_EXIT_OPEN;
     9;STEELWALL                          ;W;Ws;BD;steelwall;
    10;FIREFLYl                           ;Q;ol;BD;bd_firefly.left;
    11;FIREFLYd                           ;o;od;BD;bd_firefly.down;
    12;FIREFLYu                           ;O;ou;BD;bd_firefly.up;
    13;FIREFLYr                           ;q;or;BD;bd_firefly.right;
    14;BOULDER                            ;r;rr;BD;bd_rock;
    15;DIAMOND                            ;d;dd;BD;bd_diamond;
    16;INBOX                              ;P;P1;BD;player_1;
    17;HEXPANDINGWALL                     ;x;Wx;BD;bd_expandable_wall;
    18;VEXPANDINGWALL                     ;v;Wv;BD;bd_expandable_wall;
    19;EXPANDINGWALL                      ;V;WV;BD;bd_expandable_wall;
    20;BUTTERFLYd                         ;c;bd;BD;bd_butterfly.down;
    21;BUTTERFLYl                         ;C;bl;BD;bd_butterfly.left;
    22;BUTTERFLYu                         ;b;bu;BD;bd_butterfly.up;
    23;BUTTERFLYr                         ;B;br;BD;bd_butterfly.right;
    24;AMOEBA                             ;a;am;BD;bd_amoeba;
    25;SLIME                              ;s;sl;BD;QUICKSAND_EMPTY;
   132;DUMMY                              ;F;PF;BD;;#unknown;
So again, who can we cover a level where the autor want to use both a normal "WALL" and a "BD_WALL" and a so called "EM_WALL"?
Or in other words, how should handled a "WALL" when it is defined in a BDCFF level file, and we use engine=BD or engine=EM?
To avoid trouble we should made BD_xxxx elements and EM_xxxx or even EMC_xxxxx or SP_xxx elements where is a overlapping.
Hm, on the other side RND have only one "SAND" and only a "BD_WALL" and a normal "WALL", but not a "EM_WALL".
Please discuss it here before you change anything.

@Holger: What do you think?


Btw: The new rndTest325-tc8 can convert your proposal to "bdcff.conf".
And the answer is ... 42 !

Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest » Mon Jan 07, 2008 1:49 am

Dave said:
i have posted some files which you might find useful.
http://www.geocities.com/atwukonn/
Thanks Dave!
Great help.
I never bothered much with the EMC additions to Emerald mines, but now I notice I misted a few properties.
wind_time: hmm ... I always thought the wind_time was infinite ... I guess I should check out the EMC editor you pointed out earlier.

Cacid_1,
Cacid_2,
Cacid_3,
Cacid_4,
Cacid_5,
Cacid_6,
Cacid_7,
Cacid_8,

and

Cameuba_1,
Cameuba_2,
Cameuba_3,
Cameuba_4,
Cameuba_5,
Cameuba_6,
Cameuba_7,
Cameuba_8,

Those are just different animation steps of Acid and Amoeba, right?
do they occur as such in cave design data?
I never noticed that.

Cemerald_force_e and other "force" elements ... hmm
do they also occur as such in cave design data?
I never noticed that also, hehe :-)

Seems like a very complete list, I'll base the BDCFF on this, trying to differentiate between common EM objects, EMC objects and something like "EM extended" objects, like the different Acid animation steps.
(I think there should be 1 EM_ACID element in the Basic EM subset table, and the rest in the "extented" table, because the acid2-8 are just cosmetics and only important if you want to have a 100% recreation of the original cave.)
But still: if they ever occur in cave designs, they should be somewhere on the list.

Thanks again ! I know I could dig this up in your source code, but it helps if you point me in the right direction.
Steffest

Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest » Mon Jan 07, 2008 2:07 am

To avoid trouble we should made BD_xxxx elements and EM_xxxx or even EMC_xxxxx or SP_xxx elements where is a overlapping.
Yes, I see the point in that now.

let's forget about the internal ID's for now ... after all, its up to the engine how it interpretes the different BDCFF elements.
I never ment for the internal ID's to have something to do with the engine, but more as a conversion table for the native level-formats of that engine.

I've reread the original BDCFF proposals and it was the intention from the beginning to define a new element for every slight variation of an overlapping object (for example a rock, or a bomb) and to have subsets of the BDCFF element list where an engine (or a level designer) could target on.

So I think we have (at least) the following subsets
BD (basic Boulderdash)
BDextended (elements that came later, like Bladder)
BDinternal (elements not meant for cave design, but other purposes, like the delayed elements)
EM (Basic Emerald Mines)
EMC (EMC upto EMC6 elements)
EMCextended (elements that don't add new behaviour, but are internal or cosmetic in nature)
SP (Supaplex elements)
SO (Sokoban elements)
DC (Diamond caves elements)
RnD (Rocks'n'Diamonds elements)
DX (DX Boulderdash elements)

And indeed, for overlapping elements, the naming should include the subset, like EM_WALL, EM_DIAMOND ....

Am I missing some games/gametypes that should be included?
XOR maybe ?

Steffest

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe » Mon Jan 07, 2008 6:39 am

Steffest wrote:And indeed, for overlapping elements, the naming should include the subset, like EM_WALL, EM_DIAMOND ....
Only problem is the compatibility to existing BDCFF files. Those are all BD1, BD2 or PLCK and they don't use names like BD_DIAMOND. For the 1stB and CrLi extensions, naming them with BD_ would be no problem as there are no BDCFF files of them, yet. On the other hand, the result would be somewhat inconsistent, then.

Maybe, we should do that initials thing for any non-c64 engines only, because of that. After all, Atari 8 bit and C64 were first and deserve those simplified treatments.
For later clones, it makes sense to use those initials throughout for the sake of consistency.

Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest » Mon Jan 07, 2008 8:33 am

ah yes, offcourse: existing names shouldn't be changed.
I the case of BDCFF, I think its a valid assumption that if no engine or property is specified, then its about BD elements.
only the EM and SP etc ... would have that naming.

Maybe for clarity all elements that e.g. EM adds should be named EM_... , not just the overlapping ones.

Steffest

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Mon Jan 07, 2008 11:32 am

Maybe for clarity all elements that e.g. EM adds should be named EM_... , not just the overlapping ones.
Yes, this is the best way.
Except BD elements like "DIAMOND" as LogicDeLuxe said.

Please post it when you are ready with renaming,
so we can edit or add elements.
And the answer is ... 42 !

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Mon Jan 07, 2008 11:50 am

Those are just different animation steps of Acid and Amoeba, right?
If they are only animation steps, they should not added to any element list, because this handles each engine different.

Eg. even the "falling" elements in LogicDeLuxe proposal are handled from
most tools/engine as normal elements - I think.
(I know that the behaviour is a little bit different).
And the answer is ... 42 !

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe » Mon Jan 07, 2008 12:23 pm

HerzAusGold wrote:
Those are just different animation steps of Acid and Amoeba, right?
If they are only animation steps, they should not added to any element list, because this handles each engine different.

Eg. even the "falling" elements in LogicDeLuxe proposal are handled from
most tools/engine as normal elements - I think.
At least for altering the effect table, all BD elements should be available, also those not useful to be used in a map. Keep in mind that in BD, those animation sequences are not just animation steps, but every single stage of them may be altered with an effect command.

Maybe EM is different. At least, I don't know an EM engine with such a Lord Diego Effects concept, or if this would be even possible with the engine mechanics.

Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest » Mon Jan 07, 2008 1:13 pm

If they are only animation steps, they should not added to any element list, because this handles each engine different.
Hmm, if these elements are ever used in a cave design, then they must.
or else you never could recreate the level 100% the same as some information would be lost.

in the case of Dave's list of the EMC engine, whith the different Acid and Amoeba animation steps, you could have a nice wobbly acid, or a nice wobbly amoeba where not every tile animates in the same sync.

An engine could convert those all to the same tile.
The cave would still be playable, but not 100% the same.
if an engine has the ability to render e.g. EM or BD caves with 100% accuracy, then the levelformat should also be able to provide 100% of all original cave details.
therefore, those elements should be somewhere in the list (a bit buried maybe, but still there somewhere)

Some engines have elements that are purely cosmetical and never used in cave-designs and these serve no purpose in a BFCFF so should not be included.
For example: DX-boulderdash has the option to render dirt and walls with slightly different tile-graphics to make the appearance less monotone, but this is just in the engine, not in the levedata.

I'll try to update the naming and add the subset-selection this week.

never thought this would grow in such a nice discussion :-)
Steffest

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Mon Jan 07, 2008 5:16 pm

LogicDeLuxe wrote:
At least for altering the effect table, all BD elements should be available, also those not useful to be used in a map. Keep in mind that in BD, those animation sequences are not just animation steps, but every single stage of them may be altered with an effect command.

Maybe EM is different. At least, I don't know an EM engine with such a Lord Diego Effects concept, or if this would be even possible with the engine mechanics.
Yep, the elements for the "effects" should be in the list.
Steffest wrote about the animation steps
Nice wobbly or not, the level keep playable.
So I see no reason to keep this information.
Think about a Diamond which is sometimes blinking.
Or the player in RnD he is sometime smooking, reading newspaper...

If wobbly is really a needed feature, more sense is a element like this:
BD_AMOEBA_RANDOM_WOBBLY
But not the exact "wobble state".

...Now I wobble to my chair... :D
Steffest wrote:
never thought this would grow in such a nice discussion
So put credits of all discussion members to your proposal ;)
And the answer is ... 42 !

dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave » Wed Jan 09, 2008 3:58 am

Steffest wrote:wind_time: hmm ... I always thought the wind_time was infinite ... I guess I should check out the EMC editor you pointed out earlier.
i added a few more options for things which i thought would be useful. everything else used a timer (wheel, wonderwall) so i thought wind should too.
i also changed the magic ball to have a 3x3 programmable output because eaters were like that. in my old engine i even had 8 lots of 3x3 output, but i decided it wasnt as useful so it got changed back to 1.
note these changes fully support the original behaviour (set wind time to 9999, make 3x3 all the same object in the ball).
i forget if i made other changes. probably :)
Steffest wrote:Cacid_1,Cacid_2,Cacid_3,Cacid_4,Cacid_5,Cacid_6,Cacid_7,Cacid_8
these all have unique codes in the EM binary file format. animations in em are fixed at 8 frames, so longer animations need more codes (so it cycles through the states). exactly like the 3 codes for open exits. holgers (apparently buggy) improvements to the gfx engine could sort of handle it with one code, but then all acid animations would be locked together (eg. you wouldnt be able to have nice patterns)
Steffest wrote:Cameuba_1,Cameuba_2,Cameuba_3,Cameuba_4,Cameuba_5,Cameuba_6,Cameuba_7,Cameuba_8
these are not animations. they are equivalent to decor or the 4 different steel/wall/etc images. these occur in caves from the beginning.
Steffest wrote:Cemerald_force_e and other "force" elements ... hmm
do they also occur as such in cave design data?
these have been there from the beginning but they are really internal codes. however, they have interesting behaviour in themselves and they add something to the game (even though originally i resisted adding them). i extended it to include rolling emeralds & diamonds (as a logical continuation, but not in emc caves).
Steffest wrote:Seems like a very complete list, I'll base the BDCFF on this, trying to differentiate between common EM objects, EMC objects and something like "EM extended" objects, like the different Acid animation steps.
it's enough to play 99% of caves & will be the only objects allowed in my editor (when i get around to coding it).
for _every_ object from emerald mine, look in filter.c in the conv/ source (i'll post it on http://www.geocities.com/atwukonn/ ). it is harder to read, but it has every code spelled out. the trouble is there is slight variations between the versions, so if you want to put it in your BDCFF thing, you'll probably need to differentiate between versions (at least kingsoft, v5, v6).
plant springs to mind as being a problem. it is a sort of grey area to when it appeared (ive seen it in pre-v5 caves, but it's not in kingsoft's player).
the copyright letter also. some minor variations that make a big headache for an exact archiving of caves.

HerzAusGold
Posts: 326
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Wed Jan 09, 2008 8:20 pm

Dave wrote:
Cameuba_1,Cameuba_2,Cameuba_3,Cameuba_4,Cameuba_5,Cameuba_6,Cameuba_7,Cameuba_8

these are not animations. they are equivalent to decor or the 4 different steel/wall/etc images. these occur in caves from the beginning.
Hm, can you give an example?
Dave wrote:
the copyright letter also. some minor variations that make a big headache for an exact archiving of caves.
The copyright letter is always CHAR_COPYRIGHT.
It's up to the graphic set to cover different variations.
The behaviour is the same for playing.

The same for the plant or springs too.

To sum it up, if the behaviour is the same for playing we should have only
one "element code"!
Or (if really needed) a element code "ACID_RANDOM_WOBBLY" for a nice pattern.

Please don't blow up the BDCFF file format with "animations" or different "graphic".
And the answer is ... 42 !

User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe » Wed Jan 09, 2008 9:00 pm

dave wrote:the trouble is there is slight variations between the versions, so if you want to put it in your BDCFF thing, you'll probably need to differentiate between versions (at least kingsoft, v5, v6).
That's where the Engine attribut cames in handy, which we just discussed here. Furthermore, some Type/Properties attributes could be defined for them like I did for Amoeba, Magic Wall, border behavior etc..
HerzAusGold wrote:To sum it up, if the behaviour is the same for playing we should have only
one "element code"!
Or (if really needed) a element code "ACID_RANDOM_WOBBLY" for a nice pattern.

Please don't blow up the BDCFF file format with "animations" or different "graphic".
I agree, that there are things which do depend on the graphics set and there is really no need to cover those with the BDCFF.

I don't agree that we only need one element in cases where the behavior is the same, though. The most obvious examples are the letters, which do behave all the same since the only difference is the way they look. Would be rather silly to have them all the same graphic. Other elements which only differ in graphics also may be well used to give hints, thus they can be more than just cosmetic in nature.

As far as the animations of C64 graphics concerns, they have no relation to the game physics and can not be influenced with the game data (besides disabling some of them in BD1/BD2 for performance reasons).
Explosions being the exceptions, as they do display their actual progress, and we need them for effect table alterations. And since they are placeable elements in CLCK, having map codes of them makes sense too.

Btw., I don't think that we need map codes for OUTBOXopen and HIDDENOUTBOXopen. They are for effects. And while it is possible to have them in a map, there is no editor in which you can place them, afaIk.

Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest » Wed Jan 09, 2008 11:12 pm

Btw., I don't think that we need map codes for OUTBOXopen and HIDDENOUTBOXopen. They are for effects. And while it is possible to have them in a map, there is no editor in which you can place them, afaIk.
They are sometimes used in Emerald Mines though (usually encased with steel wall so you can never reach them, just to tease)
HerzAusGold wrote: Please don't blow up the BDCFF file format with "animations" or different "graphic".
and
LogicDeLuxe wrote: I agree, that there are things which do depend on the graphics set and there is really no need to cover those with the BDCFF.
Hmmm ... I'm afraid I disagree a bit.
If you let me quote one of the "Founding Fathers" (LOL :lol: ) of BDCFF, Peter Broadribb:
Peter Broadribb wrote:It needs to be able to potentially support all the existing caves in all the existing various implementations of BoulderDash
And my "supporting" I think is meant that a cave comes out just the same as it goes in (in an engine that supports all features of the cave)
Therefore, if a cave gets mangled just because the levelformat can't describe the cave accuratly, then its not a good levelformat and it will end up not being used, or superseded with something else.
If we can make BDCFF good enough so that it can hold al Emerald Mine caves without losing any data, then maybe it will get picked up by people like Dave that would use it as native fileformat for his Emerald player (Hmm sounds like a hint ! :lol: )
There i still feel that "somewhere" these elements should be defined.
(but perhaps in a seperate subset that is tucked away under the more comon elements)
Maybe this is "blowing up" the fileformat, but better a blown up fileformat that is usefull (and therefore will be used) then a fileformat that won't be adopted because of its limitatons.

Otherwise, one might argue that all those different wall-tiles are "cosmetic" too, or that an acidbox might as well be a wall, or that the leveltime can be tossed out, because all levels would still be playable with infinite leveltime ... (Ok ... a bit stretched, but you get the thought)
HerzAusGold wrote:So put credits of all discussion members to your proposal
Offcourse! I never meant to take credit for this, and it's certainley not "my proposal" :)

I've been playing around with the last Amiga Emeral Mine editor (V6.03 from no-one/ruppelware is the last one I think ?) and I think I'm going to stick with all the EM elements that you can use in that editor.
that means e.g. also 4 different Dynamite elements: 1 inactive and 3 active ones each progressed further towards detonation. These are not purely cosmetical because they have different timings when the explosion will occur.

Till later!
Steffest

Post Reply