Combat API and its use in a Player Run Tourney |
Post Reply | Page <1 678910 11> |
Author | |||
Brandmeister
Postmaster General Joined: 12 Oct 2012 Location: Laoshin Status: Offline Points: 2396 |
Post Options
Thanks(2)
|
||
I know that people on this thread have good intentions, but I just find myself shaking my head.
An API is just a messaging interface between two architectural layers, with the added wrinkle that the programmatic interface has been made public. The developers are just allowing people a direct web access to their own complete battle report XML files. The addition of the encryption key is what allows players to identify they are a particular account owner to the system. By extension, this allows them to grant others access to their complete battle report XML files stored on the Illyriad servers. Any request at a filtered API is a lot of additional extra work. What some of you are requesting is a user-configurable filter layer between the internal system battle report XML interface (which delivers a mail to your inbox) and the external API interface. That is not a trivial request. Right now the devs just give you the same basic data as your battle report. That's simple and maintainable. The filtering request is also pointless. There are two points of potential spying: the person running the tournament, and your fellow alliance mates. Frankly, if you can't trust the person running the tournament, then why are you even participating? As for spies among your alliance mates sharing battle report information, they don't need an automated battle report API to accomplish that. Web-based collection makes it easier, but accumulating the information is trivial regardless. Again, if you can't trust your own allies to not publish alliance troop numbers, maybe you should reconsider your choice of allies. |
|||
Gragnog
Postmaster Joined: 28 Nov 2011 Status: Offline Points: 598 |
Post Options
Thanks(1)
|
||
The easiest solution to this whole issue is the devs start to introduce tournaments again and stop trying to rely on a few really passionate players to keep their game alive. With all the data issues involved I am surprised that those players even bother. Thumbs up for Koda and his team and thumbs down for the devs in letting it get to this situation. Regular tournaments would have never let this moaning session arrise.
|
|||
Kaggen is my human half
|
|||
Luffster
New Poster Joined: 11 Feb 2015 Status: Offline Points: 5 |
Post Options
Thanks(0)
|
||
Gragnog I totally agree! Cheers Luffy |
|||
TheBillPN
Forum Warrior Joined: 03 Jun 2014 Location: England Status: Offline Points: 305 |
Post Options
Thanks(0)
|
||
My post 4 pages ago:
Another post:
Totally agreed as well.
|
|||
Digioso
Forum Warrior Joined: 09 Feb 2015 Location: Germany Status: Offline Points: 312 |
Post Options
Thanks(0)
|
||
To add a bit on this.
Especially Rills last posting. @SC: My tournament script can only look at one type of key for each tournament. So let's say there's a new tournament API that only has a limited amount of info. We decide that we want to use this. That means we'll only get API keys for this. So in that case we don't know any of the FULL-Combat-API-Keys and cannot query them. Whether a participant shares his FULL combat key with someone else or not is of no concern for the tournament in this case. This would fix the issue that the tournament administrator knows information that he does not need to run the tournament. In our case: Attacker, Defenders, Occupation Time in secs, Fake Attack yes/no, Combat occurance date and who is the winner of the battle. The latter could be a simple boolean: Attacker has units left yes/no - Defenders have units left yes/no. My script does nothing else to determine the winner of the battle. 0 = Defender lost everything 1 = Attacker lost everything 2= Both have units left (EG when the attack is a raid) Yeah I have three values so it's not a boolean, but... blah. :P This would address the trust concerns that data about army sizes gets leaked by the tournament administrator or may be used by the tournament administrator in the future in case his alliance engages against another. Because the admin only knows who attacked and who won. |
|||
Cilcain
Wordsmith Joined: 13 Oct 2012 Status: Offline Points: 106 |
Post Options
Thanks(1)
|
||
SC,
You have mentioned a couple of times that the current Combat
API has been in use since 2010, and infer “what’s the fuss about?” Well, the fuss is due to the fact, that all players on the
server are now being asked to provide their API key to a peer – this as far as
I know is unprecedented. Yes, Alliances
(and possibly Confeds) have shared keys in the past, but that was for
completely different reasons – for which the existing API is suitable. All players now face the option of sharing all their data
(automatically and without discretion) with a peer, or to continue in the
drought of “regular Tournaments” [ http://www.illyriad.co.uk/GameInformation/Military ],
which until now (and I use the word “now” loosely) have been run by Devs and
not players. I have always maintained that a Tourney API could co-exist
with the current Combat API – I have never suggested retiring it – and therefore,
I am not wishing to impose anything on anyone. A tourney organiser could quite happily say that they will
accept either API key to run a tourney – as both would have the required data
(it’s just one would have additional data unnecessary to the tournament). But I bet, if players were given this option,
most would go for the Tourney API. Yes, there would always be some cases where the effects of
the Tourney API in a battle are overridden by the presence of the Combat API in
the same battle – but if most people in the tourney are using the Tourney API,
then the volume and completeness of data from the Combat API will reduce such
that it becomes less viable to use for unintended purposes. Also, in one of your posts, you may have inadvertently given
the impression that throughout this thread, I have been arguing for the ‘checkbox
API’ option – it should be clear to anyone reading this thread that I have
not. It was, I agree, one of a number of
initial ideas you and I discussed, but was quickly shelved. I am happy to quote from our convo if
necessary and with your permission. I must go now, as I have an update meeting with my
development team for them to demo the suite of B2B APIs they have developed
this week. Regards, C |
|||
BARQ
Greenhorn Joined: 06 Oct 2015 Location: in Death Status: Offline Points: 77 |
Post Options
Thanks(0)
|
||
stop shouting on API thing and ask devs for regular dev run tourneis . u'll enjoy tournaments without giving anyone ur API key prob solved
|
|||
I m the most scarring dream of your life
|
|||
Mahaut
Wordsmith Joined: 20 Jan 2012 Location: North West UK Status: Offline Points: 173 |
Post Options
Thanks(2)
|
||
Strangely Barq, thats been tried. In spite of their own blurb saying "regular tournaments" (screenshotted by the way) apparently "regular" means once every two to three years if we're lucky.
In general I think a lot of players would like to see the devs returning to the game to run tournies like they used to. I know I would. We're currently fighting a rear guard action here to try to get player run tournies as secure as possible.
|
|||
|
|||
GM Stormcrow
Moderator Group GM Joined: 23 Feb 2010 Location: Illyria Status: Offline Points: 3926 |
Post Options
Thanks(0)
|
||
Hi everyone,
I suggest people read all the way through before hitting reply!
I think I've made it clear that I believe this position is illogical enough times not to have to do it again :)
Sadly we don't permit the publication of conversations with the dev team. I certainly acknowledge you requested this feature, we discussed it and shelved it. However, I do hope you will agree that the system you *are* requesting (a limited dataset to coexist with a full dataset) is functionally and logically the same as a checkbox system. At most, the minor semantic difference between the two is that the fixed-dataset limited key system is a radio button (coexisting with the full dataset) rather than a flexible-dataset checkbox system (also coexisting with the full dataset). The point is that the issues associated with implementing it are the same: different players choosing to share different sets of data, with the more-open players' wish to share data inevitably trumping the less-open players' wish to suppress data. ----- @TheBillPN, @Luffster, @Gragnog You guys have asked why we (the dev team) don't just run a tournament ourselves. One of the (only six!) founding principles of the company, which we published way back in 2009 when the game first started, is that "There’s no in-game content that’s as compelling to players as player-created content." We still believe this passionately. Player-run tournaments are an attempt to further that part of the Illy sandbox, and we are keen to get player-run tournaments off the ground and see how they go. For example, I think it's awesome that part of this tournament's objectives is to highlight Neurofibromatosis - and that wouldn't have happened if we'd put a tournament together. ----- Partly because I've run out of energy to further discuss what seems self-evident to me, but mostly because we actually want to see a player-driven tournament succeed, and especially given that the tournament organisers themselves have requested this limited data API key - I agree: we'll implement the limited tournament data key. Some caveats/notes: 1. Full combat API key It'll be up to digi and Koda if they also accept the full API key as well. Cilcain has said he's fine with them running in parallel (so there's no issue there). But it's your call. 2. Limited key specification Digioso, I know you made a brief specification a couple of posts above, but I think it needs some clarification and refinement. Amongst many data fields I believe you would want, your specification is missing some key ones, such as <combatoverview><location>. I imagine it'd be hard to hand out your Regional Winner prizes if you don't know which square any of the participants arrived at And I specifically need to know what data you want in the <participant> fields, as I believe Cilcain wants (eg) player town repressed from these fields. As you guys (the tournament organisers *and* the limited-data-crew collectively) are defining what the limited dataset should actually consist of, I will need you to produce a collectively-agreed sample xml file that contains only the data fields you want shared; and I will code to that sample file. I will add, from some prior experience, that you should carefully consider what makes a tournament exciting to not only participate in, but also to watch - and I'd caution against kneecapping "fun" in the name of limiting data. For example, a tournament without a visible casualty count (and only with the proposed win/lose/draw) is not that much more than a ranked list of alliances, and I believe would lose the 'epic'. But this is, as I hope is now crystal clear, entirely your call. 3. Square and key timestamp limits As I mentioned earlier in this thread, I'll be fixing the key time bug (for both the tournament and the full API key) where a reissued key produces data that precedes the new key issuance datetime back to the original key issue datetime. I'll also be ensuring that the tournament API key only returns data from the specifically designated tournament squares. 4. Development schedule I don't currently have any time in the development schedule for this work, and - depending on how long it takes you to get a mutually acceptable (between the tournament organisers and the limited-data-crew) sample xml file put together - I can then see when we can slot some development time in to make this change. We may not make May 17th, but I will keep you posted. ----- tldr; Fundamentally, I want player-run tournaments to work, and although I wholeheartedly disagree with this limited-data tournament key... if it's the only thing that'll make this tournament fly - and if it's what the organisers of the first player tournament also want - then "what the hey, let's give it a whirl and see where we end up". Regards, SC
|
|||
Digioso
Forum Warrior Joined: 09 Feb 2015 Location: Germany Status: Offline Points: 312 |
Post Options
Thanks(0)
|
||
Thanks SC. :)
I'll work out a sample XML that would suffice for this tournament. |
|||
Post Reply | Page <1 678910 11> |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |