Combat API and its use in a Player Run Tourney

• An attacker (Player1) arrives at a square, where there are 4 defenders (Player2, Player3, Player4 & Player5) on it.
  
  
• Player1 has set up his API key, using the checkboxes, to only reveal Data1 & Data2
• Player2 has set up his API key, using the checkboxes, to only reveal Data2, Data3 & Data4
• Player3 has set up his API key, using the checkboxes, to only reveal Data5
• Player4 doesn't care, and is sharing his full combat API key to reveal all pieces of Data1 thru Data5
• Player5 doesn't want anyone to know what happened in the combat, and has chosen not to share any data or APIkeys at all

SC,

Sorry for the delayed response to your post – but I’ve been attempting to be on holiday for the last few days J

All you say regarding in-game battle reports is, of course, true.  A participant in a battle gets a report (either complete or partial), and is able to share this with whomever they like by forwarding the report.

This is fine, and it translates into the ‘fantasy Illyriad universe’ quite well as “word of the battle spread far and wide” type stories.

The use of the current API in my mind changes this somewhat.

Firstly, it enables intelligence gathering to be done automatically, and at volume – this is easily then extended into automation that populates a large database of intelligence outside of the perimeters of Illyriad.  The action of sharing information then becomes less of a ‘role play’ thing – which essentially the game is – to a coding thing.  The owner of data also loses the ability to cherry pick which data to forward on to others, as the API gives access to all data.

Secondly, the use of the current Combat API for a player run tourney means that players must share this data with players outside of their alliance with whom they have probably had no previous dealings.  Your example of forwarding battle reports is generally done within the confines of an alliance – or more specifically, shared with specific leadership accounts within an alliance.  On the fewer occasions when reports are shared outside of an alliance, they tend to be on a battle by battle basis (see the first point above).

Thirdly, the current Combat API provides more information (or rather, the same information in more scenarios) than in-game battle reports do.  Currently, if I reinforce a square occupied by my Allies, Confeds or NAPs, I just get a report stating that my army has arrived, and the name of the player with the earliest occupying army.  However, using the API, I get an XML that details all of the armies on the square (including troop types and quantities) – i.e. you can scout without Scouts, even when the occupying armies have huge contingents of defending scouts themselves.  The same applies for reinforcing a city.

I am not saying that the current Combat API should be retired – I think there are a great many good uses for it.  What I am saying, is that for the specific use case of a player run tourney, the current Combat API is not suitable, and that we need an API specific to this use case.  This tourney API should not only be tourney square specific, but should also filter out some data elements so that it doesn’t become a tool for intelligence gathering via the coder’s back door.  It wouldn’t require a new XML schema – just an API policy or data masking rule on the existing schema.

C