Space Nerds In Space

[smcameron]

I just found this project and am very interested in trying it out. I'm running into some build problems, I'm hoping someone can help me with. Linux is not my primary OS, so I apologize if the answers seem obvious to others.

I'm running Ubuntu 15.04 inside VirtualBox on Mac OS X Yosemite. I installed all the dependencies. When I run 'make', it starts with this warning twice:

"Package sdl was not found in the pkg-config search path. Perhaps you should add the directory containing 'sdl.pc' to the PKG_CONFIG_PATH environment variable. No package 'sdl' found"

Then it builds for a while and ends up failing, not able to find 'SDL/SDL.h'.

I think you need sdl-dev. e.g:

apt-cache search sdl-dev
libsdl1.2-dev - Simple DirectMedia Layer development files

Then "apt-get install libsdl1.2-dev".

Well, the above is for ubuntu 14.04 (actually Mint 17 -- derived from ubuntu 14.04) which is different than what you're running, so, it might be different.
Try "apt-cache search sdl-dev", and it will tell you which sdl-dev you need.

In any case, I think sdl is only used by mesh_viewer, which is a tool for viewing models, but which is not actually used in the game. So you may be able to get by without sdl if you can get the build to proceed without mesh_viewer.

As long as it builds snis_client and snis_server, and all the openscad models, if mesh_viewer isn't built, it won't stop the game from running.

I've previously tried both Raspbian and Ubuntu Mate on my Raspberry Pi 2, but could not find SDL2 in the former and OpenSCAD in the latter case, though I have not tried building them locally yet. If anyone has overcome these issues, I would love to know.

You're not going to have a good time on the raspberry pi. The little machine just doesn't have enough oomph.

Also, does anyone have build instructions for Mac OS X?

I haven't built it myself on Mac, though I know it has been done by at least one other person, although I am not sure it has been done recently (within the last year or so.)

In general, I think this project would benefit from some build instructions, as it is not as simple as 'git clone, then make'.

True. Send me a patch? There are some build instructions here: https://smcameron.github.io/space-nerds-in-space/
although they are in the context of creating a bootable image. If you're not creating a bootable image, then the parts you're interested in begin after you're in the chrooted environment. Granted, those instructions don't mention libsdl-dev. It is hard to fighure out all the build dependencies when, as in my case, you already had most of them installed before you began. And it is even harder to track them across multiple linux distros. My strategy is to try to make the game good enough that I just keep the source on github and hope that other people will find it worthwhile to package it up for all their various distros. Not entirely successful so far, but that's ok too.

[btaggart]

Thanks for the quick response. By the time my post was moderated (it was my first), I had figured out the SDL issue for Linux, and also have gotten it building and running on on Mac OSX. I'm getting a friend to try my steps on Mac, so when he confirms them, I'll post them here.

As SDL2 was the missing dependency on Raspbian, I tried that one again, but hit some other problems. If I ever get that worked out, I'll post about my experience.

Are you ever planning on restructuring the project so you don't have the bulk of the game files in one directory, or so that it builds to a separate directory?

