Holy crap. The first draft of snake.js was finished quickly, and is available for play here. The mechanics of the game are super simple, start it up and a board is presented to you with a pale pink snake racing down towards a lime green dot. Use the arrow keys to move the snake in the direction you want it to turn. Every time you hit a green dot your snake grows one block longer. Hit a wall and you die. Hit your own body and you die. The game has just about zero syntactic sugar for the user, which is to say, it’s not built to be user-friendly. Readers of this blog will know by now that I tend to abhor this kind of design. In this case, I have built the game as an intermediate step in pursuit of a very different end product, and so I do not expect it to be played by anyone; it is not designed to stand on its own, I have included the url here to give the reader some background for the rest of the post.
Immediate challenges:
I ran into trouble early on in development, when I asked a friend to test the game for me. She started it up in firefox and reported that her inputs were not registering. Whoops! After a little rooting around, I tracked down the problem to Firefox’s implementation of the HTML5 specification: when the browser registers a keydown event, the spec calls for a “KeyIdentifier” attribute to come with the event object, detailing which key was hit. Chrome did it fine, Firefox did not. Not the end of the world, I just added a translation layer into the code, so that now the lower-level “which” attribute is read, and its counterpart is called from a dictionary to find the right input, which then feeds into the game. Super! A bug squashed!
Now for the fun part, to port it to a multiplayer game.
Oops. Turns out that making a game multiplayer is hard. Not hard like writing snake was hard, which (at least for me, and for the first time) it was. But hard like a hard problem in computer science. Turns out that making a game multiplayer requires coordinating state across several systems in real time, and fast. What does that mean?
Recalling last post’s digression into the MVC pattern, remember that the way the snake game works is to have a Controller object take inputs from a user, modify a Model of our data, and build a View of the information for the user. This works fine when there is one user for whom this information must be coordinated, on one system. But once one of those conditions changes, everything goes to hell.
Backing up a second, think about how we might make a turn based game like tic-tac-toe multiplayer. There are approximately two options we could try: first, have each of the two systems (each player’s browser) hold the model, and update it each time the other’s controller object broadcasts a user’s move, which would change where each model should be. Using TCP (or a TCP based protocol like WebSockets), this is pretty easy, and pretty reliable; TCP ensures that every message sent arrives at its destination, and that it arrives in the order in which it was sent, relative to all others. That’s pretty cool. Trust me, it is. But there’s something fundamentally broken about each player having the model locally, because it violates the idea of a model, which calls for there to be one, and only one True state of things. Using a TCP protocol just masks this violation, by ensuring that nothing happens until all the controllers have coordinated what the One True Model is, and updating their own accordingly. For two player tic-tac-toe then, imperfect MVC is fine, or at least, it’s acceptable.
Ok, now let’s try that with snake. If each player has its own model of the game locally, and that model is considered canonical (again, a fundamentally broken concept) then no player input may be processed into the model, or from the model into the view (remember, data goes User->Controler->Model->Controller->View->User) until the clients have had a chance to bring everyone else up to speed. In a turn based game that’s not the end of the world. Browser’s are serper derper fast, and WebSockets are pretty fast, and together they’re fast enough to coordinate models between each turn fast enough to not be a pain in the ass to players in something like Chess, Checkers, or Tic-Tac-Toe. But Snake is not a turn based game. Snake is in real time. If we force the browsers to coordinate their two models every time the game tries to cycle, it will slow down. It will suck.
That would be annoying, and with a game as twitchy as Snake (you need to move rill fast to avoid hitting things) the game is pretty much ruined if you force it to be coordinated between multiple endpoints across a network.
In fact, it’s a little worse than it sounds. Remember what we said earlier: the game as we’ve been considering it is actually a corrupted form of MVC, in which there are multiple, potentially conflicting sources of truth. Making snake step through turns ruins the gamer’s experience, but doesn’t fundamentally destroy the concept of the game. (Although one could fairly make the case that a game like Snake is no longer itself when it ceases to be a quick twitch-reflex testing game, I’ll leave that decision to the reader for now.) In other words then you could still play multiplayer web based snake, it would just be kind of crappy. But now what happens when state somehow changes in one model, and not the other? Impossible! Our models are coordinating with each other each step, how could they fall truly out of sync? Well, the trivial case here is a cheater. Our code is in Javascript, in the browser, and it would be relatively simple for a user to change the game as instantiated to change how his computer understood what was happening in the game. That kind of mismatch would get ironed out eventually (as long as the game protocol was built robustly enough), but the game states only have to be broken once for the game to be altered entirely. In other words, it would only take a user one malicious edit to cause his computer to believe that the other player was dead, and for it to report that he had won. Sorting that out would be basically impossible. Some answer could be arrived at by the server, but it would be extraordinarily difficult for that answer to be reliable. That is to say, even if we could make a final ruling, it would be arbitrary, since each browser’s model is considered “TRUE”.
The solution to this problem is to keep the model the way God intended it to be, singular and unified and held in a third party server. This is the second of the two models for building the game that I mentioned waaay at the beginning of this article. The only way to make really truly sure that no player irrevocably cheats the other is to make the server the sole and final arbiter of reality. From the perspective of the game on either user’s end, the server is the alpha and the omega. It instantiates a game model, and then accepts inputs from the users, modifies the game accordingly, and reports back to them what reality looks like now. Sound familiar? This is the way MVC code is actually really truly supposed to be organized: One Model – I can’t stress that enough – ONE MODEL – is handled by one controller, and fed into however many views you want. The number of views does not matter. The superbowls happens the same way whether you have one tv displaying a view of reality, or ten, or ten million. But what if you tried to have ten superbowls, each of which purported to be simultaneously the same thing as all the others, as well as the gospel truth of what a “The Superbowl” was? Well basically then you’d have politics. Depending on how you feel about politics, they’re fine in the political realm, but we don’t want that crap in our computer programs.
What does all of this mean for you – dear reader? Well first it means that with apologies, I must withhold from you a multiplayer snake game. Some reasonable approximation of such a game is still very much possible, but some serious design decisions will have to be made first if I want to make one worth playing. At this point I’m putting the odds of that at around ~30%. Not the end of the world, but probably not going to happen in the short-medium term future.
Our next post will take us away from Javascript for a little while, and into the world of Python. Stay tuned.
Finding the Forest 