“But Karja, haven’t you heard? iPhone/XBox Live 360/Android/etc etc is the new indie platform of choice! This guy I read about made six billion dollars on his game there!”

I have a number of reasons why that is utter bull excrement:

• iPhone is flooded with games. Literally flooded, with thousands and thousands of games that make it hard to gain visibility. Also, iPhone relies on Apple’s SDK, objective-C (to some extent at the very least), touch screen, low-end hardware, etc etc – and all of these aspects have to be hand-crafted for the iPhone release without being reusable on other platforms.
• XBox 360 is good if you only intend to target Windows and XB360. But that would be incredibly stupid for me, since my target audience isn’t the XBox lads.
• Android is interesting. It would be neat to get in quickly just in case the market suddenly explodes á la iPhone. But, and this is a big but, Android requires Java which is utterly incompatible with web deployment (Flash is the only viable option there).

After some consideration, I found that my options are as follows:

• Java – Windows and Mac deployment is possible, and I can deploy on Android as well, eventually. I also looked at Java-to-Actionscript converters, but…that feels desperate and unreliable. So, web deployment is a no-go for this one.
• BlitzMax – What, BlitzMax? That only supports Win/Mac! Yes, but I seriously considered trying to write a BMax->Actionscript converter since I already have a lot of BMax code and an abstraction layer API in place. (This means that I would have to write the APIs for drawing/sound in Actionscript from scratch, but convert the game logic at least.)
• C++ – Screw web deployment, and go for a full-fledged C++ engine! That would be the most fun to code in. But… No. 2010 is coming up and the web is the new black.
• HaXe – This would allow web deployment, and there’s a neat HaXe->C++ converter that can be used along with NME/NEASH, an SDL version of the flash API. Essentially, what this promises is that the same code could be used to make a Flash version and a compiled standalone downloadable (…as well as an iPhone version!). Alas, things aren’t as good as they sound. I did some quick tests and NME/NEASH lacks a lot of bitmap manipulation support. For example, BitmapData.colorTransform() support is missing – and this means that the alpha channel of bitmaps cannot be modified in the downloadable version. Things like this make HaXe seem way too shaky at the moment.
• PushButton Engine – If I’m considering pure Flash (well, Actionscript) engines, this is a strong candidate. It’s a well-designed library intended to be used for larger game projects. However…. After looking at the code a bit, I fail to see exactly what it will bring. The rendering, file-loading and game state management seems to be the biggest things that it provides but to be honest those aren’t all that tricky to write by yourself.
• flixel – Another Actionscript/Flash engine. This one seems very attractive at first, but the main problem with flixel is that it makes assumptions. “You only want to make a platformer style game, right? You’ll want to use pixelated effects, right? You want to embed all files since you’re deploy for the web only, right?” And so on.
• Actionscript/Flex – Finally, the last option is to go for pure Actionscript with Flex. No no no, I’m not trying to reinvent the wheel and have a NIH (Not Invented Here) mentality. But to be frank, writing the main framework that flixel or PBE would provide is…not that much work. Also, I have specific needs: for example, I need to target different platforms and handle files differently on the different platforms (embedded/external).

Nothing is decided at all, but I’m currently leaning towards using PBE, flixel or pure AS/Flex. My main beef with that is whether or not it’s fast enough to look good on the downloadable versions. HaXe seemed like an interesting choice for a long while, and I’m sure that it will be in the future, but I simply found too many flaws in it to provide any actual benefit at the moment. I’m (probably) going for a double-buffer approach with quite a few alpha effects on bitmaps (not in the least for the particles), so the current unstable alpha support in the SDL parts makes HaXe’s NME/NEASH solution for downloadables and iPhone pretty dubious.

In the end maybe I oughtn’t spend so much time investigating this, and just choose something and start developing instead. I guess all engines and choices have their flaws, so nothing’s going to be perfect.

My latest game, Wildhollow, is released and I have some great ideas for my next game. Let’s just say that it might include puzzles, RPG elements and some online functionality. Oh, and superheroes or monsters too. Not really sure which yet. Either way, in order to get the game done I need to decide what to implement it in. Sheeplings, Spandex Force and Wildhollow were all developed in BlitzMax, an object oriented BASIC language that’s extremely easy to develop cross-platform games in.

As long as your cross-platform needs are Windows, Mac or Linux, that is.

As an indie casual games developer I find myself wanting to maximize my potential market (of course), and that means maximizing the number of platforms I can distribute games too. To make things easier for me I’ve constructed this table of feasible game engines/libraries as things are now in 2009:

Note that I said feasible engines and libraries. This is not close to a complete list, but they are the ones I’m considering. I can list some criteria:

• There must be decent performance, which means preferably no software rendering
• All Windows only, Xbox only, etc libraries are of no use to me. I’ve listed a few anyway just for consideration
• I want to be able to create mostly 2D games in an efficient manner. 3D engines are often bloated and unusable. Unity may be free but it’s of no use to me, for example
• Finally, I have a prioritized order of platform preference. You may note that the columns in the table are ordered rather strangely. That’s because I’m going from most important to least important platform

