Update: My github for reading xlsx files using actionscript 3.0 is now available here

 

Background:

---

I've been involved with making gameshows since I was a teen. First you have to pitch a show to a broadcaster like ABC, CBS or the BBC. If the broadcaster likes the pitch then you get 'comissioned' which means you are given money to make a pilot, a whole series or both.

Getting a gameshow comissioned to be made into a series by a broadcaster like the BBC is only the first step though. Refining it so it runs smoothly, is competetively fair and stays compelling throughout is a huge challenge. All of these elements affect how well the show works when the show finally goes to studio and in turn make a big impact on how the show feels to the audience (and how the show does in the ratings) when it finally airs.

I have worked on several gameshows and gameshow pitches with Wild Rover Productions including the new show Secret Fortune which airs February 2010. One thing we realised is that trying out complicated "what if we did this?" new features for a gameshow is often very hard to visualise. The exact mood in the room at every moment matters, and it builds cumulatively through a show. This is compounded by the fact the mood often changes depending on whether the contestant is doing well in an individual question and across the show as a whole.

Making it even harder, changes often have to made with extreme time constraints (hours and sometimes minutes rather than days) due to the nature of the TV business.

Our standard approach of building flash demos was fine for individual versions of shows but there were problems:

1. Code resuse was hard because implementing new features at speed under pressure always ends up introducing bad architecture and unreliable code.
2. Complex changes were often not attempted because of the complexity of implementation.
3. A coder (me) was needed to make nearly all of the changes and often needed to be present at the run-throughs.
4. Demos were fragile because new features were needed before bugs could be hunted down.

This provided a fairly clear case for creating a platform to build gameshows on top of. The feature set we needed was:

1. A Non-Technical Development Producer should be able to:
   1. Edit all standard variable features of a gameshow: The question set, number of questions, money ladder, time on the clock etc.
   2. Choose which version of the show to demo: Clock, no clock, number of rounds, type of rounds etc.
   3. Run through the demo smoothly at his/her own pace.
2. A Technically Savvy Producer should be able to make complex running order changes really quickly without jepoardising the archictecture.
3. A Coder should be able to add new shows and new features to shows with maximal appropriate code resuse, good backwards and forwards compatibility with speed and a minimum of hassle.
4. The system should be robust. Crashes should be infrequent and debuggable, even considering the rapid introduction of changes.

The Platform:

---

The architecture I decided on was to use Excel as a kind of interpretter for gameshow running orders. This allowed for immediate feedback and flexibility. The xlsx file is read directly by Adobe air/Flash using my actionscript 3 xlsx parser and the Adobe air app runs the show.

Friendly mode allows producers to customize an instance of the gameshow with a minimum of hassle:

In version 1.1 I added html device support to the plaform. This allows ipads, smartphones and other device to be linked to the main demo platform and to play along and control the gameshow demos live.