Which language to learn for web game dev?

There are a number of different options these days when making casual games. Here is my take on the order of usefulness today:

1. Flash/Flex
2. HTML5
3. Java
4. Unity
5. Silverlight
   
6. etc..

Depending on your goals, any one of the above could be put to use. So why did I put in in that order?

The majority of casual games right now are being developed in Flash. If you look at sites like Games.com, Mochi, Mindjolt, and so on...you'll see that 90% (or more) of the content is Flash. Does this mean that Flash is better than the others? Nope. It just means that it's the most common use-case for developing casual games right now.

The question really is how long that's going to be. HTML5 is hot on Flash's heels, and it's really shaping up to be a powerful ally to casual game developers. I just don't think it's ready to usurp Flash's position just yet. The progress is substantial, though, so give it a year or two and it'll be a formidable contender. Adobe knows this too. They have been working on Flash->HTML5 conversion systems, and I wouldn't be surprised if they created a Flash-like IDE for the HTML5 (focusing primarily on the canvas support). As John Nack put it in his article regarding the conversion tool, "Adobe lives or dies by its ability to help customers solve real problems." This does seem the case and I would argue that Adobe's doing a pretty decent job of it. If they did create a full HTML5-IDE (ala Flash), I'd buy it.

Java is a great language for developing games. It's been around forever and has had a lot of push. I'm not a Java game developer, but I've tinkered lightly in the past and I had to do a few projects in college (non-game) using the language. The power afforded by the Java gives the developer a lot of options. The issue I see is that when Oracle took over the company they seemed to have put games off to the side. This doesn't mean that Java no longer offers gaming as a possibility. Far from it. It just means that the company-backing to grow that area of the language is no longer in the forefront...unless something has changed that I'm unaware of.

Unity is a nifty language with a robust graphics engine. It's powerful, 3D, supports builds on various platforms and distribution channels, etc. I've dabbled only lightly in it and I can say it is a very nifty world. Issue: the documentation is less than awesome. There are a lot of things that you just have to figure out. Now, if you're the tinkering type, this may be cool to you; if you're part of a team that is taking Unity and extending it to fit your particular game, then it's a very smart path to go. But if you're a hobbyist or a developer working on time-constrained projects, the learning curve may just be too great until they get their docs in order.

Silverlight is interesting, but I wonder how far it's going to go. With Microsoft behind it, one would imagine it has decent longevity. I wonder why they'd bother pushing money in its direction when HTML5 seems to be heading swiftly toward front-runner position. Personally, I've not developed in Silverlight, so I can't talk to its particular strengths. Still, as time permits, I will create a least a little something so I can see how it all comes together. I just don't see it as an area to spend too much of my time since Flash already has the lead and since I'm guess that HTML5 will soon take the #1 spot.

There are others out there that are available to learn as well, but I think the ones listed are the primary contenders at the moment. Of course I may have completely spaced on one of the other big players. If so, smack me. I'm not proud. :)

The bottom line is that any of the above languages (and more) have their advantages and disadvantages, but if you're looking to pick one or two to learn at this point, I feel that picking the more relevant one makes the most sense. This isn't a case of me saying (or thinking) that Flash/ActionScript is the best and everything else is crap. I don't believe that at all. Actually, there are parts of AS3 that drive me nuts. The point is that I see little value in spending my time deeply learning Unity and Silverlight for web-game development at this time, unless, again, there is a particular need (or job-opening) that requires that expertise.

Playing devil's advocate: There are a load of Flash and Java devs out there already. Companies that are invested in Silverlight, WildTangent, ActiveX, Unity, Torque, etc. are on the lookout for developers that know those technologies.

It's a catch-22. You either focus your time on being a know-it-all about one or two technologies, or you play the jack-of-all-trades card and just be decent in various technologies. I've always gone the second route. The way I see it is that I'm a developer regardless of the language I use. If I am tasked with developing an application in Java, I'll focus my efforts on learning it for that purpose. Same with Silverlight, etc. So I purposefully do not try to be an expert at any single language. To do so, for me, is limiting. ...but that's really a different discussion.