A quick glance at the table shows that there’s no single engine or library that fulfills all my needs. An X demarks that the platform is supported, and an (X) means that limited support is possible. That could mean that it’s possible but requires a lot of messing around (e.g. HaXe for iPhone), or that the solution isn’t practical (e.g. Java web applets aren’t very useful), or that it requires unreasonable things (e.g. Unity on the web requires a specific plugin).

Most engines and libraries support Windows and Mac, so that’s not really a problem. The real problem comes with my third platform of choice: the web. And by the web I mean that it should run seamlessly for most users. Which means that Java is doubtful (too…clunky, and portals won’t accept it), and that leaves only Flash. Which, of course, is mostly incompatible with “normal” programming languages and engines.

This is not an easy decision…

One important thing that differs is the scope. In the finished design, the player’s hero has just gotten a job as superhero of Vigilance Valley – a city troubled by minor crime and wacky super villains. In the original design I had planned a more involved process where the hero would start out as “city hero” and eventually graduate to “world hero.” This shift would be very visible: the city screen would feature minor villains and citizens in need, and the world globe would feature global threats and major super villains. This would have been interesting…but totally unnecessary. The game’s budget would’ve increased by a magnitude (well, maybe not; but it would have doubled at least) and the game would have taken months more to develop. I doubt that the benefits would have outweighed those consequences.

And speaking of scope, another thing that I was planning from the beginning was a more involved story inspired by Bildungromans. It would tell the story of how the hero grows from fledgling whippersnapper to responsible self-sacrificing hero. I had planned a structure where the first three episodes would be stand-alone, but then a subtle plot involving a villain trying to frame the hero would emerge. The hero would try to find out information through the following episodes, and eventually meet the ultimate villain in the next-to-last episode. Inspired by Watchmen, after our hero had beaten the villain he would explain to the hero that it’s too late anyway – the Evil Plan(TM) was already set into motion a long time ago. Our hero would race to stop the Evil Destructive Device(TM), only to discover that it’s too late to stop it. Panic! What to do! He would sacrifice himself to protect the city…and everything would go black.

…And had I had my own way, that would have been the end of the game. But, of course, I had to think of a happy ending. So I pondered a final episode after this, where the hero wakes up weak and sore, and supervillains whom he have already beaten have teamed up to take revenge on him in his weakened state. Almost like the fight-all-the-bosses-before-the-final-boss in the Mega Man games. It all would end in a heartwarming scene where the people of the city aid the hero and he defeats everyone. Yay!

But that’s not how things turned out. Instead, I chose a format where every episode is stand-alone, and there’s no on-going storyline in the game. “How dull,” you exclaim now, “that totally sucks!” From an artistic point of view: yes, this is the worse choice. But I think it will work better from a gaming point of view! The game focuses on easily accessible minigames, humour, and instant-get-in-the-game-ness. That approach conflicts with a deeper storyline; if nothing else, it becomes difficult to jump into the game if you’ve had a break for a few weeks. Instead I chose episodes that you can finish in about an hour (depending on the episode) and clearly defined sub-tasks within each episode. Each subtask only takes 15 minutes (or something like that), so you get constant updates on the episode’s plot.

Old concept showing the early city screen and some dialogue.

But there are other design issues on a lower level that differs between then and now. For one thing, at first I intended to make Spandex Force into a game that would have been much more of a Puzzle Quest clone. The current implementation has many strictly different puzzle mechanics: Catch ‘n Match, Slide ‘n Match, Shoot ‘n Match, Click ‘n Drag, mini-minigames…and last but not least, the two types of puzzle battles. But in my original notes I only planned on doing the puzzle battles – nothing else! I had thought of a system with slightly different game modes: standard, simultaneous, and so on, and the type of villain you fought against would decide which game mode it would be. Supervillains would have a very special mode; the villains would have the simultaneous mode; and the henchmen would have classic modes. But after some prototyping I quickly abandoned this game design. It wouldn’t have given enough variation, and the simultaneous mode was…too chaotic. Play Spandex Force and, when you come to a battle, imagine that you both perform your actions simultaneously instead of turn-based. Sure, it opens up to great things like stealing your opponent’s cascading matches…but it would be too action-oriented, and impossible to have a clear overview.

Old prototype of the puzzle battle game. Can you see which game I received inspiration from?

If things go well with the first game I just might implement a better simultaneous version in Spandex Force 2, though. And speaking of Spandex Force 2, here’s another thing I had to consider:

• If I made the game with a very large scope I would put all my eggs into one basket. If the game fails I will have lost a lot.
• However, if I choose restraint and lessen the scope, I can see how the game fares. If it does awfully and it’s because of the game design or the theme…then it’s not worth making a sequel. But if it does well I’ll gain a lot of feedback that I can use to implement an even better sequel.
• This sequel can then use many of the discarded options from the original design. For example, it can revolve around a global hero instead of a city-based one, and experiment with innovations to the minigames.
• Also, if the first game does well enough, I can implement something that I didn’t dare in the first game… Multiplayer! Puzzle battles online, where you can defeat other heroes and villains! I think this would be absolutely brilliant but I don’t have the resources to pull it off unless Spandex Force does reasonably well.

So, here’s to hoping that I can make Spandex Force 2 soon!