Indie Game Engine Choices 2011

February 25th, 2011

What? Is it 2011 already?! And I will be finished with Spandex Force: Superhero U soon? This means that it’s time to plan ahead for my next game project!

One of the most crucial choices right now is what game engine to use for my next game. I use the term “game engine” very loosely – I don’t care about all the added bling bling right now. In fact, I would be just fine with a low-level engine that provided graphics and audio abstraction layers. Granted, extra functionality will result in a shorter development time, but first and foremost I am going to look at what platforms are available for distribution with the different game engines. For a small developer like me it means incredibly much if I can reach an extra market with not much extra effort!

It’s worth noting that this is a non-comprehensive list of all the available game engines. These are simply the ones I think are of most interest to me as an indie developer.

Engine Name Language Windows Mac Web iPhone Android Xbox 360 Linux
Flash/haXe haXe X X X (X) (X) (X)
Flash/Actionscript Actionscript X X X (X) (X)
Unity C#/JS X X (X) X X
LWJGL Java X X (X) (X) X
Simple DirectMedia Layer C++ X X X X X
Gosu C++ X X X X
Allegro C++ X X (X) X
BlitzMax Misc X X X
ClanLib C++ X X X
Game Maker Misc X X
pygame Python X X (X) (X) X
Silverlight Misc X (X) (X) (X)
XNA Game Studio C# X X
Upcoming Engines Language Windows Mac Web iPhone Android Xbox 360 Linux
Monkey/Mojo Misc X X X X X X
ExEn C# X X X X X


So, what’s this table all about? This is a list of different game engines/SDKs/development environments that are suitable for indie games. An X marks support, while an (X) marks dubious support that may or may not work correctly/easily.

The platforms are sorted in order of priority, from left to right. Web has a very high focus, but if the benefits of the other platforms outweigh that of web based distribution, I could definitely skip it. After all, iPhone (which includes iPad) and Android might be emerging as quite valid alternatives.

Based on the platform support, each engine is listed in order of priority. Essentially, a development environment that e.g. lacks support for Mac will be at the bottom of the list, plain and simple.

A quick look would show that haXe is the way to go, but that’s not the entire truth. The language is not widely spread, and the support is quite lacking. Actionscript is what I’m using for my current game, but it’s not really a great environment to develop in. Other than those two, Unity and LWJGL have some sort of support for web based games, but I still claim that the Unity plugin and Java work pretty poorly in browsers. I’m not dismissing LWJGL completely, though – I’d love to develop in Java.

If I were to decide that web based distribution isn’t all that cool after all, I think that SDL is a clear winner. I have made a small game in it earlier and it’s decent to work with. The problem is that the Android port is of an old version, and I’m not sure how functional the iPhone port is.

Lastly, I have to make some honorary mentions regarding ExEn and Monkey. ExEn is a project to port XNA to various platforms, and it’s really very interesting. Monkey, on the other hand, is a new upcoming language + graphics framework by the developer behind BlitzMax. Not only will it support the listed platforms, but also HTML5. Quite, quite interesting!

Have I missed something?

Stop that Thief!

February 3rd, 2011

This, kids, is how you act like a complete bastard and ruin things for everyone:

Counterfeit Lugaru on Apple’s App Store

What’s going on here is that Wolfire Games released the source code to their game Lugaru as part of the second edition of the Humble Indie Bundle a little while ago. Essentially, a great deal where you get loads of good games as well as source code for a pittance. Great deal indeed for a guy calling himself iCoder (Michael Latour) – he decided to use the source code for Lugaru to release it himself on the App Store. And to make things even better, at the tenth of the price of the official Lugaru HD release.

“Naah, I can’t be arsed to make a game of my own! I’ll just grab this code…and steal these assets… There! Hah! I wonder why more game developers don’t do it like this instead!”

I’m completely flabbergasted. My flabber is all gasted. Or maybe my gast is all flabbered. From Wolfire’s blog:

iCoder was very unhelpful in response to our emails (their feedback form doesn’t seem to work), but Kotaku managed to get an interesting comment for their article, they responded “we have every legal right to market and sell the software” and, “the license we were granted allows for non-exclusive redistribution of the source code or the compiled product, modified or unmodified, for a fee or free of charge.”

So, the code was GPL’d and thus this Michael Latour thinks that the art and sound assets fall under the same license. Insane. The gall of it. Let’s see, in how many ways is this wrong?

  • It’s illegal, first of all.
  • It’s immoral and unethical, secondly. To such an enormous degree that it’s ridiculous.
  • This little stunt will cause others to think twice before releasing the source code for a game.
  • He’s releasing a game at a pitiful price, speeding on (ever so slightly) the race to the bottom with regards to game prices.
  • His little stunt requires the time and effort of the original developers. It’s not just a passive loss of revenue – it requires them to actively pursue this in order to get it removed.
  • Even though it’s blindingly obvious that the game will be pulled off the App Store, he’s still earning money from it – at the expense of the original developers. Think about that. No matter what happens, he will probably have gained something from this because it’s going to be too much work getting him to cough up the dollars he’s earned.

And I’ve probably missed a number of other points.

