Working with social game entities in Couchbase

What’s in a new social game? Fundamentally, a game is an “experience” built around a series of interactions between the player, the content, and other players. Sure, the concept of the game, the storyline, the characters, and social components all have a huge influence on the game experience. But at the heart of a game’s attraction are the objects in the game world, the mechanics associated with these objects and the rewards offered to players. To power all this virtual activity you need a high-performance and scalable database.

In this blog, I’ll share how Couchbase can be used to power your basic game elements – Objects, Actions and Rewards

Game Objects

When you build an online social game, you typically represent elements that are part of the game world. They are called game objects and can be game characters, vanity items, functional items and buffs, etc. These object impacted by events in the game.  Some examples follow

 

Game Object Type	Document Value
Player	{ “type”: “player”, “uuid”: “35767d02-­???a958”, “name”: “DonPinto4540”, “score”:663, “level”:4, “loggedIn”: false }
Item	{ “type”:“item”, “name”:“Axe_e5890c94-­???11”, “uuid”:“e5890c94-­???11c6-­???”, “ownerId”:“Dale9887” }
Monster	{ “type”:“monster”, “name”:“Goliath9932”, “uuid”:“d10dfc1b-­???0412-­???41”, “hitpoints”:370, “experienceWhenKilled”:52, }

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In Couchbase, JSON documents are used to model game objects and are identified using the document id. For these documents, the type field is used to define the type of the object being stored.

Game Actions

As part of game play, players perform actions that may lead to the game objects being updated or changed. For example, players can move to different areas of a map, perform actions and earn rewards, and retrieve the coordinates of other players’ that are currently in the game.  Each such player action translates to viewing, adding, removing or updating documents in the database.  

 

In reality, social games have multiple players playing concurrently and their actions might impact the same object. As an example, actions performed in a game may require “energy” and once a player runs out “energy”, they need to recharge. Items such as speedup and energy packs are pretty common in social games give a quick boost of “energy” to the player. But the fun comes from competing for the limited number of “energy” packs in the game. Access to shared game objects needs to be synchronized to avoid conflicts and to maintain a consistent game state. Couchbase Server provides both optimistic and pessimistic concurrency control.

 

Here’s how to use these concurrency mechanisms. Let’s say two players want to attach the same tree-house at the same time. By using the CAS methods and retry logic, game programmers can guarantee atomic updates of global shared game objects to maintain consistent game state.

 

Game Rewards

Most games have a structure composed of a cycle of actions and rewards. Scoring systems are used in games to allow players to measure how well they have mastered the game and also to make it a little addictive. A leaderboard is typically used to record players with top scores.

Game leaderboards can be created in Couchbase Server 2.0 using views. A view in Couchbase is written using map/reduce functions that generate an index. For the JSON game objects shown in the game objects section, a map function (as shown below) can be used to generate a list of player scores. If the jsonType field of the document is of type player, we emit the score of the player and the id.

Final Thoughts