Android port

[Guest afeder]

So, I am not saying this would be easy by any means, but have any consideration gone into porting 0 A.D. to the Android platform?

Clearly, the UI would need to be rethought, but I have to say, mobile does seem like the future of gaming: I don't want to have to be chained to the PC to have fun. Also, it's very easy to market a game through Android Market - a 'donation version' could be made, giving generous users the option to pay a small sum for the download, thus creating a modest source of revenue for the project.

What I know, or think I know, about porting to Android is that it would probably involve using the Android NDK. Particularly, the game would probably have to use OpenGL ES for graphics, instead of whatever API it uses now, and OpenSL ES for audio.

What other complications you can think of?

Edited December 26, 2011 by afeder

[Arthur_D]

All sorts. I am not a programmer or contributor to this project, so I do not have anything to back up my claims. But personally, I believe an RTS game like 0 A.D. doesn't make sense for current and near-future mobile platforms. Besides, you would almost have to create a whole new game in order to get it going on e.g. a tablet. The maps and models would probably be too much to handle for the hardware, and even if you got that going, it would be a pain to get all the assorted libraries etc. working as expected.

Finally, I think if any Android port should happen, it should happen AFTER, not before, the first part of the game is finished. Splitting up development effort in order to do too much at once is what many projects have fallen victim to, and their development usually halts and possibly never reboots into something tangible.

As said, this is only my opinion, so don't take it too seriously.

[WhiteTreePaladin]

I think it could be a nice idea, but it will be several more years before it's remotely worth pursuing.

[Guest afeder]

All sorts. I am not a programmer or contributor to this project, so I do not have anything to back up my claims. But personally, I believe an RTS game like 0 A.D. doesn't make sense for current and near-future mobile platforms. Besides, you would almost have to create a whole new game in order to get it going on e.g. a tablet. The maps and models would probably be too much to handle for the hardware, and even if you got that going, it would be a pain to get all the assorted libraries etc. working as expected.

Finally, I think if any Android port should happen, it should happen AFTER, not before, the first part of the game is finished. Splitting up development effort in order to do too much at once is what many projects have fallen victim to, and their development usually halts and possibly never reboots into something tangible.

As said, this is only my opinion, so don't take it too seriously.

I think you are underestimating the power of modern mobile devices. I am literally able to play first-person shooters with fluid 3D graphics equivalent to approximately an anno 2005 desktop PC on my Galaxy Nexus:

I also wasn't suggesting a "split". I am suggesting a port, i.e. taking whatever is done for PC and adapting it to mobile - not the other way around.

[Ykkrosh]

