Privacy Policy

2.1 Waitlist email. If you type your email into a signup form and confirm it, we store: the address, the signup time, which form you used, and which language the page was in. We also keep a little internal bookkeeping — timestamps for when each step (sent, confirmed, unsubscribed) happened. Purpose: sending you occasional project updates and the announcement when the first public version is out. Legal basis: your consent — given when you confirm the signup email, withdrawn the moment you unsubscribe.

2.2 Support messages. If you use the support section to send a note with your contribution, we store the wallet and transaction ID you give us, the amount you optionally mention, an email address only if you choose to leave one, the language you used, and a supporter code we generate so we can recognize your message later. A transaction ID is public information on that currency's own ledger — it can already be traced back to the sending wallet by anyone, not only us. We may also keep a short internal note of our own about the message; that note is for us and isn't shared. We keep all of this to say thank you and to recognize early supporters at launch. Legal basis: your consent.

2.3 Server logs. Like almost every website, our server keeps technical logs (IP address, browser type, requested page, timestamp) for security and abuse prevention. We don't currently promise a fixed, automatic deletion schedule for them. Legal basis: legitimate interest in keeping the site running and safe.

2.4 Analytics. We count visits to this public site with a small counter of our own, built into the site and running on our own server: no analytics service, no third-party script, and it sets no cookie. For each page you open we record the day (not the time); which page it was, by its name and never its address, so the personal links in our emails are never recorded; the language version of the site you opened; the website that linked you here (only its domain name, never the full address); if the link you followed carried campaign tags, those three tags (which source, which medium, which campaign); your country as Cloudflare reports it; and whether you are on a phone, a tablet or a computer. To count how many different people came without using a cookie, we combine your IP address and browser type with a random key that is replaced every day, run them through a one-way function, and store only the result; your IP address itself is never stored. When the day is over, its key is deleted, so visits on different days cannot be linked to each other, and the stored result can no longer be traced back to any address. A small script of ours also notes, once per page, that someone is there — the first time you move the mouse, touch the screen, scroll or press a key — and counts presses of three buttons in the support section (SubscribeStar, showing the wallet addresses, copying an address); each such note keeps only the day, what happened, the page's name and the same daily one-way result. With no such result at all, we count how many times the game's sign-in and registration pages are opened — nothing else of the game is counted — and how many pages known bots open. These records are deleted automatically after 30 days. Cloudflare (named in §5) also sees aggregate traffic simply by proxying the site, the same way any CDN does. Legal basis: legitimate interest in knowing, in aggregate, how many people find the site, how they get here and what they reach for.

2.5 Age confirmation. When you confirm you're 18+, that choice is stored in a session on our server — not in your browser's local storage. For this check specifically, your browser only holds a random session identifier, not the flag itself. While that session is active (about two hours of inactivity, or until you clear cookies), the same database row also carries the ordinary technical details any session does — an IP address, a browser type. We don't keep a separate, permanent list of who has confirmed: there's no account, name or email tied to this flag, and the whole row disappears automatically once the session ends. The check doesn't create that session; it writes into the same session §2.6 describes, which every visit gets anyway.

