Julie Uhrman to Keynote at Droidcon

[BlairJ]

It appears that OUYA will be making an appearance at Droidcon afterall:

http://uk.droidcon.com/sessions/futu...-keynote-ouya/

[AdyCarter]

Aye, kinda regretting passing on tickets now :/

[MyOpia]

When is this? Is anyone here going?

[Eddie K]

Here's some information about Urhman's keynote:

http://uk.droidcon.com/sessions/futu...-keynote-ouya/

It is on the "Future of Android", and Droidcon will allow you to ask her questions.

The Droidcon will be held on Oct 25-26th, 2012.

Ed

[James Andrew Coote]

I'll be there if anyone wants to meet up and talk OUYA stuff

[Eddie K]

Anyone attend and have anything to say about the keynote? Here are a few minor things I heard were discussed:

- OUYA plans to use a 70/30 Rev Split for Developers, meaning Devs will see 70% of income taken in for games.
- OUYA will list games by time played plus revenue & reviews, according to a tweeter who was there.

Ed

[dr-nix]

Hopefully the keynote speech was filmed, if so it will probably find it's way to youtube.

[James Andrew Coote]

The video will appear on either the droidcon website or the skills matter website at some point soon / in the future. I might try and get in contact with the guys at Novoda about getting a special link to the OUYA keynote if I have time over the next few days. I'm about to head on holiday, so here are a summary of my notes (i.e this is my take on the talks) from the keynote, and also from another talk by one of the new recruits to the OUYA team

Keynote - Julie Uhrman:

OUYA background
- Trying to bring the explosion of mobile & indie development to an open console

Working with NVidia to overclock and push hardware

Design and aesthetics important, including console controller and ergonomics

Fact controller had touch screen was mentioned a number of times

OUYA will curate content - all about finding the best games
- Open to suggestions on how to do this. E.g. one in reddit threat someone suggested measuring how long people play the game for as a measure of how fun it was. Als suggested were peer review (i.e. devs reviewing other devs)
- Dev section will be much more advanced than other app stores (implied that devs will be able to have a much better store front)

No Advertisements on OUYA (see also 2nd talk)
- IAP is the way forward, or premium/freemium or subscriptions
- Most of the OUYA SDK / API will be around giving devs IAP tools etc

APK's won't be copyable from the device. Bit of a confused message about piracy, as emphasis was that console would be as free and open as possible, but there would also be anti-piracy measures built in for developers

Still comitted to working with streaming services. "Don't write off OnLive yet"

Cross platform or games where other devices link into the game (such as your phone) a cool idea, but something they are really not concentrating on atm (i.e. if devs wanna make it, cool, but they won't support it)

70 / 30 revenue split (just like the mobile (business) model)

No "Secret Sauce" - OUYA can compete because it isn't trying to invent super-bleeding edge tech. Room for both a Playstation and an OUYA in the home of the average gamer

No marketing done (aside from kickstarter. Team is focused on product at the moment

No general retail date set. Kickstarter backers will get console in March, those that bought online after the kickstarter, april

_____

And in the second talk, much more aimed at practical advice for devs:

OUYA not google approved (so no google play store) because device does not have touch screen

Design for TV, don't think small, think big assets, big screen

Pull big assets from your own servers (implied because OUYA won't have much capability to host your 4gig of game files or whatever)

Use zonal displays. HUD constantly on screen, heath, ammo at edge of screen (again think TV,not mobile)

Don't do on-screen buttons, as they are bad. Equally don't do "click here" type buttons. It is not advisable to try and use the touch pad to control a cursor

Android SDK actually already has support for MotionEvent D-PAD and GAMEPAD. Use this for getting input from ouya controllers

InputEvent.getDevice() - Use this to identify controller. Don't assume the same player will pick up the same controller after the game is paused, and everyone goes off to get another round of drinks or eat pizza

Use getDeviceRange() to calibrate sensitivity of sticks, (implied because not all controllers might be ouya controllers)

Each OUYA will have a "primary user" which will probably be the person who pays for stuff on that device

Consider coop, head to head and split screen design patterns for multiplayer games

Device ID is per power cycle (i.e. can change every time the console reboots or a controller is plugged / unplugged)

Bandwidth and battery aren't an issue on OUYA, unlike mobile

But obviously don't be downloading vast amounts of data and capping out some player's data useage on their home broadband.

Also try to only do stuff when the current game/app is on screen. I.e. No Background services!! Ideally, kill your app when it is put into the background / closed

Be social, integrate facebook, use achievements

Remember to handle AFK's or Ragequits for multiplayer, or pausing if someone goes to answer the door for the pizza delivery.

Also encouraged is if players can take their game with them, so when they leave the house, they can continue playing on their mobile. E.g. like Eve online lets you check skills via a web interface. But no SDK / OUYA support for this. Devs have to code this stuff themselves

Every app will only have 1 APK (unlike how google play recentl;y allows you to have multiple apk's under 1 app in the dev console of the google play store)

Again emphasising / encouraging devs to do multiplayer and social

finally, if the game has a good buzz, and something a bit quirky or unique, then OUYA will try to look out for that and give some help out (they have already backed a couple of Kickstarter campiagns of OUYA games), but probably not best to pester them or pitch to them directly

___

One other sentiment repeated in both talks was "If you want something from OUYA, tell us, and if enough ppl agree, we'll try and do it. We want to be user lead, not dictating what gamers should and shouldn't want from on high

[dr-nix]

Thanks for the info, good post

[Jawdy]

James, thank you for posting up your notes! Incredibly helpful, informative and some excellent points in there.

OUYA will curate content - all about finding the best games
- Open to suggestions on how to do this. E.g. one in reddit threat someone suggested measuring how long people play the game for as a measure of how fun it was. Als suggested were peer review (i.e. devs reviewing other devs)
- Dev section will be much more advanced than other app stores (implied that devs will be able to have a much better store front)

Peer review is a little how Greenlight has done it - although, that's hardly "Peer" reviewed, as anyone on Steam can do it... but it can be an interesting concept. Same as measuring the amount of time, that's an interesting take - but often not indicative of some games, as many you'll play for a few minutes, versus those that you'll play for hours.
Mind you, if you play a game for hours, that often means you're willing to invest the time into the game!

No Advertisements on OUYA (see also 2nd talk)
- IAP is the way forward, or premium/freemium or subscriptions
- Most of the OUYA SDK / API will be around giving devs IAP tools etc

Developers often quote falling ad numbers, as users are becoming increasingly aware and ignoring advertising. IAPs, when done well and not crippling a game, can be excellent! I certainly like the idea of offering variable pricing options - freemium with small IAPs, a subscription model like an MMO or perhaps some sort of premium price (via an IAP?) where you can buy the entire game without limitations, but for a profitable price? Anyway, I digress...

APK's won't be copyable from the device. Bit of a confused message about piracy, as emphasis was that console would be as free and open as possible, but there would also be anti-piracy measures built in for developers

This might prove difficult to prevent, especially if the device can be rooted as easily as they're claiming. But at least some attempt in tackling piracy is being made!

Cross platform or games where other devices link into the game (such as your phone) a cool idea, but something they are really not concentrating on atm (i.e. if devs wanna make it, cool, but they won't support it)

Also encouraged is if players can take their game with them, so when they leave the house, they can continue playing on their mobile. E.g. like Eve online lets you check skills via a web interface. But no SDK / OUYA support for this. Devs have to code this stuff themselves

This is a great idea. We've seen it with the PS3 and Vita, we're seeing a use of this with the Wii-U and the kinds of networking technology to make this happen are become more available.

OUYA not google approved (so no google play store) because device does not have touch screen

What about Google TV? That doesn't have a touchscreen, yet it's Google approved... or is that under a different thing?

InputEvent.getDevice() - Use this to identify controller. Don't assume the same player will pick up the same controller after the game is paused, and everyone goes off to get another round of drinks or eat pizza

Much like the 360 or other consoles, if anyone has ever battled with this via XNA or the full devkits!?

Device ID is per power cycle (i.e. can change every time the console reboots or a controller is plugged / unplugged)

Interesting. I'm guessing there's a better way to track your actual user? Probably via the logged in user?

Also try to only do stuff when the current game/app is on screen. I.e. No Background services!! Ideally, kill your app when it is put into the background / closed

This is something many of us have discussed in another thread. The services are tremendously helpful when you want to play music, but not have the screen on - and with the OUYA, that's kind of difficult to do, as the audio comes out of the HDMI! So in many cases, I can see the use of Services as moot!

Every app will only have 1 APK (unlike how google play recentl;y allows you to have multiple apk's under 1 app in the dev console of the google play store)

This was particularly useful if your app needed specifics for ARM based devices and something else for x86 based (like Atom). Fat packages, containing APKs for both builds, make sense on an open market like Google Play, where you're hitting a plethora of devices, but on the OUYA store, not so much - as you know the device :-)

-----

Thanks again, James!