Suggestion Voting, monetization and free development

I would rather have put parts of this into the suggestions area, but that is not possible. To fix this problem, allow people +1 vote for attaching a working credit card to their account, or allow people to buy their first vote for $1, doing effectively the same thing. Votes on your recommendation system disproportionately encourage people who want to be herd to re-create accounts monthly to get 5 votes, Please alter this to a +1/yr free, +1/m supporter, +2/m mentor, and if you need balance only allow people to bank 10 votes (or something similar) I do not do much roleplaing anymore, due to distance and time. I am happy to have found roll20, and may finally be able to start back up. I do want a better sense of what and how hard it would be to implement some of my ideas, but do not want to signup for a pay service I can't tinker with first. please allow for the creation of a single player campaign so prospective developers and game masters can test out your features before buying. At worst you will see developers who are not actively playing anything, coding new features with your api. At best, your dynamic lighting , etc, will draw more paying people in.

TwinHerder said: Votes on your recommendation system disproportionately encourage people who want to be herd to re-create accounts monthly to get 5 votes I'm not sure what you mean by this. Could you clarify? TwinHerder said: please allow for the creation of a single player campaign so prospective developers and game masters can test out your features before buying. At worst you will see developers who are not actively playing anything, coding new features with your api. At best, your dynamic lighting , etc, will draw more paying people in. Apparently, one part of the reason why the API is a Mentor only feature is that the API servers are expensive, and so locking the feature behind a paywall limits the number of users hitting those servers. Assuming that's true, granting Base accounts access to the API (even if you bar other players from joining that campaign) could be problematic. It's also worth noting that there are a number of groups who meet in person and use Roll20 anyway, doing things like projecting the VTT onto a widescreen TV. Groups like this don't need other user accounts to join the campaign. groups like that would then have zero incentive to become a subscriber.

To expound upon what Brian said, during the Roll20 Panel at Gencon, there was a discussion about why the API is restricted to Mentors: the API servers actually pose a significant cost over and above the other servers.

TwinHerder said: I do want a better sense of what and how hard it would be to implement some of my ideas, but do not want to signup for a pay service I can't tinker with first. please allow for the creation of a single player campaign so prospective developers and game masters can test out your features before buying. 1. This exists. It is and always has been free to start up a campaign on here, whether you want that to be a single player campaign as you mentioned or 5 or 100 players. You can test most features of this site, and can get a sense of what the difference would be if you upgrade to advanced subscriber features later. 2. If you want to test Subscriber-level features, you can subscribe for 1 month for less than $10. Simply cancel your subscription and you won't be charged again, and you can test the most advanced subscriber features for the month.

Brian, What I meant was if a person wanted to pay 5$ a month, and they wanted to make it appear that a feature is more popular than it is, then they could create a new account every month, and get 60 votes a year, rather than the normal subscribers 6. This should be balanced, before someone decides to exploit it and discredit the voting system. As far as single player campaign to test out the API, I didn't think of the use case of a live group using the virtual tabletop as a prop in their game, this is a compelling argument against it. The idea of javascript API adding to the server overhead is strange, as javascript is normally client side computed, not server side, but with an AJAX style dialogue it could add some overhead. If the scripts are all being run server side and their effects are only being exposed via flash, then the overhead could be huge, especially if there is no prevention of messy / inefficient scripting. Subscribing for 1 month has been something on my mind, but I tend to take my time tinkering as the mood hits me. Truth be told I will probably do that, then pay for a year if I am not disappointed, and take my time seeing what can really be done. It would be nice to do this on someone else's dime, then pay for time I am actually playing games, but I have always enjoyed the setup more than the running / gaming. Thank you all for your quick responses

TwinHerder said: Brian, What I meant was if a person wanted to pay 5$ a month, and they wanted to make it appear that a feature is more popular than it is, then they could create a new account every month, and get 60 votes a year, rather than the normal subscribers 6. This should be balanced, before someone decides to exploit it and discredit the voting system. Since an account must be active at either of subscriber or mentor level to have it's votes show up, the only way they could put 60 votes in is by maintaining 10 accounts concurrently. Additionally, since you can only vote on a suggestion once per account, they could only get 10 bumps per suggestion with 10 accounts. While I can see that this is technically exploitable, in reality I think it is already pretty self balancing, and if someone really wants to fork over an extra $50 per month to highlight something extra important to them I don't have a problem with it. There isn't anything on the suggestions forum that I don't want (possible exception for the "popularity contest" suggestions), and more money in the hands of Roll20 is just as likely to cause them to do things I have voted for, regardless of the source. The idea of javascript API adding to the server overhead is strange, as javascript is normally client side computed, not server side, but with an AJAX style dialogue it could add some overhead. If the scripts are all being run server side and their effects are only being exposed via flash, then the overhead could be huge, especially if there is no prevention of messy / inefficient scripting. The API is server-side javascript, with a sandbox for each campaign. It communicates changes to the state of the campaign by setting data in a (near) realtime database called Firebase. The game servers receive these state changes by the data communicated down to the clients from the Firebase for that campaign. Graphics are all handled in client side OpenGL ES (or equivalent), so no flash. There are systems in place that will prevent an API server from running away via heartbeats and other metrics. There is nothing beyond that to prevent messy / inefficient code. I imagine much of the cost is associated with the increased traffic of reads and writes to Firebase and in the continued execution of the many events that occur as a result of multiple players all performing actions in the system. Subscribing for 1 month has been something on my mind, but I tend to take my time tinkering as the mood hits me. Truth be told I will probably do that, then pay for a year if I am not disappointed, and take my time seeing what can really be done. It would be nice to do this on someone else's dime, then pay for time I am actually playing games, but I have always enjoyed the setup more than the running / gaming. If the setup is the part you enjoy, then paying for it will be paying for enjoyment! =D If you're on the fence, feel free to PM me and I'll invite you to a sandbox campaign where you can tinker a bit.

TwinHerder said: The idea of javascript API adding to the server overhead is strange, as javascript is normally client side computed, not server side, but with an AJAX style dialogue it could add some overhead. If the scripts are all being run server side and their effects are only being exposed via flash, then the overhead could be huge, especially if there is no prevention of messy / inefficient scripting. Normally, yes, JS is client-side. But the API has to synchronize any changes with all of the players in the game, meaning it has to update a database, and thus at minimum must talk to a server-side technology. (In truth, Roll20 also uses some JS on the server-side but that's neither here nor there.)

So if I subscribe, vote on things, and then don't maintain a subscription my votes will disappear?

Correct.