Developing games for multiple devices on iOS: Part 1 – how screen differences effect gameplay

One of the challenges of writing games for multiple devices is that there are typically several form factors you need to support. In the Android world, you literally have hundred of devices to consider, though you can target popular ones and probably make most people happy. I haven’t done too much development on Android however so can’t give too much detail here.

In the iOS world, it’s a bit easier since you have a much smaller universe of models to tend to. Grouping all the similarly sized devices into categories (and excluding old models that aren’t supported anymore) you end up with only six device types, which isn’t too bad.

There are only two things to really be concerned with for each screen type: it’s resolution (number of pixels horizontally and vertically) and physical size. Sometimes you hear about pixel density (DPI or PPI), but this can be derived from the size and resolution of the screen.

In this series of articles I’m going to talk about some of the challenges I came up when porting Play The Field from iPad to iPhone, and along the way give some ideas that may help you doing the same for your game. PTF is a minimalist RTS game, but I expect many of the things I discuss will apply to other game types as well.

Though as I mentioned above there are six devices types on iOS to worry about (at least as of May 2015), I’m just going to focus on iPad Retina (which I originally wrote the game for) and iPhone 6. You can see the full list of specs for all currently supported iOS devices here here.

Before I get any deeper I’ll explain a little more about how Play The Field works. There are two sides, the user and the computer, and each has their own units – you can think of them as little tanks if you like though the game is mostly non-violent. There are different unit types, but most share in common the following characteristics: movement speed and attack distance, both specified in pixels.

Movement speed represents how many pixels the unit can move in a turn, and attack distance is the maximum distance to an enemy before it can begin attacking it. One more important piece of information is that there is a series of levels, each with a different layout of enemy units, and I wrote the engine to scale the layout to the screen size.  So if a certain level contains 10 units in a circle, this circle will be adjusted to fit properly on any resolution without being cut off.

iPad Retina has a resolution of 2048 x 1536, and iPhone 6 has 1334 x 750. The latter is a little smaller than you would expect given the resolution difference, because the pixel density is roughly 23% higher. What this means is that if I draw a circle of a certain radius (in pixels) on both devices, the one on the iPhone 6 will be approximately 23% smaller. In the case of PTF, I determined this was not a major problem so I left the unit sizes the same. If the density difference was significantly higher, I would have had to scale all the unit sizes accordingly.

The problems begin when you consider how the levels get rendered on each device. Just ignoring the menus for now, there is 2048 – 1334 = 714 pixels extra in the vertical direction on the iPad Retina, as compared to the iPhone 6. Assuming I don’t change the speed of the units or the board layout at all, it would take units significantly that much longer to cross the board. Also, assuming I don’t change the attack distance, this means the board is effectively more cramped. For example, on some levels where I could have added a unit safely without being attacked immediately by an enemy, now there is less space and my unit will get attacked right away. As a user playing the game on both devices and comparing, because the physical distance is almost the same, this difference would seem strange. After all users don’t actively think about resolution.

I knew these factors could have a pretty major effect on the gameplay, so I play-tested the levels on the iPhone to see how it was. Fortunately, though the game had a different feel, most levels were playable and still had a good degree of challenge. I did tweak a few things to make them work better on the smaller resolution, however. For example, I removed the red area (which blocks unit placement) on one stage because it limited the user’s choice too much. Another option I had when doing the port was to just scale everything down to match the lower resolution: the unit size, speed, and attack distance. In theory, this should keep the gameplay the same as the larger device, as if you were watching recording an iPad on a camera and replaying it on a small TV.

But this approach has its own issues. First, the units would not be much physically smaller, which would render them hard to see as well as hard to select. Accidentally selecting the wrong unit would also happen more often. Also, the speed of units (as seen visually), which had been carefully adjusted, would now be significantly slower on the iPhone. This is because the units are moving the same speed relative to the number of pixels available, but the physical size of the screen is smaller so this translates to less distance per movement.

