[Release] BoulderCaves+, a Krissz Engine compatible remake

[DarkStoorM]

I actually would also like to know this.

We know that Boulder Dash is Trademarked, which, I think, can lead to problems when someone decides to release his clone to public - I don't see people caring at all since we have... hundreds of clones?. I'm not really sure, but in this case, each BD clone should have a license that was originally shipped with the software, which I don't think it was back in the day, but don't quote me on that - or basically: no license = no permission.

In my opinion, when you release something like Boulder Dash, the copyright still belongs to BBG Entertainment GmbH - no matter if original assets are modified or not - and it should be stated explicitly in the project, but I would need a confirmation on that. How is that called... you "waive your rights"(?)

For me it's a bit complicated, so it would be nice if someone could shed some light on this matter.

I personally use GDash assets in my clone, but I don't even know where they originally came from.

[Agetian]

Yes, indeed, I have exactly the same thoughts.
The original Boulder Caves appears to also use the GDash assets, which are, in my understanding, a conglomerate of the original assets from BD1 and BD2 and also the various fan-made objects packed into a single tile sheet. Boulder Caves+ reuses that but also adds an extra row for Krissz Engine-specific tiles and their variations.

I definitely intend to provide all the original information regarding the copyright owners, and I'll also mention all the fan-made sources of material that I used on top of that, Krissz Engine included.

- Agetian

[Agetian]

Today I'm working on optimizing the code, and I'm testing DarkStoorM's idea with changing over from using full objects when performing a cave scan to a shorthand in the form of identification codes. I didn't rewrite the entire code to use the codes internally (at least yet), but I did change the code that performs checks against various object types to only check the ID instead of performing a full object comparison every single time. That seems to have given quite a performance boost, though the exact extent of it is yet to be established as I test the code on lower end hardware such as Raspberry Pi. Stay tuned for information. And thanks a lot to DarkStoorM for an interesting optimization idea!

Found a couple weird bugs in the process that need fixing, so will take care of that next

- Agetian

[DarkStoorM]

Small question: are you working on a GitHub repository? If you just want to write a test code, the best way is to branch off your current working code, release or Master (currently: main) and break as many things as you can then you can revert any time you want back into your "working" state without losing any of the code. SVN is a blessing these days

It would actually be a nice experiment to keep the old code and check the performance on a cave bigger than 100x100 then compare with the new updates.

I might come up with some more optimization ideas once I get more free time good luck

P.S. I don't know Python, but if you base your project on the original BoulderCaves, I will take a look at their source and find some room for improvement always nice to practice with new stuff

[Agetian]

Yeah, I'm currently running a local/private GitHub repo but I'll make it public soon-ish Actually, has been working with Git for quite a while since the main project I develop and maintain (Forge, a fan-made MTG game) switched over from SVN to Git. I agree that branches are a blessing indeed. And the fact that Git works locally in addition to remote is a blessing too.

Yeah, I'm going to experiment with some stuff as well and I'll post my findings in the next few days And yes, the code is based on the original BoulderCaves, though it has changed quite a lot from the reference implementation by now. Thanks again for your help and for interesting ideas, DarkStoorM!

Btw, speaking of the thing that still gets me the most when it comes to the original Boulder Caves, it's definitely the Rockford blink/tap animation - even with all the code seemingly in place, it looks like it just won't sync completely correctly to the beginning of the animation cycle. Will need to get back to it later at some point.

- Agetian

[Agetian]

Today I ran some tests to measure the performance increase after switching over from comparing full objects to comparing objects IDs during the cave scan. I tried 100x100 open border maps thus far, which are probably going to be the biggest maps played on Boulder Caves+ unless we enabled even bigger maps than e.g. Krissz Engine supports.

