Jump to content
Eternal Lands Official Forums
Entropy

Android client

Recommended Posts

Anyone here that would like to start a basic port of EL to Android?

First just the basic stuff, such as log in and chat/console, and then all kind of small improvements, maybe even a 2d map and stuff.

 

I would love to do it, but I don't know any Java (or any Android API).

Share this post


Link to post
Share on other sites

nice.

wish i had an android phone so i could help w/ testing... might get a new phone soon, if i do i'll let anyone developing such a client know.

Share this post


Link to post
Share on other sites

Interesting idea. I've not got an Android phone or tablet but would most likely go that route if I was in the market for a either. I have already downloaded the SDK for a bit of a play and have a virtual machine running it too. Were you thinking of an open source client that is a free download or of making a closed source one which might have a cost?

Share this post


Link to post
Share on other sites

I have an Android Phone (connected via USB in debug mode as I write this), SDK installed, wrote a book on Java, and have a basic understanding of the Android APIs... but I'm normally terribly time-constrained. Had even investigated OpenGL ES 1.0 some time ago; it COULD work well enough with devices slightly faster than the Motorola Droid (i.e., all those that came out in the last few months, and all future ones). Might even buy an Android tablet as soon as a good one comes out.

 

I cannot say I can take the lead, but I should be able to help if a small team can start working on this. We need convince Fedora that she needs not finish his MD thesis :P

Share this post


Link to post
Share on other sites

I had talked to Radu via pm about this before. There is a problem with the idea of a phone based client where if the phone was to directly connect to the server, it would probably need to keep sending keep alive packets aka heartbeats to the server unless there was a minor server adjustment. If the desktop client was modified to allow communication to the phone, it could keep the connection alive and talk with the phone when appropriate. Connecting to the server directly from the phone would probably eat up bandwidth on their data packages.

 

Not from that discussion, if you connect via a phone, should a person know if you are connected via a chat client or the real client? Would the game appear to have more online players than are REALLY online (not just chat client)?

 

I have the phone and no life else than weekends, but Eclipse is kicking my ass. It won't run for me at all. I am considering developing the next phase of my project (I have written something in python to help me keep track of who is online and compare stats of some people) from....ergh....Windows so that I can use the development kit and make it in the android Java. I hate Windows though.

 

I may end up using the MOTODEV Studio. It is a development studio made by Motorola for writing Android software. I have no idea how it will affect compatibility with non-motorola phones......and no luck there either.

Edited by nathanstenzel

Share this post


Link to post
Share on other sites
I had talked to Radu via pm about this before. There is a problem with the idea of a phone based client where if the phone was to directly connect to the server, it would probably need to keep sending keep alive packets aka heartbeats to the server unless there was a minor server adjustment. If the desktop client was modified to allow communication to the phone, it could keep the connection alive and talk with the phone when appropriate. Connecting to the server directly from the phone would probably eat up bandwidth on their data packages.

Maybe I'm missing something here, but what's the point of having a phone client, if you have to be connected to your desktop machine anyway? If you are talking a cable, I see no use for the phone. If you are talking a wireless connection, then it would be much better to modify the server, or maybe a service such as Learner's proxy which could send keep-alives to the server, while not requiring them on the client (=phone) side. Asking people to have their desktop machine always on and reachable from outside (hence, they would need a fixed IP and no firewall protection) is a little too much imo.

 

But apart from the technical issues, the point is that keep-alives are there for a reason: so that the server can know if something went wrong on the client side. Maybe their use could be reduced, but I don't think we can do without them entirely.

 

I have the phone and no life else than weekends, but Eclipse is kicking my ass. It won't run for me at all. I am considering developing the next phase of my project (I have written something in python to help me keep track of who is online and compare stats of some people) from....ergh....Windows so that I can use the development kit and make it in the android Java. I hate Windows though.

 

I may end up using the MOTODEV Studio. It is a development studio made by Motorola for writing Android software. I have no idea how it will affect compatibility with non-motorola phones......and no luck there either.

Eclipse has been working flawlessly here. It might take a while to setup, but I would rather standardize on that, rather than having to work in a distributed team with people using different development environments...

Share this post


Link to post
Share on other sites
I had talked to Radu via pm about this before. There is a problem with the idea of a phone based client where if the phone was to directly connect to the server, it would probably need to keep sending keep alive packets aka heartbeats to the server unless there was a minor server adjustment. If the desktop client was modified to allow communication to the phone, it could keep the connection alive and talk with the phone when appropriate. Connecting to the server directly from the phone would probably eat up bandwidth on their data packages.

Maybe I'm missing something here, but what's the point of having a phone client, if you have to be connected to your desktop machine anyway? If you are talking a cable, I see no use for the phone. If you are talking a wireless connection, then it would be much better to modify the server, or maybe a service such as Learner's proxy which could send keep-alives to the server, while not requiring them on the client (=phone) side. Asking people to have their desktop machine always on and reachable from outside (hence, they would need a fixed IP and no firewall protection) is a little too much imo.

 

But apart from the technical issues, the point is that keep-alives are there for a reason: so that the server can know if something went wrong on the client side. Maybe their use could be reduced, but I don't think we can do without them entirely.

 

I have the phone and no life else than weekends, but Eclipse is kicking my ass. It won't run for me at all. I am considering developing the next phase of my project (I have written something in python to help me keep track of who is online and compare stats of some people) from....ergh....Windows so that I can use the development kit and make it in the android Java. I hate Windows though.

 

