[Release] BoulderCaves+, a Krissz Engine compatible remake

[Agetian]

Today was the "optimization" day I implemented several optimization techniques in BoulderCaves+ split across three optimization levels. Depending on the hardware, it will allow to run the game smoothly even if normally it wouldn't do so.

First of all, I tried to determine how bad of a hardware you can actually allow yourself to have in order to run BoulderCaves+, hehe I mean, there is, of course, a performance cost associated with running a game written in pure Python, so performance is kind of a critical thing when developing a game like that.

My experiments showed that the least you can allow yourself to have is something like a Raspberry Pi 4 (I tried a 4 GB model with no overclocking). A Pi 4 allows you to smoothly play standard-sized or slightly bigger caves without worrying about optimization, and can reliably play even large and busy caves with heavier optimization and/or while running under Pypy3 at least in 30 fps mode, but most caves even in 60 fps mode.

I tried going even lower than that, to a Raspberry Pi 3 (with a slight overclock) with 1 GB RAM, but basically any cave larger than 40x40 or maybe 50x50 or so is unplayable and the game grinds to a halt even in 30 FPS mode with heavy optimization enabled. Smaller and standard-sized caves play very well though on a Pi 3 even with very little or no optimization, and I played Boulder Dash I caves in 60 fps mode on a slightly OCed Pi 3 without a problem.

When it comes to desktops or laptops, basically anything that's not total trash that was made 5 years ago or later will allow to play pretty much any cave in BoulderCaves+ at least in 30 fps mode, but possibly in 60 fps mode as well, at least when running under Pypy3.

As for optimization levels, there will be four of them, and each subsequent one trades a little bit of visual accuracy for slightly more performance:

None - no optimization, everything is displayed and animated as it should, at the FPS specified during the game launch (if your PC can keep up, that is).
Light - slightly optimizes the reveal demos (usually the most CPU-intensive part of the game) by skipping every other frame of the reveal demo.
Medium - does everything that Light does, and on top of that will not scroll the playfield to the inbox, but instead just center the playfield immediately.
Heavy - does everything that Medium does, and on top of that doesn't play any object animations during the reveal demo.

I might introduce other optimizations to these levels later

Oh, and BoulderCaves+ now has its own, albeit simple for now, title screen. It's not much, but eh, I'll try to improve it later.


- Agetian

[Agetian]

Today I continued working on polishing frame-exact implementations of object interactions and animation.

The first thing I did was improve the behavior of inbox and outbox. Instead of being a continuous, fixed-frame blinking animation, the blinking is now properly implemented as an object state update which happens every frame (this behavior is confirmed on Krissz Engine and by looking at the GDash source). Not only this allows to properly "time" the blinking when it comes to frames, it also allows to avoid the side effect of having the inbox blink during the reveal demo, something that doesn't happen in the original games or in Krissz Engine.

Also, this allowed me to properly synchronize (up to a frame) Rockford's birth, making it frame-exact and time-exact when it comes to different values of Game Speed vs. the different values of Rockford Birth Time. For example, a Rockford Birth Time of 10 yields the following behavior:

Frame 0 (initial cave state) - inbox displayed in closed state
Frame 1 - inbox blinking, open state
Frame 2 - inbox blinking, closed state
Frame 3 - inbox blinking, open state
Frame 4 - inbox blinking, closed state
Frame 5 - inbox blinking, open state
Frame 6 - inbox blinking, closed state
Frame 7 - inbox blinking, open state
Frame 8 - inbox blinking, closed state
Frame 9 - inbox blinking, open state
Frame 10 - inbox blinking, closed state
Frame 11 - inbox blinking, open state, the "crack" sound for Rockford birth plays - Rockford birth stage 1
Frame 12 - Rockford birth animation is playing, Rockford birth stage 2
Frame 13 - Rockford birth animation is playing, Rockford birth stage 3
Frame 14 - Rockford birth animation is playing, Rockford birth stage 4
Frame 15 - Rockford stationary frame is displayed, can animate if the player pushes a movement button, but can't move this frame (scanned)
Frame 16 - Rockford can move, sequence complete

