Ripping alt-j webgame part 1

Intro

So Alt-J’s new album has an aesthetic that’s based on LSD: Dream Emulator, and they made a webGL game for it – you can walk around the violence district in it! Turns out Osamu Sato is credited for the album art and he helped make the webGL game. So I’m gonna have a look at it.

Source code

So the source code is written in Javascript, which I don’t know a lot of but I’ve done my best in looking at it. It’s pretty obfuscated but there’s a bunch of stuff left in there. I played around in the Chrome developer tools and managed to change a few things around, like turning off fog, and I managed to glitch the map once by changing the width. It seems like the game is loading from the original files, or some variation of them, as I found a reference to TMD files, which are PSX model files. After looking at the source some more I found some paths to data, such as sounds and images, and most importantly data.

Data files

The files in the data directory are stored in .mpz format. After looking around the web and the rest of the code for a while I figured out they were MessagePack files but compressed with zlib (the first 2 bytes in every file were 78 DA, which is the start of a zlib header). So I wrote a little python script to decompress them, which resulted in getting text visible in the hex editor, such as “Violence District” (!!). I then converted this now uncompressed MessagePack file to json using msgpack-tools, and it worked! Kind of. There’s still some parts of the data it doesn’t know how to parse. Here’s a sample:

{
    "id": 5,
    "name": "Violence District",
    "map": {
        "w": 110,
        "h": 120,
        "tiles": <ext of type 22 size 52800>
    },
    "tiles": [
        null,
        {
            "model": 39,
            "height": 0,
            "rotate": 0,
            "area": 1,
            "next": 0
        },
        {
            "model": 39,
            "height": 0,
            "rotate": 0,
            "area": 1,
            "next": 0
        },
...

You can see the part where it says <ext of type 22 size 52800> is the part it doesn’t know how to convert.

Okay so it turns out that with MessagePack you can have user-defined extensions which consist of an integer identifier and a byte array. So I guess this application has defined a bunch of custom extensions. They seem to be from 18 to 23? I found an array in the source code that contains all the values, but it also has a bunch more. It’s on line 4514.

I managed to get the converter to spit out a base64 string of each byte array, but the resultant file is not pretty… At least it’s in the file though.