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