all i’m saying is this:
what if i have super subs tech?
what if i am playing house rules where we have a new unit, called “partisan”, that is 3/2/1 and can do a first strike ON LAND, and we also have “spies” that cancel out the partisan’s special ability on land?
by doing it the “open” way, where you are attaching things separately from the name of the unit, you are allowed to put things in however you want
All this complexity is for odds calculation, so no manual intervention can be done. For simple rolling one need not include automatic hit assignment, and the problem could be much simplified and made to include arbitrary units (like self-defined ones).
Veqryn, an open system whereby you can add new rules via an input file of some sort again good idea but would require a complete rewrite as all the rules are no-doubt in code rather than in data. It’s realy far from trivial. Just a guess but I bet AACalc has 100s of manhours in it, perhaps 1000s when dealing with constraints/workaround of legacy solutions/code. I couldn’t even imagine how you would program a dynamic system whereby something like a partisan unit with first strike abilities and spies that would cancel it could be predicited and implemented. A unit property called ‘First strike’ and ‘First strike negation’ would have to be programmed for beforehand, then a runtime file containing a set of records comprising the list of units and unit abilities/stats could be then used. I just don’t see how runtime rules could easily be implemented. This coming from a guy who writes genetic learning algorithms……
well….
i prefer modular open-ended object oriented design to something closed off.
as far as attachments go, it is actually not that hard
TripleA uses attachments to units, so that I can do such things as calculate a battle between two-hit elephants vs spearmen, or against x-wings and the death star, not just axis and allies stuff
Objected-oriented design or not has nothing to do if the system is open or not, and I am not familiar with the term open-ended system other than when clients think the contract is open-ended and they can keep asking for free changes :-). If an elephant is going to be a 2 hit unit, the ‘property’ of having 2 hit points must be coded. Then facilities must be hard coded to allow units to have properties, how many properties? If the cardinality is greater than 1 then datastructures must be created to implement this and some hardcode to access this date must be created. If the hit point property were to be truly open, then you would have to hard code for N hit points and a field would have to be created and read by the program to determine if the unit has 1 or 5 or N hit points. It’s actually probably the way to go for a complete rewrite. You would have a static list of unit properties (again how could you write a program to deal with properties that are unknown at compile time) and a file that would describe a list of N units each of which has a set of properties ie, Name, Offense, Defense, Number of Hit points, Cost and then a pointer to a relator table to set up the Many to Many relationships between units and more unique properties such as first strike attack as in subs and partisans and first strike neutralization of subs and anti-partisans. Special coding would have to be there to handle AA guns, they would be treated more like a regular unit with a property called AA which in this case means the unit cannot be a casualty in the battle and has a first strike ability of sorts. This is all fairly doable, and from a clean sheet design would probably have been the way to go. Depending on how the data was represented it still might not be too difficult to retrofit onto the existing program.
Programmers almost never have the luxury of seeing what the program should finallly be in the end when doing the initial design work. Most often, we are given the task of creating a chevette, and over the years are instructed to constantly upgrade it towards being a corvette, had we been told to begin with we were going to build a corvette different design choices would have been initially used.
Now, how to handle dynamic rules or new properties…… That is the tricky part. How would you handle dynamically say a unit that reflects 20% of the hits in a battle back to the attacker? This property of damage reflection would never have been coded nor anticipated. In theory its simple, just add 20% of the attackers hits to the defenders return hits, but how to make a program do that when it was never design to do something like that?
while what you said is awesome,
i do think we can draw the line at a couple things. (at least for now)
things like reflecting hits back, etc, are not known properties. I’d say we can limit the engine to known properties (the properties that matter during combat that is)
this includes:
attack
defense
bombard
aa
air
sea
double dice rolls (heavy bomber)
double dice rolls pick the best of them (heavy bomber larry harris rules)
first strike (sub)
anti-first-strike (destroyer)
two hit
gives support (artillery)
supportable (infantry-like)
can not hit air (like sub)
can not be hit by air (like sub)
so… take all those properties, and apply them to:
x number of units rolling at 1
x number of units rolling at 2
x number of units rolling at 3
x number of units rolling at 4
x number of units rolling at 5
x number of units rolling at 6
and there you have basically what the engine should look like (and what triplea is already capable of doing).
hard-coding that there is something called submarine, and that is rolls at 2 attack and 1 defense is dumb.
what if i get super subs? what if i get larry harris super-subs?
what if it is a two-hit land elephant that attacks at 4 and defends at 5?
there are the properties I would code, and i don’t believe there are any more within the axis and allies world that apply to combat
Yup, that sounds pretty good. It would be sweet if the input file was text, say comma delimited for all the units and properties. A public template would be available, one could then modify it for house rules/new units etc. or even modify it for foreign languages for unit names.
I noticed that I made a change that stopped my modified version of AACalc from working a couple months ago.
This is back to working (with several exceptions previously listed still applying - ex. heavy bombers and battleships):
http://www.campusactivism.org/aacalc/
Gives great results for land battles.
Thanks to a patch from Greg Massaro, he fixed the bugs that I had with subs and battleships. So now both should work for the AA50 simulator: http://www.campusactivism.org/aacalc/
(Originally designed by Dan Rempel who did almost all of the work)
If there are any bugs, let me know.
I saw someone mention earlier about sub hits coming off first.
I believe a DD changes when a Sub fires. With one, a sub fires when everything else does.
So I think a defending sub would fire in surprise strike, but the attacker sub would fire with other units if the defenders have a DD.
Also in the opening fire phase, sub hits could be taken on defending subs that also fire, thus preventing a unit from not getting to fire if you have enough subs to cover the hits.
