I messed around for an hour or so, and managed to get it to compile fully on my older macOS 10.12 system. It seems to mostly work, but snis_client just throws up a black screen. Clicking on certain regions on the bottom left/right corners does emit a sound effect, so it is running. Further investigation is in order! I'll submit patches if I figure out some nice fixes, of course.
I don't like to be contrarian, but, for Debian-based distros specifically: it's not!
Use `dpkg-deb` to create a `deb` file from your executable and upload for distribution. Generate different executables for different target architectures from your compiler toolchain, package them separately as different deb files, and share. It's a one-liner to do this.
I was wondering, is there any interest in implementing a kind of single/two player mode? Something where, for example, you can operate the weapons systems while being able to do simple navigation durring a battle (essentially evasive maneuvers). I can see something like this being handy with limited players. Maybe this is already feature that I haven't discovered yet.
Either way, it's really cool and I've been having fun with it!
It's not the first time such an idea has been floated. If you go onto the "demon" screen (gamemaster screen) and type in "set MAIN_NAV_HYBRID=1", you'll then see both the "main view" and the usual navigation stuff on the navigation screen. That's about as far as I've gone down that road though. The thing is, what makes this game a little bit unusual is the multiplayer cooperative aspect of it. You get a bunch of linux nerds in a room with a projector and a bunch of computers and it's like you're captain of a star ship (hence the name "space nerds in space".) Obviously, it could conceivably be possible to run the whole ship from a single screen by a single person, as demonstrated by countless other space games in which ships are piloted by a single person. But then, it's just another space game just like all the other space games, as you've removed the one thing that makes it kind of different. So, I've kind of resisted that path. If I were to pursue such a path, I'd probably fork the project and make a different game out of it.
BTW, there's a hell of a lot more to package up than just a few executables.
But I'm not really too interested in distributing packages that will just get out of date.
"git pull; make" is easier anyway.
1. Why do I have to compile the thing myself?
Because packaging on linux is a nightmare. For a long time, Linus Torvalds did not offer linux binaries for his "subsurface" diving program, but did offer them for Windows and Mac. Now there are linux subsurface packages, but Linus doesn't do them himself. If Linus can't be bothered to make linux binaries, you know the situation is messed up. I figure, if the game is good enough, then someone (besides me) will make packages. If that doesn't happen, well, I guess the game isn't good enough. And I'm ok with that.
2. Why don't the devs do this or that?
"The devs" is mostly just me. I do what I feel like, this is my hobby project that I do for fun.
3. How does this compare to Artemis/Empty Epsilon etc.?
It's more properly 3D than Artemis or Empty Epsilon. It has a much nicer Lua API for making mission scripts than Artemis's XML based system. It doesn't have as many mission scripts as Artemis or EE. It feels a little more "millenium falcon" than "Enterprise", mainly due to the turret gun, I suppose. I think the planets, especially the gas giants[1] in SNIS look cooler than anything in Artemis or EE.
4. Why does the game design suck?
It's hard to make a cooperative bridge simulator that's fun at every station all the time. Back in 2012, I heard about Artemis, and thought it was a cool idea, and it seemed like a neat project, so I started working on my own interpretation of the genre. It's hard to know how things will turn out without just trying it. It came out the way it came out (so far). A lot of the fun in this type of game has to come from the participants. With the right participants with the right attitude, it can be pretty fun. Some parties are fun, some are dull. Alcohol sometimes helps.
5. Why doesn't it run on Windows or Mac?
It used to run on Macs, but then support for OpenGL on Macs became problematic. Maybe someone could get it to run on Macs again, but not me. It will run on Windows using the Windows subsystem for linux, however, the graphics will be software emulated, which is generally not good enough. Trying to compile natively on Windows would be a big job. It uses pthreads extensively, and some other various linux-isms here and there. Windows and Mac were not a priority for me because I don't have either of those machines, and I was mainly interested in playing the thing with my friends. Besides, Windows and Mac already have enough games.
6. Can you run the game remotely, or does it have to be on a LAN?
Maybe. I've never seriously tried to run it remotely. I have tried it once or twice, with the server running on a digital ocean server in New York, with my clients running in Virginia, and it worked better than I expected it to. It does have a voice chat feature built in (added after COVID appeared), and that seemed to work. But my test was limited to about 5 minutes of messing around, and only a couple of clients. Each client will require about 100k/s of bandwidth. This can be greatly reduced by reducing the number of objects (asteroids and NPC ships) floating around in the simulation, but I haven't really experimented much with running this thing other than on a LAN.
7. Will it work on a Raspberry Pi 4?
Yes and no. Some stations will work. SCIENCE, COMMS, and ENGINEERING seem to work alright. More graphics intense stations don't work so well (MAIN SCREEN, NAVIGATION, WEAPONS, GAMEMASTER).
[1] https://github.com/smcameron/gaseous-giganticus