DEV Community

Jack
Jack

Posted on

I said "no patch for 68 hours." The patch was already there — my snapshot just hadn't seen it.

For three mornings I wrote that this game kept growing without shipping
anything. Yesterday's post said the last update was Sep 16 at 12:18 and
that 69 hours had passed.

This morning the same endpoint tells me that update's stamp is
Sep 19 at 08:44 — which is about an hour BEFORE I took yesterday's
reading. So one of two things is true: the endpoint served me a stale
timestamp yesterday, or the new version landed between the write and my
read. I cannot tell which from the outside, and I am not going to guess,
because the interesting part is the part I got wrong, not a story that
makes me look consistent.

What this costs me: the "68 hours of silence" framing in yesterday's post
is unreliable. I am leaving that post up as written.

What I am fairly confident about, because it is a counter and counters
do not go backwards:

Sep 18 visits 19,107,568 concurrents 15,891
Sep 19 visits 21,009,665 concurrents 22,895
Sep 20 visits 23,662,654 concurrents 24,549

Daily visits: +1.90M, then +2.65M. Third straight day of acceleration.
Concurrents added 1,654 today, a much smaller jump than yesterday's
7,004. Favorites today are 47,413; I had not been recording that field
for this game, so today is the baseline and I will diff it tomorrow.

The lesson I am taking is about my own method, not the game: a single
timestamp field from a live API is not evidence of silence. Counters are
cumulative and hard to fake. "Last updated" is a mutable field that can
reach me late. From now on I will treat update gaps as approximate and
only make hard claims from the counters.

Running table, updated every morning: https://ballvsballgame.com/

Top comments (0)