Rocks'n'Diamonds with GDash game engine

[artsoft]

Summary:

Rocks'n'Diamonds has integrated the game engine of GDash now! Check it out for your preferred platform:

• Linux
• Windows (64-bit installer; more options below)
• Mac
• Android

Get all GDash cave sets ready to play with R'n'D (66653 levels in 1973 level sets):

• GDash levels for R'n'D

Just drag and drop the downloaded zip file into the Rocks'n'Diamonds window (main menu) and restart the game. Now you can select all GDash cave sets from the "Levelset" menu! Have fun!

Detailed:

Finally! 40 years after the first release of The Game That Started It All, nearly 30 years after the first release of my own little clone of this game, around 20 years after I first planned to add native BD support to it, and 10 years after something like a vague announcement here in this forum, it is finally becoming a reality: Rocks'n'Diamonds will get a native BD game engine!

Of course, it is based on the game engine of Czirkos Zoltan's famous GDash, which most probably is the best freely available BD compatible game engine.

The main focus of this project (that is, Rocks'n'Diamonds in general, and its new, native BD engine in particular) is to preserve as much of the history of this game genre, as authentic as possible, to make it as easily accessible, usable and playable as possible for today's players, and to make everything as openly available to the public as possible.

This is to announce the final release version for Linux, Windows, Mac, Android and web browsers. Choose your preferred platform to download the game for your system:

• Linux
• Windows: 64-bit installer / 64-bit plain zip / 32-bit installer / 32-bit plain zip
• Mac
• Android
• web browser

The source code is also available; check it out from one of the following Git repositories:

• main repository (always has the latest public code)
• GitHub mirror (updated every now and then)

To build the game from source code, just check out the branch "master-next-major-release" and type "make run" to compile and run the code from the shell. All you need in addition to the game's source coce is the usual tool chain to build C programs (gcc or clang or mingw) and the SDL2 libraries (SDL2, SDL2_image, SDL2_mixer (with MOD/MP3 support) and SDL2_net). No other libraries or dependencies required.

The R'n'D source code repository itself does not contain any native BD level sets, but you can easily convert and play the cave sets included in the GDash repository. To make things as easy as possible, there is a fork of the latest maintained GDash version (gdash-export-CrLi) available at GitHub which contains two small shell scripts to convert the GDash cave sets to R'n'D level sets (mostly just adding some config files and some additional artwork, leaving the GDash cave set files itself untouched).

Just check out the branch "rocksndiamonds" from the Git repository gdash-export-rnd and type "make convert-all" in the sub-directory "rocksndiamonds". You can then directly use the contents of the newly created sub-directory "levels", or type "make package-zip" to create a zip file ready to be dropped into the R'n'D window to add the level sets. To make things easy, the zip package is also directly available for download from the "Releases" section of the above repository (on the right side of the repository's web page, or see the direct download link above).

The new BD game engine is based on the old C code version of GDash, but it also contains all the latest fixes and additions from the above repository (like additional player animations for pushing and moving up and down). The engine was successfully tested against all replays included in the BDCFF cave sets of earlier game versions (before they were removed for whatever reason). However, it does not contain OpenGL support, so there are no particle effects and no "old TV screen" effects available.

There are also some fixes and additions compared to the original GDash game, like the following:

• fixed teleporters (did only work when entering from right or bottom, but not from top or left)
• fixed some game element graphics (like stone graphics, which did not look like on the C64)
• game artwork (graphics, sounds, music, and menus) highly configurable (as known from R'n'D)
• added cave set specific game artwork (no need to manually select BD3 space graphics, for example)
• setup option to select between old (C64 style) and new (Boulder Rush style) game graphics
• smooth player and game element movement, giving the game a slightly more modern touch
• improved input handling for smooth playing (when pressing a key, the player will always move)

The following fixes and features may not make their way to the upcoming final R'n'D release anymore, but should hopefully be added soon after the release:

• fix "playing game music when uncovering sound still being played" (non-GDash level sets only)
• support for BDCFF tape (replay) export (to play R'n'D tapes also with original GDash game)
• further fixes for the C64 graphics set (only use C64 style "wide" pixels and limited colors)
• optional music set for in-game music (using a selection of chip tunes that fit to the game)

Additionally, there are those various features and functionality already known from R'n'D, like the high score server (with score tapes (replays) playable for each score entry) or the tape recorder. The level editor, however, will only support creating map based levels (caves).

Features like directly downloading level sets from the server, or even saving levels and level sets directly from the level editor to the server (from which especially the web browser version would benefit, as it cannot import or export level set packages) are only planned for some future version, but won't be available with the upcoming major release version. (On the other hand, the backend code for the high score server, the uploaded score tapes and the high score database
content could be made publicly available via Git repositories and nightly dumps or downloads, to prevent the risk of the server suddenly going away for whatever reason. The game itself already supports using different high score servers, but this is currently only used for testing purposes.)