The most time-consuming problem would probably be porting all the rendering code to work with OpenGL ES - I don't think that would be particularly difficult, but it's quite a lot of code to change. (I think we could support GLES 2.0+ and desktop GL with mostly shared code (just with some fallbacks for fixed-function hardware) so it doesn't need to be a fork - we could incrementally modernise the main codebase to support GLES.) Apart from that, I guess the main technical difficulties would be getting the build system and third-party libraries to work properly in the new environment.

I'd imagine the bigger problem is that a lot of the gameplay design is influenced by the mouse+keyboard UI system (e.g. we assume experienced players will use hotkeys, and we assume everyone can click precisely on small points on the screen, and we assume we can fill a 1024x768 screen with small text and players will be able to read it all), and those assumptions may not be valid on non-PC devices, so the gameplay design may work very poorly. It might make most sense to port the engine and then develop a new mobile-oriented gameplay mod (using the existing art and gameplay concepts but perhaps streamlining the game design in various ways), if someone wants to make a game that works well in that environment.

[gerbilOFdoom]

Perhaps not a full port, but a mobile add-on that lets a player manage some sort of "global conquest" mode outside of the RTS gameplay? My thought here is like Galactic Conquest from Star Wars Battlefront 2, maybe something like Tribal Wars in terms of functionality. People play the RTS portion of the game on PC, but manage an empire on their mobile device. Just a concept though, I don't have any specific ideas for what it could do at this time.

[historic_bruno]

I don't see what a mobile version of 0 A.D. would actually share with the standard desktop/laptop version. I mean the UI, gameplay, and art would need widespread changes to be practical for a mobile device (think bigger, "cuter", simpler, gimmicky) with totally different controls, obviously no keyboard shortcuts or mouse click selection. That means multiplayer between mobile and non-mobile devices wouldn't make sense either, so this idea doesn't make any sense to me at all. A first person shooter is not even remotely comparable, because let's face it, all you have to do is run around, point a gun at your enemies and shoot

[Guest afeder]

I don't see what a mobile version of 0 A.D. would actually share with the standard desktop/laptop version. I mean the UI, gameplay, and art would need widespread changes to be practical for a mobile device (think bigger, "cuter", simpler, gimmicky) with totally different controls, obviously no keyboard shortcuts or mouse click selection. That means multiplayer between mobile and non-mobile devices wouldn't make sense either, so this idea doesn't make any sense to me at all. A first person shooter is not even remotely comparable, because let's face it, all you have to do is run around, point a gun at your enemies and shoot

What it would share would be the main thrust of the game: the 3D engine, the gameplay mechanics, the models & textures and sound & music. The controls would be "totally different", yes, but that is to be expected - I don't see how it would exclude multiplayer between mobile and non-mobile devices?

The first person shooter comparision was to compare hardware capability. Actually, in many ways, FPS's are less suited for mobile than strategy games are, because FPS's generally challenge you on your reaction speed, which is often a bit handicapped on mobile. Though reaction speed is not unimportant in RTS, its main challenge is on strategic thinking and planning, which can sometimes be executed even more intuitively on a multitouch device than with just keyboard & mouse.

[Spahbod]

RTS games are designed especially for PC. Other platforms cannot support them because of the control problem. A failed example is Age of Empires Mobile. It was very hard to play and didn't end up in success.

[Guest afeder]

RTS games are designed especially for PC.

Says who? Comparisons with antiquated platforms like Pocket PC doesn't really apply.

[Almin]

@afeder: To be honest, but I also think that it is ways to difficult to create a port for mobile phones, just to show that it's possible(,-> which it not even is, in the case of 0 A.D.)! And even if it's possible there wouldn't be enough people maintaining this port, because there are just not many people who want to play such a game on an small (and weird) device, rather than on a big screen. But if you feel like you can do it, than no one will stop you. Likewise you can't expect the developers to help you. That's just how foss-development is working.

[historic_bruno]

What it would share would be the main thrust of the game: the 3D engine, the gameplay mechanics, the models & textures and sound & music. The controls would be "totally different", yes, but that is to be expected - I don't see how it would exclude multiplayer between mobile and non-mobile devices?

I don't believe you could keep the same gameplay mechanics or art, because it wouldn't be an effective mobile game IMO. Mobile games require a different paradigm, or at least the successful mobile games I can think of are very different. There are physical limits, the smaller screen limits what you can see with a glance and how big the "world" can be, and many of our models assume you can easily zoom in and out, rotate the camera, and that you're using a 1024x768 resolution or higher screen that's at least 15-17". We also assume you can read small text for tooltips and UI buttons, but if you remove those, you have to remove certain functionality that they represent. You could try for voice command and use the accelerometer control of the device (for camera movement), assuming those worked intuitively, there would still be visual limits. I believe the direction a mobile 0 A.D. would inevitably take is toward a quicker, less historically accurate, goofier, simpler game - at which point it's no longer 0 A.D. I just feel that even if I could play 0 A.D. today on a tablet, smartphone, or whatever, I wouldn't enjoy it. Still I'd be interested to see where such a project went.

[Guest afeder]

And even if it's possible there wouldn't be enough people maintaining this port, because there are just not many people who want to play such a game on an small (and weird) device, rather than on a big screen.

Well, this illustrates the misunderstanding perfectly. I am not asking anyone to choose between desktop OR mobile. It would be a port, meaning you would still be able to play desktop when it's practical. But in many, many situtations desktop is not practical - like if you're riding the bus and lugging around your laptop just isn't convienient. In those situations you currently have no options, regardless of how much you like big screens.

As for people not wanting to play on such devices, that is simply not true. Grand Theft Auto III, a ten years old PC game, was just released for iOS and Android on December 22. It has already been downloaded more than 100.000 times (at 2$ each) from Android Market alone. People are craving quality games for mobile.

[Almin]

Well, this illustrates the misunderstanding perfectly. I am not asking anyone to choose between desktop OR mobile. It would be a port, meaning you would still be able to play desktop when it's practical. But in many, many situtations desktop is not practical - like if you're riding the bus and lugging around your laptop just isn't convienient. In those situations you currently have no options, regardless of how much you like big screens.

As for people not wanting to play on such devices, that is simply not true. Grand Theft Auto III, a ten years old PC game, was just released for iOS and Android on December 22. It has already been downloaded more than 100.000 times (at 2$ each) from Android Market alone. People are craving quality games for mobile.

You really try to misunderstand me, right?

1st: There was not a second that I thought you would like to "kill" the desktop version and I understood quite well that you talked about a port.

2nd: I would like to know when playing a game like 0 A.D. is practical on a mobile device. And please don't misunderstand me, but I really would appreciate seeing the facial expressions of someone trying to play a rts like 0 A.D. on a smartphone or tablet.

3rd:

As for people not wanting to play on such devices, that is simply not true. Grand Theft Auto III, a ten years old PC game, was just released for iOS and Android on December 22. It has already been downloaded more than 100.000 times (at 2$ each) from Android Market alone. People are craving quality games for mobile.

Well, and there's no difference between GTA and 0 A.D.(Sorry, but this made me laugh). GTA is not an rts. What do you do in GTA? Right! You run around, steel some cars, kill some people. I think when it comes to First-Person-Shooters, historic_bruno already said everything needed so I don't have to repeat it. Furthermore, as you said yourself, the mobile version of GTA was sold, which means it was developed commercially. But 0 A.D. is foss and therefore nobody here pays a development studio to port 0 A.D.. I therefore don't know where you want to get the people porting the entire stuff. As Ykkrosh already mentioned the rendering must be done with OpenGL ES and you have to care about the build system and third-party libraries. I don't know whether you build 0 A.D. yourself, but I did so. To see how many third-party libraries and other stuff are needed you can look them up here: http://trac.wildfiregames.com/wiki/BuildInstructions#Linux

So for now I'm quite interested how one can solve all of those problems.

Edited December 28, 2011 by Almin

[Guest afeder]

You really try to misunderstand me, right?

1st: There was not a second that I thought you would like to "kill" the desktop version and I understood quite well that you talked about a port.

You might not, but that was what you wrote and that was what I responded to. I can't read your mind.

GTA is not an rts.

GTA is not an RPG or a turn-based strategy game either, but there's plenty of RPGs and turn-based strategy game for Android. It's quite silly to suggest that because a game of type X is popular on mobile devices then games of type Y won't be.

What I am interested in are the technical obstacles, rather than these superflous "it won't work because I don't like it" arguments.

Edited December 28, 2011 by afeder

[Almin]

You might not, but that was what you wrote and that was what I responded to. I can't read your mind.

GTA is not an RPG or a turn-based strategy game either, but there's plenty of RPGs and turn-based strategy game for Android. It's quite silly to suggest that because a game of type X is popular on mobile devices then games of type Y won't be.

What I am interested in are the technical obstacles, rather than these superflous "it won't work because I don't like it" arguments.

Sorry, I thought, I wrote that "I also think that it is ways to difficult to create a port for mobile phones", but however...

Besides the '"it won't work because I don't like it"-arguments' you asked for "the technical obstacles" and here is again what I also sent:

A link to the building page in the wiki including all the third-party-stuff you need to build the game:

http://trac.wildfiregames.com/wiki/BuildInstructions#Linux

GCC (at least 4.0, preferably 4.3 or later)

Subversion (or git if you want to use the Git mirror; see below)

SDL

Boost

zlib

libpng

libxml2

OpenGL

OpenAL

zip (needed by spidermonkey)

libogg

libvorbis

libcurl

Gamin (FAM should work too, but is considered deprecated)

CMake

To compile editing tools (enabled by default; pass the flag --disable-atlas to update-workspaces.sh to disable):

wxWidgets (packages are probably called wxgtk)

To use shared system libraries instead of bundled copies (default) of libraries (pass the flag --with-system-$COMPONENT to update-workspaces.sh to use the non-bundled copy):

ENet 1.3 (--with-system-enet)

NVTT (--with-system-nvtt)

SpiderMonkey 1.8.5 (--with-system-mozjs185)

What I don't know is whether all of that stuff exists (and works) for Android. Now, which other 'technical obstacles' do you need(,besides that I still can't imagine how a GUI on such a small screen that includes all 0 A.D.-functionality should look like)?

