The problem is that me and a friend working on a game don’t have the time, energy or mental fortitude to port our game to all those platforms. This has been the dilemma of the mobile application developer for years. Unlike desktop development where 90% of your market runs the same platform, mobile is, has always been and very likely will always be a fractured market with no clearly dominate player.

What this means is that I need to put in a lot more work for my apps to reach the majority of smart phone users. I have worked at companies that make their own mobile frameworks with the dream of one day being able to plug an xml file through their machine and have a blackjack game (for example) spit out the other end. Problem is that platforms are always being updated forcing you to always update your framework. The biggest problem though is that if your apps are so simple that a framework can make them, it will be faster and cheaper to just build the apps using reusable code.

Adobe is trying to be the new Java (only focusing on the front end rather than servers). As an independent developer, I applaud their efforts but gotta say mobile Flash is in an alpha stage right now and is not ready. After trying to port my tower defense game to my Nexus One, I was surprised to find everything was just really slow, across the board. I put in some diagnostic code and discovered that the mobile version of my game takes 50% longer to do everything. 30 FPS became 20 FPS. What I thought would be the processor intensive parts of the game (the path finding) actually ran fine. It was the graphics, drawing one circle around a selected tower slowed things by a further 35-50%. I have heard that when doing mobile Flash development to avoid using any vector graphics (using the Graphics API), but the truth is that any vector graphics kills your apps performance to the point where vector drawing shouldn’t be allowed on mobile Flash, it is unusable.

Of course, the problem is that once you do that, you fracture your cross-platform platform. But that doesn’t really matter anyways as just using Sprite’s and bitmaps alone slows my app down to the point off being unusable (and those are essential to Flash). If you look at Adobe evangelists showing off Flash on their phones, they are usually apps where there is very little movement (showing an image gallery is common). I wish they would stop doing this as I find it misleading. What would be great is for Adobe to instead advise developers on how to optimize their Actionscript code for mobile devices (other than a few forum posts, there is really nothing on the web providing guidelines on this). If this isn’t possible, developers are going to abandon Flash as a mobile platform, but if Adobe keeps acting like there isn’t an 800 pound gorilla in the room, developers might start abandoning Flash all together.

Of course, if RIM and Adobe are able to make their new QNX OS and Flash work fast and zippy together, that could be the time where Adobe can start shaking the “poor performance” monkey off it’s back. If they don’t pull it off, I hope RIM has a native SDK in the works.

I am currently working on a tower defense game and needed the turrets for my towers to rotate around the center. There are many sites such as Ryan Bosingers that correctly explain you need to use a matrix and transform your object so that the point you want to rotate around is at 0, 0.

private function rotateAroundCenter (ob:*, angleDegrees:Number, ptRotationPoint:Point) {
      var m:Matrix=ob.transform.matrix;
      m.tx -= ptRotationPoint.x;
      m.ty -= ptRotationPoint.y;
      m.rotate (angleDegrees*(Math.PI/180));
      m.tx += ptRotationPoint.x;
      m.ty += ptRotationPoint.y;
      ob.transform.matrix=m;
 }

The problem with solutions such as the above is that over time your objects can start to drift. This is caused because once you rotate your object, you are altering it’s width and height. If you rotate a square 45 degrees, it is a diamond and its width is greater. In the function above you transform an objects back X pixels, rotate it a bit then transform it back the same X pixels, ignoring the fact that the rotation changed the width and height slightly. This adds up over time, which is why you want to basically reset your matrix with the identify() method:

private function rotateAroundCenter (ob:*, angleDegrees:Number, ptRotationPoint:Point) {
      var m:Matrix=ob.transform.matrix;
      m.identity()
      m.tx -= ptRotationPoint.x;
      m.ty -= ptRotationPoint.y;
      m.rotate (angleDegrees*(Math.PI/180));
      m.tx += ptRotationPoint.x;
      m.ty += ptRotationPoint.y;
      ob.transform.matrix=m;
 }

After a few days of Nexus One ownership I began looking for games, preparing to be hypnotized by games as amazing as the Nexus One itself. After my first search, the list of games I found was the following: Robo Defense Lite (an ok tower defense game), Labyrinth Lite, Poke A Mole, Pinball and BreakTheBlocks Lite. The list of games after the top five were similar and included many more brick breaker, whack-a-mole, snake and pong games.

Underwhelmed hardly describes how I felt.

Being a computer programmer with notable skillz, I thought “I will make an amazing 3d game on Android and show these other Android developers how its done!”. After a weekend of tinkering, researching and compiling code, I can with 100% certainty say the reason why there are so few good games for Android is because it is nearly impossible to program good games without losing your sanity. I felt like the Charles Bukowski of computer programming by the time I was done.

While Iphone, webOS and windows mobile all have openGL ES 2.0 available, Android is stuck with openGL ES 1.0. The recommended way to write a string onto a 3d object is to make the text you want to draw a texture. So “game over” could be one texture and “press start to continue” would be another. But to display something that changes, like your score, onto the side of a rotating cube you need to write your own text renderer (ugh).

Android exposes OpenGL ES 2.0 which makes drawing text easier, but you need the NDK (Native Development Kit) to do that. Working with the NDK reminded me of working with Symbian v3 five years ago; lots of config files and directory structuring, like it was designed by engineers who spend far too much time in a terminal and think GUI’s are “nice to have”. Because I was running Windows, I needed to install Cygwin to build the native libraries.

