# Space Nerds in Space is a bridge simulator meant to be played in a room > Space Nerds in Space is an open source multiplayer networked spaceship bridge simulator written in C, inspired by Artemis, with stations for navigation, weapons, engineering, damage control, comms, science and the game master, a Lua API for mission scripts, voice chat and a procedurally generated universe. The README is explicit that it is meant to be played on a LAN with everyone in the same room. **smcameron/space-nerds-in-space** — Multi-player spaceship bridge simulator game. Captain your starship through adventures with your friends. See https://smcameron.github.io/space-nerds-in-space - Repository: https://github.com/smcameron/space-nerds-in-space - Stars: 782 · Forks: 83 - Language: C - License: GPL-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/smcameron-space-nerds-in-space ## A game about a crew, not a game about a ship Space Nerds In Space is an open source multiplayer networked spaceship bridge simulator game, inspired by another game called Artemis Spaceship Bridge Simulator. The status paragraph is unusually blunt, and it is the most useful sentence in the README. It is still a work in progress, but it is substantially far along, and reasonably free of bugs as far as the author knows, which he glosses as the game should not crash, in other words. The design point is that the game is about the crew rather than the ship. Every player sits at a station, the stations do different jobs, and the ship only gets flown if the people at the stations coordinate. That is why the README says the game is meant to be played on a LAN with all players in the same room, and why the bandwidth requirement is on the order of 100k/s per client. You are building a set of machines into a set of consoles around a screen, and the screen is where the shared state is projected. The repository is a C project of considerable size, and the file listing at the root shows the shape of it immediately. There are simulation files such as a_star.c for pathfinding, crater.c, black_hole_lens.c and earthlike.c, entity handling, fleet and commodity systems, and a docking_port.c. There is an arduino directory, a debian directory for packaging, an extern directory, a Contrib directory, a doc directory, a fuzz_obj_parser.c and a checkpatch.pl, which is the Linux kernel's own style checker. There is also a TODO file, a CITATION.cff, an AUTHORS file, a CC-BY-SA.txt alongside the GPL COPYING, and both AGENTS.md and CLAUDE.md and GEMINI.md at the root, which says something about how the project now expects to be worked on. The licence is GPL-2.0, and the repository is not archived, with the last push on 2026-10-19. ## Seven stations, and any of them can be picked up or dropped The feature list starts with the stations, and it is the part that defines the game. There are terminals for Navigation, Weapons, Engineering, Damage Control, Comms, Science, and Game Master. Seven roles, and the roles are the game. Navigation moves the ship, Weapons fires, Engineering and Damage Control keep the ship alive, Comms and Science handle contacts, and the Game Master terminal runs the scenario. Around that sit three structural rules that make it work as a group activity. Multi-crew is supported, with multiple bridges able to exist at once, so a group can run more than one ship. Terminals may join, leave and re-join games at any time, which is what makes it possible for one person to take a break, or for the Game Master to hand over, without ending the session. And the physics of it is a shared world: travel between instances of the game via warp gates in an arbitrarily large universe of solar systems, so two bridges in different parts of the universe can meet. The rest of the feature list is the reason the stations have something to do. Asteroid mining, bounty hunting, docking at starbases to repair the ship, buy and sell various commodities, sell mined ore and obtain warp gate tickets. And the closing line of the list, which is also the summary of the genre: and of course, fly around and shoot stuff. Two features are worth pulling out because they change what the project is. The Lua scripting API for mission scenarios means the content of a game is not hard coded in C, and there is a separate document, doc/lua-api.txt, that describes it for people writing mission scripts. And voice chat is part of the build rather than an add-on, which is what makes the room feel like a room. ## Building it: a dependency script, make, and a hardware reality check The build instructions open with hardware rather than software, which tells you what kind of project this is. The quick preview is: acquire the necessary hardware, some Linux machines, a network switch, cables, a projector, stereo and so on; clone the repository or obtain the source tarball; install the dependencies; build the code by typing make; run the game by typing bin/snis_client; download additional art assets; and restart snis_client. The clone step is a git command, and the README insists on one thing: ``` > git clone https://github.com/smcameron/space-nerds-in-space.git ``` with a note that says do NOT perform these steps as root, and as a non-root user. The same section offers an ssh clone for registered GitHub users and a snapshot zip for everyone else. Dependencies come from a script, util/install_dependencies, which in theory can install them on apt, yum, zypper or rpm based systems but has only been tried with apt based systems. It has a --dry-run option so you can see what it would do. The README is blunt about the difficulty: even on apt-based systems package names are not consistent across Linux distros so it might not do the right thing, and this is a Hard Problem which there is no avoiding. The manual list underneath is the fallback, and it includes build-essential, portaudio19-dev, libpng-dev, libvorbis-dev, libsdl2-dev, liblua5.2-dev, libttspico-utils, sox, libcrypt-dev, libcurl-dev and libncurses-dev, with libopus-dev marked as needed for the voice chat feature, and the note that the Makefile can download and compile Opus itself if your distribution has no packages. The hardware note is the part that decides whether the game is playable for you. A Raspberry Pi 4 with 4 GB of RAM and heatsinks is sufficiently powerful to run the game at 720p for some screens, namely Navigation, Engineering, Damage Control, Science and Comms, but is not really good enough for the main view, the Weapons or the Demon screens, where you will see very low FPS. Older Raspberry Pis are generally not powerful enough to run the game at all. For the full experience the README describes six Linux computers, a network switch, a projector or large TV, and a stereo system, in a reasonably dark room. ## The Makefile is the build manual, switch by switch The Makefile is where the project's real configuration surface lives, and reading it tells you what the maintainer actually cares about. The first switch is voice chat. WITHVOICECHAT=yes is the default, with a comment that for no voice chat you set it to no. The second is DOWNLOAD_OPUS, which is no by default, with the explanation that if your distro does not have Opus library packages, the Makefile can download the source from Mozilla.org and compile it, and that you can change it to yes if you need that. Then there is a long series of ordinary but telling knobs. USE_SNIS_XWINDOWS_HACKS is set to 1 unconditionally, and the name is a warning about the project's target. SERVERSONLY defaults to 0, so the server and the client are built together unless you ask otherwise, and USE_GLES defaults to 0, which is the OpenGL ES switch. For the Mac there is a single line, OSX=0, with a comment to use make OSX=1 for mac. The optimisation and debugging switches are documented in the same way. O defaults to 1 for an optimized build with no debug info, and the comment explains the three-way setting, including make O=0 for a debug build with -g. P is the profiling switch, off by default, and V turns on verbose output so every command is printed. The sanitizers are the most interesting part. UBSAN=1 adds the undefined behaviour sanitizer and switches the compiler to clang, and ASAN=1 adds the address sanitizer. There is also a comment about a hack for the Raspberry Pi, because there was some trouble getting -fsanitize=bounds to compile there, and the workaround disables the bounds, undefined behaviour and address sanitizers on aarch64 while enabling bounds sanitizer elsewhere. Finally there is ccache, which the comment explains is worth having because it makes hopping around in git history much cheaper, since files that were merely touched do not get recompiled, and it can be turned off with make USE_CCACHE=0. That is a build system for a project where people change C code and rebuild often, and it is legible. ## Where Space Nerds in Space is the wrong tool The limits are real and they are about the room, the platform and the licensing. First, this is not a single-player game. It is meant to be played on a LAN with all players in the same room, and the full setup wants six Linux computers, a switch, a projector and a stereo system. It can be run entirely on a single Linux laptop, but then the premise of a bridge crew collapses into one person pretending to be a crew. Second, the platform is Linux. The game is currently developed using Mint 20.3, and the README says it is possible that the game could be made to build and work on Mac OSX, that it has been done before but not since 2014 or so, and that you are on your own if you want to try, with the author's understanding being that newer Macs do not support OpenGL, which means you are out of luck. Third, the hardware floor bites in a specific way. A Raspberry Pi 4 runs some stations acceptably and the main view poorly, and older Pis not at all, so a group planning to run stations on cheap hardware will find the split between screens uneven. Fourth, the licence has a practical edge for anyone who modifies it. GPL-2.0 means a distributed derivative carries obligations, and the repository also carries a CC-BY-SA.txt file, so the artwork and the code are not on the same terms and both need reading before you redistribute a build. Fifth, it is a work in progress that says so, with the reasonable assurance that it should not crash, but with a TODO file at the root and no release notes beyond the tags. The recent releases are v1.0.11 on 2026-06-01, v1.1.0 on 2026-08-06 and v1.1.1 on 2026-08-09, so the version line moves in small steps. For a group with a room, a projector and a habit of running Artemis, it is a rare thing: a bridge simulator you can read, patch and script. ## Conclusion Groups that already play Artemis and want an open source, scriptable version of it should build Space Nerds in Space, because the Lua mission API and the C source make it a project a group can extend rather than only play, and the multi-bridge support means a crew can be split across several stations. It is the wrong tool for a solo player on one laptop, since the design assumes six machines, a projector and a room, and it is the wrong tool if you are not on Linux with OpenGL, because the macOS build has not been touched since 2014. Before deploying it, read the build instructions and the hardware notes, budget for the LAN switch and the projector, and note that the licence is GPL-2.0, so a modified version you distribute carries obligations. ## FAQ ### What is Space Nerds in Space? An open source multiplayer networked spaceship bridge simulator game written in C, inspired by Artemis Spaceship Bridge Simulator. It has terminals for Navigation, Weapons, Engineering, Damage Control, Comms, Science and Game Master, supports multiple bridges at once, and lets terminals join, leave and re-join games at any time. ### How do I build Space Nerds in Space from source? Clone the repository as a non-root user, install the dependencies with util/install_dependencies, which has a --dry-run option, then type make to build and run bin/snis_client. The README also lists the dependencies to install manually if that script does not work for your distribution. ### Can I write my own missions for Space Nerds in Space? Yes. The project includes a Lua scripting API for mission scenarios, documented separately in doc/lua-api.txt in the repository, so scenario content is not limited to what is compiled into the game. ### What hardware does Space Nerds in Space need? A Linux machine with a reasonably capable GPU, a network switch, a projector or large TV and a stereo system for the full experience, which the README describes as six Linux computers in a reasonably dark room. A Raspberry Pi 4 with 4GB of RAM and heatsinks runs the game at 720p for the Navigation, Engineering, Damage Control, Science and Comms screens, but not well for the main view, Weapons or Demon screens. ## Sources - [Issues](https://github.com/smcameron/space-nerds-in-space/issues) - [License: GPL-2.0](https://github.com/smcameron/space-nerds-in-space/blob/master/LICENSE) - [README](https://github.com/smcameron/space-nerds-in-space/blob/master/README.md) - [Releases](https://github.com/smcameron/space-nerds-in-space/releases) - [smcameron/space-nerds-in-space on GitHub](https://github.com/smcameron/space-nerds-in-space) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/smcameron-space-nerds-in-space