Test version 1 of Rocks'n'Diamonds 4.4.3.0 available!

[Holger]

The first test version of the upcoming new version 4.4.3.0 is available now!

The main change of this version is not using the Rocks'n'Diamonds game engine anymore for native Diamond Caves levels, but the native Emerald Mine game engine instead -- with added support for all Diamond Caves game elements.

As Diamond Caves started as a clone of Emerald Mine (and came with a number of converted Emerald Mine level sets), its game engine is very close to the original EM engine (but with some notable differences, like being able to grab falling emeralds and diamonds, which is not possible in Emerald Mine). Therefore, it seems to make more sense to use the EM engine to play Diamond Caves levels than the R'n'D engine, as many Diamond Caves specific changes and additions are already present in the EM engine (or easy to be added).

It is also worth mentioning here that it was much easier to add Diamond Caves specific changes to the very clean Emerald Mine game engine compared to the much more complex (and convoluted) R'n'D engine -- a big thanks must go to David Tritscher here for the code base of the EM game engine!

Everybody who is interested in playing Diamond Caves level sets in Rocks'n'Diamonds is therefore invited to give it a try, and check (and let me know) if it really is the improvement for playing Diamond Caves levels that I think it is.

As this test version is not an official release version, and therefore not available on the usual R'n'D news and download pages, here are the download links for the packages for the main platforms of this test version:

- Linux
- Mac
- Windows (installer)
- Windows (plain zip)

This R'n'D 4.4.3.0 test version works fine with the currently available "official" Diamond Caves level collection package 1.0.0, but you might like to use a slightly updated test version which fixes a few cosmetical bugs:

- Diamond_Caves-1.0.1-test-1.zip

Have fun!

[filbo]

Not currently testing, but I am wondering what this will mean for existing tapes of the levels which are now run by a different engine?

A) latest RnD will be able to smell the tape and know to run it with RnD engine?
B) engines are so compatible that it doesn't matter which one runs the tape?

I'm guessing A. In which case, I assume new tapes from the newly chosen engine will fail / blow up on older RnD?

=====

A subtlety. Suppose one has a saved tape which one would like to 'edit', i.e. play part-way, then take manual control to improve the final outcome. Then this run will (assuming I'm right) use the RnD engine throughout; whereas a completely newly initiated run would use the native EM engine? So the best possible outcomes you could get might vary, even if you just played back part of a second of the saved tape.

All of which leads to assorted weirdness; but nothing fatal, I think; just slight potential for confounding results.

[Holger]

Not currently testing, but I am wondering what this will mean for existing tapes of the levels which are now run by a different engine?

A) latest RnD will be able to smell the tape and know to run it with RnD engine?

Exactly.

B) engines are so compatible that it doesn't matter which one runs the tape?

No, the R'n'D engine and the EM engine are very incompatible, mainly because you can only move every eight frames in the (synchronous) EM engine, while you can move every single frame in the (asynchronous) R'n'D engine.

(The asynchronity of this game engine is the main reason why it has to cover so many "special cases" (just like it is the case with the -- also asynchronous -- Supaplex engine), while the EM engine (and also the -- also synchronous -- BD engine) is very clean and simple in that regard.)

I'm guessing A. In which case, I assume new tapes from the newly chosen engine will fail / blow up on older RnD?

Yes, that's right (as the EM engine in R'n'D 4.4.2.x knows nothing about DC game elements).

=====

A subtlety. Suppose one has a saved tape which one would like to 'edit', i.e. play part-way, then take manual control to improve the final outcome. Then this run will (assuming I'm right) use the RnD engine throughout; whereas a completely newly initiated run would use the native EM engine?

Yes, exactly.

So the best possible outcomes you could get might vary, even if you just played back part of a second of the saved tape.

All of which leads to assorted weirdness; but nothing fatal, I think; just slight potential for confounding results.

Yes, you are right here. Deciding to use a different game engine for exactly the same levels, depending on the version used, is something we did not have before, so I do expect some strange behavior or errors that I haven't detected yet...

[BrownSky]

Hi Holger,

Jumping in ignorantly... will we still be able to use the RnD engine to play the DC levels, if we want?

Are you stripping stuff out of the RnD engine?

Looking forward, what do you envisage for the future of the respective engines?

Off the top of my head, I would see asynchronous as an advance on synchronous, hence the focus for future development; kind of like how acrylic paint has eclipsed oil paint. But, after reading this and other posts, I'm not getting that impression.

An alternative/competing possibility is that the asynchronous RnD engine is perceived as compromised, and thus over time there will be some kind of rollback to focusing on the synchronous engines?

Is another thing to consider that RnD is your engine, Holger, ie you don't have to keep it faithful to some other release out there, whereas for EM, BD etc, you do have to?

I apologize for not knowing what I am venturing into. But I do possess the curiosity I really don't champion the RnD engine because it is asynchronous; I champion it because of the depth and complexity of the elements it allows to use, including elements from other games - but sadly not from the BD engine - well, I wouldn't want to use eg BD fireflies or BD diamonds when RnD has perfectly good equivalents; but BD flying diamonds, BD slime, BD cows and ghosts, well sure...

What would I miss, if the RnD engine went? Well, all the levels I wrote for it. Looking at elements, not so much CEs, to be honest; although I have written a few. But not for a while. In terms of elements:

GEs

RnD specials, like mole and pig, Game of Life, Biomaze

Tubes - or will these be usable in the EM engine, now?

Empty Space 1 to 16

2 sets of text elements

ability to do Sokoban

and quite a few others, I am sure.

Apologies if this should be a topic of its own. I just cannot help noticing that almost all of the development effort* is non-RnD engine. As a RnD fan I feel like a dodo, or giant tortoise, watching some humans newly arrived on the island who are gathering wood and lighting a fire onto which they have put a big cast iron pot full of water

* which I appreciate, honest! it is yout time and your generosity that keeps this project alive!

John

[Holger]

Hi BrownSky,

Jumping in ignorantly... will we still be able to use the RnD engine to play the DC levels, if we want?

technically this is still possible (and will be used to replay existing tapes for DC levels), but the next R'n'D version will use the EM/DC engine for playing DC levels by default, because it will be the more compatible game engine for these levels (hopefully -- the test version is available to check if this is really true for the majority of DC levels). (There will probably be no simple switch or setup option to use the R'n'D engine instead of the EM/DC engine, so you might have to use version 4.4.2.4 to play that way.)

Are you stripping stuff out of the RnD engine?

No, as all those existing DC game elements are supported by the R'n'D engine since ages (and is used by many existing R'n'D levels), support for them will never be stripped from the R'n'D engine.

I would see asynchronous as an advance on synchronous

It definitely is, I think, because it allows for noticeably smoother gameplay! But if the goal is exact emulation of existing level sets, this also has to be considered (as is the case for BD, EM and DC level sets).

An alternative/competing possibility is that the asynchronous RnD engine is perceived as compromised, and thus over time there will be some kind of rollback to focusing on the synchronous engines?

No, I don't think so -- it's just a different game engine (just like the asynchronous SP engine) that works a bit differently.

I'm quite sure many players won't even notice the difference (or care about slightly different level of "smoothness" in player movement)...

Is another thing to consider that RnD is your engine, Holger, ie you don't have to keep it faithful to some other release out there, whereas for EM, BD etc, you do have to?

Regardless of game or engine type, I try to keep a given engine as compatible to existing levels as possible -- be it "classic" levels, for which the BD, EM and SP engines exist, or be it "newer" levels, for which the R'n'D exists. And the DC levels are somewhere in between...

I really don't champion the RnD engine because it is asynchronous; I champion it because of the depth and complexity of the elements it allows to use, including elements from other games - but sadly not from the BD engine - well, I wouldn't want to use eg BD fireflies or BD diamonds when RnD has perfectly good equivalents; but BD flying diamonds, BD slime, BD cows and ghosts, well sure...

Well, the R'n'D engine supports all BD game elements for the "classic" BD games, but does not support the game elements of newer BD incarnations. Just like the R'n'D engine does not support DC game elements from newer DC incarnations.

And since the R'n'D engine offers great possiblilites by using custom elements, I have the feeling that adding new "static" game elements to it has more disadvantages (due to even higher engine complexity) than advantages (by offering even more game elements).

What would I miss, if the RnD engine went? Well, all the levels I wrote for it.

The R'n'D engine will always be the "main" game engine for R'n'D, and will never be taken away from it, as this would make no sense. But yes, maybe there will be more game elements in native game engines (like BD or EM) that won't be supported in the R'n'D engine.

So what has changed over time is that the R'n'D game engine is not the "superset" engine anymore that contains and unites all existing BD/EM/DC/SP/whatever style game elements from all other game engines, but rather "yet another BD/EM/DC/SP/whatever style game engine", just with many (maybe too many) game elements supported by it.

[ncrecc]

I'm quite sure many players won't even notice the difference [between moving around in RnD/SP and moving around in BD/EM] (or care about slightly different level of "smoothness" in player movement)...

...that must be a cultural/generational difference, because i notice, and it absolutely drives me nuts how rockford in BD & EM will seemingly ignore my keypresses about a quarter of the time, and his reaction speed to my inputs fluctuates to the point where most of my deaths look like i walked into a spaceship because i was curious about it. but that's just the canonical input scheme & event loop of those games so i guess there's nothing that can be done about that.

[BrownSky]

(There will probably be no simple switch or setup option to use the R'n'D engine instead of the EM/DC engine, so you might have to use version 4.4.2.4 to play that way.)

Holger about this, currently the Config contains a dropdown that allows the user to change the engine for the level, and it doesn't do any restricting - if the combination of level and engine makes no sense, like say the SP engine with a level with non-SP elements, you find that out when you play it.

How will the ability to play a DC level with a different engine be prevented? That sounds like a change from what I have described above?

Well, the R'n'D engine supports all BD game elements for the "classic" BD games, but does not support the game elements of newer BD incarnations. Just like the R'n'D engine does not support DC game elements from newer DC incarnations.

And since the R'n'D engine offers great possiblilites by using custom elements, I have the feeling that adding new "static" game elements to it has more disadvantages (due to even higher engine complexity) than advantages (by offering even more game elements).

Well, I don't think growing complexity is a bad thing - otherwise games like Minecraft wouldn't release new versions, with new kinds of block as well as all sorts of other tweaks. And could the ability to make changes by telling AI what you want and having it make the changes, or at least propose some, and scan the codebase to find the places where the changes have effects, assist with handling growing complexity?

The R'n'D engine will always be the "main" game engine for R'n'D, and will never be taken away from it, as this would make no sense. But yes, maybe there will be more game elements in native game engines (like BD or EM) that won't be supported in the R'n'D engine.

So what has changed over time is that the R'n'D game engine is not the "superset" engine anymore that contains and unites all existing BD/EM/DC/SP/whatever style game elements from all other game engines, but rather "yet another BD/EM/DC/SP/whatever style game engine", just with many (maybe too many) game elements supported by it.

I had an idea for a set of new elements for RnD that are like Tube, but both player and monsters can go over/under them when not entering through an open bit, and also monsters can enter the tube through an open bit, and journey through it, and if they encounter the player inside the tube, explode. Which I don't think could be done with CEs. And would mean a lift in the game engine's complexity as it would need to be able to handle 3 elements in the same place - i) tube, ii) player/monster inside tube, iii) player/monster outside tube. Maybe even 4, if you consider the scenario of a pig entering the tube and going past the player, as pigs are able to do??? But now I am feeling like there isn't much point...

John

[Holger]

I'm quite sure many players won't even notice the difference [between moving around in RnD/SP and moving around in BD/EM] (or care about slightly different level of "smoothness" in player movement)...

...that must be a cultural/generational difference, because i notice, and it absolutely drives me nuts how rockford in BD & EM will seemingly ignore my keypresses about a quarter of the time, and his reaction speed to my inputs fluctuates to the point where most of my deaths look like i walked into a spaceship because i was curious about it.

In fact, I do feel exactly the same about this when playing either BD/EM games or R'n'D/SP games. I noticed this again every time I played BD caves (when integrating the new BD engine in 2024) and when playing Krissz BD caves (when extending the BD engine for Krissz engine support in 2025) -- the latter is actively played a lot on Krissz' BD web site, and new caves are regularly created and played there, some of them being really hard. And I always wonder how people can cope with this systematic movement delay -- I'm totally bad at playing that way, permanently getting killed due to bad timing.

Maybe it works if you only ever play with these "delayed" engines (BD or EM), but if you're used to the player instantly moving when you press a key, you're probably spoiled for playing with that arbitrary delay.

but that's just the canonical input scheme & event loop of those games so i guess there's nothing that can be done about that

Unfortunately, that's true. The main problem is that in the BD and EM engine, every single game element always moves at the exact same time (game frame), waiting for eight frames after each (possible) move. This is what makes these engines really nice and clean, while it adds all these "special cases" and bugs (and things that at least look or feel a bit buggy) to the SP and R'n'D engines, in which every game element (and the player) are allowed to move each single game frame.

[Holger]

(There will probably be no simple switch or setup option to use the R'n'D engine instead of the EM/DC engine, so you might have to use version 4.4.2.4 to play that way.)

Holger about this, currently the Config contains a dropdown that allows the user to change the engine for the level, and it doesn't do any restricting - if the combination of level and engine makes no sense, like say the SP engine with a level with non-SP elements, you find that out when you play it.

How will the ability to play a DC level with a different engine be prevented? That sounds like a change from what I have described above?

The option "Default Game Engine" in the "Game Engines" setup menu apparently is a bit misleading, at least now that there is the question of using either the EM or R'n'D engine to play DC levels (which is both possible, in general). This option is only used to select a default game engine when creating new levels in the level editor, but not for playing levels (for which there is always a matching game engine defined for each level, depending on the level format/type).

That is, all DC levels will always be played with a "fixed" game engine (which was the R'n'D game engine in 4.4.2.x, and will be the EM/DC game engine from 4.4.3.x on).

Well, I don't think growing complexity is a bad thing - otherwise games like Minecraft wouldn't release new versions, with new kinds of block as well as all sorts of other tweaks.

I think the main difference here is the number of employees at Microsoft (over 200,000) and Artsoft (only one), which could be advised to test new features for bugs and incompatibilities.

And could the ability to make changes by telling AI what you want and having it make the changes, or at least propose some, and scan the codebase to find the places where the changes have effects, assist with handling growing complexity?

It can definitely help to write the code for new features (like new game elements). But this is the easiest part! Testing for bugs and (especially) for all possible interactions with other game elements (and check what is the "right" behavior and what would be considered "wrong") is the really had part, and for now I cannot see how AI could assist with it (especially as that decision between "right" and "wrong" is highly dependend on inner (sometimes strange) game engine logic -- for example, does it really make sense that emeralds slip off flat steel walls in the EM engine?).

I had an idea for a set of new elements for RnD that are like Tube, but both player and monsters can go over/under them when not entering through an open bit, and also monsters can enter the tube through an open bit, and journey through it, and if they encounter the player inside the tube, explode. Which I don't think could be done with CEs. And would mean a lift in the game engine's complexity as it would need to be able to handle 3 elements in the same place - i) tube, ii) player/monster inside tube, iii) player/monster outside tube. Maybe even 4, if you consider the scenario of a pig entering the tube and going past the player, as pigs are able to do??? But now I am feeling like there isn't much point...

That all sounds like a funny new extension (and I think it would indeed be cool), but it would require major changes of the complete game engine. Currently there is only one game element allowed at the same tile (with the player not counting here as a game element, because he is handled separately) -- and the few exceptions (like dynamite) are all handled as "special cases", but not in a generic way, so allowing monsters in tubes would require adding a new "layer" for the playfield, and a lot of additional checks against game elements that would exist either on the "normal" or the "new" layer.

Those (relatively new) "background game elements" were already "bending" the game engine a little bit, but in the end this is just graphical sugar, and no extension to the game engine (because neither the player, not other game elements -- like monsters -- can interact with these background "elements").

[BrownSky]

First of all apologies if I have stuffed up the quoting, I have done it with copy paste, and it gets harder with increasing complexity.

(There will probably be no simple switch or setup option to use the R'n'D engine instead of the EM/DC engine, so you might have to use version 4.4.2.4 to play that way.)

Holger about this, currently the Config contains a dropdown that allows the user to change the engine for the level, and it doesn't do any restricting - if the combination of level and engine makes no sense, like say the SP engine with a level with non-SP elements, you find that out when you play it.

How will the ability to play a DC level with a different engine be prevented? That sounds like a change from what I have described above?

The option "Default Game Engine" in the "Game Engines" setup menu apparently is a bit misleading, at least now that there is the question of using either the EM or R'n'D engine to play DC levels (which is both possible, in general). This option is only used to select a default game engine when creating new levels in the level editor, but not for playing levels (for which there is always a matching game engine defined for each level, depending on the level format/type).