This behavior is now consistent in BoulderCaves+ and Krissz Engine. Also, the cave countdown timer is also synchronized with Krissz Engine and seems to behave consistently.

Another improvement was in the area of object animation speed in general. First of all, object animations are now properly synchronized with each other (thus, diamonds would animate consistently across the cave as opposed to being animated each from a different frame). Second, the speed of object animations now closely matches what is seen on Krissz Engine, though may not yet be completely cycle-accurate and needs a bit more testing. Then again, even if it's not 100% cycle-accurate, I don't think anyone will notice the minimal possible difference except in very thorough, possibly slow motion side-by-side comparisons.

Interestingly, I also found an alternative use for animation callbacks that I removed previously - instead of tying them into the cave scan order (a big no-no, as explained above), I wired them as a form of "fallback code" that would wrap up pending animations such as explosions after the game is over. When the cave is won, the regular cave scan stops - thus, if there are pending explosion animations happening, they will never end if they rely purely on the CSO update. Thus, animation callbacks will now be used as a form of fallback to catch those "dangling" animations and finish them correctly instead of looping them again and again. For example, it's possible in the rare corner case in Dustin's CSO 77 where Rockford blows up with the outbox right after triggering the outbox and winning the game. Unless this animation is "caught" and completed using a callback that would inform the animation system to stop animating the explosion and display an empty tile instead, it will repeat itself until the game is completely stopped.

Among other news, I started pondering over the possible Infinite Scroll implementation. It's a rather complex feature that might require quite a bit of refactoring/rewrite of the existing BoulderCaves code base, but I'm eventually figuring things out as to how they might work. Mechanically, at least so far, Infinite Scroll appears to be mostly a "view" thing where the cave scanning order remains the same and the "model" (e.g. the cave and its mechanics) is unaffected regardless of whether Infinite Scroll is active or not, but the playfield is displayed differently - essentially, in Infinite Scroll mode, it sort of "wraps around" on overflow or underflow, showing an extended view of the playfield. I haven't yet found any specific side effect workarounds that would work differently between Infinite Scroll and non-Infinite Scroll standard open border implementations, but I will test more things as I progress in figuring out this feature.

I also tested some more CSO effects and confirmed them to work. So far, so good. Stay tuned for more updates

- Agetian

[Agetian]

In the last couple days I worked primarily on improving and testing game mechanics and object interactions for various CSO effects. First of all, I confirmed that slime permeability-based maps work the same as they do on Krissz Engine. For example, Dustin's CSO 184 ("Slime Time") is completable in BoulderCaves+ with the same per-frame configuration as on Krissz Engine.

Also, Light Boulder was used a lot in testing CSO and open border functionality. It's a kind of an object that I like to call a "pure CSO object" at the moment, or a "pure CSO boulder". Since you can pretty much always push it, it clearly shows where you go forward along the cave scanning order (and you can thus push the object on with no delay and without it falling) and where you go against the CSO, and the light boulder would fall since it would get scanned before Rockford has a chance to push it.

The Launcher received a hefty upgrade, now allowing to choose more options and, very importantly, to select subfolders in the "caves" folder, so you can organize your caves by name of the cave author or somehow else:


Another significant breakthrough is the serious optimization of the reveal demo. Now, Pypy3 is no longer required on fast and even midrange PCs for most caves, even in 60 fps mode. More information about optimizations will follow soon, since this work is currently underway and more optimizations may be introduced soon.

Here are a couple videos from the current build of BoulderCaves+ so that you can see how it's shaping up:

A short video of playing Arno 452 converted to BoulderCaves+. Quite hopelessly I might add, but that's a different story.
A video on Dropbox.

Me torturing myself with CSO #174 - Guillotine until I finally get it
A video on Dropbox.

Please note that the game is running in 60 fps mode, but the videos are recorded at a lower frame rate, so the game is running a lot smoother in practice than you see on the videos.

- Agetian

[Agetian]

