combat support

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

combat support

squid_daddy
This post was updated on .
#UPDATE jan 3
----------------------------------------------------------------------
Functional code submitted, not yet commited.
completely backwards compatible
functions for dice rolling and battlemap (and therefore battlecalculator too)
however as yet does not include AI support
(AI's will not be invalid, their methods simply will not take new support into account)

Implementation subject to change in the future, (as it is shit and I hate it) however
Usage as follows.
<attatchment name="supportAttachment1" attatchTo="artillery" javaClass="games.strategy.triplea.attatchments.UnitSupportAttachment" type="unitType">
                         <option name="unitType" value="infantry"/>
                         <option name="faction" value="allied"/>
                         <option name="side" value="offence"/>
                         <option name="dice" value="strength"/>
                         <option name="bonus" value="1"/>
                         <option name="number" value="1"/>
                         <option name="bonusType" value="arty"/>
                         <option name="player" value="Russians"/>
                         <option name="impArtTech" value="false"/>
                    </attatchment>


*<attatchment name="supportAttachment1" attatchTo="artillery"
name must start with supportAttachment and must be unique
attachTo is the unit doing the supporting

*<option name="unitType" value="infantry"/>
the unit to be supported, may be a list, i.e. "infantry:tank:fighter"

*<option name="faction" value="allied"/>
values = allied or enemy.
not implemented (i.e. only allies may be supported)
may be a list

*<option name="side" value="offence"/>
values = offence, defence
support when defending or attacking
may be a list

*<option name="dice" value="strength"/>
values = strength or rolls
not implemented (only strength is affected)
may be a list

*<option name="bonus" value="1"/>
how much to add to the roll
 
*<option name="number" value="1"/>
how many units to support
                       
*<option name="bonusType" value="arty"/>
any string, identifies bonuses as being of the same type, and therefore not stackable
name all grouped bonuses the same
                         
*<option name="player" value="Russians"/>
values are valid player names, restricts bonus to this player
entirely optional, don't include if you want bonus to affect everyone
may not be list as of right now.
                         
*<option name="impArtTech" value="false"/>
whether of not this bonus is doubled by the improvedartillery technology.

----------------------------------------------------------------------
begun work on more general supporting code.
patch is up with first step ( xml support )

current plan is to implement:
any unit type may support any unit type
may support more than 1 type of unit
may support any number of units
support on defence or offence
support either rolls or pips
may support by any value

if anyone has a compelling reason to include other cases let me know
such as hits, movement, effects outside of combat etc.

with such you may have tanks support planes...if you so choose.
but otherwise some nice idea for usage could be.
defensive structures (bunker) helping infantry.
equipment for smaller scale game, for example a "machinegun" unit that improves infantry.
Reply | Threaded
Open this post in threaded view
|

Re: combat support

Veqryn
Administrator
1. we need the ability for 1 unit to give another unit an ability (like tanks giving mechanized infantry the BLITZ ability)

2. we need to specifically support the 1940 rules set (pacific 1940, europe 1940, and global 1940)

so for example, in 1940, there are two interesting cases:
tanks give mechanized_infantry the blitz ability (on a one-to-one basis), but only if they move with the tank (same route)

tanks and fighters give attack support to tactical_bombers, on a one to one basis.


i really look forward to this addition.... but it will play hell with all the battle calcs, AI's, casualty pickers, etc... it could be a lot of work

good luck,
veqryn
Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: combat support

squid_daddy
ok cool, i've only briefly glanced at those new rules.
i'll see about folding that blitz ability in too. willing to bet that will be a pain in the ass.

the only critical case (dice rolling) will be fairly easy.
tracking down all that other stuff will require some effort though sadly.

if there are any other specific cases you can think of that need to be supported let me know.
don't assume i'm familiar with all the maps people want to make. (cos i'm not ) :)
Reply | Threaded
Open this post in threaded view
|

Re: combat support

Ajmdemen
Why would battle-calculator be affected if it only simulates (not calculates) the result probabilities?

About AI - couldn't it be programmed to actually use the bcalculator and base its decisions on it (in some part at least)?
Reply | Threaded
Open this post in threaded view
|

Re: combat support

Pulicat
In reply to this post by squid_daddy
Great and noble project squid_daddy.

What about bonuses and penalty options for your own, your allies, AND your enemies units?

For example, a "tank obstacle" unit that reduces enemy tank's attack during battle rather than increases your own defense.

or, "anti-tank artillery" that decreases enemy tank's defense when YOU attack THEM

or, trench and bunker units that can increase defense not just for your own units but also for allied units in the same territory

or, an "inefficient mix" of units actually reducing your attack or defense

The more flexibility for modders, the better :)

puli
how now brown cow?
Reply | Threaded
Open this post in threaded view
|

Re: combat support

hepster
In reply to this post by squid_daddy
I like where this is going!  Good luck.
“A man can never have too much red wine, too many books, or too much ammunition”― Rudyard Kipling
Reply | Threaded
Open this post in threaded view
|

Re: combat support

ComradeKev
Administrator
In reply to this post by Pulicat
Basically, we need to break it down to its component parts.  Here's a 1 minute start after just considering the examples in this thread:

Buff Type (attack, defense, movement, hits)
Buff Unit (unit receiving buff)
Buff Effects (number of Buff Units affected)
Buff Value (+/- type)
Buff Target ( or something like that to denote Allied or Enemy units)


From that, we could build a table of buffs for a battle or movement and check against it for any units receiving the buffs.

If it's put together in such a way that the items are a delimited list (similar to Nat'l Objectives), then we can support multiple Buffs per unit.  That is to say, a single unit could buff multiple other unit types.
If emailing me at ComradeKev at yahoo.com , please add TripleA to the subject line
Reply | Threaded
Open this post in threaded view
|

