Current state of text based levelformats

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

Moderators: Zomis, Flumminator

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

Post by LogicDeLuxe » Thu Dec 20, 2007 1:47 pm

HerzAusGold wrote:
Not for DX Boulderdash, but for RnD, it's quite a bit of work.
Hm, so I see... the pascal conversion is not the problem..
it's the integration in RnD...
As I didn't even took a look into the RnD code, I really can't tell wether the conversion or the integration would be more work.

Though keep in mind that my code is not exactly "written for RnD", as stated sometimes. It's actually an old version of The new Dash Dimension. The source code of the latest version is lost unfortunately. And since it wasn't intended for a source code release, it is virtually not commented and the variable names are a mix of German and English or even just some letters. Also, there is no menu in the Pascal code, as it is actually a separate program written in Quick Basic, and the game engine is a program on its own. Early versions were completely written in Quick Basic, but the compiler was pretty useless and the code unbelievable slow (the game was only playable on a Pentium and didn't even have soft scrolling, while the Pascal version runs fine on an 80286), though since the menu worked fine, I left it the way it was.

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

Post by HerzAusGold » Fri Dec 28, 2007 7:33 pm

LogicDeLuxe wrote:
No, it's not. Take a look here: http://www.gratissaugen.de/erbsen/bdcff.html
I'm actually rewrite the BDCFF stuff, and want to integrate the mentioned proposal for RnD. If I have any deeper questions, I think it better I send you a email
And the answer is ... 42 !

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

Post by Steffest » Sun Dec 30, 2007 12:01 am

Hey

I extended the BDCFF to hold all the Emerald Mines objects.
You can find this proposal at http://www3.stef.be/projects/boulderflash/bdcff/
If you were planning on doing the same for R'n'D - it would make sense to keep our objectcodes in line :-)
My extentions are only a proposal, and only used in Boulderflash so they can be changed if needed.

I also released a leveleditor that can read and write BDCFF files.
you can find this at http://www.steffest.com/dxboulder/Files ... rV0.26.zip
In the editor: when there are properties found that it doesn't understand, it holds them in a "BDCFF3 section of the level so that they remain intact when saving the level again.

Still very alpha, so do make a backup copy of the BDCFF file before editing them in the editor.

I also added a "test level in EMC player" option in the editor, to created levels for Dave's player.
This exports the level to EMV6 format and puts it as "test.lev" in the levels folder of dave's EMC player.

Next on the todo is a R'n'D export filter, allthough that probably won't support custom elements.

Cheers!
Steffest

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

Post by HerzAusGold » Sun Dec 30, 2007 8:56 pm

This is cool!
Also have planned to write a editor... (with QT)
Too bad that I'm late.
I took a first try with the editor and it look's very good.
And the feature list is great. Even a ADF support is integrated.
Do you plan to make the source of the editor open source?
What program language do you use?
Who long do you develop this thing?

The BDCFF support in R'n'D with extended element's is
soon ready (hopefully).
If there are any incompatibilities I write it here.
And the answer is ... 42 !

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

Post by Steffest » Sun Dec 30, 2007 9:19 pm

Hey!
Yes, The editor will certainly be open source and will fall under GPL.
I have to clear some dependant components first, so that it would compile "out of the box"
It's written in Delphi (That's Pascal)
In fact - The editor is over 10 years old, I just recently dug it back up to add BDCFF support.
I made it in 1997 - 1998.

The ADF support is a bit buggy, but it works enough to import emerald mine caves directly from the ADF image. (or to extract any file from it)
I can't believe how much free time I had in college hehe :-)
The C64 import is based on xxx2das by Marek (LogicDeluxe)

About the BDCFF export: as long as you use only C64 objects, the levels are exported with 1 char objectcodes.
AS soon as you use 1 or more objects from EM, everything gets exported with 2 char object codes, even the levels with only C64 objects.
so 1char and 2char is never mixed in the same file.

BDCFF support in R'n'D .. that sounds really great !!!

Cheers! (and a happy new year!)

Steffest

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

Post by HerzAusGold » Mon Dec 31, 2007 6:03 pm

I changed some elements for BD-C64 support:

Code: Select all

 20;BUTTERFLYd        ;c;bd;
 21;BUTTERFLYl        ;C;bl;
 22;BUTTERFLYu        ;b;bu;
 23;BUTTERFLYr        ;B;br;
 10;FIREFLYl          ;Q;ol;
 11;FIREFLYd          ;o;od;
 12;FIREFLYu          ;O;ou;
 13;FIREFLYr          ;q;or;
 14;BOULDER           ;r;rr;
 15;DIAMOND           ;d;dd;
