Current state of text based levelformats
Moderators: Flumminator, Zomis
scrolling
i just can't get the idea, i simply do not understand, how that ("buggy") scrolling makes any sense. how it would enhance game experience.
take rta dash cave 5 for example. it is a nice puzzle, you have to find a way which is good for all 3 rockfords on the left, and the one on the right. this puzzle is much more complicated, than bd1 cave i, for example, where rockford was alone. but the thing that you can't normally see the cave, simply makes this a nightmare. you move in single steps, you don't really now which player did actually move, because you don't see them. and you can only hope that the screen will scroll to the area you want to see.
of course, if you get to know the scrolling algorithm, you can think for a while and understand why the screen will scroll one move at one time, and three moves at the other. but you can't really plan your movements.
because of this, i don't really feel any inspiration to implement this in my own game. but that is my own, others can of course use this.
thinking of this, hereby i suggest a behavior for bdcff-capable programs: if some tag is encountered when reading a bdcff game, the program doesn't know, it should read as a string, and later, when saving the file again, save those, too. for example, if my program does not understand "Scrollproperties.counteroverflow", it still remembers it, and after editing and saving the cave, the option will be preserved. what do you think?
take rta dash cave 5 for example. it is a nice puzzle, you have to find a way which is good for all 3 rockfords on the left, and the one on the right. this puzzle is much more complicated, than bd1 cave i, for example, where rockford was alone. but the thing that you can't normally see the cave, simply makes this a nightmare. you move in single steps, you don't really now which player did actually move, because you don't see them. and you can only hope that the screen will scroll to the area you want to see.
of course, if you get to know the scrolling algorithm, you can think for a while and understand why the screen will scroll one move at one time, and three moves at the other. but you can't really plan your movements.
because of this, i don't really feel any inspiration to implement this in my own game. but that is my own, others can of course use this.
thinking of this, hereby i suggest a behavior for bdcff-capable programs: if some tag is encountered when reading a bdcff game, the program doesn't know, it should read as a string, and later, when saving the file again, save those, too. for example, if my program does not understand "Scrollproperties.counteroverflow", it still remembers it, and after editing and saving the cave, the option will be preserved. what do you think?
cirix
- LogicDeLuxe
- Posts: 83
- Joined: Sun Jun 04, 2006 9:23 pm
- Contact:
Re: scrolling
Good suggestion. This really should be stated to any BDCFF documentation. In the data base, to the introduction text of the "Properties" tab might be a good place for this.cirix wrote:thinking of this, hereby i suggest a behavior for bdcff-capable programs: if some tag is encountered when reading a bdcff game, the program doesn't know, it should read as a string, and later, when saving the file again, save those, too.
- LogicDeLuxe
- Posts: 83
- Joined: Sun Jun 04, 2006 9:23 pm
- Contact:
Instead of introducing a new attribute, we could just extend Intermissionsize:cirix wrote:yes, that one assumes 40x22 and 20x12, those can be default. but it DOES NOT CONTAIN either the cavesize, or the intermissionsize tags, which could be easily removed. i just haven't come across any bdcff which had that. Not mentioning, that BD1 intermissions ARE NOT 20x12, they are 40x22 with upper-left 20x12 visible. We would rather need a Size=40 22 and Visible=0 0 20 12 for this.
Intermissionsize=width height [visiblewidth visibleheight]
Default should remain 20 12 for compatibility. Any unmodified C64 conversion should include the following line, though:
Intermissionsize=40 22 20 12
As for an individual by caves basis, the following should be allowed in a [cave] section as well:
Size=40 22 20 12
cave sizes
yes, but that one should restrict this possibility to intermissions only, and i think cave could also have this.
a possible cave buildup (i've seen this in intermissions): there is a large maze in the invisible area. fireflies go into the maze, and you cannot see them, you don't know where they are. and then they appear again very suddenly in the visible area, so you have to be alert any moment. i think this is a nice idea, and should be allowed in normal caves, too. (btw, i think an intermission is should only be different in one aspect: you get bonus life, you do not have to solve.) i don't really care if this can't be exported back to c64, as this is the purpose of bdcff, do describe everything, every engine realizes the possibilities to a different extent.
therefore, i suggest "size=<width> <height> [visiblewidth visibleheight]", or even "size=<width> <height> [visiblewidth visibleheight [visible_from_x visible_from_y]]", not to restrict visible area to the upper left corner. default should be "size=40 22 20 12" for intermissions. or maybe "size=w h [x1 y1 x2 y2]" would be nicer!
still imo cavesize and intermissionsize are of no use. as the standard states the default size= for caves and intermissions, any other size can be set explicitly, for example "size=35 19", 11 bytes more for readability and easy processing.
anyways, the some current bdcff files are incompatible with the c64 design, as they have 20x12 intermission maps, and c64 has 40x22 intermissions internally. but this can be worked around: the standard should state that cave maps are allowed to be smaller than the actual size=w h specified (or the default size=w h), and if smaller, the remaining part should be filled with steel walls. (that's what gdash does if you resize a mapped cave in the editor. also plck did that, practically speaking, as it did not allow setting those cells.)
a possible cave buildup (i've seen this in intermissions): there is a large maze in the invisible area. fireflies go into the maze, and you cannot see them, you don't know where they are. and then they appear again very suddenly in the visible area, so you have to be alert any moment. i think this is a nice idea, and should be allowed in normal caves, too. (btw, i think an intermission is should only be different in one aspect: you get bonus life, you do not have to solve.) i don't really care if this can't be exported back to c64, as this is the purpose of bdcff, do describe everything, every engine realizes the possibilities to a different extent.
therefore, i suggest "size=<width> <height> [visiblewidth visibleheight]", or even "size=<width> <height> [visiblewidth visibleheight [visible_from_x visible_from_y]]", not to restrict visible area to the upper left corner. default should be "size=40 22 20 12" for intermissions. or maybe "size=w h [x1 y1 x2 y2]" would be nicer!
still imo cavesize and intermissionsize are of no use. as the standard states the default size= for caves and intermissions, any other size can be set explicitly, for example "size=35 19", 11 bytes more for readability and easy processing.
anyways, the some current bdcff files are incompatible with the c64 design, as they have 20x12 intermission maps, and c64 has 40x22 intermissions internally. but this can be worked around: the standard should state that cave maps are allowed to be smaller than the actual size=w h specified (or the default size=w h), and if smaller, the remaining part should be filled with steel walls. (that's what gdash does if you resize a mapped cave in the editor. also plck did that, practically speaking, as it did not allow setting those cells.)
cirix
- LogicDeLuxe
- Posts: 83
- Joined: Sun Jun 04, 2006 9:23 pm
- Contact:
Re: cave sizes
This is a good idea. Except the invisible part should be initialized with InitialBorder, which of course defaults to STEELWALL.cirix wrote:anyways, the some current bdcff files are incompatible with the c64 design, as they have 20x12 intermission maps, and c64 has 40x22 intermissions internally. but this can be worked around: the standard should state that cave maps are allowed to be smaller than the actual size=w h specified (or the default size=w h), and if smaller, the remaining part should be filled with steel walls.
And as "size=w h [x1 y1 x2 y2]" is easier to edit, "Size=width height [visiblewidth visibleheight]" would do techically, as you can wraparound over all boarders. "size=w h [x1 y1 x2 y2]" is probably the more user friendly option nevertheless, so I second this.
And if there is really no one using Intermissionsize, we really might abandon this. On the other hand, it doesn't harm anything and isn't exactly hard to implement, either.
There was a workaround even in the unmodified PLCK, though: Start a new cave, press F, select a region, load an existing intermission, edit the region you just selected, save intermission back.also plck did that, practically speaking, as it did not allow setting those cells.
Re: scrolling
The key to this cave is that, while the distances are different, all 4 areas are theoretically laid out exactly the same. With the rightmost rockford, you must only make moves to definite barriers to guarantee the safety of the 3 rockfords you can't see. If you make random moves without utilizing anything to guide your path, you will definitely hit a firefly. Sorry about off-topic-ness, just had to defend this.cirix wrote:take rta dash cave 5 [RTA Dash 5 - cave 6] for example. it is a nice puzzle, you have to find a way which is good for all 3 rockfords on the left, and the one on the right. this puzzle is much more complicated, than bd1 cave i, for example, where rockford was alone. but the thing that you can't normally see the cave, simply makes this a nightmare. you move in single steps, you don't really now which player did actually move, because you don't see them. and you can only hope that the screen will scroll to the area you want to see.
of course, if you get to know the scrolling algorithm, you can think for a while and understand why the screen will scroll one move at one time, and three moves at the other. but you can't really plan your movements.
Those who can't learn will teach; those who can't teach will learn.
cave colors
hi
i received requests to support atari colors.
as naming all colors there makes no sense, i suggest to extend the colors the following way: if the bdcff is a c64 file, or has c64 colors, the program should use names, for example colors=orange gray1 white. (this way, the programs loading bdcff can use their own c64 palette, like vice)
if any other color is selected, simply use a html-like notation, colors=e0e020 808080 ffffff.
(of course colors=orange 808080 ffffff can as simply be valid as the above, as it makes no difference.)
i haven't really decided but amoeba and slime colors would also make sense. maybe if 7 colors specified for colors=, last two would be for slime and amoeba.
those values can default to:
- green and blue, if bd2 graphics is used. (((this way dirt mod can also make sense!)))
- ignored, if bd1 graphics is used, because it had color3 amoeba, which had a very different color than dirt. (((and dirt mod makes no sense)))
opinions?
i received requests to support atari colors.
as naming all colors there makes no sense, i suggest to extend the colors the following way: if the bdcff is a c64 file, or has c64 colors, the program should use names, for example colors=orange gray1 white. (this way, the programs loading bdcff can use their own c64 palette, like vice)
if any other color is selected, simply use a html-like notation, colors=e0e020 808080 ffffff.
(of course colors=orange 808080 ffffff can as simply be valid as the above, as it makes no difference.)
i haven't really decided but amoeba and slime colors would also make sense. maybe if 7 colors specified for colors=, last two would be for slime and amoeba.
those values can default to:
- green and blue, if bd2 graphics is used. (((this way dirt mod can also make sense!)))
- ignored, if bd1 graphics is used, because it had color3 amoeba, which had a very different color than dirt. (((and dirt mod makes no sense)))
opinions?
cirix
- LogicDeLuxe
- Posts: 83
- Joined: Sun Jun 04, 2006 9:23 pm
- Contact:
Re: cave colors
Hex-colors and adding amoeba and slime makes sense to me.cirix wrote:opinions?
Though I would list amoeba at 6th and slime at 7th. It seems more intuitive since amoeba was first and slime was added later. And of course, those extra colors should be save to ignore, ie. you can't specify them without specifying border color and background color, too.
And default colors shouldn't be ignored for BD1 graphics. (The dirtmod makes no sense in this case, true, but this is not relevant here.) The Atari version has the exact same graphics as the C64 version. Those hardwares couldn't even have individual colors for the modified BD2 amoeba.
Thinking of this, the dirtmod flag given in a BDCFF only represents the original caveset. The engine shouldn't use it regardless, but use it wisely, since it depends on the used graphics set, whether it makes any sense or not. Thus having an appropriate flag in the graphics file would be a good idea. Maybe we should abandon that BDCFF flag altogether, since the graphics set is indeed much more important. It could be forced with Effect=DIRTLOOKSLIKEeffect DIRT2 anyways.
- LogicDeLuxe
- Posts: 83
- Joined: Sun Jun 04, 2006 9:23 pm
- Contact:
acid properties
LogicDeLuxe:
you wrote this in the other topic:
bye
you wrote this in the other topic:
so a boolean flag should be added to acidproperties, as bdcff should also support this!$17 Bit 2: if set, Acid's original position converts to explosion puff during spreading. Otherwise, Acid remains intact, ie. it's just growing. (unused in the original BD1)
bye
cirix
intermission sizes again
we have a problem, houston
we decided that cave size always defaults to 40x22, with 20x12 visible for intermissions.
but this way, the bdcff files on arno's site are incompatible with the spec. for example, bd1 intermission 1:
[cave]
Name=Intermission 1
... size defaults to 40x22, visible to 20x12
[objects]
Point=10 10 BUTTERFLYr
Point=10 2 BOULDER
...
and there should be a drawrect (0,0,19,11, steelwall) for this to function properly. an implicit drawrect might be incompatible with other bdcff files. 20x12 intermissions are incompatible for random generator and invisible parts - even more important.
we decided that cave size always defaults to 40x22, with 20x12 visible for intermissions.
but this way, the bdcff files on arno's site are incompatible with the spec. for example, bd1 intermission 1:
[cave]
Name=Intermission 1
... size defaults to 40x22, visible to 20x12
[objects]
Point=10 10 BUTTERFLYr
Point=10 2 BOULDER
...
and there should be a drawrect (0,0,19,11, steelwall) for this to function properly. an implicit drawrect might be incompatible with other bdcff files. 20x12 intermissions are incompatible for random generator and invisible parts - even more important.
cirix
- LogicDeLuxe
- Posts: 83
- Joined: Sun Jun 04, 2006 9:23 pm
- Contact:
If you need this, how about:cirix wrote:LogicDeLuxe:
you wrote this in the other topic:so a boolean flag should be added to acidproperties, as bdcff should also support this!$17 Bit 2: if set, Acid's original position converts to explosion puff during spreading. Otherwise, Acid remains intact, ie. it's just growing. (unused in the original BD1)
AcidProperties=Element Probability [Element]
The optional Element is what the Acid leaves behind (default=EXPLOSION3 which is the one with the biggest puff graphic) Those Crazy Dream 3 special caves would just have ACID as the second Element.
Alternatively, we could just specify:
AcidProperties=Element Probability [nopuff]
whereas "nopuff" is written as a word for readability.
Anyways, this would have as little priority as all Crazy Dream 7 extensions would have, since there is only one game using it.
I know. And I really spend some thoughts on it for a reasonable compromise. There is no ultimate solution, since those files are just not consistent, ie. they assume the size to be 20 12 in one file and 40 22 0 0 19 11 in another.cirix wrote:we decided that cave size always defaults to 40x22, with 20x12 visible for intermissions.
but this way, the bdcff files on arno's site are incompatible with the spec.
I know that the FillRect is missing from some BDCFF files, including that of BD1. I thought of that already and the solution lies in the Initialborder attribute:for example, bd1 intermission 1:
[cave]
Name=Intermission 1
... size defaults to 40x22, visible to 20x12
[objects]
Point=10 10 BUTTERFLYr
Point=10 2 BOULDER
...
and there should be a drawrect (0,0,19,11, steelwall) for this to function properly.
This should be the best compromise we can get for several reasons:data base wrote:Initial border element. This element is used to draw the border, which includes the invisible part of the cave.
- I'm not aware of any Intermission in any BD1 engine game requiring dirt or random placements there. In the case, there is such a cave, it really has to be fixed in the BDCFF file.
- If an autor wants random placements there, he can still do this with the RandomFill cave object.
- The random placement of existing C64 caves is always compatible as the engine always proceeds all 40 colums.
- The defaults of 40 22 0 0 19 11 are compatible to PLCK caves. Though if the map is smaller than this size, all parts (presuming the usual conditions) beyond the map will/should be filled with Initialborder.
As those special intermissions all using the PLCK engine or later (thus they are map based), it really would not matter how the field is initialized since drawing the map is overwriting it anyways.an implicit drawrect might be incompatible with other bdcff files. 20x12 intermissions are incompatible for random generator and invisible parts - even more important.