As a side note: Accessing the high score server is always optional; R'n'D is designed to run offline just perfectly. Once the high score server can be accessed again, all scores and tapes recorded while being offline will be uploaded. Of course, you can completely disable using the high score server, if you don't like it. You can access the web interface of the high score server here:

• https://api.artsoft.org/

I am curious what you think about the GDash integration in Rocks'n'Diamonds, and I hope I will be able to release the final version soon, most probably after some more test versions with bug fixes and features still to be added.

Have fun!

[CWS]

Very exciting! Thank you!

GUI is a little bit peculiar for the BD engine/games. And the info screen/game elements does not show the GDash specific elements.
Is it just here or isn't there a sound when you are standing under a boulder and let it fall down by stepping away?

Is it possible to use the sound set from GDash? It would also be great to have an option for scanlines in the graphic settings.
I also think it should be possible to configure the game speed for each engine separately.
Showing the highscore after each cave in the Boulder Dash engine is very disturbing, this should be configurable.

Can you add your transporter fix into the GDash source on GitHub, too?

[LogicDeLuxe]

fixed teleporters (did only work when entering from right or bottom, but not from top or left)

You mean, when you leave the same teleporter you entered, unless the exit side is blocked? That is intentional. Yes, it does not behave that way when entering from the right or bottom, but as a level designer, you can easily force that strategy by placing the target teleporter with no spaces to the left and top.
I could have easily excluded the source teleporter from the target search, but I wanted the logic kept simple like everything in Boulder Dash.
It goes like, from the field on you enter a teleporter, search the entire cave for a teleporter with a space on the opposite side. The first hit may be the same teleporter you entered, but can be blocked intentionally by the player to be excluded.

[artsoft]

GUI is a little bit peculiar for the BD engine/games.

Yes, it probably feels quite unusual when you are used to the GDash GUI. In fact, although fonts are customized to GDash fonts, everything else is pretty plain R'n'D menu look and feel.

However, this can easily be changed -- not by the average user who just wants to play the games, but by anybody who knows how to edit the corresponding "graphicsinfo.conf" config files (and knows how to change things there). In this case, that's me, mainly...

So far, I haven't put much focus on the main menu (or the other menus) other than replacing fonts and background to have it look a bit like GDash. And the main difference to GDash (or the original C64 game) is, of course, the main menu.

While GDash's main screen somehow looks like the C64 main screen -- that is, have about 80 % of the screen covered with the large BD title screen, with only a few lines for showing current cave/level and some hints about navigation -- R'n'D traditionally has a different approach: Make the menu and navigation as easily accessible as possible, regardless of the user using a joystick or gamepad, a keyboard or the mouse. I remember well from the C64 how every new game required first finding out how to start the game, how to select a level, and which joystick port to use, most times starting to press all four function keys, then all other keys, or pressing joystick buttons. Intuitive menus? Not in the 80's...

That said, R'n'D won't try to clone the main screen from GDash (which I think is really not that user-friendly), but attempt to be easily usable for both new and advanced users here.

However, there's a lot of room for changes in the menus, and I will be happy to hear what could/should be changed. (One thing surely being the level preview on the main screen, which, on the one hand, could be seen as a spoiler, but, on the other hand, makes it really nice and easy to quickly select a certain level to play which the user is searching for in a large set. This is something which could also be made configurable in the setup menu, like disabling it completely, or just showing the part of the cave that is visible from the start position etc.)

I'm open to discuss what could or should be changed here!

And the info screen/game elements does not show the GDash specific elements.

That's indeed still missing from the current test version -- I have added it in the initial post unter "things still missing". This will hopefully already be added for the next test version.

