A Web Designer I am Not

March 2nd, 2014

At long last I have updated the web design of all my web pages. That includes this blog, the KarjaSoft homepage, the game pages for Wildhollow and Sheeplings…and, most importantly, the Spandex Force series pages.

The word “series” is key in the sentence above. Previously I viewed the Spandex Force and Spandex Force: Superhero U as completely separate pages, for two very different games. However, given the upcoming Champion Rising I’m forced to realize that I have in fact created a series of games. As a consequence I aligned the design for all three game webpages, and added more visible links to each game. After all, if someone likes the humor in one of the games it’s highly likely that they’ll be interested in the other games too.

Which of course means that I will have to make a buy-all-three-games bundle as a promotional item, once I launch the newest game. Not doing so would be criminal neglect from my part!

Another thing worth noting is that the design is…serviceable, but not great. I’ve tried to make innovative and cool web designs in earlier years, but right now I find myself focusing on usability rather than pure looks. All sites are designed to scale up or down according to the device screen size. As I have a Galaxy S3 phone and a 1920 laptop I’ve made the pages scale decently to both of those resolutions – but with a bit of luck they will look good on all in-betweens as well. Bootstrap is really a godsend for all of these nitty gritty responsive design issues – but I wouldn’t recommend anyone to use it plain vanilla style. The only way to get a page you’re happy with is to do some manual editing of certain aspects.

For example, having a completely collapsable menu is something I just don’t like. It looks ridiculous and is much too cumbersome to use on small devices. So I’m overriding a lot of the default behaviors like that. Also, I had to dig into how the @media CSS items work. I know that all “true” web designers will scoff at simplifications like this, but I found that the only way to keep sane is to limit the responsiveness to two levels: @media (max-width: 767px), and @media (min-width: 768px). Keeping track of all other variations outside of that just becomes ridiculously complex.

Finally, something struck me that I should have seen a long long time ago. In my games I’m adamant about always giving the player feedback – scale buttons when hovering over them, or change the opacity, or do something at least. On my web pages I’ve been using non-responsive static images as links for way too long. So, in an attempt to join 2014 I’ve finally employed some simple CSS3 opacity transitions as well, to try to give a more playful experience to the visitor of my sites. We’ll see if it works out well or not.

All in all, I’m happy that I spent these long hours digging into Bootstrap and modifying all the pages. I still have some work left on the actual game as well – but this little detour was necessary!

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!

Game Design Evolution over Time in Champion Rising

February 9th, 2014

Some people make a 200 page design document for their indie games, and that becomes the major part of the design process for them. Personally, I have never seen one of my games end up becoming exactly what I envisioned when I started out making it. There are many reasons for this.

Partly it’s because I have a very light prototyping phase and instead opt for making rapid changes to the actual game. I can afford that as a single-person team – if I had more team members depending on the design I would have had to stick to the original plan, which would have led to a longer prototyping phase.

Another reason is my limited art resources. I don’t know any artists willing to have a close cooperation, so I have to outsource the artwork – and that means that I’m limited in the scope of art I can include in my games. If I realize that a minigame requires an animated piece of art or a custom background I’m often forced to skip that minigame or try to make do with efforts of my own. That’s one of my biggest disappointments with Wildhollow, for example. The game could have been greatly improved from having more art, allowing it to have more interesting minigames and breeding mechanics.

As an example of this evolutionary design process, let’s talk about my upcoming game Spandex Force: Champion Rising. The game was originally meant to be a Princess Maker-like game where you raised your superhero’s attributes and watched him grow into a good or evil character. As you can see in the screenshot below, three “resource” meters were present to the right: happiness, stamina and time.

An unhappy hero would get lower ethics, which in turn would lead him to the dark side. Ways to make the hero happy was to ensure that his stamina doesn’t run out, that he gets nice superhero toys to play with, and that he performs interesting superhero actions.

Another thing to notice in the screenshot above is the small city map. For some reason I was envisioning the game as requiring no scrolling. Everything would occur on single screens. That soon changed, as you can see below.

Here, the city is zoomed in and you can scroll around the map. In retrospect it’s easy to see that this is better – but for some reason it never struck me in the first design of the game. Another thing you can see is that there’s an active quest in the upper left. At first I didn’t want to have any quests, and instead let the player do exactly what he wanted. But that led to too much confusion and too little guidance.

The GUI elements are also overlayed instead of fixed in a panel to the right. Eventually I removed the happiness/stamina/time meters and tried to minimize the GUI as much as possible. I removed the happiness and the stamina at the same time as I made a fundamental change in the game design. For the longest time I had tried to keep the game statistics based. When you worked, you gained X amount of money depending on your current happiness and stamina, and you gained Y amount of attributes while you decreased Z amount of other attributes. This works wonderfully in Princess Maker and other similar games, but I could simply not get my game fun!

Part of the reason for the lack of fun was that there wasn’t enough positive feedback to give the player. Watching a number grow is really…not that intense. I wanted to award the player an animation for example – but I had no artwork for that. I experimented with minigames for each job, but that never felt good. In the end I decided that the game was lacking a core mechanic, so I introduced the hex-based puzzle gameplay that you can see in the current version. This gave the game a stronger focus, and increased the appeal of the game (as far as I can determine).

When it comes to locations, for a long time I wanted each location to have multiple actions available. You could feed pigeons to increase your happiness, or rest to restore stamina, or work to earn money, or talk to various people.

Above is an example of the Vegemite Park location. More actions would become unlocked as you progress, and some events would be dependent on the time of day, or the date. I still like this idea, and I think it would be a really good mechanic – but for art reasons and simplicity I decided to skip it. But not before I had gone through some design changes.