That is, all DC levels will always be played with a "fixed" game engine (which was the R'n'D game engine in 4.4.2.x, and will be the EM/DC game engine from 4.4.3.x on).

[/quote]

I meant the dropdown within the Config menu/dialog of the level editor. I may open a level that was intended for one engine, eg the EM engine, and change it to say the RND engine, and test-play it from within the level editor, and then maybe make some changes, etc, and then eventually save it, or cancel without saving. I guess I am asking, will that facility to play any level using any engine, when within the level editor, continue to exist?

And could the ability to make changes by telling AI what you want and having it make the changes, or at least propose some, and scan the codebase to find the places where the changes have effects, assist with handling growing complexity?

It can definitely help to write the code for new features (like new game elements). But this is the easiest part! Testing for bugs and (especially) for all possible interactions with other game elements (and check what is the "right" behavior and what would be considered "wrong") is the really had part, and for now I cannot see how AI could assist with it (especially as that decision between "right" and "wrong" is highly dependend on inner (sometimes strange) game engine logic -- for example, does it really make sense that emeralds slip off flat steel walls in the EM engine?).

[/quote]

I have never done it myself, but I understand that unit tests can be set up to just pass or fail a test, does the headless version of the program support this? I suppose levels can get too random to provide a deterministic result, but a seed can force that, but that is ignoring the effect of the player which is non-deterministic, but for testing can a set of player instructions be provided, even if just 'move right - wait 8 cycles - move right -wait 8 cycles - move down' etc? For a simple enough level, could test to confirm that eg an emerald continues to slip off a flat steel wall in the EM engine? Do levels need a player to be auto-testable? I guess that it not really a limitation, the player can be there but do nothing while the emerald either falls off the wall, or not?

I had an idea for a set of new elements for RnD that are like Tube, but both player and monsters can go over/under them when not entering through an open bit, and also monsters can enter the tube through an open bit, and journey through it, and if they encounter the player inside the tube, explode. Which I don't think could be done with CEs. And would mean a lift in the game engine's complexity as it would need to be able to handle 3 elements in the same place - i) tube, ii) player/monster inside tube, iii) player/monster outside tube. Maybe even 4, if you consider the scenario of a pig entering the tube and going past the player, as pigs are able to do??? But now I am feeling like there isn't much point...

That all sounds like a funny new extension (and I think it would indeed be cool), but it would require major changes of the complete game engine. Currently there is only one game element allowed at the same tile (with the player not counting here as a game element, because he is handled separately) -- and the few exceptions (like dynamite) are all handled as "special cases", but not in a generic way, so allowing monsters in tubes would require adding a new "layer" for the playfield, and a lot of additional checks against game elements that would exist either on the "normal" or the "new" layer.

Those (relatively new) "background game elements" were already "bending" the game engine a little bit, but in the end this is just graphical sugar, and no extension to the game engine (because neither the player, not other game elements -- like monsters -- can interact with these background "elements").

[/quote]

I would love you to go into more detail on all this sometime, i.e. a walk-through of what goes on in the playfield, for the RND engine, and maybe contrast it with the other engines. TBH I got a bit confused with the last paragraph because it was so general. By "Those (relatively new) "background game elements" " do you mean the " few exceptions (like dynamite)" [which] "are all handled as "special cases" " ? And by that do you mean that once placed, dynamite cannot be picked up again? But if a monster bumps into it before it explodes, the monster will bounce off, right? And when it explodes, that is some interaction.

Makes me want to try to figure out what happens if a dark yam yam hits burning dynamite before it explodes - actually from memory, dark yam yams don't consume dynamite do they, so the question is moot?

Switching from special case-handling of 2 things [in the same tile] being a special case to a general thing, in the RND engine, sounds like a very worthy goal! It would allow the creation of monsters that swap places with existing elements, instead of the monster just replacing the tile contents with itself, and then [sometimes] with something else when it leaves the element?

It's all very confusing and fascinating. I know there is scientific research into cellular automata. I think the guy who contributed the code for the headles running of R'n'D was working in that. Has anyone else looked into this app [and specifically, the R'n'D engine] as a leading engine for building and running 2D cellular automata? But I guess the attention has switched to 3D ones.