• Create Account

# Inferiarum

Member Since 02 Dec 2009
Offline Last Active May 21 2015 04:13 PM

### #5054236Need help solving GJK woes

Posted by on 17 April 2013 - 11:36 AM

Ok, I checked out the 2D gjk explanation. And while I think it is not optimal it should still yield the correct result.

The direction of the y axis should not matter in your implementation, since you check the direction of the normal vectors anyway.

You do not mention how you actually calculate the normal vectors. If you have x=[x1, x2] the normal could be calculated as nx=[x2, -x1].

### #5011957Network input handling

Posted by on 18 December 2012 - 02:21 AM

What does the tick offset mean? Did you check on the server if inputs are used at the ticks they are intended for?

### #5010543Network input handling

Posted by on 14 December 2012 - 03:28 AM

But it makes sense theoretically to do so... It only takes half the RTT for a packet to get from the server to the client, which means the server should have moved forward 4 ticks in that time rather than 8.

The packet takes another RTT/2 to get to the server. You should try it without dividing by 2. Otherwise I think the calculation is fine.

It looks like you are still working with time, rather than ticks, as your baseline for timing.

But is it not preferable to store things like the RTT in time and then, e.g., calculate the number of ticks that have to be extrapolated at the client exactly like he did using values in time and then quantizing to ticks in the end?

edit: ok, i guess you could do it all with ticks if you do not think of them as discrete and allow stuff like RTT = 2.343 ticks, but that does not work if, e.g., you get the RTT already in time from the network library.

edit2: thinking about it, you still have to do the transition from time to ticks at some point on the client if you want to update the client time with the internal clock.

### #5010171Network input handling

Posted by on 13 December 2012 - 06:20 AM

I guess you should not divide by two

### #5008754Network input handling

Posted by on 09 December 2012 - 04:07 AM

well, I guess it was mentioned earlier that it is a good idea to do the simulation/game state updates with a fixed time step.

What you are doing right now is probably something like this (written as a pure function):

newState = update( oldState, inputs, deltaTime)

whereas with a fixed time step you would only have

newState = fixedUpdate( oldState, inputs)

and the duration of the update is kind of hard coded.

edit: if you do the fixed update, you only need the same set of inputs every time you do the update, for two simulations to be consistent. And since this is a discrete system time is represented by an integer counting the number of updates.

### #5008486Network input handling

Posted by on 08 December 2012 - 07:26 AM

You have to estimate the RTT separately (e.g. include the latest time stamp of the input packets from the client in the server packet). If the server time is 300 and it takes 100 ms for the update to get to the client, then the client has the update with time stamp 300 when it is already 100 ms old, now he adds the RTT to the packet time stamp and is now 100 ms ahead (if the estimate is correct). If the actual client time differs from this target time you adjust it slightly.

Ok, so here is how I do it (slightly different from what I described above since I do not use the RTT explicitly)

On the client we have the internal clock CLK and an offset OS, such that ideally the client time CT = CLK + OS = ST + RTT/2

Client sends input packet with current time stamp CT1
server receives input, updates simulation, sends out new game state, includes the current server time ST, and the stamp of the latest input packet CT1
Now ideally CT1 and ST should be the same
When we receive the game state update on the client (which includes CT1 and ST) we update
OS = OS + alpha*(CT1 - ST )
with some small alpha > 0
and the new client time would be
CT2 = CLK + OS

You can still keep an estimate of the RTT if you need it somewhere
RTT = (1-alpha)*RTT + alpha*(CT2-CT1)

### #5008185Network input handling

Posted by on 07 December 2012 - 12:23 PM

Considering the timing problem here is how I do it:

Every time you get an update from the server you can calculate the server time ST corresponding to the update. The target client time targCT would be
targCT = ST + RTT + c
where c is a constant that accounts for jitter in the RTT (such that input packets arrive in time with high probability) and RTT is the current estimate for the round trip time.
The actual client time CT is updated with the internal clock between each server packet and then adjusted according to something like
CT = 0.99*CT + 0.01*targCT

