Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 26, 2014
arrowPress Releases
October 26, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Design Tips When Porting Mobile to Console
by Nathan Fouts on 04/05/13 08:31:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


The Ouya game console officially launches June 4th, but has already been sending out Kickstarter backer versions. The game store itself is live. I've had a dev kit console for some time and have been working on an original game for it called Pig Eat Ball. I'm interested in this console, am making a game for it, and want it to do well. It's a low cost console, but doesn't need to come off as cheap. What can make it look cheap and neglected? Quick ports.

Let's turn those shoddy port faces upside down.

Obviously since the Ouya is Android-based many developers have ported their existing games from mobile over to the Ouya. This is fine and many of these games are very polished like Knightmare Tower, Beast Boxing Turbo, and Gun Slugs.

After playing lots of games currently on the Ouya store, I've been seeing a trend in which a few irksome issues keep cropping up. Here is a simple checklist for developers to consider before releasing games to console. This in general could apply to all mobile-to-console, but I'm specifically thinking of the Ouya (could be for GameStick, others too).

  1. Analog controller sticks require a dead zone. Many, many, many games I've played on the Ouya store have a 'drift' in their controls. It's extremely annoying, especially considering most games on the system currently are action games requiring precision input. 
    1. It usually manifests by tapping the left analog stick to move, and after releasing the stick, the character/cursor/etc continues to move in that same direction.
    2. This is easy to fix--in the code, when you get the X,Y back from the left analog stick, measure the distance of this vector and if it's less than a certain amount, disregard the stick press.
    3. I'm pretty sure there's even example code on the Ouya dev site, but I'll present some here just in case. 
    4.   static private float stickMag(float axisX, float axisY
              float stickMag = (float) Math.sqrt(axisX * axisX + axisY * axisY);
              return stickMag;
    5. The float returned from the stickMag function will tell you the length of the vector made by the left stick input. It should be between 0 and 1.0f. The Ouya controllers are pretty gummy, so try making the dead zone fairly large like 0.35f. That is, all input lower than 0.35 in length is ignored. 
    6. For a more detailed and nuanced approach to handling deadzones see this article here.
  2. Make a selected menu option >>obviously<< different from the other options. Being presented with two options such as an in-game store "Buy" "Cancel" and seeing one yellow and one white is not helpful. Some games will say yellow is the selection and some will say white. Simple color coding is not intuitive and it's easy to fix. 
    1. There are many simple ways to show something is the current menu option that is selected. 
    2. Consider:
      1. Drastically increase the size of the text.
      2. Put a special background behind the selected text
      3. Put a special pointer graphic off to the left
      4. Pulse the scale of the selected text
      5. Put some simple particle effects on the selected text
  3. Quick--save her! But do you have the right one selected?
  4. Support both analog stick and d-pad input for character movement and menus. Especially on menus but also in the game. It's just common courtesy to allow for input for both. Some people like to play with the left stick and some like the dpad. I've played games that for some reason only allow d-pad input on the menus. I've also seen games that would work fine with d-pad in the game, but only allow the left analog stick on menus (in games where the choice of stick/d-pad really didn't matter. Yes I understand it's possible it could important in a game, but it's very common that the game would be fine with either input).
  5. Remove mentions of touch/mobile controls. Seeing things like "Tap the screen to continue" or "Press here to continue" when that function is not supported anymore in your game looks rushed and sloppy. Remove all "tap", "swipe" terminology from your game unless it's actually using the mini-touch-pad as the only input. 

    Please don't make us do this.

    1. Even if it *is* supported to allow the player to tap a portion of the screen to continue on a menu, the touch pad is a chore to use. Support button input, and show button tool-tips.
    2. Remove HUD graphics that are obviously just left over from the mobile version. Based on real examples I've played: When the O button on the Ouya makes the main character shoot, don't leave a big button on the HUD, taking up space, that lets you shoot if you manage to click on it via the touch pad. Sure it's technically possible to click on the button to shoot, but it's very ineffective and the game already has a button on the controller dedicated to that action. It's just wasting screen space, and again looks sloppy.
    3. Don't leave the || (pause button) on the screen as *the* way to pause the game via the touch pad. It's terribly slow to try to pause like that. Use the Ouya system button or another face button.
  6. Please put an Exit option in the game. Yes the Ouya system button can do this, but you can just as easily present the player with a simple option to turn off the game if they'd like to do so.
  7. Remove unused manifest settings. This may be an Ouya system issue, but I've seen some games that when installed prompt that they may need to make phone calls. I'm pretty sure the Ouya can't make phone calls, but if it can, is your game really making calls? The ones I saw with this requested never made calls. If it's not needed, just remove it--it looks sloppy.

