Is it possible to have an online multiplayer leaderboard for an Inform game?

As the title says. Assume the Inform game is running online (perhaps with Vorple) and uses a table to store high scores and names, say. Various people would play from their browsers and try to compete for a high score. But Inform / Vorple / Quixe saves its info in localStorage. Would it instead be possible for the Inform game to access a properly defined Inform file / table that’s online elsewhere, and read from and write to it?

And then the important follow-up question: if yes, how?

I’ve got a goofy idea for an IFComp game where I think an online leaderboard / table of high scores would be fun. But my web skills for this sort of thing are nonexistent. I’d appreciate tech wizardry anyone could offer!

5 Likes

Vorple can do anything with Javascript. So it’s simplest to think of this as a Javascript problem. Have a server somewhere which can accept web requests and record the score for later display.

This is not a simple problem, but it’s simpler if Inform isn’t involved at all except through Vorple making JS calls. Don’t try to bring I7 tables into it.

8 Likes

It’s clunkier, but you could take the per-game text that you wanted to appear in the leaderboard and generate a checksum for it that also incorporated some secret constant number in the game (number, not text, to make glulx-strings not see it). Output the text and checksum and tell the user to copy-paste it and submit it at: [some url].

The web form submits to a server that knows the secret and can verify the checksum, rejecting results that don’t match. It’s not secure but reverse-engineering your hashing-algorithm and finding the salt would be a lot of bother to go to just to be a griefer on an IF game leaderboard.

(The point of this is that it allows forgoing Vorple if you wanted to. The javascript approach would make for a better user experience.)

5 Likes

Ok, cool. Kind of what I expected.

Would anyone out there be interested and willing to collaborate to make this a reality? (And to be clear, for all the JS stuff, I’d pretty much be cheering from the stands. I could set up a test case on the Vorple side, though.) If so, please DM me–I’m happy to describe the project / vision more, etc.

Thanks!

3 Likes

If this works well and becomes user friendly to implement, it would be quite a milestone for IF.

2 Likes

The only way I see it becoming user friendly would be if someone took on creating and owning a website that would allow creating leaderboards in general (maybe as one specific case of a more general abstraction of text-stuff) and receiving the Javascript API requests, such that an individual author would only need to create an account there and would be given the URL they would plunk into configuration of a Javascript library that could talk to it.

The API approach would be easier for a griefer to figure out how to abuse than the checksum approach I described above, which would require variously, extracting the ulx-file from a gblorb, reverse-compiling it into I6, and then reading and tracing through that I6 to figure out the checksum generation details, providing some (pseudo-)security through obscurity.

So I imagine one would want it to be the case that:

  • to create a leaderboard, the game author must create an account, with email verification
  • when a player submits an entry, email is sent to the game author (who does have an email-verified account) for approval before it’s posted

(It’d be better to also make players create accounts, with email verification, to submit their leaderboard entry, but that would probably take it into the territory of being too much overhead for most people to bother.)

Edited to add: eh, scratch that. It’s more bother to code, but appropriate use of nonces for authorization could make it reasonably secure without all this human involvement.

1 Like

Yeah, I might go so far as to say I think it shouldn’t be user-friendly. It’s honestly pretty trivial to code a basic leaderboard, and I’ve started writing multiplayer stuff for Twine several times, but then stopped when I remembered that I wouldn’t want to drop an unsuspecting author into the headache of moderation and dealing with attacks against a server.

Kongregate is obviously a bigger target, but when you’d put a small game up there the leaderboard would be filled with junk within a matter of days. I think it’s possible to do somewhat better on security than they did, but you have to authorize the browser to send leaderboard entries and I don’t see how to keep that from being trivially hackable when the browser is in the full control of the player/user. Though security isn’t my field, so… maybe I’m missing something.

1 Like