After an hour or so setting up the NDK and prepping and catching up on this Java JNI business, I was ready to run the openGL ES 2.0 demo that came with the NDK on the emulator. But for some reason, I kept getting an error that simply said “The application xyz has stopped unexpectedly. Please try again”. After the relatively tedious process of setting up the NDK and running the sample app and getting vague errors, I retraced my steps. I thought I screwed up my NDK during install or I somehow screwed up the sample’s build process. I spent hours trying to resolve this only to find on a forum that the emulator doesn’t do openGL ES 2.0. I had to test the app on my Nexus. No debugging and a longer than necessary process getting my .apk onto my phone (not to mention the number of times I would crash the phone testing my .apk).

That was bad enough, but the kicker was that after hours of hair pulling frustration, the sample app only showed a static 2d green triangle and a background that went from black to white. A 2d sample to demonstrate openGL ES 2.0, the defacto mobile 3d library. It would be nice to have a few Nehe demos included instead (though props to INsanityDesign for putting some together for openGL ES 1.0)

Am I going to be developing an amazing 3d game that is going to make people feel like they were punched in the face because it’s so amazing? Not on Android anytime soon.

To demonstrate my point I’ve created a wee demo. It’s a binary tree that uses recursion to draw itself. I’ve also added some code so that it can animate, but that’s more for fun rather than demonstration.

If you run the demonstration, you’ll find a very noticable delay when drawing more than 5 levels of recursion, or 126 branches. You’ll also notice that rendering takes an exponential amount of time longer compared to the next lowest number of recursions.

We aren’t splitting the atom here, we are merely drawing lines and my interpretation is that though Actionscript is great for more simple applications or a gui on a database, when it comes to serious processing power you are better off with different platforms.

For those who would argue that Actionscript is fine and I’m simply a crappy programmer (which I wouldn’t argue too much), you can optimize the code and prove me wrong here (CS4 fla here).

This is why my idea of an RTS in Flash is dead. Flash can’t handle it. Daphne is dead

BUT – Alchemy looks promising… speed of c/c++ in your browser, every browser, on every platform??? Fuck ya, that is an awesome idea (why every program for the OS then?)

Thought it is possible for players to play Daphne in a regular browser window surrounded by HTML, it loses a lot of appeal, especially as your mouse must always be over the Flash canvas in order to register certain fundamentally important (and basic) game features, such as the ability to scroll the game map when your mouse is at the edge of the canvas. It is too easy to move your mouse beyond the Flash canvas, especially when your base is being over run and you are frantically scrolling the map to look for defense or an exit. This significantly deteriorates game play.

And besides that, who wouldn’t want to play games in full screen vs a small canvas in a browser?

A limited solution is to have your Flash canvas take up 100% of the width and height of the browser page and rely on the browsers build in full screen functionality (usually activated by the F11 key). This is limited because different browsers have different notions of ‘full screen’. Firefox for example expands to full screen, but the address bar is still visible on top (though there are plug-ins that remedy this). Opera mean while implements true full screen right out of the box.

This is a limited solution for these reasons, and because the end user may need to install a new browser to play Daphne in full screen. The whole idea of using Flash as my development platform is so Daphne can be played in any environment and behave the same with no additional downloads or without troubling the end user to have to manually install 3rd party products.

Nevertheless, this proves my point that Adobe is out to lunch when it comes to the thought process behind their idea that keyboard input whilst in full screen is a security liability. It can be done by circumventing Flash and javascript entirely and just relying on the browser.

Often, at work I can’t wait to get home, I don’t think about what I will do at home and inevitably, when I get home, I spend several minutes frozen wondering what I’m going to do with my new found, temporary, precious freedom.

As I am not big on TV, I often find it difficult to wisely spend my precious free time. I am very conscious, almost obsessed, with the thought of me of the future looking back on my earlier years and asking my future self “Why was I such a useless git? What the hell did I do with my time?”.

It is for this reason that I often am programming video games in my free time. I know it is debatable whether or not mucking about with Flash and all its quirks is really a better use of my time than doing nothing, but different strokes for different folks…

The reason I like programming video games is that games are always unique. There is no standard list of GUI components you constantly use, there usually isn’t any database malarky to deal with. The GUI should be custom and unique and how the components of your game interact with each other and the user is totally up to you and what you think is awesome. I find that using standard components over and over again gets a bit boring. Finding slick new ways to access data is also quite dry. There are billions of frameworks that help make developing such classic database apps (enterprise apps?) super easy to the point that it’s no long fun to program.

Hence, I like my game programming.

The first step to creating any application of any significant size is finding a name by which to reference it. As I suck at finding cool names for things, I follow a Greek Nymph naming convention. So far Echo and Calypso have been used, so I randomly decided to choose Daphne, famed for her decision to escape Apollo’s gino-like obsession by transforming herself into a Bay Tree.

I will make no pretenses, Daphne is based upon Blizzards original Starcraft as much as possible. This is partly due to my pathetic lack of creativity, but it is also due to the fact that Starcraft is one of the best games ever made, definitely the best RTS. It is primarily for this reason that Daphne is a sort of homage to what I consider to be the best game developers on the planet right now (seriously, who makes better story lines than Blizzard? and with the glaring exception of Warcraft 3, all their games must of been at least partially developed by some sort of higher being).

So, I have started working on Daphne, So far I have the tile map stuff working fine and a lot of the multi-player communication stuff is sorted. I would like to post the game in updated carnations as I develop it, but right now, it’s so god damn ugly and lame that I’m going to have to wait until it is at least some what presentable to people with a vivid imagination.