Yet another option would be to redesign each level from scratch for the smaller form factor of the iPhone. This has the potential to have the best user experience because things are fine-tuned, but it puts a heavy burden on the developer for the redesign process. I am considering doing this eventually, but for the initial iPhone release I just wanted something that was playable and fun, and was able to achieve that without the extra work.

But alas, our work is not yet done! There is still one more area where I had to put in extra time to fit the iPhone’s smaller screen and resolution – the menu system.

I’ll dedicate part 2 of this series to the menu changes I made.

References

http://www.iosres.com

Desktop Games vs Mobile Games: input method differences and how that effects gameplay

Although I had originally created this blog mainly to be a home base for my mobile game Play The Field, after some consideration I’ve decided to put a heavier emphasis on mobile game design in general. I think this will be more interesting for readers, as well as myself, in the long run.

In this post I’m going to focus on input control differences between desktop and mobile games, and how that effects gameplay.

For the desktop, the primary devices for input are the time-honored combination of mouse and keyboard. On mobile devices, a touch screen is the primary method. For now I’ll stay away from alternate methods such as console-style controllers, acceleration sensors, audio, and other custom devices like food pedals.

The first thing to note is that, given the user does not have any major physical handicaps, you can manage inputing nearly any type of content on either desktop or mobile. What is different, and what really matters, is how easy it is for each content type.

To give a specific example, typing up a document can be done on either a standard desktop keyboard, or on a in-screen mobile keyboard, but the latter is typically much difficult or at minimum awkward due to lack of force feedback, key sizes, and other factors. This isn’t the best comparison, however, since you can get a mobile keyboard to partially solve this problem.

For the rest of this post I’d like to focus on comparison of the desktop mouse vs the mobile touch screen, as they tend to be the main input methods used for a majority of games on each platform.

On the surface, these two input methods seem quite similar – after all, in both cases the user can pick a point roughly corresponding to the display screen. In other words if I want to click on a balloon which is floating on the screen, the conceptual action of clicking vs touching it is not that different.

One of the differences is that mice have two or three buttons, while a touch screen effectively has one. Also, mouse double clicks don’t translate too well to double taps on the screen; they can be done in theory but are rarely used in the mobile apps I’ve used.

What I consider even more important is the fact that tapping all over a mobile screen is just a lot more physical work than moving a mouse cursor the same relative distance on a desktop monitor. The higher the mouse sensitivity is set the less distance the hand has to move to translate to larger distance on the monitor. At the highest setting, crossing the entire monitor can take less than an inch of real distance, whereas on a mobile device the user has to cross the physical size of the entire device.

Another weak point of mobile devices’ touch screens is accuracy. Since you usually don’t know the exact pixel you are clicking on (like with a mouse cursor), there is uncertainty about exactly where you are clicking. The smaller the screen the larger this uncertainty is relative to the screen’s total size. Much of the problem here stems from the fact that the place you are touching is exactly the place that you can’t see, since your finger is obscuring your vision there. One pretty effective technique used in iOS to combat the accuracy problem when selecting text is to show a magnified view of the text and selected area.  Buttons and the like are also typically much larger on mobile apps.

What all these drawbacks mean is that input for mobile games, and mobile apps in general, tends to be much simpler. If you look at the most popular apps, you’ll find a good percentage of them have, well what I feel as maddeningly simple input control systems.

To give one iOS example that is a bit dated, the game Jetpack Joyride involves a character in what looks at first like a classic side-scroller, except the major difference is the control is super simple. Tap to jump, don’t tap to do nothing. The character moves to the right automatically so no other buttons required.

Another more example, a bit more modern, is Hellrider, where a motorcyclist runs literally through “hell”. The controls are equally simple: tap to change directions, don’t tap to keep driving in the same direction. The only two directions are forward-left and forward-right.

Both of these games were actually kind of fun for the first few minutes, but with so many years of mouse+keyboard experience I just couldn’t get over how limited and simplistic the input controls where. Sure, mobile games with such simplistic controls (and believe me, they are a dime a dozen) can have great elements like a   great graphics, engaging music, challenges, and require a certain level of strategy and persistence to beat, the extreme lack of options as the user just endlessly annoys me.

