Archive

As owner/organizer of the SeaFall game for our group, I felt responsible for going into the game with as good a handle on the rules as possible, so I took some time to read through the rulebook a couple times before we gathered to make sure I understood the intricacies of the system that Rob Daviau of (Risk: Legacy and Pandemic: Legacy fame) had built for us. It’s a pretty beefy rulebook even before you start to unlock the unfolding “legacy” portion of the game — Daviau himself calls it a “medium-to-heavy” game system. One side effect of investing in the rules early on was that the tease of narrative and future revelations left me with a deep curiosity and enthusiasm to get the group together and kick off the game, if for no other reason than to begin unlocking the mysteries behind it.

As a legacy game, part of the fun of the core mechanics is knowing that you don’t know all the rules at the beginning of the campaign; you expect things to go sideways halfway through. (In fact, having come to this game from midway through a Pandemic: Legacy campaign, I’m starting to learn just how much things can go sideways, but that’s another post.) What’s different about SeaFall is that this is the first legacy game that is built off of a fundamentally original core game system, rather than taking an existing game and layering a legacy campaign on top of it.

Board setup – the main board, side board, and province boards for four players.

Taking the time to read through the rules a couple times and watch a tutorial video was well worth it, otherwise we probably would have been pretty lost when we first sat down to play. Since we came to the table forearmed, however, setup went fairly smoothly, especially considering all the components to prepare. The boards themselves provided good guidance on where the pieces needed to be placed. Little boxes called “province chests” used to store individual players’ chits that carry over from game to game are genius. All in all, there were only two elements that could have been improved in my opinion: the way the “milestones” (a mechanic for progressing the game narrative) are provided to the players to set up for the first two game sessions, and the placement of the event cards that describes the state of the world for a portion of the year–unlike most other cards, this deck doesn’t have a dedicated place on the main or side board, leading to confusion about where it should be set up. The choice to use an enmity sticker from your side, typically reserved to track when you’ve wronged another player or island, to tag your portrait for your side is also a little weird. A dedicated sticker for this would have been a less incongruous choice.

Preparing to set sail

After setup came the actual gameplay. And here is where I am starting to grow concerned. The primary issue I’m facing is that the core mechanic of a game turn is…well…cumbersome to put politely. The game design forces the players to choose one of four “guilds” to employ each round, which enables them to buy/sell goods, build enhancements to their province or ships, explore a site on an island, or conduct a violent raid. On its face, this seems reasonable, but the mechanic results in all players struggling to get ships where the they need to be to execute their plan leading to a very choppy and sluggish feeling experience. Forward momentum is hard to come by.

One thing that is clear is that each game is going to be very different. The first two games we’ve played unlocked enough of the board that we won’t be able to do much more unlocking for a while — the low hanging fruit is taken on our board — and instead we’ll need to change our strategy to leverage the fruits of our exploration from previous games. While on one level that’s fine, and in fact part of the point of a legacy game, the flip side of this particular coin means that I’m concerned that we may never get to the point that the rounds in the game can proceed smoothly, because we will forever be trying to evaluate how to try to get our guilds to do what we want in an ever-changing environment.

Finally, for me personally, coming from a cooperative game like Pandemic: Legacy where the deck drove the uncertainty mechanic with some constraints, moving to a competitive game where there is unbounded uncertainty based on dice is fundamentally a less fun game to play. Also, dice hate me. These two statements may be related.

I’m still curious to see how the game evolves as we “reset the board” each session in a semi-dynamic world, and of course there are strong hints that the whole game is going to go sideways sometime in the future. Fundamentally, though, I must admit I’m a lot less excited about the whole experience than I was before we had started play. Hopefully as we get more practiced in the game the rounds will smooth out, but I’m not optimistic. We will see how things unfold. My people will struggle through. It is my destiny to become Emperor of the sea, after all.

In the last post we discussed how digital multiplayer games have evolved, various strategies for getting different game clients to keep their games in sync, and why the core HTTP request/response architecture of the web was fundamentally flawed when it came to multiplayer games. In this post, we’ll dig into the HTML5 solution to this problem and how to use it in desktop or mobile web applications.

WebSockets are a new technology that was written in response to JavaScript developers using AJAX calls to keep checking back with the server to see if anything new had come in. It was clear that the current design was not meeting the needs of modern Web 2.0 applications, which wanted to leave a connection with the server open for as long as the web page was up so that any new information from the server could instantly be read by the JavaScript running on the client and displayed.

At the lowest levels, WebSockets do piggyback on top of the World Wide Web infrastructure (hence the name). They follow a URL scheme, similar to the ubiquitous HTTP definition. Since the underlying protocol is different from HTTP, however, the URL scheme begins instead with a new label: ‘ws‘ (for unencrypted streams) and ‘wss‘ (for encrypted streams). For example:

ws://yourserver.com/yourwebsocketresource

If you’re running your own web servers, you’ll need to have a program running on the backend to handle WebSocket requests such as these. Apache’s ActiveMQ project is one example of WebSocket-aware server software. A full discussion of the pros and cons of various server configurations and software packages to handle WebSockets is beyond the scope of this post.

