Current state of text based levelformats

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

Moderators: Flumminator, Zomis

Current state of text based levelformats

Postby Steffest » Fri Dec 07, 2007 7:49 am

Hey Guys!

Recently my interest in Boulderdash spiked again, just like it happens once every few years :-)
I picked up my online flash based boulder again and took it some steps further to the point where it should be loading actual levelmaps instead of creating random ones.

instead of reinventing the same stuff all over again - like levelmap formats - I'm going to try to integrate with some of the wonderfull tools that you people have created.
Seems like I have a lot of catching-up to do! haha.
So I thought: Why not ask the people that know best?

Here's my question: What's the current status of a common boulderdash level fileformat?
For online usage, the leveldata should be stored in a text-format, not binary.
I read somewhere on this forum that there where some thoughts on a XML based format?
has anyone done something with that?
For online use, XML would be perfect offcourse.

See you!
Steffest
Steffest
 
Posts: 53
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium

Re: Current state of text based levelformats

Postby Zomis » Fri Dec 07, 2007 3:44 pm

Steffest wrote:Here's my question: What's the current status of a common boulderdash level fileformat?
For online usage, the leveldata should be stored in a text-format, not binary.
I read somewhere on this forum that there where some thoughts on a XML based format?
has anyone done something with that?
For online use, XML would be perfect offcourse.
Hello Steffest!

I'm not sure at all, but I doubt that there's any plans of a common BD level format.
For online usage (with a Flash application), I see no problems in loading binary files? I've recently learned Flash myself, and I've found good ways of loading binary format.
I do not see any reason why XML would be perfect for online usage, I think it more depends on the file structure itself than whether it should be online or not.

I've searched the forum for XML, but found more con-XML than pro-XML.
User avatar
Zomis
 
Posts: 1501
Joined: Mon Jun 21, 2004 1:27 pm
Location: Sweden

Postby Steffest » Fri Dec 07, 2007 8:23 pm

Hey!

Thanks for your input.
in fact - proposals for a common BD format go back a long way.
its commonly called the BDCFF : BoulderDash Common File Format.
The last proposal to my knowledge is e.g. at http://www.boulder-dash.nl/bdcff_doc.html

The problem is: this is solely a proposal for the BoulderDash objects, not all the EMC objects, let alone al the supaplex ones or any other BD-type game.

if you take that BDCFF format at http://www.boulder-dash.nl/bdcff_doc.html and replace all the [] brackets with <> , you almost have a valid XML file.

As for working with binary files in flash.
Hmmm ... XML loading and parsing routines are built right into the core of the Flash player, and any other webtool for that matter.
loading and parsing XML is a breeze, and allthough working with binary files in flash is not impossible, its considerably more work and certainly not following any web-standards, so why not use the widely spread standard for passing around data on the web?

I'm thinking out loud here, but as example you could provide and RSS feed with new levels, and since the leveldata would be XML as well, you could include the level right into the RSS feed, no need for an enclosure link which would need a seperate download thread.
So you could build a player that would autoupdate the levels with standardised routines as RSS-feeds.

Since i'm on a rant allready - here are some more advantages of XML
- leveldata would be human readable, no need for extra level visualisation tools.
- leveldata and metadata would be editable with any text or XML editor. Offcourse a dedicated leveleditor would work better, but still ...
- XML is very extensible, a player could simply skip unknown metadata in a standard way.
- new objects would include a description of their behaviour, or a link to more info, so an editor wouldn't have to actually trace down a compatible player that knows the new object to get an understanding of what the object does.

Anyway ...
Don't you agree that throwing around ascii files around the web is far easier then binary files?

