Games these days tend towards web-based API interfaces for 3rd party websites and applications to use. Many guild sites use this for character and loot linking to allow users to easily view what was found during raids, or what gear a specific person is equiped with. Query tools use this for NPC and item look up for players to more easily find the what kinda of items are out there, who might drop them, and where NPCs are located and what they are for. There are pretty much endless possibilities to what an API could offer to the community.
My Question is:
Given the mystery and discovery Pantheon is promoting so highly, should an API be implemented in such a game?
If so, what kind of functionality should be added or prohibited to better achieve your goal or desire.
If not, would you rather see some in-game functionality, as mention, added? maybe something limited to character experience, or maybe just nothing at all?
I am going to keep my personal bias out because I want to know everyone's opinion on systems like this. :) cant wait to play!
If an API were to be implemented (whici should be way down on the priority list) my personal preference would be that it only show gear worn by a character, and then stats for that character. There should be no infomation on mob, location to obtain, drop rate, or anything else. Honestly I'd take it a step further and have it only update once / day or week too so it was purposely on a delay. This would allow you to pull together what your guild has, or allow people to show off, but would limit the spoiler information somewhat.
Taldaas said:If an API were to be implemented (whici should be way down on the priority list) my personal preference would be that it only show gear worn by a character, and then stats for that character. There should be no infomation on mob, location to obtain, drop rate, or anything else. Honestly I'd take it a step further and have it only update once / day or week too so it was purposely on a delay. This would allow you to pull together what your guild has, or allow people to show off, but would limit the spoiler information somewhat.
I understand this is far off. I am just trying to get a scope of what everyone is expecting from the game from a record standpoint. Also, maybe help the UI and database team with some functionality ideas they could implement and test. Gotta keep them busy you know!
The concept of pushing updates via API once per day or week is an interesting idea.
since i'm an simple man api = application programming interface(yes i bing searched it).
i'm translating this like some kind of metadata sharing kind of system?
ehh it's probably unavoidable with how things are nowadays.
i think they call it datamining(not even sure what that is exactly).
i would prefer not to have it though. it sucks how some new armor appearance(wow) were datamined and it spoils the excitement and disappointment. if i know what i don't know then why bother reading a book, when the act of reading the book is what makes it fun?
uhh i think what i'm getting at is.. the knowledge isn't what makes it fun, but the act of gaining that knowledge is what makes it fun.
Personally, regardless of the schema, I would probably deploy it something like:
Replicate the relevant table(s) into a Google Cloud SQL instance daily or hourly, it being hosted somewhere not near their server hosting, and not in the game server hosting VPC, if that's what they're currently using.
Then simply set up permissions based on Google Auth / IAM Roles, and allow read-only access to whomever they wish, including the public.
Following something like this, absolutely nothing that happens to this instance would have any impact whatsoever on the game servers, ever.
https://cloud.google.com/sql/docs/mysql/connect-app-engine
As far as what's in the schema? Hopefully everything. :) I mean, really, there's no downside to more transparency.
If it's read-only data already included in the client UI or fields filled in the client log file (not PII)? It should be included in the API.
It will end up in someones database, eventually, either way, might as well stand up and be the canonical source.
vjek said:Personally, regardless of the schema, I would probably deploy it something like:
Replicate the relevant table(s) into a Google Cloud SQL instance daily or hourly, it being hosted somewhere not near their server hosting, and not in the game server hosting VPC, if that's what they're currently using.
Then simply set up permissions based on Google Auth / IAM Roles, and allow read-only access to whomever they wish, including the public.
Following something like this, absolutely nothing that happens to this instance would have any impact whatsoever on the game servers, ever.
https://cloud.google.com/sql/docs/mysql/connect-app-engine
As far as what's in the schema? Hopefully everything. :) I mean, really, there's no downside to more transparency.
If it's read-only data already included in the client UI or fields filled in the client log file (not PII)? It should be included in the API.
It will end up in someones database, eventually, either way, might as well stand up and be the canonical source.
-deer the headlights while nodding-
well it's over my head i'mma bow out now XD
"It will end up in someones database, eventually, either way, might as well stand up and be the canonical source."
I completely agree. Let it be the lucy of this epoch!
Kilsin said:We have covered this in multiple threads but basically the official stance is we will allow some customisation for the user to move their UI around, skin it and set it up the way they like but we will not support APIs, Addons or 3rd party programs that link information to the game or allow the UI to be dramatically changed.
https://www.pantheonmmo.com/content/forums/topic/4072/ui-map-customization
The context of Kilsins response isn't exactly what some API's could be.
In particular, a public API for public websites to provide character data wouldn't affect the game client itself, nor be related to the game client UI in any way.
Something like this, is what my responses were in the context of. Nothing, at all, to do with the game client or game client UI. (as Kilsins response was)
No APIs. No third-party programs. As much effort as possible to obfuscate and secure the data, please.
All those tools and analytics detract from the game.
I think most people agree that the best games have you looking at the screen and reacting to 'real' activities in an immersive way rather than playing the UI.
To allow or encourage use of tools and analytics beyond even the UI would be the ultimate abstraction from the 'real' game.
If you 'need' a DPS meter to tune your character or you need a combat analytics tool to succeed in a raid then the game is designed badly.
Also, the elitism that that kind of satistical stuff allows/encourages is just... ugh. "Dude, your DPS was 0.4% below national average in the last raid and your current items have an efficiency rating 0.15% below the guild average. We have standards. You're out". "Dude, why are you taking so long to find X? Don't you have Questie-Add-On side-loaded? Leave the group if not". Yeah. No thanks.
Also, an API is just asking for security and data mining problems.
Yes, third parties will develop databases of 'stuff'. That doesn't mean VR have to make it easy and produce a 100% accurate live lists of items, quests, NPCs, etc, etc.
disposalist said:vjek said:That's going to happen from parsing the client side log file anyway, HemlockReaper. What the API could provide, would be everything -except- the PII that's in the client side log file.
Does there have to be a client-side log file?
No, and there's some tricks for VR with regard to manipulating the client as well so a person cannot simply pull the information directly or indirectly through a PPL siphon or something similar.
disposalist said: Does there have to be a client-side log file?Not unless you want your customers to be able to troubleshoot problems, validate changes, or in any way provide reasonable feedback regarding your game. :)
disposalist said:No APIs. No third-party programs. As much effort as possible to obfuscate and secure the data, please.
All those tools and analytics detract from the game.
I think most people agree that the best games have you looking at the screen and reacting to 'real' activities in an immersive way rather than playing the UI.
To allow or encourage use of tools and analytics beyond even the UI would be the ultimate abstraction from the 'real' game.
If you 'need' a DPS meter to tune your character or you need a combat analytics tool to succeed in a raid then the game is designed badly.
Also, the elitism that that kind of satistical stuff allows/encourages is just... ugh. "Dude, your DPS was 0.4% below national average in the last raid and your current items have an efficiency rating 0.15% below the guild average. We have standards. You're out". "Dude, why are you taking so long to find X? Don't you have Questie-Add-On side-loaded? Leave the group if not". Yeah. No thanks.
Also, an API is just asking for security and data mining problems.
Yes, third parties will develop databases of 'stuff'. That doesn't mean VR have to make it easy and produce a 100% accurate live lists of items, quests, NPCs, etc, etc.
Agreed
disposalist said:No APIs. No third-party programs. As much effort as possible to obfuscate and secure the data, please.
All those tools and analytics detract from the game.
I think most people agree that the best games have you looking at the screen and reacting to 'real' activities in an immersive way rather than playing the UI.
To allow or encourage use of tools and analytics beyond even the UI would be the ultimate abstraction from the 'real' game.
If you 'need' a DPS meter to tune your character or you need a combat analytics tool to succeed in a raid then the game is designed badly.
Also, the elitism that that kind of satistical stuff allows/encourages is just... ugh. "Dude, your DPS was 0.4% below national average in the last raid and your current items have an efficiency rating 0.15% below the guild average. We have standards. You're out". "Dude, why are you taking so long to find X? Don't you have Questie-Add-On side-loaded? Leave the group if not". Yeah. No thanks.
Also, an API is just asking for security and data mining problems.
Yes, third parties will develop databases of 'stuff'. That doesn't mean VR have to make it easy and produce a 100% accurate live lists of items, quests, NPCs, etc, etc.
This is my stance on the whole situation. I would rather the game be so air tight the only way people can get information out of it is the old school way of screen shots and manually writing it all down. Need to know the frequency or trigger for specific actions of monsters? get hit by them enough until you can 'feel' them coming. Don't understand what a debuff does? contract it enough until you feel the difference it makes. It is all about understand the game through trial and error for me, not research research research then get pissy when 72 people cannot execute a perfectly timed meneuver a couple dozen times in a row to defeat a boss.
I understand there are communities of people who love to collect data, build databases on that data, create ideal strats, min/max per scenario, etc., but I find that to subtract from the adventure and exploration of the game.
vjek said:disposalist said: Does there have to be a client-side log file?Not unless you want your customers to be able to troubleshoot problems, validate changes, or in any way provide reasonable feedback regarding your game. :)
They've also confirmed there will be a client side log file.
From here: " We will support the use of a parser that collects information from our combat chat logs which we can control what information is delivered to those logs and allow people to use that information externally to improved themselves etc. ... Using a parser to collecting information by saving it to a .txt file after a session/fight/raid mob and uploading that into a parser and parsing it to be broken down and studied after a fight, sure, knock yourselves out, I will even be using something like that to better myself and my characters and to figure out raid strats ... "
And here: " ... A parser gathers information and displays it after the fact. A DPS Meter is basically a widget that shows a live visual representation of your DPS in-game.
... We will, however, allow parsing of combat text displayed in chat, like you could do in EQ and VG for players to use that information to better themselves, learn strats for boss mobs, test weapons, armour, EE's etc. like you could also do in EQ and VG. "
You can allow customers to /report someone and have the game internally send a log to a GM. You can allow customers to /bugreport and have the game internally send a log to a techsupport person. Same for /feedback or whatever.
I have the same issue with Kilsin's comments as others did in those threads. To say VR will allow client-side logging *is the same* as allowing 3rd party tools such as DPS meters, because client-side logging is what allows these tools to be made and *they will be made* if there is client-side logging. To say Pantheon will not have DPS meters but *will* have client-side logging is splitting hairs and is nonsense. Just because VR hasn't *made* the tool doesn't mean anything if they *enable* it's production and know darn well it will be made.
May as well say "we won't have a cash shop where you can buy in-game currency" and then have a mechanic that enables gold-sellers to function really easily.
Except that Kilsin also said "we have not decided yet on how much information we will allow to be sent to the chat log", though if they put in enough information for people to 'work out raid strategies' and the log can be written at any time, then someone can easily make a third-party, pretty-much-live DPS meter.
My comment about "providing reasonable feedback regarding your game" is based on this..
If you don't have a client side log file that shows every cast, hit, miss, attack, effect, spell, ability, etc? Then all you get from your customers is feelings.
Feelings don't help in a game based entirely on math. Feelings are sometimes important, but not always as helpful to developers trying to fix broken code.
To fix that, you need the results of the math, to fix the broken math.
Hence, the need to have customers be able to capture, cut and paste, or upload log files to the developers, showing.. " hey, see this math? It's broken, please fix the broken math. "
To your point, if there is no log, people will just read it out of memory. Personally, I would prefer more transparency, not less, in a game based on math. Several other posters have expressed a desire to hide the math from paying customers, when all that does is require paying customers willing to break the TOS/EULA to gain access to the same information everyone should have access to. I see that as unfair, personally.
If your game design is solid? Knowing the math should make the game better, not worse. (see DnD, all dice based RPGs, and more)
vjek said:Personally, regardless of the schema, I would probably deploy it something like:
Replicate the relevant table(s) into a Google Cloud SQL instance daily or hourly, it being hosted somewhere not near their server hosting, and not in the game server hosting VPC, if that's what they're currently using.
Then simply set up permissions based on Google Auth / IAM Roles, and allow read-only access to whomever they wish, including the public.
Following something like this, absolutely nothing that happens to this instance would have any impact whatsoever on the game servers, ever.
https://cloud.google.com/sql/docs/mysql/connect-app-engine
As far as what's in the schema? Hopefully everything. :) I mean, really, there's no downside to more transparency.
If it's read-only data already included in the client UI or fields filled in the client log file (not PII)? It should be included in the API.
It will end up in someones database, eventually, either way, might as well stand up and be the canonical source.
lol, they can expose a public API any number of ways.