Marketplace for API scripts

Could we have a marketplace for API scripts? Introducing this would have a big impact on what is available, rather than just the stuff that people do in their spare time. It would certainly dangle the carrot :)

I brought this up at the GenCon Panel. The answer was basically "no", with a side of "we'd love to but we can't justify it financially." Certainly, I'd love to get paid for the scripts I write (and some people have gifted me subscription money for them (Thanks Kevin!)), but I can understand their position. Here are some of the problems I came up with when I stopped to think about it: API Scripts have to run on the API servers, which are an additional expense. That is the reason they are restricted to the Mentor level. This leads to a limited number of consumers. As a rough estimate, I'm guessing there are about 1250 mentors ( (50k salaries x 5 people (3 current, 2 hires)) / ($100 yearly mentors + 2 x $50 yearly subscriber (I'm assuming there are twice as many subscribers as mentors))). Half of those people might buy scripts (625), 10% of those people might be interested in YOUR script (62), a quarter of which will buy it (15), leaving you an income of about $52.50 ($5 x 15 x 0.7) for that script. Most of my scripts take more than 10 hours to write, meaning the income would be less than minimum wage. Since the scripts are in an interpreted language, there would need to be some distribution system created which would allow you to buy and manage installing/activating/deactivating/removing without exposing the code. The quality of the API system would need to be improved. No insult intended to Riley, et al. The API is great as a Mentor level perk, but there would need to be some changes if it were to become a full fledged feature. The API system would need to isolate individual scripts, but allow them to communicate in order to be effective. That would require much grander hardware, and much greater understanding by the script programmers. Likely, the Roll20 crew would want to curate scripts. They wouldn't want someone selling a script that would trash your whole campaign. That would add a large work load for someone, installing all the various scripts and testing them out, reading and understanding what all the code does. Failing to do that would lead to a proliferation of low quality scripts, which would cause the view of users to be that they are better off not messing with them. On the flip side, by curating the scripts, they would decrease the availability of scripts in general (as most people would be wanting to sell their scripts, but not everyone would be able to, and thus fewer scripts would be released). That's my understanding of the problems involved. If it could be done in a manner that was profitable to all, I'd be totally down for it. That said, we might be better off trying to get a system of micro-gifting others, and develop a community culture of gifting each other for scripts and other things. Or perhaps a crowd gifting mechanic where multiple people can get together and pledge a gift amount to a common scripting goal, and script programmers can write to that goal. Anyway, hope my perspective helps! =D

Thanks Aaron. For #5 it should simply be a case of 'buyer beware'. There will always be positive and negative feedback and the scripts can be rated by the community. As the numbers flow in for roll20 and more and more scripts that automate certain games become available the $$$ will come. More people would pay to be 'mentors' to gain access to the scripts. I am currently working on fully automating 5e using the API. I have enjoyed writing the script even if it goes nowhere. I have found it tremendously useful in my games. All of the spells, attacks, powers etc.. are built in.

6. Legal concerns regarding if programmers wrote scripts to implement rules that are owned by someone else, such as automating all the rules to a game sold by Wizards of the Coast... =D Anyway, If they can find a way to do it and avoid all those pitfalls, I'd be all for it.

The Aaron said: Since the scripts are in an interpreted language, there would need to be some distribution system created which would allow you to buy and manage installing/activating/deactivating/removing without exposing the code. Not necessarily . As a contrived example, if subscribers could purchase scripts and the only means they had to add a script to a campaign was via the script marketplace interface, it wouldn't matter whether they could see the code or not. Similar to how everyone can use character sheets from the official GitHub and everyone can go look at the code, but only mentors can copy+paste that code and achieve anything. (This example expands who can benefit from the API while maintaining a perk of mentor over subscriber by giving the mentors access to the API scripts for free, much like they have access to many existing marketplace images for free.) I suppose you could also use Google Closure tools and/or JS minification to make looking at the code basically useless, too. However, at that point you're essentially relying on security through obscurity. (GClosure and minifaction should be used for speeding up runtime/download time, not disguising your code.)

The Aaron said: 6. Legal concerns regarding if programmers wrote scripts to implement rules that are owned by someone else, such as automating all the rules to a game sold by Wizards of the Coast... =D Anyway, If they can find a way to do it and avoid all those pitfalls, I'd be all for it. Yeah :) I would anticipate that WotC will eventually take a keen interest in what is happening at Roll20 and possibly help fill a certain void in the virtual tabletop market with their product becoming available through the Roll20 vehicle. I would love to see it happen! Pipe dream? In the meantime I will make my own.

Brian said: The Aaron said: Since the scripts are in an interpreted language, there would need to be some distribution system created which would allow you to buy and manage installing/activating/deactivating/removing without exposing the code. Not necessarily . As a contrived example, if subscribers could purchase scripts and the only means they had to add a script to a campaign was via the script marketplace interface, it wouldn't matter whether they could see the code or not. Similar to how everyone can use character sheets from the official GitHub and everyone can go look at the code, but only mentors can copy+paste that code and achieve anything. (This example expands who can benefit from the API while maintaining a perk of mentor over subscriber by giving the mentors access to the API scripts for free, much like they have access to many existing marketplace images for free.) I suppose you could also use Google Closure tools and/or JS minification to make looking at the code basically useless, too. However, at that point you're essentially relying on security through obscurity. (GClosure and minifaction should be used for speeding up runtime/download time, not disguising your code.) If you took 3 on it's own, I'd agree with you, but since it's framed in the context of 1, I stand by my point. =D Also, if that's the only way to get the code installed, there isn't actually any reason to expose it to begin with, so I think I'd still stand by my point. Additionally, even if for some reason the code was released in some fashion but only mentors got "free" access to it, and there was some subscription level that could only install it, nothing would prevent making cosmetic changes and running it through cheaper or free, further destroying the effectiveness of the model. (Ok, the weary & downtrodden theoretical Roll20 gatekeeper would be there to stop it from happening... because he'd be memorizing the contents of all the scripts, and making sure there wasn't some hanky-panky going on... =D ) Also, considering the number of annoy-ware chrome extensions I've beautified and "fixed", I certainly agree with you regarding the false security of obscurity.

Here are my thoughts on whats been brought up so far: 1. Without knowing what the API servers cost to maintain I can only offer up some suggestions.  Per Campaign Access: Allow non-sub users to pay for API access on specific campaigns? You could put scripts in the marketplace where non-sub users can access them. When they try to add them to their campaign they get hit with a paywall. They can either become a mentor or pay some recurring or one-time fee to run scripts for that specific campaign.  Single/Unlimited Access Scripts: I don't know how widespread the use of scripts is but if you offered payment options for unlimited or single-use versions of the script (single use can only be used in the campaign it was purchased for, unlimited can be used in any campaign created by that account) perhaps just taking a cut of the sales would be enough to cover the servers? 2. If you take into account the suggestions I made in the previous section I believe that might help bolster the numbers of script consumers. Either way though, even when I write a script that takes me 12 hours like my last one did, in the end I'm pursuing a hobby and making some cash on the side is just an added bonus. I can see how this might be discouraging to other content creators who are committed to delivering quality material and want to be paid accordingly. 3. I thought the scripts were already ran server-side not client-side? Seems like the framework is already in place for something like this. You could pick and choose what scripts are included in the campaign from the list you have purchased. The server would just check that list and load them up from what it has saved on the backend. 4. I agree that the API needs some TLC (particularly in the realm of drawing and visibility controls) but I think its sufficient for the needs of most scripts. I haven't tried it but couldn't you place methods into the state for interactivity between scripts? I know that you would need to reinitialize every time the sandbox resets but a workaround should be possible. I'm not really a javascript developer so maybe there's something I don't understand :( 5. Having someone curate scripts is one way to ensure the quality of what is available on the marketplace but I believe there are other ways to accomplish the same goal.  Unlike images where the quality of the product is able to be quickly determined at a glance, it would be much more difficult for users to separate the good scripts from the bad. This means some sort of demo or 'Try before you buy' system needs to be implemented. When you choose to demo a script, a transient clone of your campaign could be spun up with the selected script applied to it, when the demo ends the clone is destroyed with no changes made to the original campaign. This demo system would also serve the purpose of curating scripts by extension, if a user demos the script and it performs some malicious actions or simply doesn't work they can flag the script as needing attention by Roll20. Additionally having a rating system where users have purchased the script can rate the quality would further serve to separate the good from the bad. 6. Yes, this could potentially get sticky if Roll20 is taking a cut of the script price and one of those scripts implements stuff it shouldn't. I'd like to believe WoTC wouldn't come after things like that but who knows.

The Aaron said: 6. Legal concerns regarding if programmers wrote scripts to implement rules that are owned by someone else, such as automating all the rules to a game sold by Wizards of the Coast... =D Anyway, If they can find a way to do it and avoid all those pitfalls, I'd be all for it. I'm a little late on this, but game rules aren't copyrightable .  Basically, you can copyright the text describing the rules, but you can't actually copyright the rules , so automating the rules isn't a problem, so long as they don't reproduce the text itself.

Thanks for the suggestion! After 30 days, Suggestions and Ideas with fewer than 10 votes are closed and the votes are refunded to promote freshness. Your suggestion didn't build the right momentum this time, but feel free to submit it again! We find that the best suggestions describe the problem you are having, and the solution you want. You can learn more about the process of making suggestions on the Roll20 Wiki! More details can be found here .