Rocks'n'Diamonds

I went to the Github repository,
https://git.artsoft.org/?p=rocksndiamonds.git;a=summary
and paged back through the shortlog;
I got as far as:
https://git.artsoft.org/?p=rocksndiamon ... tlog;pg=29
which is about April 2018.

Every commit as far as I could see, was by Holger.

Can anyone explain what the intent of the Git hub repo was/is, in terms of making contributions? Holger, can you explain what you were/are hoping for, in terms of it being an open source project, presumably contributable by anyone?

Put another way, the Github repository, what is it for? Is it just so that users can compile from source? Or is there more to it?

Have any current forum members ever made a contribution, or thought about making one, but decided not to? What factors did you take into account when a) considering contributing, and b) deciding not to?

Just trying to understand what would be involved in contributing;
offhand, I assume that one would have to have,
- strong skills in C and C++
- knowledge and experience of source code control via Github or similar
- knowledge of Rocks'n'Diamonds enough to be able to make a meaningful [positive] contribution
- ability to work in harmony with others.

John

My understanding is that this is 99.9% Holger's project, but it is not 'closed source'. He wants us to be able to see not only the code, but the code progression.

I have contributed small bits of code in the past; communicated via email or forum posts or PMs. What eventually ended up in the code was only 'in the spirit' of what I submitted; changed to Holger's style of coding, variable names, whatever (I don't even remember at this point). Mind you, this was before the public git repository; it is possible that if I were to contribute again, I would try to do it through git branching etc. rather than direct handoffs.

Anyway, I think of it like this. We have the Mona Lisa sitting in a museum somewhere. Would it be enhanced if we also had a series of video recordings of Leonardo painting it, muttering over it, correcting errors, mixing paints, etc.? It wouldn't change the painting itself, but surely the combined 'multi-media artwork' would be even more valuable?

I imagine it's also somewhat a matter of self-discipline; making sure segments of effort are 'checked in' somewhere so that he can do things like bisect for when an error was introduced. Even if you are working 100% privately on a complex project, it's good to have some sort of change management system for such purposes. Making that public is a choice, and -- for a project intended to be as visibly open as this one, makes sense.

I really don't know anything about Holger's intentions with regard to incoming changes from anyone else. I know he welcomes them (to a degree), but don't know if the git tree is meant to solicit them or just sort of make them possible. I imagine he'll have something more direct to say on that matter :)

(I should add: code-wise it is not 99.9% Holger's, as he has imported multiple game engines from other people's projects. However, those have always been Holger's work of importing, not some other game author injecting their work. I'm making this correction specifically to separate between how much of the source work (massaging interfaces, committing, etc.) is Holger's, vs. the somewhat smaller -- and I wouldn't hazard a guess at a percent -- amount of the original source code is his.)

Thanks for the response Filbo.


Some more things I thought of that seem necessary for the wannabe contributor:

- ability to compile on own platform
-- in my case, I've never been able to make this come true (on Windows). I did it on Linux with a single word, but I have other/different problems with Linux that prevent me just doing it that way.

- ability to compile on other platforms???
I'm not sure if this is a necessity, or not. If it is, then that would rule me out, as I don't have a Mac and have abandoned all the Linux installs I have ever made. I guess I do have an Android phone...

- knowledge enough of then organisation of the source code not to do something dumb.


As for your remark about source code from other systems, I think of Rocks'n'Diamonds not so much as a game as a meta-game, or game construction kit,

- Partly because it handles multiple game engines [and MM/DF is entirely original to Holger, i believe];

- Partly because it has a level editor. Mind, so do lots of games, including Boulderdash 4, Emerald Mines, GDash - I would argue that a level editor is 100% necessary for a modern Boulderdash-style game

- Partly because it has custom elements, which are a good attempt at providing general programmability. Personally I find them very frustrating and no longer use them very much, but I have seen what people like Alan Bond have done with them, eg with Snakebite.


So, thinking of Rocks'n'Diamonds as a meta-game, I am more interested in the part of the source code that is unique to Rocks'n'Diamonds, than in the port-of-game engines parts.

By unique, I am thinking of things like:

- file handling
-- e.g. ability to save a level when playing, in its current state
--- hence 'fork' the level, leaving the original untouched, but saving the 'as played' level as a new file, maybe as the latest level in the levelset(?)

- level editor
-- e.g. palette
--- adding more options,
---- eg ability to rotate the contents of a level;
---- ability to replace all occurrences of an element with another element;
----- ability to replace an element with its contents - mainly for Group Elements but maybe also other elements that can have contents [player?], or explode to give elements; this would hijack a run-time feature and turn it into a design tool.

- graphics handling
-- e.g. ability to display RND elements when playing a level under BDX element.

- elements unique to Rocks'n'Diamonds
-- e.g. CEs
--- extending further and making even better
---- e.g. have the ability to start customizing a CE by giving it the base behaviour of a certain built-in element, eg mole, dragon, Game of Life.

- possible extending of certain standard elements, by adding settings that default to traditional unless explicitly set
-- e.g. nccrec's idea about contents of ghosts
-- e.g. want a butterfly that travels in opposite clockwiseness on this level? - just make a setting
-- e.g. want a dark yamyam that can devour walls or doors or exits or keys? - just make a setting
-- e.g. give Biomaze the ability to trap monsters and destroy them, once trapped.

-- hence over time, to extend the ability to customize the built-in elements more.


These areas would affect the built-in engines to a greater or lesser extent;
e.g. anything to do with file saving and reading could have a massive impact,
so to be done good enough, would need to have no effect on existing levels and levelsets,
and would need a lot of testing to verify this.

It seems hard to unpick, and know where to start. Does anyone have any thoughts? Anyone want to collaborate on a small, 'demo' code contribution?

John

I would certainly encourage you to Start Small! See if you can develop code to do just one tiny aspect of the many varied things you described.

As to building -- I've never tried building RnD on Windows, but the ./INSTALL file claims it should work the same as Linux, i.e. just run `make`. It also says 'with gcc or MinGW', so you'd want gcc handy; and libsdl2 with its sub-libraries.

That said, I suspect it might almost be easier to set up a Linux VM on one of the various free VM runners, than get a properly working dev environment for this :) But that's my general disgust for Windows speaking.

filbo already answered the initial question quite well. Here are some additions by myself:

Since many years, I use a Git repository for managing the source code of R'n'D, because it offers many advantages over the "make a tar ball every few days" approach I used before. =:-)

As R'n'D is open source software, I see no reason not to make the Git repository publicly available. For those that like to fiddle around with the source code, it may make it easier to keep the code up to date.

However, the intention of the public Git repository is not to make it easier to make contributions (as it would be the case with typical GitHub repos, with people using pull requests to add their changes). R'n'D is not a typical community project, but a hobby project of myself. If you should have written a change or addition or improvement that you would like to add to R'n'D, just create a classic patch file and send it to me by mail. But there is also a copy of the repo on GitHub, so you can indeed create a pull request to offer changes -- others have already done that in the past, and it also works fine for me.