Jump to content
Gasbow

Suggestion of version scheme for rules and Orbats

Recommended Posts

A recurring theme in discussions in these forums is the matter of small fixes of rules and typos in the orbat documents.

James mentioned the problem of finding a good pace to change the orbats without irritating or confusing the players.

 

 

How often should Orbats change? Issue new ones once a month, regardless of if they change or not? Or only when there are significant changes? If you issue new ones, then for people to stay up to date, they have to be downloaded, in many cases printed out.

 

Trying to find the happy medium here isn't easy.

(...)

James

 

This problem is very similar to the problem software developers face when developing and releasing updates and patches.

One has to be able to fix problems quickly but still keep an overview of the changes and make them transparent to users and other developers.

 

One way to do this is through a version scheme I am fond of using in software development.

Its called semver (http://semver.org).
It divides the version into three numbers: xx.yy.zz

xx marks so called breaking changes. In DW this means large rule changes that "break" old fleets in the sense that their statistics are simply not valid anymore.

The change from DW 1.1 to 2.0 is such a breaking change.

yy marks non-breaking changes. These changes change a particular artefact (one orbat file in DW) but leave the other statistics valid.

The new orbat documents for the larger factions have increased this number, while the minor factions are still at a lower version number but they can be used together.

zz marks bug fixes. These changes are just there to fix minor issues which where not meant to in version before.

These are fixing of typos, adding "attachment 1-3 naval" to escorts, when it was lost etc.

These changes should never change actual values of the orbats in play.

 

Using this version scheme, we currently have the CoA Orbat 2.03.0

(DW major Version 2, 3 minor changes to the orbat so far, no bugfixes since the last minor version change)

 

Using semver versioning would allow the developers to quickly fix small issues in the orbats without confusing the playerbase.

If I have a orbat 2.03.0 and a new file 2.03.01 is released, I immediately know that there will be no rule changes and only small fixes.

If this is the orbat of a faction I don't play, I don't need to check the new file even if I face the faction in play, as their statistics will still be the same.

Comparing two version numbers immediately tells what differences between one can expect.

 

If the orbat files are managed in a version management system (cvs, svn, git, choose your poison here) these numbers can even be managed automatically.

 

I believe this will make work easier for the developers and create a better experience for the players.

Link to comment
Share on other sites

It seems a lot of organisational issues in DW can be solved with Software Dev-inspired solutions (see also the change to MARs from very specific to argument based).

Perhaps Spartan should hire a software developer to assist with implementing these sorts of changes. I just so happen to be a software developer with some spare time on my hands...

 

But more seriously, I think it's a great idea, especially tracking bugfixes. I think Spartan also needs to implement the concept of a changelog, as hunting for what's changed in a new ORBAT does get a bit tiresome.

Link to comment
Share on other sites

I'm software developer too. One issue with developers and engineers in general is that if given them a chance they are never finished. Things can always be just that bit better.

At one moment in time you must stop and consider what ever you are working on finished. This should be the goal with current available ships. Don't mind an orbat update with new stuff of fixing something that is realy OP. But all those small changes to everything has to stop at one time.

What I realy don't like is changing a model so much it gets a whole new role/function. It might be balanced or even better, but when I buy a model I have a vision how I want to use it, how it fits in my fleet. After such an overhall it feels like a complete new miniature that I might not like or have a use for.

The Diophantus f.e. has gone from Large to Dreadnougt. In our club we don't use dreadnoughts and most tournaments I have visited they aren't allowed either. You can argue about this, but bottom line this model is not the same as the one I bought.

Link to comment
Share on other sites

@typhs

That is exactly what this idea is about.

It allows the rules team to make these amendments without the need to make a full fledged rules update.

 

 

 

It seems a lot of organisational issues in DW can be solved with Software Dev-inspired solutions

I wholeheartedly agree.

In my dreams, the Orbats are maintained as xml or json files in git and the orbat pdfs are generated automatically as soon as a new revision is pushed. The xml or json files could then be used by the army builder and other tools, which would then be up to date automatically and relieve nucreum of the annoying task to update his files by hand.

Link to comment
Share on other sites

In my dreams, the Orbats are maintained as xml or json files in git and the orbat pdfs are generated automatically as soon as a new revision is pushed. The xml or json files could then be used by the army builder and other tools, which would then be up to date automatically and relieve nucreum of the annoying task to update his files by hand.

 

I want this. I didn't know I did, but now I do. Git repositories are a criminally underused resource in tabletop gaming.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.