|
3 years ago ::
Nov 18, 2010 - 9:25PM
#111
|
|
|
I *think* that iPlay4E uses the Compendium search functionality as a pseudo API, so yes, I believe that you are correct ( big cheer). I have never seen that site before you mentioned it. It looks pretty slick. I'll have to check it out more thoroughly. But this is a great example of what can be done in the hands of the community. ObsidianPortal is another one that is nice. I would imagine that if Wizards did want to pursue this, that any program would have to be provided as open source so they can review the code firsthand if they chose to. But yes, the intent would most likely be that the proprietary data would remain on their servers and not be stored locally. The only question marks would be the creation of custom content based off of the propietary data. For example, I want to create a kobold sniper based off of a kobold slinger, how would this be handled? Obviously, this could be stored locally if keyed in by hand. But if access is granted to the Cloud, even this custom content could be stored there and potentially shared. There would be a lot to iron out for sure. Bigger brains than mine are far better at covering all of the finite details. I just know enough to spark the fire.  If I think of more, I'll be sure to keep you updated.
Reflavoring: the change of flavor without changing any mechanical part of the game, no matter how small, in order to fit the mechanics to an otherwise unsupported concept.
Retexturing: the change of flavor (with at most minor mechanical adaptations) in order to effortlessly create support for a concept without inventing anything new.
Houseruling: the change, either minor or major, of the mechanics in order to better reflect a certain aspect of the game, including adapting the rules to fit an otherwise unsupported concept.
Homebrewing: the complete invention of something new that fits within the system in order to reflect an unsupported concept.
Default module =/= Core mechanic.
|
|
|
|
3 years ago ::
Nov 18, 2010 - 9:42PM
#112
|
Date Joined:
Feb 24, 2009
|
One of the big concerns from the powers that be (I predict) will be that any API uses the data in a manner which is like iPlay4E (where the data stays on the server), and not like Masterplan or HeroLabs, which allow you to download the data once, and never need to connect to the server again.
Getting ready for sleep while I try to write this so please forgive anything that doesn't make sense. Just point it out and I'll clarify in the morning.
Data provided from the API should be stored via the reference to data as opposed to the data itself. For example, the fighter power "Crack the Shell" should be stored as http://apiwebaddress/powers.php?id=some-unique-id-for-crack-the-shell. The value returned from this address could be formatted in XML or JSON (or any other document format that makes sense and is easily parsed). The database table would be filled with web urls instead of the XML returned from the API.
Each user that wants to create a tool that uses the API should be given an api-key. This key is unique per project, and would allow each community/WotC project to be tracked. Obtaining a key can be free for DDI subscribers to create these tools, but will require agreement to a ToS that would limit the data allowed for storage locally and require that each project be created for non-profit/open-source. Being open-source allows WotC to review any code created to ensure that their policies are respected. This will allow WotC to control the use of the API and protect their data.
My company provides keys to our API users for free and requires that the software created is open-source. This allows us to review any uses of the API and ensure data isn't used in a way that would violate the ToS. Our API allows others to sell our products through their websites. This has driven a lot of revenue our way and the community does the work for us. For their efforts, they receive a percentage of the profit.
WotC doesn't need to adapt this specific model, but if an API is implemented that allows the community to create tools for DnD, each request to the API could require the following:
1) request for data
2) api-key
3) end user's ddi username and password
Number 3 is key. The api-key is identifier for the project, but the username and password is the ddi account info for the end user, not the software developer. Usable tools released by the community could be a catalyst for additional subscriptions to the DDI.
WotC could even provide space on the site to showcase these community created tools.
Edit: Damn, now Jharii is ninjaing me. I see that the game is now afoot. 
|
|
|
|
3 years ago ::
Nov 18, 2010 - 9:52PM
#113
|
|
|
Data provided from the API should be stored via the reference to data as opposed to the data itself. For example, the fighter power "Crack the Shell" should be stored as http://apiwebaddress/powers.php?id=some-unique-id-for-crack-the-shell. The value returned from this address could be formatted in XML or JSON (or any other document format that makes sense and is easily parsed). The database table would be filled with web urls instead of the XML returned from the API.
If they packaged up the API in a DLL or class, it could be even better, although we could always write our own. Instead of the URL method, we would use a command such as GetPower("Crack the Shell") or GetPower(27) and then we could just store the name or number.
Edit: Damn, now Jharii is ninjaing me. I see that the game is now afoot.
LOL. Just discussing this stuff is infectious. To be honest, the potential of it all is what I have always envisioned the D&D community evolving into. Just this vast well of creativity and knowledge, all at each others' fingertips. It would be like Facebook, but for cool people who are actually nothing more than geeks that think they are cool people.
Reflavoring: the change of flavor without changing any mechanical part of the game, no matter how small, in order to fit the mechanics to an otherwise unsupported concept.
Retexturing: the change of flavor (with at most minor mechanical adaptations) in order to effortlessly create support for a concept without inventing anything new.
Houseruling: the change, either minor or major, of the mechanics in order to better reflect a certain aspect of the game, including adapting the rules to fit an otherwise unsupported concept.
Homebrewing: the complete invention of something new that fits within the system in order to reflect an unsupported concept.
Default module =/= Core mechanic.
|
|
|
|
3 years ago ::
Nov 18, 2010 - 10:48PM
#114
|
|
|
This is an interesting thread. The discussion is interesting and I will be including it in my weekly report to WotC.
I know *nothing* about programming, so perhaps this might be an interesting discussion point to add (as I don't know if the people getting these reports know anything about programming, etc...):
1 - Can one program an API so as to prevent people from scraping the entire compendium?
2 - What type of APIs do you envision that would complement the currently planned tools?
Thanks for keeping it (mostly) civil.
Well implementing timeouts before each search as well as a maximum number of searches in a day (say 100). Or a combination such as a delay of 1 second between searches that goes up for every search so if you hit 100 searches your at 1 minute 40 seconds between searches. I'm sure to get the info you'd need thousands of searches so this would slow people down not stop them, but you could also flag people that search more than the prescribed 100 times per day and investigate... Also Captcha's do awesome jobs foiling this kind of thing...
|
|
|
|
3 years ago ::
Nov 18, 2010 - 11:02PM
#115
|
|
|
I don't think any of that would be necessary. Putting a throttle on the number of queries a day would limit the most basic of functionality, such as browsing monsters or powers.
Pzychotis's method with the unique key that must be used is much more efficient and elegant. If the associated key breaches the terms of the ToS, then the key is deactivated, rendering the software useless. It could even go another layer, where the key is used, but another key is generated when a DDI subscriber uses the key via the software itself. If that user breaches the terms of the ToS, that generated key is deactivated, rendering the software useless for that DDI subscriber.
Again, the details of the ToS would need to be worked out, but Wizards would likely have statistics available to them based solely on the utilities they currently have available. They could make assessments and decisions based off of that if they felt compelled to.
Reflavoring: the change of flavor without changing any mechanical part of the game, no matter how small, in order to fit the mechanics to an otherwise unsupported concept.
Retexturing: the change of flavor (with at most minor mechanical adaptations) in order to effortlessly create support for a concept without inventing anything new.
Houseruling: the change, either minor or major, of the mechanics in order to better reflect a certain aspect of the game, including adapting the rules to fit an otherwise unsupported concept.
Homebrewing: the complete invention of something new that fits within the system in order to reflect an unsupported concept.
Default module =/= Core mechanic.
|
|
|
|
3 years ago ::
Nov 19, 2010 - 5:26AM
#116
|
Date Joined:
Feb 24, 2009
|
If the associated key breaches the terms of the ToS, then the key is deactivated, rendering the software useless. It could even go another layer, where the key is used, but another key is generated when a DDI subscriber uses the key via the software itself. If that user breaches the terms of the ToS, that generated key is deactivated, rendering the software useless for that DDI subscriber.
This was exactly what I was thinking. Jharii just said it better
|
|
|
|
3 years ago ::
Nov 19, 2010 - 5:27AM
#117
|
|
|
If the associated key breaches the terms of the ToS, then the key is deactivated, rendering the software useless. It could even go another layer, where the key is used, but another key is generated when a DDI subscriber uses the key via the software itself. If that user breaches the terms of the ToS, that generated key is deactivated, rendering the software useless for that DDI subscriber.
This was exactly what I was thinking. Jharii just said it better
We is synergy.
Reflavoring: the change of flavor without changing any mechanical part of the game, no matter how small, in order to fit the mechanics to an otherwise unsupported concept.
Retexturing: the change of flavor (with at most minor mechanical adaptations) in order to effortlessly create support for a concept without inventing anything new.
Houseruling: the change, either minor or major, of the mechanics in order to better reflect a certain aspect of the game, including adapting the rules to fit an otherwise unsupported concept.
Homebrewing: the complete invention of something new that fits within the system in order to reflect an unsupported concept.
Default module =/= Core mechanic.
|
|
|
|
3 years ago ::
Nov 19, 2010 - 11:24AM
#118
|
Date Joined:
Aug 17, 2007
|
That sounds like conspiracy talk.
To be fair, that is not much different than your "special ops/one man army" theory. Just the opposite side of the same coin.
I'm not sure what you are trying to say.
PDFs got pulled because a handful of people were selling them in the thousands under the table, right? A few people ruined it for everyone else.
The same can happen with the API stuff.
Selling was not the issue.
WOTC Podcast:
"The web is a shortcut"
"Piracy was a big thing"
|
|
|
|
3 years ago ::
Nov 19, 2010 - 11:39AM
#119
|
Date Joined:
Jan 15, 2008
|
Data provided from the API should be stored via the reference to data as opposed to the data itself. For example, the fighter power "Crack the Shell" should be stored as http://apiwebaddress/powers.php?id=some-unique-id-for-crack-the-shell. The value returned from this address could be formatted in XML or JSON (or any other document format that makes sense and is easily parsed). The database table would be filled with web urls instead of the XML returned from the API.
If they packaged up the API in a DLL or class, it could be even better, although we could always write our own. Instead of the URL method, we would use a command such as GetPower("Crack the Shell") or GetPower(27) and then we could just store the name or number.
Edit: Damn, now Jharii is ninjaing me. I see that the game is now afoot.
LOL. Just discussing this stuff is infectious. To be honest, the potential of it all is what I have always envisioned the D&D community evolving into. Just this vast well of creativity and knowledge, all at each others' fingertips. It would be like Facebook, but for cool people who are actually nothing more than geeks that think they are cool people.
Unforuntantely this is a pipe dream. While many companies can and do support an API to thier product and know how to protect it against bad/malicious queries, it has nothing to do with that.
WoTC has Intellectual Property they are not going to release in an electronic fashion. It's the same reason why we don't have PDFs for sale anymore. They are afraid someone will get the benifit of thier product for free.
|
|
|
|
3 years ago ::
Nov 19, 2010 - 1:07PM
#120
|
|
|
Unforuntantely this is a pipe dream. While many companies can and do support an API to thier product and know how to protect it against bad/malicious queries, it has nothing to do with that.
WoTC has Intellectual Property they are not going to release in an electronic fashion. It's the same reason why we don't have PDFs for sale anymore. They are afraid someone will get the benifit of thier product for free.
"Someone" already does get their product for free. All over the place. And it doesn't even have anything to do with DDI. But we've covered all this in this thread already.
You may call it a pipe dream, but Mudbunny is running it up the flagpole, and I carry no expectations. This is much further along than I would have expected when posting it. I just merely wanted to discuss it openly.
Whatever the case, I do know that this is likely the deciding factor whether I keep my DDI subscription or not. It just doesn't have any value to me if I cannot use the data efficiently and to the best of my abilties. I don't think that I am the only one that shares in the last assessment.
The time I spend waiting on some type of campaign manager from Wizards can be spent building one myself. Yes, I can do it on my own anyhow, but the database is an invaluable resource. But whatever I make for myself, only I can use. I can't distribute it. And if I can make something that other DM's with DDI status can benefit from, how is that not a bonus to Wizards?
Reflavoring: the change of flavor without changing any mechanical part of the game, no matter how small, in order to fit the mechanics to an otherwise unsupported concept.
Retexturing: the change of flavor (with at most minor mechanical adaptations) in order to effortlessly create support for a concept without inventing anything new.
Houseruling: the change, either minor or major, of the mechanics in order to better reflect a certain aspect of the game, including adapting the rules to fit an otherwise unsupported concept.
Homebrewing: the complete invention of something new that fits within the system in order to reflect an unsupported concept.
Default module =/= Core mechanic.
|
|
|
