Very interesting to read! I guess I'll have to try my hand at multiplayer HTML5 game as well some time, because even reading you, I believe you, but at the same time it's hard to believe that it's hard like that :)<p>Care to elaborate a bit on the part where you say communicating the entire board state was too much data? Looking at your game, I don't see how the board state could be much more than 100 bytes or so? Was it the JSON that bloated it up?<p>If I were you, I'd do it like this: split the state into a static and dynamic part. Player's names won't change during the game. Or if they might, maybe even better to split the state into a high and low latency part. If you see a Player's name update a second too late, it's no big deal, so communicate that via a different, slower, channel. All the other data, the board state, player positions, scores, you don't need JSON if you're transmitting the same fields every time. So make sure everything's a ranged integer and squeeze them together either using a base64 library, or maybe just simply Number.toString and ParseInt with radix 36 (max natively supported radix encoding in JS, and still 5.17 bits/byte), or maybe you hack Unicode/UTF8 to translate integer code-points into bytes and vice versa (you should probably go for the latter, because it'll be <i>awesome</i>).<p>Oh and then, a tip, when you wrote:<p>> I added some rules and gameplay elements to make it feel more like something one would like to play, including:
Feedbacks when you get hit<p>I was reminded of this really cool presentation about game-design and "juice": <a href="http://www.youtube.com/watch?v=Fy0aCDmgnxg" rel="nofollow">http://www.youtube.com/watch?v=Fy0aCDmgnxg</a><p>As you can see, all those tricks are "merely cosmetic", but they truly do make the game a lot more fun to play. The second most important thing, almost all of them are simply transformations to the "view" of the game, so they can all be done client-side, cost nothing extra network-wise (apart from loading initial extra gfx). But the first most important thing is that all these extra tweening functions and particle animations help cover up any accidental lag or latency! If you got a bare bones squares-on-a-grid game, any lag and stutter will be super obvious, because that's the only thing to see. But if everything is bouncy and wobbly, and there's explosions and smoke flying all over the screen, those things can keep moving and animating because they don't depend on server information, while the game engine waits for the next data packet, and the player won't suspect a thing. It similar to "suspension of disbelief", in a way.<p>Please do post follow-ups if you continue developing this game!