Combat API and its use in a Player Run Tourney

Digioso/SC,

 

That XML looks fine.

I would suggest that battle casualties are per side rather than for the battle as a whole – this would make reporting on the tournament more meaningful.

One observation though, the <personalcombatkey id> will need to have a different value to that returned from the current ‘combatreportsapi’ API, otherwise it would be possible to obtain the <personalcombatkey id> via the new tournament version of ‘combatreportsapi’ and then feed it into the existing ‘combatreport’ API and get the full data set.

(X,Y) co-ords from the first API is a good idea, as it will mean you do not have to execute the detailed process for squares you are not interested in (e.g. if someone in the future just wants to run a BL tourney)

 

C

So far that's the list I need. :D

Hmm... that's a good question.

Can you put a 0 (attacker wins) in there if there is no defense (= square was onuccupied)?
And a 2 (no winner) if the new army is sent as a reinforcement?

Then I can do:
If winner == 2
    if casualties == 0
            army must be a reinforcement
    else
            a battle took part but both sides survived. In our case that means that the defender is still holding the square.

My suggestion would be this:

For the combat report overview (API-Key):
<combateventsapi>
    <server>
        <datagenerationdatetime></datagenerationdatetime>
    </server>
    <player id=""/>
    <playerapikey id=""/>
    <combatevents>
        <uniquecombatidentifier>
            <server id=""/>
            <combatguid id=""/>
            <troopmovementevent id=""/>
            <datacomplete id=""/>
            <personalcombatkey id=""/>
            <combatoccurrencedate></combatoccurrencedate>
        </uniquecombatidentifier>
    </combatevents>
</combateventsapi>

Here it would also be nice if you could include the X/Y coordinates as well. Not only for the tournament API but for the normal API as well.
If a tournament only happens on specific squares we can skip reading unneccessary reports.
For the tournament API this doesn't really matter because it'll only provide reports for tournament squares. But it would be nice to have for the normal API.

Fot the specific combat report:
<combatevent>
    <server>
        <datagenerationdatetime></datagenerationdatetime>
    </server>
    <personalcombatkey id=""/>
    <uniquecombatidentifier>
        <server id=""/>
        <combatguid id=""/>
        <troopmovementevent id="" occurrence_datetime=""/
        <datacomplete id=""/>
    </uniquecombatidentifier>
    <combatoverview>
        <location>
        <X></X>
        <Y></Y>
        <terrainspecifictype id=""></terrainspecifictype>
        <terraincombattype id=""></terraincombattype>
    </location>
    <datetime>
        <combatoccurrencedate></combatoccurrencedate>
        <occupationlengthsecs></occupationlengthsecs>
    </datetime>
    <stratagem>
        <armyaction id=""></armyaction>
        <feint>Yes/No</feint>
    </stratagem>
    <participants>
        <participant>
            <role></role>
            <player>
                <playername id=""></playername>
                <alliance id="">
                    <allianceticker></allianceticker>
                    <alliancename></alliancename>
                </alliance>
            </player>
        </participant>
    </participants>
</combatevent>
   
Either: total casualties for the whole battle or casualties per side:
EG Defender(s) lost x troops and Attackers lost x troops

And we need to have an identifier which side is left standing after the battle.
<winner></winner>
EG:
0 = Attacker
1 = Defender(s)
2 = Both are left (EG after a raid)

The meaningful frank exchange of views gives me hope that an acceptable solution will be taken care of.  Hopefully this will herald an increasingly broader concept of "community" with the user base becoming increasingly involved in direction and development.  I think that, at present, the Illyriad gaming model requires changes to increase its stability, and these events give me hope that they will be addressed.  It is ultimately all about keeping customers happy and loyal by communicating with them and involving them.  Fingers crossed Eh? 

I agree the the data should not be so limited that the key will only work for this type of tournament.