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.

Designing for Both Mobile and Desktop

February 13th, 2014

The holy grail for a small indie developer is to be able to deploy your game to multiple platforms from a single codebase. Part of this is a question of finding the right framework/technology/platform to develop your game with. There are many available technologies for this – Monkey X (that I’m using for my latest game, the superhero puzzle/RPG Spandex Force: Champion Rising), Haxe, Corona SDK, etc etc. One of these days I’ll summarize the currently available options and weigh the pros and cons of each, but today I intend to focus on another aspect of multi-platform deployment: design.

A standard comment one often hears is that one has to focus. Don’t try to deploy the same game to both web, mobile and desktop; the player behavior is too different, the markets are too separated, the expectations are too varied. This seems to be common wisdom and a general rule to follow.

So, of course I intend to try to deploy my latest game across multiple different platforms. To begin with I’ll focus on Android and Windows, with Mac and iOS coming afterwards. That’s not a marketing or business decision – I simply use Windows and Android privately, so it’s convenient for me.

Here are some details about the different targets:


  • Target resolution: 800×480 or 480×800
  • Allow for screen rotation
  • Small physical screen requires big icons and buttons
  • Players will mostly play in short bursts
  • In app purchases are simple to implement
  • Limited CPU and graphics capabilities
  • Touch controls


  • Target resolution: 1000×600 and 800×600 (widescreen and normal resolution)
  • Full screen and windowed mode to account for various screen sizes and preferences
  • Players often play in longer sessions
  • In app purchases is complicated to implement
  • Unlimited CPU and graphics capabilities
  • Keyboard, mouse, joypad sometimes

Wow. Look at all those differences! How could one possibly cover all of these with one single game design and code base? All of these items can be summarized into these points:

  • Different memory/CPU/graphics capabilities
  • Different types of input
  • Different player behavior
  • No consistent method of payment
  • Multiple resolutions and ratios

Let’s have a look at each item!

Different memory/CPU/graphics capabilities

A player on a mobile device is used to limited resources. A game may not use the latest shader technology, or may not be a full-fledged 3D action-fest. PC gamers, on the other hand, are used to pushing the limits when it comes to AI, graphics, sound, and all other technical aspects of a game.

My approach to this is to have a little extra visual polish for the PC version, but go for the lowest common denominator when it comes to the overall game design. I.e., start with the mobile version and add polish to the existing low-resource designed version. This works for me since all my games are 2D puzzle/adventure/RPG games, and they don’t really require too many bells and whistles. This would not be a good choice for a bigger game, though – just look at how well games are received if they are designed for a low end machine and quickly ported to PC. (Hint: not very well at all.)

Different types of input

See above. The least common denominator is to have a set of coordinates and one-click action, so that’s what I require in my games. I do assume that the player has some way to enter a name, as well – but other than that there is no need for a keyboard at all.

In fact, I always make sure to supply a default name so that the player can simply click “OK” when creating a character. This is to never require the player to perform a cumbersome action like enter a name on a touch keyboard.

Different player behavior

This one is slightly tricky. A mobile game can be played for just a couple of minutes at a time, while a PC gamer can sit for hours on end. In order to attempt to appeal to both I make the following design choices:

  • Continuous rapid saving, to account for people just closing down the app
  • Never let a mini game last for more than a couple of minutes. Each individual puzzle or dialogue must be short, even if there are many of them
  • Tell a continuing story to allow for longer sessions, but have obvious breaking points every 15 minutes or so
  • When resuming a game, always show a summary of the currently active quest

This is not optimal design from either the mobile or PC perspective – but it will mean that the game can be enjoyed both in short bursts and for several hours.

No consistent method of payment

Common wisdom today is that in-app purchases is the way to go for mobile. Small microtransactions for various items in the game. That is not the common way to earn money in a PC game, however.

As far as I can tell there is no golden rule for how to handle this dilemma, so I have tried to come to a compromise: the PC version will be distributed in a demo/real version, and the mobile will be distributed as a free demo game where you can unlock the full game with a single IAP. Let’s see if this experiment works out.

Multiple resolutions and ratios

All of the other problems seem pretty trivial in comparison with this!

One obvious way to handle this is to have one set of assets for each target resolution. That gives the optimal player experience, but also involves most work for the developer. All assets need to be customized, the build procedure for the game needs to account for multiple asset locations, and – most importantly – every change you do to one asset will need to be performed on each other platform.

That’s simply too much work for a one-guy team like me. So I decided early on to reuse as many assets as possible between platforms. Later, I decided to try to reuse all assets for all platforms.

“That’s insane!” I hear you cry. “It’ll never work!”

Well, I think it’s working pretty well so far:

  • All GUI elements have the same resolutions on all platforms. This means that a popup will look big on a mobile phone, but slightly smaller on a PC. I can live with that.
  • I’m using a fluid layout system where GUI items located in the top, bottom, left, right or center. Rotating the device calls a specific OnRotate() method present on all game screens, that modifies the positions of GUI elements.
  • The maximum width of any single GUI item (such as a popup) will never exceed 480 pixels, to account for a mobile phone in portrait mode.
  • All backgrounds are centered, and scaled to cover the current device height. This means that you only see the middle of the image in mobile portrait mode, and that the 1000×600 PC version is scaled up from 800×480. But the quality is actually quite acceptable despite the scaling.
  • One exception is the game map. This one is never scaled, but different device resolutions means that a differently big portion of the map is shown, and the player can scroll around to see the rest.

All in all, it took some effort to make this work. And sometimes there could have been a better result if I had gone for a single specified resolution, such as in this power up screen:

I had to fit the power preview somewhere, and the best choice ended up being showing it in a separate container to the right of the main dialog. In portrait mode the preview window is simply placed above the main dialog instead. It’s not optimal, but it works!

All in all, I see no reason why the game wouldn’t work pretty well across all platforms. The release date will probably be April 11, so I’d better get off my rear end and get everything done soon so I can see what the audience thinks!

Designing a Game: Spandex Force Analysis

January 17th, 2008

Game design is a strange beast. Yesterday I made build v0.4 of Spandex Force, my new puzzle/RPG/adventure game; it’s coming along very nicely, and with this release all main functionality is present. But after I’d finished the build I had a look at my notes from half a year ago, and early screenshots. The game is very much the same in spirit, but many design choices differ between my original drafts and the soon-to-be-finished product.

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!