I was one of the earlier folks to put down a pledge for this thing, because it seems like something I'd like to develop for. However, I pulled it back today because of the lack of a dev story for it. I was told by the Ouya official twitter account to just "develop on another Android device", which is a very shallow answer given the huge differences in gameplay between a touchscreen device and a gamepad device (and that gamepad-api isn't really viable yet). That suggests that they don't take the craft of game development seriously, and to me that doesn't bode well for the platform.
When they have development resources that show me that they're taking developers seriously, I'll revisit it (and doing so is fairly cheap for me; I'm using the always-awesome libgdx, which has Android support already). But my initial experience has been pretty bad, and I'm questioning their competency right now to the point where I can't give them money.
This is pretty telling. You're right on all points from a developer's perspective, and their line seems to be nothing more than "we're leveraging the big, wide, Android game ecosystem!"
I think anyone with hardware or Android game development experience should be healthily skeptical of the tall promises and minimal explanation coming out of this Kickstarter. I love a good chunk of optimism as much as the next guy who loves games, but the fervor seems to really be distorting reality and setting up an inappropriately adversarial tone to these HN discussions.
cpuspin: You appear to be hellbanned, though I'm not sure why.
But to reply to you--their pitch may be "working" in the sense that they're getting pledges, but the amount of the pledge totals is pretty clearly not going to generate a profit. Without the app store, they're not going to be making money. Without developers, they're not going to be selling anything in their app store, which you need to have populated with games by early 2013. Six to nine months is already not a lot of time to put together a game, so you really, really want to get developers excited for and working on your stuff right effing now.
That's where they're falling over. And it is literally-literally as important as getting the consoles to consumers.
Yes, this is what worries me too.
If they wanted to reel developers in on this what they should be releasing like right now is some documentation for developers.
Since the hardware is not released yet they should be showing developers how to emulate as-close-as-possible to this on a regular PC (including which commodity joypad you should be testing with) so they can be confident that their game will only require minor tweaking when the final hardware is released.
OT: It seems to be very easy to get HellBanned from HN which makes it seem pretty cruel.
You only need a handful of people not to like your first few posts to effectively kill your chances of contributing to the community and potentially wasting a lot of your time.
Perhaps a system like , you can only downvote comments from users under a certain karma threshold if you also flag them as trolling/spam
Its ingenuous how they talk about indie developers. If the founder is as knowledgeable about the gaming industry as she claims to be then she knows that game development by indie developers is great and a couple lucky ones will emerge but the big player come in quickly and take up most if not all of the profit so any gaming platform that pitches to indie developers is just creating smoke and mirrors
I already tried to get in contact with them, no reply. My optimistic assumption is they are overwhelmed with the response and need time. My pessimistic assumption is that they don't care for apparently small fish like libgdx. Thing is that we power more Android games than Unity or AndEngine according to AppBrain [1], that has to count for something. They need developers, we can get them those if they let us in early. On the other hand it's probably more important to get the marketing sping going with Unity or Notch. We'll see.
You can use an Xperia Play, which has slide out game controls, although ICS + Bluetooth controller would be a better route. Almost no games will ever be written for Ouya alone anyway, they'll just be written for Android in general and if Ouya is lucky have a few small tweaks for them like hiding the on screen controls. I've seen games ported from gaming handhelds to Android and the porting company didn't even add support for the D-Pad buttons on some Android devices. Just tossed in on screen touch controls and that is it. Game developers just won't, in general, put much time at all in customizing the game for a specific Android device.
Without further information about their controller (and the rest of their environment, really), I'm hesitant to just jump right in.
And, sure, most developers won't put time in to customize a game for a specific platform, but I'd personally be ashamed if I didn't make it good on every platform I say I support. If it isn't done well, I'd rather not do it, know what I mean?
I'm not even sold about supporting the Nexus 7 I've got, because I don't know yet whether I can make it awesome enough. Trash-flood games ruined XBLIG and make finding worthwhile games on the iOS App Store and Google Play way harder than it should be. I won't contribute to the pile of crap.
I agree, there seems to be a bit of handwaving over whether this is something that is designed for existing android games or whether you are supposed to be developing new ones for this.
I'm not a games programmer , but I would certainly be interested in building a small simple game for this and having at least a demo ready for the console launch.
It's interesting that you mention LibGDX as something that could work well here. Let's say I want to build a game that is designed around joypad control would my best bet be to build a game with LibGDX using the lwjgl backend (for PC) and plug in an xbox pad to test the gameplay? What about testing performance?
Slightly OT: LibGDX seems to have relatively scant documentation in terms of examples of significant working code so it is difficult for me to think about how to best structure the code for the engine. Are there any books that cover this specific to LibGDX? I can't find any.
libgdx is extensively javadoc'd, but best-practices materials are pretty weak. It's something I'd like to contribute to at some point, but I'd like to get my own stuff going first.
The bigger issue right now, as far as libgdx on Ouya would be, is that libgdx doesn't support controllers yet. But badlogic (who also replied to you--he's the main dev behind libgdx) seems to have some ideas on that one. I wanted to start in on writing a gamepad extension to their input system last night, but pulling down a clone with git-svn took most of an hour and I ran out of time. =)
Yes, best practises were more what I was looking for especially since I'm a noob at gamedev. Having lots of code samples does help to address that however.
One thing I noticed when comparing libGDX to XNA was that the basic game framework that you can extend from in XNA has 2 "tick" methods in it's main class, update() and render() (or something to that effect). Also the Java library "slick2D" follows this convention. This makes it simple to seperate out rendering code from logic updating code.
LibGDX on the other hand only provides a render() method which confused me a little. Should my render() method be handling logic updates? Should it call another method that does, but check time deltas on each loop to decide whether it should run, or should game logic happen in it's own thread?
moat people put their logic updates in render, others have a separate thread. we don't want to force any architecure on anyone as libgdx is a framework, not an engine. this is getting way to off-topic. i suggest you register at our forums where you can get input from lots of knowledgeable people on such matters :)
we have an external svn reference in core to table layout, something git doesn't support. your best bet is to check out libgdx from svn to et the externals.
it definitely does build, otherwise jenkins would scream at me all the time :)
That's good to know, and I'm really trying not to look a gift horse in the mouth because libgdx is awesome, but you should probably know that saying "use SVN" is really close to saying "don't contribute to my project." libgdx is literally the only project I use that uses SVN and I almost didn't use it because SVN makes hacking on code viciously unpleasant.
Massive amount of edits on your end, not sure what i'm replying to. Glad the middlefinger was removed, i'm afraid i won't be availble for a SVN vs. Git war.
We have our reasons to use SVN for the time being, externals being one of them (git modules don't work for our setup), tooling support being another one. We are eager to give people commit rights, provided they follow a small set of rules.
This does not necessarily help you with your dev process of having lots of local changes that you throw away. But that's something git-svn should be able to solve.
Ping me via e-mail at contact at badlogicgames dot com.
If you're that upset about a perfectly functional SCM system, you're acting like a person who is 'visciously unpleasant' to deal with.
SVN is functional, simple, and it works.
If you're doing OSS contribution right, you'll spend far more time talking and coding than you'll spend poking at SCM, and you won't be maintaining a large fork or poor hacks that upstream doesn't want to merge.
My biggest fear is Ouya being anything other than another Android device that runs Android software. I'm terrified the company tries to create their own platform, rather than just creating a very solid reference hardware that'd be ideal for Android gaming.
The completely non-standard gamepad with display is a terrifying hint that Ouya is trying to do their own thing, not build a good solid ecosystem device.
Yeah, I went back and edited that--Android 4.0 does have gamepad support, but that doesn't mean it supports Ouya's and I want confirmation that it does, as well as details about a lot of other developer-specific stuff.
The Kickstarter feels very consumer-focused, which is great but they still need to have games to sell to people.
It raises the question of how this kind of project should be handled. Should they have developer docs ready before fundraising? In the end, that's what it would take to answer your questions.
I'm not taking a side on that, it's quite possible that the answer is "Yes, they should have that level of documentation ready."
Just thinking about what's best for this kind of Kickstarter.
I think it would help them avoid some common problems if they did have developer documentation prior to the kickstarter launch, that said though it wasn't clear from their page what they were seeking the funding for exactly, and that is where i decided I couldn't participate.
Either the funding is "to develop the platform and make it available for developers to write games" or "to get the platform we've developed into production so that games written for it will have a wide audience."
If its the former then there is a much bigger gamble here, they may not be able to make it compelling enough to actually be a competitive game platform. If its the latter then they should have the 'big' pieces in place software wise and the remainder might be just refinement. Reading their collateral and listening to their pitch I think it is more if A than it is B but I would love to hear differently.
I keep trying to remember the DirectX guy who created a company to make 'game develoment for the masses' and then faded away, damn my aging neurons.
This is the guy I was thinking about, and reading WildTanget's material it looks like Oouya should take its Kickstarter proceeds and buy WildTangent to get their Ad patent portfolio and a an implementation of their business model :-)
I think it's more of how far out the release date is, honestly.
If they were pitching this for, say, Q1 2014, this wouldn't be that much of a red flag. That's plenty of time to get a dev SDK out for developers to have enough time to make something.
However, with less than 9 months to launch, they absolutely need an SDK ready, unless they're serious about only getting ports of existing android games. A 6-9 month dev cycle is on the short side for most quality indie game releases, but it's very possible to get good games made in that time.
They're looking at what seems to be an early 2013 release. So, yes, I'd definitely say they need a decent level of developer documentation like-now.
I would bet that to a large extent this could be called a land-grab platform--"get in early or don't get in"--and that makes them particularly important to have well in advance.
When they have development resources that show me that they're taking developers seriously, I'll revisit it (and doing so is fairly cheap for me; I'm using the always-awesome libgdx, which has Android support already). But my initial experience has been pretty bad, and I'm questioning their competency right now to the point where I can't give them money.