Technical Manager at Blitz Games Studios, responsible for tools development of the BlitzTech middleware. Previously roles include engine programmer on the middleware team and gameplay programmer on several PSX, PS2 and GameCube titles. On twitter as @deltaflux
Posts by Tom Gaulton
  1. Embrace Freemium ( Counting comments... )
  2. Building your tools as a webapp – Part 3 ( Counting comments... )
  3. Building your tools as a webapp - Part 2 ( Counting comments... )
  4. Building your tools as a webapp – Part 1 ( Counting comments... )
  5. Social media - an alternative to the scrum ( Counting comments... )
  6. The unexpected performance of debug builds ( Counting comments... )
  7. The unexpected behaviour of debug builds ( Counting comments... )
  8. Iterate Better, Iterate Faster ( Counting comments... )
Game Design / Technology/ Code /

webappWow, where to start? I’ve had this topic in mind since before I joined #AltDevBlogADay but I’ve struggled to get it down on paper. It’s not that I haven’t got anything to write on the subject, more that I’ve got too much to write. To explain why, here’s some back-story:

I work as a tools developer on the BlitzTech middleware. The toolchain has been in development for 12 years, and I’ve personally been involved in writing it for 9 years. For the majority of that time the tools have been developed in C++, using the classic Win32 API for the user interface. More recently C++ started to give way to C#, the old Win32 functions were replaced with the .Net framework classes, and scripting languages began to find a home in the pipeline – but fundamentally the tried and tested method of building dialog based tools hadn’t changed in a decade.

Then, in the middle of last year, we decided to try something a little different. In fact, a lot different. Our user interface would no longer be a series of Windows dialogs, but instead a shiny web interface. The UI wouldn’t drive the back-end code directly, but would instead communicate via a HTTP interface. In short, our tools development would be radically different to everything we’d done before.

At first we weren't sure it would work, but quickly we started to see the potential and over a year later this approach is really paying dividends. When Mike Acton published a post entitled New generation of @insomniacgames tools as webapp back in March, I was excited to see that ours wasn’t the only team going in the web direction, and subsequent enthusiastic posts from other developers made me determined to share my own experiences on the subject.

Now, how to distil all those thousands of hours I’ve spent developing tools into a single blog post that explains a) why building your production tools as a webapp is such an awesome idea, and b) how to actually go about doing it?

Well, on the goal of condensing it into a single post I’ve failed, so I’ve decided to split this into a series of posts. In fact I only finally decided to write this intro a few hours before my posting deadline so I’m afraid it's merely a tease for what is to come. My next post will focus on all the reasons why a webapp is a Good Thing (TM). Mike’s previous post on the subject gives a good summary of the key goals, but there are a lot of other subtle benefits to explore.

After that, I’ll do a series of posts describing (in as much detail as I’m contractually allowed to share) how we’ve plugged together all the components to make a working webapp-based toolchain - and how we’ve gone about bolting this onto a decade old codebase in a way that gives us all the cool new stuff, while maintaining the legacy of feature rich tools.

If you have an interest in this subject, particularly if there’s anything specific you want to know, please drop a comment below and I'll do by best to answer any queries.