First pre-release of Rocks'n'Diamonds 4.4.0.0 available!

[Holger]

The first pre-release of the upcoming new major release version 4.4.0.0 is available for testing now!

This new version will finally contain what was planned decades ago: A native game engine that is compatible with Boulder Dash, the classic game that started it all! This game engine will make it possible to play all those thousands of BD games created since the Atari and C64 era, up to the present day! The new game engine is based on the famous BD clone GDash by Czirkos Zoltan, which most probably has the best freely available BD compatible game engine.

For more details (and how to play converted level sets for testing the new game engine), please check out the complete annoucement in the Boulder Dash Forum!

The pre-release version is also available from the download page!
Or play in your web browser now!

[filbo]

> please check out the complete annoucement in the Boulder Dash Forum

This could be a link, maybe? I have no idea where this is supposed to be!

[Holger]

Thanks, filbo! I messed up adding the links like on the news entry on the R'n'D web site, just doing a dumb copy+paste!

Links added now, as it should be!

[ncrecc]

S as the default bind for the "slow playing speed" key is a bit inconvenient; i use WASD for moving and was confused why i couldn't move down. maybe change the default binds for "slow playing speed" and "fast playing speed" to - and +? (+ is on the same key as = on american keyboards)

(let me know if there's somewhere else i should post about pre-release thoughts)

[Holger]

S as the default bind for the "slow playing speed" key is a bit inconvenient; i use WASD for moving and was confused why i couldn't move down.

Oh well, that was indeed what I suspected when I added it (as a complement to the "f" for "fast speed while key is pressed" as used in GDash), as WASD is such a common alternative cursor key mapping. But I didn't expect to hear that complaint that fast.

So I see that I should change this to something else. But would the "-" and "+" keys really be a good choice? I'm not sure how "+" exactly works on US keyboards during the game, as it is created by pressing Shift-=, and during the game only raw keys are recognized (but no combination with modifiers, which are used as snap and drop keys etc.).

I also thought about "f" and "c" for "fast" and "slow" (maybe to be memorized as "calm" ), as they are close together and should not overlap with common keys like WASD (and people used to GDash can keep their muscle memory ).

(let me know if there's somewhere else i should post about pre-release thoughts)

I think it's fine writing/discussing here! Especially as it's still a pre-release version.

[ncrecc]

Oh well, that was indeed what I suspected when I added it (as a complement to the "f" for "fast speed while key is pressed" as used in GDash), as WASD is such a common alternative cursor key mapping. But I didn't expect to hear that complaint that fast.

i'm now realizing it might have been more tactful to open with my amazement at how many peculiar new game mechanics have been just out of my sight all along, rather than "uh, cool, but it doesn't work with wasd!"

So I see that I should change this to something else. But would the "-" and "+" keys really be a good choice? I'm not sure how "+" exactly works on US keyboards during the game, as it is created by pressing Shift-=, and during the game only raw keys are recognized (but no combination with modifiers, which are used as snap and drop keys etc.).

by "+" i indeed meant "="; "-" and "="/"+" are right next to each other on US layouts, and i there is a precedent on some software for pressing - to decrement a value and pressing = to increment a value (without needing to hold shift) - e.g. paint.net lets you zoom out with ctrl -, and lets you zoom in with ctrl =. but i can see how this probably isn't consistent internationally.

"c" and "f" definitely seem more consistent internationally, though on US layouts it's a bit awkward since C is right next to F but on the bottom row. "s" and "f" is a lot nicer aside from its unfortunate conflict with WASD... which, hey, might only be a problem for me. if WASD is a common scheme among other RnD players, though, maybe use "x" and "v" for slow/fast (1 row below "s" and "f" on US layout). no mnemonic for that unfortunately.

also: the Boulderdash levelset in Classic Original Games could possibly be changed to use this BD engine, like how the Emerald Mine levelset uses the EM engeine, amd the Supaplex engine uses the Supaplex engine

[Holger]

i'm now realizing it might have been more tactful to open with my amazement [...]

Not needed, I'm more interested in how I can improve things.

by "+" i indeed meant "="; "-" and "="/"+" are right next to each other on US layouts

Yes, I already suspected this (and R'n'D already supports "Ctrl-=" which would be "Ctrl-+" on other keyboard layouts, for window scaling in this case), but during game play only the configured keys are used, so tweaks like "=" for "+" do not work that well (and it is on a different physical key on a German keyboard, for example).

if WASD is a common scheme among other RnD players

That's the question here. Just did some googling on this, and apparently it's some sort of "industry standard" at least for FPS games (where you use the mouse with the right hand and WASD keys with the left). As there is no mouse use in R'n'D, I think cursor keys (plus snap/drop keys on Ctrl keys or something) is mostly used -- unless you are used to WASD, that is.

So maybe I will indeed change it to "f" and "c" for now (to keep it away from WASD) and let the user configure it if something else is preferred.

also: the Boulderdash levelset in Classic Original Games could possibly be changed to use this BD engine, like how the Emerald Mine levelset uses the EM engeine, amd the Supaplex engine uses the Supaplex engine

Good point (and indeed one I also already thought about). I haven't changed it yet because all levels in the "classic" level set (distributed with R'n'D) already have a lot of solution tapes on the high score server. So maybe I should just add a new BD set with a slightly different name that uses the new, native BD engine. (Well, to be honest, I have already tested a number of levels from that original level set with the native BD engine and the R'n'D engine, and at least for me, using the R'n'D engine just feels so much better when playing (due to the asynchronous nature of the R'n'D engine compared to the synchronous nature of the BD engine) that I really hesitate to replace that set with one that, well, does not play better than before. For all those BD classics it's fine, of course, but for R'n'D it's just no improvement. Still thinking about a good solution here.)

[ncrecc]

if smooth element movement is turned on, walking into a pot looks like this:

pot.gif (8.34 KiB) Viewed 843 times

the pot appears over rockford while he's still walking to the space where it was. it would be nice if, instead, the pot in its original position remained visible until rockford finished walking to it, and rockford didn't switch to his "stirring" animation until he's finished walking onto the pot.

also, it would be nice if the "gravity switch change delay" option for gravity switches could go down to 0 (instantly activate).

[ncrecc]

in the BD engine, quick-loading tapes with F2 doesn't seem to work; it always just takes you to the intro of the level and pauses.

[ncrecc]

something interesting: if i make a new level in the BD engine with the default settings (200ms game cycle delay, PAL timing off), then the game runs a little bit slower than it would in the EM or RND engines. but if i set the game cycle delay to 166ms (1/6th of a second instead of 1/5th of a second), then it runs at the correct speed. i think this might have to do with me using a 60hz monitor.

this hunch might be wrong, though. the game also feels fine at 180ms game cycle delay, which is what GDash uses for its levels by default. i'd recommend setting the default to 180ms, down from 200ms.

[ncrecc]

"use player pushing graphics", "use player up/down graphics", and "mute double falling sounds" options are long enough that they cut into the "yes" nearby (watch when they are highlighted):

gameenginesettings.gif (425.09 KiB) Viewed 829 times

[ncrecc]

explodable steel walls and diggable steel walls show as the ! character ingame. explodable steel walls also show as ! in the editor.

walls.gif (2.52 MiB) Viewed 827 times

(in this gif, you'll also notice another bug where sometimes the intro animation cuts off very early. i don't know what makes that happen)

the same issue happens with all three types of expanding steel wall

[ncrecc]

in GDash, loose sand and sand balls are given the same coloration as Sand 2. RnD's graphics colors Sand 2 green, but has sand balls and loose sand colored brown like normal sand. ideally these should be consistent so the aesthetic of GDash levels isn't broken as much when displayed in the RnD graphics.

gdash_sand.png (1.52 KiB) Viewed 818 times

rnd_sand.png (3.16 KiB) Viewed 818 times

[ncrecc]

in the BD engine, the player moves faster than the camera and can outpace it. this is true regardless of whether smooth element movement or scroll delay are enabled.

outpace2.gif (1.01 MiB) Viewed 799 times

dunno if this is also a thing in GDash. if it is, it's probably less noticeable there since you can't turn on smooth movement.

[ncrecc]

BD nuts, BD walls-with-diamonds, and trapped diamonds should count for "automatically count gems needed" (since non-BD nuts and walls-with-BD-style-diamond already do)