Mochi ZIP integration issue resolved

It took a couple of weeks working back and forth with the tech folks at Mochi, but we finally uncovered an interesting ooopsie.

There are three ways (that I'm aware of) to build a game for Mochi distribution:

1 - Use a single SWF file that contains all your components, images, sounds, etc.
....This one works pretty well for the most part. Very few moving parts so not a lot to worry about.

2 - Use a single SWF that loads external resources from a site you host.
....Works well as long as you have a reliable server with the proper crossdomain.xml file setup and all that, but is subject to dropouts of your assets and potentially slower loading times. If you have a decent CDN it's better.

3 - Use a .ZIP file that contains your SWF plus all the externally loaded assets.
....Neat idea and has its merits, but it's not idea. Firstly, you can't use sub-directories (as of this writing anyway). Not a huge deal, but I like to try and keep my assets categorized so it bugs me a little bit. Secondly, you have to watch how you load these assets because Mochi's launchpad pages (the pages where they launch the games on) fail on external loads of the .ZIP'd content in some instances. Third, even if you use try{}...catch{} blocks on items that aren't available, using the catch to resort to different methodology for getting your assets/data, the game will fail to launch.

The point of this post is to discuss what I did to get the .ZIP file local loading issue resolved in the hopes that it'll help someone else.

The key component came from the Mochi techs that said I needed to have any loaders based off of the loaderURL. This snags the URL of the initiating SWF file, thus providing a fully qualified URL instead of relative. Here is a bit of sample code for what I mean:

var loader:Loader;
var resourceURL:String;
var request:URLRequest;

loader = new Loader();
resourceURL = loader.contentLoaderInfo.loaderURL;
resourceURL = resourceURL.substring(0,resourceURL.lastIndexOf("/") + 1);

resourceURL = resourceURL + "tempflashfile.swf";
request = new URLRequest(resourceURL);
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loaderCompleteHandler, false, 0, true);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, loaderErrorHandler, false, 0, true);
loader.load(request);

The key point is to make sure that instead of having just "tempflashfile.swf" as the resource URL we end up with like "http://www.yourdomain.com/tempflashfile.swf". In the case of a Mochi distribution point, this "yourdomain" would be whatever domain the game gets loaded from, of course.

The next trick comes from making sure you either a) do this on ALL externally loaded items or b) you don't put in any try{}...catch{} blocks for stuff you know isn't going to be there. In other words, if you have code that checks for an external asset and defaults to an internal asset if the external one is not found...don't do that. Any non-found external asset seems to knock your game to a halt, even if you use the above methodology (at least it did for me!). Instead, for your Mochi build, just rely on the internal asset and avoid the external check completely.

If you're loading .XML files or somesuch, you will likely just be using the URLLoader and not the Loader. That's fine, but the URLLoader doesn't have a corresponding contentLoaderInfo.loaderURL data point, so you may scratch your head a bit. Just use a dummy Loader to get that full domain and stack it globally so you have it when building your resource URL.

private var gLoader:Loader;
private var gResourceURL:String;

gLoader = new Loader();
gResourceURL = gLoader.contentLoaderInfo.loaderURL;
gResourceURL = gResourceURL.substring(0,gResourceURL.lastIndexOf("/") + 1);

Now you can just preface any of your URL's with the gResourceLoader (gResourceLoader + "tempflashfile.swf") and you should be fine. Creating a class out of this is a snap and will save you a bit of headache and cut down on globals too.

HTML5 is nifty

I've been coding primarily in AS3 for a few years now, but I was tasked to do some research into HTML5.

While I'm still in the exploration stage, it's pretty nifty. I can see adopting this technology heavily once all browsers are on board. I'd love to be elitist about it and just say be damned to IE, but that's not my call. I know thee are workarounds for the IE shortcomings, but I kinda have to wait for actual support for the things I do.

Either way it's a very interesting technology that I'll be giving mindshare to so that I'm ready for the full shift when all browsers get with the program.

Algorithms are fun

I've been working on a persnickety (yes, I actually just used that word) little algorithmic issue for a new game I'm working on. The game is kind like Phlinx and Bubble Town, so there is a little projectile that flies up toward the board and, upon matching three or more, causes the pieces to explode and disappear.

That matching bit was fun in and of itself, but I got that one sorted out. The challenge now is the line-of-sight check for spotting where the projectile is allowed to land.

The problem is a little tougher because the board is staggered (Row 0 starts at pixel 45 and Row 1 starts at pixel 90...for example), so you can't just simply check on an array basis. You use the array, of course, but you have to kind of treat it a bit differently.

For example, consider:

[ ][ ][O][ ]
[ ][ ][X][ ]

      [P]

Since the row offsets match, we can immediately see that the projectile (P) can not get to the open position (O) because there is a piece (X) in the way.

But, if we stagger the board:

  [ ][ ][O][ ]
[ ][ ][X][ ]

      [P]

...and if we imagine an line drawn from P to O, then the piece CAN hit that spot.

But how far can it go?

  [ ][ ][ ][O]
[ ][ ][ ][O]
  [ ][ ][O][ ]
[ ][ ][X][ ]

      [P]

...looking at this board, an imagining that line draw up, the projectile can find its way all the way to the top of the board here.

Those are just a couple of the issues associated with this. Either way, it's a fun challenge (so far), but I'm certainly finding myself brooding more than coding at times. :)

Flash Debugging

So as I (and seemingly tons of other Flash devs) continue to struggle with memory and CPU issues, I searched for ways to help pinpoint issues. I found two items that I'm planning to try out today to help:

1 - De MonsterDebugger -- an AIR app that allows you to realtime debug on many fronts.

2 - EventController Lib - a library that manages events to make sure you don't end up with lingering event managers in your code.

With any luck I'll have good news on these two items soon. Either way, I'll post up how things are turning now.

**UPDATE:

Wow. The two items listed above are AWESOME. I highly recommend this to anyone serious about developing Flash apps/games. The bug I've been hunting forever has been found and (hopefully) squashed. And, yes, it was my fault.

I fell into the trap of expecting Flash's garbage collector to be more intelligent the larger system gc's because it is smaller world. Unfortunately, it's not. So, just like C's new and delete, so it goes heavily with Flash. If you want more details, check out this great article by Tom at Gabob.

It was in the comments of that article that I found the EventController Lib and from that I found the Monster Debugger.

Even though I was removing the event listeners from everything, I wasn't nulling things properly. I *thought* I was, but with the Monster Debugger I was able to see a lot more than I was getting from the Flash debugger. What I saw with Monster was how I was missing quite a few of nulls, and a couple of deletes too. Oops.

Anyway, now CPU usage is now quite nice (when the GC decides to kick off) and memory is staying low too.

I will likely integrate the EventController Lib too since it seems to be really intelligent in how it works. First, though, I want to see how things go now that I'm nulling/deleting in (again, hopefully) all the right places.

With my luck I'm probably still not 100% solved on this issue, but it's GOT to be better!

** Update Part 2:

Integrated EventController Lib. Nice. It was simple to integrate and it gives a simple interface for controlling events. Plus it can be easily set to log information over to Monster Debugger, so that's sweet.

So far I'm liking these new toys!

One year anniversary

I can't believe it, but yesterday was the one year anniversary of when I stopped drinking sodas. After downing 4-6 sodas a day (on a slow day) I decide that it was time to stop.

So, I did. And...it sucked, but I ended up dropping lots of weight and my mood evened out. It took thirty days or so before I could stand being in a room with soda and not wanting to imbibe. Even now I long for an ice-cold can of Mt. Dew.

Point is that I stuck with it for a year. I'm glad I did it and I'm not going to go back to sodas, but...but...but damn do I want that Mt. Dew.

Ice Breakers: Penguin Pirates

Finally released Penguin Pirates on games.com. It's in beta right now, so I'm sure there are still a few bugs to contend with, but it's looking pretty good.

Check it out at http://www.games.com/game/ice-breakers-penguin-pirates/