Ludicrous Software

Here’s a quick optimization tip that can pay big dividends: If you can, try to avoid using functions as the condition of your for or while loops. For example, consider this code:

myString = "lorem ipsum lorem ipsum";
for (i = 1; i <= length(myString); i++) {
trace(substring(myString, i, 1));
}

Every time the Flash Lite player iterates through the loop, it evaluates length(myString) to see if i is less than or equal to the length of the string. However, because the length of myString is not changing, there’s no need to re-evaluate the length of the string with every iteration of the loop. Checking against a simple variable is faster, so you should use this code instead:

myString = "lorem ipsum lorem ipsum";
stringLength = length(myString);
for (i = 1; i <= stringLength; i++) {
trace(substring(myString, i, 1));
}

Because the conditional is a variable instead of a function, you save some CPU time. Depending on the number of iterations in your loop, this can really add up. And as you no doubt know if you’ve been doing Flash Lite development for any length of time, every little bit helps!

Of course, if the value of your condition is changing as a result of the code being executed in the loop, then you will have to use your function as the condition. But if that value is not changing, as in the example above, then this is a simple way to speed up your app.

The big news of the day - which you’ve probably already read about elsewhere - is the announcement from Adobe of the Open Screen Project. The goal of the project is, among other things, to provide a consistent Flash runtime, regardless of the physical device on which Flash content is being used. The highlights of this initiative are:

• Removing restrictions on use of the SWF and FLV/F4V specifications
• Publishing the device porting layer APIs for Adobe Flash Player
• Publishing the Adobe Flash® Cast™ protocol and the AMF protocol for robust data services
• Removing licensing fees - making next major releases of Adobe Flash Player and Adobe AIR for devices free

I think the biggest implications of this for the mobile world are two-fold: rather than having to rely on the player being pre-installed on target devices, it looks like the next version of the player can be bundled with Flash content. Also, by removing the restrictions on the SWF specs, third parties can create a version of the Flash player for specific devices (such as the Blackberry or the iPhone), which will increase the market for Flash content.

This is great news, a definite step in the right direction. Given the fact that this announcement was just made today, take these comments with a grain of salt:

Flash Lite has always been up against a moving target in the desktop Flash Player - a frequent refrain from desktop developers is that they don’t want to develop for mobile because they don’t want to return to coding in previous versions of ActionScript. The gap has been closing of late, with Flash Lite 3 able to play Flash 8 SWFs, albeit with some limitations. But even as Flash Lite makes some gains in one area, the desktop player pulls away in others (e.g. the demo at MAX last year of 3D capabilities in the next version of the Flash Player). Hopefully that gap keeps closing, but I’m not sure that the mobile technology is improving that rapidly. In other words, there will probably always be a number of developers who don’t want to develop for mobile because the devices are under-powered relative to the PC.

How effectively will this deal with device fragmentation? Fragmentation is a multi-headed beast - the problem is not just with the fact that there are multiple, un-updateable versions of Flash Lite on devices. The deeper problem is with the variety of operating systems on all those devices. A FL2 SWF will run on any device that has FL2 or later installed, but installing that SWF is a major stumbling block right now. A SIS file for S60 devices is useless if you have a Series 40 device, or a Windows Mobile device, or a BREW-enabled device, or … you get the idea. The beauty of AIR on the desktop is that an AIR installable file will fetch and install the AIR runtime if your desktop computer doesn’t have it already. That’s a lot easier to do when you’re dealing with just a few operating systems (Windows, OS X, Linux in the future) than with the large number of operating systems in the mobile world. We’ll have to wait and see how that plays out whenever we start seeing AIR for mobiles, but I’ll be curious to see how it’s handled.

Speaking of which, one question I have about the initial list of business partners: where’s Symbian? or Microsoft? Solving the problem of fragmentation at the device level seems like it would require the involvement of not just the hardware manufacturers but also the companies involved in the software side of things. I mean, Nokia and Sony-Ericsson have been heavily committed to Flash Lite for a few years now, but that hasn’t resolved the fragmentation issue. It’s still early, and hopefully we’ll see Symbian, Microsoft, and other similar companies come on board in the near future.

Ultimately, given how early it is, I’m confident that these concerns will be addressed. Now we just need to wait for some news about the timeline involved in all of this!

Not Flash Lite-related, but cute nonetheless: How to customize your cell phone.

For many designers and developers who use Adobe Flash, the introduction of ActionScript 3 was met with some trepidation. The perceived increase in the complexity of ActionScript 3 code compared to ActionScript 2 - including the belief that you must use Object-Oriented Programming to use AS3 - has led some to decide to stick with AS2. This is unfortunate, as AS3 has a number of advantages over AS2. While AS3 is somewhat more complex than AS2, it is not prohibitively so, and the time required to bring oneself up to speed with AS3 is well rewarded.

