(Note: This is the first in a series of posts discussing the technology and design behind Storium. Today’s entry, from Storium co-founder and lead engineer Josh Whiting, is intended for a technically-minded audience.)
Today I’d like to give you a quick peek under the hood of Storium. I’m proud to share some of how things work and discuss interesting problems we’re solving behind the scenes.
Let’s dive in with a high-level diagram of the current architecture:
Most of this is typical for a tech startup getting off the ground. They’re popular technologies, and we chose most of them because we have experience running them through their paces at scale. And while most could be replaced by other similar tools, there are two that stand out as irreplaceable: AngularJS, and what we call the “game state manager.” These are the secret sauce behind Storium’s rich gameplay UI.
Earlier versions of Storium were built without AngularJS, just using “plain old” JQuery and a lot of scattered event handlers, callbacks, and direct DOM manipulation. This worked for our initial designs, but as the UI requirements progressed the code became unmanageable. Take a run through the editor interface for composing a new scene or move sometime — it’s got a lot going on! Without Angular, it would have been a nightmare to build. We’d love to discuss how we’re using it in more detail in a future blog post.
Angular is great, but the client is only as capable as the APIs that provide its data. Switching to Angular brought the need for a clearly-defined JSON API to represent and manage the gameplay. Enter the “game state manager.” The GSM is not a set of Rails controllers acting on ActiveRecord models. It organizes all the game’s objects and moves into a single, complex, mutable representation that is used by both the Angular app as well as the server-side game views. And because Storium moves start out as unpublished drafts, the GSM has to present multiple divergent views of that holistic game state to individual clients with their own drafted changes. It then must reconcile conflicts caused by multiple players moving at the same time. It’s really a first-class component in the system, and will almost certainly be promoted from a library API into an independent webservice over time.
So, what’s next? We want to integrate more real-time interaction into Storium. Imagine changes from the GSM being pushed directly to Angular, without a page reload. This will require some new and really interesting event-driven components in the stack. It’s an exciting direction both technically and for the product, and we can’t wait to get started on it.
We also plan to make a number of changes and improvements to the system — both visible and invisible — based on the great feedback we’re getting from our beta testers. Some of this work has already begun, and it will continue throughout the beta and into the future public launch of Storium!
Co-founder and lead engineer