-
Notifications
You must be signed in to change notification settings - Fork 7
/
WOULD BE NICE
132 lines (71 loc) · 4.59 KB
/
WOULD BE NICE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
WOULD BE NICE
-----------------------------------------
There is some fluctuation on the linux box.
Instead of measuring minimum delivering for adjustments, take the average
then calculate one, two standard deviations of delivery.
If the standard deviation of delivery is within +/- 4 tolerance of average.
This should avoid the client fluctuating speed faster/slower for no reason.
Need to study a bit of statistics to understand exactly what I want to do here.
-----------------------------------------
Client needs to adjust ticks gradually rather than immediately.
Client should report back that the adjustment is made once the adjustment has been performed.
A rate of adjustment, eg. one tick per-1/4 second or something like that should be established
This way fast adjustments, eg. common +/- tick adjustments can be made quickly
While larger adjustments can be spread out over a second or more
-----------------------------------------
I don't think "frame" is really a property of the world.
World shouldn't care about frames at all.
World should only care about ticks.
Frame belongs to client/server.
-----------------------------------------
Server is going to need an easy way to detect when clients are active vs. not
Right now many situations make clients active or not.
But the server just wants one place: server_activate_client, server_deactivate_client.
-----------------------------------------
Not nice that the adjustment is forever sent from server -> client after being applied.
It's functional sure, but inefficient.
-----------------------------------------
Probably best to just assume the input is empty vs. holding the previous input
-----------------------------------------
If the client delivers too many late inputs in one second tell the client to reconnect.
-----------------------------------------
Client should not send any input until it has synchronized.
Right now it tries to send inputs before sync. This is pointless and annoying.
-----------------------------------------
It would be much nicer to have separate synchronizing packets
vs. input and snapshot packets.
They are really quite different.
No need to combine effectively two packets into one.
-----------------------------------------
it certainly seems that instead of going back to a synchronization stage
while maintaining the connection, it would be much better to just tell the
client that they should reconnect from scratch
perhaps the client could bump a connection counter so we can distinguish
repeated packets from the same connection attempt, from new packets that
should tear down the client slot and restart it in a connection from scratch.
I greatly prefer this to the idea that the client should have to manage
complicated transitions in/out of synchronization state.
in fact if this is done then the idea of "sync sequence" can just disappear.
-----------------------------------------
Implement small adjustments, eg. speed up n frames over x seconds, slow down etc.
This should be only small adjustments.
If detect that desync has occured outside of threshold for small adjustments,
go back to synchronize state.
Make sure that when going back to snychronize the sync offset is cleared to zero.
-----------------------------------------
Implement interpolation between ticks for client render, eg. fix your timestep.
-----------------------------------------
Might be a good idea to create server guid and stick it in connecting packets,
as well as sync packets, this way the client cannot connect or get packets sent
to it for long without knowing the challenge response.
-----------------------------------------
Get the alpha blending and color transition blending working again.
To do this we'll need the concept of per-entity view data, eg. indexed by entity id.
Move the client window setup and create stuff into render.cpp
Remove the vector BS in physics_ode.cpp for the authority walk. Come up with a better data structure.
physics_ode.cpp uses a bunch of C++ vector classes for authority walk. Can probably do better than this.
Would be very nice to be able to connect by hostname.
If the address to connect to does not resolve to a valid address, try running it through DNS.
Ideally this could be done seamlessly inside client state machine
Ideally the DNS resolution would be non-blocking
-----------------------------------------