- Google Nexus One
- Verizon Droid by Motorola
- HTC Magic (The myTouch in the US, HT-03A here in Japan)
- HTC Dream (The G1)
- Samsung Behold II
- Samsung Galaxy
- HTC Hero
- HTC Tattoo
- LG Eve
- ODROID
- Covia SmartQ5
- Android for x86
I don't have regular access to all this hardware to test on, so when a phone comes my way I jump on it, install the game, and try it out. Excepting basic support for multiple screen sizes and input systems, I don't have any device-specific code. I developed Replica Island almost entirely on Dream and Magic devices; it's built for a trackball and touch screen. I've added support for directional pads as well, which covers almost all of the phones on the market. The game runs at a nice frame rate on the Dream/Magic hardware, and it's very smooth on faster devices like the Nexus One and Droid. But that's it--no special case code for any particular device anywhere. Cool!
You might be interested in which of these devices plays Replica Island the best. The answer might surprise you. Wait for it... ok, it's the ODROID.
Yeah, seriously.
What the heck is the ODROID? Well, it's an Android device (not a phone) sold by a South Korean company called Hardkernel. Actually, the consumer version isn't even for sale yet, but you can buy test hardware for nebulous "development purposes" on their web site. The
My ODROID arrived in the mail yesterday, direct from South Korea. It's clearly prototype hardware; the thing is made out of light plastic and looks fairly cheap. There's a very strange power button that doubles as a hold switch and screen orientation switch, and I keep accidentally hitting the capacitive volume controls where I expect shoulder buttons to be. The directional pad is actually pretty bad compared to what you'd find on gaming hardware like the Nintendo DS or Playstation Portable, but it's better than your average phone. The thing can talk to adb, it came with an SD card already installed, and supporting the A/B/X/Y buttons is trivially easy (they just map to regular keyboard events).
But the reason that the ODROID is the best device for playing Replica Island isn't just because of the game-like form factor and controls. Unlike most other Android devices, the ODROID is a combination of fast CPU and medium resolution screen. The devices with larger screens tend to be fill-rate bound; though the Nexus One and Droid have extremely capable CPUs and GPUs, the high resolution screens on those devices work against them when it comes to games (it's almost impossible to break 30 fps on those devices via the GPU, though they can crunch really complex scenes at that speed without breaking a sweat). On the other hand, the Magic/Dream class of devices have the same HVGA resolution, but tend to be CPU bound--rendering is fast but I spend quite a lot of time running the game simulation. The ODROID has neither problem--its CPU is pretty fast and its GPU has no problem filling the HVGA display. As a result, Replica Island is silky smooth on the ODROD--a constant, reliable 60fps. Add that to the game-ready control scheme and you have a pretty great game experience.
That's part of what's so awesome about the run-everywhere Android approach. Replica Island works on all Android devices, pretty much by default. It's fun to play (well, I think it's pretty cool) on most average phones. But when some crazy company wants to make some crazy device that's good at one thing, they can do so without requiring any changes to the applications themselves. In this case, the ODROID is a surprisingly solid game device, at least for games like mine (though other games, particularly 3D games with complex scenes, are probably faster on devices like the Nexus One). And supporting it costs me literally nothing; I just loaded it up and it worked. That's pretty neat.
With all that said, will you be making Replica Island available to ODROID users (via SlideMe)? I know you don't speak for Google but I hoped they would have been more aggressive in putting the Android Market on devices.
ReplyDeleteI was wondering how you're going to resolve controller issues. Is it playable on Droid?
ReplyDelete> Andrex
ReplyDeleteGood question! Probably not, but not because I have anything against SlideMe or other markets. The issue is that maintaining builds across multiple locations (and sending out updates and things like that) is a pain, and none of the 3rd party markets have anywhere near enough users to make it worth while. And also, phones with SlideMe are, almost by definition, devices that are in some way incompatible. If they were compatible phones, they'd just have the regular Android Market. In some cases the degree of incompatibility is limited to areas of the phone that don't affect my application (e.g. in the ODROID's case, it's missing a camera and telephony hardware, neither of which affect Replica Island). But I can't support users on those kinds of devices because who knows what is wrong with them. The Covia device, for example, technically runs Android and can run Replica Island, but there's no way it (or any game, really) will ever work well on that device.
What I might do instead is just post a web link to the APK on this blog so that people with incompatible devices can download it and check it out.
> Maceij
I'm not sure what you mean; I have an input system that takes Android events, be they trackball, d-pad, keyboard, or whatever, and translates them into game buttons which are used throughout the code. It's pretty simple stuff. The Droid works fine (though it's a little strange to play with the keyboard slid out, as one hand has to he higher than the other). My d-pad path could use a little tuning (a point further enforced by some minor latency when playing on the ODROID and other d-pad devices), but generally, it's been pretty simple to translate Android input events into game events.
Hm, so replica island doesn't get above 30fps on the droid? That's what i expected from my own development experience. Given the nominal fillrate of the powervr chip that's kind of suprising to say the least. I have a parallax scrolled tile map renderer similar to the one you have in replica island. I'm not using the texture blit extension though but go with VBOs. I get around 40fps on the droid. Interestingly the G1/Hero/any device with a qualcom beats the crap out of the droid when it comes to drawing screen aligned quads. I forgot were i read it but the qualcom chips recognize screen aligned quads it seems and do a faster scaled blit operation. It was suprising to see that my hero ran at full 60fps while the droid struggled at around 40fps. Of course the comparison is not entirely fair due to the different native screen sizes, but still, i expected more. Going compatibility mode on the droid doesn't change the performance noticeably. Instead you get a nice blurry image due to upscaling.
ReplyDeleteI was hoping to find the holy grail in form of replica island's source code. That is, getting decent performance out of the droid. Now i'm even more pessimistic.
>Mario
ReplyDeleteReplica Island runs super fast on the Droid. It executes its whole game loop in about 1 ms, with another few ms in there for GL commands. But the hardware can't fill the screen that fast (there are quite a lot of them on that device: 800x480), so the whole thing gets knocked down to 30 fps. That's fine, though, because as long as the physics and input are fast (they are), the game is perfectly playable. If you draw with just the CPU you can probably get up above 30 fps (since the screen composite is part of the reason that fill time is slow), but I don't think it's worth it considering the number of other devices that are slower when using the CPU.
ya, from my experience the CPU bound code (physics, collision detection) runs pretty smooth on the droid. Maybe i'm an idiot and should have the time based movement code in a seperate thread along with the rest of the game logic. As of now i do everthing in the OpenGL rendering thread. I will try that, hopefully it works out.
ReplyDeleteBtw, concerning the 30fps you get: If you use alpha blending for your transparent tiles/sprites you might consider using alpha testing. That gets you a couple more fps.
> Mario
ReplyDeleteYou definitely want to break your game sim code out of your rendering thread. See the post from a few months ago here called "Rendering with Two Threads" for why.
Also RE your comment about alpha blending. Since the hardware is fill-bound (meaning it's the filling of the pixels on the screen that is taking time, rather than the rasterization of the 3D scene itself), the complexity of the scene actually has very little impact on the frame rate (until the scene becomes so complex that it starts to lengthen the entire frame, that is). I mean, I can render a black box with nothing else on the screen on the Droid and I'll still only hit 30 fps--that's because it's the filling of the pixels in that box, not the rendering of the scene, that is taking time. So no amount of scene simplification is going to help me here--30 fps is pretty much the cap. On the other hand, a significantly more complex scene can probably also be executed at 30 fps. You can see using my SpriteMethodTest app that there's very little speed difference between 1 sprite and 100 sprites on that hardware.
Thanks for all the information. I'll take everything you said into account. I'm well aware of the fill-rate issues on the droid. Having two threads (game loop, rendering) seems like a good idea I just. I still get stuttering for moving objects that are animated in the game loop thread (time based movement of course). However, the camera position is updated in the rendering thread (again time based) and that works out pretty well, all is smooth. I will check out your post on seperate threads.
ReplyDeleteThanks again and keep up the great work!
Regardless of code running across all machines, you have just said yourself that the mode of delivery isn't platform-agnostic. I'd call that fragmented, fragged, but definitely not fragmentawesome.
ReplyDelete> imaletu
ReplyDeleteSorry, you'll have to clarify what you mean. To me, having a single unified distribution system (which is Android Market--coverage is way over 90% of all devices in the world) that enforces standards, and being able to write code that runs across all machines sounds pretty freaking awesome to me.
@Chris: I know it's simple to translate input events, but I've got other concernes of a more organic matter, like: Does it feel right and natural to play on theese devices? Is it comfortable? Isn't it frustrating? And if not - what have you done to achieve it?
ReplyDelete> Maceij
ReplyDeleteI see, I misunderstood your question. Yes, control design is tough enough with one set of inputs, and the problem is certainly complicated by supporting multiple sets of inputs.
In my case, I am kind of lucky because I did my control work up-front with the trackball, which is a weird interface for this kind of game. Once the trackball was working, adding dpad support was fairly trivial; the trackball was a lot harder to get right.
That said, there are still problems to solve in this are. My dpad code, at the moment, sort of sucks. I have a burning desire to rewrite that part of my input system, which I will probably do before the game ships (it's dangerous at this point but there's a lot of unnecessary cruft in there right now). My design mandates that the input system hide the actual input method from the rest of the game. The game looks for buttons pressed and magnitudes of movement, but whether those get generated by a dpad or a trackball or a touch screen or the tilt sensors is all hidden behind the input system interface. So to add new interface types, I just need to make the input system smarter.
One thing I will probably do is allow some control customization in the options screen. For example, right now I have the jump button on the left side of the display because almost all devices have a trackball or dpad on the right. The Motorola Cliq, however, is an exception: it has its dpad on the left, which means you can't touch the screen buttons for jumping. I support the space key to jump, so the game isn't totally unplayable, but a better solution would be allowing the player to flip the controls. I may also allow the player to turn on and off certain controls, or maybe even flip the entire screen upside down.
99% of the world right now fits one form factor, and that's pretty easy to support. But I'd like the game to be playable on every crazy device that comes out, so I'm thinking about slightly more complicated customization options.
> Chris
ReplyDeleteWe agree that runs-anywhere is cool. But I'm trying to reconcile your pro-ODROID impression with the first few comments -- they asked for, and you declined to support a delivery mechanism (SlideMe) that they needed. That's fragmentation.
As for 90% of the market (I'll use your number, but I imagine it was a guesstimate), we had 90% market uniformity for a decade and change of the IBM-PC era. That still meant that the other 10% were left in the wilderness. That's fragmentation.
Don't get me wrong -- I'm not writing as an iphone fan or to be anti-android or anything. I'm just not willing to gloss over how locked-in OS's and platforms remain. Every platform (PC, smart phone or gaming) has a tin ear for this crap. Vendors restrict file browsing, lock out features for Verizon or AT&T or whoever, block peripherals, block data transfer, block scripting langs like Perl/Python/Java, take away desirable features (iphone vs. ipod for alarms, ringtones), restrict distribution channels, etc. And you overlooked it when it stared you in the face: someone (first comment!) asked you to support a delivery channel they needed, and you declined and didn't notice the irony. Outliers *ARE* fragmentation, aren't they?
I'm not disagreeing with your decision in any way, BTW. Just poking at how not-quite-awesome things really are.
> imaletu
ReplyDeleteMy definition of "fragmentation" in this case is "a scenario where devices diverge so significantly that supporting them all becomes a headache for developers." I think that your definition is something more like, "an unfair scenario in which Android Market isn't universally available."
Part of the reason to avoid third party markets because they represent a vector for fragmentation. Centralization around Android Market is an extremely strong unifying force within the Android ecosystem--it's the only real incentive that hardware manufactures have to keep their devices compatible (which, by the way, also requires that they leave them open).
I don't buy the argument that ignoring devices which, by definition, align to no standard (I've seen Android devices that don't even have a screen!) somehow contributes to an environment where developers have to worry about how their app will run on every single device. I said 90% of Android devices are compatible above, but I think it's more like 99%--the vast, vast majority of devices in users hands today are devices that passed Google's compatibility test and carry Android Market. I mean, the Covia SmartQ 5, which I mentioned in this article, has probably sold less than a thousand units total. We're not talking about a significant portion of the market here.
I think that you are arguing that the lack of third party markets somehow leads to fragmentation, maybe, because that means that some people will have more access to apps than others, or something. My response is, if a non-Market device actually managed to move enough units that supporting it was worth 10 or 15 minutes of my time, sure, I'd support it. Maybe the OPHONE is such a device? I don't know--at the moment the entire world is pretty standardized around Android Market, which is why I think your complaint is pretty weak. No developer needs to seriously worry about sales lost to users of non-Market devices.
I'm all for third party markets if they can gather tons of users. Until then, I'll just make my games available to everybody by posting them on the web (as I suggested in my first response) rather than via some third party distribution service.
Hey Chris. I just put up a post on the Duarlander blog after reading your post, and thinking about fragmentation a bit more. I'd love it if you took a look and gave me your thoughts.
ReplyDeletehttp://blog.duarlander.com/2010/02/lets-define-fragmentation-problem.html
Hey Chris. You mention which device plays Replica Island the best. It would also be interesting and useful for testing to know which of the devices, that are still suitable for gaming, is the slowest. (Not counting of course devices like Covia SmartQ5 which don't even have the proper inputs).
ReplyDeleteThanks for the great blog!
This comment has been removed by the author.
ReplyDelete> Cristian
ReplyDeleteActually, the experience is pretty similar across all the other devices. The LG Eve is probably the hardest to play on, simply because it doesn't really have a proper d-pad. That said, it has a slide-out keyboard, so if I supported keyboard controls it might be ok. My d-pad code is behind my trackball code, so d-pad-based devices feel a little worse, but that's not the device's fault at all.
I guess the game won't really be playable on devices like the Xperia which have no inputs other than the sensors and touch screen. Maybe in an update I should support an on-screen d-pad.
Oh, and the SmartQ5 is a pretty terrible experience all around, not just with my game.
(posted this twice as I neglected to mention that last part).
Chris,
ReplyDeleteI think you're right in that there seems to be a difference in nomenclature when talking about "fragmentation". I also agree that this is not a major issue -but then again, all other platforms (excluding the J2ME bases)at least have guidelines relating to 'limits' -addressed next. However, I would heavily disagree with you regarding ROM space not being a major issue; Knowing from the onset, that one has X amount of space for work allows us to work within 'the limits' -just like many do for DS games. Not knowing the limits, means design decisions are always in flux (or at least overshadowed) by possibility of your software not being installed/run. While size may not 1-1 equate product quality, or even market quantity, it does play a major role in platform choice from a design/planning perspective -for at least us small players.
*Looking forward to your GDC talk. Hope we might even meet up, as I'm just trying to get a better handle on Android as a gaming platform.
> Nathaniel,
ReplyDeleteI think your post belongs in comments section for the post about file sizes. But anyway, in response, I don't think I ever claimed that file size restrictions are a non-issue. I just took issue with the idea that the current file size limitations are somehow preventing "real games" from being ported to Android.
I would be happy to meet up at GDC! If not right after my talk, swing by during the Google Office Hour session (Thursday, I believe), and I'll be there.
Hi Chris, where can I find the source code?
ReplyDeleteChris,
ReplyDeleteLooking forward to the talk & conversation. While I know a bit of android coding (just a bit -why I'm at your talk), I've been working as a product manager & designer for a while now & I would like to get a better perspective on things. Hopefully I can get a few minutes of your time after the talk, as I'll be heading back to Ohio on Thursday...
(sorry for the section misspostings)
Hi Chris,
ReplyDeleteCould you comment on how you handle different screen resolutions? Are you letting the platform scale your graphics, or do you provide different graphics for different resolutions? What about camera code - do you take into account the screen resolution when deciding how much / when to scroll?
How much time and code have you had to spend to handle various screen resolutions?
> Anonymous
ReplyDeleteGoing from HVGA-only to supporting WVGA and QVGA (and pretty much any other screen size) took me about an hour.
My art is all HVGA-resolution, so I let OpenGL just scale up or scale down if the target screen size is different. To support multiple screen sizes, I switched my targetSdkVersion to 4 (Android 1.6), added some code that queries the screen size with the DisplayMetrics class, and fed that to my renderer. The renderer generates the appropriate view port and projection matrix, and applies a scale factor to everything that is drawn. That got everything drawing correctly, but parts of my game needed to know the size of the viewable game space (rather than the size of the screen), so I added a couple of new constants. And doing this exposed a bug in my background scrolling code math, which I fixed. So, all in all, about an hour worth of work.
I was partially lucky because I didn't hardcode screen size values in my game anywhere. There are some things in the game based on the size of the screen (like the camera code, and the code that calculates game object activity), and those just worked because no constants were hard coded.
One side-effect of this change was that the aspect ratio is slightly different on WVGA devices vs HVGA devices, so I let the camera show slightly more in the horizontal axis. This exposed a bug in one level that had been sized to exactly the HVGA width. I resized that level a bit to make it look better on bigger screens.
So yeah, I use scaling and it looks fine. It was super easy. The only place I supply a resolution-specific image is for the main menu.
Is a port for the Pandora possible ?
ReplyDeleteJens
I don't even know what that is!
ReplyDeleteBut if it's an Android device, it doesn't need a port--it should just run.
ODROID-T will be out soon. Try Replica Island on that too!
ReplyDeletehello friends how are you ?you can find here replica mobilesreplika telefonlar
ReplyDelete