At the beginning of April I was invited to the most brief and preliminary of development meetings concerning a forthcoming project, then only a concept for a web-based, live mass-participation game show. We were told it would be exclusively online, combining a high-quality live video feed of a presenter-led programme, facilitating up to 1,000 paying contestants to simultaneously compete for real money prizes with a number of interactive games.
I was invited because the primary candidate for deployment was using Flash Media Server, which I had a intensive experience with in my final year of university. Primarily I was asked whether the project was feasible, achievable and did I feel using the FMS the right approach technologically, because no one else on our team had previous dealt with it. Although less than a year since my work at uni, it was quite apparent that the scale of the project was going to be significantly more demanding than anything I’d worked on before, but I figured I say yes anyway.
The project itself is deceptively complex, but stubbornly never so in explanation. Essentially, it’s a enriched online port of the infamous interactive game shows despised on late-night television – you know the ones with premium rate numbers and supposedly con viewers? They’ve all pretty much been scrapped now, so this idea was (and because it had to be) a completely new format – the idea of a game of skill, with straightforward general knowledge and trivia as opposed to frustratingly ambiguous questions; without the premium rate number to join a queue of callers, instead, an approx. 25p entry fee that goes to an accumulative pot entitling you to answer all questions posed. The eccentric presenter remains, the live video stream remains as-near-as-we-can-to-broadcast quality – the exception being the intended hundreds of players compete simultaneously, meaning every question and answer must be timed, recorded, logged and audited with a robust and secure system.
I only truly realised the scope of the thing after so eagerly agreeing to build it when I began to comprehend the vast difference between this project and that I’d previously built at uni. We had a substantial amount of R&D time to really consider whether FMS was our best option, it’s capabilities, limits, the licensing – and being the only member of the team with any experience with the FMS, we were cautious to commit if it could be achieved some other way we might feel more familiar with – an open socket model with Java or PHP maybe – but FMS eventually won through.
The project required was a standalone engine to run, load and dispatch data, make remote procedure calls to server-side scripts, all independent of any administrator control unless commandeered. At this point, looking back at Talkboards which stored all dynamic data in persistent shared objects the user simply subscribed to, its entirety was equal to the live chat ‘feature’ alone.
Building this engine immediately began to highlight Adobe’s lack of development with the Media Server since obtaining it. It’s still pretty much Actionscript 1.0 – or near enough, their API confesses ‘Server-side Actionscript’ is just their name for JavaScript 1.5. So OK, back-date the code – and no type declarations unless you want the app to silently unload, but there’s also no use of the Delegate or EventBroadcaster – arguably the backbone for Actionscript development. I also wanted to avoid using prototype functions where I could and try to divide the code into some kind pseudo-class system – not only to be more logical and readable, but for any later hand-over or joining of other developers to the process. But this could only really go so far to contextually separate ASC files that all load from the app’s main.asc anyway.
Problems with the absence of the Delegate and EventBroadcaster are obviously not uncommon. Peldi ported the classes to ASC files in his handy Flash comm server book, some hosting services, such as Influxis, bundle their own frameworks with hosting packages. But the more complex the objects and lengthy the extensions from the top-level Client and Application classes, the more scoping errors I encountered.
Jesse Warden wrote an interesting article concerning the Observer pattern experiencing the same problem developing Flex applications:
“With a little work… you can implement FMS server-side components into Cairngorm 2. For ever server-side component you create, you merely create a client side equivalent as an Observer. It listens for NetConnection or Remote SharedObject sync events and dispatches events. These events run Commands which in turn set data… just like normal. If your Views are bound to said data, boom, you’ve got a nice, clean separation.”
Ultimately we devised a model that essentially handles quite a complex (application) data object, passing itself around via prototype functions, making amendments and modifications and passing itself on. Each client has their own (client) instance (that extends the Client class), enabling their unique connection to call server-side methods – and vise-versa – without needing to loop around the application.clients array.
And finally, last Saturday was the pilot launch. Initially a beta test group of 100 competition winners and by and large, it went extremely well. Surprisingly, the biggest infringement was on behalf of our PHP/MySQL host, who happened to have hardware difficulties that day. So although all still proceeds to go well, I won’t count my money at the table, episode number two is tonight – with an increase to 300 users.