Note that these calculations are done in (more or less) continuos time.

Considering the client side prediction, I guess if you have an expensive physical simulation, it might be infeasible to calculate the prediction steps. In this case, as mentioned by hplus, you could just render everything at a render time
RT = CT - RTT - IP
and try to mask the control delay somehow.

I keep trying to figure out how this would play out and I can't see how it could work:

Client A has RTT of 200ms
Client B has RTT of 200ms
Interpolation time of 50ms

Server Tick: 200, Client render: 150, Client Tick 400: Client B moves forward
Server Tick: 300, Client render: 250, Client Tick 500: Client B moves forward again. Server receives move command for tick 400
Server Tick: 400, Client render: 350, Client Tick 600: Server applies move and sends out world state. Server receives second move command for tick 500
Server Tick: 450, Client render: 400, Client Tick 650: At this point client A should see client B move, but the world state still has another 50ms before it reaches client A
Server Tick: 500, Client render: 450, Client Tick 700: Client A receives world state for tick 400. Now what?

Valve defaults to an interpolation time of 100ms. In this situation if the interp time was set to that, the client would have just barely received it in time. If the packet took a little longer than 100ms, it would have still been too late.

what i meant was that the difference between the client time and the time corresponding to the latest update from the server is the RTT, the difference between client time and the simultaneous server time is RTT/2. With this timing, assuming constant RTT, the client input packets arrive at exactly the tick, when they are needed.

At the server you do not necessarily have to take the time stamp of the input packet into account, you can also just use the latest packet of each user for the update (edit: you still use the time stamp to detect out of order packets). The RTT tells you how far you have to extrapolate at the client (If you want to use prediction).

### #5007748Network input handling

Posted by on 06 December 2012 - 07:29 AM

Considering the timing problem here is how I do it:

Every time you get an update from the server you can calculate the server time ST corresponding to the update. The target client time targCT would be
targCT = ST + RTT + c
where c is a constant that accounts for jitter in the RTT (such that input packets arrive in time with high probability) and RTT is the current estimate for the round trip time.
The actual client time CT is updated with the internal clock between each server packet and then adjusted according to something like
CT = 0.99*CT + 0.01*targCT

Note that these calculations are done in (more or less) continuos time.

Considering the client side prediction, I guess if you have an expensive physical simulation, it might be infeasible to calculate the prediction steps. In this case, as mentioned by hplus, you could just render everything at a render time
RT = CT - RTT - IP
and try to mask the control delay somehow.

### #5007707Network input handling

Posted by on 06 December 2012 - 04:15 AM

You could also make the bitmask more flexible to allow for an arbitrary number of actions, you have to know if it is worth the effort.

If you time stamp the input states with the simulation tick they should be used for, there is a one to one mapping between input state and simulation tick, and, as long as the input packets arrive at the server in time, the same input should be used for the same simulation tick. So if this is what you are doing then I am not sure where the issue is.

### #5007701Being Immortal, Can it be Fun?

Posted by on 06 December 2012 - 03:58 AM

There could still be a game over.
E.g. your mission is to safe people from some danger and you fail. -> game over

### #5007699Network input handling

Posted by on 06 December 2012 - 03:54 AM

You can still send a bitmask you just have to have the same information on the server and the client, which bit maps to which action. For example you could write all actions in a text file and just assign IDs successively when reading it. Of course on the client you need additional information about which key maps to which action, but you should have that already.

That is, the client produces the bitmask out of information from the input devices and the mapping from actions to IDs, sends it to the server and the server gets the bitmask from the network interface.

The actual part of the program (e.g. a class which stores the current bitmask internally and also knows the mapping from the actions to the bit IDs ) that presents the input to the game logic is the same for client and server.

edit: also in my opinion resending lost input packets in this scenario does not make any sense because at the time the lost packet arrives at the server it is probably out of date anyway.

### #5007693Network input handling

Posted by on 06 December 2012 - 03:37 AM

