Veqryn you have some good ideas but there are some problems. Not all 3’s or 1’s are the same when it comes to automated order of losses. For a navy battle, you’d like to assign 2 hits to the 2 battleships right away to those 4s are different from the fighters 4 on defense. When attacking peal harbour you might want the second hit on the third fighter rather than the sub as the extra fighter cannot stay, whereas the sub can. (the first hit on the battleship). The rules have to be hardcoded. You could in theory create a generic engine that would accept a dynamic run-time file containing all the rules and values. It would be completely open and would be awesome. It would also add so much more complexity and be a complete rewrite.
Any system that can be written on paper can be coded into a program that is the easy part. Exhaustively and thoroughly documenting every rule, scenario and exception and what course of action to take for each is actually the hard part.
For simplicity I would consider “ignoring” some naval special situations. What I mean is, it doesn’t seem essential for subs/dds to work in terms of determining an OOL for a correct simulation. First and foremost naval battles can be tough for humans to work out considering OOLs can be real screwy and are so game/strategy dependent.
I would suggest a simple default OOL, with no special circumstances taken into account for the battles.
IE: sub, dd, ac, ca, ftr, bom (if attacking), bb.
Which is based soley on best defensive roll. Afterall if you are using the calc, most of the time you want to see “what happens if I fight to the death” and any time you do this you should be assuming your opponent isn’t an idiot and will use the best defenders possible. In terms of the sim it really doesn’t matter if you remove a DD before an AC if attacking subs are left b/c they both defend at 2.
I think it is safe to assume any human player that goes through the trouble of finding and using the AACalc, will know that you need a dd to negate the subs first strike etc.
You can also run the battle one round at a time and manually remove the losses as you see fit, if you want to try and see different scenerios play out. But you could get an overall look at odds and see what happens if you stay till the end of battle and your opponent always kept his best defenders.
I would think a Disclaimer like this might work:
“For Naval battles AACalc assumes no special abilities and uses a default OOL of lowest defender to highest. For more detailed results that take special abilities into account run the battle one round at a time and manually remove the units you see fit before proceeding to the next rd of battle.”
Again, I think A&A players are pretty smart when we work out when to attack or not attack at sea and how we take losses, so I don’t think it is necessary to go through an immense amount of trouble trying to code for the crazyness of naval battles. IMO, you only need a ball park figure. And if you are counting on your opponent to make poor OOL choices then I don’t think you’ll need AACalc to help you win the game.
I’d keep all slots for units, but the only thing I’d code would be the Inf + RT connection. Everything else the player can pretty much do.
Edit:
Oops, I’d also account for 2-hit BBs if that wasn’t assumed in my post. So OOL would be:
1 hit BB, sub, dd, ac, ca, ftr, bb
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.
