Tuesday, June 19, 2012

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.

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:

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.

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!

If you think a room could be improved in some way please click on it and it will load in the map editor. If you have ideas for new rooms you can head over to the map editor straight away using this link:

Sunday, June 10, 2012

I'm trying to get the balancing of monsters and items in Dweller just right, but it's not at all an easy task. I'm fairly certain that the game needs to become harder, but I don't want it to become too hard. I've started exporting the game data into formats that make them easier to share and explore. The first thing I started working on was a simple HTML output of the datafiles. The idea is to have something wowhead, but with static content generated at build time. Check out a first non CSS styled version of the monsters (SPOILER ALERT!) here.

When it comes to balancing the game I've taken that data and exported it to graphs to try and find monsters that stand out from the rest, either by being too hard or too easy. I calculate some kind of perceived power of the monster, the amount of XP you get from the monster and at what depth they are encountered:

I've managed to get perceived power and XP rewarded to be aligned, now I also need to make sure that you encounter the monsters at the appropriate depth as well. Things get a bit complicated though due to the side branches, but I think I'll manage to get it right eventually.

Friday, June 8, 2012

#285 Buff Elven Water #286 Fix impassable room #282 Shambling corpse has the wrong description #280 Automatically discover secret doors when you stand on them #279 Treat unknown cells as empty when calculating the bitmask #276 Bookshelves can generate books that should not be available to the player #275 Automatically switch to 'Disarm?' when moving cursor to a trap #283 Ranger's dog gets targeted first #281 Shooting by tapping on a target also incorrectly moves you #277 Empty bookshelves should be a lot more frequent than ones with books in them #274 Auto-close targeting mode when all targets are dead #289 On low-res screens to the top of the tutorial text isn't visisble #290 Blurry monster graphics on some screen resolutions

Dweller

Dweller is a fantasy roguelike for Java enabled cellphones. A version for desktop computers also exist, but the main focus of development is for mobile platforms. Dweller is designed to run on any MIDP2 or Android OS 1.5+ enabled handset.

Dweller is free to download and play, but it is also a one-man effort to bring a full featured roguelike to cellphones and other mobile devices. If you like the game please consider sending a donation: