Miho Dash

[ketmar]

Miho Dash is BD-compatible engine written in Miho Scheme. because i needed something to test my Scheme implementation with, and why not BD? ;-)

it features:

• support for almost all objects from GDash.
• BDCFF loading (of course).
• database with all games from GDash (in exported BDCFF format).
• cave statistics: the program records each cave play attempt, the outcome (died, finished, skipped, etc.), cave score, collected diamonds, and so on.
• automatic engine-independent replay recording: every finished cave run is automatically saved.
• quicksave and quickload: you can save current cave state, and reload it if you did something wrong.
• single-step mode, so you can record "perfect replays". ;-)
• some configurable special effects, like camera shaking on explosions.
• tile recoloring using HSL color scheme, based on cave hash (i.e. each cave always has its own color).
• user can attach personal comments to games and caves. it is also possible to rename games and caves while keeping the original BDCFF intact.
• all caves are hashsummed (map only, map and gameplay options), so it is easy to find duplicate caves. it was done because i wanted to know how many different caves are there. ;-)
• proper handling of "left+up" and such keys: Rockford will go in zigzag pattern instead of preferring the single direction.

planned features:

• cave editor which will record editing commands (a-la BD1/BD2 engines).

the novel feature of Miho Dash is engine-independent replays: the engine records all game board changes and important events (sound played, something exploded, etc.). it is possible to replay demos without the full BD engine implementation: you only need to know how to draw various objects. this is much more flexible than simple movement recording (but a lot bigger too — one replay takes about 30-100 kb). documentation on the replay format will be included with the released game source code.

the game is not yet publicly released, but i am working on it. ;-)

and now some screenshots…

[ketmar]

and slightly better-looking game list. i should have done listbox widged differently from the beginning. so i rewrote it. ;-)

[artsoft]

Wow, that's an impressive list of features!

Did you do the impementation from scratch, or did you use the GDash source code as a reference for the game engine (which is a really mature BD engine that covers a lot of edge cases just like the old original games did)?

Regarding replays, this sounds like you could also easily play replays backwards, which would be a nice feature (not for really watching replays playing backwards, but for freely navigating back and forth in a replay)!

user can attach personal comments to games and caves.

Interesting feature that reminds me of the cave messages supported in the Krissz Boulder Dash web site! Do you only store these personal comments locally, or are they stored on a central server, so that others can also see those comments (which would be a cool feature)?

proper handling of "left+up" and such keys: Rockford will go in zigzag pattern instead of preferring the single direction.

That's something which I added to the Emerald Mine engine in (my own BD clone) Rocks'n'Diamonds, but not (yet) to the Supaplex and BD engine, because both corresponding, already existing level collections already came with replays that would break when implementing this feature for already existing replays. But I really like this (instead of simply giving one of two direction keys pressed at the same time priority over the other key), and would also (at least optionally) add this to the BD engine, too.

I'm curious to see a first playable version of your new game!

BTW: Will your game run on many platforms, or only on a certain one?

[ketmar]

Wow, that's an impressive list of features! :shock:

thank you! ;-)

Did you do the impementation from scratch, or did you use the GDash source code as a reference for the game engine (which is a really mature BD engine that covers a lot of edge cases just like the old original games did)?

yes, i used GDash code to find out how things should work. as the idea was a "BD Clone", not "BD-inspired game", this was the only way to be sure that it is The Real BD. ;-) Zoltan did great work reversing BD and various clones, and i am really happy that we have GDash now.

i even used object names from GDash (basically, copy-pasted O_xxx enum).

Regarding replays, this sounds like you could also easily play replays backwards, which would be a nice feature (not for really watching replays playing backwards, but for freely navigating back and forth in a replay)! :)

the player would still need to "unpack" the replay. replays are basically lists of events happened during the game frame (so it's something like "delta snapshot"), so they are not well-suited for rewinding backwards. but such unpacking is very cheap, and the player can create "key frames" for faster rewind. i deliberately kept replay format simple (it's just a stream of 16-bit integers: command and its arguments, command+arg, command+arg…). 50-150 kb per replay is not that much these days, and simple int stream guarantees that the player (and various replay analysis tools) could be written in any language, without requiring external libs (like zlib, or some binary serialisation libraries).

i will prolly implement vcr-like controls for replay mode later. (when i force myself to stop playing; because for now it is: "oh, i just HAVE to… test one more cave, what if it is broken?!" ;-)

Interesting feature that reminds me of the cave messages supported in the Krissz Boulder Dash web site! Do you only store these personal comments locally, or are they stored on a central server, so that others can also see those comments (which would be a cool feature)?

