-
Notifications
You must be signed in to change notification settings - Fork 0
/
presentation.txt
151 lines (132 loc) · 8.83 KB
/
presentation.txt
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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
f,g for 80/500 ms of fake lag
i for prediction
p for into/out of screen
w,a,s,d for movement
left click for shoot
Make sure when you start it up the cubes orient themselves correctly
1. Tell assessors about project
2. Demo system
3. Answer questions
Why was the project worth doing?
Unsolved complicated field that is frequently used in development of actual games.
My project is really just a delve into the field and the various difficulties
Turned more into an exploration into developing a game - tough
Technical strength -
Collision code
Physics concept
Shooting
Networking concept for reliable UDP
Intro on defining fps-game genre
State that my aim to understand networking aspects behind them
Need to build a basic game
Started with OpenGL labs and Vulkan - took most of term 1 really for not a lot
Vulkan was incredibly tough esp. for beginner to graphics
So started back at effectively square one, switched to OpenGL
// Need part on project management
// Test driven rapid incremental agile development, testing parts of code on smaller programs
// and then slotting them into the main program afterward
// for example the graphical representation of the cubes are actually completely
// separate from their collision model, could have any graphical, one that doesn't
// even conform to physical model
// the networking class structure of a Sender and Receiever send any items that can
// be serialised etc., slotted in later
// thorough testing carried out on each unit before integrating it into the main application
// Then after integration of components into program system testing undertaken to find out
// if program still behaves correctly
// philosophy is to break problems into sub problems, implement solutions for those,
// build up those solutions until have a test program that works, then integrate into main
Luckily two things still had were the concept of a physics engine/collision code
Collision code - SAT theorem explained, test vertices of two shapes if when projected
onto common axis of either shape, if all projections pass for an axis shapes colliding
http://www.dyn4j.org/2010/01/sat/
// Fixed timestep physics engine, what do Havok/Bullet do
// Wanted to do own for understanding
Physics "engine" - when say engine, really just mean a way to an rigid body at a position with
a mass, and advance it a fixed time tick (note that fixed time delta important) so it's at
a new position with a new momentum
Note that the issue with simple Euler integration is that due the game world being sampled
at discrete time intervals (80tps) that very quickly the physics of the world spiral out
of control with this. Using RK4 that effectively does Taylor series approxs and takes a
weighted average. Running at a fixed number of simulations per second with a fixed delta t
gives reasonable output.
// Collision resolve, cons of momentum+minimum translation vectors forces
// Could be done alternatively with impulse but requires additional algorithms like GJK? etc.
// go lookup to find the contact point about where the impulse should be transferred
It must be noted that getting realistic physics I found was very found/I'm very dumb and the to
ensure that objects are not still in collision after a frame when they are (a posteriori)
colliding objects are gently pushed apart along minumum axis of separation
Lot of tweaking to physics engine, works well enough for this. In reality I suspect very
difficult to get right - using these pushing apart forces and conservation of momentum
principle to set momentum. Spent a lot of time tweaking this.
// Maybe find game that uses octree?
Octree for storage, divide space up into cubes/octants. Each octant may also be subdivided.
Octree holds <pos, Id> pairs, indexed by position so only need collide on nearby.
In heinsight octree lookups are sufficiently slow I believe this is due to the
quintessential problem that whilst O(n) analysis is great, the octree has fairly awful
cache locality and does a lot of traversal to find an element. And a lot of if cond.
add else don't branching. In heinsight perhaps have more higher level nodes that are
compactly stored and lowest level nodes in leaves that are somewhere else.
https://en.wikipedia.org/wiki/Octree
primarily to avoid O(n^2) collision checks
// How do games do shooting?
After this shooting - shooting was not too difficult once had broken down into appropriate
smaller subproblems. Eventually settled on using
// (0<AM⋅AB<AB⋅AB)∧(0<AM⋅AD<AD⋅AD) test if point M in rectangle ABCD
// https://en.wikipedia.org/wiki/Line%E2%80%93plane_intersection
so check if org + t(dir) = point where point in cuboid
then check if coef t is positive ie. shot forward, not shot backward
check this for faces, lots of early exits for optimisation
// cite source multiplayer networking as goal to accomplish
// following gaffer on games/source with sending snapshots in packets for client
Networking. Using asio library that does the lowest level network ops and exposes a socket
like API. Using UDP - explain TCP sliding window waiting around for stale data problem.
Also using increase byte-size packet numbers to guard against UDP's lack of guarantee
for out of order packets and duplicate ones.
To serialise data using a library called C++ cereal. Nice and simple API, able to
serialise types like glm vec3 and all STL containers so really nice.
Could/will in proper version consider a switch to google's protocol buffers that are
a more complete solution that I suspect will especially have greater space efficiency.
Also have a zlib impementation that does compression to compress serialised data.
Despite all this I still send fairly large amounts of data - haven't optimised for
bandwidth as it would take so long and already quite behind schedule.
Protocol I have sends off packet n, and until it receives an ack for that packet will
include the payload for packet n in packets n+1, n+2 etc.. This utilises redundancy to
combat packet loss rather and minimises latency as opposed to stopping at waiting.
The cost is bandwidth - again stress not optimised for bandwidth - ie. no delta optim.
(When optimised - strategy games like sc2 for example (get link for I think AOE)
send unit inputs over network. Often shooters ie. CS send state. I am sending both
but only using state).
Clients send input forces/shots to game server.
Server processes these inputs and applies them to it's world, affecting world state.
Server send changed world state/events to all clients.
Clients receive this and update their world state.
At 80tps for server and client, 12.5 ms delay between sims.
In order to combat packets arriving out of order, client buffers packets received
by adding them a small queue of size 4 currently. This therefore adds 50ms in "input
latency" where all actions are delayed by an additional 50ms but means up to 3 packets
in a row may be lost and the client will still be able to render perfectly normally.
Ie. client doesn't receive packet n, n+1, n+2 but receives n+3.
Since n+3 has all state data for n, n+1, n+2 in, client adds all these to buffer
and can continue as normal. For better quality connection could reduce this buffer size,
less input latency. Buffer protects against up to buffer number of packet drops
Dumb client really here. Ie. client just receives new world state like position and sets
it. Actually the current arch also redundantly sends new momentums for pieces too.
However these are not set as they don't matter. Could do some extrapolation type thing
where when buffer empty and recieved no data just simulate with stale, but you get a
huge jump when you get back new data.
Also have prediction on shot, simple idea. Complex to properly implement and ran out of
time quite frankly. Idea being client does not have to wait for their own delay to see
the partial result of some action. Ie. here shoot and sees "hit" text change.
In reality could have units move in a strategy game and give sound cues, recoil kick,
etc. But cannot fully confirm this until server says you did in fact hit.
// https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Lag compenstation - refer to article
In a sense I already have this, ie. currently my hits are calced server side but I could
easily change that to client side. In a real world impl. cannot do client side due to
being unable to trust the client.
// What to do better, time management definitely
// Don't be so optimistic (stupid), doing so much stuff from scratch like the physics
// Great learning experience, learnt a lot, very close to being able to develop more
// on networking concepts - can mention input prediction (if not already), and lag
// compensation
//