Simple Simulations

It's finally time for me to hand in one of my final projects. And what might have I done this time? Some strange thing mocking airport security. As I write this, I'm thinking of more ways to actually make fun of airport security; but let's say for now it is quite advanced.

At it's heart, it's a simple game of "build the ideal maze". The computer passes in about 64 little smiley faces, and each has to be able to get through your maze as quickly as possible, or they just give up. But if they give up, they still need to navigate themselves out of the maze. The greatest challenge is probably building a maze that can accomodate the 3 different targets that a smiley can go for (exit = boarding the plane, exit = give up, other smiley to arrest it).

Then, there's the fun fact that it's all done in Flash. This project gave me a good idea of what can and cannot be done in Flash -- and for the record, this is an example of what can be, but shouldn't be, done in Flash. Reason? It's too slow. My poor laptop is having trouble running it -- placing down a tile in the maze just pauses the simulation while it recomputes the optimal paths and other things that it needs. I found myself caching as much as possible, creating huge arrays and never destroying them just to prevent calculating things twice -- if this were in C, I wouldn't need to do that... Also, those weights are adding more calculations to the breadth-first-search... hmm, need to find better algorithms.

The interesting thing about the simulation is that at times it bogs down (too many smileys in one location, each stuck for some reason or another) ends up naturally fixing itself up; if it is given time. It forms clear dips in the output statistics graph. But how can they get stuck if there is only 1 path? Well, checkpoints are the way to win the game; they stop your character, and if it stops for too long, it has to wait for an officer to unblock it. That means the others wait, get unhappy, and give up on boarding the plane (hence, you need multiple interrogation stations, and a clear path for the police to pass, and it's probably best giving a path for those that gave up so they don't get in the way)... I'm probably having more fun playing with it now, then anything else. So, back to having fun!!!

Weeeeeee!!!!

Flash Coding

For my last pattern recognition assignment (dealing mostly with formants and fundamental frequency of voice), I decided to use Flash/actionscript; and to compare that to my experience of using C# for my previous assignments (which tended to deal with bitmap data). Also -- I've done other (bigger) projects in both; to the scale of over 10 classes (I like to keep my code organized).

C# was fun to program in. There is a panoply of existing objects to quickly get started to do practically anything. Debugging was easy and painless, and the squiqling up of the code like any word document was a nice addition (in comparison to XCode). The language has practically the same semantics as Java (both are managed/in a vm with reference counting galore -- well, a sophisticated version of reference counting). The documentation was easy to read; and I needed no help what-so-ever from Google's web search to complete the assignment (except for the odd bit of code that quickly loaded up the bitmaps).

Flash was fun to program. Admittedly, it is based around a different philosophy of programming. The built-in finite-state machine (aka timeline) made it possible to have very differing screens when buttons on the menu are pressed -- the easiest way to do that in C# would be through big if/else statements, or dynamically loading/unloading components. Debugging is really primitive in Flash -- I have not managed to set up a breakpoint that actually breaks... I'll investigate this later; for now trace is my trusty friend. Since the program is interpreted, some errors it only reports at run time -- and by specifying types, Flash will attempt to say if there will have any errors at run time. This prediction of errors can be wrong -- in the sense that it doesn't find errors, or that it finds non-existant errors. All-in-all, it's quite usable. The documentation, opposed to the one from Sun/XCode feels as though it's as good as the MSDN -- however I did have a bit of trouble the first time I used the BitmapData object -- and still do when it comes to loading images with transparency. Also, errors in the documentation sort of made it difficult... UI is what Flash does much better than C# -- where I'd import a bitmap for a coordinate system, I just draw them in Flash. Lastly, flash is resolution independant (if you don't use bitmaps), and is cross platform -- some nice incentives especially when you're doing all your homework on a Mac, and it will be graded on a PC or Linux box.

All in all, this just shows that Flash is as viable a language as C#/C++ for programming assignments. Actionscript hasn't let me down as a watered down language for designers, but as a nice semi-complete (public, private which acts like protected, no protected) OO implementation.