Is it just here or isn't there a sound when you are standing under a boulder and let it fall down by stepping away?

You are right, this is disabled by default, but can be enabled in the menu "Setup -> Game Engines -> BD engine".

Maybe I should change the default to the odd original behavior of playing sounds for falling objects not only when they hit the ground (or another object), but also when they start falling (which really should not make a sound at all, but does in BD).

I know that I am not the only one who thinks that this is just plain wrong (others have mentioned this in the German C64 forum, for example), but as this is how the original game sounds like, it should probably be the default setting here.

Is it possible to use the sound set from GDash?

The converted level collection uses exactly the sound set from GDash, so if it's only that "falling sound" thing, changing the setup option mentioned above should do it.

It would also be great to have an option for scanlines in the graphic settings.

Yes, that would indeed be a cool feature! Even though R'n'D does not use OpenGL (which makes such things easy), adding an overlay texture which a darkening alpha channel for every second line could come close to it. (Maybe this is easy to do, so I might do some tests if it works as expected.)

I also think it should be possible to configure the game speed for each engine separately.

This is an interesting point! Recently, I was indeed thinking about which setup options should be available for each engine separately, and which should be valid for all engines. (Like scroll delay or which graphical style -- old or new -- should be used, which should probably also better be "old", that is "C64 style with cave specific colors" for the BD engine, instead of the "new" (Boulder Rush style) graphic set.)

Both variants could result in unexpected behavior (like changing the game speed and wondering why it's back to previous value after selecting another level set using a different game engine, which the user might not care about).

Showing the highscore after each cave in the Boulder Dash engine is very disturbing, this should be configurable.

It is -- just set "Show Scores After Game" to "no".

And yes, I expected this to be one of the first complaints, as the original game simply has a different "flow" here (not playing single levels, but playing cave sets, cave by cave, mostly uninterrupted, unless you have no lives left). This is quite different to, say, Emerald Mine, where single levels are played, followed by the high score table after solving a level.

Even though the GDash engine in R'n'D also has a single-level approach (that is, you cannot get a score for playing more than one level), I understand that those interruptions (asking to save or confirming to save a tape, and showing the high score table after the game) must be disturbing if you are used to a continuous flow of playing more than one level.

Can you add your transporter fix into the GDash source on GitHub, too?

Yes, of course -- the main reason why I haven't added it to the main branch yet (or as pull request to the repository I have forked from) is that I first want to check or discuss if what I have fixed is really a bug or just odd engine behavior which "has to work that way". If the latter should be true, I would add a checkbox for this (and a flag in a potentially exported BDCFF file) to set using the old or new behavior.

More about this in my reply to LogicDeLuxe's post!

And thanks a lot for your comments and suggestions!

[artsoft]

fixed teleporters (did only work when entering from right or bottom, but not from top or left)

You mean, when you leave the same teleporter you entered, unless the exit side is blocked? That is intentional. Yes, it does not behave that way when entering from the right or bottom, but as a level designer, you can easily force that strategy by placing the target teleporter with no spaces to the left and top.
I could have easily excluded the source teleporter from the target search, but I wanted the logic kept simple like everything in Boulder Dash.
It goes like, from the field on you enter a teleporter, search the entire cave for a teleporter with a space on the opposite side. The first hit may be the same teleporter you entered, but can be blocked intentionally by the player to be excluded.

OK. This may make the internal logic in the code a little bit simpler, but makes the behavior in the game, for the player, totally illogical, and totally unexpected.

I'm not really sure if I understand you right regarding blocked fields next to the source or target teleporter, but just imagine the following scenario in a cave: There are two teleporters, and all eight fields around them are empty space (ok, all four fields to the top/left/right/bottom of each teleporter would work the same here).

Now the player enters a teleporter -- any teleporter, at any side: It either works or not, depending on the side from which the player entered it. This really does not make any sense (other than "that's how it works in BD for some strange reason").

(And yes, as a level designer (if you are aware of this engine glitch), you can of course prevent this from happening by intentionally blocking those directions that do not work.)

I know that the BD engine is full of such inconsistencies (caused by the cave scan direction), like approaching enemies from top, left, right or bottom side (which results in the player getting killed either immediately or in the next engine iteration).

But for teleporters, this is Just Wrong[tm].

So I think this should be fixed (and if fixing such odd behavior should really break any existing cave, a flag/checkbox could/should be added to either get the "correct" or "wrong" teleporter behavior).

(BTW, the code for correctly working teleporters is only slightly more complex than the code for the wrong one, and the fact that this would cost a few more opcodes on the original platform should not be a reason to keep such ridiculous bugs in today's implementations.)

[HerzAusGold]

artsoft wrote:
fixed teleporters (did only work when entering from right or bottom, but not from top or left)

LogicDeLuxe wrote:
You mean, when you leave the same teleporter you entered, unless the exit side is blocked? That is intentional. Yes, it does not behave that way when entering from the right or bottom, but as a level designer, you can easily force that strategy by placing the target teleporter with no spaces to the left and top.
I could have easily excluded the source teleporter from the target search, but I wanted the logic kept simple like everything in Boulder Dash.
-> It goes like, from the field on you enter a teleporter, search the entire cave for a teleporter with a space on the opposite side. The first hit may be the same teleporter you entered, but can be blocked intentionally by the player to be excluded.

I think LogicDeLuxe described it like it is implemented at C64. Even when this means: Only two teleporter pairs are possible?
So this is not a

ridiculous bugs in today's implementations.

Don't change this engine behavior. A flag to switch the teleporter behavior should also not implemented.
It should work like on C64.

"that's how it works in BD for some strange reason"

Nobody would play the caves if the engine is not like the original. A flag to switch behavior maybe makes the cave easier playable.
Nobody would play with an engine which can be "modified".

Any example cave where we can test it?

[artsoft]

I think LogicDeLuxe described it like it is implemented at C64.

Yes, that's how I understand it, too.

Even when this means: Only two teleporter pairs are possible?

This is not what this issue is about.

And yes, you can use as many teleporters in a cave as you like, and it will work (always teleporting to the next teleporter in the cave that is found in scan direction, including overwrapping the playfield).

But that's not my point. My point is that teleporters can generally only entered by the player from the right or bottom, but not from the top or left side of the teleporter, and even though this is apparently the way it was implemented on the C64, it seems to be terribly wrong to me.

Don't change this engine behavior. A flag to switch the teleporter behavior should also not implemented.
It should work like on C64.

I do agree here! Existing caves should definitely behave just like they were designed and intended to be played by their authors. And there should be no way to suddenly play these caves with changed behavior, of course.

However, I also do think that this should be fixed for newly created caves, just like it was done for other existing bugs and engine (mis)behaviors that have been changed or fixed in newer versions. And just like it is the case with all these engine changes, there should probably be a flag in the level editor to explicitly select the old, buggy behavior, if somebody wants to use it.

Nobody would play the caves if the engine is not like the original. A flag to switch behavior maybe makes the cave easier playable.
Nobody would play with an engine which can be "modified".

I totally agree here, and something like that was never my intention.

Any example cave where we can test it?

I also would like to know if there are any caves out there that actively make use of this "special teleporter behavior", or that would be broken (or easier) by such a game engine change as described above.

[artsoft]

I have just released the second test version of Rocks'n'Diamonds (version 4.4.0.0-test-2) with the new GDash engine, which contains the following additions and fixes:

• added support for opening level set zip files in Android version
• added UTF-8 support for cave names in BDCFF files
• added setup option for fast BD game start from level editor
• added precedence of game keys over speed/debug keys when playing
• added checking availability of level specific colors in level editor
• added using masked drawing for player on walkable tiles in BD engine
• added snapshot support for BD engine
• added single step support for BD engine
• added checking for help anim/text files in different locations
• improved converting BD game engine elements for R’n’D game engine
• improved smooth movement animation for classic BD scheduling types
• improved smooth movement animation for BD engine (complete rewrite)
• changed defaults for falling element sounds in BD engine
• changed default game cycle delay value for BD engine
• fixed showing level in cave names for BDCFF cave sets without levels
• fixed score time for BD engine
• fixed cave flashing on open outbox for non-black cave background color
• fixed player entering pot when using smooth movement
• fixed graphical bug when snap-pushing with smooth movement in BD engine

I have updated the download links in the first post of this thread accordingly.

I have also added a new version of the GDash level collection to be played with the above version, which contains game element animation and text definitions to show the BD game elements on the info screen (apart from this, the package is unchanged).

The first item in the list above is not BD specific, but worth mentioning if you want to test the game on an Android device. Before, it was really tricky to add a level package on recent Android versions. Now, you can just download the package (zip file) and open it with the R'n'D app when prompted to open the file (or, if you have already downloaded it, open it with "Open with" from the file's context menu in the Android file browser of your choice).

[altermaven]

If you are looking to include GDash levelsets as part of the eventual release, you can go ahead and use mine. Be aware, however, that there are GDash-specific morphs (second amoeba timers, different magic wall outputs in Dig Vol.2), so until these are implemented in stable, you might want to go with including the DangerDash series instead, since they use standard element behaviour.

[neuromancer]

Thanks for making it easy for me to play all these gdash levels without having to mess around with figuring out how to build gdash.

[igormakovsky]

Awesome news, can't wait for the final release of the Rock'n'Diamonds'n'GDash!

I especially like that looks like it is ok to launch fancy new levels like this one
https://youtu.be/IMMuI4s_JDA?si=Wdz1rErmlcA9tD9e

The best thing is the different cave size, borderless rooms where items could fell off the level and appear at the top row, etc.

Amazing project, that arouses me.

[artsoft]

If you are looking to include GDash levelsets as part of the eventual release, you can go ahead and use mine. Be aware, however, that there are GDash-specific morphs (second amoeba timers, different magic wall outputs in Dig Vol.2), so until these are implemented in stable, you might want to go with including the DangerDash series instead, since they use standard element behaviour.

That's very cool -- thank you for this offer, altermaven!

In fact, I do hesitate to change the engine of the included classic BD set from R'n'D to BD engine, because there are already too many scores and solution tapes for this set in its current form on the high score server! But as the new R'n'D release should indeed have some level sets with the new engine included, I will happily accept your offer to add some of your level sets!

Also thanks for pointing out those engine specialities required to play those level sets -- as the new BD engine is based in GDash, it *should* be able to play them, but I will check this before including them (especially as the new engine is based on the old C version of GDash, and there are some fixes and additions to the engine in more recent (C++ based) versions that might not have been ported to the R'n'D code yet).

[artsoft]

Thanks for making it easy for me to play all these gdash levels without having to mess around with figuring out how to build gdash.

You're welcome!

Although it should also be mentioned that the latest versions of the GDash fork by revvv also contain packages ready to run for Linux, Windows and Mac (in the "Releases" section), so you might want to have a look at them, too.

[artsoft]

Awesome news, can't wait for the final release of the Rock'n'Diamonds'n'GDash!

I hope I will be able to release it in summer or autumn this year. It still needs some more testing and polishing, but most things should already work as they should now (with the currently available test-2 version).

I especially like that looks like it is ok to launch fancy new levels like this one
https://youtu.be/IMMuI4s_JDA?si=Wdz1rErmlcA9tD9e

The best thing is the different cave size, borderless rooms where items could fell off the level and appear at the top row, etc.

I've just reconstructed the level as seen in the above video, and the game mechanics seem to work just as the should.

And one more miraculous thing I found inside bd editor:

What are those unused items in boulder dash cave editor, dozens of them. Where do they came from and where can you get levels including them?
I mean, bombs, different enemies, chasing rocks etc.

I've tried putting them inside a level and I suppose plenty of them are still in beta and do not work as it intended. Am I right?

No, luckily you aren't -- all of these game elements are fully supported and work as intended! Just try it out!

And they are not really new, but were just not used in the classic first few BD games (but were invented and used in later clones of the game). You can also find them used in several of the more recent level sets in that large BD level collection linked to in the first post of this thread -- just download the zip file and drag-and-drop it into the R'n'D program window (either into the main screen or level set sub-screen) to install it into R'n'D!

BTW: There are "normal" and "effects" BD style elements available in the level editor (both in GDash and R'n'D), where the second class are "run-time game elements" which could also be placed in a level, but are usually used for game element configuration, like "enemy X should change to element Y when exploding" and so on.

[igormakovsky]

Thanks a lot for the reply and thanks for all the work!

I have encountered appearing of blue "?" under the slime in the Future Dash by Arno Weber, like in the cave 04 or the following intermission, cave 05



Why does it happen?