Re: Space Nerds In Space
Posted: 24 Apr 2016, 03:58
Around the end of August of 2015 I had made a proof of concept of traveling between multiple "universes" (really, more like solar systems) within the game. Over the last 8 months or so I have been slowly trying to get this code stable and working, and doing all the things it needs to be able to do (mostly having to do with maintaining state of the player ship) to be something worth committing. There turned out to be quite a lot of code for this, around 75 patches. I didn't clean them up quite to the level of my usual standards, but carrying around ~70 patches for ~8 months was getting to be a little tiresome (although stgit made it tolerable). This new code is still disgustingly hacky in the way that it works, but it is nonetheless committed, and you can try playing with it.
There is now a new process, snis_multiverse, which maintains the state of all bridges in a small "database". This means that when you run snis_client (either manually, or via the quickstart script) there is now a "create ship" checkbox. The first time you use a ship name, you need to check this box, and subsequent times, you should leave it unchecked -- that is to say, your ship is now persistent between runs, and its state is preserved in the "database" maintained by snis_multiverse.
I am quite sure there are a lot of bugs lurking in this new code -- some I already know about, and undoubtedly some that I don't know about. I expect there are some races in the hand-over code when all the snis_clients on a bridge switch to a new snis_server, and I expect there is still some ship state that is not preserved across such switches, but at least the infrastructure to preserve that state exists now.
By default, the quickstart script will only start a single instance of snis_server, and there will not be any warp gates in the game. But, if you "export MULTIVERSE_TEST=1" prior to running quickstart, it will create 3 instances of snis_server -- that is to say, 3 solar systems -- and will put warp gates near each planet, and you can buy warp gate tickets to different solar systems from the starbases via the comms station. You are advised to use additional art assets in the space-nerds-in-space-assets repository on github if you run multiple solar systems.
When running in multiverse mode, every planet currently has a nearby warp gate, and from any warp gate, you can get to every other known solar system. The warp gates correspond 1 to 1 between every pair of solarsystems, so if you depart from warp gate X in solarsystem A to solarsystem B, you will consistently pop out of the same warp gate in solarsystem B, and if you depart from warp gate X+1 in solarsystem A, you will pop out at warp gate N+1 in solarsystem B. In the future, I think I would like to be able to have some kind of graph to establish the possible paths of travel between warp gates to enable building a more interesting topology of solar systems than this kind of automatic and fully connected graph we have now.
- {l Code}: {l Select All Code}
git diff 8d8dd83 e8e9842 | diffstat
Makefile | 44
README | 3
graph_dev.h | 15
graph_dev_gdk.c | 33
graph_dev_opengl.c | 182 +++
key_value_parser.c | 458 +++++++++
key_value_parser.h | 103 ++
quat.c | 10
quat.h | 4
quickstart | 59 +
share/snis/models/warpgate.scad | 38
share/snis/solarsystems/default/assets.txt | 3
share/snis/solarsystems/default2/assets.txt | 14
snis.h | 20
snis_bridge_update_packet.c | 200 ++++
snis_bridge_update_packet.h | 35
snis_client.6 | 2
snis_client.c | 766 +++++++++++++---
snis_hash.c | 106 ++
snis_hash.h | 32
snis_marshal.h | 5
snis_multiverse.6 | 37
snis_multiverse.c | 1336 ++++++++++++++++++++++++++++
snis_multiverse.h | 19
snis_packet.h | 12
snis_server.6 | 47
snis_server.c | 1199 ++++++++++++++++++++++++-
snis_server_tracker.c | 243 +++++
snis_server_tracker.h | 18
solarsystem_config.c | 54 -
solarsystem_config.h | 2
ssgl/ssgl.h | 1
ui_colors.h | 2
33 files changed, 4877 insertions(+), 225 deletions(-)
There is now a new process, snis_multiverse, which maintains the state of all bridges in a small "database". This means that when you run snis_client (either manually, or via the quickstart script) there is now a "create ship" checkbox. The first time you use a ship name, you need to check this box, and subsequent times, you should leave it unchecked -- that is to say, your ship is now persistent between runs, and its state is preserved in the "database" maintained by snis_multiverse.
I am quite sure there are a lot of bugs lurking in this new code -- some I already know about, and undoubtedly some that I don't know about. I expect there are some races in the hand-over code when all the snis_clients on a bridge switch to a new snis_server, and I expect there is still some ship state that is not preserved across such switches, but at least the infrastructure to preserve that state exists now.
By default, the quickstart script will only start a single instance of snis_server, and there will not be any warp gates in the game. But, if you "export MULTIVERSE_TEST=1" prior to running quickstart, it will create 3 instances of snis_server -- that is to say, 3 solar systems -- and will put warp gates near each planet, and you can buy warp gate tickets to different solar systems from the starbases via the comms station. You are advised to use additional art assets in the space-nerds-in-space-assets repository on github if you run multiple solar systems.
When running in multiverse mode, every planet currently has a nearby warp gate, and from any warp gate, you can get to every other known solar system. The warp gates correspond 1 to 1 between every pair of solarsystems, so if you depart from warp gate X in solarsystem A to solarsystem B, you will consistently pop out of the same warp gate in solarsystem B, and if you depart from warp gate X+1 in solarsystem A, you will pop out at warp gate N+1 in solarsystem B. In the future, I think I would like to be able to have some kind of graph to establish the possible paths of travel between warp gates to enable building a more interesting topology of solar systems than this kind of automatic and fully connected graph we have now.