|
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).
- 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.
- 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.
- 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.
- I'm pretty sure there's even example code on the Ouya dev site, but I'll present some here just in case.
- static private float stickMag(float axisX, float axisY
{ float stickMag = (float) Math.sqrt(axisX * axisX + axisY * axisY); return stickMag; }
- 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.
- For a more detailed and nuanced approach to handling deadzones see this article here.

- 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.
- There are many simple ways to show something is the current menu option that is selected.
- Consider:
- Drastically increase the size of the text.
- Put a special background behind the selected text
- Put a special pointer graphic off to the left
- Pulse the scale of the selected text
- Put some simple particle effects on the selected text
 |
| Quick--save her! But do you have the right one selected? |
- 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).
- 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. |
- 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.
- 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.
- 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.
- 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.

- 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.
|
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.
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.
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.
Thanks!
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.
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."
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.
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.
The only valid response to sloppy ports is not to buy the damn game!
Wtf... Phone calls?? rofl
Anyways, I am skeptical about Ouya's future.