Rocks'n'Diamonds

In some Emerald Mine levels, the object "Dead Amoeba" appears. However, this object is not available in the editor menu. While you can set the "Dropping Amoeba" speed to 0, which has the same effect, this limits you to using only one type of Amoeba per level. I don't know if this is a bug or intentional. It occurs, for example, in Emerald Mine 1 Kingsoft level 27.

I don't play EM games, so when I create a level or play one of my own, I am using the RND engine. This makes available most of the elements (excluding MM/DF and Boulder Dash engine). When playing using the RND engine, Dead Amoeba is under the RND section, not under EM or EMC. Matter of fact the grouping (in the palette) of elements by the game in which the element was originally introduced is not completely accurate. I would vote for doing away with the grouping by source game, and putting all elements 'of a type' together, eg all amoeba, all magic wall, etc.

I appreciate above doesn't help with your problem, which seems to be that Dead Amoeba doesn't appear on the palette when EM engine is specified. That could be fixed by just adding Dead Amoeba to the list of EM/EMC elements. I still like the idea of going from a hierarchical, 'top-down' grouping to a 'bottom-up' approach to building the palette, though.

Not to create Extra Work For Holger or anything, but ...

I see the value of the which-engine-did-it-come-from editor layout; especially when you might eventually intend to export the resulting level to some other game milieu where it mattered, OR set its RnD metadata to indicate running it under a different one of RnD's internal engines.

On the other hand, if you intend to run your levels only in the RnD main engine with support for everything, I can see the value of sorted-by-concept.

So, maybe the editor could be switchable between these modes? One of these years when Holger is feeling bored :)

Well, as shown by this post, the top-down grouping hasn't been implemented 100% correctly, and I think it would be a lot of (low-profit?) work to make it so, and even then the choices made would be arguable.

e.g. why differentiate between EM and EMC? They are both handled by the EM engine, at least in RND they are. Is there such a thing as an 'EM purist' who only plays EM levels without elements introduced in EMC? Wouldn't that mean no yam yams?

Sokoban elements have no engine of their own and are handled by the RnD engine. Still, I see that some people prefer having them clearly marked out. I guess I am quite technical-minded, but also ignorant - eg I don't get why the Boulder Dash (new) engine) had to define new elements for firefly, butterfly etc and could not share the elements used by the RnD and Emerald Mines engines - after all, the latter two engines share some of the same elements; why not the Boulder Dash engine?

It would be much better from my POV, to have a palette that could so snazzy things such as:

- Allow filtering by showing all elements that work in a particular engine [but not force use of only them; that would be more restrictive than now]

- Allow filtering by typing a text string, so could type 'fire' and get everything starting with that, and maybe could type '*fly' and get things containing 'fly' but with text before it, or something.

- And/or, have a dropdown of categories so could pick all walls, all growing things, all monsters, all falling things... of course the job of categorising and grouping elements could turn into a job that never ends! I think though the ability to refer to element types by kinds of similarity is an area that could be used to make RnD, or at least its editor, much more powerful.

John

My mistake in my previous post: I checked the palette and, according to how it is structured, yamyams were introduced in EM - non-directional - and directional yamyams were introduced in EMC.

Now, regardless of whether this is true, historically speaking, I just don't think that distinction is of much use in 2025, or to recent arrivals to RnD. In other words I think it will become less and less help as the years go by, and more of a drag.

But I don't have any domain knowledge of EM / EMC - don't usually create levels using the EM engine - created one yesterday, and was surprised by the sideways wrapping behaviour, which I had forgotten about.

It is fantastic having access to elements from multiple games, and of course their engines - but it sure does create complexity, and I'm guessing, place some kind of 'dead hand' over future decisions, that would not apply to a game that 'did its own thing' and developed/enhanced a single engine.

John

I can't speak to Holger's reasoning, but:

There's a lot of activity in 'retro' computing these days. This often means melding together ancient things + current ones. For instance, I semi-follow an Apple II retro group on Facebook -- people are constantly refurbishing ancient Apple II systems, really excited to find one with a low serial number, stuff like that. Meanwhile, they're plugging in Apple II-bus-to-DisplayPort adapters, running old games in VMs on their Raspberry Pi 4 systems -- all sorts of combinations.

All of which means, it is entirely likely that someone, somewhere, is running The Original Emerald Mine game on their whatever-system (or emulator or who knows what). And then they'll want to inject new data -- new levels -- into their old rig.

And that is one reason why it may still be valuable for new content creators, like people making levels, to have firm inline guidance as to which elements are 'valid back then' vs which will only work in newer EMC engines, or only in RnD, or whatever. They might be intentionally creating levels which can be carried 40+ years into the past and run on an old system (real or emulated).

