"Do you log your changes." Topic

Since our issue 2 we have begun logging on a separate sheet any changes/amendments we have made to the initial release. These changes have not been published, a discreet time interval is useful as it allows us to make sure that in amending the rules even very slightly, we do not cause problems elsewhere. Many are at the very fringes, rare cases where lack of definition begins to show up.

How come we are adding changes 15 years on, well we still find the odd typo, or situations we had never dreamed of crop up.

Just as an example of one of the latest.

Note added to Fast Mode -
NOTE – In extremis an element reaching it's target in the second phase can instead of remaining in Fast Mode, take a suppression immediately on achieving the target. An example could be achieving a crater to be used as cover. The troops leap/tumble in, in disorder but are immediately in the cover of the crater in Halt mode.

The reason this happened is for the first time EVER (and its 15 years on) we actually put large shell craters on the table capable of being used as cover. The US had intended to bomb the Normandy beaches to create this type of crater (they misses alas).

To be fair there are lots of anecdotes of folk leaping into some form of shelter, one I recall even into a latrine pit! Other leaping into a pit already occupied and landing on the current occupants. So as not to "break" the current system and make it "credible" for us we added this ruling. Basically it means that there will be a 1/2 move(ish) delay before the element begins functioning effectively.

Now for some this may seem too complex, but for us it had to come in. Without it you got a result which was illogical and wholly unsatisfactory, spoiling the fun. Without credibility a game to us is unplayable.

I just save as a different version during development.

If you really want to track all changes you can use a version control system like they do in software development which tracks every change in a file, eg a system called 'git' is popular.

You can create a repository in the git cloud, control who has access to it, work on local copies and commit updates to the cloud version including having different branches (versions) of the source.

You can also just have git locally and track changes on a local folder.

But that might be a bit over-the-top for what you want?

Just an idea.

B

I just track document changes, although I do have major and minor release numbers etc. Sometimes I fork off a different branch (to use git terminology).

Basically I let the software do the work.

I worked in IT for decades so I'm used to version management.

I write my rules using the case system. A system similar to military manuals and SPI rules. It makes it easier to edit and record the changes.

I self-published a set of Army Men rules from 1998-2007. My first version would not fit into the printed format I was using, so I broke it into two separate booklets, even though they were really the same game, just that the first book was a simpler, less complex version. Later on, I re-wrote the two, into one booklet, stripping out the scenarios, which took up around 20 pages -- I moved these to my long-gone website, for free.

I started working on revising it again, one last time. However, this time around, I will be publishing it on a POD service, so I will no longer be limited to 96, 5.5" x 8.5", pages, as before, when I was hand-assembling the booklets; I will be able to include everything in one book, including all of the scenarios from the past versions.

Each version/booklet has had a different sub-title. Other than that, no, I do not keep track of versions by numbers, such as: 1.0, 1.5, 2.0, 2.2, etc. I do not use any sort of tracking system for my edits, either. I am too much old-school for that. ;-) Cheers!

The problem with the sort of rule UsCha talks about is not that it is complex, it is that after a while there are lots of these little special rules, and the rules become big, and it is very hard to remember all the special rules in the heat of the action, and probably impossible if you are not playing with the author.
It is always much easier to add a rule than to take one out; the art of rule writing is to take out as much as possible, but not too much.

Saved separately, usually with date of change in the title.

I update two technical manuals I wrote, beginning in 2017, every couple of weeks, at my job. I began listing the Last Updated: date, on the cover page, years ago. That is as far as I go with it, professionally, as well as personally. The technical processes documented in my manuals, change every couple of weeks/months, and due to how complex the system documented within them is, I need accuracy as to how it works today -- I don't care how it worked last week, I only care about how it works now… Cheers!

Dexter Ward – You are correct – However our aim is in general NOT to add rules. That way madness lies. The trick is to write a better rule, that is more precise in its definition and ideally in less words than the original.
In truth in some cases the log are also designers notes so we can check over time the rule was an improvement. To many "special rules" in our experience makes things worse, it improves one specific but can have adverse impacts elsewhere.

Sgt Slag I wish, sometimes you need to know in the real world what was changed and when for legal reasons. Hence when I had a "proprr job" I'm retired now, more detail was required, Now with an ageing brain some reminders of what we did in the past, makes sure we don't screw up in the future.

Yes, we write them down, type them up, put them in a notebook, and post them to our io group.

We raise tickets in Jira, document stories and the system in general in confluence. Track changes in gitlab via Merge Requests linked to tickets.
For my day job building the back end for high throughput low latency sports book (betting) software.

For games software, which is a side gig. I wrote up a change log in a forum so people could see what was happening. Software development is much slower than most people expect.

If I was doing commercial rules I think I'd use git in azure DevOps as a repo. And write up a change log.

For home brew games.
I keep a rough list of things we tried, thought of and effects.