Current state of text based levelformats

[LogicDeLuxe]

@LogicDeLuxe:
Is a exit in BD destroyable?

It is. Always, any kind, any state.
There are even many caves where you have more than one exit, and you need to destroy some of them as they can block your way.
This is mainly done because there is no destructible Titanium Wall in PLCK and since the Exit looks the same as Titanium Wall, it was a convenient choice.

[Steffest]

If I remember correctly a EM exit is destroyable.

Yep, in EM an exit (both closed and open) is destroyable.
Therefore, looks like the exact same element as the BD_exit, no?
no need to define a separate element for that.

@Steffest:
To avoid any confusion, I can rename all defined EM_xxx elements for RND engine to RND_xxx (e.g. RND_EXITOPENemstyle).
But please can you check if no one is missed in the already defined EM elements. Like e.g. EM_Decor9 ?

I changed allready some names of the RND elements.
I'll only change them if I'm 100% sure that they are not a genuine EM element.
I'll check the decors. I memory serves me right then those decor things are additions of the EMC engine that don't exist in the EM engine.

New issue (??):
For the "envelope1..x" text we need a section in bdcff.

I allready specified Note1...n in the properties section of the BDCFF.
I should also include the "engine" column , so that you can sort the properties depending on the engine, because now its easily overlooked.

so somewhere in the level with the rest of the properties you could have
Note1 = "This is the first note"
Note2 = "This is the second note"
Note3 = "This is the third note"
.....

is this sufficient?
Offcourse you could name then envelope1, etc ... but envelope seems like a graphic thing, maybe note is more general.

Steffest

[HerzAusGold]

Hm I like more this:

[note1]
Hi, this is game <b>SuperGau</b>
With the new element piggy.
And you should <u>collect bullets</u>
[/note1]

So a multiline note with bold and underline is possible.
Ok we dont need bold and underline?
But I think multiline is usefull.

See you
HerzAusGold[/b]

Edit: So I should rename EM_EXIT_OPEN to RND_EXITOPENemstyle because the two exits are both selectable in editor and for archiving a RnD level as a original copy it's needed.
Edit2: Ah, you rename it already. RND_EM_EXIT_OPEN is ok, too!

[LogicDeLuxe]

Offcourse you could name then envelope1, etc ... but envelope seems like a graphic thing, maybe note is more general.

Exactly. I once thought of implementing a scroll for the same purpose, but never did this due to C64 memory restrictions. Maybe someday in Crazy Light PC.

[note1]
Hi, this is game <b>SuperGau</b>
With the new element piggy.
And you should <u>collect bullets</u>
[/note1]

If we also support unicode like in HTML, so we can use all characters including [] and <>, we should be fine with this solution, I think.

[HerzAusGold]

If we also support unicode like in HTML, so we can use all characters including [] and <>, we should be fine with this solution, I think.