The first change was to make each location a full screen with limited options (see above). People to talk to would show up at the bottom, and available jobs/training possibilities or actions would be at the top. After some consideration I decided to skip this simplified location screen as well. It was too hard to show the player what was available in each screen on the city map. If he’s looking for a job it’s really annoying to have to dig through a lot of locations to see where that particular job was. I experimented with icons on top of the locations to show what was available, but it simply looked too cluttered. I also experimented with having one active job at a time – but that was also hard to incorporate in a way that made sense to the player. Also, all of these experiments would have required additional art work that I didn’t have.

In the end I opted for one action per location instead. This simplified the player experience and streamlined the game. There can still be multiple events at each location – but each happens in order of priority. First, any quest related actions. Second, any special events. Third, any normal actions that always occur. Each location event/action is also triggered from the game map instead of going to a separate screen now. This serves the purpose of focusing more in the city – making it the natural navigation hub it should be.

Regarding player choice, things have generally taken a turn from multiple choices to a more streamlined experience. As an example, the very first quest would originally give you three options of jobs to attend – in order to let you customize your hero completely from the start.

But as you can see in the image above, it’s just confusing to the player to have multiple options right at the beginning of the game. I still allow the player to pursue his growth as desired, but I provide one single path of progression as a suggestion to new players.

In other changes, the game was much grimmer with a lot of dark humor in the beginning. The player had to sleep on a park bench to regain stamina until he could afford a hero base. The insults between the hero and his mentor was much more acidic and less good-humored. This is visible in the title design as well – it was much darker in the first version.

Eventually I had second thoughts about the grimness and dark humor. It could still be a fun game to do, but it should be for a separate game where the player has the option to become truly evil. Who knows, maybe I’ll do a Spandex Force: Villains if the current game is well received.

In general, I decided on a few design choices for Spandex Force: Champion Rising to ensure that the game delivers that elusive aspect called “fun”:

  • The player must always progress; no reduction of skills and attributes
  • No happiness / stamina mechanic is necessary – it introduces too much micro management
  • The tone should be sarcastic but happy
  • The player must always know what to do next
  • The game is centered around a core mechanic: hex based puzzle gameplay

Finally, to show what the game has evolved into, here are some screenshots of the current version. I hope you agree that these look more appealing!

Greater of Two Evils – Microtransactions or IAP Unlocking

February 7th, 2014

The recent debacle with EA’s Dungeon Keeper for mobile has made me question how to handle unlocking of content in my new game, Spandex Force: Champion Rising. Dungeon Keeper apparently uses very shady tactics such as pay-to-play design and making it hard for users to downvote the game. Part of me wants to optimize my game for revenue – but a bigger part wants to ensure that I present a fair and decent game.

Whenever someone uninitiated talks of microtransactions they clump everything together into one single concept. But there are really many different kinds of microtransactions:

  • Pay-to-play - the player’s actual gameplay is rendered non-existent unless he pays to proceed
  • Pay-to-win – the player can spend money to e.g. get an advantage in multiplayer games, or progress in the single player experience
  • Cosmetic – the player can purchase additional themes, items or details that are mostly cosmetic
  • Content – the player can pay to access additional content such as new quests and new gameplay modes

What’s the difference between pay-to-win and pay-to-play, you ask? In my view there’s a fundamental difference in how the game is designed. In pay-to-win, the player can buy rapid progression, while there is simply no way to proceed in the gameplay at all in the case of pay-to-play.

For example: if you were to be able to purchase level-ups in an RPG, it would be a pay-to-win design. But in Dungeon Keeper and many other IAP games the actual gameplay halts until you’ve either waited for 4 hours…or paid an amount of money.

The order of the list is roughly from greatest evil to lesser evil. Dungeon Keeper and many other IAP games causes so much aggravation because there simply is no gameplay unless you decide to pay, over and over again. Pay-to-win is scorned by many gamers but I don’t see a particular problem with it, myself; if a player chooses to get access to story progression quicker by paying for it, he should be allowed to do so. But then again, I’m the type of guy who never plays action games – I see no reward in learning how to become proficient in a game that requires practice and motor skills. I went for idkfa and iddqd a lot when playing Doom II back in the days…

Cosmetic content is harmless in my view. It enhances the player experience and allows the player to customize his game – not much to complain about there. And likewise, unlocking new content is perfectly fine in my view.

Looking at these different microtransaction types and how they relate to Spandex Force: Champion Rising, I make the following observations:

  • Cosmetic microtransactions require something to give to the player. I would have to come up with new character designs, or items, or new enemies – in general, a lot of extra artwork to enhance the experience. As I only have my own meagre talents to rely on at this point, that’s simply not feasible
  • Pay-to-win is not applicable, since my game is a casual experience as it is, and designed to be a relatively short game. (4-5 hours if you plow through it.) It would leave the player very unsatisfied.

That leaves:

  • Pay-to-play would be possible. The player’s superhero currently regains all his health after each fight, but I could easily add a timer for regaining health – or add a healing ray as a consumable item. I have also added dungeons in the game, where you lose everything you have gained if you choose to exit before finishing the dungeon. An excellent design choice would be to automatically fail the player upon the first loss – or let him pay to continue playing the dungeon.
  • Content unlocking is what I have designed the game for, primarily. You get the first act for free, but if you want to progress you have to purchase access to the rest of the game as a single IAP. Alternately, I could also introduce payment for each act by itself – but I have a feeling that that would cause some players to give up on the game after a few acts instead of playing it to completion. I want people to see the full game after all!


At this point I haven’t decided for sure which approach to take. My instincts and sense of fairness tell me that unlocking content is the way to go, and it would also fit better with my ambition to have a similar game experience on desktop and mobile, but the biggest monetary gain seems to be from the pay-to-play model.

Any thoughts on the matter?