Re: combat support

squid_daddy
In reply to this post by Pulicat
@publicat
I thought about tank traps too, i'll put in negatives and enemy effects if you think it'll be useful

@kev
plan to use a new wrapper class. SupportRule say.
patch modifys the parser to read move values into attachment options.
so delimited list is not necessary.

Reply | Threaded
Open this post in threaded view
|

Re: combat support

hepster
Holy Latin!  Go gettem guys!
“A man can never have too much red wine, too many books, or too much ammunition”― Rudyard Kipling
Reply | Threaded
Open this post in threaded view
|

Re: combat support

squid_daddy
In reply to this post by squid_daddy
not finished yet, but posted a patch for anyone who cares to look at how i'm implementing this.
now would be a good time to complain ;)
will work in simple case (i.e. current artillery rule, only normal luck diceroller )

here is the xml syntax

<attatchment name="supportAttachment1" attatchTo="armour" javaClass="games.strategy.triplea.attatchments.UnitSupportAttachment" type="unitType">
                         <option name="unitType" value="fighter"/>
                         <option name="faction" value="owned"/>
                         <option name="side" value="offence"/>
                         <option name="dice" value="strength"/>
                         <option name="bonus" value="1"/>
                         <option name="number" value="1"/>
                    </attatchment>

this makes armour support fighter

*faction can be owned,enemy or allies
*side can be offence or defence
*dice can be strength or rolls
bonus how much to add
number how many can it support
*=not implemented

the string fields can be delineated lists like "offence:defence"  (not implemented for unittype yet)
comments regarding this welcome.

Edit: further thought
maybe It should be implemented as a rule, using sets of units.
that way you could map multiple supporters to multiple supportees.
i.e plane+tank could give +1 to infantry for example.
anyone think this would be useful?



Reply | Threaded
Open this post in threaded view
|

Re: combat support

Veqryn
Administrator
f-ing awesome

with this and kev's work on scrambling, i will be in heaven

Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: combat support

ComradeKev
Administrator
In reply to this post by squid_daddy
"squid_daddy wrote
*side can be offence or defence
spellcheck - Offense/Defense
It might also be good to be able to limit to a particular (or group) of players.... for example, Germans had the Stutka and so should benefit from the tank/fighter bonus, but the Japanese (for example) didn't have much in the way of a attack fighter (that I know of- it's just an example in any event).

It'd also be nice if you could check into how we might do away with having to ennumerate the attachments.  I threw that together in a rush to get the Nat'l Objectives working, but it's less than optimal.  If you can figure it out- GREAT!  If not- no biggie.

Make sense?
If emailing me at ComradeKev at yahoo.com , please add TripleA to the subject line
Reply | Threaded
Open this post in threaded view
|

Re: combat support

squid_daddy
spellcheck passed. I'm not american. I only speak english english, well kiwi english actually but its mostly the same.

I can add player specific check. thats easily done.
alliance too.

actually I thought your solution to add nat'l objs was neat.
you could use instanceof couldn't you?

if( attachment instanceof RulesAttachment )
and thus name the attachments whatever you like.

otherwise you are always free to declare your own totally new entry in the xml
rather than use attachment. the parser and dtd are very simple now I've looked at them.
which is what I might do eventually. want to get this fully functional first.