Fortunately, some games try to make the best of mobile touch screen’s strong points and increase interactivity. One good example is the classic Fruit Ninja, which utilities multi-touch and gestures, neither which work too well in the normal mouse-keyboard world. The result is much more satisfying to me, since I am not just dumbly taping the screen (albeit with perfect timing).

Another genre that I enjoy that has taken up a lot of popularity on mobile platforms  is defense games (or tower defense games). These typically involve a setup period where you place your buildings and units, and then start the game to let the battle unfold. It’s fun to watch the action and cheer for your side, and the level of control you have is much higher than the click/don’t click style I discussed above. But a key point here is that the setup time is typically not timed and you don’t have to rush to place buildings and units, and once the hectic battle begins you don’t have to do much but wait (though sometimes you can upgrade or do other tasks). Again, comparing to full RTS games on the desktop where you can change the orders of unit’s in the heat of battle, I feel there is a loss of control and as a result less enjoyment. There are such full-featured RTS games on mobile platforms, but they are relatively rare and typically not given away from free.

Having tried a great many iOS games (most free and/or from one of the ‘popular’ categories in the app store) and being disappointed with the lack of rich, engaging controls is one of the things that inspired me to develop Play The Field. I took some of the basic aspects from the RTS genre and boiled things down to their simplest elements: creating units (of various types), moving them, and attacking. The important thing was that both placement and control of units happened during the game, in real time, so I was never forced to sit back and watch dumbly, or just slam the screen with some perfectly-timed pattern. To help things out, I took a cue from games like Fruit Ninja and added gestures for unit creation and selection to remove tedious machine-gun tapping.

I think the end result is fun and challenging, if you are interested try it out here: https://itunes.apple.com/us/app/play-the-field/id985621862?mt=8

