Seems like the concensus is that Attnam/master is the working space, NOT the "stable" version. Stable versions will instead be released as tags.

I can fork Attnam/master into capristo/master and then make my own changes. After I have tested my changes, I submit a pull request to Attnam/master which is merged in so that everybody else can test.

If I have a larger feature that will take a long time to complete, I can branch my own fork into capristo/FireSystem. Then when I am comfortable with this feature being complete, I should first merge into capristo/master, and then submit a pull request as usual to Attnam/master.

Then to release specific versions, we should use git tagging because that is basically what it was built for and what Github supports out of the box. For example, after my capristo/FireSystem branch has been merged in, we tag this as version 0.51. All commits up to this point are now released as version 0.51 and can be downloaded as a zip. Then if we fix a few bugs related to the fire system, we can release this as 0.51.1. The next batch of bugs is tagged 0.51.2 and so on. Then when we add the next big feature, call it 0.52.

That was designed for APIs. I am ok with using a letter to denote the patch instead, e g. 0.51a, 0.51b

Ok so from this it seems I need to make a fork of master, and then make a feature branch (firesubsystem) from the fork. Got it

Edit: So I did this and consolidated the other branches that were swimming alongside my fork. It seems to me that small, self-contained changes should indeed be merged early and often, whereas a larger subsystem should be worked on and tested to some degree before merging into master.

The question is, if I want some testing done, should I release on my own fork?

Inspired by murlock's SDL2 patch, a thought crossed my mind — Should we perhaps convert the project to C++11 as well?

I mean, IVAN currently uses C++98, which is already 17 years old. I think C++11 would be a great step forward.

Some of the C++11 features I'd love to have in the IVAN source code include smart pointers, override (and final), delegating constructors, range-based for, constexpr, auto, = delete, = default; maybe also: new algorithms in <algorithm>, decltype, lambdas, enum class, static_assert; to name a few.

This is of course a lot of work. I think it could be manageable in chunks, one feature at a time. And not necessarily all of the above. I'd be happy to do this. If anyone wants to help, that'd be awesome.

I just had a thought. You could totally include Bleeding as a feature of damage. All you would really need to do would retool critical hits to inflict a different form of poisoning; and name it bleeding. Makes sense, sort of; but it'd have to affect slashing/stabbing/lacerating weapons... Though, crushing weapons could be a thing; if we had a method of inflicting limb damage to make them black ('useless due to being broken, causing a person to limp or be unable to use their limb'.

Regarding the mixture of spaces and tabs in the code, and some slight variations on coding styles, etc.:

I think that, especially now that multiple people have started contributing to the project, we should establish a set of explicit rules, some kind of "IVAN coding standard / style guide", to help keep the codebase consistent and clean, as it was at the time of the original v0.50 release.

Regarding DJGPP, I agree that it clutters the graphics code a bit, but just last year I ran IVAN on my ancient computer with DOS (just for fun) and it actually worked. So I think it's a nice feature to have, and it would be a shame to just throw it away, even though nobody uses DOS on a daily basis. (Also it adds geek value.)

Awesome, thank you everyone for the contributions in the SDL 2 update.

My vote would be to go ahead with C++11 and drop DJGPP. It's a shame but as someone who writes PHP all day and sees the huge benefits of newer PHP versions, I can appreciate the need to update the code.

Regarding the mixture of spaces and tabs in the code, and some slight variations on coding styles, etc.:

I think that, especially now that multiple people have started contributing to the project, we should establish a set of explicit rules, some kind of "IVAN coding standard / style guide", to help keep the codebase consistent and clean, as it was at the time of the original v0.50 release.

Regarding DJGPP, I agree that it clutters the graphics code a bit, but just last year I ran IVAN on my ancient computer with DOS (just for fun) and it actually worked. So I think it's a nice feature to have, and it would be a shame to just throw it away, even though nobody uses DOS on a daily basis. (Also it adds geek value.)

I think it is a good idea to move on C++11, and I will support it. As to coding style, for starters is it ok if we stick to "BSD style", with two-space indentation?

Batman? wrote

its been so long since i had gotten that far i didnt think it through. arrrr!!!!!!

Yes, those, no tabs, and any other consistencies we can find in the original source code, off the top of my head:
* no braces for 'if's, 'while's, etc. if they contain only one statement
* no space between 'if', 'while', etc., and the following '('
* 'lowercasewithoutunderscores' for type names, 'PascalCase' for variable names
* no space between type name and '*' / '&' in variable declarations
* comments start with a capital letter

There are also some inconsistencies that we should probably fix. For example sometimes '&' and '|' have no space around them but there's also lots of code with spaces around them. I think they're more readable with spaces.

Maximum line width? There are some ridiculously long lines that don't really contribute to readability. Would something like 90 or 100 be good? With 90 I can fit two pages of code side by side in my editor which is really handy.

While these are really good for general (C++) programming style and best practices, they might clash with IVAN's existing style in some areas. To cover that we could make a minimal list of things that are "unique" to IVAN, and for all other more general stuff refer to some external coding standard.