Thoughts on Where from here after 4.4.2.0

[BrownSky]

I like to acknowledge each release with a heartfelt '3 cheers for Holger', so, just like always, big thanks to Holger for the new release. Maybe even bigger this time, as this release looks very interesting, with changes in so many areas. I like the way that the announcement clearly groups the changes.

Holger you wrote:
"additions to improve Emerald Mine support
[cut]
added checkbox to use EM/DC style duration in “moves” instead of seconds"

I am curious about this, as I thought that DC was handled within the RnD engine? This belief was based upon my believing that the EM engine only handled elements within the sections of the palette,
- EM
- EMC
- TEXT [first one of two]
At least when a level is changed from the RnD engine to the EM engine,
these are the sections that remain.

It seems I had a simplistic understanding. Holger have you time to discuss this?

I probably should wait for your reply, but this ties into my belief that the division of the palette into BD, EM, EMC, RND, DC2, DX is neither logical nor optimal (I don't have a problem with the other divisions). I think that it would be better to be able to put the non-GE, non-CE, no-REF elements into one pot, and be able to filter them by choice of engine from a dropdown (this should be optional so there is the ability to place an element irrespective of engine),
and choose to sort the visible elements by, say:
- description A-Z
- token A-Z
- element type, at a high level, eg all normal walls together, all steel walls together, all monsters, and so on.

This might also tie in to dicussions about how EM elements behave differently under EM and RND engines. To take an example, Fake Acid; this is not on the palette at all, but is an EM element; it is stated that the player can move through it; this is true under the EM engine, but under the RND engine, it behaves like wall. I would love to have this element easily available under both engines, and be walkable through by the player, under both engines.

I had an idea, is there any way that element behaviour could be moved outside of the individual engines, to an 'element' subsystem, which the engines then call? Hence the logic for say Fake Acid could be defined in one place, and then there would just be calls to it from the engines which are allowed to use it.

I get that on the face of it, this would be harmful to an engine accurately mimicking the original engines for EM, SP, BD etc; but, this could be dealt with by keeping the different algorithms for one element or element type together, and ensuring that an engine calls its algorithm for the element, if there are engine-specific algorithms for an element; it not, attempt to use the general one? The last part is assuming that it is possible for different engines to share an algorithm; even if not, it might be logically beneficial to keep the various flavours of an algorithm adjacent to each other.

I had better come clean here and admit that I would quite like to make a few of the elements under BDX engine become available under the RND engine (as fully functional elements, not just wall-like elements), even if there is not much chance of making that happen. I accept that there are BDX features that could not be ported to RND, such as the wrap-around, and that's fine, I don't want to bring them across; I like RND without the wrap-around.

On the other hand there are aspects of Boulderdash that none of the engines seem to emulate, such as true-diagonal movement - for monsters, and/or player - I've seen this in some forks of BD running on a C64 emulator - and I would love for this to become available within RND, in all the engines that it makes sense for - BDX I suppose - and definitely RND engine.

Also I love TheOnyxGuy's "R'n'D in WIDESCREEN" release, but I don't think I will be using it much unless it is integrated into the app as a built-in feature, choosable by going into Settings and checking a checkbox or selecting from a dropdown list.

And while I'm on Dream Street, wouldn't it be great to release with the ability to run in 64-by-64 pixel graphics?

A combination of widescreen and 64-by-64 pixel graphics would go someway to making up for the screen-gobblingness of the 64-by-64 pixel graphics. I believe that certain members have produced 64-by-64 pixel graphic strips over the years, although I guess they would be a bit out-of-date now.

Wouldn't it be good if the graphic strips could be auto-converted, so 2 sets of files wouldn't have to be maintained? - I guess this would mean down-scaling from 64 sq to 32 sq, and I guess this wouldn't be considered good enough, since auto-down-scaled graphics would not look as good as manually designed graphics. But for some of us, they would be.

John

[BrownSky]

Bumping...

First of all, I admit that I don't know if this is feasible, either at all or with a reasonably small amount of effort.

Same example benefits of this idea of shifting the monster/moving element logic into a 'central repository' that could be accessed by multiple engines:

- what some users have noticed, about the same elements behaving differently in EM and RND, should go away.

-- eg Fake Acid doesn't allow player to walk through it in RND

-- eg Nccrec reported bug with Score for slurping robot in RND engine, and:
"in the EMC engine, pushing this spring right will result in it running over/"slurping up" the robot (yielding the amount of points specified by "Score for slurping robot") and meeting the spring bouncer. in the RnD engine it will just stop at the robot"

- eg in: viewtopic.php?t=3719
Ryz reported "the Plant tile, which has two unique distinctions that make it different from an unremovable Land Mine, which is that enemies can dig through them safely, and boulders and similar objects like that would remove them under the weight of those objects.
I was so disappointed when I thought of some ideas for the level generation scenarios and tried using the Plant tile, as it didn't work like it was supposed to from the Emerald Mine engine but in the Rocks'n'Diamonds engine. it's just a reskin of the Land Mine element that can't be removable, as I can't find the differences between the two after some testing."
-- I feel that the EM behaviour is plainly far superior, because more sophisticated, and offers more opportunities;
this is why I'm perservering with this proposal, because I feel that the multiplicity of engines has an unfortunate side-effect, which is a decline in the quality of elements from other [non-RND; basically, EM] engines, even when they are usable in the RND engine.

- eg in: viewtopic.php?t=3700
Ryz reported many oddities, but re-reading that conversation I don't know if it is about differences between engines or not, but for example:
"Wait, the springs can kill bugs in a similar manner as robots?"
- if this was implemented [as a checkbox option?] it would be cool for it to be cross-engine, as in, across EM and RND engines.
- (p.s. re-reading this page makes me realize how little I know; is this about the EM engine, or the BDX engine? Or both? Is the BDX engine able to play all, or nearly all, of the Emerald Mine Club collection levelsets? Or just Emerald Dash?)

- And of course, none of the BDX elements are available in the RND engine. Nor are they meant to be, I know I know. Nor do even I think they should be, like BDX firefly type 1, which is basically identical to BD firefly [handled by EM and RND engines].
On the other hand: other forum members [not just me] have wished for being able to place e.g. ghosts or cows in an RND level...

- eg in: viewtopic.php?t=3719
Ryz reported "Would it be possible to just have a toggle to enable the proper effects like in the Emerald Mine engine? If you have to, you can have a Rocks'n'Diamonds kind of spin, like you did with most of the Emerald Mine Club elements (for example, out of the blue, I did not realize that Magic Balls when spawning elements in the Rock'sn'Diamonds engine, when it tries to spawn an element that's occupied by the player, just kills them instead, which can make some interesting scenarios that's different from doing it in the Emerald Mine engine)."
- this is an example of where the new 'element behavior store' would need to be able to handle differences in behaviour and configurability between EM and RND,
either by means of some kind of OO encapsulation/polymorphism kind of thing [???], or with 2 copies of the algorithms, one for EM and one for RND. But kept together so it is easy to get an overview of the behavior of the Magic Ball over all engines that support it.
- at the very least, it might make it easier to find the 2 versions of the algorithm, to do some kind of line-by-line diff on them

- someone even once asked about bringing across MM/DF elements to RND, but I think that is a different/harder/impossible thing, because the style of gameplay is just so different. So no, I am not advocating that.

* * *

Trying to be not too uninformed/ignorant, I guess the difference between the RnD engine and other engines in terms of the following might be a problem:

viewtopic.php?t=3728
ncrecc:
"
even then, since this is the BD engine, the animation of the diamond falling does not actually reflect game logic. it is a purely visual feature that can be toggled with the "smooth movement" setting in Setup->Game Engines->Boulder Dash. the reality of the matter is that the diamond always existed solely on the tile it eventually "falls" into, as, behind the animations, Boulder Dash is strictly a grid-based game where all elements are tiles on a grid.
"
Holger:
"
As ncrecc already wrote, the BD engine works 100 % synchronous, and all game tiles are always at exactly one position on the grid. Everything else (especially the "smooth movement") is just visual sugar I added to let it look more like the other game engines -- the BD engine in R'n'D (and the original BD game) internally does not know anything of what looks like a game element moving from one tile to another.
"

My [John's] interpretation of the above is that the RND engine supports partially-in-cell mode, whereby a single monster/player/rock/gem/zonk/nut/bomb etc can block 2 cells at once, because in each of them [partially]. Whereas, the other engines, EM and BDX, only allow an element to be in one cell at any point in time.

Putting on my thinking cap, this would seem like a major difference, that could make it hard for the same algorithm for element behavior [eg amoeba growing, or robot movement] to be the same under different engines.

Ideas:

Try to find a common routine that can be called before or after the element behavior algorithm, to make it work in one of the engines, say RND,
whereas the 'naked' algorithm could be used 'as is' by the simpler algorithm [EM or BDX].

Or:

Cripple/gut the RND engine so it no longer supports partially-in-cell mode, and becomes one-cell-per-element, like the EM and BDX engines?
- con: some [maybe a whole lot?] of the RND levels cease to work as intended
- pro: Holger you have referred to the RND engine as bug-ridden, would this help make it less buggy / more maintainable, and maybe even enhanceable?

* * *

A pro of this proposal to move elements into an 'element behavior store' might be:

- the ability to create levels under the EM and BDX engines, either in 'classic' form [with no non-engine elements, in the original file format, and able to be played in other emulators],
or in 'extended', 'RnD-like' mode [= eg can have elements from RND, SP, Sokoban, DC2, DX,
- probably requires RND file formats;
-- really this would be adding the ability to play an RND level under the EM or BDX engine,
but without any of the RND special stuff, such as partially-in-cell mode, and with all the engine's own features, eg BDX's wraparound mode.

So you could have cows and pigs roaming around, together.

There is some programming term for doing this, in object-oriented programming at least, is it encapsulation? I will just use the term "refactoring" very loosely.

To simplify this, it could go hand in hand with refactoring/simplifying/abandoning the built-in palette, for something more straightforward, like an A-Z listing, or different columns for EM/RND/BDX, and a 4th column for other engines?

* * *

Idea: could this be implemented in part, over time? E.g. whenever an element is adjusted, move its behavior into the new 'element behavior store', while keeping elements that haven't been modified since it was begun, in their locations. This would enable testing of the concept.

* * *

Apologies if this post seems a bit off, it arose due to my wondering how to create a more holistic, universal experience under the different engines, while still keeping their unique features. And allowing a 'mighty stew' of all/many of the various different elements.

John

p.s. This post doesn't mention the Supaplex engine at all, not on purpose, it's just that I don't think about it much, as it has so few elements that the permutations available seem few to me. But I could be wrong. I like that RND allows use of Supaplex elements, maybe there are some discrepancies between these 2 engines too, I don't know.

[filbo]

Speaking as a viewer (and person who has looked inside the RnD code from time to time) -- the above proposals would amount to a tremendous amount of work. And one of Holger's guiding lights throughout this entire project has been careful, detailed backwards compatibility.

Your ideas are possible, but you're asking the one-man team to take a 5000 mile detour in the wrong direction in the middle of their 50-mile journey.

[ncrecc]

Cripple/gut the RND engine so it no longer supports partially-in-cell mode, and becomes one-cell-per-element, like the EM and BDX engines?

this seems like it would be a lot more work than just implementing analogues of the BDX elements one by one (which is already a lot of work) - since every single moving element in RnD would need to be rewritten, many probably with ghastly kludges (i am sure amoeba drops in EM, which move at half the speed as everything else, are kludgy enough already).

one of the more difficult BDX elements to implement would probably be the gravity switches as every element with gravity would need to be rewritten so that gravity can be any arbitrary direction. flying rocks/diamonds are likewise probably difficult for crushing things upward (but would at least come for free with gravity switches: just copy the code for regular rocks/diamonds but make them fall in the opposite direction). they'd also require rewriting slipperiness since all 4 sides of an element now need to have independent slipperiness behavior if sloped walls are to be recreated. (ideally this would just be 4 boolean properties: slippery on top-left corner (e.g. objects falling down can/will slip left, and objects falling right can/will slip up), slippery on top-right corner, slippery on bottom-right corner, slippery on bottom-left corner -- but i'm not really sure how helpful that simplification would end up being.)

in some future realm where i can be bothered to learn C (i'm used to Lua, and i thought it was just a lesser version of C until i actually tried writing C. who in the world thought a preprocessor with its own syntax was a good solution to entering redundant data? ah, the guys whose reference point for programming language usability at the time was FORTRAN...) i would take a crack at adding some of the more trivial-seeming elements myself, perhaps getting a better idea of how trivial they are or aren't:

• nitro packs (just bombs but they don't detonate when landing on sand)
• box
• clock
• water
• heavy rocks
• light rocks (ideally air-pushable in both directions since RnD isn't bound to the silly quirks of BD)
• grass ball
• loose grass
• glued elements that are just equivalent to fancy-looking dirt/walls
• invisible exit (appear to be normal walls; perhaps still make "door opening" sound when opening to hint toward the player)
• invisible steel exit (likewise but steel walls)
• stonefly (just take the butterfly and make it explode into BD rocks!)
• firefly 2/butterfly 2
• sloped walls (probably equivalent to the "only left" and "only right" slipperiness settings for CEs - although gravity switches complicate things as mentioned above)

some possibly less trivial ones:

• trapped bubbles/bubbles (the thing of being able to push them around corners might be tricky)
• acid (would warrant new graphics)
• replicator (would warrant new graphics)
• glued players
• slime (i'd imagine some code could be reused from/shared with magic walls)
• waiting/chasing rocks (seems like they replay player movements but also just try to minimize distance to the player sometimes. could the logic for this mostly just be copied from BDX?)
• bombs (dropping puts them in front of you and requires space to be available in that direction. the "in front of you" part could be solved by just having them start underneath the player and move 1 tile in the direction they're facing. also ideally bombs that explode into empty space would free walls with content)
• voodoo dolls

some BDX elements that would force interesting design choices (because i have an unfortunate habit for thinking about interesting design choices over actually writing code):

• keys 1-3 & gates 1-3 (would these be new keys entirely or just use existing keys? what color/appearance should the keys and doors be to differentiate them from normal red/yellow/green RnD keys/doors?)
• conveyor belts (these would need to be faster than normal RnD conveyor belts for levels to work - although i imagine they will need to have a "faster" setting for sufficient DC2 compatibility anyway)
• conveyor belt power/direction switches (would these only be a thing for yellow conveyor belts or would every conveyor belt get them in addition to the normal switch? at least these both have different designs than the left-middle-right conveyor belt switch)
• jackhammer/walls with content (in BDX, walls with content only yield their content when mined with a jackhammer; merging them into normal walls with content would be the obvious move but would break some simple BDX levels that aren't even Crazy Dream-level complicated - that wall-with-diamond that's supposed to only be breakable with the jackhammer at the end of the level can now be harvested with a nearby firefly!)
• rocket launcher (presumably rockets go in the inventory like dynamite does, but what happens if you collect a rocket when you don't have a rocket launcher? should collecting a rocket only do something if the current item to drop is a rocket, and rocket launchers only give you a rocket if you don't already have one? and what to make of infinite rockets? if you pick up a rocket launcher with infinite rockets enabled, does it just cut off the rest of your inventory then and there?)
• ghosts (among the possible elements it can spawn are duplicate players, which i doubt is supported well by RnD)

things i won't even consider:

• gravity switches (as mentioned)
• effects (not that RnD can't be equally crazy and unpredictable with CEs... just look at slappyhappy's latest levelset)
• true-diagonal movement

of course then i am in the same position as i presume holger is: can't i make better use of my time?