6 ms·

I don't think you even need a backend. Just base64 encode the gamestate and include that in the url being shared. It will only work if the gamestate is small en

• ac2u 4y ago
  yeah you should have plenty of wiggle room as a query string parameter, which could be useful if you want to see how your game is played (time between turns etc) as it'll be logged on your web server. If you don't care, you could always use a client side url fragment.
• CBarkleyU 4y ago
  Unfortunately not possible, as the JSON is quite long. I've even gone the extra mile to calculate the average entropy of my game-state (its just numbers) to see how much I could save by compressing it, but to no avail. It would way too long, even compressed. Thanks for the suggestion though!
  • xwdv 4y ago
    Depending on the game you could precalculate every possible game state and assign each one an ID then load the game off of that.
    • CBarkleyU 4y ago
      Also impossible, unfortunately. But a fun idea, nontheless
    • elecush 4y ago
      I used to think this is how NES worked x)
  • packetslave 4y ago
    how long is "way too long"? URLs (including query parameters) can be up to 4k. Does it have to be JSON? Can you use a binary format like protobuf, BSON, etc.? you're likely to get much better compression.
    • CBarkleyU 4y ago
      > how long is "way too long"? How long would a link that you receive on iMessage/WhatsApp have to be before you would reply with a "?" I'm quite open to testing out different ways to keep all of this frontend only (I would much prefer it tbh). The JSONs contain around 2000 integer data points, which could theoretically be compressed by removing redundant information, but seeing how there is little rhyme or reason to the datapoints, there will be sequences with little redundancies which will blow up the end result. I think?
      • srcreigh 4y ago
        With base64 you have around 6 bits per character. M$ edge max url length is shortest now at about 2038 characters. If you can drop support for edge, the next highest is Android browser at 8k. 8k characters gives you around 6000 bytes to encode into the URL. Unless your 2000 ints are utterly random and use the full spectrum of 4-8 byte integers, im sure you can find a way to compress them into 6000 bytes.
  • x86x87 4y ago
    i think it's possible. this is an example: https://github.com/topaz/paste https://github.com/topaz/paste in the big brain bucket, you could generate the url and use and url shortener
    • CBarkleyU 4y ago
      Many thanks for the input, but as I've said above, I roughly calculated the entropy of an average state and without some kind of magic there just is not enough wiggle room. I've tried your example and it gave me a URL with ~24,000 characters (down from around 30,000)
• alberth 4y ago
  Have you tried compressing your JSON before base64 encoding it. https://github.com/KilledByAPixel/JSONCrush https://github.com/KilledByAPixel/JSONCrush Agreed with GP, it seems like you don't even need a backend.
  • CBarkleyU 4y ago
    Even when compressing thje JSON before encoding it, it's still way too long for a shareable link. As I've said below, I've roughly calculated the entropy and even had a quick look around if there was any cool research out there regarding compressing the type of data I have (just loads of integers) (and there is cool research out there, just no magic, unfortunately).
    • 8note 4y ago
      JSON might be the problem though? The string representation of integers could easily take more space than storing them as ints
      • CBarkleyU 4y ago
        For sure, but how much impact does it actually have? Let's say I have around 2000 datapoints, all of them integers, little rhyme or reason to their sequence. I'm very open for ideas on how to squeeze that down to a link that wouldnt (a) deter you from sharing that link with family and friends and (b) deter your family and friends from clicking that link.
        • woleium 4y ago
          Why not use an url shortener?