Learning ActionScript 3.0, by Rich Shupe and Zevan Rosser is, overall, a great introduction to AS3. The chapters are well organized, with a quick run-through of some familiar ActionScript concepts and code. If you’ve written any ActionScript before, you can skip this part, or skim through it just for some reassurance that not everything in AS3 is completely different from what you already know.

The subsequent chapters cover major aspects of ActionScript programming, ranging from graphics to sound and video to loading pretty much any sort of data. For example, the new display list in AS3 is thoroughly and clearly explained; as somebody still relatively new to AS3 I found this to be a pretty significant change to the way I think about Flash, so I appreciated how well the authors covered this part of AS3. And if you think that everything in AS3 only got more complicated, this book is worth it alone for the chapter on working with XML. These and other topics are explained clearly and thoroughly. The authors are both teachers at New York’s School of Visual Arts, and their experience as educators shows through in their writing.

A neat aspect of the book is how it gradually transitions you into thinking about Object-Oriented Programming. For many people, the thought of having to do this with AS3 can be pretty scary. Initially, the code samples are meant to be placed right on the timeline. But part way in you get a primer on OOP. The book explains the concepts behind OOP very well, and gives the right amount of information - enough to get you going, but not so much that you’ll get scared off at the thought of OOP. The code samples are no longer on the timeline, and suddenly you’re working with object-oriented code, and it makes sense.

Those who are already familiar with AS2 will probably get the most out of Learning ActionScript 3.0. If you’re new to programming, and not just new to ActionScript, then this probably won’t end up as the primary book you’ll use to learn how to code. For example, topics that would normally get their own chapters in a ‘learn how to code’ book, such as variables, get only a section of a chapter by way of introduction. If you’ve already done some coding, this will be enough to reassure you that not everything is significantly different in AS3, but if you’re new to programming, you might want something that spends a little more time on the basics.

In addition, the book would have benefited from another round of proofing. There were a few typos that, although minor, were a bit of a distraction. The typos that I came across were pretty minor - nothing that you won’t immediately notice, but it’s too bad that they’re there in the first place. And to be fair, I think I noticed only about a half-dozen throughout the book. (By the by, the errata page at the book’s companion web site is much more complete than the page on O’Reilly’s web site.)

Obviously, if the most significant criticism I can make of this book is that there were a few too many typos for my liking, I think it’s a very good book. If you’re looking to make the jump into ActionScript 3 coding, Learning ActionScript 3.0 is a great place to start your education.

Adobe Device Central is great for testing Flash Lite content, but you can also use it to test HTML content. Since many phones have Flash Lite pre-installed only as a browser plug-in, it’s great to be able to actually test the content in the browser context without having to test it from an actual device.

The problem with Device Central is that it’s not immediately obvious how to do this. If you look under the ‘File’ menu, there’s only one option for loading content: ‘Open’. And if you select ‘Open’, you get the standard file open dialogue box. There’s no immediately obvious place where you can enter a URL for testing.

Here’s the trick: in the ‘Open File’ dialogue box, select an HTML file to open. You’ll see the HTML page rendered on the currently emulated phone. The other thing you’ll see is a panel on the right-hand side of Device Central called ‘Rendering’ - from what I can tell, the only time you’ll see this is if you’ve opened an HTML page.

Once you have the ‘Rendering’ panel open, you can enter URLs in the panel, and they’ll load and be displayed. This isn’t a perfect replacement for on-device testing, but it’s a handy feature to have. It’s unfortunate that it’s not easier to get to from within the Device Central menus.

The question of how to sort emulated arrays came up on one of the Flash Lite email lists, so I thought I’d post my solution here.

// fake array
p1 = 5;
p2 = 3;
p3 = 6;
p4 = 2;
p5 = 9;
arrayLength = 5;
// sort
for (outer = 1; outer < arrayLength; outer++) {
for (inner = outer + 1; inner <= arrayLength; inner++) {
if (eval("p" add inner) > eval(”p” add outer)) {
tempVal = eval(”p” add outer);
eval(”p” add outer) = eval(”p” add inner);
eval(”p” add inner) = tempVal;
}
}
}
// show results
for (i = 1; i <= arrayLength; i++) {
trace(eval("p" add i));
}

The code is pretty straightforward - basically you’re just looping through each value in the array, comparing that value to all of the other values in the array. If another value is larger, you swap the two values. The result is an array sorted from highest value to lowest. If you want to sort from lowest to highest, simply change the ‘greater than’ in the if() statement to a ‘less than’, and you’re good to go.

One thing to be careful of is if you’re sorting a very large number of values. The nested for loops can result in a large number of iterations, and could cause your movie to hang. If that happens, simply break the code over multiple frames, using counters and conditionals to iterate through the array.

Rotating a movie clip so that it point toward a specific point is a handy little technique. If you’re using Flash Lite 2 and up, it’s pretty easy; this code will do it for you:


// 'point' is what we want to rotate toward
pointX = 50;
pointY = 50;
// 'rotater' is the clip that we want to rotate,
// so that it's pointing toward 'point'
rotaterX = 100;
rotaterY = 100;
// get the X and Y distances between the two objects
dX = pointX - rotaterX;
dY = pointY - rotaterY;
// find the angle between the two objects
radians = Math.atan2(dY, dX);
// convert from radians to degrees
angle = radians * 180 / Math.PI;
// apply the angle
radar._rotation = angle;


What makes this such a simple technique is the use of Math.atan2(), which does all the heavy lifting.

The Math class is available in Flash Lite 1.1, which is based on Flash 4 ActionScript. But, as the help docs in Flash 8 (although not Flash CS3) say, “In Flash Player 4, the methods and properties of the Math class are emulated using approximations and might not be as accurate as the non-emulated math functions that Flash Player 5 supports.” Math.atan2 is one area where the Math class is inaccurate. The result of this is that rotation toward a point only works as expected when the _x value of the point is larger than the _x value of rotating object.

The work-around for this is some extra code that checks the exact position of the point object, and adjusts the value of the angle accordingly. This sample file shows how all of this works. If you publish this as a Flash Lite 1.1 file, you’ll see that the arrow doesn’t point in the right direction when the ball is to the left of the arrow. If you publish the file as a Flash Lite 2 or higher file, the code works as expected. To get it to work in Flash Lite 1.1, you need to uncomment the conditional code in the second frame.

GDC Mobile has come and gone for another year, so I thought I’d post some thoughts about the event, both in general and from the perspective of a Flash Lite developer.

Generally, it was a pretty downbeat conference this year. The overarching theme was basically that the mobile operators are making it really, really difficult to work in, let alone innovate, in the mobile games space. Almost all of the presentations I saw to some degree touched on the notion that the mobile games industry won’t significantly grow or evolve unless something is done to break the operator’s strangehold on distribution of mobile games.

The advent of the iPhone and other Wi-Fi-capable devices was seen as an important first step toward that goal - in one session, a poll was taken of iPhone owners in the audience, of which there were many, and not one had visited their mobile operator’s deck. Of course, in the case of the iPhone there’s the very real concern that distribution through iTunes is basically just substituting one tightly controlled deck for another. But, the general notion that mobile users are growing more comfortable with the idea of accessing content off-deck was greeted quite positively.

The other major general theme was the growth of SNS (Social Networking Systems) in mobile. David Collier (DC) of Pikkle demonstrated some of the most popular Japanese mobile SNS during his talk, and another session was all about the SNS elements of Playyoo, and various other presenters mentioned social networking as an important component of any mobile app.

In terms of Flash Lite specifically, it had some representation in the presentations that I attended. Most notable was DC’s presentation about SNS in Japan, in which all of the games and, in some instances, the entire interface is developed in Flash Lite. (Disclaimer: I do some work with DC - and had the pleasure of seeing one some of my stuff demonstrated during his talk. So while I think it’s all pretty darn cool, I may be biased.

Although the presentation about Playoo was not about the games, per se, all of the games on Playyoo are also done in Flash Lite, so this was another notable mention.

Outside of that, Flash Lite received passing attention in some of the other sessions, for two main reasons:

1. Rich visual experience. Much easier with Flash Lite than other technologies.
2. Reduced/non-existent porting costs. In the Monday keynote, the CEO of Gameloft said that they have to maintain 50,000 SKUs for five games, given the number of handsets they target and the languages the game will be translated into. Consider that Gameloft releases about five games per month, and you quickly get an idea of how much time, money, and effort is spent in porting.
   By comparison, DC mentioned during his talk that in developing a site that targetted about 200 handsets, he only tested on 20 of them. Tested, not ported. And since it’s next to impossible to actually get a Japanese device outside of Japan, I can’t even test on them at all. Obviously, Flash Lite won’t help with the need for localization, but it’s great saver of time and money to be able to drastically reduce the number of versions you need to maintain because you know your swf will scale nicely.

Overall, in comparison to last year’s event, I think that the general reception/perception of Flash Lite is much improved. At last year’s GDC Mobile, there were a number of sessions devoted specifically to Flash Lite. However, the general buzz amongst the people in attendance seemed rather dismissive - there was a lot of focus on the limitations of Flash Lite compared to J2ME or other mobile development environments. This year, however, it struck me that Flash Lite is starting to find its niche in the larger mobile game development world, and was generally recognized as being an important part of the ecosystem.

The website for Game On Manitoba, an initiative to promote the game development industry in the province, is now live. I’m proud to be one of the initial companies promoted on the site - hopefully in the not-too-distant future there will be many, many more!

Recently finished up working on a site for the University of Winnipeg Classics Department. It’s a pretty straightforward little site, but working on it was a lot of fun, since all of the photos or monuments, ruins, etc. were from our vacation photos:

Had I known that I’d be doing this site someday, perhaps I could have claimed those trips as business expenses! Oh well, maybe when the site needs to be updated…