Social Game Best Practices
A social game with (hopefully) millions of players has different technical and performance characteristics than a Massively Multiplayer Online RolePlaying Game (MMORPG ) like World of Warcraft.
- Session Oriented
- Connection Oriented
- Synchronous and Asynchronous
- Session Oriented
Session oriented services (in contrast to discrete services) allow for a longer connection duration and response to external (asynchronous) events. The stereotypical Instant Message program is an example of a session oriented application where events (such as a friend has just logged in) can be communicated to an established session to do something (such as pop up a notification window).
Connectionless protocols function under the premise that the receiver does not necessarily have any state and must be provided all of the information it requires to process a transaction. Communication is based on self-contained packets of data (datagrams) exchanged independently and without reference to other datagrams. A connection oriented protocol establishes and maintains state about the connection and often involves a two or three-way handshake. Consequently, connection oriented protocols have a high initial overhead which can be amortized over the duration of the connection (which makes them less suitable for frequent transitory connections).
Asynchronous services respond to requests at some point in the future and can not be relied upon to provide an immediate response. Social games are typically fully asynchronous with the minimal server involvement servicing infrequent requests by the client at some point after they come in. MMORPGs such as World of Warcraft typically operation in a mixed mode where some operations are immediately acted upon and others are responded to asynchronously (for example, casting a spell might immediately process in the server, but opening up the auction house to view items is asynchronous with the response coming...eventually).
Minimal Server<->Client Communication
Social games (and especially, Free-to-Play ones) must maintain careful control of their costs and in particular costs associated with bandwidth usage. Where a subscription-based MMORPG is constantly sending character movement packets and other game traffic, a social game communicates rarely with the server (probably no more than a few times per minute) and receives as little traffic from the server as is possible.
Caching is an important technique in reducing bandwidth consumption. Take for example the stereotypical social Farm game. When the user starts to play, you could have the server send all of the information required to instantiate their farm...A better way would be to store the farm in the Local Repository Cache ((LRC) with a time stamp and during login check to see if the file matched the server's timestamp and if so use the locally cached information. Using the local cache in this manner reduces the bandwidth from many kilobytes of data, down to as little as a few hundred bytes.
Client-Based Processing reduces bandwidth consumption by allowing the client to process the majority if not all game play and then sending an occasional update to the server. The server is then responsible for determining whether or not what the client claims is reasonable and then applying or rejecting the message. You may have experienced a server-based rejection in social games where you had to reload the webpage to proceed because the server decided what your client claimed occurred was not reasonable.
Trust But Verify
Social games typically execute significantly greater amounts of their game logic on the client generally trusting the client to do the right thing and then verifying the minimal updates the client sends the server. This is different from MMORPGs where most actions triggered on the client are sent to the server to process and respond back to the client (and other interested parties) with the results.
Server Area Geometry Rarely Changes
Area geometry (the collection of the ground, trees, buildings, etc) leverages the Local Repository Cache (LRC) to cache files related areas including not only list of all of the instances and their properties but also the collision data to represent the area in physics. These files can be large, if the server geometry is modified frequently in a social game with millions of players the bandwidth consumed to communicate the new data can be prohibitively expensive.
This should not be confused with local changes to an area which are achieved using the Prop buckets mechanism to instantiate objects locally on the client without modifying the server geometry.