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!