First and foremost--please, PLEASE use a dead zone on your left analog stick input. If you've taken anything from this article, go to your code now, and implement a dead zone. Now. This is really bad, as it's making your play experience worse.

Everything else on the list is good too. Basically it means you really cared about bringing your awesome game to new people. No one likes a sloppy port. No one wants to see "Press Start" in their PC games when they don't support controller input, and no one wants "Tap Screen to Continue" in their console games.

They want to think the neat, new game they are considering purchasing was made special just for their system, just for them. You worked really hard on your game. Ports are annoying--I know from experience. Put in that extra effort, clean up your game some more, and make it a AAA port. Good luck! Gamers will thank you.

Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

University of Central Florida, School of Visual Arts and Design
University of Central Florida, School of Visual Arts and Design — Orlando, Florida, United States

Assistant Professor in Digital Media (Game Design)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Game Designer


James Coote
profile image
Browsing around the OUYA a couple of days ago, I played two games in a row that both needed deadzone on analogue sticks sorting. I'm making the generous assume developers didn't have an OUYA to test on

Josh Fairhurst
profile image
Another thing: Keep your confirm and cancel buttons consistent with the OUYA interface. 'O' for confirm, 'A' for cancel. I played a game yesterday that used 'Y' for confirm, which makes no sense. It's as if they didn't even have an OUYA to test with. Consistency on buttons will make the entire OUYA experience feel more polished.

On another note, OUYA needs to define a standard for what should happen to a game when the user drops out to the menu. Some games exit, some games go into the background, and some just completely break.

We set the analog dead zone in Saturday Morning RPG to .3 and still seem to get sticky movement from time to time. Some of it has to do with the input lag that was present in the Unity plug-in up until a few days ago.

I think the biggest problem with the store looking cheap right now is that many of the games in the sandbox were actually OUYA CREATE entries that probably haven't been touched or polished since the competition. The developers probably figured they already had a game, so why not throw it on the store - without fully considering that their games weren't really finished.

Also, people were scrambling to get games out by the 28th and ended up releasing a lot of really unpolished things. We're a bit guilty of this with Saturday Morning RPG because the Unity plug-in did not support IAPs on the 28th. We kind of had to hack that together and the result is that our IAP implementation is rather weak. There's also the aforementioned Unity specific input lag that wasn't fixed until a few days ago. Between the slew of CREATE games and rushed launch games, the store looks to be filled with a lot of half-baked stuff.

I'm working on getting Saturday Morning RPG to be a bit more polished right now - I definitely think other developers need to follow your advice if the OUYA is going to be taken seriously.

Stephen Boyce
profile image
I just finished checking out some new titles on the OUYA store on our dev hardware, while there are a *few* polished titles, the majority are very poorly ported. I've encountered titles that quite literally do not have any controller support on their main menus and I was forced to use the touch pad to navigate.

While I agree with everything you and Josh mentioned above, as I've mentioned to you on Twitter, I would also add HUD design to that list. Many games I've played, the developer has not modified the HUD and is a direct port from mobile. This results in a oversized, sometimes even blurry interface that takes up the majority of the screen space.

As James said, I will give the benefit of the doubt with the assumption that perhaps these developers have not received their hardware yet. Regardless, it is no excuse to not find a means of testing from others who do have hardware or basic porting logic before putting your game out in the wild.

Nathan Fouts
profile image
Yup, blurry, poorly handled HUD would be pretty bad as well.

Casey Leonard
profile image
It does appear that too many of the currently available games were rushed out the door, but I think the OUYA game approval process should be a little more picky. I would rather they reject a game until they get the controls consistent with stated guidelines (maybe they need more clearly stated guidelines), for example. It might take people a little longer to get approved but it hurts the platform to have all these issues in the games.