Cyberjack wrote: ↑Sat Dec 27, 2025 5:19 pm In some Emerald Mine levels, the object "Dead Amoeba" appears. However, this object is not available in the editor menu. While you can set the "Dropping Amoeba" speed to 0, which has the same effect, this limits you to using only one type of Amoeba per level. I don't know if this is a bug or intentional. It occurs, for example, in Emerald Mine 1 Kingsoft level 27.

This is definitively a bug! All game elements supported by the native Emerald Mine game engine should be available from the "EM" section of the "element palette" menu in the level editor!

Thanks a lot for reporting this! I hope I will be able to fix this soon.

I see the value of the which-engine-did-it-come-from editor layout; especially when you might eventually intend to export the resulting level to some other game milieu where it mattered, OR set its RnD metadata to indicate running it under a different one of RnD's internal engines.

The current approach is especially useful for only offering those game elements that are supported by the currently selected game engine. (And that's why the"missing dead amoeba" issue should be fixed.)

On the other hand, if you intend to run your levels only in the RnD main engine with support for everything, I can see the value of sorted-by-concept.

Unfortunately, the "main" R'n'D engine does not suppport everything anymore, as I did not want to implement those various new game elements (like cows) or techniques (like optional diagonal movement for the player) from the GDash engine to the R'n'D game engine anymore (which is really complex and buggy enough in its current state). (Not to speak of all those Mirror Magic game element, which do not belong to the whole "R'n'D game genre" anyway.)

So, maybe the editor could be switchable between these modes? One of these years when Holger is feeling bored

Nevertheless, I did think about this idea since many years (and it would be quite easy to implement): Offer (via setup) an alternative set of element palette sections in the level editor, like "walls", "gems", "monsters" and so on (somehow similar to how it was done in old versions of "Diamond Caves"; not sure if it still looks that way).

Well, as shown by this post, the top-down grouping hasn't been implemented 100% correctly, and I think it would be a lot of (low-profit?) work to make it so, and even then the choices made would be arguable.

e.g. why differentiate between EM and EMC? They are both handled by the EM engine, at least in RND they are. Is there such a thing as an 'EM purist' who only plays EM levels without elements introduced in EMC? Wouldn't that mean no yam yams?

Have a look at the EMC collection: Older level sets only use the "EM" subset of game elements as used by the original EM game engine, while newer ones (using the enhanced "No One & Ruppelware" EMC engine on their corresponding Amiga disks) use many more game elements (which can also be seen in the included graphics sets).

Of course, the EM/EMC engine in R'n'D (thanks to the work of David Tritscher, who wrote this engine for his game "X11 Emerald Mine") supports both the "pure EM" game elements and also the "extended EMC game elements.

But it seemed to make sense to me to put those elements into separate element palette sections (although this also means not to have those four additional keys and doors next to the original four keys and doors, which would indeed be nicer if you do not know anything of the above).

Sokoban elements have no engine of their own and are handled by the RnD engine. Still, I see that some people prefer having them clearly marked out.

It's indeed only a small subset of the R'n'D engine, but for Sokoban-only level sets it might be nice to have just the Sokoban game elements put together in their own palette section.

I guess I am quite technical-minded, but also ignorant - eg I don't get why the Boulder Dash (new) engine) had to define new elements for firefly, butterfly etc and could not share the elements used by the RnD and Emerald Mines engines - after all, the latter two engines share some of the same elements; why not the Boulder Dash engine?

That's a very good question indeed, which I can answer here.

In fact, I tried hard to not have duplicate BD style game elements when adding the GDash engine to R'n'D, and I nearly succeeded! But then, only a short time before the final release, I decided not to do it that way. Why?

There were several subtle reasons which finally make the current implementation the better decision. First of all, converting between game elements is trivial, so changing from "bd_diamond" (R'n'D engine) to "bdx_diamond" (EM engine) and vice versa when switching game engines in the level editor is no big deal.

But have a look at the existing graphics definitions for the amoeba. Or, even worse, the BD style explosion -- it has a "linear" (non looping) animation of a fixed length (in animation frames) and time (in video frames), just as all other animations do. But the explosions in the R'n'D and BD engine have a very different duration! So this does not work with one single animation definition (or would require dirty workarounds that would be totally confusing when re-defining custom artwork).

Then, look at the "config" tab in the level editor for "bd_diamond" and "bdx_diamond" -- they have very different, game engine specific configuration options! I could work around this by showing different element options for the "same" game element depending on the currently selected game engine. But this would not improve readability or maintainability of the corresponding code for the level editor. (And yes, the same problem currently exists for other engines: Select the "EM engine" and look at the player's config options, which are not used at all in the EM engine. This has to be cleaned up one day, and I did now want to make things worse with a new engine.)

So I finally decided to use a whole range of new game elements exclusively used by the new BD engine. (While still keeping the "bd_" prefix for all those new GDash level sets, which I thought about also changing to "bdx_", as there are old level sets "bd_boulderdash_2" and "bd_boulderdash_16" that are using the R'n'D engine, while there are cave sets with similar names that are part of the GDash cave collection -- but I managed to change those names to prevent collisions.)

It would be much better from my POV, to have a palette that could so snazzy things such as:

- Allow filtering by showing all elements that work in a particular engine [but not force use of only them; that would be more restrictive than now]

- Allow filtering by typing a text string, so could type 'fire' and get everything starting with that, and maybe could type '*fly' and get things containing 'fly' but with text before it, or something.

- And/or, have a dropdown of categories so could pick all walls, all growing things, all monsters, all falling things... of course the job of categorising and grouping elements could turn into a job that never ends! I think though the ability to refer to element types by kinds of similarity is an area that could be used to make RnD, or at least its editor, much more powerful.

Yes, as already written above, something like that as an alternative would indeed be a nice thing!

But yes, there would be many possibilities how to exactly categorize all game elements in the level editor...

My mistake in my previous post: I checked the palette and, according to how it is structured, yamyams were introduced in EM - non-directional - and directional yamyams were introduced in EMC.

When we're at it, here's how they were introduced exactly:

- the EM engine had only yam yams that start moving up
- the EMC engine had four types of yam yams, starting in one of four directions
- the RND engine has an additional yam yam that starts in random directions

All five types of yam yams can be distinguished in the level editor by which direction they are looking to.

Now, regardless of whether this is true, historically speaking, I just don't think that distinction is of much use in 2025, or to recent arrivals to RnD. In other words I think it will become less and less help as the years go by, and more of a drag.

Unfortunatelyy, many of those "historical things" are a drag, that's right.

It is fantastic having access to elements from multiple games, and of course their engines - but it sure does create complexity, and I'm guessing, place some kind of 'dead hand' over future decisions, that would not apply to a game that 'did its own thing' and developed/enhanced a single engine.

Definitely true!

Thanks for the information, it's good to learn more.

Something I just noticed: DC2 has 2 landmines, 'land mine' and 'land mine (DC style)'. Does this mean that the latter comes from DC1 and the former from DC2? Or that the latter comes from DC2 and/or 1 and the former is an RnD-only alternative?

Anyway, asking more about some of what Holger said:

Unfortunately, the "main" R'n'D engine does not suppport everything anymore, as I did not want to implement those various new game elements (like cows) or techniques (like optional diagonal movement for the player) from the GDash engine to the R'n'D game engine anymore (which is really complex and buggy enough in its current state). (Not to speak of all those Mirror Magic game element, which do not belong to the whole "R'n'D game genre" anyway.)

Maybe the RnD engine never did support 'everything'?

For example, without going through all versions of it to prove my statement, I assume it never implemented EM horizontal wraparound.

And, when playing the original BD levels in it, I was always struck by how different the bonus level with the big block of fireflies behaved, from in BD (at least the C64 version). i.e. instead of a fearsome big 'blob' they broke up and moved individually.

Also I bet that some of the Supaplex configurable aspects have no equivalent in the RnD engine, hence, the RnD engine never fully implemented Supaplex, but rather an approximation of it.

Mirror Magic engine, well I used to think it would be great to fold it within the RnD engine, and somehow have a combination of McDuffin and lasers and elves and all the other elements running around (after all PacMen are already in both), but that seems well impossible.

I used to think that the RnD engine should be a superset of the other engines, but I no longer think so. I would like to see/help it develop further in its own direction, and leave the EM, Supaplex and Boulder Dash engines for the purists.

It is special because no other engine offers such a multitude of possibilities, thanks to :

256 CEs, with Ref Els to help

32 GEs

novel elements, non-CE or GE:
- mole, pig, penguin, dragon, satellite, pacman, dark yam yam
- conway's game of life and (especially) biomaze
- speed pill, time orb, lamp, black orb bomb, dynabombs
- doors that don't need space on the other side of them in order to be able to go through them (with key)

text elements (first set of which are also found in EM engine)

Also could include all the elements from DC2 and DX Boulderdash which as far as I know are implemented in the RnD engine, and no other.

My fear is that the RnD engine will have fewer and fewer users over time, and thus fewer and fewer reasons to update it.

So, I hope I'm not being presumptuous, but I have got a draft list of ideas to enhance it with some killer - or at least notable - features. I have already written in another post about the idea of adding 'true diagonal movement' * to the RnD engine, as well as 'diagonal snapping', the latter of which would be a point of difference for the RnD engine, vs the BD engine.

* I think that true diagonal movement already exists in the RnD engine, inherited from EMC; that is, in the movement of the android element. Obviously this is quite different from true diagonal movement for the player.

Nevertheless, I did think about this idea since many years (and it would be quite easy to implement): Offer (via setup) an alternative set of element palette sections in the level editor, like "walls", "gems", "monsters" and so on (somehow similar to how it was done in old versions of "Diamond Caves"; not sure if it still looks that way).

Yes please! Anything, no matter how big or small, would be welcome. Additional ways to sort would be great, and so would be some way of filtering, or finding within the palette. Being able to sort A-Z by element token or by element description would be fantastic.

p.s. Would you agree with this statement? - The palette both sits above the game engines, and is affected by them.

"Is affected by the game engines"

- If I switch from RND to EM or BD, the available sections reduce, or change completely.

"Sits above the game engines"

- If I build a list of elements in the config file for the MY section of the palette, this is unaffected by changes of game engine, and I can add whatever element I like, wherever it comes from. Of course adding to the level is one thing, and element behaviour when the level is played is another - most elements from other engines behave like normal wall, and we are lucky if their graphics display properly.

In fact, what I wrote above really applies to the level editor, rather than the palette; you can get any kind of element into a level by all sorts of means, eg copying from another level, or from the forum, or by the Enter Text Elements feature, and no checking is done for compatibility with the selected game engine.

I wouldn't like to see this change; I guess I'm writing this to say that I'm very happy with the flexibility that the level editor currently adds, and I would hate to see future enhancements take away from this.

regards

John

Holger wrote: ↑Fri Jan 09, 2026 5:22 pm

Cyberjack wrote: ↑Sat Dec 27, 2025 5:19 pm In some Emerald Mine levels, the object "Dead Amoeba" appears. However, this object is not available in the editor menu. While you can set the "Dropping Amoeba" speed to 0, which has the same effect, this limits you to using only one type of Amoeba per level. I don't know if this is a bug or intentional. It occurs, for example, in Emerald Mine 1 Kingsoft level 27.

This is definitively a bug! All game elements supported by the native Emerald Mine game engine should be available from the "EM" section of the "element palette" menu in the level editor!

Thanks a lot for reporting this! I hope I will be able to fix this soon.

I had a closer look at this issue, and while it is still a bug, it's different from what I thought at first.

First of all: The original Emerald Mine (and what you get when using the native EM engine in R'n'D) only has one single type of amoeba. Whether it grows or not is simply determined by the "amoeba growth speed" as specified in the level editor. That is, if you set it to "0", the amoeba does not grow, effectively rendering it to a "dead amoeba" (which is a different game element in the R'n'D engine that can be used next to a growing amoeba -- but this only works when using the R'n'D game engine).

What makes things confusing is that when you view a native EM level in the level editor, the native EM amoeba is converted to "dead amoeba" if amoeba growth speed is set to "0" in that level, and "dropping amoeba (EM style)" otherwise. When playing, it is converted back to the (unique) EM amoeba (with whatever growth speed was configured). This is bad.

So I have fixed this now, using only the "dropping amoeba (EM style)" in the level editor for native EM levels. (This does not affect playing those levels.)

So, not offering the "dead amoeba" game element in the level editor when editing native EM levels was indeed correct (although confusing in the current version of the game, which will be fixed in the next version).

Thank you Holger for the explanation and for fixing this bug.
I have another question about Amoeba. What is the "Content" of Amoeba? When does it appear?

Pretty sure it's just a general setting assigned for every amoeba type besides amoeba drop and amoeba tiles from MM.

TheOnyxGuy wrote: ↑Sun Feb 08, 2026 5:39 pm Pretty sure it's just a general setting assigned for every amoeba type besides amoeba drop and amoeba tiles from MM.

Yes, but it is in fact another bug here. Both "normal amoeba" and "dropping amoeba (EM style)" have configurable content in the level editor, but don't use it in the game engine.

I have fixed this, too.

There are more things to be fixed here: All game elements that can be used by more than one game engine should only show those properties which are really supported by the selected engine. This mainly affects the EM/EMC style game elements, which have a lot of properties which only have a meaning in the R'n'D engine, but which are still shown when the EM engine is selected, despite not being supported here at all. (Fixing this requires more flexible gadget positions -- which are more or less fixed at their Y position now -- to prevent empty space over or between such property gadgets.)