only checked BD-C64 elements.
release BDCFF support next year. ;)
And the answer is ... 42 !

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

Post by Steffest » Wed Jan 02, 2008 8:52 am

Hey!

The full name of the object doesn't matter much, do they?
I think they only are used as a label and never in a level file?

Anyway: as you know in BD-C64 the boulders and diamonds behave slightly different then the boulders and diamonds in Emerald Mines.
Thats why I named them "C64BOULDER" and "EMBOULDER"
the name doesn't matter much, as long as "rr" translates to a boulder C64 style, and "RR" to a boulder EM style.

Steffest

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

Post by HerzAusGold » Wed Jan 02, 2008 1:12 pm

The element names are used in some level files.
Like the BDCFF ones from "Arno Weber's Webpage".
So they should be compatible with the old ones,
which mentioned in "LogicDeLuxe's proposal".
And the answer is ... 42 !

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

Post by Steffest » Wed Jan 02, 2008 8:42 pm

In that case, you are absolutely right!
I updated the table at http://www3.stef.be/projects/boulderflash/bdcff/

Steffest

P.S. HerzAusGold: 1 more post and your post-count will be 2 bytes also :-)

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

Post by HerzAusGold » Wed Jan 02, 2008 10:58 pm

Even I like more the '1's as the '0's:
I have to post again ;)

FIREFLYd should have the two-byte code "od",
FIREFLYr should have "or", aso.
isn't it?

Question:
For the BUGleft - a change to "BUGl" is not necessary?
Or for the other elements, which kind of this?

Seems, I get a coauthor of this proposal...
And the answer is ... 42 !

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

Post by Steffest » Thu Jan 03, 2008 10:46 am

Doh!
You are right offcourse ... I mixed them up.

It's fixed now.
I also added a bunch of new objects and some graphics to the list.
http://www3.stef.be/projects/boulderflash/bdcff/

Steffest

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

Post by HerzAusGold » Thu Jan 03, 2008 12:42 pm

Hi,
Hm you add some elements which not exists in EM!

Can we use the RND element names instead?
For all (new) elements?
Than we have a BDCFF proposal which cover the RND needs. ;)

This makes things and tools easier!

To save compatibility we should use the old names ( maybe additional ) which already exists.

Uppercase, Lowercase should not matter!
The "Id" should not matter too!!

Look here: viewtopic.php?t=1564
Takes a while for loading!
There are all RnD elements!

The two byte code is free to use.
But for Rnd we need more.
*edit: ... but a 3 byte code is not readable anymore..
so only for the most important ones a 2-byte code
or (only a tougth) a switch to a other charset "#1"
or (only a tougth) a second map which is combinded with the first (other charset)
or whatever?? (only needed in map section)

And one thing should be usefull in the game section of a BDCFF file.
The "engine" which should use for.

engine can be "BD1","BD2","BD3" for Boulderdash engine,
or "EM1","EM2","EM3","EM4","EM5","EM6" for EMC engine,
or "RND" for Rnd-Engine
or "DX" for DX-Boulderdash engine
or whatever.

eg. "engine=EM6"
So RND can cover the special needs.
And the answer is ... 42 !

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

Post by LogicDeLuxe » Thu Jan 03, 2008 1:23 pm

HerzAusGold wrote:The "Id" should not matter too!!
What's the purpose of it anyway? I'm not familiar with Emerald Mine internals.
The two byte code is free to use.
But for Rnd we need more.
As those codes are merely defaults, any cave editor is free to define more, and any engine is supposed to read such a list. The important thing are the element names, which should be consistent for compatibility.
The "engine" which should use for.

engine can be "BD1","BD2","BD3" for Boulderdash engine,
or "EM1","EM2","EM3","EM4","EM5","EM6" for EMC engine,
or "RND" for Rnd-Engine
or "DX" for DX-Boulderdash engine
or whatever.
I just thought of this as well. (Btw., there is no BD3 engine, as BD3 uses the dated BD1 engine.)

The Engine attribute is in fact a good idea. It can be "BD1", "BD1atari", "BD2", "PLCK", "1stB" or "CrLi" for Boulder Dash and should set some defaults as following:
(feel free to fill in those for non-BD engines.)

