Introduction
The content of this post was originally intended to be presented during the International Roguelike Developers Conference 2012 in London. Due to me finishing the talk in the evening after the first day and the second day of IRDC being primarily focused on a roguelike showcase I never got a chance to present this. So here it is in a version suitable for a blog post, my thoughts on roguelikes for mobile.The mobile use-case
I’m gonna start all this by introducing the mobile use-case. It seems to me that everywhere I look people have phones in their hands. Be it on the train, bus or god forbid in the car. I see them in the hands of people in cafes, restaurants and in the park. In the local grocery store and in the waiting room at the dentist. I also read somewhere that 75% of American mobile phone users admit to using their phones while on the toilet. And according to this ad we even bring our phones when we take a bath:
People seem to find many opportunities each day to use their phones, although often in short sessions, in-between doing other things.
Everyone has a smart phone
In 2011 there was an estimated 1.08 billion smart phones in use and if you include feature phones you triple that number. According to Google an astounding 700 000 Android devices are activated every day. That is a mind boggling number. Now, it’s not as if the active number of smart phones increase at a rate of 700 000 devices per day. People swap out their old phones regularly, some even do it several times a year. And we use our phones in so many different ways that we almost forget that they can be used to do regular voice calls as well.We e-mail and send text and picture messages. We browse the web and at the current rate mobile web browsing will overtake desktop traffic in 2014. In many developing countries where access to internet via fiber or ADSL is very limited peoples first encounter with the internet is via mobile phones and not computers. One third of smartphone users use social networks on their phones. We also consume music and video content with YouTube having 200 million views per day made from mobile phones.
On top of all of the above we also use a whole lot of apps and play games, but not a lot of roguelikes. Why is that and what can we do about it?
Why are there so few roguelikes for mobile?
This is an interesting question. We’ve clearly seen that people take every opportunity they’re given to whip up their phone and start using apps or internet services. My personal opinion is that traditional roguelikes aren’t suited for mobile. Here’s why:The space shuttle manual
Most traditional roguelikes have a manual several pages long and a list of commands more suited for controlling a space shuttle. Angband and Crawl have more than a hundred commands listed in their manuals. A hundred! Try to get that to work on a devices that doesn’t even have a proper keyboard...Long game sessions vs coffee break roguelikes
Game sessions in traditional roguelikes are often very long, measured in days and weeks, not minutes or hours. Another related property of most traditional roguelikes is that they require a lot of concentration with even the smallest mistake being punished by death. Neither of these properties work well with the “in-between” use-case. We should look more to what is often referred to as “coffee break roguelikes” when we think of how to design a roguelike for mobile. Games that are quick to pick up and play and last for not much longer than a few hours.Roguelikes for non-roguelike players
Relating a bit to the accessibility of coffee break roguelikes is the whole discussion about how to design a roguelike for players who have never heard of the term roguelike. Mobile phones are mass market devices and in many ways even more so than computers. People who did not own a computer or maybe wasn’t even born when roguelikes were the most popular now have devices in their pockets that outperform what people used to play roguelikes on 15 to 20 years ago. Put these people in front of a roguelike when they are used to playing Angry Birds, Diablo or Modern Warfare... Darren Grey recently posted a very interesting write-up of his thoughts on how to design roguelikes for non-roguelikers. It’s a very interesting read and it really puts forward a lot of good arguments for how to make roguelikes more accessible for players new to the whole genre. Coincidentally a lot of the stuff makes playing roguelikes on mobile devices a lot more bearable as well.Programming languages and cross platform complexity
Finally there’s another limiting factor in that the choice of programming languages differ a bit from what roguelike developers usually prefer. On iPhone you use Objective-C, on Android you use Java and on Windows Phone you use C#. A lot of roguelike projects still use C/C++ and some kind of terminal/curses/libTCOD output and that doesn’t make them particularly easy to port to mobile. Now you could target mobile only or write in a language that offers cross platform functionality from the start (more on that later), but you would still be forced to deal with the complexity of writing cross-platform games. This leads us to the final impediment for writing apps and games for mobile, namely device fragmentation.Device fragmentation
Device fragmentation is a bit of a buzzword and something that Apple fans usually like to throw as fuel on the fire when they discuss iPhone versus Android. For me device fragmentation is “the ability to write once and run anywhere” and it’s caused by both software and hardware diversity.Hardware diversity
If we look at hardware diversity we find that:- Screen resolutions on mobile devices range from 320x240 pixels to 1980x1080
- Input options vary from a numeric keypad to a full QWERTY keypad with different variants of virtual keyboards in between as well as proper gamepads
- CPU performance vary from single core CPUs running at a couple of hundred Mhz to quad core CPUs running at gigahertz speed
- Graphics performance vary from basic 2D graphics to PS2 3D quality or better
- Available memory range from around 300kb to 2Gb
Software diversity
When it comes to software diversity you have the obvious phone OS diversity with Android and iOS being the most common and several others such as Windows Phone, Blackberry, J2ME, Symbian and WebOS.To make matters worse each OS comes in many flavors and there are many versions in use at any time. Writing for Android forces you to take into account at least a handful OS versions to cover the most common ones in use today. iOS also comes in several versions but it’s a less daunting task to write for iOS since the hardware diversity is much smaller compared to Android.
Fragmentation visualized
If you want a good visualization of exactly how diverse the Android landscape is then have a look at the OpenSignalMaps survey. During a 6 month period they gathered statistics from around 700.000 devices and found almost 4000 unique Android devices with a wide variety of Android OS versions and screen resolutions.Ok, ok, I get it. The mobile landscape is fragmented. What can I do about it?
There are several languages and tools that have a “write once, run anywhere” offer. Here are some of the more well known:- Adobe Flash (Actionscript targeting Desktop, Android and iOS)
- Haxe/NME (haxe targeting Desktop, Android, iOS, webOS and Blackberry)
- Google PlayN (Java targeting Desktop, Android, iOS and HTML5)
- PhoneGap (JavaScript targeting Android, iOS, Windows Phone, Blackberry, Symbian and many more)
- Appcelerator (JavaScript targeting Android, iOS and HTML5)
- MoSync (C/C++ targeting Android, iOS, Windows Phone, J2ME, Symbian and more)
Doing it on your own
If you don’t want to use one of the languages and platforms listed above you can do a lot of the work by hand. If you separate your engine from the platform specific stuff like drawing to the screen, doing file I/O and handling input and if provide a layer of abstraction for these things it becomes a matter of rewriting the platform specific stuff while reusing the engine. This is what I do in Dweller, but it has its disadvantages. First of all you need to pick a language that is available on all platforms. I chose Java a long time ago and this does prevent me from porting to some platforms. C would have been a better choice, as Jeff Lait did with POWDER. At IRDC 2012 Jeff gave a very interesting talk on how he goes about porting POWDER. Jeff talks about the concept of bedrock programming and finding the right level of abstraction to make porting as simple as possible.Designing a touch friendly UI
A finger is not a mouse pointer
The first thing you need to accept when you’re designing a touch UI is that a finger is not a mouse pointer. Don’t ever expect the same kind of accuracy from a touch and a click. What this means is that you can’t clutter your UI with tiny buttons as the user most likely will misclick a lot. What you also need to do is to make sure that the physical size of UI elements is the same regardless of screen resolution or screen size. Don’t ever set buttons and other UI elements to absolute pixel sizes. Android has a concept of “density independent pixels” mapped to the “dp” unit. If you specify a button to be 50dp high it will be of more or less the same physical size on all Android devices, it doesn’t matter if it’s a 3.3” or 4.7” or 10” display with a resolution of 320x240, 800x640 or 1980x1080 pixels. You should use the same kind of scaling of UI elements in your roguelike.Adaptive user interface
You should create a user interface that adapts to the users screen size and orientation. Rearranging UI elements when the device goes from portrait to landscape mode and vice versa is a good idea. On low res screens you should also consider hiding UI elements that aren’t critical or possibly have UI elements change how they are rendered depending on screen resolution.One handed design
In my opinion you shouldn’t expect players of mobile games to have both hands available. They may be standing on the bus or train and need the other hand free to either hold on or carry a bag. A lot of mobile games aren’t playable with one hand and with the current trend of screen sizes of 4.3 inch or more it’s also becoming physically difficult to reach everywhere on the screen with only one hand. Still, I think it’s a good ambition to aim for.Streamline interaction design
Minimize amount of UI interaction needed
You should try to reduce the number of interactions needed to reach important or often used functions within your game. A touch interaction is a lot more expensive for the user compared to a mouse click.Automatic actions
It might also be a good idea to automate some things to remove the need for user interaction. Darren Grey suggests that the use of stairs is an automatic action. This is a good idea, but it requires stairs to be put out of the field of play, typically in walls, especially if you have stairs in one cell wide corridors. Automatic pickup of some/all items should also be considered.Automating equip and possibly also getting rid of the inventory completely as Ido Yehieli and Ruari O’ Sullivan are doing with Cardinal Quest II is yet another way of streamlining the interaction design.
Another thing that can be automated is targeting when using missile weapons and spells. If the player doesn’t have a previous target it makes sense to automatically target the closest enemy.
Optimize your mobile application
Even if some of the high end devices out there are capable of some really amazing stuff graphics and performance wise there really is not other way around it than to optimize and be smart about what you do and when if you want to offer a good experience for all your users, even the ones with a phone two or three years old.With this in mind you shouldn’t redraw everything every frame. Use bitmap caching to speed up drawing of rarely modified but complex graphical elements.
You should also beware of object creation as it is costly in many languages. This should of course be a best practice everywhere, not only on mobile, but its effects become more obvious on low end mobile devices. Roguelikes usually have extensive use of textual information with verbose message logs, inventory, character screens and so on. Building these strings can be costly as it often involve a lot of string concatenation. On low end devices, especially J2ME, this can be devastating to performance and memory use.
Test on device!
I’m going to end this rather lengthy post with a few words of wisdom regarding testing. First of all, test on device as much as possible! Emulators only take you halfway as they rarely emulate actual device behavior and performance accurately. It is my experience that things like file I/O speeds are often way slower on device than in an emulator. Rendering performance is another place where an actual device often is much slower than an emulator. The Android emulator is probably the one closest to a real device, but even then tests on device should be preferred.Also keep in mind that testing a touch UI using a mouse is not the same as with your finger!