When it comes to 100x100 open border maps, there is indeed a noticeable difference, though not as dramatic as I thought it would be. However, it's significant enough to make the game more tolerable on a Pi 4 without needing to resort to something like Pypy3 for extra optimization. Another interesting observation is that after all the optimizations implemented thus far, the game appears to be more graphics-bound than limited by the computing power needed for the cave scan, at least on most tested hardware and in most typical caves and gameplay scenarios (unless I deliberately "overload" the cave scanning routine with an oversized map full of dynamic elements and explosions happening simultaneously).

Thus, it looks like for the future optimization, it may be at least as important to figure out how to make the display more efficient rather than just the cave scanning (which is still very important though). Sadly, the biggest optimizations in the graphics department may come from a port/rewrite to a different graphics framework, such as SDL 2 (which is possible via Pygame 2.x), and as such, this is a longer-term goal for Boulder Caves+ that won't be implemented yet for the initial release.

As always, more progress reports will follow soon

- Agetian

[Agetian]

Today I fixed a few minor issues that I found while testing the game in various modes. I believe I'm getting close to completing the testing cycle as well, and to be honest, I don't know if there's much left to do with the game before the initial release.

I'm sure there will be more bugs and issues to squash after the release, but so far, the initial goals seem to have been completed, at least.

Am I satisfied with the final result thus far? Well, kind of. It's my first "solo" project that is basically a game I've never tried coding before. It's also based on an existing code base that's far from ideal and it's somewhat difficult to work around certain issues and limitations of the original Boulder Caves engine without rewriting significant portions of code. As such, I'm not yet sure if, once I get to the SDL 2 porting stage, I'm actually going to keep maintaining this particular core or if I'm just going to write a fresh SDL 2 one from scratch using the Pygame 2 framework and then "slab" the engine on top of it, reusing the successful portions of Boulder Caves+ and writing the unsuccessful ones from scratch. We'll have to see, I guess.

That said, most of the initially planned goals have indeed been completed - Krissz Engine compatibility, a conversion toolset to convert Krissz Engine cave images to BDCFF supported by Boulder Caves+, a more fluent and optimized game engine than the original Boulder Caves, better implementation of Boulder Dash mechanics than the original Boulder Caves went for.

There are still things left that I can't quite figure out, at least within the confines of the Boulder Caves core. Properly fixing Rockford idle animation, for example, will most likely necessitate the rewrite of the object animation subsystem as such, avoiding the strange and seemingly arbitrary system of assigning a "sfps" property to each object and then using that as a basis to synchronize each animation to the game loop. This will have to go, most likely, and be rewritten in a way DarkStoorM suggested above, with all the animated elements synchronizing to the same animation cycle variable that increments from 0 to 7 and then wraps around.

Infinite scroll implementation definitely needs more work, and that's where I can't quite find the needed breakthrough. Not only do I not know how the original infinite scroll was implemented in Krissz Engine, I also have little idea how to improve my mirror tile-based implementation to make it transition smoothly across open borders. It's also one of the "heaviest" parts of the code, significantly affecting performance and thus only really useful on either faster modern PCs or smaller-sized caves (best if under 1000 objects scanned per frame).

So, that's where I stand for the time being. Stay tuned for further updates and the upcoming release!

- Agetian

[Agetian]

Alright, it's that time, I guess - time to make the project public. The remake is now released, and the game (and its source code) are now available from the link in the first post of the thread.

It was quite a journey for me, a project that made me tread unknown waters and learn new things. Overall, I spent nearly 400 hours in the last 3 months coding, testing, playing, fixing, testing again, and coding again to bring the project to the state it's currently at.

It's not perfect by any standard, and it could use improvements in multiple areas (and will receive these improvements over time), but for the time being, I think it can be deemed playable and it can be deemed an improvement over the original Boulder Caves to enough extent to warrant a public release.

This is my first Boulder Dash-related project, so I'm pretty sure I messed up at least in a few places. I will look for opportunities for improvement as time permits, but for now, I think I'm going to take a little rest from the project, as the development marathon was quite intense.