Edited December 28, 2011 by Almin

[Guest afeder]

Sorry, I thought, I wrote that "I also think that it is ways to difficult to create a port for mobile phones", but however...

Besides the '"it won't work because I don't like it"-arguments' you asked for "the technical obstacles" and here is again what I also sent:

A link to the building page in the wiki including all the third-party-stuff you need to build the game:

http://trac.wildfire...tructions#Linux

What I don't know is whether all of that stuff exists (and works) for Android. Now, which other 'technical obstacles' do you need(,besides that I still can't imagine how a GUI on such a small screen that includes all 0 A.D.-functionality should look like)?

I didn't ask for the '"it won't work because I don't like it"-arguments' Those are some you came up with.

As for the substance:

GCC - the Android NDK provides its own ndk-build for compiling.

Subversion - assuming this is just for obtaining the source, this can be done on a PC workstation.

SDL - is already ported to Android.

Boost - there is an unofficial port.

zlib - libz is part of the native NDK.

libpng - there's unofficial ports like this one.

libxml2 - Google publishes a tree that is tuned to compile on Android.

OpenGL - this must be ported to OpenGL ES.

OpenAL - this should be ported to OpenSL ES.

zip - not sure which exact library this refers to.

libogg - may be covered by Tremor (below).

libvorbis - this can be done with Tremor.

