The technical architecture for Live Gaming: Databases, Languages, Frameworks

04Dec12

For the past month and a half since the last post, Appify has been furiously comparing different server-side technologies for Live Gaming, including what kind of database to use, what language to code in, and what frameworks to use. For the technically inclined RPGers, or those who just want to see that we’re still working and haven’t disappeared, here are the directions we’re taking on the new stack:

Database: MongoDB

Using the usual, relational database (SQL) or using a document-oriented database (MongoDB) is the big question here. SQL is by far the most popular database choice, but MongoDB has wide enough support to be compatible with most frameworks. Relational databases are great when bits of data need to be combined and manipulated in many different ways, with one row a data being independent from others. Document-oriented DBs excel at scalability of complex or dynamically structured sets of data.

SQL would be a good match if characters in Live Gaming were a list of a fixed number of attributes with a single value each. However, we’ve designed stats in Live Gaming not only to include the value of the stat itself, but links to other stats affected by it, help text, dice-rolling information, and character statuses that are currently affecting the stat. In SQL, this would mean that each stat in an RPG would have its own table, which would make assembling characters a longer, less efficient process… Live Gaming would require several functions to look for the user and get a list of characters, then look at the character to get a list of stats, and then apply values of each column in of a stat to create help text, dice rolls, etc. In contrast, a document-oriented DB like MongoDB could just hand the browser one (albeit long) document of stats and their attributes in a more ready-to-use format.

Also, MongoDB has another advantage over SQL: it would allow Appify to handle everything in JavaScript. Since documents are stored in JSON (JavaScript Object Notation), saved characters wouldn’t have to be translated from format to another in the app. The JSON for the character could be passed directly to the browser to be translated into a visual interface in JavaScript.

Language: JavaScript

PHP was never in the running. We’re looking to create a rest API on the server, so that game rules, stories, and characters stored in the database could be used in a number of different applications. This kind of architecture would be difficult in PHP, which is designed more for the display of pages than for the manipulation of data.

We didn’t consider Python for very long, either. It’s a great language, but didn’t have many compelling tools built for it. The Django framework is great for handling forms, but the character sheet is not a simple form. We might prefer to code in Python over Ruby, in fact… but Ruby has Rails.

Ruby has been a major contender, largely because of Ruby on Rails. The Ruby on Rails framework makes things like user authentication and authorization really, really easy to set up. While SQL is the default of Rails, it supports MongoDB, and we even considered using SQL to sign in users and create a session with a certain permission level, and then use MongoDB for creating, editing, and retrieving characters, stories, and game sessions.

However, JavaScript wins out largely because its simplicity and scalability. One language, one database, one world. It makes life simple, especially since we want to store data in JSON.

Framework: Node (with Express.js)

Node is a hugely popular library for server-side JavaScript with wide support. Express.js is probably the widest-used framework. We looked a few others: Meteor.js is not a good fit for developing a REST API, Derby doesn’t have much support, and Tower.js… well, a handleful. Express.js is a very simple, starter framework to skip a few steps in the architecture creation, but gives programmers a lot of flexibility afterwards. It’s a good fit for creating lean code, custom-tailored to our needs.


We hope to get a minimum viable product of the Character Generator out in within a few months, contact us if you want to be one of our testers!

Advertisements


2 Responses to “The technical architecture for Live Gaming: Databases, Languages, Frameworks”

  1. 1 ephemarel

    Hey, I couldn’t find anywhere else to ask, but you don’t seem to have updated since last year. How’s the app coming along? Are you going to post any more updates soon?

    • 2 ansorensen

      Thanks for asking! A Master’s project and a new job have drastically slowed down the app, but I’m still working on it.

      I actually did a foray into angular.js for the character creation flow, but I realized that the hybrid of express and angular wasn’t working the way I wanted. Front-end frameworks (like Angular or Backbone) need to exist only as single pages, or alternately as the whole app. Trying do a flow (a few pages) in a front-end framework just leads to sadness.

      Did you have any particular questions?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: