Building Browsergames

You should try a NoSQL database today.

One of the hottest new web technologies being discussed right now on the web is NoSQL Databases – with the two I hear about most being CouchDB and MongoDB.

NoSQL databases provide a different approach than traditional relational databases by being ’schema-less’ – allowing you to quickly and easily add arbitrary data to whatever you need to. This is a feature that’s extremely well-suited to browsergames – if you need a certain item to have a specific attribute that no other item has, it’s easy: you just add it, and move on. In a traditional SQL-based database setup, you’d need to add a column and make sure it was null or defaulted for all of your other items – which would be a major hassle if you had a large number of items.

Both the CouchDB and MongoDB sites have quickstart guides – if you haven’t tried one of the two out already, I highly encourage you to do so.

• CouchDB Quickstart
• MongoDB Quickstart

If you still need some convincing, here are a few areas in a game where a NoSQL database like Couch or Mongo will be better-suited than a traditional database like MySQL or PostgreSQL:

• Items

  So you have a potion, and potions usually heal people. But for this one super-rare potion, you want to heal the player and teleport them to a secret location. How?

  In a traditional SQL-based system, you’d add a column to your items table to track what the potion did, and then add the extra code and handlers so that when a potion of the one super-rare type was used, the player was both healed and teleported. This works, but it’s a bit of a pain – you need to create/track a new item type, along with writing the code to handle it.

  In a schema-less situation (when you’re using something like Couch or Mongo), all you have to do is add an attribute ‘teleports_player_to’ to your item – and then in your code, check if the item has a ‘teleports_player_to’ attribute. If it does, teleport the player there after running your item handling code. All done!

• Quests

  Quests are one area where schema-less storage really shines. You want to keep track of quests a player is on – but each quest is different! One quest involves killing a certain number of enemies, while another requires you to talk to two different NPC’s, while yet another needs you to move Important Package A to Secret Location B. How do you track all of that data?

  In a relational database, you do it by keeping track of what ‘type’ each quest is, along with a small amount of arbitrary information related to that quest. For a “kill 10 ogres” quest, you need to track that it’s a killing quest, you need 10 things killed, and those ‘things’ are, in this case, ogres. For a “delivery” quest, you need to track which item the player has to have, and which location they need to take it to.

  In situations like this, using a relational database to track information for your quests starts to break down very rapidly. What if you wanted to have a quest that required a player to kill 10 ogres, and then deliver a package to the town mayor? How would you do that?

  With a schema-less database, this is easy. All you have to do is check which attributes you quest has, and write your code to work around them – so if you wanted to have a quest where users had to kill 28 goblins, talk to the goblin herder and the shepherd, and then deliver the goblin herder’s letter of surrender to the shepherd, you could – all you’d have to do is check the quest attributes.

What other situations can you come up with when a NoSQL database might be superior to using a relational database to track data in your game, or when a relational database is a better option? Let us know in the comments!

Luke is the primary editor of Building Browsergames, and has written a large portion of the articles that you read here. He generally has no idea what to say when asked to write about himself in the third person.

Tags: databases, nosql