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
|
High priority items:
Medium-priority:
- For the battle ending synchronisation, set the end at at least
getBattleInputDelay() + 1 frames in the future (instead of just 1),
so that there will be no hickup during the end synchronisation.
Also check this value for incoming packets.
- If a player only moves away from 'Battle!' there's no need for the other
to have to reconfirm.
- decent pause handling
- make compilation of crc.c and checksum.c conditional.
- negotiate checksum interval
- Closing and destroying of NetConnections is a terrible mess.
- Checks allConnected() shouldn't be needed if CHECK_ABORT is set
on disconnect.
- Shorten or lengthen the time between frames depending on how full the input
buffer is, to prevent one side constantly stalling when the connection in
one direction is slower than in the other direction.
Low-priority:
- Some difference in pictures to indicated confirmed/unconfirmed.
A check mark perhaps.
- Check whether the random seed and frame delay have been agreed before
continuing (in doConfirmSettings).
- Replacement for TOS. It is IPv4 only.
- Integrate network check functions with doInput
It will be easy to get rid of the separate threads then too.
- The state changes from interBattle to interBattle. That shouldn't happen,
but it doesn't seem to cause any problems. Need to investigate.
Addition: negotiateReadyConnections() is called again just to make sure
all sides pass this checkpoint. This is not a problem. It should be
documented in STATES though.
- More files define NETCONNECTION_INTERNAL than they should.
- voice transmission during the game (using an external lib)
read ramjee94adaptive.pdf
- Keep-alive packets. Store time of last packet sent, use alarms to determine
when to send the next one. Count received messages?
- Some way to (optionally) hide your fleet setup until the start of the
game? With either a previously determined maximum fleet value, or
just display a number to the opponent.
- (when ships stats are in the content) Negotiate the ship stats, so people
can play with non-default ships.
- Pre-fleet-setup setup
The values negotiated could include handicapping (different values for
each player)
- hide fleets (also handicapping here)
- maximum number of ships per side
- maximum ship cost per side
- ship properties
- Send taunts (prerecorded samples) at the touch of a button?
Use taunt add-on packages? Send the opponent's package before the start
of a game?
Future improvements/optimisations:
- For BSD sockets: use dup2() to move fds to lower values, so that less fds
have to be checked on select().
- Use writev() to send multiple packets in one syscall, instead of
calling send() for each packet.
- Refusing games with both parties network controlled is not always
necessary. In theory it should be possible to have a client work
as "proxy". The client can watch as the actual players play the game.
Checking for "loops" would be tricky (eventually there should be a human
or computer controller for each side).
- Concurrent selection of ships. Note that if this is handled properly, it
will also be easy to take care of the "Allow Shofixti to choose last" bug.
Note that one party will still have to send his choice to the other side
first, which may be "exploited". Encryption would take care of this,
but at the least make sure the same player who gets to chose first
every time.
- meta-server. Use HTTP? Existing libs can be used, no problems with NAT,
human-readable. Speed is not an issue.
- move to UDP. Repeat past battleinput packets for each new packet that
is sent until they are confirmed.
- Once the protocol is stable: register the port number with IANA
- Per state data (in NetConnection.stateData) is unnecessarilly complicated.
Putting all fields directly in NetConnection simplifies things a lot.
It's not as generic, but this code won't be used elsewhere anyhow.
- Send captain names to the other side
Bugs:
- as positions are dependant on the screen resolution, you won't be able
to keep sync on games with a different resolution.
- collision detection is dependant on the images used. Using different
graphics packs will result in a desync.
- Both sides need identical battle frame rates. This value is not
negotiated.
- If one player closes the connection while the other player is selecting
a ship to put in his fleet, or loading a fleet, the "Network Control"
button won't be updated.
- If one side is computer-controlled, sync loss will occur, because the AI
uses the RNG. It needs its own RNG context.
- Pressing F10 to exit the supermelee setup when a connection is active
will cause an attempt to draw a NULL frame. (possibly the disconnect
feedback)
Final actions:
- Check out TODO, XXX, WORK tags
- memleak testing
- check for and remove mtrace()/muntrace() calls.
- update documentation
- FILES, also note which part of the separation they are in
- check coding style (search for '\>(')
- compile with maximum warnings
To put in the announcement of Netplay:
- Slow connections is acceptable. Packet loss isn't.
Bugs and todos unrelated to netplay.
- other player being able to choose the next ship after 3 seconds
of inactivity
- DoRunAway() shouldn't be handled in ProcessInput()
|