Has anyone made progress on building for Windows (or know of some obvious reason why it's not worth trying)? All your libraries seem to be cross-platform, and the big obvious hurdle I see right now is the lack of an apt-get alternative and a built-in pkg-config.

[smcameron]

Thanks for the quick response. By the time my post was moderated (it was my first), I had figured out the SDL issue for Linux, and also have gotten it building and running on on Mac OSX. I'm getting a friend to try my steps on Mac, so when he confirms them, I'll post them here.

As SDL2 was the missing dependency on Raspbian, I tried that one again, but hit some other problems. If I ever get that worked out, I'll post about my experience.

Cool. Thanks.

Are you ever planning on restructuring the project so you don't have the bulk of the game files in one directory, or so that it builds to a separate directory?

Wasn't planning on it, as... well, wasn't aware of anything driving such a requirement. I know that's kind of how cmake works, but... I'm not using cmake. So, why would I want to do that? I am not seeing what that would enable or what problem that would avoid. Not that I'm against it, but I'm not going to do it without some good reason.

Has anyone made progress on building for Windows (or know of some obvious reason why it's not worth trying)? All your libraries seem to be cross-platform, and the big obvious hurdle I see right now is the lack of an apt-get alternative and a built-in pkg-config.

Not a lot of progress on that front. Jeremy was for a time working on an SDL port (moving away from gtk) but, that has stalled, I guess (to be fair, we both got pretty demanding new jobs at the beginning of this year, so free time is a bit scarce). Not that gtk can't be compiled for Windows (and has been done before on my other game, Word War vi, though I don't know if gtkglext works with Windows). From my perspective... windows has enough games, and, if people are crying that the game doesn't work on Windows, well, shoe's on the other foot now isn't it? How does it feel?

It occurs to me that the joystick code uses linux-specific ioctls, so that won't work on mac or windows -- but joysticks aren't really a big part of this game, so that's no matter -- actually I haven't tested the joystick code in ages. (on second look, I forgot somebody already ported the joystick code to windows for word war vi, so it might work on windows.)

[btaggart]

Wasn't planning on it, as... well, wasn't aware of anything driving such a requirement. I know that's kind of how cmake works, but... I'm not using cmake. So, why would I want to do that? I am not seeing what that would enable or what problem that would avoid. Not that I'm against it, but I'm not going to do it without some good reason.

To be honest, this response took me by surprise. I've been a professional software engineer for 20 years now and I've never worked on a project set up this way. It would be easier for people to contribute if they know what's going on in the code, and having source files broken down into logical groups helps with that. Also, building into the source directory makes it really hard to package up the game for distribution, if you (or I) ever wanted to do that. Also, building into the source directory means that a mistake in the makefile could overwrite your source.

Obviously, this is your project and you'll run it as you see fit, and all these reasons are mostly conveniences. I'm looking forward to getting my Artemis group to give this a try.

[smcameron]

Wasn't planning on it, as... well, wasn't aware of anything driving such a requirement. I know that's kind of how cmake works, but... I'm not using cmake. So, why would I want to do that? I am not seeing what that would enable or what problem that would avoid. Not that I'm against it, but I'm not going to do it without some good reason.

To be honest, this response took me by surprise. I've been a professional software engineer for 20 years now and I've never worked on a project set up this way.

Not that it's relevant, esp. seeing as how this is only a hobby and not a professional project, but I've been a professional software engineer for 28 years, and I've seen plenty of projects set up this way. One example off the top of my head: fio. it would not be hard to find others, as this is more or less the old-school way of using make.

It would be easier for people to contribute if they know what's going on in the code, and having source files broken down into logical groups helps with that.

The entire project is...

{l Code}: {l Select All Code}

$ find . -name '*.[ch]' -print | wc
    158     158    2853
 $ find . -name '*.[ch]' -print | xargs wc | tail
     52     216    1383 ./vec4.c
    781    2155   17581 ./snis_marshal.c
      6      20      72 ./placeholder-part-points.h
    232     733    5815 ./snis_text_window.c
     25     106    1294 ./snis_event_callback.h
      6      20      70 ./placeholder-system-points.h
     85     228    1114 ./string-utils.c
     26      95     808 ./snis_gauge.h
      6       8     110 ./starbase-comms.h
  75069  388161 2886969 total


only 158 C source files and ~75k lines of code. So as these things go, this project is fairly small, and relatively speaking, it's not really hard to find anything. There is likely nothing you cannot find with a single grep (even what little token pasting is done is augmented with comments to enable grepping). Contrast with the asset importing library "assimp" ( http://assimp.sourceforge.net/ ) which last I checked was around 300k lines of code, and all it does is import 3D assets (incidentally, this is why I wrote my own asset importing code -- 2700 lines of it, roughly -- I can understand and debug 2700 lines a hell of a lot easier than the 300k of assimp.) And, have you ever watched someone work with a C++ codebase with visual studio? Almost invariably, they *have no idea* where anything is defined, unless they are the ones that wrote the bit of code they are looking at, and even then, it's iffy. They use the IDE to navigate the code. What file any particular piece of code is in does not matter for purposes of making the code easier to understand, and this only gets more true as the codebase grows (e.g. if your code base is multiple millions of LOC, you better have good tools, because you're not going to learn your way fluently around it any time soon.) Now, I don't use visual studio. I use vim and gcc and make. The more files there are, the more files there are to search through. There are a few reasons to break things up into separate files. That a file is merely large is not one of those reasons. Breaking a large file up into smaller ones only *for the sake of making the files smaller* makes things *harder* to find, not easier. The two largest C files in SNIS are snis_client.c and snis_server.c and they are both roughly 13k lines each -- not really all that big. The next biggest file is 3k lines.

And I have and do separate functionality out into separate files to form modules -- and if you take the time to look, you'll see that I am fairly diligent about defining reasonable interfaces and not polluting the global namespace unnecessarily and things like that. Is it perfect? No. But it doesn't need to be perfect. But in any case, you are talking about moving things around into different directories, rather than busting up files, and more specifically, you're talking about separating the build artifacts from the source files specifically by means of directories (they are already separated by naming conventions, mostly.)

Also, building into the source directory makes it really hard to package up the game for distribution, if you (or I) ever wanted to do that.

With that, I concede you may have a point. This has nothing to do with how hard or easy the code is to understand though. And as a counterpoint, there is already some packaging of snis going on around the net, https://aur.archlinux.org/packages/snis-git/ and moving things around would presumably break them (though possibly make it easier for them in the long run.)

Also, building into the source directory means that a mistake in the makefile could overwrite your source.

As could a mistake with the "rm" command, or any number of other shell commands. We have git and stacked git I don't think that overwriting the source accidentally via the specific vector of a Makefile mistake is a concern worth worrying about. git reflog will correct most such mistakes.

Moving files around may also introduce discontinuities in the git history -- "git log --follow..." is supposed to mitigate that, but, I am not super confident that it works perfectly.

Obviously, this is your project and you'll run it as you see fit, and all these reasons are mostly conveniences. I'm looking forward to getting my Artemis group to give this a try.

So, the point about packaging seems like it could be a legitimate one, but there are tons of other bits of software out there that build in a similar manner (the typical "./configure", "make", "make install" steps) that don't seem to have any trouble getting packaged up despite dropping build artifacts right next to source files.

And, while making a game is a goal for me, it is really a secondary goal -- the primary goal of this thing is for me to have a project to have fun tinkering with. Moving files around to different directories, potentially making the git history ugly... it's a little hard for me to get very excited about it.

[smcameron]

Been working on the names given to spaceships -- previously a random nonsense "alien" name was given to each ship, with some effort given to try to make it pronounceable and short, but ultimately the names were not very satisfying. So I've tried to make them a little more "sci-fi", while keeping a bit of the "alienness" here and there. Seems like an improvement, but I'll probably continue tinkering with it. Here are a few samples of the sort of names it now generates:

{l Code}: {l Select All Code}

scameron@spacenerd ~/github/space-nerds-in-space $ ./infinite-taunt | tr 'a-z' 'A-Z' | head -25
LUPHU STARRO
LIBRA WALRUS
SWIFT LIGHTRAY
PUSPE JADE
MOONGAZER HEAVENLY
JIO GRAVITON
ANDROMEDA TUI
SHOS TIEMPO
ACHO NIGHTSKY
ORBIT AURIGA
VISTA STARMAN
HEAVENLY VAE
CYGNUS WANDERING
OSHI STARWAY
STARCROSSER STELLAR
BLACKSKY WOLF
ALTO KRAKEN
GRYPHON TOPAZ
SCYLLA REDSHIFT
ALTA FORTUNE
PERSEUS BONZAAR
ASTERION BEAST
JEWEL SHINING
WALRUS ASCENDRE
ESTERON SAPPHIRE



[c_xong]

There's another spaceship name generator here: http://fantasynamegenerators.com/spaceship-names.php

And here's the source, which includes the dictionary (although there's no license): http://fantasynamegenerators.com/script ... ipNames.js

It's a simpler generator, as it only uses a single dictionary with an optional prefix acronym like "SS". It's made by the guy who's making Spryke (http://www.volnaiskra.com/), so it'll be cool if you can ask him about incorporating his code or at least his dictionary.

[smcameron]

Because getting a few friends together into a room with a bunch of linux systems wasn't quite hard enough, I have been experimenting with adding "warp gates" into Space Nerds In Space. Normally, there's a single server process which simulates the universe, and a number of client processes through which players interact with that server process. Well, I say the server simulates "the universe", but really, there's one big star in the center, a few planets, and a bunch of asteroids, along with a big fake starry sky as a back drop. It feels a little small, more like a solar system. So I thought, hey, it'd be kind of cool if you could run multiple server processes, each running their own "solar system", and have a way to travel from one to the other. That's what warp gates do. I've got a proof of concept running, although some critical pieces are still missing (e.g. when you travel from one system to another, you actually jump into a new ship that's local to that system, and so far none of the state of your old ship transfers to the new ship, and, what's more, if you jump back to the old universe, you end up in your old ship, which continued on it's journey without you when you first jumped out of the universe. So still quite a lot of work to do to get all that straightened out, but nothing insurmountable, I don't think.)

https://www.youtube.com/watch?v=4N0ILFW_ft0

[Vandar]

Nice idea. Also good to have one simulation process per system, that allows easy control over which parts of the universe you really need to calculate (e.g. system without players can hibernate, till someone enters).

[smcameron]

Spent all day today working on procedural clouds of a sort. Clouds have been in the back of my mind for quite some time, and I've been thinking of various ways to approach the problem. This morning I had a bit of an epiphany. I realized that my "earthlike" program, which sort of dynamically creates heightmap "brushes" on the fly by sampling real terrain elevation data and which it then paints onto a sphere, could also be used for clouds. Instead of sampling terrain elevation data, it could sample (slightly processed) satellite cloud imagery, treat it as if it were elevation data, and paint it onto a sphere in exactly the same way. This could produce a 6 seamless cubemap images of cloud texture. I could also modify gaseous-giganticus to take a cubemap image set as input and use that for initial particle coloration. So I could feed my cloud cubemap through gaseous-giganticus and see if I could get some neat fluid-flow going to make some weather systems or something. So that's what I've been up to all day. And it worked ok. Not quite as well as I was hoping it would, but ok.

Some images:


The above image is "earthlike" sampling from some cloud images without any fluid flow from gaseous giganticus.


I just like the fjords in the terrain generation here. Very Slartibartfastian.


Gaseous-giganticus working it's fake fluid-flow magic on the cloud field.


Clouds after having been through a bit of the gaseous-giganticus wringer.

Besides clouds, I have been working on the multiple universe idea a lot, there's still a lot left to do... uncommitted patches that I have on my stack currently:

{l Code}: {l Select All Code}

+ handle-multiple-display-monitors.patch
+ add-description-of-monitor-option-to-man-page
+ add-snis-multiverse-program.patch
+ make-snis-multiverse-connect-to-ssgl.patch
+ add-opcode-to-switch-servers.patch
+ try-multiverse-experiment.patch
+ make-snis-server-track-other-servers-via-lobby-client.patch
+ allow-player-to-buy-warpgate-tickets-at-starbases.patch
+ add-warp-gate-model.patch
+ add-warp-gate-objects.patch
+ make-warpgates-work.patch
+ make-snis-multiverse-listen-for-incoming-connections.patch
+ clean-up-snis_server-argument-processing.patch
+ allow-server-tracker-to-track-multiverse-servers.patch
+ add-notifier-to-server-tracker.patch
+ make-snis-server-connect-to-snis-multiverse.patch
+ make-snis-server-update-snis-multiverse-with-player-ship-data.patch
+ debug-multiverse-connection.patch
+ make-snis-server-transmit-player-data-to-snis-multiverse.patch
+ progress.patch
+ factor-out-stop_gameserver_writer-function.patch
+ distinguish-between-creating-and-joining-ships.patch
+ show-failed-login-attempt-msgs-on-client.patch
+ set-thread-names.patch
+ do-not-create-new-damcon-entities-on-warp-gate-traversal.patch
+ debug-it.patch
+ debug-warp-purchasing
+ transmit-sdata-from-snis-server-to-snis-multiverse
+ make-snis-multiverse-save-its-data-periodically
+ make-creating-ships-be-controlled-by-snis-multiverse
+ earthlike-changes
+ allow-gaseous-giganticus-to-begin-with-cubemap-images
+ gaseous-giganticus-allow-controlling-fade-rate
> increase-graph-dev-cubemap-texture-reload-delay



[smcameron]

Still tinkering with clouds...

[smcameron]

I think I'm getting better at this cloud thing...

If anyone would like to try their hand at this sort of thing I've outlined the procedure I used here How to generate earth like planet textures.

[Arthur]

Wow, seems like you store a lot of data in the cloud!
Keep up the good work.

[andrewj]

yeah, very very nice!

[smcameron]

I was looking at some images of Jupiter, and one thing that I've noticed is that it's got these "spots" for lack of a better word -- these circular whirlpools. My procedurally generated gas giants do not have these circular whirlpools, though they do occasionally have a bit of rotation going on. So I have tried to modify gaseous-giganticus to allow putting some whirlpools in by adding some code to manipulate the velocity field. The direction of rotation isn't always "correct" -- which is to say, comporting with the already present rotation of the unmolested velocity field. I can probably fix that though. Nevertheless, the experiments so far are not entirely failures. Here's one:

[charlie]

Looks fantastic, even if rotationally incorrect. :P

[smcameron]

As I have been working on making better assets for Space Nerds In Space, I have resisted the urge to update the assets in the main repository because I don't want to create a lot of churn as I keep dinking around with things. Also, at some point, the art assets should probably be separated from the code. I've also been thinking about how to distribute those assets. I don't have a very good answer for that yet. Nevertheless I have created a new repo just for assets. https://github.com/smcameron/space-nerd ... ace-assets

With a recent commit, I have at least separated out the assets that define a "solar system" to some extent. These assets are 1) planet cubemap textures, 2) central "star" texture, and 3) skybox cubemap textures. I have created a simple specification for such a combination of textures which now lives in share/snis/solarsystems/xxx/assets.txt where "xxx" is the name of the solar system in question. By default, there is a "default" solar system, which is the same one that's been in the main space-nerds-in-space repository since the beginning. I've created a new solarsystem, "tau-scorpii", which is in the new repository, space-nerds-in-space-assets. Copying the tau-scorpii directory into share/snis/solarsystems on all your SNIS clients and setting SNIS_SOLARSYSTEM=tau-scorpii before invoking quickstart (or using the --solarsystem option of snis_client) will make it use the new solar system.

Here are some pics:

[Vandar]

Nice work there on the clouds. I found good looking clouds quite difficult to create also. Real weather systems are a tricky mix of bands, swirls and flocks of satellite clouds.

Lately there are some images going around about "real" exoplanets. Like the ones in this article: http://www.heise.de/newsticker/meldung/ ... 43302.html

I wonder how they were made. The article says "artistic impression", so I guess they have little to do with the real exoplanets looks, but on the other hand, they look as if they were made with specific planet features in mind (color, bands, surface type, amount of fluid/rocky parts on the surface)

[charlie]

On the last image, with the 'ringed earth-like planted' in the background behind another planet, the rings are visible through the earth-like planet. :P

[Vandar]

Interesting, that planet must be an illusion, a space mirage. But what keeps the ring there? There must be something hidden in the mirage. Woot, exploration!

[charlie]

Interesting, that planet must be an illusion, a space mirage. But what keeps the ring there? There must be something hidden in the mirage. Woot, exploration!

Or it's a shader bug.

[smcameron]

It is indeed a bug, probably not in the shader, but in the engine. I have not so far been able to figure it out, but have known about it for awhile. Atmosphere rendering seems to cause some problems with depth sorting. By tapping the sysrq key a couple times (if your keyboard has it) you can bring up a menu which will allow you to turn off atmosphere rendering, and then the problems with depth sorting seem to disappear.

[psymin]

My apologies if this isn't the proper place to post a question like this .. but ..

Which joysticks would you recommend for the gunner position?

Just thinking of which things might help add to the "feel" of the system for players. If there are joysticks you've had more success with than others I'm all ears

[smcameron]

Good question. I have not used a joystick very much with this game at all, and for what little time I have spent using a joystick, it has been an xbox 360 controller. This also means the code has not been polished with joystick use in mind, so I expect using a joystick on the weapons station will not be as good an experience as it should be.

For a time in 2014, I was designing for my own use a series of "consoles" -- boxes with loads of switches, buttons, lights, knobs, faders, joysticks, etc, a unique one for each station, with a usb connection. There is some basic support for custom input devices in the code, and I got as far as rigging up a toggle switch to an arduino to trigger torpedoes to fire. The plan I had was to run a bridge sim with these consoles at ComicPalooza in Houston as part of the booth for the hackerspace I was a member of at the time. As part of that plan, there is a half-completed design for a 3D printable joystick I was trying to make here. But then I got a new job and moved to California, so that was the end of that.

Having said that, I can't help but be attracted to the HOTAS Warthog, just because, well, look at that thing. It's a tad on the pricey side though.

[smcameron]

Been playing around trying to make rocky cratered planets today...