(SugarCube 2.27.0 & Twine2) — Unlocking extra content for Kickstarter backers

Question

I'd like to unlock extra content in my game for those people who pledged to support the game's development in my kickstarter campaign last year. I have a brief idea of how I'd implement this but I'm struggling to figure out how to actually do so.

When players launch the game they get a "title screen" that currently pulls a website in with the latest release notes and also has a button to start a new game or load a previous save.

I want to add a third button there to the effect of "supporter perks" or whatever and that takes the player to a page explaining what that's talking about and providing an input box for them to enter the email address they used on kickstarter.

Then, the game would check a text file I have uploaded to another server for that email address and if valid change the $supporter flag to true which would unlock whatever content is contingent upon that being the case.

I recognise this isn't probably the most secure method and someone could spoof it relatively easily, but I'm fine operating on the honour system and would like a more overt way of demonstrating my thanks to kickstarter/patreon supporters who have helped the game from the beginning.

This seems to be the easiest way I can think of to accomplish this but I'm open if anyone else has a better idea instead? Thanks tons.

Answer 1

What you want to do is possible, though you are correct about the various security issues inherent in your chosen method.

IME, what most do in your situation is to simply make two builds: a public one, with the basics, and a backer/patron-only build, with all the extras.  Is the some reason why this, which is far simpler than what you're thinking of, is unpalatable?

Comments

Yeah that was the other idea but I have misgivings about maintaining two builds for a variety of reasons. I'd prefer a single build if it can be accomplished, but I'm not sure of how to do so within Twine itself.

---

Unless you have some sort of server and log-in / authentication system, I would also strongly recommend separate releases. A CLI compiler like Tweego (or Entwine, Twee2, etc) will make adding the appropriate files to the backer release easy enough. Any content running client side will be incredibly easy to get to if it's just sectioned off by a client-side email check anyway. But also, you shouldn't post your backer's emails like that anyway; I would be real mad if someone did that with my contact info. 

Relying on the honor system is one thing, publishing a list of user email addresses in a client-accessible text file is a completely different bad idea. 

---

> A CLI compiler like Tweego (or Entwine, Twee2, etc) will make adding the appropriate files to the backer release easy enough.

^ This.  Even if you want to primarily use Twine 2, you can relatively easily use Tweego (maybe the others mentioned by Chapel) to stitch two Twine 2 projects together (i.e. your main/public one and one which is just the backer/patron kit).

 

> But also, you shouldn't post your backer's emails like that anyway; I would be real mad if someone did that with my contact info.

> Relying on the honor system is one thing, publishing a list of user email addresses in a client-accessible text file is a completely different bad idea.

^ Also, this.  Please do not do that.  Unless you've communicated with each and every one of you backers/patrons and they're okay with you publicly hosting their e-mail addresses online, that's a very poor thing to do.  You cannot know if the e-mail you have on file is semi-private or not.  Beyond that, people get enough spam without any outside help.

If you were going to do something like this, the way to do it would be to generate a unique string for each user (e.g. a GUID) that's associated with their e-mail address (kept in a file which is on your local machine only) and use those strings.  That said, this is getting rather more complicated than what I outlined above.

---

I had thought about it from the perspective of someone messing with host files and changing where the game should look for a domain but thanks, it hadn't occurred to me that someone might try downloading the file.

My reservations against maintaining separate builds is that people are downloading the game through multiple different sources and I'm reticent to force people who want the backer content to only download it through one place if they've redeemed a code elsewhere. It seems like an inconvenience to insist and as a customer I would be annoyed about it if a game made me jump through that sort of a hoop.

---

Couldn't you just give them a password? Encrypt it and check if it matches the encrypted password on your site?

It's hardly secure but, unless you get an actual login system, it's not going to be.

---

> Couldn't you just give them a password? Encrypt it and check if it matches the encrypted password on your site?

That's actually what I've decided to do ultimately; as I am not super fussed about anyone who tries to circumvent the code and am fine leaving it with the honour system, that seems like an easy enough way to put a bit of a wall up to those who haven't backed the game earlier.