Nice graphics, but I'd like to see another one more. The (#death/#alive vs time).
If all the pipes had the same difficulty and all the players had the same ability, then the only factor to pass a pipe is luck and a x% of the players die just before each pipe and the graphic is a row of equal mountains.
But some of the pipes are more difficult or easy, so they will have a bigger % or smaller % of deaths, and higher or lower mountains.
And some players will have more ability. If, for examples noob, have a 1/3 chance of diying per pipe and pros has a 1/20 chance of dying per pipe, then the first 3 or 6 mountings will be big and full of noobs carcasses, and the other mountains will be much smaller. (In real word there is not a binary noob-pro classification, but it's easy to explain with this toy model.)
>the game no longer trusts the client with coordinates and instead the client sends a list of jumps/flaps made by the player during the attempt. This means the attempts of other players are no longer seen in real time, but rather you see "recordings" instead.
They were never seen in "real time" anyway. Communicating more facts that could have been derived from a smaller set of different facts does not make it any less of a "recording" of facts or more "real time". Fewer facts to communicate may enable lower latency in their delivery, which is a better definition of "real time". Would it be any less of a "recording" to send the rendered pixels of the fish? I would argue the opposite.
Perhaps the point was that much more time was passing before elements of this list in the new format were sent, is that true?
I love these kinds of posts. Interesting way of mining data from a product that isn't yours :). Are there any negatives to this type of approach (other than potentially pissing off the dev)?
The author was pretty courteous in the method he used to log the data IMO.
1) He only connected to one of the 'MMO' servers instead of multiple instances
2) Only established 1 long-living (Websocket) connection which is basically like having 1 (idle) player on the server. At the rate that other players were connecting, he likely added little to no real load
The author seems to have logged all the data in a 4 hour period connecting to only one server so it should be pretty easy to do the logging yourself with the current site. It also seems to be as simple as just opening 1 Websocket connection to the target server.
Amazing how such absolutely bare-bones basic games succeed. Way back on the Atari 2600 the all-time most successful game was Kaboom! which was a clown firing a cannon at a target. You got to raise/lower the cannon. That's it!
If all the pipes had the same difficulty and all the players had the same ability, then the only factor to pass a pipe is luck and a x% of the players die just before each pipe and the graphic is a row of equal mountains.
But some of the pipes are more difficult or easy, so they will have a bigger % or smaller % of deaths, and higher or lower mountains.
And some players will have more ability. If, for examples noob, have a 1/3 chance of diying per pipe and pros has a 1/20 chance of dying per pipe, then the first 3 or 6 mountings will be big and full of noobs carcasses, and the other mountains will be much smaller. (In real word there is not a binary noob-pro classification, but it's easy to explain with this toy model.)