The last couple days were mostly spent testing and tweaking game mechanics. I confirmed that CSO 206, which utilizes a partial amoeba to diamond conversion trick, can be completed in BoulderCaves+ just like it can on Krissz Engine.

Another curious cave I tested was Dustin's CSO 144, which involves a side effect at the open border that allows Rockford to safely pass under an endless rain of heavy boulders and also to push a heavy boulder to the desired location with the help of a light boulder. These side effects were important to test to ensure that BoulderCaves+ open behavior was consistent with Krissz Engine, and I'm happy to announce that yes, both effects work perfectly fine and CSO 144 can be completed in BoulderCaves+ without a problem.

This observation also led me to more investigations of the infinite scroll feature and its ramifications for the open border side effects. The more I test things, the more I'm certain that infinite scroll is just a visual variant of the open border, with the underlying mechanics remaining essentially the same. For example, a smaller version of CSO 144 (with no infinite scrolling involved) can be completed in exactly the same sequence of steps in both Krissz Engine and in BoulderCaves+ as well.

As for the possible infinite scroll implementation in BoulderCaves+, I'm still investigating things. I'm likely to opt for a simpler "mirror borders" implementation first, where a row or two of tiles beyond the cave border will mirror the opposite part of the cave, creating the illusion of an infinite cave. Later this implementation might be upgraded to a full infinite scroll if I figure out how to properly do it

Stay tuned for more progress, as usual

- Agetian

[Agetian]

Currently I'm making some progress in figuring out the implementation of an extended open border view similar to Infinite Scrolling in Krissz Engine. So far, I came up with an implementation based on mirroring the playfield - basically, the playfield will be surrounded with "mirror tiles" that will show the opposite part of the map, essentially making an illusion of an "infinite world". When the player crosses the border of the real map, the game will realign the view in such a way that it makes an impression of transitioning through the map instead of jumping across to the opposite end.

So far, there are two different "variations" of the extended open border view in BoulderCaves+. The first one is unique to it, and it basically allows you to set the size of the "extended see-through" border (currently in the range between 1 and 3). As you approach the border, you will see the border represented with tiles with a white hatched pattern overlay:



You can see what's happening on the other side. Once you cross, you jump to the opposite side of the cave.

The second implementation is the actual "infinite scroll", which basically draws enough mirror tiles (with no hatched overlay this time) to make a full impression of the infinite world, and then tries to realign the view more or less smoothly to make an impression of a transition.

This works similar to Krissz Engine infinite scrolling, but currently, I can't quite figure out the proper math for the view realignment, and because of that, you can still "feel" crossing the border as the view jerks around slightly as the view is repositioned. I wish I were better at math and figuring these things out, but I'm not, so I may actually need some help in making this smoother and hopefully seamless once the game is publicly released, code and all. If the project ever gets any contributors, this may actually be one of the "known issues" that will need to be addressed. As of right now, this is the best I could come up with when it comes to transitions across the border in the "infinite scroll" mode:

A video on Dropbox.

As you can see on this video, transitioning in this particular scenario from right to left is mostly smooth and seamless, but transitioning from left to right is noticeable due to a single-tile noticeable realignment. Also, when crossing the border back and forth with single-tile steps, you can also notice the shift in view. This is more noticeable on maps where both borders are open (horizontal/vertical) and when you cross both of them in succession.

Hopefully someone will be able to help figure out the proper math for this after the game is publicly released (unless I get some kind of a sudden insight as to how to properly do this myself, haha).

When it comes to performance, it is, of course, a somewhat "costly" implementation for a pure Python game, but it works smoothly on my faster test PCs. I'll also implement some optimizations soon which should make these modes more "palatable" on legacy hardware and/or larger caves. Still, you may need to have a reasonably decent PC if you want good performance, especially in 60 FPS mode, and especially if you're planning to run the Infinite mode (the extended see-through border mode with 1-3 tile hatched overlay border is less costly when it comes to performance).

- Agetian

[Chris Neilson]

Hey.