I’m all for open source. In some cases. But a game is heavily (I’d say to most part) dependent on assets, so the code itself serves little purpose. If you have some clever algorithms it makes sense to release the code, but I have a hard time seeing how general game code is useful for anyone. With that in mind, this little incident hasn’t exactly made me more favorable toward releasing source code for any games. The risk of people like Michael Latour confusing the source code and the assets is simply too great.

Multiple Madness and Test Driven Development

September 16th, 2010

A recent private thread on Juuso’s GameProducer forums discusses Test Driven Development and offers insights into benefits of the paradigm. I can’t argue that there are benefits, but I also don’t see the point of applying it to minor projects like casual games. In general, I’m very sceptical towards evangelic people who claim that one process/development method/paradigm is applicable to all kinds of projects. TDD is great for large systems, TDD is a fresh way of looking at design, etc etc – but it’s not relevant for KarjaSoft.

Why not? The primary reason is that my games evolve relatively organically, and the initial overall design is rarely the final one.

“Well, that’s the beauty of it all! You can apply continuous refactoring – and TDD is great for that!”

Look, I don’t just mean that the code changes. I mean that I rewrite essential basic requirements of the game all the time. Partly, this is because I’m doing this for a hobby. It’s meant to give me pleasure, and just “doing stuff” feels good. But also, it’s largely because my game designs change along with the art I have. I’m very much doing art-driven game design, and the art I have depends on what artists I find and what I can do myself. …Nothing of which is set in stone at the beginning.

“Why don’t you just gather all the art you need and then do the design afterwards?”

Because that’d take longer, and because there’s a constant give-and-take between the art and the design. If I get a decent enough price for the backgrounds I can hire a GUI artist, and then I need to design the power and item stores to utilize the GUI art. But wait, I can’t afford a GUI artist! That means that I have to design the stores in such a way that I can create the art for them myself. All of this moves to and fro for many months.

But enough of that. Yesterday I encountered a situation where I really could have used a TDD approach. I have multiples among my tokens on the game board, and since the beginning I’ve had some issues with deciding if there are three or more matches when a multiple’s involved.

I decided to just let it go and finish all the other stuff first, but now the time has come to fix this bug. And for some reason the logic in my code isn’t working:

if ( found > 0 && index == multiple &&
tiles[i][j].active && tiles[i][j].state == "Active"
&& (tiles[i][j].index < 3 || tiles[i][j].index == multiple) )

It never correctly identifies a line of three or more, that begins with a multiple!

No big deal. I’ll just have a closer look at it, rewrite the function to become cleaner and easier to read, and then fix the problem. If I had used TDD the code would already have been prepared for this, and I could simply have added another test case. Now I have to spend an hour (-ish) to make this work properly instead. TDD would most definitely have helped.

…But on the other hand I just lose an hour this way, compared to the time I’d have had to spend if I went with full TDD from the beginning. I’m a firm believer that it’s way too easy to suboptimize, and that implementing a theoretically more effective method often will cause the end result to be more costly. Choose the right tool for the task; not the prettiest and sexiest tool.

A Quick Look at my Ideas File

February 2nd, 2010

I have an ever-growing file with ideas for various games and applications. A few years ago it contained a few gems like Grabble (Grammar Scrabble) in which you place words instead of letters and have to form grammatically correct sentences, and DoodlePad which was a text editor much like Notepad, but with the possibility to add simple illustrations by drawing with the mouse. Sometimes these ideas result in an actual product, but most of the time they never get further than concept stage…or a few lines in the ideas.txt file.

For fun I decided to check what I wrote a year or two ago. These are different game concepts that may or may not result in actual games later:

  • TV show production game. Create small game shows and try to get good network ratings.
  • Ninja school. That’s all I wrote – I guess it pretty much says it all!
  • Game continuity. A game where the player dies but continues with his offspring. Affecting the game world results in changes for the next incarnation too.
  • SimCity + Viva Pinata. Prepare environment for citizens to join. E.g. a doctor requires sick people and wealth, and provides health. The player never has active control over the citizens.
  • Woggle or Worggle. Word-Boggle. Same idea as Grabble, but make a simple Boggle game where you have to string up sentences from words.
  • “Modern fantasy.” A fantasy world that was common fantasy ~1000 years ago but have evolved. How would elves, men and dwarves live in a more modern setting?
  • Vampire adventure game. Oh, so many snarky Twilight parodies that could be included…
  • “Closed system RPG.” Nothing is ever added to the game world: killing enemies doesn’t give experience points – it gives you the person’s life force. Money is never created, it only shifts hands. The same thing with weapons and armor. Includes autonomous heroes/villains that “level up” just like the player.

Fun fun fun! A few of these might actually end up in real projects, if I only get my game development up to speed. I wonder if I should have a look at the ideas from five years ago too, to see what else I was thinking of…

Web and Downloadable Game Engine Choices 2009

December 20th, 2009

In my last post I complained about the lack of a perfect silver bullet game engine that would fit my needs as a small indie developer starting up a new game project. My three primary target platforms are Windows, Mac and the web, in roughly that order.

“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.