WebSocket technology is new enough that browser support when running your client HTML5 application should not be assumed. To assist in this, there are several JavaScript libraries that wrap the WebSocket calls in their own API and thus can downgrade the connection to an HTTP polling connection if the client application is running on a browser that does not support WebSockets, and we’ll dig into one of those wrappers momentarily. In the HTML5 mobile space, WebSockets were added to Mobile Safari in iOS 4.2 (though the WebSocket spec supported is an out-of-date specification, so make sure your servers are compatible with the old spec if you want to support iOS devices), but as of this writing are not supported on the default Android browser. WebSockets are supported in the newly-announced Chrome for Android beta, which only runs on Android 4.0.

If you are running in an environment that supports WebSockets, interacting with one on the client side is delightfully simple. Read more…

Along with the recent performance upgrades in the major browsers’ implementation of the HTML5 canvas, there is one other big piece of the puzzle falling into place that will provide HTML5 games with an environment that allows them to look and feel just as much like a “real game” as a game developed for Xbox Live Arcade or Steam, particularly where multiplayer is concerned. That piece is the WebSocket, which finally provides web applications with genuine realtime 2-way communication with game servers and/or other devices. But before we get to a detailed discussion of WebSockets, let us take a look at the history of networking as it relates to games and see how we got to where we are today.

A talks to B, B talks to A

In the beginning, there were two game clients who wanted to talk to each other. My personal first experience with this was a little first person shooter called Doom. The clients each ran their own copy of the game and in multiplayer mode, each copy of the game sent messages back and forth over the network so you could see where the other players’ little guys were running around and could try to blow them up before you got blown up. You know, the usual.

When Blizzard Entertainment first set up Battle.net to allow Diablo players to find each other over the Internet and play together, they followed a similar simple networking model. Each client ran a copy of the whole game and sent sync up messages to the other players so you could keep track of what your friends were doing. As long as everyone followed the rules, this was fine. However, it quickly became clear that since each client was the final authority of the game running on that client, it was very hard to catch cheaters who hacked their local copy of the game to give their character an unfair advantage.

Clients talk to the server, the server talks to the clients

Enter the client/server model. In this system, the game is designed from the ground up not to trust the client. Since clients can be hacked, servers are now used to run the central game processing, with clients only having very limited control over their environment. The messages a client sends to the game world become severely restricted in this environment as well. Take, for example, a game where a player is supposed to only move up to three squares a turn. Where before, in an environment where a client might broadcast to the other players in the game, “My player is now in location 200, 200!” and the rest of the clients simply accepted this message, a hacker could easily bypass the three-square-max rule on a hacked client where the rule was not enforced. In a client/server environment, the server verifies all messages that are sent in by the client. In this way, a hacked client that tries to bypass the three-square-max restriction would get caught by the server when the client attempts to claim their player is in a location that should be impossible for the player to reach in one turn. At the very least, the illegal message can be rejected by the server and never passed on to the other clients playing the game.

Battle.net took on just such an enforcer role for Diablo 2, which is why players were given the choice to play Battle.net-only characters, who could be considered trusted by other players to have never been hacked, or they could play “local” characters with whom Battle.net did not play a watchdog enforcer role, and thus the characters may or may not have been given unfair advantage through hacking the game. Even the Blizzard behemoth World of Warcraft, at its core, uses a similar model, though hundreds of clients are allowed to connect to a World of Warcraft server at once (actually several different servers make up a World of Warcraft game world, which is why players see a loading screen when they move from continent to continent in the game–the loading screen masks the hand-off of the character across different game servers).

On the HTML side of the world, client/server communication was around long before it became clear that client/server networking was required for trustworthy multiplayer gaming. The basic form of communication between a web page and its web server has always been something called “HTTP”, which is designed around the core idea that the web browser will ask for a single resource–a web page, an image file, a video stream, etc–then hang up the connection after the resource is delivered. In the course of loading this blog post, your web browser issued several HTTP requests: one for the post itself, and one for each image embedded in the post, as well as some extra requests invisible to the reader.

As it turns out? For games, although you have the same client/server architecture the multiplayer game world migrated to, this is a terrible system. Although it already has a server in place ready to be used as the game enforcer to protect players from cheaters using hacked clients, there is a fundamental problem in the “hang up after every request” part of the HTTP design. For multiplayer games, you don’t want to hang up. Ever. You want to keep that line open so that you can be in a constant state of communication with the server: keeping it up to date with what your client is doing and getting back constant updates on what the other clients are doing. In HTTP-land, that means a whole lot of wasted bandwidth as clients constantly set up new connections to provide new updates to the server and check for updates from other players. It also means web servers have to set up and tear down a lot of connections that may not actually contain any data if nothing has happened in the game since the last time the client checked.

TL;DR: HTTP was never intended for this kind of communication.

Which leads us, at last, to WebSockets: a new protocol that allows web pages to open a connection to a server and keep that connection open, both for sending and receiving data, for long periods of time. In my next post, we will explore WebSockets in detail and see what options HTML5 developers have today to leverage this new technology.