i am not a fan of online things. ;-) but it is not that hard to implement "comment sharing". i collected all games supplied with GDash into one SQLite database (that's where the game list on the screenshots came from), so each game there has an unique id. user comments are stored in another SQLite db, keyed by game id. as game db is supplied (will be supplied ;-) with the game, game ids will be the same for all users, so comments could be shared too.

the engine still can load standalone BDCFF files, though, so i will prolly need a way to extend the database later. maybe i will use BDCFF hashes instead of simple integer ids as unique game ids. i haven't decided on this yet.

proper handling of "left+up" and such keys: Rockford will go in zigzag pattern instead of preferring the single direction.

That's something which I added to the Emerald Mine engine in (my own BD clone) Rocks'n'Diamonds

and this is exactly where i've seen this feature for the first time! do you know that you ruined GDash for me?! i couldn't play GDash anymore without this feature. ;-)

some people might argue that this is "cheating", but i don't agree with them.

and while we are here: thank you for RnD! sadly, i couldn't play it much due to two things: "async" nature and graphics. don't get me wrong, please: this is not your (or RnD) fault, it's my own brain. somwhere deep in my brain there is the hardwired thing: "anything that is not based on tile movement and doesn't look close enough to the original BD is a cheap replica. do not want!" of course, i know that RnD is not that (and it is based on EM, not on BD), but… i never played the original EM; i played DOS Supaplex, and was never hooked by it too, due to "smooth movement".

but i still playing RnD from time to time, because it is such a fun game!

I'm curious to see a first playable version of your new game! :D

thank you. i just need to find the way to make it easy for people to try. it was started as simple Miho Scheme test, and Miho Scheme itself is still in heavy development (i found several bugs in the compiler thanks to Miho Dash), that's why i didn't made the game downloadable. the code is GPL, of course (because it is heavily inspired by GDash).

BTW: Will your game run on many platforms, or only on a certain one?

only x86 GNU/Linux for now. maybe i'll be able to make 32-bit windows build of Miho Scheme, though, and upload the game in that form. Miho Scheme doesn't support 64-bit systems, and i have no plans to change that. it's C for core Scheme engine, SDL2 for gfx, SDL2_Mixer for sound, and SDL2_Image for loading png graphics, so it's mostly portable. i simply don't want to make it work on 64-bit systems.

[artsoft]

i am not a fan of online things.

Indeed I have a similar approach with R'n'D, although it does support some online functionality with the high scores. I will always make sure that R'n'D can be played offline without any problems (but without the additional online functionality then, of course). For example, if you play offline for some time, all scores during that time will be uploaded to the high score server if you are online again later. Maybe I will add some more online functionalities, but the focus will always be to be fully playable even without internet connection.

and this is exactly where i've seen this feature for the first time! do you know that you ruined GDash for me?! i couldn't play GDash anymore without this feature.

I plan to add it to the BD engine (and also the Supaplax engine) in the future, as an optional feature. I just have to take care that tapes recorded with diagonal movement enabled are treated differently than those with this feature disabled. To make things more complicated, the BD engine has its own, native (cave specific and optional) "diagonal movement" (which is true diagonal, not "zig-zag-style" movement)...

and was never hooked by it too, due to "smooth movement".

Just to quickly mention here that "smooth movement" for the BD engine in R'n'D is totally optional and can easily be disabled with a single switch in the setup->engines menu. But yes, it is enabled by default, as all other game engines in R'n'D natively use smooth movement, too.

And maybe it's also worth mentioning that the BD engine internally is fully synchronouos and tile-bases, just like GDash. The optional "smooth movement" is just some sort of graphical sugar to use if you like it better than the original jump-movement.

it was started as simple Miho Scheme test, and Miho Scheme itself is still in heavy development

OK, that explains that I wasn't able to find anything when looking for "Miho Scheme" in Google!

only x86 GNU/Linux for now

That sounds good! And maybe cross-compiling it to Mac and/or Windows is easier than expected...

[ketmar]

I plan to add it to the BD engine (and also the Supaplax engine) in the future, as an optional feature. I just have to take care that tapes recorded with diagonal movement enabled are treated differently than those with this feature disabled.

i haven't looked at internal RnD tape format, but this sounds like a perfect fit for "options chunk". new tapes will not play in older game versions, of course.

or, write only the buttons which actually did something. this way zigzag will be converted to corresponding keypresses, and even new tapes will be compatible. i assume that currently RnD simply records all pressed buttons, so the new logic will prolly require some work. but it solves the problem without breaking the compatibility.

To make things more complicated, the BD engine has its own, native (cave specific and optional) "diagonal movement" (which is true diagonal, not "zig-zag-style" movement)... :D

yeah. there are not much caves with this option turned on, though. and my idea above solves this too: because both buttons "did something", both will be written.

Just to quickly mention here that "smooth movement" for the BD engine in R'n'D is totally optional and can easily be disabled with a single switch in the setup->engines menu. :) But yes, it is enabled by default, as all other game engines in R'n'D natively use smooth movement, too.

And maybe it's also worth mentioning that the BD engine internally is fully synchronouos and tile-bases, just like GDash. The optional "smooth movement" is just some sort of graphical sugar to use if you like it better than the original jump-movement.

yeah, i know it, and i immediately turned smooth movement off for BD. ;-)

another problem i still cannot solve is keyboard handling. there's quite a big delay between BD game frames. i tried to implement "sticky keys" a-la EM, but was not satisfied. for now i switched back to "hold the key until the game frame advances". i'm more-or-less used to it, but it doesn't feel responsive.

it was started as simple Miho Scheme test, and Miho Scheme itself is still in heavy development

OK, that explains that I wasn't able to find anything when looking for "Miho Scheme" in Google! :D

The Very Secret Engine, yeah. ;-) my own.

That sounds good! And maybe cross-compiling it to Mac and/or Windows is easier than expected... :)

i think that mac is out of question: Miho code assumes 32-bit pointers. a lot of code casts pointers to unsigned ints and back, expects struct members to be at the fixed byte offsets, and so on. and as far as i know, macos is only 64-bit. 32-bit windows builds should be possible, though.

[artsoft]

or, write only the buttons which actually did something. this way zigzag will be converted to corresponding keypresses, and even new tapes will be compatible

That would indeed be a solution that would ensure that new tapes work on old game versions.

However, the problem with this approach is that it cannot easily be done in a generic way, which is currently "dump all pressed keys to the tape file, regardless of game engine". That is, before being able to decide which keys should be saved for the tape (replay) file, the game has to know what the game engine did with that key input. If you have keys pressed for both horizontal and vertical directions while being surrounded by empty space or sand (dirt), this will result in zig-zag style movement. But if the player is next to a wall and the pressed keys result in moving up or down next to that wall (with one of the keys pointing towards the wall), generic zig-zag (throwing away one of both directions in an alternating way) would result in moving, stopping, moving, stopping, etc. So zig-zag movement depends on what the engine does with the key input.

Your suggested solution would still work if key input would be adjusted by the game engine, and only written to the tape afterwards.

But then, I'm more concerned about old stuff still working correctly with newer game versions, but not that much about new stuff working correctly with older versions (which in many cases does not work anyway), even though the IFF style (chunk based) file format I use for most R'n'D files principally supports such an approach very well.

another problem i still cannot solve is keyboard handling. there's quite a big delay between BD game frames. i tried to implement "sticky keys" a-la EM, but was not satisfied. for now i switched back to "hold the key until the game frame advances". i'm more-or-less used to it, but it doesn't feel responsive.

Yeah, that's a general problem with the BD (and also the EM) game engine: It's synchronous, which means that it does just nothing for quite a "long" time, regardless of any keys being pressed or not (while the R'n'D and SP engines immediately react to user input). So this means that the player may move immediately when a key is pressed, or may wait for nearly a full game engine cycle (or "frame"). This really feels unresponsive, unfortunately (although it makes the game engine logic _way_ easier to implement). Indeed that's why I added the stickyness functionality also for the BD engine: Just hit a key (quickly pressing and releasing it), then you can wait for the player to finally make its move, while in the original engine just nothing may happen far too often (and sometimes two steps are done if you keep the key pressed for around one game cycle if you are unlucky).

Maybe I should make this configurable, as there may indeed be players who prefer the original behavior here.

i think that mac is out of question: Miho code assumes 32-bit pointers. a lot of code casts pointers to unsigned ints and back, expects struct members to be at the fixed byte offsets, and so on. and as far as i know, macos is only 64-bit. 32-bit windows builds should be possible, though.

Did not think of that, but yes, you're right about Mac. Windows 32-bit should be fine though (and I also still ship 32-bit builds of R'n'D for Windows).

[ketmar]

But then, I'm more concerned about old stuff still working correctly with newer game versions, but not that much about new stuff working correctly with older versions (which in many cases does not work anyway), even though the IFF style (chunk based) file format I use for most R'n'D files principally supports such an approach very well.

yeah, i was so facsinated by my idea of backward compatibility that completely forgot about forward compatibility. ;-) but i think that this can be solved by "options chunk". so if there is no "options chunk", then the engine should deactivate "zigzag mode". and when writing the tape, it should write only "used" buttons. this way the tapes would be compatible in both ways (if the old versions are written in a way that they ignore unknown chunks).

while in the original engine just nothing may happen far too often (and sometimes two steps are done if you keep the key pressed for around one game cycle if you are unlucky).

that was the problem i was fighting with, and i haven't found any solution i'd like. yet i found that (at least for me) "non-sticky" mode feels less responsive, but more predictable. this is prolly the case where smooth movement feels (and works) better. ;-)

after all, most BD caves have 140-180 msecs delay, which is well within human reaction time and "rhytm feel".