oh .. and by the way .. your file archive is HUGE and AWESOME !!!!!!
Thanks !!!!
(and thanks for reading all the way through ... sorry - I didn't mean to write that much or sound presumptuous)

Cheers
Steffest
Steffest
 
Posts: 53
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium

Postby HerzAusGold » Sat Dec 08, 2007 10:30 pm

Hi,
I'm post a tought "...let's RnD output the level in XML"
But only for the tools (for RnD).

A common level format is not possible I think.
Some clone have e.g. a earthquake which throw boulder from steelwalls...
So all have it's special effects.

I try to write native loader's for BD (nibble format) and BDCFF for RnD.
This is not the whole problem.
The problem is the emulation of the special things or quirks.

Btw:
Here comes the fun:
http://www.zomis.net/rnd/download.php?id=421

Now with native BDCFF loader.
and a native BD loader.
Have fun.

Look here:
http://www.artsoft.org/forum/viewtopic.php?t=957
And the answer is ... 42 !
HerzAusGold
 
Posts: 319
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Postby LogicDeLuxe » Sun Dec 09, 2007 10:32 pm

Steffest wrote:The last proposal to my knowledge is e.g. at http://www.boulder-dash.nl/bdcff_doc.html
No, it's not. Take a look here: http://www.gratissaugen.de/erbsen/bdcff.html
It is supposed to be on Tim Stridmann's site as well, as he told me, but he apparently disappeared since then. :(
It's mainly updated for missing features (of all C64 engine versions), along with some few additions. Eventhough that page is written in advance to Crazy Dream PC developement, its information is generally quite usable for any other close which intends to use BDCFF.

As for the missing EM elements, it should be no problem to just use EM names instead (eventhough it is called Boulder Dash comon file format). Any engine which doesn't know them is supposed to ignore them (like any keyword). This specifications don't tell how the elements behave exactly, as this depends on the engine anyways, thus it's all the same format-wise.
User avatar
LogicDeLuxe
 
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm

Postby Steffest » Mon Dec 10, 2007 11:31 am

Hey LogicDeLuxe!
Thanks for the Link!

Indeed - looks like a usable format for me.

As I remember correctly, Paul Williams (from BD4) has a new textbased levelformat in use with double byte ascii indications of each Emerald Mine object, so I'll probalby use the same object-codes.

HerzAusGold: you're right that a common levelformat is not entirely possible, but I do believe that a common ground can be found which would greatly simplify the exchange between all the diffrent players and editors.

Cheers!
Steffest
Steffest
 
Posts: 53
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium

Postby HerzAusGold » Mon Dec 10, 2007 8:49 pm

- new objects would include a description of their behaviour, or a link to more info, so an editor wouldn't have to actually trace down a compatible player that knows the new object to get an understanding of what the object does.

HerzAusGold: you're right that a common levelformat is not entirely possible, but I do believe that a common ground can be found which would greatly simplify the exchange between all the diffrent players and editors.


How deep should it be. Only Emerald and BD elements?
Think about the CE in RnD, how should a player can cover this?
Or how can a common decription for a CE looks like?

Any engine which doesn't know them is supposed to ignore them (like any keyword). This specifications don't tell how the elements behave exactly, as this depends on the engine anyways, thus it's all the same format-wise.


If the engine ignore it, it becomes unplayable.

But you don't ask for a XML format for RnD,
you ask for a "boulderdash" XML format format, isn't it.
If it is so maybe forum members and I don't notice it (up to now).
And the answer is ... 42 !
HerzAusGold
 
Posts: 319
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Postby Steffest » Mon Dec 10, 2007 10:05 pm

Hey!

If we could start with the boulderdash en Emerald mines upto V7 objects, then we would have allready a pretty big common ground.

the CE objects in RnD are indeed something else.
Clearly RnD is the most advanced boulderdash-like engine around at this moment.
It has grown to a game-platform/engine that goes way beyond boulderdash or emerald mines.
I'm certainly not implying that RnD should embrace a common fileformat ... I was simply looking for a more or less standards-based fileformat for a webbased Boulderdash type game.

Thanks for the input everyone!
Its great to see such an active fan forum !

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

Postby LogicDeLuxe » Tue Dec 18, 2007 6:47 am

HerzAusGold wrote:If the engine ignore it, it becomes unplayable.
Sure, there hardly won't be any engine compatible to all caves in the world. The idea of BDCFF is more about content exchange, I think.
And of course, the engine should display a warning if any unknown keywords are encountered.
User avatar
LogicDeLuxe
 
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm

Postby HerzAusGold » Tue Dec 18, 2007 7:38 pm

Hi LogicDeLuxe,

for the BDCFF format you mentioned here
No, it's not. Take a look here: http://www.gratissaugen.de/erbsen/bdcff.html

are there any levels out? Are all elements possible in RnD?

One question to BDCFF
Is a falling element have any difference to a normal element placed
on this position? The normal element are handled from the engine
and begin to fall.
What is the difference or why they exists in BDCFF.

Can you explain the delayed "d" thing again, are there any value for the delay?
And the answer is ... 42 !
HerzAusGold
 
Posts: 319
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Postby LogicDeLuxe » Wed Dec 19, 2007 10:16 am

HerzAusGold wrote:are there any levels out?
So far, there are only converted C64 levels, afaIk: http://www.boulder-dash.nl/bdcff.php?lang=en
There is a problem with the bonus value. If not set, it sometimes means equal to the initial value, and some other times, it means zero. The best way to prevent this confusion is to always set the bonus value.
Also the new attributes to distinguish between those C64 engine versions are still missing.
Are all elements possible in RnD?
Since there is no BD engine in RnD yet, none of the C64 engines are fully compatible, eventhough, the elements of the ealier engines are there.
One question to BDCFF
Is a falling element have any difference to a normal element placed
on this position? The normal element are handled from the engine
and begin to fall.
What is the difference or why they exists in BDCFF.
Falling elements are just separate elements on its own. Falling elements become laying elements once there is no more room for falling further, and laying elements become falling elements once there is space under it or space to slide off a slidable element. It's the way BD was designed, probably due to code efficiency. They exist in BDCFF (along with those delayed elements) mainly for the effect command. There is no need to use those falling elements when constructing a cave. Although, for example, it is possible to place a falling boulder on top of a firefly, and it will explode immediately at start.
Can you explain the delayed "d" thing again, are there any value for the delay?
They are there to prevent several movements of one element within one scan interval. The BD engine handles element execution and an effect table two lines after the execution. Thus the effect table always lags the element execution and is build in a way that delayed elements become the undelayed elements (unless this is changed with an effect command).
Whenever an element is moved or placed in BD during runtime, you generally use its delayed version. Nothing to worry about for cave authors.
User avatar
LogicDeLuxe
 
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm

Postby Steffest » Wed Dec 19, 2007 10:48 am

LogicDeLuxe: The walking BoulderDash encyclopedia :-)

