"Dead Amoeba" is missing from the editor (EM)
Moderators: Flumminator, Zomis
"Dead Amoeba" is missing from the editor (EM)
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.
Re: "Dead Amoeba" is missing from the editor (EM)
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.
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.
Re: "Dead Amoeba" is missing from the editor (EM)
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 :)
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 :)
Re: "Dead Amoeba" is missing from the editor (EM)
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
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
Re: "Dead Amoeba" is missing from the editor (EM)
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
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
Re: "Dead Amoeba" is missing from the editor (EM)
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).
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).
Re: "Dead Amoeba" is missing from the editor (EM)
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!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.
Thanks a lot for reporting this! I hope I will be able to fix this soon.
Re: "Dead Amoeba" is missing from the editor (EM)
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.)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.
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.)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.
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).So, maybe the editor could be switchable between these modes? One of these years when Holger is feeling bored
Re: "Dead Amoeba" is missing from the editor (EM)
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).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?
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).
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.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.
That's a very good question indeed, which I can answer here.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?
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.)
Yes, as already written above, something like that as an alternative would indeed be a nice thing!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.
But yes, there would be many possibilities how to exactly categorize all game elements in the level editor...
Re: "Dead Amoeba" is missing from the editor (EM)
When we're at it, here's how they were introduced exactly: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.
- 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.
Unfortunatelyy, many of those "historical things" are a drag, that's right.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.
Definitely true!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.
Re: "Dead Amoeba" is missing from the editor (EM)
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:
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.
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
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:
Maybe the RnD engine never did support 'everything'?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.)
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.
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.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).
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