Archive for the ‘actionscript’ Category

In detail: Mathmos (Part II)

Wednesday, July 15th, 2009

mathmos-small-3

Last summer, Mathmos asked us if we fancied doing something for the 45th birthday of their iconic Astro Lamp. We felt that a natural fit for this would be a screen saver that simulated the lava lamp.

From a coder’s perspective, this project had two interesting problems to solve. Firstly, we had to consider the physics at work inside a lava lamp in order to create a realistic simulation. Secondly, once you’ve figured out where your blobs are, their sizes and how they’re moving, you need to draw them in a satisfyingly blobby way.

This second post will cover how I went about drawing those blobs. You can read Part I here.
(more…)

Adding mx.* libraries to FDT

Wednesday, May 27th, 2009

For my most recent AS3 project, I’ve settled on developing in Eclipse/FDT and have set up the Flex compiler for building. In general, this works great, but every so often you run across a snag, as the FDT/Flex setup has its quirks.

Today, I added a SWF asset to my main class, like so:

[Embed(source="../../assets/frame.swf")]
[Bindable]
public var Frame:Class;

but upon compiling, mxmlc threw the following error:

Error: The definition of base class MovieClipLoaderAsset was not found.

It would appear that using the [Embed] metatag requires the presence of some classes you’re not going to get by default. 

A quick Spotlight search later revealed MovieClipLoaderAsset.as in the following location:
{Flex SDK}/frameworks/projects/framework/src/mx/core

Adding the framework source folder:
{Flex SDK}/frameworks/projects/framework/src to my project as a new linked library solved the problem and the compiler was happy again.

I leave this note here in the hope that it proves useful to someone else one day ;)

Launchball

Monday, October 8th, 2007

So it’s been a while since I posted anything here – largely, my interest has been directed elsewhere. However, I’ve decided to keep this blog for professional stuff, and it’s with that in mind that I’m posting today.

I’ve just finished my latest project at Preloaded, a physics-based game in the mould of classics like The Incredible Machine: challenge the player to build a Heath Robinson contraption to get from Point A to Point B. The project was for the Science Museum to support the relaunch of their Launchpad exhibition, which made it an interesting challenge: we had to reflect the hands-on experience of visitors to the gallery, keep the physics accurate enough that we wouldn’t be giving out any bad, counter-educational messages and keep the thing fun enough to keep people entertained while they’re absorbing the science.

One of the first big decisions we made was to use a third party physics (or, more specifically, dynamics) engine. The reasoning here was that I could either have spent most of the project time busting my heed over the finer points of vector integration and rigid body dynamics, or we could use one of the fine open source engines out there and I could spend the time making the damn thing fun instead. Practicalities aside, I’m very much into the idea of pushing an open source agenda at Preloaded anyway; I think we could make a really good contribution to the community and get a lot back if we managed it properly. Flade was the obvious choice (at least, while we’re still an AS2 house), and Alec Cove has my undying gratitude for making such a great engine and being cool with our using it.

The next decision, then, was what blocks we should include in the game. Bearing in mind the point about realism, this ruled out a lot of stuff like transporter beams, cannon, lasers etc. The eventual set we ended up with were the result of a lot of back-and-forth with the Science Museum staff, based on discussions with their content team and, in some part, on National Curriculum Key Stages 3 & 4. I then spent a month implementing the decisions we’d made, tweaking the physics like a madman all along the way. This was precisely the point all that stuff I’d ever been taught about both science and object-oriented programming came in very handy indeed, and let to some interesting points where I’d start having thoughts like “this magnet will always be affecting the ball in some way. Does that mean every magnet in the universe affects every metal thing in some minute way?” and have to step away from the computer and have a nice cup of tea and a little rest.

Outside of the game engine itself, we had a lot to think about in terms of user experience. As the game’s aimed (mainly) at children, we had to make sure that the UI was clear and easy to use, which we refined in collaboration with Science Museum staff over many iterations. Additionally, we decided fairly early on that an important part of the game would involve giving players the chance to build and share their own levels. This meant we were going to need a pretty involved backend, handling user accounts, sending out share emails and, most importantly, managing both in-game and created levels. Stephen Pope at Eduserv did an amazing job building a webservice to provide all the functionality we needed and fielding increasingly frenzied IM conversations during crunch points. The client/server interactions we’re doing with the game could swallow a blog post by themselves (and are the reason we couldn’t host it elsewhere, Digg trolls ;) ), but I’ll save that for a rainy day…

