Thursday, September 24, 2009

More Flash youtube fun

This works pretty well, though flex debugger seems to sometimes interfere and break it, making it a bit of a challenge to develop.

As it seems it has to be the case with youtube it mostly works, but not totally, the problem here being with the error handling. According to the documentation it should dispatch an event when the youtube video is either not found or is not available for embedding. It didn’t. After doing some checking and verifying that it wasn’t my code I opened up and found that there was nothing in there to handle any errors coming from the javascript. I then checked the javascript and found that there was also nothing in there to send or receive error messages from the as2 youtube player you’ve loaded in.

Simples, I think. I amended the javascript to catch the errors from the as2 player, then added in code in to catch the externalInterface calls. Feeling very smug I tested it out. I found that youtube are bollocks. A working youTube video always dispatches a 100 error, right at the start. This is the error for video not found. When video is not found it is also dispatches this error. There is no way of telling them apart. It does however send the 150/101 error correctly, which is the error for when the video is there but you’re not allowed to embed it.

So my solution is to keep in the error catching functions I added to catch when the video is there, but not allowed, then put in something that makes a request to the youtube api for the info on that video. If the ID is wrong or the video doesn’t exist then this will fail. I don’t like having to split my error handling up but it seems to be the only way.

Why youtube can’t get a measly couple of flash devs together to write a solid working player with no bugs or surprises is beyond me.

My changes to youtubeLoader.js:

function onYouTubePlayerReady(playerId) {
if (checkObj()) {
obj.addEventListener("onStateChange", "onytplayerStateChange");
obj.addEventListener("onError", "onytplayerError");
function onytplayerError(newState) {
//alert("Player's new state: " + newState);

My changes to

ExternalInterface.addCallback( "playerErrorHandler", playerErrorHandler);//Added to constructor
private function playerErrorHandler(errorCode:String):void
var e:YouTubeLoaderEvent = new YouTubeLoaderEvent(YouTubeLoaderEvent.IO_ERROR);
e.state = errorCode;

Wednesday, September 23, 2009

Flash youtube nightmares.

So at work I’m working on a project that requires that youtube videos be embedded and controlled in an AS3 site. Unfortunately those lazy bastards at youtube still only have an AS2 chromeless player. This means that when you load it into your AS3 movie you can’t control it directly, you have to go through either local connection or javascript.

After a quick bit of research I decided on going the localConnection route, using TubeLoc, a nice and easy wrapper that loads in a ready made as2 swf and communicates using localConnection. Pretty simple and easy and I thought I had it cracked. Then we tested it around the office and found that it wouldn’t work on any of the office macs. It would work occasionally, but not reliably.

I got the tech department to set me up with a macbook myself so I could do some tests and research and found some pretty horrifying things. I found lots of people referring to localConnection not working correctly on Macs, especially since the last flash player update ( Indeed, adobe did make a big change to how localConnection works on macs in that update, though they swear blind that it should be fully backwards compatible.

To test I made 2 swfs that use localConnection to simply send the contents of a text field back and forth. These worked perfectly on a PC, but on sporadically on the mac when I rebooted.

After this I concluded that I couldn’t trust localconnection, and so went over to the javascript method for the youtube api. This works, though it is a bit of a hassle, and it means that you can only test in a web-browser with the correct html and files.

If anyone has any suggestions I would love to hear them, otherwise I just wish Youtube would get off their arses and make an AS3 version of the player.

My localConnection test (switch LocalConnectionTest0 and LocalConnectionTest1 and save with different names - make sure you drag onto the browser as you standalone flash player probably won't be latest version):

package {
import flash.display.Sprite;
import flash.text.TextField;
import flash.text.TextFieldType;

public class LocalConnectionTest extends Sprite

private var receivingConnection :LocalConnection;
private var sendingConnection :LocalConnection;
private var inputTF :TextField;
private var outPuTF :TextField;

public function LocalConnectionTest()
receivingConnection = new LocalConnection();
receivingConnection.client = this;

sendingConnection = new LocalConnection();

inputTF = new TextField();
inputTF.type = TextFieldType.INPUT;
outPuTF = new TextField();
outPuTF.x = 200;

var btn:Sprite = new Sprite();
addChild(btn);;, 100, 20);
btn.addEventListener(MouseEvent.CLICK, send);

public function onLocalConnectionEvent(object_p:Object):void
inputTF.text = object_p.text;

public function send(evt:MouseEvent):void
sendingConnection.send("LocalConnectionTest1", "onLocalConnectionEvent", {text:inputTF.text});
inputTF.text = "";

Monday, September 14, 2009

The ethics of flash games sites.

OK, so I have my distinctly low rent flash games site up and running. While I am pleased I’m not 100% happy. This is because deep down I think that there is something deeply scummy and unethical about running this kind of site. The whole concept strikes me as being faintly parasitic. Essentially I’m trying to build a site using other people’s content without really adding any value of my own. I keep on telling myself 'hey, this is how the web works'. To an extent that's true - look at aggregator sites like the Huffington post, but that doesn't really say much. At least I'm not doing the Ebaum's world thing and pretending the games are mine.

A large part of my dislike for this kind of site stems from the fact that when I first started in flash game there was no Mochi ads, and my first, most popular games pretty much earned me nothing, despite clocking up millions of plays between them. None of my more recent, Mochi enabled games have been anywhere near as successful (lack of competition back then probably) and I’ve never been able to make any decent cash out of my games. Something I’m still oh so slightly bitter about.

Luckily now things are different. Mochi ads have changed everything, in that if someone has ads at the beginning of their game then any hits are good hit no matter where they come from. The other common way for game creators to make cash is by selling sponsorship, and I guess for that purpose any hits are good hits. I try to only put up games that are either clearly sponsored or have ads.

At some point I may try sponsoring some games myself, but as the moment I don't have the cash for that or the site/ad to take advantage of any upticks I may get. To be honest if I wanted to sponsor some good games that would actually generate some traffic I'd be up against the big boys anyway, and I don't think I'm up for that. At the moment the site is still a spare time hobby thing. Once you start sponsoring you need lawyers, accountants etc.

So, for the moment I'm going to try to carry on like this. I have a few games in the works, but my day job has really picked up and I'm not sure when I'll have enough time to look at them. Then I can start adding some games of my own and actually feel like the site isn't so worthless.

Wednesday, September 02, 2009

Sam's guide to freelancing
Part 1: Making an impression*  
Or rather, not making the wrong type of impression. 
This relates to two different facets of freelancing in digital agencies. The first is that most small to medium size agencies seem to have large tech departments, and as a consequence a gender spread of about 2 men for every woman. Unfortunately in too many case for me to count they will also have only 2 toilets and despite the gender disparity they divide them into one men's and one women's.  
The second is that at least initially people won't know who you are. Actually the chance are that they'll probably never know who you are unless they've worked with you directly. This means that if they need to refer to you down the line, say when they need more resource or (more likely) the project you worked on develops bug, they'll think of whatever first spring to mind.  
'Remember that big freelancer guy we had in?' 
 'You mean the dashingly handsome one?'  
'No, the morbidly obese one, you know, the one with really bad BO.'  
'Oh! That guy who did that huge dump in the women's toilet and we had to call the plumber?'  
Bingo. Don't let this be you.

*This may, or may not become an ongoing series depending on whether or not I can think of more nuggets of wisdom to share. And if I can be bothered.