Various servers for SS13 have taken to using a donation system, often patreon for funding server hosting. For the tgstation server, we've been wanting to implement cosmetic benefits for server donators for a while. The BYOND subscription system would work perfectly, but lacks donation tiers for tiered benefits.
Basically, I'd like to have the hub owner be able to set various reward tiers for differing payment levels, similar to patreon, as well as be able to get the tier information via CheckPassport() or a similar proc.
ID:2182467
 Dec 5 2016, 11:09 pm
|
|||||||
| |||||||
Lummox JR wrote:
Color me intrigued. http://www.byond.com/games/MrStonedOne/tgstation13 We already have the hub entry ready. (and i've already figured out the code required to allow us to use that hub for passport checks while still remaining on the ss13 hub) (now that I think about it, we also might use the other hub entry we have for metals and scrap the tgstation13 one since that one already has it's own account) (or see about getting you to move the metals one to the tgstation account once I find where I put the password for it) How it works on patreon is the user just picks a tier or they can choose their own amount, (and they can edit the amount for each tier if they want to go higher). It is displayed as rows with the lowest priced tier first, then choose your own, then the rest of the tiers. I'd love if I could move that system over to byond so you guys get the fee instead of patreon since it's about the same. Landing page, https://www.patreon.com/tgstation Payment page, http://i.imgur.com/mcGUkzL.png Hub Page side: If you wanted to apply that model completely then it would start with a subscription type dropdown on the hub settings page, choosing between single tier, multi tier, and "Pay What You Want". For multi-tier you would add an extra column to the price selector called tier that would be a drop down choosing between 1 and n with n being some sane number of options (or, add a textbox for some id that is passed to the game, but I think the drop down will be the least hassle), and finally add a text box for describing what you get with that tier. (this might actually need to be a seperate list since monthly and semiannual payments for the same tier would get the same benefits.) For PWYW you would just do the same system as multi-tier, but also add a min payment and default payment option. If you want to keep it simple, drop the drop down and instead pop checkbox by the add payment amounts for one of the two extra options and only implement one. You could even still implement both if you made multi-tier the default (at say tier 5 to allow for existing games that use this to add options above and below, or tier 1 for maximum backward compatibility) and have the checkbox be for pay what you want. User side: For multi-tier just add a drop down of the available tiers, then show the price drop down after one is selected along with the text. You could even do a table of tiers as rows and term prices as columns along with the text of benefits. (maybe if the text is too long add a show more button that expands it as a sub row that takes the same horizontal space as a full row.) For PWYW you would just give them a text field to select the dollar amount and show the rewards above or below it as some list of rows. (or just do the same thing you do for multi-tier, then add some extra row for picking your amount and automatically apply the right tier.) For the game server side, returning the tier number in CheckPassport() will work. The rest is just ferrying info to and from databases. | |
I don't think CheckPassport() could be used here, as it already returns the number of days left in a standard subscription (-1 for lifetime), having it return a tier number would conflict with that. There would need to be something in place to tell the difference.
| |
Adding another argument to CheckPassport() would solve that.
So it would be CheckPassport(passport_identifier,check_tier) where setting check_tier to true would return the tier if the person is subscribed and false if they are not, while leaving it unset or setting it to false would return the number of days remaining. Alternatively, a separate proc could be added, but since the majority of its function would be identical to CheckPassport(), I don't think it's necessary. | |
Okay, I've been looking into this, and overall it seems doable. That isn't to say this is on the radar for 512, although I'm not opposed to the idea. It does look as if some level of change would be needed to support this. There are two potential ways to go: multiple passports per hub entry, or a single passport with parameters. Multiple passports seems very, very problematic to support, so I'm strongly leaning towards parameters.
Currently, the hub supports a concept of including parameters with hub passport info. These parameters are left blank by the hub and are not used by the client, but they're available. So if I were to add a capability like this to 512 for example, I would do so by opening up parameters to actually be useful. Also, under the current implementation, the presence of a passport match for a lapsed subscription means that parameters are not filled in at all. So both of those things would need to change in 512, and older clients wouldn't be compatible with that. What I'm considering is something where a hub entry can manage multiple subscribable components, which would be tracked separately from the hub entry itself. (Open question: Should all of these secondary items be lifetime-only, or timed?) This is roughly the implementation path I would need: - A way of keeping track of which items were eligible for purchase would have to be added. - The prices and/or durations for each items would also have to be kept somewhere. - The hub would have to track who had purchased what; this would be a rather different setup from what we currently use for tracking hub subscriptions. - The hub software would have to look up those purchases and fill in parameters at the time of passport lookup. In the event there was no subscription match but there was DLC purchased, the hub should act as if there was a subscription but it expired, for backwards-compatibility. - The website would need a GUI for managing these DLC-like items and any purchases. - The website would need changes to the subscription page to allow these purchases. On the whole, all of this is quite approachable. TBH we probably should have done it a few years ago. I can't promise any kind of timeline on this, but I will say I'm considering it, and I might even at least build in some abilities into 512 to allow for such support going forward. (I'm at least putting it on my List so I'll look at it.) Now you may notice that the above has very little to do with this tier idea. That's something I need to work out, still. But I think this structure is needed as the backbone for anything of the sort. | |
I would really really love for you to receive a cut of the money I donate to tgstation instead of patreon, who did me the favour of leaking my email and name to the internet at large.
Looking forward to it | |
In the meantime, If you wanted to, you could work on just adding an option to subscriptions for PWYW (without the reward/tier stuff) as that is all we would really need to be able to start taking servers funds under that system
| |
MrStonedOne wrote:
In the meantime, If you wanted to, you could work on just adding an option to subscriptions for PWYW (without the reward/tier stuff) as that is all we would really need to be able to start taking servers funds under that system That isn't a starting point, though; it's an endpoint. Most of the same infrastructure on the hub/web side would still be needed for that. Probably what I should do is allow for whatever system goes into place to have a PWYW option that counts payments over time. | |
In the interest of getting that percentage of server donations, I've started working up a concept for this. I want to get this moving right away, and the server donation thing does seem like an easy thing to have in place as a first step, even without having to modify the hub. (The site of course would need a change.)
In the meantime, I'd still love suggestions in id:2176950. | |
Obviously you'd have to setup a different hub entry for this to work, although you wouldn't have to use it for the game itself. How do you envision this system working? What would the GUI look like, etc.?
Right now BYOND's subscription system is limited to a per-hub setup: either you're subscribed to the hub entry or you aren't. There might need to be changes in the software itself to allow for a different system, and of course the hub and site would need changes too, but I'm down with the whole revenue stream idea. And moving things in a more DLC-friendly direction wouldn't hurt either.