I don't like unicode, because some editors dont like it.
Use the ampersand prefix should be enought, like "<" for "<"
(without the quote's)

[LogicDeLuxe]

I don't like unicode, because some editors dont like it.
Use the ampersand prefix should be enought, like "<" for "<"
(without the quote's)

Your editor doesn't need to know unicode, that's the point of HTML encoding. You don't even need to reconfigure your keyboard to enter foreign language characters. For instance, if you need an ä, you look up a unicode table and find that all you need to write is &#228;
This sure is compatible to any ASCII editor. And we don't even have to worry about system differences like DOS and Windows either. All element codes should be 7-bit-ASCII as well, though, umlauts included.

I think, restricting BDCFF to 7-bit serves its purpose of interchangeability very well, too. It also seems reasonable to allow HTML-like coding for unicode for all String-attributes, like the author's name etc..

Maybe, we should use &A instead of _Ä, &O instead of _Ö etc.. An exeption to the _-rule seems reasonable in this case. Maybe we should have all those "trouble-elements" start with &

Also, I think element codes like _[, _], _> and >_ aren't exactly a good idea, as they include key characters which sure makes the parser unnecessarily complex.

[HerzAusGold]

Also, I think element codes like _[, _], _> and >_ aren't exactly a good idea, as they include key characters which sure makes the parser unnecessarily complex.

That's true. But we should not use the ampersand too, because it's introduce a special char sequence.
We should not use:
semicolon - because it's for comment
equalsign - becausse it's for a value assignment
greater,less - because it introduce a HTML sequence
brackets - because it introduce a new section
aso.
Hm, Difficult to find a free one.

I use the pipe symbol for the steel_char's is this allowed?

For the special defines maybe the percent sign is better '%A' for "Ä"

[LogicDeLuxe]

That's true. But we should not use the ampersand too, because it's introduce a special char sequence.
We should not use:
semicolon - because it's for comment
equalsign - becausse it's for a value assignment
greater,less - because it introduce a HTML sequence
brackets - because it introduce a new section
aso.
Hm, Difficult to find a free one.

Agreed.

Also related, there is the <level=1> etc. (which is ID 41 in the data base which display is broken btw.) block for level specific instructions.

Here is the ASCII-Table:

I use the pipe symbol for the steel_char's is this allowed?

Pipe symbol is #124, so it should be fine. It's not used for anything special either.

For the special defines maybe the percent sign is better '%A' for "Ä"

'~A' might be another choice. It looks a bit more similar to '_', I'd say.

And there is yet another problem. The example code in the data base introduced indented formating. This is not a problem most of the part, as white spaces usually should be ignored by the parser anyways. At the [map] section, however, all leading spaces will be interpreted as actual space in the cave, since space is also the default code for the Space element.
I see two option for this problem: Either we require the BDCFF file to begin any mapcode at the first column, no matter how the rest of the file is formatted, or we have to disallow spaces in map codes as well, which unfortunately would decrease the readability of the map somewhat.

[HerzAusGold]

map section should be without indent.
For compatibilty reason (older bdcff files)!

[HerzAusGold]

About the properties, there should be separate cave and game properties.
If some property exists in both then it should listed in both.
Cheers
HerzAusGold

[Steffest]

Some goods points there !

- Avoid & , <, > in map sections. (and possibly ", [, ]; and = too, allthough a parser shouldn't be looking for those in a [map] [/map] section.)

Agreed: in my flash engine I convert supported BDCFF section to XML to load/parse. It would be so much nicer if a map section would be XML safe.

- No indent in map sections.
Yes ... I completely overlooked that. In my parser I ignore traling an leading whitespace, but offcourse a map could have spaces as first/last elements in a line.
Maybe we should leeave out indent all together ... (but most definetly in the map section)

I'll add 2 new columns to the properties page this weekend:
1 indicating in what section they can occur (Game or cave or level)
and 1 indicating in what game engine they occur.

I'll also change the note thing to
[note1]
....
[/note1]
(line feeds in a note ... good point)
HTML in notes would be a logical evolution, but then maybe could expect it too be valid XHTML too ...

-The file should only use Ascii
~A sounds good for Ä (its like "more or less A")

Good thing the french never took up Emerald mines, otherwise we would have èéàçëöäá etc ... too ...


Cheers
Steffest

[HerzAusGold]

Code: Select all

 &<>[];,=" '´` 

All this chars now removed from BDCFF list (2-byte-code).
All chars in ASCII - checked.

[LogicDeLuxe]

Some think which confuses me:
Why does Sokoban need its own SOKOBANPLAYER and not the INBOX? Other BD clones also don't actually have an inbox but start with the player immediately, and yet, there is no special element defined for that purpose.

And do we need LAMP and SOKOBANBOX? No, it's not a rhetorical question. It's in deed a bit complicated. For one, both are meant to imitate a Sokoban box. (Yes, you need to push a button to move one but you don't to move the other, but this is even true with Sokoban-clones.)
On the other hand, the Lamp can be used for more than the Box is designed for in the original Sokoban.
Although LAMP is a description of the graphic which is not present in Sokoban that way, it can in fact have the function of an actual light bulb in RnD and SOKOBANBOX wouldn't be an acurate description in that case, but neither is SOKOBANFULL.

My idea, since there is currently no BDCFF file using SOKOBANBOX, we delete that entry and use LAMP for BD as well (eventhough, there is no lamp graphic in BD). And we should rename SOKOBANFULL to LAMPactivesocket for the sake of consistency.

And if authors think, it's important, we could add an Attribute LampProperties.triggerpush=true|false

[Holger]

Now I'm also a bit confused, but I will try to clear things up a bit (that may indeed look mixed up in R'n'D).

In R'n'D, there are game elements to emulate and play Sokoban style levels. Then there is a lamp element. Important: The lamp element is a pure R'n'D element and has _nothing_ at all to do with the Sokoban elements! It's just an element (well, two for two element states) that can be switched on and off (lamp is on or off) and that needs to be "on" for a R'n'D level to be solved.

The Sokoban elements are completely, 100% independent from this R'n'D style element! They are the following:

- EL_SOKOBAN_FIELD_PLAYER: This is needed for Sokoban style levels which start with the player placed on an empty Sokoban box field. (Levels with a player on empty space just contain the normal player element.)

- EL_SOKOBAN_OBJECT: This is an element that represents the Sokoban box that is not placed on a Sokoban box field, but on empty space.

- EL_SOKOBAN_FIELD_EMPTY: This element is the empty Sokoban box field.

- EL_SOKOBAN_FIELD_FULL: This element is a Sokoban box field that already contains a Sokoban box. The player can push the box off that field, resulting in a EL_SOKOBAN_OBJECT element on one tile and a EL_SOKOBAN_FIELD_EMPTY element on another tile.

As can be seen, the Sokoban element names try to be generic, without a reference to the actual graphical representation of these elements (which is unfortunately not the case for many other R'n'D elements). The unfortunate fact the the "Sokoban object" is represented by a light bulb and not by a box, while another, different element (the lamp) exists with the exact same graphic, but totally different element properties, is likely to cause a lot of confusion. But it is important to know that these elements are not connected in any way! (In fact, the Sokoban element graphics really should be changed to avoid such confusion.)

So I hope I was able to prevent the mistake of mixing up these totally different elements in the BDCFF specification.

[LogicDeLuxe]

The unfortunate fact the the "Sokoban object" is represented by a light bulb and not by a box, while another, different element (the lamp) exists with the exact same graphic, but totally different element properties, is likely to cause a lot of confusion. But it is important to know that these elements are not connected in any way! (In fact, the Sokoban element graphics really should be changed to avoid such confusion.)

Indeed, this explains it well. And I agree in changing their default graphics to something box-like.

I corrected the flagging to SO for the Sokoban objects and RnD for the others. I also added a description in order to prevent confusion, due to the lamp graphics.
I changed the name for RnD element 68 from LAMPsocket to SOKOBANFIELD.
Please check, if this is all correct now!