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.

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!

Wish there was more?

I'm considering writing an ebook - click here.

.

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: ,

Monday, February 1st, 2010 site-news
  • bsharpe

    Thanks for the post on NoSQL. I can tell you definitely looked into it a bit. I'm just beginning to see projects at work that will benefit from these sorts of systems.

    Another benefit is that they speak JSON natively -- AJAX calls can query the DB directly skipping the application layer (and therefore speedier). Mongo really needs to beef up security for this to be mainstream though.

  • You can not skip the application layer, since you not auth and verification of the AJAX request.

  • Thanks for this post.
    But what's the benefit against adding a column "attributes" to my items-table? The development-costs seems to be the same. In both cases i have to check for each attribute and call the handler.

  • The benefit comes up when you find that you want to create hybrids of
    different objects. If you want to have a quest that requires killing
    things *and* delivering a package, how do you do that when you only
    have one column to track the quest type in? Do you add a new quest
    type, and duplicate the code for killing and delivering quests?

  • Oh, my comment wasn't very clear. Sorry.

    You wrote:
    > All you have to do is check which attributes you quest has, and write your
    > code to work around them

    If I add a "attributes"-column to my relational database, I can store contents like "kill(goblins,20);talk(goblinherder)".
    Isn't that pretty much the same as the attributes in a schema-less database?

    The quest type would be obsolete, as I can mix different types in one quest. Even if I had a class "Quest" in my code, the property "Type" wouldn't make any sense to me.

  • You can do that, sure - but when it comes to extracting those
    contents, what do you do? Either way, you're working around a
    limitation of your technology - whether you're adding lots of columns,
    or storing what should be two columns inside of one.

  • DirkSonguer

    You should try an Entity System: http://t-machine.org/index....

blog comments powered by Disqus

About

Building Browsergames is a blog about browsergames(also known as PBBG's). It's geared towards the beginner to intermediate developer who has an interest in building their own browsergame.

Sponsors

Got Something to Say?

Send an e-mail to luke@buildingbrowsergames.com, or get in touch through Twitter at http://twitter.com/bbrowsergames