Indie Games for Profit or Fun

February 22nd, 2014

Recently I read an interesting article about optimizing app revenue by applying…questionable business methods. My initial thought, as a developer primarily focused on making fun games, was to scoff and huff and frown at the dubious ethics on display. As can be seen in, for example, a Gamezebo comment on the article I was not alone in having that reaction. But after some careful consideration I’m not so sure that I agree with the Gamezebo critique after all.

The article reads like a common get-rich-quick scheme, listing a number of steps and a simple procedure to follow in order to get app revenue:

  1. Buy Low, Re-Skin, Repeat. Only Make Games
  2. Monetizing in 33 Days
  3. Choosing Your Theme
  4. Publishing
  5. Repeat

The game developer in me thinks that this sounds awful. It removes the creative aspects of game design, and only focuses on maximizing profit.

But what’s the problem with that? Really?

A very simple way to measure customer satisfaction is to observe how many people download/play/buy your apps. If enough people actually download and play these re-skinned games to give a substantial ad revenue, isn’t that a clear indication that you’re actually making a product that fills a gap in the market and fulfills needs? So what if it’s not the height of creativity and design?

Most successful game development teams have a combination of game production and business acumen. The game producing side are the ones focused on making the best game possible; to satisfy the end user optimally. The business side, on the other hand, is focused on maximizing the revenue. The normal situation for a small indie developer is to focus on the game production side, and try to get a publisher to focus on the business aspects.

I think that most indie developers’ knee-jerk contempt of re-skins and soul-less games stems from their lack of interest in the business side of game development. I don’t approve of the original article’s message, but I don’t approve of dismissive “better than thou” developers either. Designing a game for end user satisfaction is important, yes, but profit is also important. Without profit there is no way to keep a business running. If an indie developer has any plans for going full time, the business side of things must be observed. In my view, people often forget the fact that art has always needed a patron of some sort. Mozart didn’t write his operas with only thoughts of musical purity. Michelangelo didn’t paint for his own sake, making purely¬†aesthetical decisions. These days the free market is an artist’s patron instead of kings and nobles – but the concept still holds true.

Personally, I’m fortunate in having a day job I’m very happy with so I don’t have to focus on maximizing my profits when making games. But I respect people who do. Just as I respect people who create wonderful game designs. Both skill sets are necessary to become truly successful.

Note: there are many examples of accidentally successful game developers. But for every Flappy Bird story where a developer with no business sense has become successful there are thousands of garage developers who can’t understand why their awesome game isn’t successful. Exceptions exist to every rule, and bringing up a few odd cases isn’t enough to invalidate a general statement.

Indie Game Development – DIY or Middleware

January 22nd, 2014

When it comes to indie games development and the question of whether or not to write your own frameworks/tools there seem to be two major schools of thought:

  1. Use as many tools and middleware components as possible! You don’t want to reinvent the wheel, and even if it costs $300 to buy a framework you’re essentially saving money. Saving money? Yes! Your time is valuable, and you’ll spend more than $300 working on a similar framework of your own, if you count your hourly worth.
  2. Don’t spend $300 on a framework if you can write it yourself! It’s very hard to earn money in game development, and that $300 is another $300 that you have to earn by selling games in order to make the whole venture a successful one. Remember: you have no guarantees that your game will even sell a single copy, so you might end up in the red.

Despite many indie evangelists’ claims, there are pros and cons to both views.

If you ever want to work professionally with game development it’s a good practice to start thinking of option 1. This gives you a quicker time to market, and it teaches you how to interface with other products – something that’s essential for professional development. It also gives an insight into budgeting and planning the development phase, as well as the real need to get some revenue from the game in order to recoup your investments.

However, sometimes option 2 is preferable despite all of these good arguments.


Here are some reasons for actually doing it yourself instead of investing in tools or frameworks:

  1. Experience – you learn how to build the required framework/tool and that will give you valuable experience for the future
  2. Bad fit – sometimes the framework you’re trying to use simply wasn’t designed for your needs
  3. Strapped for cash – you may simply not have the $300 to shell out, or don’t want to
  4. Fun – your goal with making the game might not simply be to get a finished product; you enjoy the trip as well

Personally, I have a job that I enjoy, and I have no desires to leave it – even if I would strike gold with a KarjaSoft game some day. I like running my little game business as a proper company, but it’s an addition to my day job – not a potential replacement. For me, the arguments above that hold true are mostly #1, #3 and #4. When it comes to #3 it’s a case of “don’t want to;” my aim is not to make as much money as possible – so I’m not going to optimize the delivery times.

But the most important point for me is probably #4. I simply enjoy building all aspects of the game, just as I enjoy experiencing every part of game development – from the initial concept to the PR at the end.




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.

Game Engine Choices for Indie Developers 2009

December 10th, 2009

This post is going to get a bit technical, so if you’re easily bored by the gritty details of game development you might want to go somewhere else right now. Maybe to Cute Overload or something.

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:

Engine Name Language Windows Mac Web iPhone Android Xbox 360 Linux
Android SDK Java (X) (X) (X) X (X)
BlitzMax Misc X X X
ClanLib C++ X X X
Cocos 2D Obj-C X
Flixel Flash (X) (X) X
Game Maker Misc X
HaXe Misc (X) (X) X (X)
Haaf’s Game Engine C++ X
LWJGL Java X X (X) X
PopCap Framework C++ X
PTK Engine C++ X X
PushButton Engine Flash (X) (X) X
Pygame Python X X X
Simple DirectMedia Layer C++ X X X X
Silverlight Misc X (X) (X) (X)
Slick Java X X (X) (X) X
Torque 2D C++ X X (X) X
Unity C#/JS X X (X) X
XNA Game Studio C# X X

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…