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:

Android

  • 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

Windows

  • 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?

 



Indie Game Development with Monkey X

January 31st, 2014

When I show off my upcoming game Spandex Force: Champion Rising I often get the question what it’s developed in. The answer always surprises people: it’s an obscure and unknown language called Monkey X.

Monkey X is an object oriented light-weight Basic-like language designed for cross platform development. Here’s a sample of how it looks, from my particle system updater:

Class Particles
      Function Init:Void()
            GUIParticleDot.Init()
      End
      
      Function Update:Void()
            Local pd:ParticleDotData
            Local i:Int
            For i = 0 To GUIParticleDot.Size – 1
                  pd = GUIParticleDot.Pool[ i ]
                  If( pd.inUse )
                        pd.Update()
                  Endif
            Next
      End
      
      Function Render:Void()
            Local pd:ParticleDotData
            Local i:Int
            For i = 0 To GUIParticleDot.Size – 1
                  pd = GUIParticleDot.Pool[ i ]
                  If( pd.inUse )
                        pd.Render()
                  Endif
            Next
      End
End

As you can see, Monkey X has support for classes (and inheritance), static functions (Function) as well as methods (Method). Local variables are specified using the Local keyword, and global variables are specified by typing – you guessed it – Global. Most of the naming conventions are very easy to get a grasp on quickly. The language has its roots in BlitzMax but is cleaner and simpler in my opinion, and easier to work with.

Aside from a few issues.

As I mentioned, Monkey X is cross platform. Out of the box it can compile to native code for HTML5, Flash, Android, iOS, Mac, Windows, PSN, XNA, etc etc. I personally use a custom BlitzMax target as well, as I find the generated BlitzMax application more stable and easier to deploy than the standard GLFW desktop targets.

After having worked with it for quite a while now I feel ready to make some observations:

Positive

  • The best cross platform capabilities of any language / framework right now
  • Capable and sufficient language that abstracts away all audio / visual groundwork
  • All code – there’s no need for a visual design tool of any kind (as for Unity)
  • Extendable by modifying the existing targets and even the compiler itself

Negative

  • No function pointers
    • This complicates my GUI framework for example. It’s possible to mimic by creating callback objects that contain e.g. a Callback method – but it’s very cumbersome
  • Not plug and play
    • You almost certainly have to modify something for some target in order to get exactly the behavior you desire. This means that you have to have knowledge about HTML5 or Android or iOS if you want to deploy for that platform, even if the major part of the work is handled by Monkey X
  • Cross platform does not mean “code once deploy everywhere”
    • You still have to design the game with different things for different platforms. Micropayments on Android? Sure! Micropayments on desktop? Not so trivial. Fullscreen mode on desktop but not mobile versions. Handle screen rotations on mobile versions but not desktop. Lower quality settings for mobile compared to desktop. Etc etc.

On the Monkey X forums there have been many people suggesting that Mark (the creator of the language) needs to do more marketing to spread the knowledge. I’m not so sure that Monkey X can ever have a truly large audience as it seems designed for engine builders; tinkerers; people who have a little knowledge about every platform and don’t mind getting their hands dirty.

For me, working on Spandex Force: Champion Rising has been an interesting experience. I like the engine and framework building parts, and after some deep thought I have designed a game that can actually be deployed to both mobile and desktop without major changes to either version. That could not have been done without Monkey X, in my view. My previous games have only targeted desktops – but now I’m starting to feel ready to plunge into the mobile 21th century without losing the benefit of targeting desktops as well.



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.