I am creating a simple android game that deals with multiplayer and connecting to server. This is what I want to achieve for my game.
Client sends keystroke movement to server.
Server accepts input, update the state and calculates and returns new position to client
Client gets new position and update the screen.
I already have some code written and so my one of my threads sends keystroke to server, waits for the new position, then update the screen. The thing is there is lag between the player's movement. I think it has to do with latency. I also tried two thread, one for sending/receiving data from server and another is updating the screen. But it didnt' solve my latency problem.
Can anyone suggest a good design for networking game?
Do I need to do early prediction?
Do I need separate thread for fetching data and rendering screen?
P.S.This is my first time creating a network game so i have no idea what im doing.
The structure I prefer to use is to have one thread updating graphics and logic on the client side, and then one thread receiving and sending data to the server. If you have problems with latency, there is a magic option which might solve it if you want data to be sent continously. (at least this is the syntax if you are using java)
mySocket.setTcpNoDelay(true);
This option solved my latency issues when I sent real-time coordinates over a network.
Edit: I think TCP by default waits and bunches together data before sending it, which could be a problem if you want to send small updates fast.
Related
I am currently working on a small scale project to prove something works, I currently have a smart band device which has an Android SDK.
From this device I use the SDK to track a users heart rate in real time.
So my Android application receives updates to the heart rate in real time.
This was fairly easy to do however I now need to send this data in real time from the Android device to the server as efficiently as possible.
To start with battery drain is OK as initially this is just a proof of concept.
I have limited experience with sending large amounts of data to a server in real time and I was wondering if anyone has an ideas on what might be the best approach on Android?
I have looked into Sync Adapters but these seem to be more about keeping data aligned between the client and the server, this is something I am not concerned about. Another approach would be to see if the RequestQueue from Volley might work but again I am unsure if looking into this is even worthwhile?
Should I be looking into creating a Service and somehow using a socket to transfer the data?
EDIT: It looks like IntentService may be the best option for handling the task execution but I am assuming http requests would be too heavy for the client and I should look into something else for the transfer?
I am working on similar kind of project but the wrist band I am dealing with is Empatica E4. Please bear in mind that I am not an expert developer, therefore I am also looking forward for corrections in my design. Also, I will try to justify my idea step-by-step and as much as I can. I hope that this will give you some hints for your application and help others as well.
So, my current architecture looks like;
First of all, Empatica has also provided an Android SDK to receive the data. SF stands for Sampling Frequency whereas EDA, Temp, BVP and AccXYZ are my sensors in wrist band. Each sensor has different sampling frequency and the maximum is 64 Hz which gives you 15 ms interval between each samples. This interval is quite challenging to perform all the operations, therefore I buffer the sensors data in (Volatile LinkedBlockingQueue) FIFO queue so that I don't miss any sample. This was all happening in the service of my application.
Now, I have a Runnable task that I have used with ScheduledExecutorService to collects samples from the queue with the interval of 250 ms (you can vary it as per your need but I used 250 ms considering my needs, network latency and the device performance) and put them in a single JSON object. Number of samples that this Runnable task collects are varying for each sensor, which are, BVP: 16 samples, AccXYZ: 8 samples, Temp: 1 sample and EDA: 1 sample. At the output, I have a JSON object with the data to be sent to my server.
For transferring data to my server, I am using HTTP POST request. The reasons are easy, fast, efficient and good for concurrency. I am using Volley framework which will handle all my network related issues by itself. So I just add the JSON object in the Volley RequestQueue and my client is done here. As you mentioned, you can use socket connection to achieve your goal but I have to use multiple devices, therefore in my case, sockets can be problematic to achieve concurrency. I also tried to do it manually by using HttpURLConnection but the code was becoming tedious and hard to handle.
Finally, I have a REST API (in Python) on my server side which will handle the POST requests, parse the data and insert it in my MySQL database. As of now, I am still working on this REST API to parse the data and store it in DB. However, I have tested my application and I am successfully receiving the data from my device to the server.
Regarding your question "Should I be looking into creating a Service and somehow using a socket to transfer the data?", it's an excellent option if you are working on a single device. If more than one device, i think Http is better option.
Regarding your second question, I don't think Http would be heavy for the client and Volley is taking all your pain on itself. You just have to make a request queue and voila !!! You can find plenty of good tutorials for volley and I particularly followed this.
I hope my answer will help you a little.
PS: As I am still working on this thing and I have not come up with the final product yet, therefore I cannot surely tell about the risks involved in it but I will keep you updated if something new happens. Also, I am open to any suggestions and ideas that can help. Lastly, the picture above is not very detailed, I made it for you, just to share how I am dealing with the same idea.
I'm building a new Android game, it is intended to be real time multiplayer, similar to clash of clans but real time and synchronous battles.
Which tools or algorithms used Imperium (FX game) to implement those real time battles? There isn't any lag and there is a lot of info to transfer between clients, for example the life and coordinates of 2000 soldiers, the damage they are do or receive (it is random) and so on..
I was thinking on make a listener somewhere on a server, then delegate the "server job" to one of the clients, and this one should be updating itself and the other client but, is it going to be fast enough not to notice lag if the connection is made with sockets?
I found some libraries so if any1 had the same question they can research here:
https://nextpeer.atlassian.net/wiki/display/NS/Android+Advanced+Integration+Guide
http://swarmconnect.com/admin/docs/libgdx
Synchronizing game sprites over network in XNA
I'm building a program which interfaces with a device which runs its own internal web server. I communicate with the device via a web API.
Basically what happens is that a GUI is presented to the user, where the user can make certain modifications to the device. These changes are communicated to the device, and results are returned through XML. The device needs to converse with the program in the background more or less continually (say every 15s or so) to update certain values to the user.
My structure that I'm envisioning is something like this:
UI - Main - Networking - XML Parser.
I'm looking for advice on how to manage these. I understand the UI thread should be separate to provide a smooth experience to users. I also understand that the networking should be at least an asynchronous task. I'm not so sure about how to handle their interaction, and make sure things are happening smoothly and effectively.
My idea is that Main will handle passing data around, telling the networker to send specific messages or changes, passing the returned XML to the parser, and then passing the parsed values to UI for handling.
I'm curious though for advice beyond that.
Have a look at creating a service that is created with your Activity. Without knowing the details of your plan, a Service looks like the optimal solution to perform all the heavy work.
UPDATE:
You could have the calls to web API run in a Service and, when needed, update the UI through an interface. You would have to instruct the Service to run on its own thread, so thread safety is an issue, but less trouble in the long run than using an AsyncTask.
Have a thought about using Google C2DM.
In your case,
Pros -> Less battery use, coordinated network traffic, Don't have to run a continues service and doesn't have the potential of being killed when the device runs out of resources.
Cons -> You have to post the results manually back to your internal server, and server should know which request the device is replying to. Communication is disconnected and may not be real-time. Requires a google account on the device and Google market.
I need to make for school an app that runs on Android. Actually there are two apps, a client and a server. Ther server runs on a PC while the clients run on Android devices. I want to know what is the best technology for this. I know RMI and WebServices are not implemented in Android so what are the alternatives (besides actually communicating with sockets in the traditional way). One alternative that I did not look into is REST, but I will need to be able to notify a client once another client has done something, similar to turn base games where Player A notifies Player B that he made his move.
Like I said, sockets do the trick, but are little low-level compared to RMI and WebServices and only want to use those as a last resort.
Keep it simple. Use REST and have the clients poll for updates.
Also, if you get to a point down the road where you need to scale, this solution is actually fairly easy to scale because your servers do not need to maintain connections. Since there is no shared state between a particular server and the client (there is shared server between the application and the client), you can easily add more servers to handle the polling and put them behind a load balancer.
You can also add in caching so that the polling just gets the exact same response without causing a re-compute of the response. You would then be able to have the back-end game-state servers update the caches when the game state changes. This would let you poll much more frequently and still have a very flexible, scalable architecture.
For a turn-based game you can take a look at XMPP (e.g. Smack) that is traditionally used for instant messaging. It would also be interesting to create a game using C2DM that is used for push notifications.
You can also look into HTTP streaming which is essentially an unending HTTP response in which player moves are fed into.
Alternatively you can look into binary messaging systems that are more suited for real-time games but still applicable such as RabbitMQ (what's wrong with a smooth turn-based game?).
New to stackoverflow, been very helpful searching, but alas the time has come to ask a question.
I am trying to use an android 2.2 single core phone to do some research. I have implemented an algorithm that does quite a few calculations and produces a lot of data. These data must be processed, and the solution presented back to a client app within a 40ms time frame, then process again with new state data coming from the client. Also, the result of the calculations must be stored to the SD card as a data log. So being new to multithreading and android both, what should I use to do the following in my app: (As a side note, this phone, when in research mode is not intended to be used as a phone, phone will be in airplane mode with wireless off, and all apps that can be turned off will be turned off, and there is no need for UI display or interaction once it is up and running...)
need to process packets coming in over adb on serial port, these packets are state data that the program needs to perform its calcs on. These packets will be coming every 40ms, so I planned on using their arrival to trigger the start of the processing.
need to know if the algorithm is taking longer than 40ms and cancel it if so and send a message back on the serial port that it overran.
the calculation results need to be sent back over the serial connection via tcp and adb
The calculation intermediate data need to be recorded to SD. This can be quite a lot of data, on order of 140k, every 40ms.
So I have had trouble getting all the pieces together. I can't get my head around how a single core is going to keep up with all this going on at once?
So here is my thought, please tell me if I am headed in the right path. I am not asking for you to solve my problem, only any advice on how to break this beast down:
So i start a service to process the tcp packets coming in from the client
Use a service bound to the main worker thread to handle writes to the SD card
So assuming this setup, can i make the algorithm part of this somewhat deterministic so that it always runs if it gets a new tcp packet, and preempts the SD write going on in the background?
Argh...should have picked something simpler for my first program
Thanks.
Yes I think you are right, that it would be better to pick something easier for your first App ;)
But as far as I understand what you are trying to do, I don't think, that you need asynchronous multiprocessing. You get some data want to process it and pass a result. I think a HandlerThread is exactly what you are looking for. It is able to recieve Messages
with data inside. You send them to the Handler and process them in an overridden handleMessage(Message m) method. So everytime you recive a Message you could just log the Time
and see if the last one is older than your limit. If it is, you could just throw the Message or the whole queue, or send a Message to your serial-port inicating the overflow.
This could be implemented as you suggest in a Service. Another HandlerThread can be started with Thread.PRIORITY_BACKGROUND to write everything to SD.
You can send Messages even very compfortable if you apply a Messenger to the Handlers