Inactive Android / OUYA

[Cervator]

Name: Android support including the OUYA
Summary: Introduce a better structure for different front-ends to Terasology so it can be played with a "native feel" in different settings
Scope: Engine
Current Goal: Experiment with a project restructuring to isolate out front-end / wrapping / input code (computer application, browser applet, smart phone Android app, OUYA app). Also need LibGDX review
Phase: Design / Experimentation
Curator: Cervator is pushing it some but needs help. AbraCadaver is a coworker who has expressed interest, an ex-coworker also has a small mobile team that might get involved
Related: Lots - see below. More later.

So my OUYA dev kit arrived today




This is possibly a big deal to the project if we can get Terasology roughly working the same on different front-ends without doing a complete rewrite like it almost seems the MC pocket edition is, for example (I mean, seriously, 16-32 blocks, no crafting, no redstone, no mods, etc?). It is also a big deal to me personally as I sank $699 into the OUYA dev kit which includes a year of support, marketing, special badges, and what not after the official launch in March or so

Make no mistake though - that's a personal gamble and I'm not pushing or promising OUYA support at the project level! I'd certainly love to see it though and welcome any help in making it happen. From what initial research I've done it sounds like a good first step would be a healthy project tree restructuring to better serve Terasology in different formats - even without the OUYA this might be a good way to separate out the back+end from our primary application front-end and keeping the applet front-end stuff encapsulated as well. Mind you, this was some very preliminary research and I might have gotten the wrong idea.

On the 3d wizardry front LibGDX sounds like it has potential, and it is built on top of the same LWJGL we're using, so I'm hoping (wishfully, I'm sure!) that we could get there without massive rewrite stuff. Although I'm aware there are other things to worry about, with early review details from Immortius in

I'm going to try to find some time to play with the Nanoware organization on GitHub which I use to experiment with outright repo / organization topics on GitHub and see how things would look and work organized differently. At the same time as Android/OUYA stuff I also want to try the Jenkins approach to plugin management - each plugin/module/whatever actually lives in its own GitHub repo, which can be set up as simply as telling an IRC bot to please go make everything. Then add some Gradle magic to integrate with multiple Git repos in the same project and tadaa.

These two would go well together, IMHO, as they take major repo work and will cause crazy conflicts if there's a lot of outstanding code if/when it gets applied. Until then I'm going to see if we can push toward integrating in most the outstanding code and keep the source tree quiet for just a bit for major work like this (Checkstyle fixes would be another good thing to do at that time)

It's 1 am on a work night, going to get this posted and make more updates later. Let the rainbow ratings commence!

Related links / resources:

• Official site
• Official forums
• Dev portal
• OUYA Development Kit (ODK)
• ODK docs: site, GitHub
• Unofficial forums

 

[Skaldarnar]

Sounds promising
Is Ouya/Android mainly different in how to handle the graphics stuff and input handling? Or are there any other "language restrictions" we have to take care off?

 

[Cervator]

That's what you'd like to think at first, yes ..

But in reality you start running into other issues, like arbitrary memory limits (those may be tweaked favorably on OUYA where generally you'll only run one app a time compared to multi-app Android), library incompatibilities due to Android's not totally 100% straight up Java implementation, issues with more advanced facets of the language (annotations, bytecode manipulation, etc) and so on.

Exact details are up for further research. Each obstacle so far has been fairly easy to find material on workarounds for, but that still leaves the effort for implementing said workarounds in a sensible fashion

 

[MrBarsack]

Here some thoughts:

-Not just Android, iOS might also work:
"RoboVM" ... LibGDX is already working on support for RoboVM, so an iOS release might be possible. But there could be problems with licenses etc., iOS is to my knowledge not really nice for open source projects.

http://www.robovm.org/index.html

-Android: No support for android versions below 4.0:
Since version 3.0 "Render Script" is available. This could be used for fast computation, for example the map generation.

http://developer.android.com/guide/topics/renderscript/compute.html

Furthermore, it would save us trouble with users of old mobile phones. I think all smartphones with a dual core cpu already have >4.0.


Some more ideas maybe later... what do you think?

 

[Cervator]

Thanks for that RoboVM note, MrBarsack that would be pretty cool to see integrated with LibGDX, and makes the case even better to adopt support for that. I suspect it might be tricky to have all our fancy Java magic translate right, but hey, here's for hoping

Full agreement to use a later Android version if it helps. 2.2 I think was what I looked at as the absolute oldest, but by the time we have Android support (if ever) I suspect 4+ would be in a stronger position yet

 

[UberWaffe]

I'm trying to draw up MoSCoW requirements for all incubator threads (First test release, first playable release, full release). In an effort to help the contributors flesh out ideas and importance of features.
Would you like me to do so for this thread?

 

[Cervator]

Ohoho, this one would be fun as a MoSCoW - as I'm not even sure where we'd start

Might be premature until sometime after we restructure stuff to even make an Android support attempt feasible to begin on

 

[UberWaffe]

Oh, we'll give them a whack anyway.

--Compatibility requirements--

Spoiler

MUST:

• Isolate out Terasology GUI front-end
• Isolate out Terasology wrapping
• Isolate out Terasology user input code
• Have Terasology project distributable as a computer application

SHOULD:

• Have Terasology project distributable as a browser applet
• Have Terasology project distributable as a smart phone Android app
• Have Terasology project distributable as a OUYA app

COULD:

• [?] Have Terasology project support a server/client approach

WOULD LIKE TO:

• N/A

Sidenote on MoSCoW:

Spoiler

[+] Means a new requirement.
[-] Means a requirement was removed.
[~] Means the requirement was slightly changed (or just reworded).
[?] Means the requirement is undecided, and requires debate/revision.
An requirement changing priorities would be shown as a [-] on the old priority, and a [+] in the new priority.

From what I can gather a server/client approach is implied. Should the server part also be compatible with multiple platforms?
Or should the server code also be capable of running on any platform?

I would venture a guess that making most of the other platforms simply connect to a server running on a computer platform would be easier to implement that allowing the server code to run everywhere, regardless of lack of/support of multi-threading, multiple apps, etc.

 

[Cervator]

Interesting thought on the server bit - actually hadn't thought about that on Android/OUYA. Certainly would need to be able to launch the game in client-only mode, but I'm honestly not sure how two people on Android would play together.

If we can use the same engine everywhere (which would be ideal but maybe tricky to pull off) I'd think Androids could connect to a PC server, but a server on Android? Hmm. Would be tricky for sure to run two things on the same Android

Maybe when we get there (which won't be any time soon, heh) we can consider a lighter less cheating-secure option like a peer-to-peer mode without a central server. Same approach could be used on the OUYA to support up to four users via split-screen. As long as the limitations are pointed out to the users and central server on PC is supported as a better alternative maybe that'll be good enough.

It sounds like the options for MC on mobile are pretty limited as is.

 

[UberWaffe]

Interesting thought on the server bit - actually hadn't thought about that on Android/OUYA. Certainly would need to be able to launch the game in client-only mode, but I'm honestly not sure how two people on Android would play together.

Well, I've seen several MMO games for android. And the base rule is you need to connect to the server to do anything, as the android app is essentially just the client (GUI side of things).
Then two people on android can play together, as long as they connect to the same server.

If down the line the server (engine) part of Terasology can also be run on android, then a player can run both server and client on android and play a local (no-internet-required) game.

Maybe when we get there (which won't be any time soon, heh) we can consider a lighter less cheating-secure option like a peer-to-peer mode without a central server. Same approach could be used on the OUYA to support up to four users via split-screen. As long as the limitations are pointed out to the users and central server on PC is supported as a better alternative maybe that'll be good enough.

I've always felt that the best defense against cheating is to not play with cheaters.

A good system of public ban-lists and easy to configure personal ban lists would probably help servers more than built-in code trying to decide what is cheating and what is not (especially given the engine aims at being a platform for various modules that could theoretically be doing anything).

Off-Topic

Spoiler

In fact, having a mixed server-client & peer-to-peer approach might be worth thinking about.
If someone is off on their own on the other side of the game world, why not let them run the simulation for their used chunks and then just synchronize the results (from time to time and/or upon conditions) to the server.
A "Oh, Mrs. Server? There is now a giant crater at +200000 +50000 +0; I've got 500 sticks of dynamite less; and I also now have this bucketload full of random blocks in my inventory." approach.

 

[Immortius]

From what I can gather a server/client approach is implied. Should the server part also be compatible with multiple platforms?
Or should the server code also be capable of running on any platform?

I would venture a guess that making most of the other platforms simply connect to a server running on a computer platform would be easier to implement that allowing the server code to run everywhere, regardless of lack of/support of multi-threading, multiple apps, etc.

Yes, Terasology uses a server/client model. But not in the way you imply. Terasology is 95% shared core, with only a slither of logic for either client or server handling. Splitting out a separate server or client doesn't make any sense as a result of this - it would be more a matter of being able to run Terasology in headless mode (no graphics, audio or input) for a dedicated server, and normal mode to run a single player game, client or listen server. Players basically need to be able to run a server to play single player anyway, single player just doesn't let other players join.

Whether it makes sense to run a server on an android device, not sure. There's nothing about the server code that would preclude it though. Bigger issues are having input/audio and rendering compatible with android, and dealing

Multiplayer should be compatible across platforms.

Incidentally terasology simply won't work without multithreading, regardless of whether you are a client or server or what.

So basically my MoSCoW would be more like:

MUST:

• Centralise rendering implementation, minimizing exposure to raw OpenGL.
• Change asset system to allow the same asset with system dependent implementation (so OpenGLTexture or LibgdxTexture)
• Add Libgdx renderer (possible replacing the old one).
• Add Libgdx audio system
• Have Null renderer and Null audio system
• Implement touch screen based input

SHOULD:

• Have Terasology project distributable as a smart phone Android app
• Have Terasology project distributable as a OUYA app

 

[UberWaffe]

Awesome! Thanks!