Initial import of TMS in public CVS repository (used to be private)
[mmondor.git] / mmsoftware / mystic_ships / README
CommitLineData
f21437ba
MM
1$Id: README,v 1.1 2006/12/31 08:32:39 mmondor Exp $
2
3TODO
4====
5
6SERVER
7
8- Add support for collisions between torpedoes and ships.
9- Add support for multiframe objects. For instance, detonations could have
10 multiple frames, as well as the cloaking effect. These should possibly more
11 be time-dependent than actual frame dependent however, considering that
12 frames can be delayed and their rate changed.
13 If there was a fixed client-side FPS for those, this would also mean that
14 all other objects obtained from the server would need to be recorded as
15 well... Possibly that if we did that it might also be possible to transmit
16 less frames over the network but with thrust/angle information for the client
17 to be able to evaluate smooth transitions between them...
18- Cause older torpedoes to automatically get detonated whenever a new
19 torpido is fired and the maximum number of torpedoes has been reached.
20- Implement authentication credentials checking, limit same user to one
21 connection only
22- Limit connections per ip address in number and frequency
23- Implement and test using rc4 or openssl with aes. Verify if the overhead
24 is negligeable enough to be worth keeping. Otherwise, we could use crypto-
25 graphy for authentication only if wanted.
26- Possibly implement as part of the authentication system a method to only
27 allow signed client keys, the client key would be sent to us, and then also
28 make sure that only one client using that key can connect at a time,
29 logging when it's not the case. This client-specific unique signed key
30 could be used as ID possibly? Or other than signing we perhaps should also
31 sign against the player's name and verify at login that he can only use that
32 login with that key, too.
33- Add proper connection/disconnection/events logging
34
35CLIENT
36
37- Continue test: draw objects as they are received by the server until the
38 end of frame packet, at which time we would update the display flipping the
39 double buffered pages. This also means that we must find a way to not take
40 all CPU time while waiting for both SDL events and server packets ones at
41 the same time! Since receiving is prioritary, perhaps that we could wait
42 for messages from the server using a ring, since SDL events would
43 automatically be queued meanwhile?
44 Also now send user events to the server.
45- Add an auto-ping along with fps... Use SDL_GetTicks() to calculate the
46 delay between sending ping and receiving pong.
47- Create packets to also send user updates about his ship's statistics.
48 These could probably be updated less frequently than 10 times per second.
49
50
51NOTES
52=====
53
54An attempt to develop a portable game client using SDL among unix
55and windows operating systems. The only officially supported
56compiler should be GCC (and mingw under windows, avoiding the need
57for cygwin libraries). The compiling/development environment when
58under windows will use cygwin to provide a shell, vim and cvs,
59while compile options will be specified as needed for it to use
60the mingw compiler (which also comes as part of cygwin).
61
62Initial tests will be using SDL, SDL_mixer and SDL_net.
63
64If all works well, it should also be easy to use OpenGL portably.
65I was already able to get portable SDL/OpenGL code working, a while
66ago, but this generated no sound and had no network requirements.
67Hence this test.
68
69Moreover, the test server under kqueue/ needed a client for further
70testing to be possible at its development stage.
71
72Since SDL_net does not provide non-blocking I/O (and it remains
73unclear if windows supports this properly), a decision was made to
74port to SDL an inter-thread messaging library I had done for use
75with POSIX threads, and to use multiple threads.
76
77One thread will be used to send data to the server, another thread
78to receive data form the server, yet another thread to deal with
79all user input events, and a main thread to receive all those events
80in an asynchroneous manner form the utility threads and run the
81main loop.
82
8304:21 <@lucca> one thread to send, one thread to receive, one thread to poll
84 for io events, and one thread to bring them all and in the darkness
85 bind them.
86
87:)
88
89Ogg-vorbis will be used for music, using SDL_mixer. Ship rotations
90will be performed using SDL_gfx.
91
92It is very important to avoid having to link this client statically
93against GPL or LGPL libraries, because of the viral nature of those
94licenses. I do not intend to release my code under those licenses.
95If it ever publically is released, it shall be done under a MIT/BSD
96derived license.
97
98I am also thinking about dedicating a thread for the connect state
99to the server, or possibly to have the writer or reader thread also
100perform that task.
101
102It is possible that a thread be ideal for rendering as well. It
103could be notified when a screen refresh is wanted, when it could
104set a flag. When it's time for it to draw a frame (honoring FPS),
105it would if the flag is set, or perhaps it simply could when it
106wants. I wonder if it would be appropriate for the display thread
107to not need a mutex, since it would always be read-only accessing
108the data.
109
110Anticipated design so far:
111 Main thread
112 User events thread
113 Network receive thread
114 Network Send/Connect thread
115 Display thread (the Receive thread will draw for now).
116
117It is possible that states may be desired. For instance, there
118would be the connection state, the one where the user and client
119have to provide authentication information (this could be part of
120connect phase perhaps), and in-game state.
121
122At first, as a test, the world will all be seen by everyone and
123will fit into their screen. A world of 1024x768 could be used for
124this :) Then there will probably be addition of a chat system with
125messages window, to continue enhancing the protocol. Things will
126go on from there...
127
128Hmm for now I want to simply use a joypad.
129- Button 0 fires in direction of the paddle direction.
130- Buttons 1 and 3 could act like button 0, to provide secondary weapon (1)
131 and special weapon (3).
132- Button 2 attempts to correct navigation direction in the direction
133 of the paddle.
134- Button 6 would accelerate.
135- Button 7 would decelerate.
136- Button 4 could toggle shields
137- Button 5 could toggle cloak
138
139Equivalent keyboard layout:
140- uiojlm,. would change angle just like the gamepad directions.
141- w would toggle cloak
142- s would toggle shield
143- z would thrust up
144- a would thrust down
145- d would cause direction change
146- space would torp
147- f would fire second weapon
148- g would fire special weapon
149
150And we're already out of buttons, we can't beam up/down armies or
151bomb. Unless button 3 was special instead of a special weapon,
152and allowed to perform various commands depending on the paddle
153direction (i.e. up/down to beam up/down, left to bomb). This also
154means that orbiting/launching would need to be automatic. Of course
155all this is if we're thinking about a game like netrek. But we'll
156simply only allow dogfighting at first.
157
158Now it becomes tricky how I'll minimize bandwidth sent from the
159client to the server. Probably that buttons events will be monitored,
160and then current paddle direction when required. In the case of
161direction change button, the last paddle direction applied would
162be remembered, and if the same, the event could be dropped. If
163not, send a direction change packet. What happens if a button
164remains pressed while a direction change occurs? We probably should
165ignore it.
166
167
168Threading limitations under win32
169=================================
170
171There seem to be bugs when using SDL with multiple threads under windows
172which I did not observe on unix systems. The docs specify that the main
173thread should perform the drawing, but it wasn't specified that another
174thread than the initial one would not be able to obtain all user input
175events on windows. Typed keys would not be received, for instance.
176
177It then appears that most of the processing must be done in the main
178initial thread, while only networking related blocking functions will
179be done in slave threads.
180
181There also seem to be other windows-specific problems using SDL threads,
182such as instability. I have noticed that when using another thread
183for user events reception, part of the application would often lockup,
184despite my code properly using mutexes as required, and all sound and
185greaphics being performed by the main initial thread nevertheless.
186These problems were also not found to occur on unix systems.
187
188The design was thus changed for now, and threads will be used for SDL_net
189functions only, since they are blocking. Let's hope that this will work
190stably, however. It remains to be tested.
191
192
193Storing images and sound samples as part of the executable binary
194=================================================================
195
196I was able to include read-only (.rodata) and read-write (.data) into
197binaries directly from files using objcopy and linking them on NetBSD,
198Linux and cygwin-mingw. The SDL_image library, which I now successfully
199built for mingw, includes functions that can use RWops, and the SDL
200library allows to easily create RWops from memory buffers. Moreover, the
201SDL_mixer library also allows to do this to load sound samples. I should
202thus modify the makefiles and code to very easily use these features.
203
204The SDL_mixer library however does not allow by itself to do this easily
205with music files. However, thise generally being considerably larger,
206it should not be a problem and they can remain external.
207
208If this works fine, it would be easy to generate a cryptographic block
209cipher key at build time and to include that key within the executable
210as well. Copies of the binary files to be included could then be
211encrypted using that cipher to a temporary copy which will be linked
212in, and an initialization function could be provided to unencrypt the
213files prior to use. Of course, since the key is also in the executable,
214there is no real security. However, it could prevent computer-illiterate
215people from too easily ripping our original content. RC4 could be used
216for this for instance, or even a much more simple custom encoding
217algorithm :)
218
219
220Using a map
221===========
222
223We probably want to randomize the ship's positions on the map.
224Randomization in this respect could be done on a position in a
225circle of varied radius distance to the location of the actual
226ship. This would prevent clients from being able to exactly fire
227at the actual ship position using the map (which also would make
228cloaking useful against an unofficial client).
229
230
231Encrypting communications
232=========================
233
234A stream cypher such as RC4 would be simple and efficient to encrypt
235communication between the client and the server. If RC4 is used,
236the following must however be taken into consideration:
237
2381) Session keys must always be unique. To achieve this, a function
239like HMAC to obtain from a long term key and a unique noonce could
240be used if necessary. This however is best for private key
241cryptography, I believe.
242
2432) The key must be renegotiated from time to time after enough data
244has been sent using it. There exist vulnerabilities if 1GB of data
245is transfered using the same key.
246
2473) At least 1024 bytes of the pseudo-random generator keystream
248must be discarded after key creation to avoid a key predictability
249vulnerability.
250
251If public key cryptography was used, at least 256-bit RSA could be
252used. Such an implemetation theoretically would not need larger
253numbers than 128-bit ones to function, I think. Then a "complex"
254bignum library could probably be used which is faster and simpler
255than a general purpose more complex arbitrary precision math library.
256
257We probably should borrow NetBSD's SHA512 (or at least SHA1) and RMD160
258algorithms. My ARC4 implementation could be used as well.
259
260
261Compressing communications
262==========================
263
264Investigate if using huffman compression would be wanted and worth
265it, or some other simple compression system suiting well to the
266transfered data. Possibly that the dictionary could be static and
267would never need to be transfered.
268
269zlib could probably also be used. It however unfortunately is
270famous for frequently discovered vulnerabilities.
271
272
273
274PROGRAMMING STYLE
275=================
276
277The style chosen for this project consists of the (Net)BSD KNF style
278(Kernel Normal Form) style borrowed from. All code should conform to it.
279Additionally, lint(1)-style comments are used to make the code clearer
280for future code auditors.
281
282
283
284Matt