4 ms·
Hi, author here. I'm a little hesitant to wade into these comments, but I'll try to answer a few questions I see popping up, and some that I just made up. 1.
by smcameron 5y ago
Hi, author here. I'm a little hesitant to wade into these comments, but I'll try to answer a few questions I see popping up, and some that I just made up.
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 https://github.com/smcameron/gaseous-giganticus
- AkshatM 5y ago> Because packaging on linux is a nightmare 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.
- AkshatM 5y agoFor Debian-based distros, just use `dpkg-deb` to bundle your executables into a `deb` and distribute the `deb`. It takes one line to do this.
- smcameron 5y agoIf it's a one liner, send me a patch. BTW, there's a hell of a lot more to package up than just a few executables.
- smcameron 5y agoAlso, there's already debian packaging stuff: https://github.com/smcameron/space-nerds-in-space/tree/master/debian https://github.com/smcameron/space-nerds-in-space/tree/maste... But I'm not really too interested in distributing packages that will just get out of date. "git pull; make" is easier anyway.
- smcameron 5y agoAnd I'm pretty sure that debian stuff is out of date, because I switched from gtk to sdl2 some time ago, but the control file still mentions gtk. But I never use this debian stuff, so I didn't notice until now. Perhaps someone will fix it.
- grae_QED 5y agoThanks for sharing your project! I've been messing around with it for the past couple of hours and I gotta say, it's a lot of fun! I really enjoy the aesthetics of it too. You clearly put a lot of thought into it and it really shows. I'm excited to see where it goes. :) 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!