I bundled quite a few converted caves with the game - most of them were tested to be completable, but some of them haven't. If you know a cave that can't be completed, let me know and I'll take it out unless I can improve the game promptly to make it completable. Also, no one objected so far to having caves bundled with Boulder Caves+, so I hope it's alright that I included a few, but if you would like me to remove any of your work from the bundle, let me know and I'll exclude it from the game. I did try to give full credit to every single cave author and I tried to provide enough information about the cave to the best of my ability and knowledge (as well as convert the caves to the best of my abilities judging by the video demos and in-game testing when I had access to Krissz Engine), but if I misrepresented something in your cave, please also let me know.

I would like to wish everyone a merry Christmas and a happy New Year, and I would like to say sorry for any grief or any misunderstanding I have inadvertently caused. I hope that all of you stay safe in the upcoming year, and I wish you all a lot of creative inspiration for more great Boulder Dash material to come! I wish the whole Boulder Dash community the best in any future endeavors you may have. Thank you for being there for me if you supported me and if you keep supporting me in my project.

- Agetian

[DarkStoorM]

Nice work! I will definitely give it a try once I get some free time and manage to run python apps on windows getting some non-existing module errors (it can't find Tkinter: ModuleNotFoundError: No module named 'tkinter'), gonna figure that out later

---

I know this probably won't make a difference, but I would compress the spritesheets. I usually use https://tinypng.com/ for compressing images, mostly pixel art. I checked some files and the difference is pretty big, especially when there is not much color information. Anyway, I don't think it matters at this point



and oh boy, I did not expect a Boulder Dash project to be this huge

One thing I would like to suggest is, and it's only just my personal preference, extract most of the logic and separate it either by its type, purpose or by object (cave objects) and keep them in separate files to make it somewhat organized.

I think it would help a lot with reading through the code, but seeing the current state I believe that would be a massive amount of work
or maybe that's how Python programming looks like, I don't know

[Agetian]

Oh, thanks a lot for the heads-up regarding TinyPNG! I'm definitely going to look into compressing those images, that's a good idea!

Totally agree that the code could use some reorganization and refactoring, too Going to have to get back to that later, but it's definitely something that should be done, otherwise it's pretty easy to get lost in the code even for me though I worked with it for a few months by now It will be quite a lot of work, yeah, but it's definitely on my todo list, hehe.

Tkinter - yeah, it's one of the core modules that are needed for the game to function. On Windows, it generally comes bundled with Python, but on Linux Mint, for instance, I needed to install it separately from the repo (as python3-tkinter IIRC). Not sure about MacOS

- Agetian

[Chris Neilson]

Bug score

Cant cancel. still there and cant quit.

[Agetian]

Thanks for the feedback, Chris!

EDIT: I pushed a change to the Git repository that will make the game only ask for the high score once. If Cancel is pressed or an empty text is entered, high score won't be saved. If a name longer than 7 characters will be input into the box, it'll be trimmed to 7 characters. This will be available in the next release version.

- Agetian

[Chris Neilson]

At cave editor and playtest.
Open border problem with authentic c6 color.

"-m 100" is infinite scroll screen while load test cave in game

Code: Select all

            parameters = [sys.executable, "-m", game.__name__, "--krissz", "--playtest", "-s 5", "-m 100", "--game", gamefile]
            if self.c64colors_var.get():
                 parameters.append("--authentic")

or

Code: Select all

            parameters = [sys.executable, "-m", game.__name__, "--playtest", "-s 5", "-m 100", "--game", gamefile]
            if self.c64colors_var.get():
                 parameters.append("--authentic")

I test run cave with commands.

In editor

Open border problem

And its worked with game

[Agetian]

That's an interesting issue, most likely the current code doesn't play well with the mirrored border code - I'll try to fix it tomorrow. How do I reproduce it? Where did you add the code outlined above?

- Agetian

[Chris Neilson]

Open horizontal and Open vertical border problem with infinite scroll screen while load test cave without titlescreen start with open horizontal and vertical border.