libcurl - may be ported like this.

Gamin - don't know about this one.

CMake - all build tools are provided by the NDK.

[Guest afeder]

I added the stuff that has been covered so far here.

[Almin]

Ah, yes! I didn't thought that that much of those packages already exist in some way on Android. This changes the picture a little bit for me.

Edited December 28, 2011 by Almin

[historic_bruno]

Don't forget NVTT, Spidermonkey, Enet and fcollada, which are bundled with the source and typically built along with the game. Though depending on how much modification is required, some dependencies could change (for instance, Fam/Gamin is used for monitoring file hotloading which doesn't seem as useful on an Android device).

[Guest afeder]

Don't forget NVTT, Spidermonkey, Enet and fcollada, which are bundled with the source and typically built along with the game. Though depending on how much modification is required, some dependencies could change (for instance, Fam/Gamin is used for monitoring file hotloading which doesn't seem as useful on an Android device).

NVTT - not sure about this one. what does it do?

Spidermonkey - can this be ported to Android's native V8 engine? if not, presumably Spidermonkey has been ported as part of Fennec.

Enet - from a quick check, I see no dependencies outside of libc, so this should compile natively.

fcollada - not sure. this might do it.

[Ykkrosh]

NVTT does DXTC/S3TC compression of textures at runtime. (We cache pre-compressed textures in releases, but support runtime compression for modders). We don't need any of its fancy features like CUDA support or image-loading tools, just the basic CPU-only compression library, so it should be buildable with no significant external dependencies (though its build system might need fixing).

We can't use V8 (we rely on some complex API features so porting would be a huge amount of work). SpiderMonkey isn't API-compatible or behaviour-compatible across versions, so it'd be best to use the same 1.8.5 release as we use on PCs if possible; I think the standard releases are meant to work on ARM so that should be okay.

We use a customised/bugfixed version of FCollada, so a port of the standard version of FCollada probably wouldn't work.

[Guest afeder]

We use a customised/bugfixed version of FCollada, so a port of the standard version of FCollada probably wouldn't work.

Does this customized version have any significant external dependencies?

[Ykkrosh]

No, just libxml2.

[quantumstate]

I was just looking through your wiki page, it looks interesting, I will be following development of this. I have a few comments about the controls, which I hope you will consider.

First with the map rotation, I think that rotation is a fairly low priority feature so I would suggest using the gesture for another role. I don't know what that would be but I suspect you will be wanting as many easily accessible gestures as you can get since rts games tend to have complicated interaction.

With your selection idea you mention drag select working in two different ways depending on whether the drag started on an entity or not. Having two distinct behaviors for the same action seems like an idea which is bound to cause annoyance, especially since units are probably going to be fairly small. I would definitely suggest choosing one of them and being consistent (I personally prefer box select). Another selection idea is to have a selection brush (see halo wars) where you swipe and everything near your stroke gets selected.

If you haven't already I would suggest taking a look at halo wars with its simplified console controls and the C&C series which had single button mouse controls.

For giving units commands I would have a single click do the units primary action (context sensitive, what the main game does on right click) and them have a held click bring up a circular action chooser again context specific, e.g. attack move, building construction, garrison. The problem with this is that you lose the selection controls. To get round this you would need an easily accessible clear selection command, this could be done with a simple gesture or having a dedicated button. This would be the most frequent action in the game so would need to be very quick.