With effort, you could make it functionally impossible to submit spam to the leaderboard without writing a bot to play the game. My “reasonably secure” above was imagining someone wouldn’t go to that length, maybe a bad assumption. It’s certainly a bad assumption for anything with a huge number of users, but I was counting on the obscurity of IF in general providing some (pseudo-)security by obscurity.

Much as I hate them, a CAPTCHA is probably a better and much easier approach than anything I had been thinking of (I would’ve thought of that sooner had my hatred of them not created a mental block).

1 Like

Hmm. How would you require writing a bot to play the game? If the game can call a javascript function to submit a score to the leaderboard, can’t anyone just pop open a debugger and call that code manually? Unless you’re sending the whole command history and having the server run the game to reconstruct the score? But that seems like it’d be trivially vulnerable to people sending massive commands to bog down your server and cost you money or shut it down, depending on how you set it up.

Anyway. Yeah, IF is probably niche enough to be ok nearly all of the time. But posting “just drop this code into your Inform (or Twine) game, here’s how to set up a server, it only takes 15 minutes, it’s easy!” seemed like juuust enough of a “do I really want to drop unsuspecting authors into that?” kind of thing that I haven’t made time to seriously dig into trying to make something like this…

2 Likes

It’s a pain, but:

  • at game start, randomly generate a session id shared between client and server
  • the client sends the session id at each step and the server checks at each step that this is a valid current session
  • if the game has any randomness, it will have been written to use Xorshift and seed the random number generator with a numeric representation of the session id. Meanwhile, the server starts running the game and… I’m not thinking of an easier way to get the session ID to the game than using the current development version of Inform that can read files from its blorb, then we custom-generate a blorb with that file in place, and start running it; the game knows to take the seed from that file if it exists.
  • With each command, client-side JS stores the current time in a variable and generates a hash of the command with the current time; it also hashes the command output with that timestamp
  • the client stores up a representation of the command in plaintext, its timestamp, and the two hashed values until it has say, twenty (or the game’s over), then sends it to the server (I’m gambling that this will put enough time between requests to obviate needing to implement a queue on the server side)
  • when a server finally gets this bolus of commands/timestamps/hashes, it verifies that the timestamps are in ascending order, then for each, it verifies the command hash checks out, then executes the command in its local running version of the game, captures the output, and hashes it with the corresponding timestamp from the client to verify the corresponding hashed value checks out. If it doesn’t, it considers this session invalid.

The timestamp history is also stored on a per session basis and if it looks inhumanly fast or inhumanly consistent, the session is marked invalid.

The server both throttles requests on a per IP basis and it silently ignores requests from an invalid session.

There are probably a couple of ways this is fragile that I’m not thinking of right now that would need fixing to actually get something like it into production. But I’m pretty sure some strategy resembling this could be made to work, for values of “work” that accept that at some point or another someone would be told the leaderboard couldn’t be updated at the end of the game, despite them being a good-faith user.

So, like I said: a CAPTCHA is much easier and better.

Yeah, but this risk is common to any server accessible without authorization. (And even with authorization, you still need a strategy for potential DDOSes against your authorization mechanism.)

But posting “just drop this code into your Inform (or Twine) game, here’s how to set up a server, it only takes 15 minutes, it’s easy!” seemed like juuust enough of a “do I really want to drop unsuspecting authors into that?” kind of thing

Yeah, any scheme telling authors “first, set up your own web server” would cause more misery than happiness. Hence, my description above that to actually be user-friendly someone would have to build this as a public service out of the goodness of their heart, and take on all the technical headaches of development and administration so it’d be no more difficult for an author than: creating an account; creating their leaderboard; being told its URL; including some (provided) javascript in their Vorple setup; configuring the URL on the client side. Not it!

4 Likes

People trying to provide the IF community with what they need seems to happen in the IF world quite a lot, so there is a slight chance I think(?). However, it will no doubt depend a lot on the demand and workload. Could be an interesting experiment and if successful, it could be made more user friendly later. Easy for me to say as I won’t be able to contribute :wink:

2 Likes