Tuesday, January 22, 2013

How to Host Your Online Game

This past weekend I was having a discussion with a gentleman who was looking to create a game. Unlike most budding game creators, he had a lot of big picture questions related to the business of games instead the typical game play questions. Probably the most important series of questions he asked is seldom talked about, "How do I host the game and how to I design the game to minimize infrastructure costs?" Doing a quick search only led me to one useful series of articles at IBM. The rest were about hosting personal servers for existing games.

While the IBM series is very useful, it is from the perspective of hosting a big MMO. Considering that they are in the hardware business, it is not surprising that they do not discuss reducing your computing load. Nonetheless, Part 1 is necessary read regarding the relative requirements of the different styles of online games. Part 2 details what it takes to host an MMO. Reading it should convince you not to make an MMO as your first project (or maybe ever). Part 3 is about working out issues with your host, which is not relevant to this discussion. What is the best way to host your online game? Read on.

Assessing Your Server Requirements
While there is a continuum of hardware requirements for games, I am going to break them into three tiers. The bottom tier includes single player games and small multiplayer games where one of the players temporarily hosts the game. The top tier is a full-scale MMO requiring multiple powerful servers hosting a truly massive open world. The middle tier is a hybrid. Games are broken into chunks dynamically assigned to multiple servers. A single powerful hardware server could host multiple chunks.

Starting with the bottom tier, these games scarcely qualify as online. These games may have a promotional web site, but the sales will often be outsourced to 3rd party digital distribution sites. You'll probably also want to host a forum related to the game for community building as well as high scores and possibly match making. Ultimately any hosting company with a real or virtual hosting will meet your needs. This tier keeps your hardware costs extremely low, but you are somewhat limited on the scale of your game and also your profitability. The income from a game of this size is limited to the sale price and what you can scrape from an ad network displaying ads in game. Demographic information collection will be limited. Free to play will also be limited. While you can easily add a second server for in-game transactions, you will not be able to leverage many of the social pressures that keep players spending. Building "community" requires multiplayer gameplay and with that, servers.

The high-end multiplayer tier is for the big boys. Multiplayer games are an n2-computing problem. If you have 10 players standing in the same area you have 10^2=100 interactions to calculate. 100 players give 10,000 interactions. It gets out of hand quickly. I will show you some tricks in the next section, but even with good design, you can never assure that players will not group together and bog down the server or even the client. The city of Ironforge in WoW classic is a good example of this. It was a major travel hub, major training hub, it was next to a starting zone providing an influx of new players, and had the Alliance's only auction house. There was always congestion, which earned it the nickname of "Lag-Forge.” The only way to fix this is buying even larger dedicated servers or redesigning the game to encourage dispersion.

Games of this scale can offer the greatest profitability but at the huge risk of not getting enough players to be sustainable. Servers on this tier are actually racks of servers, each running a different part of the game. It gets very pricey. If you are hoping to be a WoW killer, be prepared for disappointment. Check out this guy's charts. You would be surprised at how many big name MMOs never broke 150k players. Fortunately, the MMO gold rush is over so you will not find too many people hyping this tier anymore.

Now we are onto my favorite tier: the hybrid tier. At the simplest level, are most games in the FPS genre as well as Diablo II, which went this route in order to offer a secure online environment.  It is harder to cheat when you do not control the server. Some medium to large MMOs are on this tier because, while they give the appearance of being massive, you jump to a new game small game server every time you go through a door. If too many people are in one area the game will create multiple copies of the area and distribute the players across them. The nicest feature of this tier is scalability. If you are cloud hosting your game, you can dynamically adjust the number of servers based on the number of active players. Alternatively, you can provide your own servers at a reduced cost and supplement with cloud servers in the case of a player surge.

The trick to this tier is designing your game to be broken into chunks. The easy approach of limiting each game to eight or so players will limit your profits. Community makes games profitable, from both increased sales as well as retention. (You cannot advertise to players if they are not playing). Building community requires common areas for people to congregate such as forums, chat rooms, guild areas, and in-game towns. Unfortunately, people congregating creates increased server load, which is why design is so important.

Designing Your Multiplayer Game as Chunks
The key to simplifying the complexity for the server is limiting interactions between players. From the perspective of computational difficulty, interactions are not limited to just two players interacting; watching another player do something is also an action. Computation is not the only thing that to conserve. Bandwidth is also of concern. As with most computing problems there is a processing vs. bandwidth (or RAM) tradeoff here. Take a simple game where players just walk around for example. When sending updates to the players we can go the CPU heavy/minimal bandwidth route of calculating which players are visible to other players and only send the visible updates. Alternatively, we can do the minimal CPU/maximum bandwidth approach and send every update to every player without thinking about it. Alternatively, we can take the hybrid approach and send every update to every player that is nearby. “Nearby” requires some simple calculations but not as much as “visible” which lowers the CPU requirement, but sends unnecessary updates for players on the other side of a wall wasting a little bandwidth. That being said, limiting interactions is achieved two ways: fewer players in an area and fewer ways of interacting.

When you strictly limit the number of players in an area then you have bounded complexity. The best example of this is "Instancing" in WoW. Having a private copy of the dungeon for your small group is ideal because it keeps the server requirements small and allows multiple copies of the server to run on the same host. As an added bonus, it is also more enjoyable from a gameplay perspective as it prevents griefing from strangers.

Guild Wars takes this to the next level with dynamic instancing. Every zone in the game is an instance. When you enter town you the server randomly assigns you to an instance of the town. The server selects the instance to keep the population in each town balanced. When you leave town, you will be in your own private zone. This gives the appearance of a full MMO without the hardware requirements. The down side to this design is that it is obvious where the portals are and can be immersion breaking. Spiral Knights is another game that uses this technique except instead of portals they use elevators. This makes that transition feel more natural.

WoW has another technique for dividing players into chunks. Instead of hard portals, it has strategic bits of architecture such as city entrances that zigzag. These make it so that nobody in the city can see out and nobody outside can see in. If you guarantee that players can never see adjacent areas, then you never have to check for interactions between players in separate areas. This is not a perfect design, though; there is no way to limit the number of players in a congested area.

Limiting interaction limits gameplay, but if the restricted interactions are not useful at the time, players will not notice or care. This allows tradeoffs such as high population towns with minimal interactions and low population dungeons having full interactions. Easy things to disable in town are collision detection and combat in general. Instead of subtractive design for the town, you can start with a town made of pull-down menus and a chat room and then start adding things back. Anther bonus of limiting things to this level you can start skimping on the accuracy. As long as the other players look convincing, no one will notice if you save bandwidth by reducing precision or the rate of updates.

Let my know if you have any other tricks for keeping players from bunching up.