Hot answers tagged

9

Part of this is a Technical solution, the other part is a Design solution. Peer to peer for this sort of thing has some fun drawbacks, especially as you're left with an interesting question of which client is authoritative, especially with lots of players. You can round robin between clients (this is actually useful for anti-cheating), but as everyone's ...


8

After searching around, it seems that synchronizing the clocks of 2 or more computers is not a trivial task. A protocol like NTP does a good job but is supposedly slow and too complex to be practical in games. Also, it uses UDP which won't work for me because I'm working with web-sockets, which don't support UDP. I found a method here however, which seems ...


8

One of the most common misunderstandings of TCP vs UDP is that TCP's main feature is reliability. The main feature of TCP is that it abstracts a stream of data to send from one socket to another. Reliability, as provided by TCP is a requirement for the abstraction to work, but is not the central idea behind TCP. You might want to consider basing your ...


8

I think what you'll find is that the UDK networking protocol which runs on top of UDP and TCP, is tied up with their proprietary client and server code. So no, if you wish to use the actual UDK networking client, you very likely wouldn't be able to write your own socket or webserver, even if you knew what the packet structure was (and wanted to try to ...


7

It turns out that this is due to how powersavings in mobile phones work. For my iPhone, sending a steady stream of UDP pings every 200 ms will keep the interface open, and give me a RTT of 80-100 ms. Reducing the ping frequency will drastically increase the RTT, to an average of about 400 ms. Further reducing frequency causes the RTT to occasionally go even ...


7

I'm assuming your question is asking about just trying to get some information from a server via TCP and not creating your own networking interface for UDK. The latter which would be impossible unless you had access to the UE3 source code just because classes like Actor and such have native replication which you wouldn't be able to override. As for your ...


4

Basically you wouldn't write a server like that. Those tutorials are showing you the basics of 2 reading and writing and assume 2 trusted processes that are guaranteed to cooperate. Instead of waiting for a message from one client before the code continues to send a message out to another client, the server waits for messages from all clients simultaneously....


4

In most of cases the relationship is simple: Client -> Input to server Server -> Calculate logic and physics, send object position and property data back to client Client -> Render the scene using received data I guess that this is what you where asking for!;)


3

I'm thinking the clients will send data to a central server over a socket or http, and receive data via GCM push messaging. GCM push messaging strategy isn't appropriate for sending large amounts of data, for a few reasons: Rate limits are in place to prevent malicious or poorly coded apps from spamming an individual device with messages. Messages aren't ...


3

If you want to create your own C++ servers, you would have write the entire networking part by yourself which is quite difficult as Nick Wiggill describes. I wouldn't recommend it, but it can be done. UDK can use DLL libraries and thus you could write your own networking part. It would be a huge project, but it could be done. However if you stick with ...


3

Due to the fact that your game is turn-based you can get quite creative with your solution - you can still run the server on one of the phones but you don't need to rely (directly) on a direct IP connection. In your situation what I would do is implement the XMPP protocol and send game state via that protocol - XMPP is particularly well suited to this ...


3

Send logical data, not presentation. Most games will never send graphics or textures to other systems during gameplay. Each system should already have all the resources it needs to render the events; you just send information about which events have taken place.


3

Those packets are still late. Even if you send 1M packets every second, there is still lag. Certain packet is packed at time t1 and it arrives at t1+ping/2. You send positions of other player to everyone. I assume you then do something like this: player[4].Position = new Vector2(readNextPlayerX(),ReadNextPlayerY()); You set that coordinate you sent, ...


2

I've written at length about this topic here: http://www.gabrielgambetta.com/fpm1.html. It's not exactly your case (this is for an authoritative server and dumb clients, vs your peer-to-peer architecture) but I guess the entity interpolation and server (in htis case, peer) reconciliation may apply.


2

UDP does not ensure that the package will arrive properly or that will arrive ordered, but is faster than TCP. TCP ensures the aforementioned features but is slower because of acks. Usually, action based games like FPS should use UDP because of the volume of data that must be sent/received over network. On the other hand, turn-based games should use TCP ...


