-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnotes.txt
166 lines (113 loc) · 7.84 KB
/
notes.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
152
153
154
155
156
157
158
159
160
161
162
163
164
165
Got it finally sending multiple with tick, was an indentation problem of course. Next
we can finally get the JS updating based on player movements. Here is the protocol:
update|:-20.074201314575127 32.00151807747753 16 CUBE_1:-4.965607133431334 50.72833402379234 16 CUBE_3:-8.79143548698126 58.50383408594084 16 CUBE_4
* Created tiny difference, when receiving from client it is x,y,tick,name but when
sending back to client it is x y tick name.
Oh I am a dumbass, looks like we only send xyz when there is a difference, instead we should send them all if there is any difference.
After we can worry about addition/deletion. Thinking just add cube if we don't
have that one, and add a DELETE in place of an X,Y,Z to remove cube.
game.j -11.948142509523887,10,101.47652779219337, 22, CUBE_1:
update|:-11.94814250952388710101.47652779219337 22 CUBE_1
TICK:69 String:-9.3706190643597011071.72818545757929 68 CUBE_1
I think that filterChanges is onyl sending back one change, it only ever
runs acum[list[3]]=list Yeah I can prove it basically..
I fixed that issue but now it seems that
Oh I'm an idiot... of course it never runs this part, whoever is first to add changes
they will be i==1. So doens't mater how many changes I make. doesn't explain why
acum only prints out one value though. must be lower code is broken.. hah
Left off having some stupid thing in recieve message block me. Now erroring on something that we need to check if changes are null. :P
This will be harder than I thought. We need to get changes to arbiter for EACH
entity. Which means we should just send it most recent changes from player by entity.
So if we were to rebuild this then we have a client giving us new positions that we
store in changeCache on the Game-websocket-Protocol. When Arbiter wants to
get those changes then it it calls filter changes which looks at the list
of changes.
Create a map of changes by entity by looping through changeCache, if current doesn't
exist in map, add it and these changes. Else check if tick for it is newer.
If tick is newer, then make changes, current changes. Return map of changes.
Arbiter will go through the map for each player and add entity changes to a acum map
Basically does the same thing as filterChanges but acros all players. If it
finds that an entity is already in it's map then check to see whoes changes
are newer and use that one.
Lastly it then broadcasts out that map of changes.
Example new changes
14,-88.63969725729285g,-54.44850581962629,CUBE_#0/
14,-88.63969725729285,-54.44850581962629,CUBE_#1/
What chage looks like:
tick| x, y, entity name
14|-88.63969725729285, -54.44850581962629, CUBE_#0/
Left off having gotten it sending out updates/changes made by other players.
Next need to make those changes actually update the board.
-
1. Now that we got clients list and arbiter broken out we need to extend the arbiter
function, renaming it in the process to look for changes and send them off to
arbiter object.
2. Then we need to get it so the arbiter has a worldview object that he can make
changes to and check if certain things are possible. We will let all moves at first
and only have one check function. But a second, harder one will be added and put in
another thread for later.
How to store worldview -> However we store it in Js is obvious awnser. response funciton
will send back down websocket new changes.
--
So I had trouble getting the template to work for me, our main objective is to create a wrapper
object around the websocket class that can store the player's async information neatly.
--
Okay so we need it to use out Game Server socket protocal instead of theirs.
Next we need to make changes that correct on the client side.
Then we need to make every third thread an AUTH thread that changes the second cubes position to
center or something.
Finally we need to design that arbiter wrapper class around everything and reimplement.
I am correct I can make the autobahn websocket threads refer to an array of 'clients' in the super
class(Factory) like so:
def onOpen(self):
self.factory.register(self)
---
def __init__(self, url):
WebSocketServerFactory.__init__(self, url)
self.clients = []
self.tickcount = 0
self.tick()
In this example they basically have 'BroadcastServerFactory' spin up a new websocket server when it
inits and passes it the URL everyone looks for. When a new guy connects he
registers(takes 'this' websocket thread and puts it into an array in the BroadcastServer) and when
he broadcasts to all players he just iterates through and can use sendMessage. So we are just going
to rip it off and construct using server as an external file.
Resources
https://stackoverflow.com/questions/18899515/writing-an-interactive-client-with-twisted-autobahn-websockets
This might be nice, if you scroll down will show you how to make a wrapper around websocket so
arbiter can access their values and keep track across multiple sockets.
Next we need to take in input and send it back out from the server as intervals.
so we need a python thread and a queue of changes. So we will broadcast changes
in one thread for now just to this one socket, later we will handle that within
a threaded object to decouple all player communication.
Looks like we should just start this from scratch we will need to:
\- 1. Get three.js loaded into browser wiht a single cube
\- 2. drive cube with arrow keys
\- 3. have it ping the game server with coordinates.
4. figure out networking with client side prediction.
*Okay so we are going to record requests with numbers, ones from any player
we will have a function called reconcile that will check things before
returning server authoritiative state back to the players. Number of
request is used when players hit things at close times. Server interpolates
between requests and last known state.
*Okay so internet is now saying we want to queue up all server input and
then have the server make sense and send out corrections in standardized
intervals.
*But during so we can send out regular updates that keep movement of other
players smooth.
*Lastly we need to compensate for lag by giving everyone a certain amount of lag.
5. So basically we need to build an entity based system. Which means that we hold a list of entities on the server that are, enemies, player units, cameras, etc.
They will be like players but also have a value that says which player owns them and that will be checked by server every tick to make sure there are no
cheaters. It should be stored on server and client as a map, packet contents can easily be filtered through and interface and server can use list of rules
to make interpolations.
Game play in the browser should probably be two buttons, one to create and one to delete 'entities' which are just cubes that spawn. They change color when
hovered over and when left-clicked are listed as your selection, right click somewhere to move them. We can add physics to keep them on some kind of plain
maybe?
From there we just have to keep track of the entities on the server and broadcast changes in steps. After we have those basics done we can add in the server
checks, we will have one in a function for every tick with some fast simple rules and one in a function for every couple of ticks which queues up a bunch of
input in the background and then checks it out with a long list of rules before issuing it as an update. RECONCILES IN SUPREME COMMANDER USED 100ms
5. So first we need the JS to do what is descirbed above.
6. Then we send that data back to the server and get nothing useful back.
7. Then we start using the time stamps and simple checks, listing entities and who owns them.
8. then we get something useful back and update the screen with it.
*By this point we have a simpe game where you can spawn and delete entities on either screen and it will update on all others.