Facebook Developer Event

We were fortunate enough to be invited to a Facebook Games developer event, taking place in London – just a quick trip down the East Cost rail line and we’re there.

The content was to cover Facebook’s new HTML5 approach to gaming on mobile platforms, with a little more detail about exactly how to do this as a developer.  And a Q&A and networking session after the presentations.
Exciting stuff, especially when this is a market you want to bust in to!

But, it seems, the British transport system had other ideas.

After leaving Yorkshire, bright and early (or so we thought!) with the sun shining and the prospect of a great event in the near future, we settled in for the two and a half hour journey to Kings Cross.
With only the terminating station to go, it looked like we were going to arrive on time.  Then the train stops and a glorious announcement hails over the speakers – “Track Circuit problem”, whatever that means.

A half hour later, we’re moving.
OK, we can recover from this, we allowed for the extra time and can make the venue with time to spare… and the trains motoring southbound.

But guess what?  It stops again with another announcement.
It turns out, signalling equipment doesn’t like getting struck by lightning (did I mention it was sunny in Yorkshire?  Not so in London!), which apparently set all the signals to red and “engineers were en route”.

After an hour of this (and thoroughly getting to see Potters Bar station) we were off, again.  Hmm, we’ve likely missed the first speaker at this point and, by the time we get to KX, switch to the Underground and make the venue, we’re certainly cutting into the next set of speakers.

We’re moving again, yay!
Oh, wait, we’ve stopped… again.  This time, because of all the backed up trains, there’s a queue getting into KX and we’re “just going to have to wait”.  Glorious.

By the time we get moving and mercifully only stopping when arriving at the platform, the schedule for the event is now well into the Q&A and we’ve still got to switch to the Underground and get to the venue.
(We remained in contact with people at the event and, at this point, agreed that we would get some notes and phone calls on the event – not the outcome we would have preferred, but silver lining and all that!).

Oh, there’s more!
With the event having a laid out timetable, we’d pre-booked our tickets and, being an indie studio (ergo, without vast sums of cash) we couldn’t just fork out on replacement tickets.  Why would this matter?  Well, the pre-booked tickets only work on a specific train.
Migrating over to the ticket office, where you can hear other travelers screaming, arguing and otherwise being obnoxious or aggressive, we figured we’re in the right place.  It must have come as a shock to the staff member dealing with us when we’re all smiles and, apart from being gutted about missing the event, just wanted to somehow afford return tickets.
With a free change to our tickets that read “Natural Disaster” and allowed us on any train, we set about trying to get a return train and, after some 9-hours, made it back to the office… well, home, as 9-hours is a LONG day (especially when it’s just sitting on a train).

If we learnt anything from that day, it’s that lightning is bad.  Very bad.  Oh, and smiling gets you a long way!


Away3D: Scale/Rotate/Translate an Object3D

Away3D is an incredibly complete, simple to use and powerful real-time 3D engine for AS3 (yes there are others, including Papervision).  We’ve been playing with some 3D within AS3 for some time now, creating a complete pipeline from 3D application (Blender!) to Flash Pro CS5 and finally to Flash Player (or AIR).

During all of this, I recently hit upon a most interesting of problems, and that is: dynamically updating the scale/rotate/translate properties of an Object3D.

Object3D is, according to Away3D’s API documentation the base class for ALL 3D objects.
If one creates a simple primitive – a cube, in this case – and then, in the render loop, increment the rotateY property of our cube, then it spins, merrily.
Try this on an Object3D (where you’ve imported a COLLADA file, in our case) and nothing will happen.  Zip.  Nada.  Bupkiss.

After many hours screaming “WHY!?”, coupled with Google searches aplenty and looking at the documentation, we couldn’t fathom the problem, let alone the solution.  Here we have a primitive, the cube, which inherits Object3D’s properties and yet, all of these properties update very happily… and yet, the Object3D in itself, does not!?

If you check the Away3D tutorials, they have this one that demonstrates rotating objects (and counter rotating a cube)… so how did they do it?  And why does our imported object not move?

The solution is crazily simple!
Create an ObjectContainer3D.
Add the Object3D as a child of the ObjectContainer3D.
Now alter the properties of the container and watch that Object3D spin as happily as our cube did.

If anyone out there knows why the first method doesn’t work, please let us know!  But even looking through all the mailing lists and Google groups postings for Away3D, we couldn’t spot others either with the problem, let alone a solution.  Maybe there are others out there, also unable to solve this… and if so, you’re welcome!


Flash CS5 – 5005: Unknown error optimizing byte code

A quick post, as this issue has been covered in massive amounts of detail over at negush.net but this really is a doozy!

Basically, if you have a LOT of code and/or library files being compiled into your project and then… poof… Flash drops this crazy error:

,line 1: Error 5005: Unknown Error optimizing byte code

OK… what?
If you try and ask Flash for more details, it tells you there aren’t any.  Wonderfully useful.

For us, it was adding the Bamboo SDK files (a pair of SWC libraries) to an already hefty project, that pushed the compiler over the edge.
But, fear not, for there IS A SOLUTION!

There are many suggestions in the link provided, but the one that worked for us was to add an environment variable to the operating system:
Value: -Xmx1024M
Then reboot your PC – that should allow the environment variable to take affect.

This is telling/allowing the Java Virtual Machine to use up to 1GB of system RAM to perform any single operations… or something to that effect.  Open up Flash (in our case, Pro CS5) and compile the troublesome project.
Et voila.  It works!