The technical architecture for Live Gaming: Databases, Languages, Frameworks
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:
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.
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.
Framework: Node (with Express.js)
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!
Filed under: Live Gaming | 2 Comments
Tags: express.js, Live Gaming, mongodb, node.js, RPGs, ruby, ruby on rails, SQL, web development