Tag Info

New answers tagged

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 ...


6

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 ...


0

My problem here was not reading the RPC calls section of http://docs.unity3d.com/Manual/UNetActions.html properly. "They can be sent from any server object with a NetworkIdentity that has been spawned." When I had the client object reading in the locations become a spawned object under Registered Spawnable Prefabs (under Spawn Info, under Network Manager ...


0

Actually I solved the problem. The solution was to manipulate the "ms" variable in the Animate() function before calculating the lerp. I know the server sends updates every 90 ms, so if i want to add a fake delay of 100ms i need to make sure that the target "msAhead" should be 190-200. So i did like this. if (Server.msAhead > 200) ms += 1; else if ...


0

The concept is that the new position is just predicted. When the next server-side position is received, client prediction is disabled. The client just guesses the future positions until the server verifies them. Most game servers take the delay in account as well. In every client message the timestamp of the local player is sent. The server can now speed ...


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 ...


2

Maps, items, monsters, etc. gives you many factors that can be tipped out of balance by 1 small difference in a floating point operation. A character moves a little bit more to the right, he bumps into another character 1 frame early, then suddenly the whole world implodes and monsters die on some clients but not others. You'll have a much easier life ...


2

It appears what you are going after is called the Peer-to-Peer Lockstep model, according to the relevant article in Gaffer on Games. That is: Each peer runs a separate game simulation Peers share their own player's moves to all other peers (that's the peer-to-peer part) Peers simulate the same game using the same set of inputs, and don't proceed until ...


2

Let me answer your question with another question. Assuming your game is checking for input every frame, you'll be reading input from the user about 30-60 times a second; which means you would be sending about 30-60 packets every second. That's a fair amount of packets to send every second, you might want to consider something more like 1 every 10 frames. ...


0

The problem is that Server will never receive these updates unless there is a LocalClient on the machine running the server. Refer unity docs for the word Host i.e. Sever and a Client


1

In the OnServerReady callback the connectionID is passed as -1 to indicate a no connection between server to server. In the connectionID parameter you should pass the connection between the localClient and server using NetworkServer.localConnections. If localConnections return only -1, then it means that you are not connected as localClient. Refer unity docs ...


2

As for the update frequency it depends from the type of game. For an action type of game 30 updates per seconds should be perfectly smooth, but for an mmorpg (where you have thousands of players) better use something like 10 per second, to save server time. I doubt there will be any reason to have 60 updates per second, that will just use a lot of server ...


0

OnServerConnect gets called as soon as the client connects, before he has been able to do pretty much anything else, including loading the online scene. Player spawning should be done in the OnServerReady function, instead. public override void OnServerReady (NetworkConnection conn) { base.OnServerReady(conn); [...]


1

I am not 100% sure that this will solve your problem but it seems that you forgot to register the PositionMessage class. Be sure to register it in the same order on the client and the server and also, do not register the server and client classes.


0

You don't have to provide the host address in your server code on Kryonet. Your computer network has its own IP address which is used by Kryonet when you start the server. So on client code, when you start the client you put in the IP address (127.0.0.1) in case where both client and server are on same network. In the case when server and client are on ...


1

Broadly speaking there are three approaches to rewinding game state (with various flavours in between): reversing/undoing actions, replaying actions from an earlier, fixed state, or storing all states and just picking the right one on demand. The first is more flexible but in the worst case you need to double your work, creating reverse versions of all your ...



Top 50 recent answers are included