My game boulder cave game is slow. https://ibb.co/XkVrrvn
And too big window. https://ibb.co/NLXytPZ

My screen 1600x900 display resolution.

Plz can fix this game and editor. make fast and make scroll window and window size.

Thank

[Agetian]

Today I'm testing open border mechanics and comparing them side by side in Krissz Engine and BoulderCaves+. Here's an interesting video showcasing a simple firefly formation behavior comparison running pretty much simultaneously in Krissz Engine and in my BoulderCaves+ engine, showing the same behavior with pretty much the same timing. Both games are running in the "infinite scroll" mode for the open horizontal border. Thought it would be of interest to show here, hehe

A video on Dropbox.

- Agetian

[Agetian]

Hey.
My game boulder cave game is slow. https://ibb.co/XkVrrvn
And too big window. https://ibb.co/NLXytPZ
My screen 1600x900 display resolution.
Plz can fix this game and editor. make fast and make scroll window and window size.
Thank

Hi Chris, thank you for your interest in my project!
I'm currently working on improving the game and making it more compatible and more true to the original mechanics and to the mechanics used in Krissz Engine. Many issues of the original implementation, including, e.g., the one-second lag when grabbing tiles, are already fixed.

The top priorities are mechanical correctness and compatibility with Krissz Engine, but I'm also trying to optimize the game as I go along. The current development build of BoulderCaves+ is a bit faster than BoulderCaves, I'm able to play most caves on a Raspberry Pi 4, which is worse performance-wise than many low-end office PCs. I'm aware of the issues with the editor size, currently I haven't found a way to make the editor window look better on smaller screens, but I will eventually get around to it, so hopefully I'll be able to think of something

- Agetian

[Agetian]

Alrighty, inspired by Chris's interest in the project and his request to make the editor usable on smaller screens, I slightly redesigned the construction kit window so that it fits a 1600x900 screen It took quite a bit of time to figure things out, but I believe it actually looks better now than it did before. It can still be expanded to bigger screen sizes, but sadly, any resolution below 1600x900 is still not usable. I'll see if I can improve it further later Here's what it looks like at the moment.



While I was working on this updated interface, I also fixed a few bugs in the original editor. For example, the "lock horizontal/vertical placement" option with Shift was partly broken, at least on Linux, with it staying persistently and not turning off when you release Shift. Some other minor inconveniences were patched as well, but nothing major to write home about

As always, stay tuned for further progress.

- Agetian

[zsom]

Hi. Ever since I saw such a great project being created, I am always euphoric.
I read new messages from you every day.
I support you with all my heart.

I look forward to seeing the first playable version of your game.

greetings

[Agetian]

Hi. Ever since I saw such a great project being created, I am always euphoric.
I read new messages from you every day.
I support you with all my heart.

I look forward to seeing the first playable version of your game.

greetings

Hi Zsom,
Thank you very much for your interest and support of the project! I'm happy to hear that my efforts to make a Krissz Engine-compatible improved Python implementation of Boulder Dash are found to be interesting and useful! There is some progress every day, and I'm hoping that a generally playable version is ready closer to the end of the year

- Agetian

[Agetian]