---
A question to all about supporting units.
my current plan is to implement multiple bonuses on a first come first served basis.
for example

suppose tanks/arty give +1 to 1 infantry, and razorwire gives -1.
if you had
3 tanks
2 arty
5 infantry
1 razorwire

1st infantry gets +1+1-1
2nd gets +1+1
3rd gets +1
4-5 normal

anyone have issue with that?
Reply | Threaded
Open this post in threaded view
|

Re: combat support

ComradeKev
Administrator
squid_daddy wrote
my current plan is to implement multiple bonuses on a first come first served basis.
for example

suppose tanks/arty give +1 to 1 infantry, and razorwire gives -1.
if you had
3 tanks
2 arty
5 infantry
1 razorwire

1st infantry gets +1+1-1
2nd gets +1+1
3rd gets +1
4-5 normal
Now you've done it!  The statistics police are gonna come running now.

That actually looks fine to me, but others might have different ideas.
If emailing me at ComradeKev at yahoo.com , please add TripleA to the subject line
Reply | Threaded
Open this post in threaded view
|

Re: combat support

Veqryn
Administrator
In reply to this post by squid_daddy
We need to specify somewhere IF the bonuses are allowed to Stack.

what I mean is this:

Right now, the way most people understand the rules, and the way artillery is currently coded, you can have this situation:

1 big artillery.  it gives +1 to two supportable units
1 little artillery.  it gives +1 to one supportable unit

5 infantry. can receive support

end result:
3 infantry get +1
2 infantry is normal

However, you are suggesting this:
1 infantry gets +2
1 infantry gets +1
3 infantry are normal


I think that things should not stack like that,
but i think it would be even better to be able to choose which things stacked and which ones get spread out.

perhaps just an optional attachment within your wrapper, called "level"
if not present, it defaults to level 0
everything on a level gets spread out
but levels themselves get stacked


so if you had this situation:
1 big artillery.  it gives +1 to two supportable units (level zero)
1 little artillery.  it gives +1 to one supportable unit (level zero)
chuck norris' artillery. it gives +2 to one supportable unit (level one)
5 infantry. can receive support

end result:
3 infantry get +1 (little and big artilleries here)
1 infantry gets +2 (chuck norris artillery here)
1 infantry is normal

as you can see, the support will pick units that have not yet been supported FIRST


but if you have this situation:

1 big artillery.  it gives +1 to two supportable units (level zero)
1 little artillery.  it gives +1 to one supportable unit (level zero)
chuck norris' artillery. it gives +2 to one supportable unit (level one)
3 infantry. can receive support

the result is:
2 infantry get +1 (big artillery)
1 infantry gets +3 (little artillery + chuck norris artillery)


now, this is completely different from a situation where all the artillery are on the same level, like so:

1 big artillery.  it gives +1 to two supportable units (level zero)
1 little artillery.  it gives +1 to one supportable unit (level zero)
chuck norris' artillery. it gives +2 to one supportable unit (level zero)
3 infantry. can receive support

