Making JSON responses even smaller... just an idea

I agree this is much more compact.

{
    "games": {
        p: ["name", "description", "activated", "points", "thumb"],
        d: [
            ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
            ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
        ]
    }
}

But wait, you could optimize it further, do you really need the "games" object? this is even smaller!

{
    p: ["name", "description", "activated", "points", "thumb"],
    d: [
        ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
        ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
    ]
}

And really, whats the point of the "p" and "d" and the object that contains, i know that the property names are going to be first, and my data is going to be second?

[
    ["name", "description", "activated", "points", "thumb"],
    ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
    ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
]

And those array and object markers are just getting in the way, save a few more bytes!

"name", "description", "activated", "points", "thumb"
"Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"
"Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"

Wait... this format already exists. It is CSV. And its been around since the mid 1960's. And its part of the reason why XML and JSON were invented in the first place. JSON and XML add flexibility to the objects being stored and to make them more human readable than tightly packed binary objects. Are you really that worried about the size of the data going over the pipe? If you are (if that is, in fact, your bottleneck) then there are a bunch of different ways to address that problem.

But, personally, I think you should use the technology and the tools for what they are made for, and what they excel at doing.

You're trying to use a hammer to screw in a screw... You'll get it in the wall, but it wont be pretty or pleasant for either party involved.

Find a pattern that solves your problem, not the other way around.

From experience, the primary reason behind using text based formats is that they are easy for a human (with unsophisticated tools) to read and debug. [For instance, I consider XML a huge no-go for most tasks].

A quite old reference about why we use text formats, although still worth a serious read is this chapter of The Art of Unix Programming.

So you must aim for clarity, not size. Aiming for size is a case of premature optimization.

If you are worried about bandwidth or storage, consider compressing the data. Text formats lend themselves well to fast and powerful compression, to the point where technically, they are not inferior to binary formats sizewise. Also, you separate the concerns of 1/ representing data conveniently 2/ transferring data efficiently.

I'm not knowledgeable in this domain, but I'm ready to bet there are 1/ Javascript libraries for compression 2/ systematic ways to have the data compressed at the protocol level.

Last, if you are worried about performance, well, you'd rather have a compelling reason (and solid profiling data) for giving up the comfort that text based formats provide.