I didn’t have much involvement with the level creation process, outside of making the sandbox editor usable enough to make it possible, but three evil geniuses on the Preloaded staff came together and did a brilliant job of it – seeing stuff done with the engine I’d built that I had no idea was possible was a big grin moment. Jon (the last of the three geniuses in that list) was the design ninja behind the whole thing and also possesses an admirably geeky brain which frequently made stuff clear that I couldn’t see for looking. Frankie Roberto, one of the team at the Science Museum did some good work too, providing some of the more surreal levels and helping us out with the CMS.

I’m incredibly proud of the end result, even though at times it made me feel like quitting Actionscript entirely, buying a lathe and moving to the country to make furniture in a barn. It’s certainly the most ambitious and fun thing I’ve done to date, and early indications would seem to show that the internet digs it too: when an early version got posted to Digg, it generated enough traffic to kill the Science Museum’s server (good news for us, bad news for the poor guys at Eduserv who were probably quite surprised when one of their boxen started to do its best impersonation of an Aga).

Big fat thankyous to the Science Museum for being supportive and helpful clients, especially Frankie and Daniel Evans, and dirty great manhugs also to Barnaby Sheeran, Simon Oliver and Alias Cummins, Brothers of the Curly Bracket who all helped me out of sticky points of one sort or another. Respectful nods to Phil and Rob, my bosses at Preloaded who kept the whole thing shiny, and Jason and Sarah who kept the project running, despite my increasing crankiness.

So what’s next? Being at an agency means I’m kind of at the mercy of the work that comes through the door, but game wise, I’ve been really inspired recently by tangible interfaces, especially the reACTivision; it’d be awesome to build something which had a bit of a physical presence. A nice, well crafted platformer with a really neat core mechanic would be nice, too. The idea of trying to develop something for a console also appeals: the Wii/Flash stuff is starting to look enticing, as are the possibilities made available by the DS homebrew scene, and XNA Game Studio hasn’t escaped my beady eye either: it’s starting to look like an interesting little ecosystem is starting to breathe on Xbox Live Arcade.

But first, a week with my criminally neglected, saintlikely-patienced girlfriend in the sun, as far away from computers as possible ;)

Screenweaver HX, file I/O and UTF8: A cautionary tale

Thursday, February 1st, 2007

As I mentioned in a previous post, I’ve been using Screenweaver HX to build a little seat-planning app. Well, thinks got a point today where I was ready to start importing the client’s list of attendees (an Excel sheet, naturally). So I decide to go the time honoured route of exporting a tab-separated text file and parsing that in Flash, after getting the contents in via a file open call in the haXe backend (file I/O in Flash! Hurrah!). However, as soon as I do this, Flash chokes on the import.

Now this is weird, becuase I’d been using exactly the same file open stuff to get in my development testing data (a nice, sane XML file) and the app had been playing just fine. Long story short, after banging my head against a brick wall for a few hours (even to the point of offloading all the parsing to the backend, and passing a neatly parsed array to the hosted SWF, which also failed), I figured out that Flash was choking because the offending text file wasn’t UTF-8 encoded. A quick insertion of this line:

content = neko.Utf8.encode( content );

into my file opening method in the backend solved all my problems and I could loosen my jaw muscles again :)

So, the moral of this story is (besides always read the friggin’ docs) is: if you’re doing text file I/O in Screenweaver, always make sure you UTF-8 encode before handing it over to Flash. Here endeth today’s lesson.

Screenweaver HX

Tuesday, January 30th, 2007

So I’ve been playing about a bit with Screenweaver HX recently in order to make a little app to generate seating plans for some swanky industry dinner or other (but that’s another story).

So far it looks pretty cool – once you get your head around the fact that, unlike with other extended projectors, the functionality of the projector is defined by another script (written in haXe, which also looks pretty awesome), which you have to write and compile yourself. Of course, this makes it about a gazillion times more flexible and extensible than any other extended projector I’ve come across, but also a bit of a headfuck. So much like any other open source effort then :)