2.6 Session and cookies. This applies to every visit — even one where you never fill in a form or confirm your age. Our server gives each visit an ordinary web session: two small cookies in your browser (a random session identifier, and a matching anti-forgery token that stops another site from submitting our forms as you), and one row in a session table on our side holding that identifier, your IP address, your browser type and the time of your last request. It exists so forms can be submitted safely and so the 18+ confirmation in §2.5 can be remembered between pages; it is not analytics. Beyond those four things, a session row on either host keeps the working memory of the pages you open: our copy of that anti-forgery token; the address of the last page you opened, which can be a link from one of our emails; on this site, which of its languages you are reading; and, for the one page that follows a form you send, a note on how it went, the form's error messages and what you typed into it — never a password, but an email address or a username if that is what you typed. The game host keeps its own separate session — the two hosts deliberately do not share cookies, so signing in on one does not sign you in on the other — and once you sign in there, that host's session row also records which account it belongs to; if you tick "Remember me", your browser keeps one more cookie for that host, one that outlives the session row so it can sign you in again without asking for your password — its matching half is stored on the account row itself (§2.7) for as long as that cookie can be used. On the game host the row also keeps what the game needs from one screen to the next: that you confirmed the 18+ content notice in this session, and which version of its text you confirmed; where you were heading when that notice or the sign-in screen stopped you, so that you can be sent on there; what the game last showed you of the hero's money and body, and which quests it has already announced to you, so that it only ever tells you what has changed; and, for one screen, which items the hero has just picked up. Session rows are deleted automatically after about two hours of inactivity, and signing out clears the row and that cookie together; everything a row keeps goes with it, and a one-page note goes sooner, once its page has been shown. Three things clear every other session the account has open, all at once rather than one by one: setting a new password from a reset link, changing the password in account settings, and the "Sign out everywhere" button on that same screen. The last two leave the device you pressed them on signed in, which is the whole difference between them and signing out. That is the "you are signed out on every other device" those screens promise, done rather than said. Legal basis: legitimate interest in a site whose forms work and cannot be abused, and, for the signed-in part, performing the agreement §2.7 describes.

2.7 Your game account. Creating an account in the game stores what you type — the username you chose (it is also your display name in the game, so treat it as public), a one-way hash of your password, and an email address only if you decide to give one — plus the bookkeeping any row like that needs. We never store the password itself and cannot read it: a hash does not turn back. Nothing further is asked for at any point — no real name, no date of birth, no payment details. The bookkeeping, in full: an internal row number that identifies the account in our database; the same name folded to lower case, which is what makes two spellings of one name the same account and keeps it unique; when the account was created and when it last changed; the server half of that cookie §2.6 mentions, written when you tick "Remember me" and replaced with a fresh random value both when you sign out and whenever a new password is set — replaced rather than emptied, which is what makes any cookie still carrying the old value useless, and it happens on a password reset whether or not you ever asked to be remembered; a flag marking the one or two accounts allowed into the admin panel; and a column for the date an address was confirmed, filled when you follow one of the confirmation links described below. Three further columns hold what you set for yourself in the settings screen, and nothing goes into any of them until you set it: which language you chose to read the game in, which is also the language the two address emails below are written in; the three game options that screen offers — how fast lines of text appear, whether they advance on their own, and whether on-screen motion is reduced — and only those three, since anything else found in that column is discarded both when we read it and when we write it; and an email address that is waiting to be confirmed. That last one is deliberately not the account's address, and the difference is the point of it: when you add or change an address in the settings screen we keep what you typed in a column of its own and send a confirmation link to it, while the address already on the account goes on working until that link is followed. So a change asked for by somebody who has got into your account cannot carry the account off while you still hold the old mailbox — and you are told it was asked for, because whenever the account already has an address at all, confirmed or not, a notice goes to that address the moment a change is requested, naming the new address in full: a warning that does not say what is being changed is not a warning anyone can act on. The waiting address stops being stored as soon as the link is followed — it becomes the account's address, and that is the moment the confirmation date above records — and asking for a different address before then replaces it rather than adding to it, which is also what makes the earlier link stop working. An address given at registration and never confirmed is the same state reached by another road: it sits in the account's own address column, unconfirmed, until the same kind of link is followed. Be clear about what that does and does not mean today, because it is the opposite of what you might expect: a reset link asked for on that account is still sent to that address, since recovery looks an address up without asking whether anyone ever confirmed it. So an unconfirmed address does get you back into the account — what nobody has established is that the mailbox is yours and that our mail arrives in it, which is what confirming it settles, and until then a lost password may turn out to have no way back after all. We intend to make recovery require a confirmed address; when it does, this paragraph will say so instead. Nothing puts a clock on the waiting address itself — the link expires, the address does not expire with it, and it stays until a later change replaces it, a confirmation moves it, or the account is deleted. Purpose: signing you in, keeping your progress attached to something, and showing you the game the way you asked for it. We send mail only where there is an address to send it to: a password-reset link when you ask for one, a confirmation link to an address you have just given us, and the change notice to the address already on the account. All three are transactional — each one answers something that just happened on this account — and none of them is a mailing (§6). Legal basis: performing the agreement you enter into by creating the account (the Terms of Service), which is also what the language and the game options rest on: you set them, and we cannot show you the game the way you asked without keeping them. The address is the exception: it is optional, it rests on your consent, and you can ask us to remove it without losing the account. One consequence of keeping it is worth saying plainly rather than leaving to be discovered: an address can belong to only one account, so the registration form has to tell you when the one you typed is already in use — which means that form can be used to find out whether some address has an account here. We accept that, because the alternatives are worse: a signup that fails with no explanation, or one that quietly drops the address and leaves you believing you can recover the account when you cannot. It is the only place we answer that question. Asking for a reset link never does, whatever address you type into it. What leaving it out gets you, and what it costs: the row then says nothing about you beyond a name you picked yourself, the preferences you set for yourself, and the times it was written, though the acceptance records in §2.8 do carry the IP address you accepted from, which is the one thing on file that points at a place. And no address means no password reset, no way for us to check that a request about the account really comes from you (§6), and no way to reach you if something about the account needs saying. The account itself lives on the game host, on the same servers and through the same processors §3 and §5 describe.

