And now it’s Kicking

Well, it’s been four long months since the last update on the development of this online collaborative stage planning and production tool, and developed it has. Some of the cause of this gap in information has been due to reluctance to share our coveted industry secrets, but most of it has been down to just being too darn lazy busy. Since the last post, a horrendous amount of work has been poured into this thing by both myself and, more recently, our fantastic, super-intern, Ciaran Schütte. We’ve turned it from the basic, sandbox style prototype you will have seen in the last post, into an (almost) fully fledged working Beta of our product.

From one trick pony to fully working demo app

Our initial “Hello World” style 3D space was, at the time, breathtaking. Although limited to just adding a few blocks and an actor to a platform that represented a stage, we revelled and basked in the glory that was 3D in the web browser; powered by the fantastic Javascript WebGL library: ThreeJS.

Having gotten used to the marvel that this was actually gong to be possible, I set out to actually get it done. Before long, I was well on my way. That’s when I was joined by the Schüttenator.

As development continued, the code began to pile and pile up. Soon, we had to split everything up into a plethora of javascript files which seemed at the time to be “organised” this quickly became a disarray of spaghetti code so we needed to make some…

Big Decisions in Back

I’m not going to pretend i’m in any way an organised person (I’m regularly down to my last pair of underwear before I cop on and put on a wash) so we needed some existing framework to keep our code spick and span. I wasn’t up for creating that. And so began our quest.

M.V.C.

Model View Controller is common but powerful coding strategy designed to logically separate parts of your code. Backbone.js is a javascript framework designed to make you work to the M.V.C. specification. We looked into using this but after some very deep research on Schütte’s part, it became clear that it didn’t entirely fit our needs. The quest continued.

Publish – Subscribe Design Pattern

Research took us to this. Commonly abbreviated to “pub/sub“. This design pattern turned out to aptly suit our Javascript needs. Essentially, code is separated into logical blocks, or modules, which are responsible for various aspects of the running of the software. These are all in communication with a central mediator, which decided when something needs to be communicated between these modules.

That solved our javascript issues, but the time was rapidly approaching that we needed users to be able to log in, to save, to have specific roles and to be involved in various different productions. We needed a backend.

The Ruby Debate

Neither myself nor Ciaran know ruby on rails, but we knew it was a powerhouse capable of quickly and easily building a backend to meet our needs. We would have loved to have learned it, but the time it would have taken to do so simply wasn’t available to us, so we had to make a decision to stick to good ‘ol PHP.

Laravel PHP Backend.

Thusfar, Ciarán’s most recent stage in his research quest has lead us to a PHP application framework called Laravel. This essentially made it nice and easy to structure a large scale app and database to manage user log in and saving of all things user and production related. Nice one Ciarán. Now the thing has scaled up to be a monster. The foundation is laid for this to grow to be a proper, commercial level, stable web application. That’s what we want, so this is good.

Big Decisions up Front

Enough about the backend. Let’s talk pretty, precious things.

In our testing prototype, I marvelled at my technical ability to hook this thing (an easy pre packaged javascript testing UI) up to various variables in the code to allow them to be changed live on screen. I thought I was a boss for being able to change the breadth and depth of the stage platform, and the king of the world for rotating actors, after you’d selected them. My bubble was burst when it became clear that dat.gui would be a nightmare to style to become our own bespoke user interface, and so, work began from scratch to build.

To be honest, this is such an “out there” product that it seemed weird to be back using plane old HTML to construct a U.I. I had toyed around with the idea of making the U.I. 3D as well, but I think that would have been overboard (not to mention far more complicated and also heavy on client-side processing power).

So it consists of a series of “panes” which change their contents depending on the state of the U.I. For example, if you switch your role to set designer, the edit pane will show you the tools related to set designer. I prefer to segment tools based on the current use case instead of pushing everything in your face. This saves space and overall, makes the whole thing neater and ultimately easier to use.

You can have a look here, at the non-techie accompanying blogpost for a full rundown on the U.I.

…And?

So there we are. That about brings us up to date on everything that’s going on. But what’s next? Well, first port of call is to fix the host of bugs throughout the software. Since we started rushing a month or two ago, decisions stopped being as well thought out in place of quick fixes. For that reason, we want to make what we have so far rock solid before continuing with any further feature development.

After doing that, and adding in a few more aforementioned beta features such as better lighting U.I. and the script pane (more on that here), we will most probably start switching the backend over to work on Node.js. We wish to create a truly collaborative product. That is to say that we want a Google Drive style character-for-character, click-for-click, live updating collaborative experience. For that, we need to use web sockets, and apparently, Node.js is the good for that.

But what do I know? I’m no expert…

…yet.