(Image credit: Matt Trostle (creative commons attribution license): https://www.flickr.com/photos/trostle/6848810640/in/photolist-brcWN5-4UA6My-8QKFCa-bd88Ue-qpJH4d-4M6Jou-ehmy7i-bP2MWP-9rcj1f-5jKhPh-9m3Srr-5eYjSG-GaSJ6-7pAjno-4kAY89-89igMH-7rrg9h-9LiPpm-4pJmY5-9TSfwz-7pAVoS-8PcDor-b19MYk-kzUBDW-9mB2Sw-9sqQAA-Q2hEK-xULQW-dwDFBc-3Xmcvh-7eEbDP-4AAnR3-n9GwQ-CED3C-jKUF6d-6wqxxe-4ytp2-j1MjXi-7rVtoK-7pAXtY-dxHQfC-5Ftq8C-9vvgMv-eV5XK3-7pwv3K-bunSTi-7pAorY-bQPpYF-djDDRw-7F83fo)

Detailed review of “Little War Game”, a HTML5 RTS game (updated)

Recently, due to my familiarity with the RTS genre I was asked to review the game “Little War Game”, which can be found here:

http://littlewargame.com

At first, I hesitated since I wasn’t planning on advertising others’ games on this blog. But on reconsideration, since the game is made by an indie developer and is from a related genre to Play the Field, I decided to review the game after all.

As this post is fairly long and detailed, I’ll just give the punch line here: I highly recommend any RTS fans to try this game out.

The game’s biggest selling point is that is created using HTML5, which means you can use it on any browser, on any OS, at least in theory. This is great for users since they don’t have to have a specific setup to play it, though I think this point is best appreciated by a game developer. Conversely, since a browser language like HTML5 conceptually would be a bit farther from the hardware, from the start I set my expectations low for the graphics and performance. [Note: I have only vague familiarity with HTML5]

In spite of the supposed platform independence, my first experience with the game was a bit awkward. I attempted to open up the website on my iPhone’s Safari browser, and after playing with it for a little time I couldn’t get it to start. To be sure, mobile browsers probably have many limitations not found on desktop machines, and maybe with a little more poking around I could have gotten it to work. Regardless, for the HTML5 aspect to really shine, it should function well on all common mobile device’s browsers – though I acknowledge how difficult that might be. At minimum, I would hope the page detects I have a non-supported browser and lets me know early on.

But on to more fun stuff – When I tried it on my MacBook Pro’s Safari, the site loaded up quickly and I was able to get a game started in only a minute or so. The initial menu screens have a strong nostalgic retro feeling, reminiscent of some classic console games, especially because of the blue color gradient.

LWG has several modes, including a live multiplayer with one or more users logged into the site, and also a single-player version. In both cases you can choose the level and add computer player(s) as needed. There seems to be a good assortment of different levels.

I didn’t explore the menu system completely, but I didn’t come across a single player story mode. Though one can argue most users spend the greatest percentage of their time in the multiplayer modes, I feel that a story helps bring you into the world and familiarize you with the various units. As good story writing is difficult I wouldn’t expect a great deal from an indie developer, but 5-10 levels of story mode would really do the game good in my opinion.

The game itself is a traditional RTS set in what looks like the medieval period. You have catapults, mages, wolves, archers, and probably many other units I didn’t get far enough to play with. Purposeful or not, I feel it took some influences from games like Blizzard’s Warcraft series (the RTS one, not the online one), though this is by no means a bad thing. The game flow is very typical: build miners, get resources, build buildings, train units, explore, attack, expand, etc. This is both a strong point, since it is familiar for most gamers, and a weak point since there isn’t that much creativity to neither the gameplay nor the universe the action takes place in.

The graphics are reasonably good, given they we going for the ‘retro’ feel, though of course it doesn’t compare to a game like Starcraft 2 whose graphics are close to a work of ark. That not a fair comparison anyway, because games like Starcraft are written by a massive studio with insane budget.

As a side note, some of the game’s graphics like the minimap and shading algorithms reminded me of my last desktop RTS game, though LWG has much better visuals. Again, there is a good explanation for this since LWG’s credits states five people worked on the art. To the developer’s credit, he seems to have done all the coding himself, which is an impressive feat.

Though I had the sound turned off most of the time, I would say the sound effects were so-so, with the music fairly well made.

Retro assets are great and all, but if you’ll allow me to wane critical again I think the game’s popularity would go up if the visuals were revamped to be more modern, with higher resolution. If certain browsers can’t take the load for high-density images, the LWG developer can make several versions of the tiles and all selecting the best set (either automatically, or by the user).

The game worked relatively well, but I did come across a handful of bugs. The most annoying of these is when the explanation text shown in the top right window was consistently cropped to a single line, in some cases hiding valuable information. Also, one time when I left the game running in the background while I opened up WordPress in a separate tab, my browser froze for a few seconds, twice, because two scripts were not responding (IIRC “event.js” and “game.js”).

In terms of the RTS elements, there were a handful of fundamental things that appeared to be missing, like the ability to create groups and to add waypoints [Update: I have been told both of these are supported though have not verified myself, check the Settings page of the game], both critical to any serious RTS gamer. Some of the visual design was also a bit wordy and hard to understand in a brief glance. For example, the capacity of mining was shown with a number instead of a horizontal bar, and it took me awhile to find the building to give more control since I had to read all the text. For this second issue, traditional RTS games usually have little icons indicating the amount of control needed or produced so reading through text isn’t required.

The overall control was mostly intuitive, but I ran into one frustrating problem over and over. I habitually did a double finger drag on my MacBook in order to try and scroll the field, but in LWG this instead zooms in or out. I imagine this could be tricky to address since HTML5 is used, but I would rank it as a pretty serious issue to try and sort out.

The performance was reasonable, though a little on the slow side. I think there should be a setting for speed – if there was one I didn’t manage to find it yet.

Overall, from the eyes of a game developer this is a pretty impressive indie game project, very solid in many areas. I am not sure if the creator is open to adding more developers to the project, but it looks like a fun endeavor to code, especially for a classic RTS fan. From a brief look at their website I saw they were making some APIs to allow customization, so anyone could potentially contribute this way.

If you’re just an everyday casual player, while the game is fun I think some people will have a hard time getting hooked to keep playing. Besides the improved graphics or story mode I mentioned, adding things like achievements, ladder play, or more races (there appears to be only one) could go a long way here.

For the hardcore RTS players, its virtually guaranteed that you will get a better experience in terms of graphics and performance on native platform code (say, code written in C/C++ compiled for Windows). So the Starcraft fanatics might never quite get addicted to this, however if LWG’s creator can beef things up with extra elements it can become an even greater game.

All things considered, I highly recommend checking out Little War Game.

For a final note – if you enjoy RTS games and happen to have an iPad, consider checking out Play The Field why you are at it. It’s a game that evolves the RTS genre for mobile to allow for shorter games while testing your tactics. Here is the link to download it from iTunes:

https://itunes.apple.com/us/app/play-the-field/id985621862?mt=8

(Note: I spent roughly 30-60 minutes playing the game before writing this, so surely there are some things I missed. I’ll update the article if I receive any new information.)

(Update: I had originally alluded to a team of people working on this game but was told there was pretty much only one person doing development and making frequent updates, so have updated the review content to reflect this. According to the credits page on the website there was several people who worked on the tileset, which is why I had written “team”, but I was told they have not been active lately. Having said that, I think their contribution is important since I know how difficult it is for a developer to make a good tileset)

Game development: Techniques to keep your users playing (plus discussion of scoring system in Play The Field)

One of the big challenges in game development, whether at hobbyist or pro level, is creating replay value so the user can enjoy the game for an extended period of time. Even if the game is free, the longer they play it the more likely they are to tell other people about it, hence increasing popularity and total number of users. If the game is ad supported, keeping the users interest is even more critical (currently PTF has no ads).

In games which are level based, hand-designing levels is tedious and requires a great deal of testing to balance the elements of each level. Random level generation is one idea, but usually users will get tired of that unless some very special algorithms are used.

Multiplayer against one or more human players is another good way to extend enjoyment, and if you can elevate your game to the level of a “e-sport” where pro-gamers will play it for money, then you user count will likely skyrocket. Or course, being a professional e-sport brings with a great responsibility for fairness and balance in gameplay.

Games where the opponent is generated from artificial intelligence are typically either too easy or too hard, though lately some games have improved in this area. Making a graded system of levels can be effective, especially if there is some way to auto adjust to the user’s performance.

In my mobile game Play The Field, I choose to utilize a classic, time-tested system to increase re-playability: scoring. When a board is completed, the user receives a score base on their performance, and that score is saved and displayed on the main level map screen. Users can replay levels, aiming for a higher score by using more creative and effective tactics.

For those who are interested, I’ll outline the algorithm for generating the score in PTF. It’s relatively simple and contains the sum of these three factors:

  • The total money remaining
  • The total cost of all friendly units in play
  • The number of seconds since the level started, subtracted from 300, i.e. (300 – secondsSoFar)

The idea of this formula is to judge how efficiently the board was solved, by factoring in the number of units lost plus the total time spend. The more units lost, which is factored in indirectly via the total money remaining and total cost of units in play, the lower the score. The longer the user takes, the lower the score.

By choosing to use a sum of the first two factors, the fact the user has chosen to purchase a certain unit doesn’t matter – what is important is that he/she uses it effectively. Sqeaking by with a single unit left isn’t nearly impressive as dominating without loosing a single friendly unit.

The reason for the 300 factor is to give the user 5 minutes (60 seconds x 5 minutes = 300) to try and complete the level. After that, the contribution of the time falls to zero (negative values are rounded up to 0), leaving only the amount of money (in terms of unspent money and cost of created units) remaining.

In my playtesting, I found this to be a pretty accurate way to gauge the user’s skill, though I am always open for suggestions to optimize the scoring algorithm.

Download PTF on iTunes (free): https://itunes.apple.com/us/app/play-the-field/id985621862?mt=8