You really should make it clearer that this is against other humans. When I saw the page, I thought the other pixels were just automatons. Even when I saw some forming letters in the corner, I just thought “interesting, some of them are programmed to not participate”. And I thought moving around was pointless because I couldn’t predict where the computer would move its pixels, so I had no idea how to get into position but to just stand there. It was only by reading these comments that I realized that the other pixels were other players, which increased my enjoyment of the game immensely because of the feeling of cooperation with others, and the understanding of why the other pixels act the way they do.
I’m actually quite proud of having implemented the scoring client-side. It helps keep the load on the server down. Looking up all possible formations is somewhat computationally intensive.
It does create some problems when some clients have high latency and don't detect the formation in time, but I think it's fixable. One way could be to make the computation redundant, e.g. get three pixels to do the detection instead of one, and consider the formation valid if 2 out of 3 of them report success.
Don't get me wrong. I totally agree that you made the right choice, especially for the node knockout.
This might be completely over the top but perhaps you should look into lag compensation technique that FPS games use. There is a global state on the server and the clients send their command with a timestamp. The server then looks at the global state XXXms ago.
You're going to need global state and scoring if you ever want a leaderboard (otherwise people will just game it).
You could also just make it so that it doesn't show the clock during the last three seconds or something. Show "calculating..." or something and give people whatever the greatest lag time is grace period.
Verifying that a pixel is valid is much, much, much less intensive than searching for all possible valid pixels. You could do the scoring client-side, with the server verifying.
That wouldn't take care of a formation not being detected because the pixel responsible for it has very high latency or is disconnecting. I think this kind of false negative is a much bigger issue than the false positives.