Alright, today's report is going to be a rather interesting one. Unfortunately, as of yesterday, I lost access to the Krissz Engine website, and I know I did because of my own silly actions - while experimenting with my cave converter, I tried to automate the download of some of the cave images from Krissz's website, and not only I actually failed in doing so (and, quite obviously, I shouldn't have attempted it in the first place), I also accidentally left the downloader going, which probably caused lots of automated requests to the server which grabbed a lot of index pages. I admit this was stupid of me, and I got carried away in my experimentation. I already apologized to Krissz privately, but I have no idea if my apology will be accepted or if I will ever regain my access to the website. Thus, on top of that, I would like to also apologize publicly here, and I would like to assure Krissz and the community that I did not have any malicious intentions in doing what I was trying to do. I hope that I can be pardoned for it eventually, but if not, I'll just have to accept being banned.

This incident actually got me thinking about things. And I would like to discuss a few things here with you guys, because after all, everything I'm trying to do, I'm doing for the benefit of you all, the community here. Thus, I would like to know what you think, too.

The first thing I was reassured in was how fickle the situation truly is when the existence of an enormous cave database consisting of over 10000 caves made over the last 7 years depends on the existence of a single online service which is not only closed source, but also privileged access-based. Should the said service shut down for any reason, or should anyone do something, possibly unintentionally, that would cause the revoke of access privilege to the service, there is the risk of losing either all the work done so far, or at least the work done by a particular person. Or there's a risk of losing access to this work, even your own work, should your access to the site be revoked. Personally, as an open source advocate, I don't truly understand the necessity to have a closed source model of release for the engine, but at the very least, I respect it as Krissz's choice. It's his engine after all, and it's up to him whether he wants to share its inner workings with the world or not. However, at the very least, the caves themselves, in my humble opinion, should be exportable in at least some format that would allow the cave author to keep his hard work for as long as he wants, and share it with the world if need be, because caves belong to their rightful authors, not to the service holder - at least as far as I understand, maybe I'm wrong, but I don't think that at any moment, the rule was communicated to me that the caves I make would belong to the engine and its owner?.. I hope I understand things right, guys, I don't want to offend Krissz or anyone else by saying something here that maybe I just misunderstand.

This particular thing was what got me into BDCFF conversion in the first place. Krissz Engine itself offers some features that allow to preserve a visual snapshot of the cave, albeit sometimes a limited one (a "semi-clone"). In my humble opinion (and it's just an opinion, mind), Krissz Engine would have benefited greatly if it had a simple plaintext export option for caves, at least available to cave authors. If a cave author had an option to click a button and get a .txt representation of his own cave, not even necessarily in a BDCFF format, but just in a format that would be human-readable and interpretable - maybe an ASCII map with a legend and a text description of the options specified in the engine - it would have actually completely removed any necessity to have an outside converter that would have to do something as convoluted and roundabout as perform an OCR on a cave image and then build a BDCFF representation based on that. Conversely, had that been possible, Arno would not have needed to collect thousands of visual snapshots of cave images in an attempt to preserve the history (a great effort by the way!) And of course, I would never have started my cave image conversion project, and thus, the accident that I brought about yesterday would never have happened either.

I don't really understand why Krissz Engine doesn't have its own cave export option. Maybe it is to make the caves "exclusive" to the engine, but I'm not sure if that's actually beneficial for the community itself in the long run (once again, my opinion only). It feels like it's almost the same thing as making, for example, a chess engine, maybe with some custom rule modifications or something like that, and then saying that if you make a chess puzzle in that engine, you can't and shouldn't be allowed to preserve it in any other format or recreate it in any other chess engine that exists. I don't know how important it is to strive for that, to be honest, it seems counter-productive. Moreover, it doesn't truly prevent copying the said puzzle - it's still possible to OCR the screenshot, or if that doesn't work, it's possible to manually lay down the pieces in the same way. It's more work, yes, but it's not impossible. Let's say Krissz removes all the options to make cave snapshots or images in the editor - does that prevent the cave from being exported? Not really. Since one can just take screenshots, stitch them together, and OCR. More work? Yes. But not impossible. Even if that's somehow completely prevented, it's still possible to recreate the cave piece by piece in a different construction kit. Once again, more work? Yes, indeed, but what's the purpose of it?

Now, when it comes to the incident from yesterday, I actually have some suggestions to Krissz regarding how to optimize the website and also make it more resilient to automation. I would like to offer this as a form of apology for my automation attempt from yesterday. I would like to suggest that when the database retrieval happens, only the list of found caves is delivered first, and the data about the cave and the forum message, as well as the link to the cave, is only sent to the user when he actually clicks the cave name. Not only will this make it impossible to automatically grab the link to the cave page, it will also make the database access slightly faster and more responsive. I don't know if Krissz is likely to see it or he would like to talk to me again or not, but hopefully this will benefit his project in some way.

So, what does it mean for BoulderCaves+? For now, nothing much. The project is progressing and it's actually shaping up to being close to the state where it would be possible to release it to public. Whatever information I may still need about the engine and the caves, I'll just have to infer from whatever videos exist of the engine, from Arno's contributed cave snapshots, and from the construction kit image exports that I did while I still had access to the website. It may be a bit of a setback, but it's the price I have to pay for my own actions, so I'll accept that and I'll work with what I have. The project is still set to be released at the end of the year, hopefully by Christmas time. In my letter to Krissz I asked him if he's alright with the existence of a compatible engine, because I know that I never asked, and I truly hope that Krissz will understand my reasons and will also be able to see that I did not and I do not mean anything bad for his amazing online project and the community around it.

So yes, that's the report for today. It is, indeed, an unusual one, and also an apologetic one, but I have to amend for my sins, and I do have to learn my lessons. Did I learn a lesson here? Yes indeed. Do I still feel determined to finish my BoulderCaves+ project? Also yes indeed.

I would be happy for any feedback that anyone can provide. Sometimes I wonder if I'm the only one who feels weird about the exclusive availability of Krissz Engine caves on a website with limited access. Maybe I am, indeed, overly paranoid or stubborn about it? Maybe everything that I'm saying here in this thread and that I'm trying to accomplish with my BoulderCaves+ isn't, after all, worth it? I don't know, to be honest. Whatever I'm doing, I'm doing for the community. Sometimes I do good things, and sometimes, unfortunately, I make mistakes, like everyone else. As unfortunate as it is, these mistakes may affect others in a way I never intended, and that pains me. All I want is that, in the end, all of what I'm trying to do here amounts to something beneficial and not undesired or frowned upon. So, thank you very much for reading, guys, and as always, stay tuned for further project updates.

- Agetian

[zsom]

Good day.

As for the Krissza site, I am registered there, and I was also wondering about the problem, what would happen if the Krissza site stopped working.
Personally, I like the LogicDeLuxe XDC-engine project the most. However, there has been no news about it for many years.
I asked here on the forum several times what is going on with this project, but no answer was given to me.

The second mega product is Gdash.
Here, just like with XDC, Gdash was abandoned by the author of Cirix.

I have a question for you, Agetian.
What operating system can Bouldercaves + run on?
What will the processor and other parameters of the computer need?

Best regards.

[Agetian]

I have a question for you, Agetian.
What operating system can Bouldercaves + run on?
What will the processor and other parameters of the computer need?

Hi Zsom,
BoulderCaves+ is going to be a fully cross-platform, open source game. It's written in standard Python 3 and only uses the minimal amount of support libraries (Tkinter, which usually comes with Python, and Pillow/Synthplayer/Miniaudio, all of them easily installable using Pip). As such, BoulderCaves+ will run on any system that can run Python 3 and use those packages - in particular, Microsoft Windows, Linux, and MacOS should be fine, something slightly more exotic but that has similar packages might be OK too but will need testing (e.g. FreeBSD?)

As for what kind of a PC it can run on, I tested it on a variety of hardware by now. If you only play standard-sized caves that are not overloaded with dynamic elements, you can get away with something like a Raspberry Pi 4 or possibly even 3.

If you play bigger (e.g. 80*80 or 100*100) caves, or caves that are overly busy with flies and amoeba and such, you may need a better PC, but pretty much any Core i3/i5-class PC from the last 5 years or so should be able to tackle most (all?) caves without any problem in either 30 or 60 fps mode. Raspberry Pi 4 can play big caves as well, but you can't really use infinite scroll in them, and some of the busier caves may need additional optimization options to work at playable speeds.

Running open border caves in infinite scroll mode is more demanding, but this requires more testing and optimization, something I'm still working on, so it's difficult to tell as of yet what minimum system requirements would be for that. Raspberry Pi 4 currently exhibits moderate slowdowns in this mode on 40*22 and bigger caves, but my test PCs (Core i5 from 2014 and Ryzen 7 from 2019) show no slowdowns whatsoever.

- Agetian

[Chris Neilson]

What happened with Krissz website?