[altermaven]

I'm interested in seeing how this project pans out. Looking forward to seeing specific implementations of what the old engines did (like BD1/BD2's scanning mechanisms). Looking good so far.

[ketmar]

thank you!

the scanning is very simple: i have two arrays. ;-) first array holds playing board, and second array holds timestamps for each cell. active object is the one for which the corresponding timestamp is less than the current one. basically, `if {field-time[idx] <= game:tick} (process-object idx)`. i am also always scanning the whole board, wrapping is always on in both directions, and always "perfect". C64 BD1 magic wall bug is not emulated.

p.s.: your games on UI screenshot is pure coincidence! ;-)

[ketmar]

Miho Dash tech preview (win32):
https://files.catbox.moe/uzvkzp.7z

this is far from the final version, but it should be playable. unpack, and run "run-bdash.bat". if you're lucky, you should see the main game selection UI.

i don't have windows, so i don't know if it works. it runs with Wine, though. sounds, gfx, BDCFF files were taken from GDash.

do not run "miho.exe" directly, it will simply crash.

[ketmar]

…and of course, i immediately hit the very… interesting bug in Miho Scheme. if your CPU is slow enough to trigger GC warnings, and it will happen in the wrong time, the game will crash. but what did you expected from "tech preview" anyway? ;-)

[ketmar]

current replay format:

Code: Select all

replay record consists of 16-bit signed integers, stored in little-endian format.
if the read integer is negative, it is a special replay command (usually followed by arguments).
positive integer means "change the contents of the gameplay board at this index to the element
whose index (otype) given in the next integer".

replay commands
===========

## -1 : end of frame
next 2 values: C64 PPRNG state at the end of the frame
## -2 : end of cave (finished)
## -3 : end of cave (died)
## -4 : end of cave (aborted)
## -5 : end of cave (skipped)
## -8 : player coords (args: x y)
used for camera panning
## -16 : magic wall active on this frame
## -17 : amoeba active on this frame
## -32 : diamond collected
## -33 : score change (arg: delta)
## -42 : exit opened
## -43 : there was an explosion
there was at this frame (maybe more than one). used for camera shaking.
## -44 : slime pprng was inited (no args)
## -46: play sound (arg: sndid)
sndid:
  * 1: GD_S_EXPLOSION
  * 2: GD_S_GHOST_EXPLOSION
  * 3: GD_S_BOMB_EXPLOSION
  * 4: GD_S_VOODOO_EXPLOSION

## -60 : play object sound (arg: otype)
## -61 : play object walk sound (arg: otype)
## -62 : play object push sound (arg: otype)
## -63 : play object fall sound (arg: otype)
## -69 : player hatched
## -666 : initial map
this command is always the first one. two args are board width and board height.
they are followed by the full game board contents.

it is usually followed by `-8` (player coords), and `-1` (frame end).


object codes (otypes)
==============
another SQLite table contains mapping between object code (otype) and symbolic object name.
object names are taken from GDash. note that the codes might be arbitrary, and only mappings
which are required to be there are for really used otypes.

of course, most of the info could be reconstructed from the game board changes, but my idea is that record player should be as dumb as possible. by writing all events and all board changes the player need not to execute any playsim logic. also, writing all events means that the whole game could be reconstructed and, for example, checked for validity: by running the playsim in parallel, and checking if the events match, for example. writing predictable PRNG at the end of the frame allows to stop replay at any moment, and continue "real" playing from that point. of course, i forgot to write non-predictable PRNG, which makes "validity checks" slightly harder, but this is because i don't want to hardcode non-predictable PRNG algo. i may add optional events to set its state later, though.

replays for crowded rooms could take 130-150 kbytes, which i deem acceptable these days. besides, they could be comressed with something like zlib before uploading, for example. cave and game metadata (author and such) should be kept separately, if needed.

p.s.: FYI, i have 340 replays now, and they took ~12MB of disk space. not that much.

[ketmar]

just got an idea: what if i'll make extra diamonds more useful? the player could use extra collected diamonds to "buy" the exit from the next cave. i.e. use them to "boost" the current diamond count, if necessary. it makes collecting those extra more valuable, and plays on player greed: "what if i'll need that one extra diamond later? i NEED it!" don't know about others, but i am ofter failing good runs exactly when i'm trying to get "that one more diamond" when the gates are open. making those extra even more useful should make the things even more interesting.

[ketmar]

Miho Dash tech demo v2: download.

brief changelog:

• UI improvements
• merged otype list with replay data
• replays and BDCFF files are compressed now
• configurable (only in the source code for now) keyboard bindings
• minimap (M)
• the game will ask if the player want to load a quicksave on death
• cave times is counted with passed game steps, not by using real-time clock (so single-step mode has the right timer)
• various bugfixes