I'm new to Swift and native iOS Development in general, and I'm trying to making an app which allow two or more users to send and receive in real time data about something (such as a line path), similarly to what happen in multiplayer games. It isn't a game, by the way. Let's make an example:
Let A and B be two users.
There is a canvas on this app, for example.
A can draw a line (which should be an array of points) and B see what A is drawing in real time (so B receive the array).
As I said, it's similar to what happen in multiplayer games (but here I don't want a server to manage what people do, I'd like something like P2P or a direct connection between devices).
How should I manage this?
Related
Two Quick questions:
Are the seconds value of the clock/time on all iPhones around the world the same? If not, are they close at least & how close?
Do the seconds value of the clock/time on all iPhones around the world change/increment at the exact same time?
Upon request, I'm editing this post and adding the purpose for asking such questions:
I'm trying to make a corporate app that can play a video on multiple iPhones around the world at the exact same time (or as close as possible, ideally the exact same moment). Could you please guide me on how to do this?
Much thanks in advance!
To answer your actual question per se,
Are the seconds value of the clock/time on all iPhones around the world the same?
The fact is, yes, 99.9999% of iPhone users simply use the "get time from a server" system which is of course built in to any phone now.
(Indeed, this simply applies to any Windows, Mac, Android, iOS, etc etc device.)
Yes, they are all "about the same".
You could rely on it being within a second or two, probably even closer.
You cannot rely on it being closer than that.
It seems that you
I'm trying to make a corporate app that can play a video on multiple iPhones around the world at the exact same time
Synchronization in general and streaming video (is it streaming?) is a well-explored (and rather technical) branch of software engineering. (For example a massive amount of game engineering, which is a huge field, relates to inside-the-frame synchronization.)
This is not something you can learn how to do in five minutes, and it requires a stack of device-cloud stuff. Go ahead and ask new questions about this, or just google to get started! Good luck.
Regarding using push notifications.
With the push notification you would send a time. You would not send a "command to play it".
So say right now it is (example) 09:13:28. You would pick a time in the future by a couple minutes. So let's say 09:14:30.
Then using a push notification you would send that information "09:14:30" (and a video file name) to everyone connected. (You'd be sending a "command" as it were, to play video X at 09:14:30.)
Then every device would in fact play the video at 09:14:30 (simply using the local clock, as asked in your question).
Be aware that sending push notifications is extremely sloppy and slow. It can take any amount of time from 5 seconds to a minute, AND quite often there are delays beyond that (ie ten minutes or the like).
I personally would not even bother starting to experiment with push notifications, for the project you describe.
These days, making apps is entirely about using device-cloud services, such as Firebase. Everything is about "OCC" - occasionally connected computing.
(So, you can't get a job "making apps" anymore - i.e. if you know how to move buttons around on an iPhone screen. You get a job because you can make a total, live, device-cloud system - indeed such as you are making.)
Indeed your example project is the perfect such "demo" project for learning about how to do modern apps.
Simply use Firebase to sync everything up.
You'll essentially put a piece of information on Firebase ("play video X at 09:14:30") and that information will be communicated fairly quickly/reliably to everyone connected.
For the particular task you describe, I personally would use PubNub which is faster than Firebase and basically made for game-like problems precisely like you describe.
http://pubnub.com
If you truly needed performance/reliability better than pubnub, you are really talking major engineering. So, the (buildings of) engineers who make live games at Nintendo, Warcraft etc, would tackle such an issue as "being even faster than PubNub".
So, the answer in brief!
The very short answer then to your question posed is:
Learn to use the various device-cloud services, which are at the heart of all apps today. (Knowing how to make "an Android or iOS app", as such, is of no consequence today.) For your particular problem, you'll want to use PubNub specifically, as it is built for precisely realtime problems such as this. (Firebase more leans towards "OCC" type data problems.)
Really that's it.
Edit: The answer is to use firebase realtime database.
I wrote a library for the next person.
https://github.com/flipflopapp/turnbased-games-with-firebase
-- Question --
I am implementing two player chess game (www.halfchess.com) and am considering using firebase messaging (instead of using sockets to create rooms and two player matches). The game would involve sending 60-100 chess moves as messages between two devices in two to three minutes (that can be android or iOS). My nodejs server would have code that enables device to device messaging (receiving from one player and sending to other).
I cannot use Google Game Services because I don't have google login implemented in my app (I only plan to keep facebook login). The advantages of using firebase (compared to sockets) is that I will have to write much lesser code (reconnections, etc) and it would take care of scalability issues.
My questions are :-
(1) Will there be problems when the users playing against each other are on two iOS devices (instead of android's)? (such as higher latency)
(2) If a user is changing location physically and a message that contains a chess move is undelivered, when will it be retried?
(3) For a fast game of chess, will the latency be manageable? This is like 8-10 times the speed of normal chatting.
While I read more on the topic, perhaps someone who has already experimented can comment.
Firebase Cloud Messaging is not meant for kind of usage, and in addition to a non guaranteed delivery time (some researches from 2013 - 2014 shows more than 1 seconds per message on avarage), FCM will probably imply throttling in such a use case.
See also this SO post
I'm sure the answers above will work but, I was having a tough time getting them to function. This is what eventually worked for me and my firebase chat app!
Hopefully, this will help some folks out there.
I was able to add a chess game to my firebase chat app and, all I used was an iframe! However, it didn't work the first time because, all I did was add the iframe coding to my app.
This is how I got my iframe to work in a firebase app...
First, change directory (cd) into your chat app's "public" folder (where you would typically run the "firebase deploy" command) and, add your iframe to the "index.html" document located there. Use this address for your iframe's source URL (src)...
src="chess/index.html"
It wont work right if you do not include the "index.html" page name!
Next, I created a new folder named "chess" in the same public directory and I added the chess game's "index.html" doc and dependanciess to it (js,css,images...etc).
And last, but not lease, open a terminal in the same "public" folder and run "firebase deploy" to upload the whole thing to your firebase account and console.
Done!
I'm pretty sure that including your chess app docs inside of your firebase app is what made the iframe finally work. I also wrapped the iframe with a couple of 'div' tags but, I'm not sure if that made any difference.
Please, feel free to come and take a look but, you'll have to sign in with Google to gain entry!
After that, just right-click anywhere on the page and select "view source" to see the code. Cheers!
https://friendly-chat-b2d6a.firebaseapp.com/
Instead of having the other player send a message to the client, why not just have the client display a message based on whats happening in the game? It seems like an easier solution for you, as the only thing that needs to be sent is the actual move, and you can piggyback off of that if you need to.
I realized I should be looking at Firebase Realtime database (and not messaging).
Useful links:
https://firebase.googleblog.com/2016/07/have-you-met-realtime-database.html
Is firebase realtime json database suitable for data broadcasting?
https://firebase.google.com/pricing/
https://groups.google.com/forum/#!topic/firebase-talk/n_B1nrgp580
(according to this talk the latencies can be < 200ms most of the times)
https://twitter.com/jonikorpi/status/733560092780462080
Which exact topics do I need to do research on in order for me to do something simple as: sending live finger sliding data co-ordinates across the screen to another iOS device over the internet and vice versa?
Take two clients, how can I create a live connection between the two so that when user A, slides his finger across his screen user B should then be able to see where user A is sliding his finger in the form of a dot for example, that too live and vice versa when user B slides his finger across on his iDevice.
A tutorial would be great.
You need to use TCP or UDP IP networking and send the data across in some form that each end can recognize. The easiest way I've found to deal with that in iOS is to use GCDAsyncSocket, a 3rd-party library you can download. The difficult part is that you cannot send the data directly between two iPhones across the Internet, as opposed to across the LAN, without a relay server (which you would need to program) in between unless you use some kind of NAT transversal.
And, of course, you'll need to know Cocoa Touch (AKA iOS programming).
I'm creating a game, turn based, and I was thinking of using Game Center to handle it, but the passed game-object is evidently max 64kb. Is there another way to pass objects between devices for this use, without having to create a database or storage-server as middle man? The game-object itself for me is probably a lot less than 64kb, but there are some initial variables I would like to send, such as images. With my calculations, the initial data for one game is about 500kb, but after getting those images once, the passed game object is just a couple of kb's, and are never going to include those images again.
Is there a way to send these images directly?
There are a few ways to get around the limit.
This answer mentions Alljoyn which would allow you to transfer that size of files.
You could also send them indirectly by transferring them to your own server, then passing a link to the file to the other player. For a turn based game, this would have good advantages of enhanced reliability as you could put in retries on error for both the upload to the server and the download to the device and control it yourself. I would recommend AFHTTPClient for this, also.
Is there another way to pass objects between devices for this use, without having to create a database or storage-server as middle man?
Without your own server, there isn't.
I'm writing a FPS XNA game. It gonna be multiplayer so I came up with following:
I'm making two different assemblies — one for the game logic and the second for drawing it and the game irrelevant stuff (like rocket trails).
The type of the connection is client-server (not peer-to-peer), so every client at first connects to the server and then the game begins.
I'm completly decided to use XNA.Framework.Game class for the clients to run their game in window (or fullscreen) and the GameComponent/DrawableGameComponent classes to store the game objects and update&draw them on each frame.
Next, I want to get the answer to the question:
What should I do on the server side? I got few options:
Create my own Game class on the server, which will process all the game logic (only, no graphics). The reason why I am not using the standart Game class is when I call Game.Run() the white window appears and I cant figure out how to get rid of it.
Use somehow the original XNA's Game class, which is already has the GameComponent collection and Update event (60 times per second, just what I need).
UPDATE:
I got more questions:
First, what socket mode should I use? TCP or UDP? And how to actually let the client know that this packet is meant to be processed after that one?
Second, if I is going to use exacly GameComponent class for the game objects which is stored and processed on the server, how to make them to be drawn on the client? Inherit them (while they are combined to an assembly)? Something else?
First of all, your game logic should be on the server.. Not only does that prevent cheating, but it also garantees consistency, especially over random operations. The clients should only be sending their inputs to the server
I'd recommend your keep the server's window visible to make it a debug console, you'll need it, to know what your server is doing exactly.
For a FPS, UDP is recommended. You'll be sending a lot of data and you don't really care if your packets are all received or ordered. While the packets are not garanteed to arrive ordered, you don't really have to worry about it. Most of the time, they will arrive in order anyway. Let's say you send 60 frames per second to your clients and one of your packet arrives in the wrong order: Your client will have erroneous information for 1/60th of a second, which is barely visible.
Finally, you should send a serialized representation of your game state multiple times per second to your clients. They should be able to retrieve that information and draw it the same way as your server. You could even serialize your gamecomponent and send it if you think that's appropriate. It's really up to you to decide.
Hope this helps!