forked from smcameron/space-nerds-in-space
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
83 lines (59 loc) · 3.48 KB
/
README
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
This is some preliminary code for a multiplayer networked spaceship bridge
simulator game inspired by "Artemis Spaceship Bridge Simulator"
If you would like to help work on this project, see CONTRIBUTING.md
There are three parts.
The first part, ssgl (super simple game lobby) is licensed under the MIT
"expat" license (see ssgl/LICENSE). Ssgl is a generic lobby library which
contains nothing that is specific to Space Nerds In Space (except that, as far
as I know, Space Nerds In Space is the sole user of ssgl -- probably because I
wrote it to enable Space Nerds In Space.)
The 2nd and 3rd parts are the client and server portions of Space Nerds In
Space. They are licensed together under the GNU GPL v. 2 or (at your option)
later versions.
1. ssgl/ssgl_server is the game lobby. "ssgl" stands for "super simple game
lobby". (There is a github project, "ssgl", but the code in here is more up to
date than that.) This does matchmaking between snis_client and snis_server
processes. It does not do NAT punchthrough, so it's a LAN only thing. It can
use, but does not require the following lines in /etc/services:
gamelobby 2419/tcp
gamelobby 2419/udp
If those lines are missing from /etc/services, port 2419 will be assumed.
2. snis_server: This is the Space Nerds In Space game server. This runs the
simulation of the space-nerds-in-space universe. There are two threads per
client, one to read, and one to write. The simulation, runs, and periodically
changed state is dumped out to all the client writer threads, and by this means
the clients are updated. The reader threads gather inputs from the clients
and these inputs are fed into the simulation.
3. snis_client: There can be many instances of this. The plan is there should
be one instance per "station" on each "starship". These process receive input
from the snis_server process and display this data in whatever form is suitable
for whichever starship station is being provided (e.g. navigation, weapons,
communication, engineering, science, etc.) (Currently any instance of
snis_client can do any of the available functions to whatever degree they are
implemented (As of Nov 2012, mostly not implemented.))
The snis_client programs need not run on the same server as the snis_server nor
on the same server as each other, and the ssgl_server may run on yet another
system.
The sequence to run this thing is:
a) start snis_client (several instances, one per bridge station per team)
b) From *one* of the clients, start the lobby server, and a game server.
c) For each client, select the role. Selecting no roles is the same as
selecting all roles.
d) Connect the clients to the lobby, and then from there connect to the
game server. Each client should use the ship name and password for
the team they are on (this is just something the players make up and
agree upon. There should be one shipname/password combo for each
"team", or starship, in the simulation.
2) press function keys f1,f2,f3,f4,f5,f6, etc. on each client to switch between
the roles that station fulfills.
That's about all the instructions I have for now.
------
Logfiles: by default, /dev/null is used as a log file.
Some environment variables can cause some network related logging:
export SNIS_SERVER_LOGFILE=snis-log.txt
export SSGL_LOGFILE=my-ssgl-log.txt
Some other environment variables influence the level of logging:
export SSGL_LOG_LEVEL=0
export SNIS_LOG_LEVEL=0
lower values means more logging (yes, that's backwards and I should fix it.)
-- steve