TRAUMA – Entangled in API

Sometimes I want to strangle the people, who made the Flash API. I’m imagining a long conveyor belt with all the Adobe employees on it waiting for their turn to receive their deserved treatment. Loading sounds and images is relatively easy and carefree. Here, let me prove it. Here is what you need to write in order to load an image.

var myLoader:Loader = new Loader();
myLoader.load( new URLRequest("lolcat.jpg") )

Cool. Just two lines. One where we create object that loads our stuff, the second to tell the object to actually load the stuff. It works this was for images, sound files and even entire flash movies. Of course there is a lot more code you need to add in order to keep track of how the loading is progressing but the core idea is simple and easy.

But then for no apparent reason the Flash API throws you a curve-ball and decides to make things different for flash video. Loading a Flash video requires this kind of code:

connection = new NetConnection();
connection.connect(null);
stream = new NetStream(connection);
var customClient:Object = new Object();
customClient["onCuePoint"] = cuePointHandler;
customClient["onMetaData"] = metaDataHandler;
stream.client = customClient;
var video:Video = new Video();
video.attachNetStream(stream);
 stream.play(videoURL);

I’m not kidding. You actually need to create 4 different objects just to play 1 video. And then it doesn’t actually even really load it. Instead it “plays” it. You see, the entire setup is made to be also compatible with video streams. So the video is not actually being loaded but “streamed” from the file. This is a cool feature but TOTALLY not what I need most of the time. Most of the time, I just want to load a video completely into memory so I can be sure it will play without stopping when requested. The API doesn’t deliver even the most basic tools for doing that like giving a simple, distinct signal that the video is completely loaded for example. And if that’s not annoying enough, just wait for all the exotic errors and the cryptic documentation this API has in store for you. Want a taste? This is taken verbatim from the Flash Help:

asyncError - Dispatched when an exception is thrown asynchronously - that is, from native asynchronous code.

Meaningless tautology is meaningless. Thanks Mr. Programmer Nerd who wrote this crap. I guess the deadline for the documentation was looming and you just didn’t have the time not to pull out something out your ass, huh?

So as you probably picked up by now, I’m in there and fighting. I didn’t quite manage to finish the video loading system today, which is a major downturn for me. After a lot of struggle, I got it running but it’s not yet fully integrated and it’s missing some less vital features. I postponed the cleanup for tomorrow.

I guess I could have made it all today but my girlfriend came back from a weekend trip and because I think she is awesome I decided to spend some quality time with her. We went to see Tangled together.

Take note, games industry: this how you crunch Indie-style.

Day9 Flip

Taking it DOWN!

P.S.: I was blown away by the visuals and animation quality of Tangled. It’s such a cute and well-made movie. And balls-out-cheesy, too. You know, the best kind of cheese.

Krystian Majewski

Krystian Majewski was born in Warsaw and studied design at Köln International School of Design. Before, he was working on a mid-size console project for NEON Studios in Frankfurt. He helped establish a Master course in Game Design and Research at the Cologne Game Lab. Today he teaches Game Design at various institutions and develops independent games.

One response to “TRAUMA – Entangled in API”

  1. Digital Tools

    Unfortunatelly there isn’t any perfect API. There is always something, where borders are met. I think this is not my intension, but reality and thinking is much more flexoble than we think – or can map into code. Sad, but true. From mine point-of-view, coming recently from Cocoa and UIKit, the solution above looks ridiculous simple in my eyes.. ;)

About

The Game Design Scrapbook is a second blog of group of three game designers from Germany. On our first blog, Game Design Reviews we describe some games we played and point out various interesting details. Unfortunately, we found out that we also need some place to collect quick and dirty ideas that pop into our minds. Hence, welcome to Game Design Scrapbook. You will encounter wild, random rantings. Many of then incoherent. Some of them maybe even in German. If you don't like it, you might enjoy Game Design Reviews more.

Twitter

follow Krystian on Twitter
follow Yu-Chung on Twitter
follow Daniel on Twitter