I may end up using the MOTODEV Studio. It is a development studio made by Motorola for writing Android software. I have no idea how it will affect compatibility with non-motorola phones......and no luck there either.

Eclipse has been working flawlessly here. It might take a while to setup, but I would rather standardize on that, rather than having to work in a distributed team with people using different development environments...

My proxy service already sends one keep-alive in case the client is laggy to reduce the chance of getting dropped. Of course that means when you lose your connection, you actually stay in game a little bit longer then connecting directly to the server.

 

But, keep in mind that the keep alive packets don't happen very often and are very small, so it would take a long time for that to add up. Plus, anyone that's going to be using EL for chatting has better be prepared for a lot of traffic because of the non-chat traffic.

 

If an android chat only is built, we can always coordinate a way that by proxy can strip out unwanted packets for those clients to reduce data being sent to the client ... and that might even have to include #ignore, since all that is processed client side, so someone could run up your bill without you ever seeing any chat!

Share this post


Link to post
Share on other sites

Except for those with prepaid plans that are very bandwidth constrained, I think the EL bandwidth is not a problem, it's usually less than 1Kbps (except during fights and crowded places, or if on the market channel :P)

So that would be like 3.6MB/hour tops.

Share this post


Link to post
Share on other sites

I don't have an android device, but I guess I could start with a plain Java chat client if that would be any help (I can get the android SDK, but I 'm wondering how to test the code on a desktop...). It would mean I'd have to mess around on the test server with an unofficial client...

 

revi

Share this post


Link to post
Share on other sites

Sounds very interesting. I have a HTC hero that is running 2.1 and spent some time a while ago writing a Boulderdash clone (but time constraints mean that it is still unfinished). My knowledge of OpenGL is pitiful, but I think that a chat client could be developed pretty quickly. Android SDK really isn't that different to standard java until you start addressing the low-level parts of the device itself and once you've set up the application framework. I'll mull it over and if I can find the time will have a go at throwing something simple together.

 

 

Also - let's not forget that most (all?) android handsets have wireless lan built in so people won't necessarily be using their data plan...

Edited by funroll

Share this post


Link to post
Share on other sites
I don't have an android device, but I guess I could start with a plain Java chat client if that would be any help (I can get the android SDK, but I 'm wondering how to test the code on a desktop...). It would mean I'd have to mess around on the test server with an unofficial client...

 

revi

 

I can offer to help with the Java client, both developing and testing. I'll have to get an android device first though.

Share this post


Link to post
Share on other sites

If you go to http://developer.android.com/sdk/index.html you will find an android software development kit. It includes an emulator program.

 

I have also found out that http://download.cnet.com/C-To-Java-Convert...4-10080009.html has a windows based c to java converter. This can be used on the c2j program itself too. Using that, we could perhaps translate the entire client. The thing is, it would still only work on a pc. We would need to modify that java and use the tools in the android SDK to get it to work on an android. There are also issues with the amount of memory that the client would take up, so perhaps this paragraph is less useful than the first one.

Share this post


Link to post
Share on other sites

Another possibility is to use the NDK for android - someone has already ported SDL-1.2 to android using this, we may be able to do a simple port of the client with minimal (?) code changes.

Share this post


Link to post
Share on other sites
[...]

 

[...]

 

Thanks, guys. I didn't even think about using an emulator. SDL and c2j sounds good, too. I'll look into it later.

Share this post


Link to post
Share on other sites

Although this is a totally different way of doing it, I am testing out the Trismegitus bot project code on my phone right now. The trade abilities which I never finished are disabled for the test. Note that the Trismegitus bot project is a Python project. I use the SL4A (scripting language for android) app.

 

I think this has potential and I will use it or a rewrite of it as a prototype for an EL client.

 

It seems to work fine after a minor modification.

Edited by nathanstenzel

Share this post


Link to post
Share on other sites

Hi all,

 

i've downloaded the Android SDK and put together a "proof of concept" android EL "chat" client ...

Lot of things are hard coded and overall it's done to just work (not look nice etc :)) ... There are most probably bugs too, but i guess it's something to start with.

You can see a video of this running in emulator (yeah i don't have an android phone) [ >> here << ]

 

The eclipse project containing the sources can be downloaded from [ >> here << ]

 

In some parts of the code i was inspired (or used) by jelc project, so some credit goes also to people behind jelc...

I am still learning about android application lifecycles and stuff, so please take this only as a "first try" :whistle:

Share this post


Link to post
Share on other sites
Hi all,

 

i've downloaded the Android SDK and put together a "proof of concept" android EL "chat" client ...

Lot of things are hard coded and overall it's done to just work (not look nice etc :P) ... There are most probably bugs too, but i guess it's something to start with.

You can see a video of this running in emulator (yeah i don't have an android phone) [ >> here << ]

 

The eclipse project containing the sources can be downloaded from [ >> here << ]

 

In some parts of the code i was inspired (or used) by jelc project, so some credit goes also to people behind jelc...

I am still learning about android application lifecycles and stuff, so please take this only as a "first try" :P

If you post it on the app market, let me know the title and I will install it and test it.

Share this post


Link to post
Share on other sites
If you post it on the app market, let me know the title and I will install it and test it.

Ok, i'll compile end export it for 2.1 version.

Question is, what should the client do, when the application is paused/resumed ? (That happens for example when it loses focus)

Should it disconnect from server or not ? (currently it's connected all the time)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×