the result is:
1 infantry gets +2
2 infantry get +1
(and one +1 gets wasted, because there aren't enough infantry)




next, to deal with things that give negative bonuses:
I would say that anything giving a Positive bonus, will choose to give the bonus first to the unit with the lowest current value.  
Anything giving a negative bonus, will choose first to give that negative bonus the unit with the highest current value.

So, if you have:

1 big artillery.  it gives +1 to two supportable units (level zero)
1 little artillery.  it gives +1 to one supportable unit (level zero)
chuck norris' artillery. it gives +2 to one supportable unit (level zero)
razor wire.   it gives -1 to one supportable
4 infantry. can receive support

end result:
3 infantry get +1
1 infantry is normal

this is because, 1 infantry is getting the bonus from chuck norris artillery, so it is +2 bonus.  this makes it the highest value unit, so the razor wire chooses to affect it first, reducing the bonus to just +1.


squid, i hope this makes sense....


so, to use your example:
suppose tanks/arty give +1 to 1 infantry, and razorwire gives -1. (all level zero)
if you had
3 tanks
2 arty
5 infantry
1 razorwire

1st infantry gets +1 -1 = +0
2nd gets +1
3rd gets +1
4th gets +1
5th gets +1

(this is currently how the engine works, and how axis and allies rules are, and I think we should aim to keep it that way)

thx,
veqryn
Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: combat support

squid_daddy
ok non-stackable bonuses, can do. I hadn't considered little/big artillery.

problem I have with what you are saying is things get very messy when you start to try to make best case decisions. especially if negative modifiers are present.

the order you apply modifiers becomes important.
consider
1 arty +1
1 infantry att=1
1 elite infantry att =2
it is more beneficial to add to the elite

however if we add
1 razorwire -3
it becomes more beneficial to add to the infantry
from the point of view of the attack, oposite for the defender.
or similar mixed cases where the strengths of units may go above 6 or below 1.
dealing with this means that to find the strength of any one unit you need to consider
the _possible_ strength of all other units.
and to be honest. i'm mostly keen to just support the most simple cases.
If a map builder wants to make units with wacked out values. then the results be on their
heads.

So I'd rather enforce a simple ordering, and avoid iterating through lists of units a dozen times.
so how about I apply bonuses in order of the bonus given.
and apply to units in ascending strength values.

so
1 big artillery supports 2 at +1 (arty bonus)
1 artillery supports 1 at +1 (arty bonus)
1 Orbital Mass Driver Platform(tm) supports 1 at +3 (arty bonus)
1 tank supports 1 at +1 {combined arms}
1 razorwire supports 1 at -1 {ouchie bonus)
1 LazE  E Beam(tm) supports 1 at -2 {ouchie bonus}
6 infantry

yields
1: +3-2+1 (arty,razor,tank)
2: +1-1
3: +1
4: +1
5: +1
6: 0

this means large negative effects may be wasted.
but I'm happy with that. after all would you throw your conscripts into the razorwire or your elites?
it also means large numbers of different bonuses may be wasted.
I'm also happy with this, it shouldn't occur often.
Reply | Threaded
Open this post in threaded view
|

Re: combat support

squid_daddy
also
                        if (isFirstTurnLimitedRoll(player))
                        {
                            strength = Math.min(1, strength);
                        }

this is intended to set defender strength to 1 under certain circumstances.
how to we want this to interact with bonuses?
add bonuses or leave values at 1?
should we apply negatives but not positives perhaps?
Reply | Threaded
Open this post in threaded view
|

Re: combat support

Veqryn
Administrator
In reply to this post by squid_daddy
ok,
so if i understand you correctly, you are saying this:

1) sort bonuses into 2 categories, positive and negative

2) sort the bonuses in Descending Order (of absolute value)
so, you have would have 2 sets:
[+3, +1, +1, +1, +1] and [-2, -1]

3) sort the units that can receive those bonuses into Ascending Order
so, it would look like [infantry, elites, mega-elites, chuck norris]

4) apply bonuses

5) make sure nothing goes below Zero, or above 6

and you are done.


Also,
By Default, you can't have more than 1 positive bonus and 1 negative bonus being applied to a unit.

if this is what you are saying, i agree.




@ squid:
                        if (isFirstTurnLimitedRoll(player))
                        {
                            strength = Math.min(1, strength);
                        }
only applies to the Original Pacific a&a scenario.
I would say, since only 1 map uses this, that you can do whichever way you feel is easier to code,
since both kind of make sense
Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
Reply | Threaded
Open this post in threaded view
|

Re: combat support

squid_daddy
well put, thats not quite what I said, but i'd be happy to do that.
I wasn't planning to restrict units to one bonus only.
so it would be possible to have lists like
 [+3, +1, +1, +1, +1] , [-2, -1] , [+1], [+1, +1]
suppose 1 list is an artillery bonus.
1 is defensive structures.
1 is a bonus for riding a tank.
1 is a bonus for having green facepaint.

if the map designer desired for lets say tank riding, and green facepaint to be the same thing
they could do that instead. resulting in
[+3, +1, +1, +1, +1] , [-2, -1] , [+1,+1,+1]
Reply | Threaded
Open this post in threaded view
|

Re: combat support

Veqryn
Administrator
well thats what i meant by having levels

your examples:
 [+3, +1, +1, +1, +1] , [-2, -1] , [+1], [+1, +1]

really means:
level zero positive: [+3, +1, +1, +1, +1]
level one positive: [+1]
level two positive: [+1, +1]

level zero negative: [-2, -1]


as i said above, the default behavior Unless specifically specified, is to keep everything on one level (ie: nothing stacks, unless specified)

so ya, i think we are on the same page and agree

looking forward to it :)
veq
Please contribute to the TripleA 2013 donation drive:
http://tripleadev.1671093.n2.nabble.com/2013-TripleA-Donation-Drive-tp7583455.html
123