2.8 The record of what you accepted. Creating an account requires three separate confirmations: that you are 18 or older, that you accept the Terms of Service, and that you have read this policy. Each one is stored as its own record — which of the three it was, which version of that document you accepted, the moment you accepted it, and the IP address the request reached us from. The bookkeeping around each record, in full: an internal row number for the record itself, the row number of the account it belongs to, and when the record was written and when it last changed — which for every record we make today is the same moment as the acceptance, since nothing edits one afterwards. The version and the time are what make such a record mean anything: a confirmation that does not say what was confirmed, or when, proves nothing at all. The IP address is kept alongside them, and it is a deliberate difference from the waitlist (§2.1), where we keep no IP address of a subscriber at all — here the record has to be able to stand up years later, and the address is part of what was seen at the time. We do not treat it as proof of where you were: it arrives in a header that networks in front of us can set, so it is a supporting detail rather than an identification. It is never used to profile you and never shared for another purpose. Accepting a new version of a document adds a new record; it does not overwrite the old one, so the history of what you agreed to stays intact. We keep these records for as long as the account exists (§4). Legal basis: our legitimate interest in being able to show that an adult accepted these documents before we let them in, and — for the age confirmation — the obligation not to serve adult content to minors that §7 describes.

2.9 Early access. If your account is given early access to the game (§08 of the Terms of Service), we keep one record of it on the account: from which date and until which date it runs, or that it has no end date; where it came from — a SubscribeStar subscription, a crypto contribution, or a gift from us; and, if we write one, a short note for ourselves — usually your name on SubscribeStar, which is how we know which subscription belongs to which account. None of it reaches us from SubscribeStar automatically: you send us your username, we check your subscription on SubscribeStar's own pages, and we enter the record by hand. The bookkeeping, in full: an internal row number, the row number of the account, the name of the right, and when the record was written and when it last changed. Extending early access changes the dates on the same record, and closing it sets the end to that moment instead of deleting the record, so the record also says when your early access ended. Purpose: deciding whether your account can open the early version of the game, and showing you until when. Legal basis: performing the agreement you enter into by creating the account, which is what §08 of the Terms describes.

2.10 Your saved game. Playing keeps your progress on the account in at most two records: the saved game, and your playthrough of the prologue. Each holds the story as you left it: the name you gave the hero when the prologue asked for one, what the story keeps track of about your choices and about the hero, where in the story you are, and the in-game day and time of day; the saved game also keeps the chapter, and both keep which version of the game they were started on. Nothing in them is about you beyond what you typed or chose inside the game and the times they were written. The bookkeeping, in full: an internal row number, the row number of the account, a number saying which format the record is written in, and when it was written and when it last changed. Starting a new game replaces what you had rather than adding to it. Purpose: letting you continue where you stopped. Legal basis: performing the agreement you enter into by creating the account.