Current state of text based levelformats

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

Moderators: Flumminator, Zomis

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

scrolling

Post by cirix »

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?
cirix
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Re: scrolling

Post by LogicDeLuxe »

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.
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.
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

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.
Instead of introducing a new attribute, we could just extend Intermissionsize:
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
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

cave sizes

Post by cirix »

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.)
cirix
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Re: cave sizes

Post by LogicDeLuxe »

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.
This is a good idea. Except the invisible part should be initialized with InitialBorder, which of course defaults to STEELWALL.

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.
also plck did that, practically speaking, as it did not allow setting those cells.
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.
User avatar
RTADash
Posts: 180
Joined: Sun May 27, 2007 11:33 am
Location: USA (Ohio)

Re: scrolling

Post by RTADash »

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.
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. :wink: Sorry about off-topic-ness, just had to defend this.
Those who can't learn will teach; those who can't teach will learn.
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

Post by cirix »

Hi
With the rightmost rockford, you must only make moves to definite barriers to guarantee the safety of the 3 rockfords you can't see.
that's what i referred to as being a puzzle :)
cirix
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

cave colors

Post by cirix »

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?
cirix
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Re: cave colors

Post by LogicDeLuxe »

cirix wrote:opinions?
Hex-colors and adding amoeba and slime makes sense to me.

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.
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

Do we still need IntermissionProperties.scroll=true|false?
This is better handled with size=width height [x1 y1 x2 y2] now.
A native C64 intermission is equivalent to:
Size=40 22 0 0 19 11
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

scroll

Post by cirix »

Do we still need IntermissionProperties.scroll=true|false?
I think no. Defining visible sizes is cleaner; it does not depend on the actual window size the player chooses!
cirix
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

acid properties

Post by cirix »

LogicDeLuxe:
you wrote this in the other topic:
$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)
so a boolean flag should be added to acidproperties, as bdcff should also support this!

bye
cirix
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

intermission sizes again

Post by cirix »

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.
cirix
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

cirix wrote:LogicDeLuxe:
you wrote this in the other topic:
$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)
so a boolean flag should be added to acidproperties, as bdcff should also support this!
If you need this, how about:
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.
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. 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.
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.
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:
data base wrote:Initial border element. This element is used to draw the border, which includes the invisible part of the cave.
This should be the best compromise we can get for several reasons:
- 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.
an implicit drawrect might be incompatible with other bdcff files. 20x12 intermissions are incompatible for random generator and invisible parts - even more important.
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.
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

acid

Post by cirix »

i would rather specify an element to which acid converts, it is more generic.
i would even
acid.spreadratio=xxx
acid.convertsto=yyy
and the like. nopuff is the most inconsistent possible.

bye
cirix
Post Reply