2

Figured out the problem: it was a remnant from a previous build in which I was trying to store all enemy data in variables and was not closing the registration of enemies properly: changed socket.on('enemyRegister', function(data){ // builds a monster on the client socket.broadcast.emit('enemyRegister', data); to socket.on('...


2

You have multiple problems with your current implementation. First of all, the biggest problem with peer-to-peer (or P2P for short) networking is, that it isn't designed for games. Due to it's nature, nobody has authority over the data being sent and received. If one of the players decides to cheat (always assume this), then there's nothing you can do ...


2

No, UDP isn't "secure" in the sense that it will prevent hacking or tampering by the client. TCP isn't either, for that matter. If you want to prevent tampering by clients you need an authoritative server to validate the data sent over the network regardless of the transport mechanism. Additionally, or if you don't have a central server you can rely upon (...


1

Thanks for reading, turns out I just needed to spend a bit more time on my problem. For those who find this in the future, I used Kryonet to run my network code in a separate process.


1

Panda Pajamas excellent answer has covered a lot of the topic, but if you want more detailed information I suggest taking a look at Gaffer on Games series of blogs on 'UDP vs TCP'. There Glenn Fiedler goes into more detail about the problem with using TCP for games with real-time requirements, and suggests how you can build reliability into your own UDP-...


1

I think the main problem is that you try to send the whole game state every interval. A better way would be to split the sync into events and states. Events are important things like a spell that gets casted or damage that is dealt. Events need to get send over TCP because such packages are reliable and sequenced. States are components like the position and ...


1

JSON Philipp makes a good point about JSON. It is human readable and makes debugging network code easy. If you have no experience in programming network code, this would be the way to go. Yes, there is a lot of overhead by using JSON, but for small to medium data transfers, it should be more than enough. And like Alexandre Vaillancourt said, you can always ...


1

Basically, you cannot fix the [entire] world and, eventually, you will have to draw the line. If the server and all clients share the same frame-rate, they just need to synchronize upon connecting, and occasionally, thereafter, especially after a latency event. Latency does not affect the flow of time or the PC's ability to measure it so, in many cases, ...


1

The degree of access you are expecting may or may not be doable. However there is a simple callback function designed for sending messages from native plugins back to Unity: UnitySendMessage(). That will call the named method on the named object; in other words, you need to have an object with the desired method in the scene and then your plugin can call ...


1

In a project I once was involved (not game related) they decided to send each UDP message twice to reduce losses with an event id so if both messages were received the receiver could ignore the second, sounds basic but it did the trick. first define burst: shotgun and sniper has a burst of one bullet smg has a burst of 5 (?!) for each bullet send a UDP, ...


1

I believe losing a message about a gun shot event cannot be tolerated since it has the potential of affecting the player's responses, unlike the position updates. You can use TCP to let the client know about the 'shooting started' event. When the enemy player stops firing, send the 'shooting finished' event. None of the packages will be lost, therefore, ...


1

Most programming languages or network libraries have APIs for asynchronous IO operations where read- and send operations return immediately. Read-operation return only the data which was buffered since the last call and send-operations are executed in background. When you have such an API available, there is usually no reason to add another layer of ...


1

I'm no expert on this , but from what I can remember the best way to do this is to just send packets when actions are taken and not the whole time. Example: Player presses a button to move > send to server > send to other players > display stuff on clients Player releases button > server > other clients ... That way you don't have to send so much data. ...


1

Adobe Air Socket The Socket class enables code to establish Transport Control Protocol (TCP) socket connections for sending and receiving binary data. TCP Transmission control protocol, a protocol developed for the internet to get data from one network device to another. Uses a retransmission strategy to insure that data will not be lost in ...


1

The Unity socket security is a system that attempts to ensure that Unity only connects to servers that are expecting a Unity client. This is there to reduce the ways in which Unity can be used maliciously. In theory this should only apply when running a web build, but in practice I'm pretty sure it can run in other circumstances too, whether appropriate or ...


Only top voted, non community-wiki answers of a minimum length are eligible