Hello Steffest!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.
No, it's not. Take a look here: http://www.gratissaugen.de/erbsen/bdcff.htmlSteffest wrote:The last proposal to my knowledge is e.g. at http://www.boulder-dash.nl/bdcff_doc.html
- 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.
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.
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.HerzAusGold wrote:If the engine ignore it, it becomes unplayable.
No, it's not. Take a look here: http://www.gratissaugen.de/erbsen/bdcff.html
So far, there are only converted C64 levels, afaIk: http://www.boulder-dash.nl/bdcff.php?lang=enHerzAusGold wrote:are there any levels out?
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.Are all elements possible in RnD?
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.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.
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).Can you explain the delayed "d" thing again, are there any value for the delay?
Not for DX Boulderdash, but for RnD, it's quite a bit of work.
Users browsing this forum: No registered users and 2 guests