Well I think we are doing all those things. The physics has its own internal stepping. I call update and tell it how much time has passed and then it will accumulate the time and run as many steps as needed. Also, the input isn't being consumed. Like I said, the server combines the states. So if it has W down, D down as its current state and it receives a Space down message, then the state becomes W down, D down, Space down.

So you kind of delta encode the packets? I think this is not really that practical for input packets, since you have to deal with lost packets, and it may actually need more data then sending the whole state at each game logic tick. As hplus said, most of the time a small integer is enough to send all key state information as a bitmask.

### #5007061Space game ideas

Posted by on 04 December 2012 - 07:08 AM

I like the suggestions above, just giving you another option:

Whilst questing, rumors of new quests come with the navigation coords of that planet. Those coords are entered into the ship's navigation system, which then allows you to hyperspace to it.

BTW, if you only allow hyperspace jumps between planets, there is no need to have the entirety of space in game (ie: Infinity style). You'd be able to get away with each planetary system (ie: star plus any planets, satellite objects, etc) being an isolated scene, thus making it easier to manage.

I think this is a good idea. You divide the universe in zones where each zone has a coords coded with some integers. You can jump to each zone with the hyperdrive. Now you place planetary systems in certain zones and all other zones are just empty, maybe with some random stuff like asteroids (which could be generated procedurally from the zone coords). So everything is in principle accessible, but it is impossible to guess the few zones which actually have planetary systems. That is, you would have to find out the coordinates by interacting with other people etc.

You could still make things more accessible with better technology. E.g., you get the information that a certain planet is somewhere near (1000,4000,5000). Let's say 'near' defines a space of 1000 zones. Now you could visit each zone till you find the planet, or you could upgrade your scanning system which allows you to scan nearby zones for inhabitable planets or something, allowing you to find the planet in a much shorter time.

edit: another example for a single player open world rpg would be gothic 3

### #5003479Network game design question

Posted by on 23 November 2012 - 06:56 AM

Method 1 is easily hackable, so I would stick to method 2.

The tick rate depends on the game type, mostly they go from 20 ticks per second to 60 ticks per second. Some servers (I read LoL is this way somewhere, can't say if the font is reliable) tick as fast as they can. My network experiments (mostly RPG based) ticked 20 times per second with good results.

If you are worried about latency, take a look at "client side prediction".

If you use method 1 you should run a local simulation on the server to determine the actual result of the game. (You could of course also get the results from the clients and only replay the game, based on the inputs, if there are inconsistencies) And of course determinism in the simulation is important.

In my opinion broadcasting the inputs is totally valid. Of course with this approach each client knows the whole game state at any moment, thus it is possible to do map hacks etc. . In League of Legends, for example, method 2 is used and you only get updates for players you actually see, so is is impossible to use map hacks. I heard fight games like Street Fighter sometimes use an input based network system where they also predict the game state by using the local inputs, but maybe someone else can elaborate a bit more on that subject.

Also if you have a game where dodging projectiles is important I am not sure if client side prediction is a good thing. I guess it is better to use some other mechanic (http://www.gamasutra.com/view/news/177508/The_lagfighting_techniques_behind_GGPOs_netcode.php#.UK9xFeOe9h4) to hide the delay, and show all game objects in the same point in time.

edit: Let me correct on this. Client side prediction together with interpolation for other game objects is probably a bad idea if the relative position of the player to the other objects is important. That is, you could either display everything in the past or if you want high responsiveness you predict not only the local player but the whole game state.

So in short, if it is not important to hide some information from the clients (i.e. you have no fog of war etc.) you could definitely go for method 1, which can give you very good results for a fast paced action game.

### #4996519Sums of uniform randoms

Posted by on 02 November 2012 - 07:15 AM

I am not sure what you want to accomplish.

If you want a random variable with uniform distribution from 0 to N, and you have a variable uniformly distributed from 0 to 1 well then you just have to scale it with N.
I do not see the point in creating a random variable with some distribution and then wanting to transform it back to uniform, if you actually have a uniform distribution to begin with.

PARTNERS