I dug out my old DX Boulderdash leveleditor from under the pile of sourcecode-crap, spend half a day to get the stupid thing to compile on Delphi 7 and added a BDCFF export filter.

Since it can also import from various levelformats and media, I use it as a levelconvertor to BDCFF, also for Emerald Mine levels.

I try to release it this weekend.
I still have to write down the various additions I did to BDCFF to hold the Emerald mine objects and parameters.
It will also be under GPL, but its written in Pascal, so I don't know if the source will be all that usefull to anyone.

Cheers
Steffest
Steffest
 
Posts: 53
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium

Postby HerzAusGold » Wed Dec 19, 2007 7:58 pm

Thanks for your answers LogicDeLuxe.
Maybe I wait for Steffens release...
/*edit*/ Pascal source should be no problem...
And the answer is ... 42 !
HerzAusGold
 
Posts: 319
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Postby LogicDeLuxe » Wed Dec 19, 2007 9:32 pm

HerzAusGold wrote:/*edit*/ Pascal source should be no problem...
Not for DX Boulderdash, but for RnD, it's quite a bit of work.
User avatar
LogicDeLuxe
 
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm

Postby HerzAusGold » Thu Dec 20, 2007 11:41 am

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...
where I doubt that I'm able to do it, because I'm not familiar with the game engine code in RnD. And have always problems with the technique which is behind the copy of elements, like synchro, scanline aso...
So it seems a lot of work...
.. too bad .. if I don't try, I don't learn more about it...
And the answer is ... 42 !
HerzAusGold
 
Posts: 319
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Next

Return to Programmer's Corner

Who is online

Users browsing this forum: No registered users and 0 guests

cron