-
Notifications
You must be signed in to change notification settings - Fork 10
/
REALLYBAD.txt
141 lines (103 loc) · 6.69 KB
/
REALLYBAD.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
REALLY BAD NETPLAY PROTOCOL TIME!
The server will accept connections!
"W" is a heartbeat.
In general when the server or client sends a JSON blob, it will be prefixed by "J" + a length.
The length will be a 3-byte integer in network order.
The clients will perform a handshake like so:
Client connects to server and says "H" followed by a 3-digit protocol version number
for example, "H139"
Server can reply...
"H" (meaning sure, you are now connected, useful messages may be on the way)
"N" (meaning FUCK YOU your protocol is out of date)
# begin lobby/game room section
Additional step, new in version havinggoodfeatures.0!
(good thing I have that versioned handshake and stuff)
Client sends a NAME for the player to the server (todo: implement inputting a name G_G)
This message also includes the saves char/level for the player...
This message is something like {"name": "Texxxtonixxx", "character": "Neris", "level": 8}.
Nameless users will be prompted for a name (go figure) (this is clientside-only).
Name can be saved in config.
Server can respond {"choose_another_name": {"used_names": ["Texxxtonixxx", "Jon", "WooferZ"]}} if the guy needs to pick a new name to avoid a collision. TODO: accounts, LOL!
This is all awful and I'm sure I'll rewrite it in the next millenium to not suck ass.
At this point I actually have some annoying structured data so the server sends snapshots
of the lobby state. There's not a real reason to have rooms that aren't full if
only 2-player games are supported (maybe obs or >2p in the future, not now), so there isn't
really a concept of a room waiting to fill.
There is a list of players who are not in a room (that is, they are unpaired)
and there is a list of players who are in rooms and their statuses
(playing/levels/not playing)
Lobby state message can look like this:
{"lobby_state": {"unpaired": ["Alice", "Bob", "Charles", "Dartagnan"], "paired": [{"players": [{"name": "Katherine", "level": 8, "character": "Ruby"}, {"name": "Vincent", "level": "3", "character": "Thiana"}], "playing": false}]}}
This is the whole lobby state; the entire old lobby state is deleted and replaced.
On the client, usernames of unpaired players are sorted alphabetically and the cursor will
remain in the same position (lexically speaking) when an update occurs.
Alice can select Bob's name from the list of unpaired players to ask for a pairing.
#Bob will receive a prompt like "Do you want to play with Alice?" with obvious answers and desired results.
Players who have requested a pairing have a note to that effect.
When two players make a mutual request, the server places them in a room together.
The client sends {"game_request_to_server": {"sender": "Alice", "reciver": "Bob"}}
The server sends Bob {"game_request_to_client": {"sender": "Alice", "receiver":"Bob"}}
#Bob gets a prompt and accepts or declines.
#Bob sends the server {"game_request_reply": {"sender": "Alice", "receiver":"Bob", "reply": true/false}}
#server asserts these fields are set correctly, that Alice actually requested a game before beginning the room, etc.
Actually, both players can send requests, and when they have, the room will start.
#After bob sends "game_request_reply", server sends a message to create the room
This message is also a menu_state message
{"create_room": true, "opponent": "Bob", "menu_state" {...} }
We'll use Bob's last known character/level, which is guaranteed to exist.
We can use whatever default cursor position the client uses, probably the level selector.
When two players are paired, they can select difficulty, select character, and ready up.
This can all be one screen, with a difficulty select on the top, a character select on
the bottom, and a "ready" button on the bottom right or something.
From here the client can send menu state snapshots to the server.
Snapshot: {"menu_state": {"character": "Lip", "level": 6, "cursor": "ready", "ready": true}}
(presumably all of the buttons on the menu will have IDs, and one of them can be "ready")
It can also send a request to leave the room, {"leave_room": true}.
Server -> client when room is destroyed {"leave_room": true, "lobby_state": ...}
The server can send menu state snapshots (for the opponent), leave_room, ora message about the match starting...
When both players are ready, the server will send a message
that causes the game to start. This message will contain the authoritative level/character
selections for both players, in case of latency and stuff.
{"match_start": true, "player_settings": {"character": "Thiana", "level": 3} "opponent_settings": ...}
Play works as before, both clients request panels and the match starts
when panels are known for both stacks.
This is kind of dumb because of the extra round trips. Who cares.
After a game, the players will be dumped back to character selection with the same
level/character selected and the ready button highlighted.
Players can leave the room to return to the lobby
(this also kicks the other player to the lobby).
Players can leave the lobby to return to the main menu (disconnecting from the server).
# end lobby/game room section
#stuff below is unnecessary :OOO
#Client picks a level!
# In this state, server can send "L" followed by a level (0=10)
# This is the level the opponent chose. This choice cannot be undone.
# For example, "L5"
#Client can say
#"L" followed by a level (0=10)
# This is the level the client picks. For example, "L5"
#
#After a client sends L and receives L, it will ask for panels and
#garbage panels. Play will begin as soon as panels and garbage
#panels are known for both stacks.
gameplay!
Whenever it likes, client will ask the server for panels by saying
"P" followed by a 1-digit number of colors and a 6-digit bottommost row of panels.
for example, "P5524153"
Server will reply with "P" followed by 120 randomly generated panels.
Panels should be in the range from 1 to K inclusive where K is the number of colors.
Server will tell the other client "O" followed by the same panels.
The client can also ask for panels for garbage to turn into by saying
"Q6123456" in a similar way.
Server will reply with "Q" followed by 120 randomly generated panels.
Server will tell the other client "R" followed by the same panels.
Each frame, client will send its input state to server by saying "I"
followed by 1 character representing the input state.
At any time during gameplay, client must accept any number of these messages:
"P" followed by 120 digits
This is 20 new rows of panels for the client's play area.
"O" followed by 120 digits
This is 20 new rows of panels for the opponent's play area.
"I" followed by 1 digits
This is an input state.
It represents a frame worth of the opponent's play.