"BD1":
BorderProperties=BD1
DummyProperties=false false true
InOutBoxType=BD1
IntermissionProperties=false true false
MagicWallType=BD1
Scrollproperties=BD1

"BD1atari":
BorderProperties=BD1
DummyProperties=false false true
InOutBoxType=BD1
IntermissionProperties=false true false
MagicWallType=BD2
Scrollproperties=BD1

"BD2":
BorderProperties=BD2
DummyProperties=false false true
InOutBoxType=BD1
IntermissionProperties=false true false
MagicWallType=BD2
Scrollproperties=BD1

"PLCK":
BorderProperties=PLCK
DummyProperties=false false true
InOutBoxType=BD1
IntermissionProperties=false true false
MagicWallType=BD2
Scrollproperties=BD1

"1stB":
BorderProperties=1stB
DummyProperties=true true false
InOutBoxType=1stB
IntermissionProperties=false false true
MagicWallType=1stBN
Scrollproperties=1stB

"CrLi":
BorderProperties=1stB
DummyProperties=true true false
InOutBoxType=1stB
IntermissionProperties=false false true
MagicWallType=1stBN
Scrollproperties=1stB

If no engine is given, the defaults remain as stated with the atribut's documentation.

Eventhough BD1 and BD2 don't have dummies, anyone should be able to convert a cave and edit them in a BDCFF file, thus there should be defaults in order to be compatible with other tools/engines. Also there are some enhanced engines on the C64, including BD1 with dummies added.

As for Emerald Mine, I think, we need some more attributes. For instance, we need to specify the Yamyam content.


And since some fans began to build sequels which are supposedly level 6-10 of old games, I though of the usefulness to restrict the levels attribute to either 1 or 5. Should this restriction remain? Or should it be loosen to allow any number of levels?

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

Post by Steffest » Thu Jan 03, 2008 2:53 pm

:-)
Hey, thats a nice list.
Yes, it would make sense to keep the naming in line.
Maybe with some small changes?
like "key_red" maybe is more relevant then "key_1" ?
(Allthough it also would make sense that a key_1 is needed to open door_1 and that the color doesn't really matter much.)

Hmm, this process seems to scream for a wiki page, so that anyone could edit the BDCFF proposal ... anyone knows how Martijn is progressing to setup his boulderwiki?

The ID part of the list doesn't matter indeed ... that's just an internal number. (it's removed now)

Yes, next to the objectcodes there should be some additional sections, like yamcontent, scores for all collectable objects, times for robotwheels, timegates etc ....
Also a highscore table for each cave (dependant on the engine)
I don't know if anyone here has ever played BD4 but the competition there is fierce and very stimulating! (I challenge everybody to crack the top 10 of the Homelands levels :-) quite hard ! )

as for the codes: 3 or more byte codes are offcourse possible, but isn't 2 enough?
The two byte code is free to use.
But for Rnd we need more.
there are over 10000 possible ASCII combinations with 2 chars ...

The Engine attribute is a very good idea, maybe also a section to put confirmed compatible engines.
(Like Engine is BD1 , confirmed compatible engines EM1, RnD, DX ...)

I'll change the names in the BDCFF list as much as possible to RnD names.
Maybe I'll put it behind a small CMS so anyone could edit the page.

See ya!
Steffest

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

Post by LogicDeLuxe » Thu Jan 03, 2008 6:57 pm

Steffest wrote:Hmm, this process seems to scream for a wiki page, so that anyone could edit the BDCFF proposal
Agreed. An official BDCFF place is badly in order.
Any addition has to be made in a way that compatibility is maintained, of course.
Also a highscore table for each cave (dependant on the engine)
Good point. I should discard the "Available only in [game] section" for the highscores attribute. So it can be used in a [cave] section the same way. Any engine is free to use or ignore either highscore table, of course.
as for the codes: 3 or more byte codes are offcourse possible, but isn't 2 enough?
Everyone is free to support more bytes, though sacrifices compatibility to strict BDCFF, especially current and older implementations.

As for naming conflicts, there are some more elements in some Boulder Dash engines on the C64:
BOMB
ACID
Maybe calling the EM version EM_BOMB and EM_ACID would be a good idea, as I'm certain, they behave quite differently.

And explosions in Boulder Dash are a sequence of several elements. Thus EXPLOSION1 etc. is defined. I don't know how explosions work in EM. If it's a complete different thing, maybe they should be called EM_EXPLOSION as well.

Post Reply