Picnic Defender was a browser-based tower defense game making heavy use of HTML5 technologies, including canvas, audio and websockets. Picnic Defender was featured on Chrome Experiments, where it was well-received (rated 4.5 out of 5 with over 150 votes).
I was solicited to write a chapter in the book HTML5 Games Most Wanted when the publisher saw Picnic Defender on Chrome Experiments. My chapter was a tutorial for creating a real-time multiplayer game using websockets in the browser and node.js on the server. For more information, see the project page.
You can still try Picnic Defender. This is a slightly stripped-down version of the game. Features which rely on a server (high scores, achievements, multiplayer) are all disabled, but the single player gameplay is fully intact.
With Firefox 4 and Chrome ~10, web browsers were just starting to come into their own, and canvas was just barely supported. Hardware acceleration of the canvas element has improved steadily since then, but canvas performance was always a concern when I was working on Picnic Defender. I employed various tricks to improve drawing performance, such as layering several canvases (so that the background would never have to be redrawn, for example) and only drawing at integer pixel coordinates to avoid unintended (and unconfigurable) anti-aliasing. Had I known then what I know now (2014), I would have made better use of non-canvas DOM elements.
I was eventually inspired to add a multiplayer component to the game. I wanted two players to be able to share a map, with both players capable of placing and selling towers in real time. This turned out to be among the most interesting and challenging projects I’ve set for myself.
How does one show the same thing to the two players? It’s a very delicate thing, not simply a matter of having the same list of towers on the two game boards. If my tower shows up on my screen one tick of the game clock before it shows up on yours, it may kill an enemy that escapes for you. The game must be deterministic and synchronized.
The mechanism I settled on was an authoritative server to which both clients would report. When I went to build a tower, the game would tell the server “this guy wants to build a tower”. The server would then send a message to all players saying “at tick 85, there’s a new tower”, where 85 is the time on the “real” game clock running on the server. If I receive that message from the server and my game time is 75, this works nicely. If my game clock reads 86, my client has to rewind to 85 and follow the server’s directions (this is lag). In this way, the state is kept consistent across all players.
There were a few towers in Picnic Defender with randomized effects (e.g. dealing a random amount of damage, or shooting at a random enemy). In order to synchronize that randomness across multiple players, the server picked a seed integer and sent it to the clients, and the clients generated pseudo-random sequences according to a linear congruential generator.
Last updated 18 October 2014