Henry Shilling
profile image
Geat to see so many of the old XBLIG gang involved in the Ouya community. These are lessons that many coming from mobile dev dont seem to get.

Casey, Does Ouya have an approval process? I know when were doing the XBLIG there is one and quite the lively discussions as to what should and should not be called a game. We could lose the openness and it becomes a curated system like XBLA or Steam, then its not open to anyone. Just what the "judges" deem appropriate.


Nathan Fouts
profile image
Henry, I've not yet submitted a game to Ouya but from being on the forums there, apparently you submit your finished game and the Ouya team does an internal approval. It's apparently very quick. It's fairly closed, but I believe also fairly basic (no porn, no nazi stuff, etc.)

Christopher Thigpen
profile image
Excellent article and mostly common sense for any porting. Know what you are porting for and make the appropriate changes to satisfy the basic of parameters.

Ian Fisch
profile image
These are amateur mistakes. This is what happens when you depend on untrained developers to fill your game library.

Brian Stabile
profile image
Most developers flocking to the OUYA are small indies who have been working on mobile and tablet titles, and so have never had to think about the problems mentioned above.

Tammo Hinrichs
profile image
Or to put it short (even if not entirely serious but there's a point hidden somewhere): Dear Ouya devs, go to the internet and download a leaked SDK from ANY console from the last 15 years. Locate the document specifying the certification/approval requirements. Read it. Read it again. Ponder about what the reasoning behind all these arcane rules might be, and then read it a third time. There's some incredibly valuable stuff in there.

Chris Moeller
profile image
Good points to note - a developer might get so used to trying to make everything touch screen friendly, they forget how to make everything gamepad friendly, or might accidentally leave in content that is no longer usable.

But I have to say- even EA PC games leave in references to the ported console controls. I can't tell you how many games I've played, where they prompt you to push the 'blue 'o' button, or some other color coded x-box button on PC.

So it's not only OUYA "amateur", "untrained developers" that make these mistakes, AAA titles do so as well.

I'm sure as the console matures, and as developers keep getting helpful feedback, such as in this article, there will be less sloppy porting problems.

Nathan Fouts
profile image
Just because EA is doing sloppy ports doesn't mean we (independent devs) should do it, right? I know you know, just saying--hey, let's do better! Right?

Something we saw a lot of early on with XBLIG was people complaining about points the community would require from other XBLIG devs such as holding everyone to a strict title safe area. Some devs would point to Dead Rising and ask why Capcom could go outside the safe area or have extra small (unreadable) fonts. "Because they're Capcom and you're not. And you're game will be better for staying in the safe area."

Chaitanya M
profile image
May I suggest this:
static private float stickMagSquared(float axisX, float axisY)
float stickMag = (axisX * axisX + axisY * axisY);
return stickMag;
and then compare it with your fudge value (0.35^2). It doesn't have to be accurate because it is a relative value for making the decision.

Nathan Fouts
profile image
Yes great point, could just skip the square root.

Tammo Hinrichs
profile image
Actually, simply ignoring the dead zone and then suddenly processing isn't a too good idea either in my opinion. From my experience it's better to extend the deadzone=>full range to 0=>full, as in

float deadZone = 0.35f;
float stickMag = (float) Math.sqrt(axisX * axisX + axisY * axisY);
float magAdjust = (float) Math.max(0.0f, (stickMag-deadZone)/(1.0f-deadZone));
axisX *= magAdjust;
axisY *= magAdjust;

[Disclaimer: I didn't try to compile or even run the code above :)]

This way you still have the full "analog" control without your character/etc suddenly jumping into action when you press the stick gently.

Glen M
profile image
Great article and great comments too. What would be really great is if they had a badge for "plays great on OUYA" and a special section for those games based on the internal playtest. Would highlight devs that took the time to port it correctly.

Bryson Whiteman
profile image
Great stuff Nathan!

Kujel Selsuru
profile image
I'll wager these sloppy ports aren't going to fair too well when the general public get their hands on the Ouya but the devs who take the time to actually do a decent port will fair much better.

The only valid response to sloppy ports is not to buy the damn game!

Bruno Xavier
profile image
0.35f dead zone? That is such a huge gap for controller sticks on a console.
Wtf... Phone calls?? rofl

Anyways, I am skeptical about Ouya's future.