I'm currently developing a Real-Time Multiplayer top down shooter.
The Multiplayer is "working" and I'm currently struggling with pushing the player updates such as position and fired shots.
My first try was using the service "appWarp" which worked perfectly but isn't free and only provided around 2 Million Messages in the free version which i completely filled in around 2 weeks with only 2 devices and 2 players. ( Maybe way to much updates send )
Then I implemented Google Play Game Services and tried using this to send the updates:
I'm able to use "sendUnreliableMessage" for Position updates, which works faster than appWarp used to. I use interpolation to get over the package loss issue here which works alright.
But here the problem is with firing shots. The nature of UnreliableMessages is that packages can get lost, which happens a lot. Shooting 4 times only makes around 1 or 2 of them appear on the other device. Which means that 2 packages are getting lost. Using "sendRealiableMessage" i can achieve around 2-3 packages getting through but with, of course a higher latency. Which makes the shots appear after around 1 second on the other device.
For a fast paced real time multiplayer game this is not what i wanted to achieve.
So what is a better way to do this ? I found web based solutions like socket.io but don't really know which fits the best for my needs.
I found this website which contains a big list of every web based solution for this problem but don't really know where to start.
https://www.leggetter.co.uk/real-time-web-technologies-guide/#_hosted-realtime-services
I am really really thankful if someone could help me with this problem!.
Since you're asking for opinion, I can suggest you try Multiplayer in Unity. It is the leading game engine as of today, so you can expect a huge support from a stupendous user-base.
Another option would be Photon. Hope these suggestions helps.
Related
Skip the first two paragraphs if your not interested in why I'm asking this question.
Here is the situation: I'm using a Moto Z Play with the Projector Modification, the mod is really cool and allows me to literally project my phone screen onto the wall. I've been writing a personal assistant program that helps me with my daily life I.E. Sorting gmails, reminding me of calendar events, keeping track of anything I want it to remember and reminding me of those things when I've asked it to, and much more. Its basically a personal secretary.
One new feature I just added was a habit tracker. I created a small graphical interface on my phone using Tasker that would email my "assistant" who would then record the habit and create a really cool graph that shows my past habit record as well as using a neural network to predict the next days habit. Only problem is, the graph got really intricate really fast. I want to show a months worth of habits (16 total habits), creating what can be up to a 16 x 31 floating point graph with labels. My laptop screen is just not big enough to display all of that without it just being a mess! I really want to display the graph from my projector mod, the entire wall will definitely be big enough to show all that data.
Ok, now my question (thanks for hanging in there I know that was a lot):
Is there any way that I can display an image on my phone from a Python program without creating a standalone app? Even if my phone needs to be plugged into my computer to stream the data through a cable.
I would use a service like Kivy to create a standalone app, but then it wouldn't be hooked up to my assistant, completely defeating the purpose.
I'm not looking for anything similar to a notification, I really want to draw over the entire screen of my phone. This is something I did with Processing (Java library) a while back, but now I'm using Python because it's more machine learning friendly.
I've looked into a lot of services but nothing seems to be able to do this. Remember that I dont need to send anything back from my phone, simply display an image on the screen until the desktop side program tells it to stop.
Not my expertise but if I would need to do something like that I would make a web-service of the python app using django and go to the url with my phone. Don't know if it help....
Regardless of "how" or "what", the answer is, you will always need some software running on the Android to capture the stream of data (images) and display it in the screen.
The point is, you don't have to write this software yourself. The obvious example that come to mind is use any DLNA compatible software, VLC for example, and have your python to generate a h264 stream and point VLC to it. Another way would be use some http service from your python and simply load it in the browser.
hope it helps.
So I am working with a quiz game in android where you are supposed to be two players playing against each other on different devices.
I am trying to figure out how the correct way is to set up the server communication to the devices. I want both devices to know when both players has given their answers to a question so they can receive the game result.
My first thought was that both devices will repeatedly ask the server if the other device is finished so they can have the game result. But I start thinking this is a bad idea as it will cause a lot of unnecessary traffic and probably some background performance.
So what is the correct way of doing this?
The Google Android way of doing this would be using Google Cloud Messaging (GCM.) This approach is battery & processor efficient, supports broadcasting up to 1000 users at once and has built in functionality for outdated/expired messages.
http://developer.android.com/training/cloudsync/gcm.html
Of course there are other ways of communicating that may be correct/right/valid but this approach is the best for your specified requirement.
I want to create multiplayer 2D top-view race game for 2-4 players. For multiplayer this game will use Google Play game services. Players will move their cars by roration device (accelerometer). This data I will send to all participant in room. Its realtime and this type of game needs, as exact as possible, positions and angle of cars for smooth animations, checking for objects collisions, display positions, etc …, so game must refresh fast enough to be smooth and work with given data.
Google Play game services multiplayer messaging has 2 concepts of exchanging game data between clients:
Sending real time message - Reliable (max 50 messages/sec) and Unreliable
Socket-based
Which concept I shoud use for exchanging players data?
I'm doing something like this too and my plan is to build a prototype with Reliable Messaging first and see how that goes. If the latency turns out to be an issue, I'll then step down to Unreliable Messaging, and then if it's really not working out, Socket-based. As with any software project, having a good architecture will allow you to switch protocols relatively painlessly.
Also, there won't be any wasted work by implementing Reliable Messaging and then switching to Unreliable, since the programming required for Reliable Messaging is prerequisite for Unreliable Messaging.
It'll be nice too if someone with experience could answer this question right off the bat with what will and what won't work.
I'm in the process of developing an almost exactly identical game as you've described for my university project. We use AndEngine as the game engine.
We decided to go for Unreliable Messaging because we read that for quickly-updating games like shooters or racing games it's better to use a UDP-like protocol.
We've had 2 approaches:
broadcasting my car's position to all other users - fairly straightforward and reliable, however with ~30 updates per second still not smooth enough,
broadcasting my car's speed and direction whenever there's any change - very smooth results, however with Unreliable Messaging if any packet gets lost it turns out after some time that the position of the same car is different on different users' devices.
I would really like to upvote the issue and ask someone with experience in the matter to contribute :)
I'm developing an engine and a game at the same time in C++ and I'm using box2D for the physics back end. I'm testing on different android devices and on 2 out of 3 devices, the game runs fine and so do the physics. However, on my galaxy tab 10.1 I'm sporadically getting a sort of "stutter". Here is a youtube video demonstrating:
http://www.youtube.com/watch?v=DSbd8vX9FC0
The first device the game is running on is an Xperia Play... the second device is a Galaxy Tab 10.1. Needless to say the Galaxy tab has much better hardware than the Xperia Play, yet Box2D is lagging at random intervals for random lengths of time. The code for both machines is exactly the same. Also, the rest of the engine/game is not actually lagging. The entire time, it's running at solid 60 fps. So this "stuttering" seems to be some kind of delay or glitch in actually reading values from box2D.
The sprites you see moving check to see if they have an attached physical body at render time and set their positional values based on the world position of the physical body. So it seems to be in this specific process that box2D is seemingly out of sync with the rest of the application. Quite odd. I realize it's a long shot but I figured I'd post it here anyway to see if anyone had ideas... since I'm totally stumped. Thanks for any input in advance!
Oh, P.S. I am using a fixed time step since that seems to be the most commonly suggested solution for things like this. I moved to a fixed time step while developing this on my desktop, I ran into a similar issue just more severe and the fixed step was the solution. Also like I said the game is running steady at 60 fps, which is controlled by a low latency timer so I doubt simple lag is the issue. Thanks again!
As I mentioned in the comments here, this came down to being a timer resolution issue. I was using a timer class which was supposed to access the highest resolution system timer, cross platform. Everything worked great, except when it came to Android, some versions worked and some versions it did not. The galaxy tab 10.1 was one such case.
I ended up re-writing my getSystemTime() method to use a new addition to C++11 called std::chrono::high_resolution_clock. This also worked great (everywhere but Android)... except it has yet to be implemented in any NDK for android. It is supposed to be implemented in version 5 of the crystax NDK R7, which at the time of this post is 80% complete.
I did some research into various methods of accessing the system time or something by which I could base a reliable timer on the NDK side, but what it comes down to is that these various methods are not supported on all platforms. I've went through the painful process of writing my own engine from scratch simply so that I could support every version of android, so betting on methods that are inconsistently implemented is nonsensical.
The only sensible solution for anyone facing this problem, in my opinion, is to simply abandon the idea of implementing such code on the NDK side. I'm going to do this on the Java end instead, since thus far in all my tests this has been sufficiently reliable across all devices that I've tested on. More on that here:
http://www.codeproject.com/Articles/189515/Androng-a-Pong-clone-for-Android#Gettinghigh-resolutiontimingfromAndroid7
Update
I have now implemented my proposed solution, to do timing on the java side and it has worked. I also discovered that handling any relatively large number, regardless of data type (a number such as the nano seconds from calling the monotonic clock) in the NDK side also results in serious lagging on some versions of android. As such I've optimized this as much as possible by passing around a pointer to the system time, to ensure we're not passing-by-copy.
One last thing too, my statement that calling the monotonic clock from the NDK side is unreliable is however, it would seem, false. From the Android docks on System.nanoTime(),
...and System.nanoTime(). This clock is guaranteed to be monotonic,
and is the recommended basis for the general purpose interval timing
of user interface events, performance measurements, and anything else
that does not need to measure elapsed time during device sleep.
So it would seem, if this can be trusted, that calling the clock is reliable, but as mentioned there are other issues that then arise, like handling allocating and dumping the massive number that results which alone nearly cut my framerate in half on the Galaxy Tab 10.1 with Android 3.2. Ultimate conclusion: supporting all android devices equally is either damn near or flat out impossible and using native code seems to make it worse.
I am very new to game development, and you seem a lot more experienced and it may be silly to ask, but are you using delta time to update your world? Altough you say you have a constant frame rate of 60 fps, maybe your frame counter calculates something wrong, and you should use delta time to skip some frames when the FPS is low, or your world seem to "stay behind". I am pretty sure that you are familiar with this, but I think a good example is here : DeltaTimeExample altough it is a C implementation. If you need I can paste some code from my Android Projects of how I use delta time, that I've developed following this book : Beginning Android Games.
I'm interested in using Android for a E-Ink
based platform. I know it has been demonstrated once by MOTO, but I'm interested in using it for a commercial grade product and not 'just' a technology demo. I have got a question on the ability to change the platform to cope with specific display effect caused by E-Ink. I'm asking this question from the role of system architect and have no prior experience with Android.
E-ink has several characteristics which are very different than the common LCD displays:
time to update display (50-700ms)
it costs power to change the display (none to maintain)
display life time is determined by number of display updates!
tradeoffs can be made between quality, performance and display lifetime
grayscale versions available
The great thing: it costs no power to retain display information and they can be read in bright sunlight with no backlight. Also the display can be literally as thin as paper...
This means that the platform software needs to have a degree of control over the number of display updates and the type of display updates to get the best performance. Otherwise, an application which is unaware of the display characteristics could quickly drain the battery, or worse, shorten display life time to months instead of years. Conceptually I'd be interested in replacing a display driver, but I'm not sure if this part is open. I know it is hard to get info on the Qualcomm chipsets....
My question: can this be done? Can the Android platform be modified to support a drastically different display effect? Any pointers to an android roadmap?
The reason I find Android interesting for this application is because there is a significant overlap in functionality (from cell phone to browser).
Thanks!
I cannot agree more and started to lobby with app and OS developers on improving readability on e-ink:
Make scrolling and page turns e-ink friendly http://github.com/aarddict/android/issues/28#issuecomment-3512595
Looking around on the web I find a recurring theme "we had to rebuild WebView from scratch to adapt it to the e-ink display"
There are already coding solutions which reduce flicker and page refreshes. Most of them are kept by those who market the e-ink readers who prefer to keep them as frontends to their shops.
I contacted the author(s) of cool reader on their implementation of
smooth scrolling on e-ink devices and got the following reply:
Hello, Look at N2EpdController.java Author
is DairyKnight from xda-developers. At least you can use it under GPL.
For use in closed project I would recommend to contact him.
Ideally, display components for e-ink devices should be part of the Webkit's WebView framework. I've submitted a feature request via
http://bugs.webkit.org/show_bug.cgi?id=76429
fyi, E-Ink has an Android on E-Ink development kit, AM350 that's being sold now. http://www.eink.com/sell_sheets/AM350_Kit_Sell_Sheet.pdf
http://www.linuxworld.com/news/2007/112707-kernel.html
In this case the application domain is e-reading, in which case the advantages of E-ink are more imporant than the disadvantages (slow display updates).
I've done some further studies of Android. I believe the trick is to perform display updates asynchronously; to provide applications with an environment which mimicks immediate display updates, whilst detecting the relevant updates (i.e. by using graphics processor and/or MMU) to have an intelligent display update. Not all types of applications would be suitable; i.e. games and video playback require immediate display updates.
Making such a platform will be less than trivial; however, with the growing number of different hardware platforms, abstractions are becoming better all the time.
I know this is an old question, but I have found it through Google - others might want to know this too.
PocketBook Pro 902/903 are based on Android and feature e-ink screen. You might want to check them out. There might be other models too - I am interested in these because of their 10" screen. YMMV.