This is a copy of a thread on freegamedev.net. Once around 2010 or so, I lost a similar thread over there for my other little game, Word War vi when the forum database was lost, so I created this as a backup in case something similar happens again.


smcameron 04 Nov 2012, 04:49

Hi guys... I've got a new project rolling these days...

https://github.com/smcameron/space-nerds-in-space

Still in the pretty early days, not even "playable" yet, really, though I expect to approach "playable" tomorrow or in the next few days (though no where near polished enough to be considered done.)

So this game (when it becomes a game) is very much inspired by Artemis Spaceship Bridge Simulator See: http://www.artemis.eochu.com/ The idea is you have a game which is played much as the actors in the Star Trek TV series played their roles on the bridge of the Starship Enterprise. There are a number of "stations": Navigation, Weapons, Science, Communications, etc. and each player assumes that role. Each station has it's own laptop or other computer which communicates via network to a central server which simulates the game universe. So it's kind of a cooperative multiplayer network game... No reason not to have multiple teams in multiple starships inhabiting the same server/universe either cooperating or doing battle.

Mine is different than Artemis Spaceship Bridge Simulator in that it is:

Here's a video from a couple days ago... (much progress since then.)

http://www.youtube.com/watch?v=BF19sPZGvmo (yeah... it's not much to look at yet.)

Hoping to be able to "drive" the ship around the "universe" and "shoot stuff" sometime tomorrow... we'll see.

-- steve


Skorpio 04 Nov 2012, 20:05

I'd love to see this game finished. Are you leaning more towards a simulation or an action game?


smcameron 04 Nov 2012, 20:23
Skorpio: I'd love to see this game finished. Are you leaning more towards a simulation or an action game?

Well, I'm not sure what you're asking...

It's going to be real time, but the action is probably somewhat slow, not frenzied. In some ways it's a simulation, but, also an action game?

In any case, I've gotten pretty far in the last day.

You can now drive and shoot, which as everyone knows, are the two most important activities of a starship captain.

Individual players can join the game at any time, and specify which starship to join, and multiple starships per game are possible. (this is all working now.)

That being said, you can pretty much *only* drive and shoot -- and the torpedoes don't ever hit anything, or die -- the torpedoes are immortal, just like everything else in the game so far (deleting objects from all the clients is not straightforward, but should be do-able, just haven't done it...)

-- steve


Skorpio 04 Nov 2012, 20:51

With simulation I meant a more complex game in comparison to a simplistic action game, but of course a simulation can be simple as well and contain lots of action (like the farming simulator :D ).


smcameron 05 Nov 2012, 04:14

Progress video... sorry about the low quality. The red lines esp. do not show up well in the video, but maybe you can still get some idea of what it's like.

http://www.youtube.com/watch?v=Jf6lttQN2A4&feature=youtu.be

-- steve


smcameron 12 Nov 2012, 02:08

Just a little update:

http://www.youtube.com/watch?v=fC0iFtF2I4A&feature=youtu.be

-- steve


smcameron 25 Nov 2012, 03:00

Got a lot done over the last week, as I was on vacation for Thanksgiving. Too lazy to do a video today, so just some screen shots:

Above is all the client modes (screens) Weapons, Navigation, Science, Comms, Engineering, and Debug. They are small because, like Word War vi, the graphics scale to match the window size, and I have shrunk them all down to fit on the screen. They are all separate processes communicating via network with a server process. The large screen partially shown on the right is the "main" screen. Any client process can "project" his screen onto the "main" screen by pressing "ctrl-O" -- O for "on screen!", as Capt. Picard so frequently says.

Above is the navigation screen. Left/right arrow keys rotate the ship, up/down arrow keys move the ship fore and aft. The Warp drive slider and "engage" button "warp" the ship instantly through space (the warp drive needs some work to make it a little more intuitave and, uh, dramatic as well.)

Above is the Weapons screen. Torpedoes may be loaded into the torpedo tubes (2) and fired at passing ships. This needs work (sound effects) and also, right now, a single hit invariable annihilates whatever it hits, so that needs fixing. Phasers don't work yet.

Above is the "science" screen (scanning). You have a scanning beam that you can swing around using left/right arrow keys. up/down arrow keys control the width of the beam. When the beam is wide, it's range is short, and the further away things are, they "fuzzier" they are. As you narrow the beam, the objects become less fuzzy. At a certain point, when things are un-fuzzed enough, you get some information about the ship, like it's name, position, bearing, range, heading, shield strength and wavelength characteristics. You can also zoom the science scope in and out using the mouse scroll wheel.

The "dotted" lines in the above still picture are kind of moving around and a bit more lively than they look in this picture, but you can't see it in a still shot.

Above is the engineering screen. There are 4 gauges: RPM, Fuel, Power, and Temperature. The idea is you have some sort of "engine" consuming "fuel" and producing "power" which can be distributed to the various systems. The power is a function of rpm and temperature. The sliders are used to distribute the power around the ship. The power distribution part doesn't really do anything yet (but the sliders work.)

Last, is the debug screen, which shows a map of the universe. The white dots (or, X's, if you look really closely) represent computer controlled ships. They are clustered around the "starbases" because the AI for these ships at the moment consists of "go sit near the nearest starbase."

Also, difficult to show, when you start up each client you can specify which "roles" it will fulfill -- science, weapons, navigation, etc. ("all" is an option.) Additionally there is a "soundserver" role, so that sounds which are global to the ship -- e.g. being hit by a photon torpedo -- can be directed to the system that is connected to the big stereo. Sounds also may be directed to individual stations -- so you could get distinctive science-y beeping noises from the science station laptop, and weapons-y noises from the weapons stations etc. Not that any of those sounds are in there yet, but the infrastructure to do it is there in the code.

No 3d "thru the window" view yet --- if I do it, it will be a totally software z-buffered flat-shaded triangle renderer that looks like it's from a 1982 silicon graphics workstation. You'd probably rather someone besides me programs that bit, lol. As would I, as would I.

-- steve

p.s. Not getting a lot of feedback... wonder if I'm wasting my time creating a game that requires you get together 4-6 of your linux/startrek nerd friends on a LAN to play, lol. Well, it's a fun waste of time programming the thing, and, I am learning a bit doing it, so... I'll keep at it. I do worry that the various stations won't actually be *fun enough* though -- trying to program in some "fun", but, also keeping to the spirit of the thing -- the "fun" may depend more on the personality of the participants than on the game content for this sort of game, not sure.


charlie 25 Nov 2012, 06:03

It's not pretty, which sadly limits any kind of exposure.

However it looks really interesting.


Myckel 25 Nov 2012, 17:48

Looks more and more as something I might want to check out. How easy would it be to change the vector-interface to allow (backdrop) images, to make it more pretty?

3D would be great on the long term.


smcameron 25 Nov 2012, 20:01

Well... probably if I switched from basic gtk/gdk line drawing and so on to cairo, compositing a backdrop image -- even scalable -- would be possible, similar to Dueling Masters of Space Time. http://smcameron.github.com/dueling-mas ... pace-time/ Performance might be iffy on low end machines, but, eh, it'd probably be ok. To some extent, I think the "looks" of the thing aren't necessarily all that important, what's important is that is should be "fun", and fun and looks are not necessarily correlated, and maybe a lot of the "fun" of this particular game may come from the people playing it, we'll see, I guess.

The one place I think that the looks probably do matter quite a bit would be in the as-yet-unimplemented 3d "out the window" viewscreen.

I need to hurry up and get things far enough along that I can get some people together to play it and see what it's like.

-- steve


charlie 25 Nov 2012, 21:59

I wouldn't worry too much about the looks, I didn't mean it in a critical way.

Not everything can be Crysis 3, and to be honest I like the quaint style you use, I think Word War Vi is great. Like you say; priority is gameplay first.


qubodup 26 Nov 2012, 14:06

This looks exciting! What self-ironic name. :) (It might make sense to make some things in the game nerdy-funny-ironic, rather than nerdy-serious, too. in-game warning messages perhaps.)

The look is quite TTY-retro but dark-blue-on-black is very bad to read. I recommend light blue instead for the weapons screen.

If you enjoy tweaking the color palettes, here are some inspirations:

http://commons.wikimedia.org/wiki/File:USS_Conquest_(MSO-488

If you prefer to not care about that but are interested in people testing other color palettes and posting screenshots and diffs, let us know.


Skorpio 26 Nov 2012, 20:25

I've been working on some new top-down spaceships (and mechs), just for fun, and wondered if you have a use for them. Or are you going for a more abstract look and 3D graphics for the screen? If you want 3D ships, then you could probably utilize the shipyard on OGA.

Btw, I think the term phaser is protected and you should better replace it.


smcameron 26 Nov 2012, 22:29

I'm probably going for a more abstract thing than those top-down views. The shpyard may come in handy when I get to the 3d stuff. (I have vague notions of metaprogramming OpenSCAD to procedurally generate spaceship models, but haven't thought very hard about it.)

As far as "phasers" being a protected term... I'm a little skeptical. Games like Netrek (http://www.netrek.org/ ) contain "phasers" ( http://www.netrek.org/beginner/newbie.php) , as do all the old text based star trek games. If a lawyer writes me a scary letter, I'll worry about it then.

For now, getting the game into a playable state (and I think the 3d view is not strictly needed for that) is the highest priority.

-- steve


smcameron 02 Dec 2012, 04:11

https://www.youtube.com/watch?v=geGwx384Fh4


schmidt100 11 Dec 2012, 11:06

This game looks really nice. Its impressive to see the fast progress and all the new things. Keep up your interesting work, I`ll follow your posts. Do you have any idears of goals for the players, beside flying around in space?


smcameron 12 Dec 2012, 01:26

Do you have any idears of goals for the players, beside flying around in space?

Well, as a start, various ships will attack various starbases, as well as your ship, so you try to intervene, etc. and stay alive.

Additionally, multiple player-controlled starships may inhabit a server, so either cooperative or combative play is possible. "Space" being kind of wide open (and in my implemenation) kind of two dimensional, there's not much opportunity to hide-n-seek, or have elaborate strategies that I can think of for multi-ship combat. Will have to think about some ways to liven that up and make things more interesting.

Farther than that, I haven't really given it much thought, just trying to get the game to a playable state for now.

If you have some particular ideas, feel free to share, but of course I can't guarantee I'll ever get around to implementing any of them.

Ideas that allow simple things to be combined in interesting ways that lead to some interesting emergent behavior are probably the best, but that is kind of a tall order.


smcameron 21 Dec 2012, 06:22

Just a little progress update...

https://www.youtube.com/watch?v=XqXw85tyhXU&feature=youtu.be


smcameron 10 Jan 2013, 02:42

Lot of progress in the last few weeks.

Tons of refactoring to make the UI code ... start to resemble some sort of UI framework. Frightening.

Added a network setup screen from which you can launch the lobby server and the game server from the client and connect the client to the aforementioned.

And, added a wireframe 3d renderer.

https://www.youtube.com/watch?v=cZVxT4L4hJw&feature=youtu.be

-- steve


Evropi 10 Jan 2013, 15:26

Nice! What is the classical music playing in the background by the way?

BTW, you may wanna try actually, err, using a screen recorder (FDesktopRecorder is the one I find the best for Linux). Also, if you find OpenSCAD slowing you down, try BRL-CAD. It's much more powerful, and in many ways, the granddaddy of the CAD programs today, made by the American army. I'll just quote Wikipedia on it:

The BRL-CAD source code repository is believed to be the oldest public version-controlled codebase in the world that's still under active development, dating back to 1983-12-16 00:10:31 UTC.

You know your program is mature when it is still in use and development today and its original author is dead (another example: the C programming language) :)


smcameron 10 Jan 2013, 19:37

Evropi: Nice! What is the classical music playing in the background by the way?

I believe it's Bach, the Brandenburg Concerto.

BTW, you may wanna try actually, err, using a screen recorder (FDesktopRecorder is the one I find the best for Linux).

Bit of a hassle with the audio then... pointing the camera at the screen is trivially easy, and I'm lazy, though it does give sub-par results.

Also, if you find OpenSCAD slowing you down, try BRL-CAD. It's much more powerful, and in many ways, the granddaddy of the CAD programs today, made by the American army. I'll just quote Wikipedia on it:

The BRL-CAD source code repository is believed to be the oldest public version-controlled codebase in the world that's still under active development, dating back to 1983-12-16 00:10:31 UTC. You know your program is mature when it is still in use and development today and its original author is dead (another example: the C programming language) :)

Interesting. I'll have to take a look at that. It appears to be a bit of a monster compared to openSCAD.


hc 10 Jan 2013, 23:53

+1 for openscad. I'm aware of brlcad and it's history for a some time btw.

But for programmers openscad seems like an awesome tool - again because I'm a fan of parametric and procedural design.

On the other hand maybe I've missed similar features in brlcad?

Can it do CSG operations like intersection, subtraction and addition on 3D geometry and that parametrically scripted with macro/modules

Would be nice if you can surprise me.

Edit: The MGED Quick Reference card shows a brlcad programming example with variables, loops and conditions. But openscad seems 'turing' complete, looks familiar and decomposition into modules (like C functions) is simple and obvious, too.


smcameron 12 Jan 2013, 08:26

hc:

But openscad seems 'turing' complete, looks familiar and decomposition into modules (like C functions) is simple and obvious, too.

I'm a big fan of openSCAD as well. I'm not actually sure whether it's turing complete or not. It does have some pretty severe limitations (e.g. the "variables" you get in openSCAD act more like constants than like variables.) For this reason, I came up with openCSCAD, which is a tiny little C library for outputting openSCAD code. (It's kind of a neat little hack at best, and a useless piece of crap at worst, lol.) It does technically get you nice things like real variables, recursion etc. but at the cost of massive openscad file output which may or may not really be processable by openscad. (e.g. the tree picture on that page was done by screen shotting after pressing F5, not F6. F6 in openscad actually does all the reall CSG stuff, and doing all the intersections of all those branches, etc... well, you may or may not live long enough to see that computation run to completion.)

Haven't yet looked at BRLCAD, as I have no pressing need, and it looks a bit daunting.


hc 12 Jan 2013, 23:12

Hm, assumed that recursion in OpenSCAD would work - which would still make it a more or less complete functional programming language for solids even without variables - but it didn't work. It gave no errors for module-recursion but didn't work as expected, duplicating and renaming the duplicate method code did of course. Yes, seems pretty static compile time and incomplete but for technical/mechanical models it should be enough. As for BRL-CAD: Can't imagine a tank having fractal structures ... unless for stealth someday ;)

Yeah, generating code from code is of course an option - besides openSCAD's code-editor isn't the best. OpenSCAD's loops should suffice most of the time, I think I'll try when in need of recursive structures.

Wouldn't mind if Admins would move this discussion about tools somewhere else - don't want to divert from the interesting work in progres topic.


smcameron » 13 Jan 2013, 05:06

hc:

besides openSCAD's code-editor isn't the best.

Yes. I'm pretty sure the openSCAD developers know this, because they provided a "hide editor" option, and the F3 key reloads the source file. What I do is have vim going in another window, and switch between the two with alt-tab. Save from vim, alt-tab to openscad, F3, then F6, then alt-tab back to vim -- that is essentially the "edit compile debug edit" cycle for me with openscad.


hc 13 Jan 2013, 14:08

Ah, I see: It's an integrated spare wheel editor. :)

Well, seems there are command line options for running automatic scad -> stl conversions, too, might become handy.


Brian Rubin 26 Feb 2013, 22:42

Hello! I just registered so I could find out more about this game. I have a site that covers space games called Space Game Junkie, and would love to learn more about your game so I could share it with my readers. :)


smcameron 27 Feb 2013, 02:29

Brian Rubin:

Hello! I just registered so I could find out more about this game. I have a site that covers space games called Space Game Junkie, and would love to learn more about your game so I could share it with my readers. :)

Alright. What would you like to know?

-- steve


Brian Rubin 27 Feb 2013, 02:37

Oh, stuff like inspiration, time spent working on it, how much work it took in creating it, planned features and such like that.


smcameron 27 Feb 2013, 03:32

Brian Rubin:

Oh, stuff like inspiration, time spent working on it, how much work it took in creating it, planned features and such like that.

Ok....

Inspiration, well obviously Artemis, as I've mentioned. I've never played it myself, but I've seen youtube videos, and it seemed like a cool idea, and not having (nor wanting) a windows machine, I figured, well, I guess I've got to make my own version. This is a bit of a pattern for me, as another game, or more like a novelty than a game which I made, called "Be The Wumpus" came in to existence in the same way -- taking the kernel of an idea of an existing Windows-only game and making my own version of it. Of course, the Star Trek TV series also informed the design of the game to an extent -- same as it did for Artemis, presumably.

Time spent working on it... hmm, well, as the painters say, my whole life up to this point. Well, I first began working on the network part of it, in the form of a generic lobby server which can be found here: https://github.com/smcameron/ssgl although that code is out of date and buggy compared to the variant which is found within SNIS -- need to fix that, I suppose -- about 2 years ago I guess (according to github). I got bogged down with that when I couldn't figure out how to do NAT punchthrough for peer-to-peer connections. So that lay fallow for a couple of years. But, the initial impetus for the lobby server was to make a game similar to Artemis, and that would have been in the fall of 2010, when I first became aware of Artemis. But, I got bogged down in the NAT punchthrough, and Christmas rolled around, and vacation, and I got distracted, and just dropped it. I think I also had some of the network code for SNIS partially done (but buggy as hell) at that time. But in any case, I dropped it at the end of 2010.

And then, in November of 2012, there was a "hackathon" at Platform Houston ( http://www.platformhouston.com/ ) and I knew one of the guys involved in that place, so I said sure, I'll go to this hackathon, which was a 2-day weekend thing, see what you can cook up in two days. So I was kind of fishing around for ideas of what to do, and I thought of this old idea of doing a variant of Artemis, and I remembered Space Nerds in Space that I had started back in 2010, so I thought, ok, let me pick up that ball again.

So I spent a couple days of hard programming getting that onto it's feet. So, all the infrastructure work that I did in 2010, building the lobby code, and the network code, that, by itself, did nothing, and was quite a lot of drudgery to write (all C code, from scratch, not much in the way of pre-made libraries, just because, that's how I roll, usually, not for any good reason other than sheer pigheaded stubbornness, really) -- all that work served me pretty well, and having taken that long break, well, I got the thing to where you could 'drive" and "shoot", and had several different "screens" all potentially separate processes communicating via network working in those 2 days. And of course I re-used a lot of ideas and code -- esp. the font system -- from Word War vi -- so the graphics kind of have that look -- everything is drawn with lines, so everything is scalable. One thing that has always irritated me is when you start up a game and it's at a fixed resolution, and esp. old games written for low-res systems that now look tiny on modern systems, so I tend to make my games scale. Anyway, I digress.

So, over Thanksgiving I had a good solid week off work, and put that to use on SNIS, and made a lot of good progress. Most recently, I've gotten bogged down in the 3d graphics aspects. This is probably a mistake, in several ways. First, I was trying to make my own software 3d renderer. It soon became clear that 1) debugging the thing is really hard for me, 2) it's not fast enough. So there are a couple possible solutions to that, one would be to use gtkglext to do the graphics and well, I'd have a different set of bugs (that I would presumably create) to worry about and lose some portability, but it should be plenty fast, and the other possibility is just use a wireframe renderer (already done, mostly) and don't worry about making the 3d graphics all fancy. If it's good enough for Elite on the old BBC micro, then it's just plain good enough, right? :) Esp. considering the game is fundamentally a 2D game, so the 3D graphics are somewhat superfluous, *except*, for that starship bridge experience with a big projection screen, you've got to have some kind of "out the window" view, right?

As far as planned features, well, I suppose I would aim for the minumum set of features that will make a fun game, as a start. That is, each station has got to have enough for the players to do, and behave in ways that encourage cooperation between "crewmembers", the crew has got to be able to get their ship into interesting and dangerous situations and be able to get out of them (or not) in some kind of interesting and fun way, and basically have something to do, other than merely mindlessly driving and shooting.

The game as it stands today is not ready to be reviewed or played. For starters, there are some bugs that need fixing first, but there is quite a lot else that needs doing.

In the last few weeks, I've been distracted from SNIS, (adding shiny laser projector support to Word War vi, and other little amusements).

But, I hope to get back to SNIS development soon.

Feel free to ask more questions.

-- steve


Brian Rubin » 28 Feb 2013, 05:42

Hmm, might I use this on my blog as an impromptu Q&A of sorts?


smcameron 28 Feb 2013, 16:31

Brian Rubin:

Hmm, might I use this on my blog as an impromptu Q&A of sorts?

Sure.

If you're on G+, we could do a hangout, if you think that might work better.

-- steve


Brian Rubin » 02 Mar 2013, 02:53

smcameron:
Brian Rubin:

Hmm, might I use this on my blog as an impromptu Q&A of sorts?

Sure.

If you're on G+, we could do a hangout, if you think that might work better.

-- steve

Huh, I totally am, and it totally could. Could you use the contact form on my website to send me an email so we can continue this discussion?


charlie 02 Mar 2013, 14:04

He can use the email button on here (as could you) in the user profile to the right of each forum post.


Imerion 18 Mar 2013, 17:23

Wow! I had no idea this project existed, but it seems fantastic! Would love to get a few friends together and play this once more finished. Thanks for creating it and keep up the good work!


farcodev 19 Mar 2013, 04:11

A bit off-topic sorry, but a Freegamer G+ circle would be cool.

Keep it up smcameron!


smcameron 08 Apr 2013, 05:51

Just a little update...

https://www.youtube.com/watch?v=aKG_uUBsme4&feature=youtu.be


charlie 08 Apr 2013, 14:32

My inner Spock says, "Live long and prosper!" \\//_


farcodev 08 Apr 2013, 23:48

Very good job!

It takes shape very well :)


smcameron 14 Apr 2013, 03:12

[deleted] (thought better of it. Don't worry you didn't miss anything interesting.)


smcameron 17 Apr 2013, 16:58

FWIW, thought I should mention that there's a fork of Space Nerds In Space on github now... the dude appears to be rewriting the whole thing in C#. Well, that was unexpected.


JeffM2501 17 Apr 2013, 18:42

So far it seems to be going pretty well.


smcameron 20 May 2013, 03:49

Just a progress update. Here's a little video showing the new Damage Control station:

https://www.youtube.com/watch?v=gkNfBEh-EsU&feature=youtu.be


JeffM2501 20 May 2013, 23:51

While I agree that the activity in Artemis is a bit lacking in interactivity, do you think that this may be too far the other way? How long will it take someone to fix a system while ignoring the rest of the interface? I fear that this may not be something someone is willing to do in the heat of battle.

I dig the fact that you are going outside the box here, but is this now a chore to fix something?

Also can you get repaired faster by docking with a friendly starbase?


smcameron 21 May 2013, 00:18

JeffM2501:

While I agree that the activity in Artemis is a bit lacking in interactivity, do you think that this may be too far the other way? How long will it take someone to fix a system while ignoring the rest of the interface? I fear that this may not be something someone is willing to do in the heat of battle.

You may be right. We'll see. Once I had the idea, I couldn't get it out of my head any quicker way than by implementing it. An "autonomous mode" in which the robot performs his functions by himself is probably a good idea, if for no other reason than it might be hard to get enough crewmembers together to play all the stations.

I dig the fact that you are going outside the box here, but is this now a chore to fix something?

To some extent the entire game is a series of chores. Normally starship crew get paid, I expect. :)

Also can you get repaired faster by docking with a friendly starbase?

I don't know, haven't got all this planned out, I'm making it up as I go.


Evropi 21 May 2013, 09:42

Yeah, I too thought this felt like an overly-repetitive chore. I would really not want to go through this minigame more than once to fix my spaceship.

You know what would be better? If you install new stuff on your ship and manually lug them around (fixing should, preferably, be automated). It would definitely... personalise your ship more. I envision something like Secret Bases in Pokemon games (I know, I know...) where you can put useful things as well as decorate the place with gratuitous plants and tables and chairs and so on.


JeffM2501 21 May 2013, 17:14

Componentization is a good thing but I think you are pondering the wrong aspects of it. What I think would be fun would be to build up a ship from a set of modules that contain equipment. So you can upgrade your Warp, or beams, or add more missile tubes.

These type of games don't really let you walk around the ship to see tables and chairs, the idea is that your physical computer screen is the console you use as a crew member of the ship and the 3d view you see is ether out the window, or in this case a camera above the engineering bay (that somehow magically can follow the robot)


Part of my motivation for the whole "damcon arena" as I call it, was to provide something for the players to say to each other.

I imagine:

Captain: "How's that warp drive repair coming, Scotty?"

Scotty: "Fine, I just have to get the transient wormhole suppressor reinstalled and we should be good to go."

And Scotty wouldn't just be merely "repeating what the computer says" (a la galaxy quest), he would actually _mean_ that he really was trying to re-install the transient wormhole suppressor into the warp drive in the game.

Whether that's really good enough reason, and whether it's worth while... I don't really know. I'll think about it some more.

It's also arguable that I haven't succeeded in getting very far away from having the player just "repeating what the computer says" in that the names I came up with are obviously just pseudo-space-jargon gibberish with no actual meaning or relevance.

(tentative list of components is here... https://github.com/smcameron/space-nerds-in-space/blob/master/snis_damcon_systems.c

-- steve


JeffM2501 21 May 2013, 23:23

The concept of the mini game is good. Something does need to be done more then

"waiting on the blue dots Sir".

I was going to look into some kind of power routing thing so it can be "Just have to shunt the drive matrix through the hyper inverter Sir"


smcameron 28 May 2013, 06:47

Just another progress update. Been working on 3d models, and the 3d "out the window" view with my very limited 3D programming chops. Hence why it's wireframe and looks like it came from the days of DOS.

https://www.youtube.com/watch?v=ToHnLq0TfBY&feature=youtu.be

There's no view frustrum culling, so things which are behind the camera show up upside down and reversed. If someone well versed in the ways of the 3D matrix wants to take a stab at view frustrum culling, the relevant code is in entity.c, probably in render_entities() or render_entity().

https://github.com/smcameron/space-nerds-in-space/blob/master/entity.c (not that I really expect anyone to pick that up and run with it, but stranger things have happened.)


charlie 28 May 2013, 16:22

It looks pretty cool. It really reminded me of something.


smcameron 04 Jun 2013, 04:43

Just a little progress update. I think all the wierd glitches in the 3D view have been sorted out now. If you've been keeping up with this thread and the videos so far, you may want to skip ahead to about the 5:00 minute mark to see the new stuff.

https://www.youtube.com/watch?v=zhgPbECMtq8&feature=youtu.be

--steve


smcameron 12 Jun 2013, 05:16

Just another progress update, Jun 11, 2013:

https://www.youtube.com/watch?v=_7aaKKBogDk&feature=youtu.be


smcameron 16 Jun 2013, 22:23

Tried to do a multiplayer run at Houston's hackerspace, TX/RX Labs today, but ran into technical issues with the network. It seems the machine hosting the server process would randomly get re-assigned a new IP address. Needless to say any TCP connections established with the old IP address ceased to work. The projector screen was also terribly washed out due to it being the daytime and light flooding in through the skylights. Maybe next week will be more successful.

snis-at-txrx


farcodev 16 Jun 2013, 23:28

Keep it up! :)


smcameron 17 Jun 2013, 00:00

BTW, in case people want to try this game (in its current unfinished state), but don't have enough linux-using friends, here's how you make a bootable live dvd containing the game that can be run on windows machines without disturbing it at all, which is what I had done for the above picture, as all those machines are windows boxes. This does assume a 32-bit Mint 13 linux install (you could install it in a vm to make the dvds, I guess.) This worked for me... if it doesn't work for you, well, you're probably on your own for now.

 Install the package "mintconstructor" from the repositories
   sudo apt-get install mintconstructor

    Open a terminal
    Type sudo /usr/lib/linuxmint/mintConstructor/mintConstructor.py
    In the mintconstructor window that opens:
   In the "Directory" field, choose a directory for the ISO (use a new
   directory with nothing in it for this) Make sure to select the
   "New project" radio option
        Click the browse button on the right of the "ISO file" field and
   point it to your ISO file
   (in my case I used linuxmint-13-cinnamon-dvd-32bit.iso  from here: http://www.linuxmint.com/edition.php?id=105
        Click "Next" and then "Yes" to confirm.

    Wait for it to do its thing for a bit, then click the button it
    presents to open a chrooted environment (it opens an xterm).  In
    the xterm:

    apt-get install build-essential
    apt-get install portaudio19-dev
    apt-get install libvorbis-dev
    apt-get install libgtk2.0-dev
    apt-get install git
    apt-get install stgit
    apt-get install openscad

If the openscad package isn't around, you can get it from here:
http://www.openscad.org/downloads.html
 and then from outside the chrooted environment, copy
openscad-2013.0.x86-32.tar.gz into your chroot directory/root
   Then, back in the chrooted xterm:

   cd /root
   tar xzvf openscad-2013.01.x86-32.tar.gz
   cd openscad-2013.01/
   ./install.sh
   cd ..

   git clone https://github.com/smcameron/space-nerds-in-space.git
   cd space-nerds-in-space/
   make

   (now Space Nerds in Space has been built within the chrooted env.)

    Once you're finished making modifications, make sure to clean up with the following commands:


    Now clean up the chrooted env (and yes aptitude takes the weird
    tilde options for some reason):

    aptitude purge ~c
    aptitude unmarkauto ~M
    apt-get clean; rm -rf /var/cache/debconf/*.dat-old; rm -rf /var/lib/aptitude/*.old; rm -rf /var/lib/dpkg/*-old; rm -rf /var/cache/apt/*.bin; updatedb
    history -c
    rm /root/.bash_history
    rm /root/.nano_history
    history -c
    exit

(xterm will close)

    Click Next
    Give your ISO a description (which will be embedded as the name of the CD
or USB stick onto which the ISO is burnt)  Don't pick too long of a name though
because if you do, it won't work.
    Click Next

Iso image will be made

Then to run the game, burn the iso to dvd several times, and boot up all your machines from dvd.

Open up a terminal, type "sudo su -"

(no password -- it's a live dvd)

Then, cd to space-nerds-in-space

Has to be root because we installed spacenerds in space into /root/space-nerds-in-space above when making the dvd -- this could be worked around by chowning it all to user "mint", perhaps putting it someplace else before making he ISO image, but I don't have the exact instructions to do that, and didn't think to do it,but if you're paranoid, you probably want to think about that.

Repeat for several machines on your lan, say, five of them or so.

On one machine that is connected to a projector, note the IP address: (run ifconfig to figure this out.)

Then start the snis client:

./snis_client

From there, start the lobby server on localhost, start the gameserver, connect to lobby, and connect to the gameserver.

Note the shipname and password you use (make up what you want).

On the remaining machines, start snis_client, replace the lobby host "localhost" with the ip address noted above, fill in only the shipname and password as above, and connect to the lobby, then to the gameserver. You can be choosy about the 'roles' for each station at this point, but you don't have to.

That's it.

edit: btw, prior to making live dvd iso's and burning a bunch of dvds, we tried to run the game in linux installed to virtual machines on the windows boxes -- that didn't work out so well, performance was kind of crap for whatever reason. With the dvds, performance was fine at least for the few minutes the network was working.

-- steve


charlie 17 Jun 2013, 10:25

That's good info steve. My one concern is that you don't just leave it here in the forum but get it up on the website.

Do you even have a website yet? :shock:

A github wiki would do...


smcameron 17 Jun 2013, 14:25

No, don't have a website yet, though I've been meaning to make one. I suppose I was hoping to have some tolerable video of real multiplayer action before putting up a website, on the theory that not having a website is ok for now since the game is still in a really rough state as far as playability goes. Not sure I want to make a whole bunch of noise about the game only to have people try it in it's half finished state and conclude "this sucks!" I will probably just use a gh-pages branch on github.

-- steve


smcameron 20 Jun 2013, 14:31

Running on a Raspberry Pi:

https://www.youtube.com/watch?v=p3tiFIAINVQ&feature=youtu.be

(Not my video, btw)


smcameron 22 Jun 2013, 13:29

Last night, ran a multiplayer session for the first time. IT WAS AWESOME!

A little rough around the edges, things are a bit unbalanced, and the game play is a little more frenetic and crazy (and hilarious) than I'd imagined it would be. Didn't really feel like "Star Trek", but it was pretty fun. In general, it was a big hit, definitely onto something cool with this game.

Unfortunately didn't get any video footage of the mayhem, or even any pictures. Maybe next time.

-- steve


charlie 22 Jun 2013, 14:18

Yes, next time do get some footage!


qubodup 23 Jun 2013, 01:25

smcameron:

Unfortunately didn't get any video footage of the mayhem, or even any pictures. Maybe next time.

Aaaaawww.

The most fun to present games at the recent game jams that I was part of were the ones where the audience could vote on what action to take (multiple choice text adventures for example). And Space Team is amazing fun with two players already. I can only imagine how amazing it must have been...

So yeah, video please next time. :)


smcameron » 29 Jun 2013, 15:15

Here's a bit of video from last night's attempt. Got off to a bit of a rough start when the server process crashed with an assert inside pthread_mutex_lock (no doubt a glibc bug ;-). Moved the server to another machine and ran it under valgrind, and we played the game for about an hour with it running under valgrind, which found nothing. Lots of rough edges with the game play that need tuning, not to mention all the functionality that isn't in the game yet, but, it's very good to finally have it in a playable state, more or less.

The video's a bit dark, and esp. the projector screen doesn't show up very well, next time I'll bring the DSLR, maybe that will help.

https://www.youtube.com/watch?v=gCfrT0N0FGA&feature=youtu.be


farcodev 29 Jun 2013, 19:16

Haha good one when they begin to act as a team.

Great progress! I hope that you will not be annoyed by any more network problems in the future.

Keep it up!


smcameron 12 Jul 2013, 04:43

Just a progress update. Had a week off around July 4, and I used it to totally re-vamp the power-system of the ship. Now all systems are modelled as a resistive network with a fixed voltage, capped current power supply. So long as the resistive load does not exceed the max current that can be supplied, voltage is constant, and the requested power is delivered. When the load requires more current than the supply can deliver, voltage drops, current decreases. Gives a rather natural way to couple all the power consuming systems together.

Additionally, I've done a lot of work on the "DEMON" screen, and now, from this screen, you can delete things from the universe, add things to the universe, become a puppet-master for any non-player ship, able to drive it, shoot the weapons, and transmit communications from any non-player ship. By this means, you can act as game master and provide a little puppet show for the rest of the players.

Some video of the latest code:

https://www.youtube.com/watch?v=TUp0h6h7qI8&feature=youtu.be


smcameron 23 Jul 2013, 03:50

My software renderer is working pretty well these days. Just flat shading, no texture mapping or anything fancy, but still I'm pleased.

Also has retro wireframe mode (press 'r' on the main screen to cycle through the renderer modes).

Here's an "epic space battle" of sorts: (note: skip to 27s mark to get to the action. The forum's youtube tag doesn't appear to allow you to tack on a t=0m27s URL parameter to automatically do that, unfortunately.)

https://www.youtube.com/watch?v=KcEbCyKU0Qs&feature=youtu.be

I'm pretty pleased with the progress I've made on this game so far, I think it's really coming along nicely.

-- steve


smcameron 05 Aug 2013, 00:53

Just a few screen shots showing some new models, laser fire, and simple lighting stuff. By modern standards, not too impressive, but considering it's done with a software renderer I made myself from scratch, I'm fairly pleased with it.

Hmm, if your screen is small, this board seems to clip the images rather than scale -- you might want to hit ctrl-minus to shrink things down to be able to see it all.

"Research vessel" model plus new station model.

Skorpio ship model.

Taking laser fire from an asteroid miner.

Disruptor and new station model. Note the lighting is from below.

Taking laser fire from a distance, and new starbase model.


smcameron 12 Aug 2013, 01:50

Got side tracked a little bit... I was thinking about spaceship models, and how making them by hand was difficult, and I remembered shipwright -- that procedural spaceship generator that slams a bunch of canned, hand-made parts together somewhat randomly, but in pairs, and in ways that maintain bilateral symmetry, and I got inspired a little bit, though I was dissatisfied with the results of shipwright -- which is here, btw: http://ship.shapewright.com/

So, yesterday I started hacking on a little bit of openscad metaprogramming to make me some freakin' spaceships.

I called my program "ship not even wrong", (inspired by "shipwright", and by that famous quote of Wolfgang Pauli)

My program is here:

https://github.com/smcameron/opencscad -- in the ship-not-even-wrong subdirectory. It relies on opencscad to produce openscad code, and of course on openscad to process the models.

Typically, a big ship will take 30000 triangles or something, so it's probably not actually suited to Space Nerds In Space as it currently stands -- my poor little software renderer is brought to its knees by such large models. Though I did manage to get some screen shots anyway.

Oh, and the SCIENCE screen now has a "DETAILS" button that shows a rotating 3d wireframe model of the selected target...

So... too many triangles for SNIS currently, but perhaps someone else will find this freaky spaceship factory useful or entertaining. Here's a little video showing lots of ships:

https://www.youtube.com/watch?v=VnyerXljmrQ&feature=youtu.be

-- steve


smcameron 23 Aug 2013, 18:45

Incremental progress.

I've added a "Tractor Beam" (that doesn't really work yet) and the Science station can now view 3D models of whatever it's scanning, and now ships are not all confined to the same flat plane, and I've started adding some lua scripting abilities.

https://www.youtube.com/watch?v=6BUt21fBlRw&feature=youtu.be


smcameron 09 Sep 2013, 03:07

Just a progress update. Converted to use opengl. I am however, still using the software renderer, just all the 2D drawing (e.g. triangle fills) is done with opengl. Plan is to replace the software renderer, but I'm not that far along yet. Only real 3d stuff done with opengl so far is the skybox. Oh yeah, I made a little (not very sophisticated) skybox program: https://github.com/smcameron/cosmic-space-boxinator

I also figured out how to get recordmydesktop to stop garbling the video (use the --on-the-fly-encoding option.). Unfortunately it now garbles the sound. So here's a silent video showing the new skybox.

https://www.youtube.com/watch?v=aZqBO-FdNZs&feature=youtu.be

--steve


charlie 09 Sep 2013, 10:57

Video capture on Linux is a minefield. I've yet to find a solution for just reliably recording from my webcam, let alone capture the desktop as a stream. Hours of research and hours of frustration for what should be a really well solved task. A new client seems to pop up and look promising every year then succumb to bitrot.


Julius 09 Sep 2013, 11:21

charlie:

Video capture on Linux is a minefield. I've yet to find a solution for just reliably recording from my webcam, let alone capture the desktop as a stream.

Not sure how well it captures video streams and OpenGL apps, but for a regular screencast the build-in tool of Gnome Shell (Gnone3 etc.) is pretty awesome (but not very well known): https://wiki.gnome.org/GnomeShell/Features#Screencast_Recording

smcameron 16 Sep 2013, 03:39

Not too much to report this week, other than that the lua scripting is coming along and is now to the point that simple mission scripts are possible. There are still a lot of entry points and callbacks and what not that would be nice to have -- I'm taking it somewhat slowly to try to avoid an API explosion, since I don't have a very good feel for the sorts of things which are a good idea vs. a bad idea for such APIs, other than that it's probably better if the lua API is small, rather than large.

Here is a bit of documentation about the Space Nerds In Space lua API, still subject to change obviously.

Here are a couple of mission scripts I've made so far:

* Training misison 1 -- kind of a race around a circuit to dock with 4 starbases -- in case it's not obvious (it isn't) the way to dock with a starbase is get very close to it, then type "dock" in the comms screen. In general, all the commnications from these scripts with the player occurs via the comms screen.

* Training mission 2 -- the obvious mission, decoy mayday call leads to ambush.

I am open to ideas about the sorts of things such an API should provide to enable easier creation of a rich set of mission scripts, though I can't promise to implement suggestions, obviously.

Edit: Also, if anybody wants to take a whack at making a mission script or two, by all means, please do, and if in so doing you run into things that the API is missing that prevent you from being able to do what you want to do -- and are going to do -- let me know.


dusted » 18 Sep 2013, 11:38

There's a great tool for capturing opengl applications on linux, it's called glc, and is hooking into the opengl api (LD_PRELOAD i believe) to do high-performance screen captures, it also hooks into the audio subsystem, it produces quite large raw files which can then be converted into less-quite-large-files which can be read by tools such as ffmpeg to produce nicely-sized-files.

http://www.dedoimedo.com/computers/glc.html

https://github.com/nullkey/glc

http://www.youtube.com/watch?v=t2wp2QqMeV0


Arthur 18 Sep 2013, 14:21

I recommend capturing with ffmpeg instead of using glc - the latter is no longer maintained and is a pita to install and configure properly. The former is just a pita to configure.


smcameron 22 Sep 2013, 22:27

So a new guy named Jack Younger rolled into TX/RX Labs a few weeks ago and ended up pointing a camera at me and asking me some questions about Space Nerds In Space for a bit, so, this happened:

https://www.youtube.com/watch?v=ATWvxgZerb0&feature=youtu.be


qubodup 23 Sep 2013, 02:10

I raise all two of my thumbs!

Re-posted on freegamer blog.


charlie 23 Sep 2013, 09:57

I think it's a great social game. I'm very impressed.


farcodev 27 Sep 2013, 16:19

Great video and project.

The guys had fun :D

Keep up the good work


Imerion 09 Oct 2013, 15:26

So happy to see this project is still moving on and getting more and more awesome each update! :)

Among the most interesting games I'm following right now this one, so thanks for doing all this great work!

dusted 10 Oct 2013, 14:02

Good interview! :)

SNIS is a really interesting project, I reckon it's only a matter of time before someone hacks up a real starship bridge for this ^_^

The "gamemaster" idea is great reminds me of good old tabletop rpgs. If it could be scripted in the future, people could share their "missions" or scenaries.


smcameron 10 Oct 2013, 16:05

dusted:

Good interview! :)

SNIS is a really interesting project, I reckon it's only a matter of time before someone hacks up a real starship bridge for this ^_^

The "gamemaster" idea is great reminds me of good old tabletop rpgs. If it could be scripted in the future, people could share their "missions" or scenaries.

There is already some support for scripting missions with lua. It's still a work in progress and I haven't filled in all the events and callbacks and things or figured out what the best set of features for a scripting system are -- taking it kind of slow in an attempt not to bloat the scripting API with crap before I figure out what's really needed, though not having done something like this before, It will probably end up with its share of warts anyway.

You can see what the current (still subject to change) api is like here: https://github.com/smcameron/space-nerds-in-space/blob/master/lua-api.txt

and some example scripts (that don't do a whole lot) here: https://github.com/smcameron/space-nerds-in-space/tree/master/share/snis/luascripts

Currently you run the scripts by going to the "demon" screen and typing eg. "lua training-mission-1.lua" into the command box.

-- steve


dusted 11 Oct 2013, 08:33

Oh, that lua api looks neat, and the missions there shows it off well! :)

I'm wondering if openscad is strictly required for building the game, does it compile the model-files into a machine-specific format?

It'd be great if the content-creation tools were only required for content creators (most projects won't require photoshop or gimp to render .psd or .xcf files into pngs during the build).

That being said, after changing includepaths for lua, stuff compiles and looks great! Definitely going to give scripting a go :)


smcameron 11 Oct 2013, 13:54

dusted:

I'm wondering if openscad is strictly required for building the game, does it compile the model-files into a machine-specific format?

Well, openscad is needed only to build the stl files from the scad files (to state the obvious). I guess I don't make such a distinction in my mind between "content-creation", and coding, esp. since "content-creation" with openscad *is* coding. :)

Originally I had dropped the stl files into github directly, but... they're relatively huge and they screwed up my graph, man... :) https://github.com/smcameron/space-nerds-in-space/graphs/code-frequency

See that giant spike around Dec 2012/Jan 2013? That's stl files. Then the giant negative spike in June 2013 is me getting rid of the stl files.

Obviously if the game is built and packaged up into RPMs or .deb or whatever, the stl files will be in there pre-built (presuming I don't move to something more complicated allowing texturing, etc. at some point) but for what goes into github as "source", I think having the scad files and not having the stl files is the right decision.

BTW, if you make any cool mission scripts, send me a patch/pull request. And, if there's something you find yourself needing from the lua api that's not there right now (quite likely) let me know and we can hash out what should be done.

-- steve


dusted 11 Oct 2013, 14:19

smcameron:

Originally I had dropped the stl files into github directly, but... they're relatively huge and they screwed up my graph, man... :)

That's fair enough, i wondered if maybe it was something like size.. :)

I don't know if you're interested, but I've setup a build-server for SNIS for doing automated builds against github-commits, I've sent a mail with details, you can then decide if you want this or if I should back off :)


smcameron 11 Oct 2013, 14:47

dusted, that's awesome, thanks!

It's probably getting to be time to add a "dist" target to the makefile that does more or less what your build script does.

I have been thinking (not very much, but some) about what form this game might best be distributed for people that just want to play it, rather than hack on it, and I think this game is a little different than most. Since it's (at the moment) a linux-only game, and since it requires several people to be in the same location with a bunch of linux computers in order to play -- well, that is a very tall order, and most people probably won't be able to meet it. To help them meet it, we could build a bootable linux distro on a USB flash drive image with the game on it. Then, all they do is download the image, blast it onto a bunch of USB flash drives, boot up all their various computers from the flash drive, et voila!

Of course, to get into the business of distributing an entire linux distro, while still compiying with the GPL to distribute source upon request, etc.... maybe there are complications with that. And in the unlikely event the thing got popular, that could eat a lot of bandwidth. So, i dunno.


dusted 11 Oct 2013, 14:52

Building the dist needn't be much trouble, as a single link to the upstream dist would suffice as "source" I think.

Building a "going to work without too much hassle" usb dist is likely more difficult, maybe based on knoppix or another of the live-dists

I'm glad it may be useful, I'll follow the project and update the buildscript accordingly to the makefile changes. :)

I'm using ccache to speed up compilation, so the CC parameter is useful.

The server is on a 100 mbit upload, so it can handle a bit of traffic, and you're free to deeplink to the files, I've configured it to keep latest 10 builds, so using the "lastSuccess" link is propably useful.


dusted 12 Oct 2013, 00:38

Sorry for spamming, wanted to say that fresh 32 and 64 bit binaries can be downloaded here, these may not be correctly packaged, please correct me if I've made any mistakes.

I also implemented a simple caching system for the stl files from the scad files, so those will only be generated if they change.

These builds are not officially supported and I've made them on my own initiative, so if you have trouble with them, complain to me first.

http://contigrator.wizznic.org/jobs/space-nerds-in-space/history.htm

http://contigrator.wizznic.org/jobs/space-nerds-in-space/builds/lastSuccess/output/


smcameron 10 Nov 2013, 06:16

It's been a little while since I posted an update, and if you've only been casually watching the github page, you might have thought not much was going on, but if you dug a little deeper, you'll have seen that there's plenty going on, just not on the "master" branch.

It's been just a little over a year since I began this thread with the bare beginnings of a network game. In the original conception, the game was primarily a 2-dimensional game that happened to have a 3-d "out the window" view. Since then, and esp. in the last month, a lot of progress has been made in turning this primarily 2-dimensional game into a real 3-dimensional game. It's been a heavy battle, and many matrices have been manipulated and quaternions grokked.

So, here's a little update video showing some of the new stuff. It's still not really ready for prime time, but in case you want to play with the new toys anyway, the code is on the "more-coord-fixing" branch on github.

https://www.youtube.com/watch?v=ha8NxGSjx1A&feature=youtu.be


xahodo 23 Nov 2013, 00:34

A quick suggestion, but I don't know whether you already implemented something like that already.

Why not add (simulated) non-bridge crew? They can get wounded or even die when their post gets hit. Each crew member could have its own qualities, making it suited for a certain posting.

If crew starts getting wounded or (god forbid) start dieing, the system(s) they are posted start running less smoothly or stop getting repaired. This makes sure the bridge crew is more careful with the ship.

When the ship is running smoothly, the non-bridge crew can spend time optimizing the various systems of the ship. Causing the various ship systems to slowly improve in effectiveness.

Crew could be shuffled around, to affect things like repair or (re)charge time.


smcameron 23 Nov 2013, 07:17

xahodo:

A quick suggestion, but I don't know whether you already implemented something like that already.

Why not add (simulated) non-bridge crew[....].

Thanks for the idea, I will consider it. I am afraid though that there are many higher priority things which will need to be done before I can get to that. If I make a list of all the things that need to be done before I can have something which is a complete and playable game, there are many sort of "basic functionality" things that remain to be done, and at least to some extent, I try to choose what I work on with the goal of getting to a complete game in mind.

-- steve


dagrichards » 29 Nov 2013, 22:56 mintconstructor is not in any repo I can apt-get from, after a bit of rooting around I found some version here: http://download.polytechnic.edu.na/pub3/LinuxMint-Packages/pool/main/m/mintconstructor/

I am building a small fleet of iso's for a New Years Eve Party of Space Nerds In Space

Will get back with some addl feedback on the provisioning process.

FYI performance is actually pretty good running i2 VM's in VirtualBox on an older MacPro single socket 2.8 Xeon with GB Ram. Kudos to you.

I have noodled through the station UI's a bit and watched most if not all the vids you have up. I find some of the controls erm elusive?

Do you have any hidden docs or other guides? If I gen up some specific questions and ask in bulk are there answers to be had?


smcameron 02 Dec 2013, 00:52

Sure, you can ask questions, and I'll try to answer. F1 is help, which I've tried to make help screens, but, yeah, the controls (esp. on the DEMON screen) are elusive, as you say.

All the coolant stuff recently added to the engineering screen is pretty experimental (but it's on master, so, experimental or not, it's what you get.)

But sure, fire away with the questions. Maybe I'll start a FAQ or improve the in-game docs, or ... somehow make it better. Feedback is good (even if I don't agree with it or do anything about it.)

-- steve


smcameron 05 Dec 2013, 07:18

December development update:

https://www.youtube.com/watch?v=9wre3DkN8TE&feature=youtu.be

The video ends a bit abruptly due to camera battery failure, but there's enough there to get the idea.

Forgot to mention in the video the significant code contributions to the rendering engine by Jeremy Van Grinsven, without which things would not look as good nor be as fast as is the case.

Summary of latest updates:

Lots of progress, lots of fun, no major, insurmountable problems -- all in all, things are going well.


Natasha_Gita 13 Dec 2013, 09:56

This looks fantastic! It's amazing to browse this topic and see how far you've progressed. I noticed some of your videos had classical music playing in the background, but are you planning to add any other music at some point?


smcameron 13 Dec 2013, 13:32

Hi, and thanks for the kind words. There is a more cool stuff coming soon.

As for music, I'm not sure. In the very early days of home computers, just making any sound at all was a novelty, and if your game could play music, or -- oh miracle! -- even *talk*, this was quite a neat thing. Nowadays, that sort of novelty is gone, as computers can easily reproduce any sound, or video, or what have you. So, in one way of thinking about it, it doesn't make sense any more to have some particular music to go with the game, any more than your automobile should have a theme song to go with it that starts up every time you drive it (well, even that might be cool for a little while, but only because your car would be the *only* car with such an absurd thing, but it would still wear thin.)

Now I am quite aware that music is a powerful thing for setting a mood, and ideally, we'd all have John Williams in our game room conducting an orchestra performing an extemporaneous composition which varies seamlessly on the fly to suit whatever is happening in the game, like a real time film score. But that's not happening, of course. Next best, we might have some music composed that is broken into little component pieces that can be mixed and matched on the fly to make a kind of robotic simulation of John Williams piecing together something to suit the game play. This is really hard, although there have been some attempts (iMuse springs to mind: http://en.wikipedia.org/wiki/IMUSE ) Doing something like that is likely beyong my abilities, and even if it weren't, it probably wouldn't be that good. Next best, we can just strap some canned music into the game (e.g.: Brahms Tragic Overture seems like a reasonable fit, and there is a fairly decent free recording around: https://musopen.org/music/1567/johannes-brahms/tragic-overture-op-81/ ) However, this gets old on repeated exposure, and is not really much superior to just letting the player cue up whatever he likes on his media player of choice in the background.

So now I'm down to maybe I just provide a "suggested listening" list to accompany the game? You could do worse than to just crank up Pandora and type in "john williams" and let 'er rip.

-- steve


andrewj 14 Dec 2013, 11:53

I reckon this is the kind of game where having no music during gameplay is actually a good thing.

Music for the pre-game title screen / menus would be nice, of course.


jcantero 14 Dec 2013, 17:08

Some sci-fi theme tracks http://www.jamendo.com/es/list/a65062/sci-fi-music under CC-BY-SA license. The 6th (good morning) is the type of track for a relaxing not-combat situation. The same author has other albums of space ambient music.


smcameron 02 Jan 2014, 00:48

Some New Year's day fireworks for you guys in this development update:

https://www.youtube.com/watch?v=6gv40ukIwWk&feature=youtu.be

Thanks to the foundational work of Jeremy Van Grinsven to enable modern OpenGL shaders and such within the Space Nerds In Space codebase, we now how alpha-blending texture-mapping shaders to render lasers, torpedoes and sparks and such, and I'm sure more exciting and beautiful things will be coming soon.

Other changes: The damage control robot can actually repair stuff now too. A lot of improvement to the client side object movement interpolation code was done as well, so things move a lot more smoothly than they previously did. Lots of other small miscellaneous changes too numerous to mention, consult the history if you need more (too much) detail.

On another topic: I know a few people are trying to run this thing on Raspberry Pis. It was never really a design goal that it should run on Raspberry Pis, though I was happy to see people try it, esp. back before any OpenGL code was added. Now that the OpenGL barn door is opened though, it appears to be leaking into many of the screens besides just the "Main Screen" (Nav, Weapons, and Science, for example.) I do not see this trend abating as development continues, the sexy graphics are just too alluring. Much as I like the idea of SNIS on Rasp. Pi, the little machine may simply not be sufficiently powerful for it. -- steve


smcameron 05 Jan 2014, 06:05

Maybe nobody else would be excited about this, but I am.... texture mapped planets!

(if you only see a mostly black starfield, the forum is clipping the crap out of the image. Use ctrl-minus repeatedly to shrink the image down to the point the forum won't clip it -- the image isn't huge, the forum is just an aggressive clipper.)


charlie 05 Jan 2014, 14:53

Steve, you are in danger of having a good looking game on your hands!

This is quickly turning into one of my favourite FOSS game projects.


smcameron 12 Jan 2014, 01:59

Just a little teaser pic, will probably post a new video tomorrow...

Those nebula are not baked into the skybox, they are 3 dimensional and you can drive through them.

Also, quite likely the forum has silently clipped the image, press ctrl-minus a few times to see the whole thing.

Edit: Here's another teaser pic, some space rocks and behind them some nebula goodness. This thing is like driving the Hubble around... except with lasers.

Same caveat about pressing ctrl-minus or right-click, "view image".


smcameron 13 Jan 2014, 06:25

https://www.youtube.com/watch?v=HPrFNofRkKY&feature=youtu.be


charlie 13 Jan 2014, 11:30

Looking really good!


smcameron 04 Feb 2014, 14:43

I'll just leave this here...

https://www.youtube.com/watch?v=-dVLMqKm4d8&feature=youtu.be


charlie 04 Feb 2014, 17:47

Holy Rings of Saturn, Batman!


smcameron 16 Feb 2014, 22:23

Just a short video for now -- now NPC ships use warp (aka jump) drive (which is represented by the bright flashes you see in the video):

https://www.youtube.com/watch?v=1MoVUdvWy8Y&feature=youtu.be

Oh yeah, Zach Schultz made an awesome modified and textured model of the "wombat" spaceship...


dusted 20 Feb 2014, 14:38

Looks awesome! We are soon giving SNIS a go at work ^_^


smcameron 25 Feb 2014, 05:31

February 2014 devlopment update:

https://www.youtube.com/watch?v=LwzWGQ255cI&feature=youtu.be


dusted 04 Mar 2014, 14:09

Looks great! I will soon have to try another shot at doing a dedicated snis-distro ^_^


smcameron 23 Mar 2014, 05:43

Development update for March 2014...

https://www.youtube.com/watch?v=JQDhI2FeLUg&feature=youtu.be


smcameron 24 Apr 2014, 00:56

Space Nerds In Space April 2014 Development update.

Kind of slacking off lately in terms of committing code to Space Nerds In Space. That's ok, it's expected that there will be occasional lulls in momentum for any hobby project of this size. Look at Word War vi -- plenty of gaps in the commit history when enthusiasm waned.

Anyway, I have by no means abandoned the project. Here's a little video of what's new this month:

https://www.youtube.com/watch?v=oJRhO7ur8YA&feature=youtu.be

The audio isn't sync'ed to the video, and the video runs out before the audio finishes, ... oh well.

Most notably, I've been getting into emulating some fluid dynamics stuff to try to get decent textures for gas giant planets. I've made some progress mostly by pursuing the ideas in this paper: Curl Noise For Procedural Fluid Flow by Bridson, Hourihan and Nordenstam. You can the current state of my experiments here: Curly Vortex on github.

What it looks like in game so far (this is not committed because I'm not yet satisfied with it.)

The fluid flows on that planet image were simulated (faked) on 6 square faces of a cube arranged in a field of perlin noise with particles moving to adjacent faces when they leave another face. This works ok, but not great, leaving visible artifacts (though less artifacts than wrapping a seamless rectangle around a sphere). It also does not work well if you want to introduce belts of counter rotating flows parallel to the equator of the planet -- things get a little too tricky for me near the edges of faces and on the top and bottom squares of the cube. I think the better way to do it is do the flows in real 3d on the surface of the sphere, then generate the cube map textures from that data, which is what I'm currently working on, but it's not really there yet. In the mean time, here some examples of 2D fluid flows with horizontal bands of flows alternating between left and right with chaotic zones between. imgur album here.


farcodev 24 Apr 2014, 01:31

I following your project since the start when you posted on this forum and I'm impressed by all the continued effort you have put in it.

It is already far from these times. Keep it up!


charlie 24 Apr 2014, 09:28

smcameron:

What it looks like in game so far (this is not committed because I'm not yet satisfied with it.)

[awesome pics]

I just looked back and came across this in the 2nd post of the thread:

smcameron:

No 3d "thru the window" view yet --- if I do it, it will be a totally software z-buffered flat-shaded triangle renderer that looks like it's from a 1982 silicon graphics workstation. You'd probably rather someone besides me programs that bit, lol. As would I, as would I.

Hrm... are these two the same guy? I'm unsure. :D


NaN 24 Apr 2014, 12:57

Beautiful idea to use curl of noise function to get divergence free velocity field.

smcameron:

The fluid flows on that planet image were simulated (faked) on 6 square faces of a cube arranged in a field of perlin noise with particles moving to adjacent faces when they leave another face. This works ok, but not great, leaving visible artifacts (though less artifacts than wrapping a seamless rectangle around a sphere). It also does not work well if you want to introduce belts of counter rotating flows parallel to the equator of the planet -- things get a little too tricky for me near the edges of faces and on the top and bottom squares of the cube. I think the better way to do it is do the flows in real 3d on the surface of the sphere, then generate the cube map textures from that data, which is what I'm currently working on, but it's not really there yet.

You say you have tried Latitude / Longitude Projection (seamless rectangle)? Did you scale vx or dx to account for changing circumference cos(lat)? Should be simpler than trying to get the Cubed-Sphere Grid (cube map) right I think.

Edit:

Using spherical coordinates for particles positions and velocity should work for cubemaps I think. You just have to figure out the transform from spherical to cubemap coords :twisted:


smcameron 24 Apr 2014, 23:37

charlie:
smcameron:

What it looks like in game so far (this is not committed because I'm not yet satisfied with it.)

[awesome pics]

I just looked back and came across this in the 2nd post of the thread:
smcameron: No 3d "thru the window" view yet --- if I do it, it will be a totally software z-buffered flat-shaded triangle renderer that looks like it's from a 1982 silicon graphics workstation. You'd probably rather someone besides me programs that bit, lol. As would I, as would I.
Hrm... are these two the same guy? I'm unsure. :D

Well, as it happens the bulk of the gnarly opengl coding was done by someone besides me.

And I didn't commit those textures because I didn't want to bloat the repo with commits of huge binary graphics files I knew would not last long.


smcameron 24 Apr 2014, 23:43

NaN: Beautiful idea to use curl of noise function to get divergence free velocity field.
smcameron:

The fluid flows on that planet image were simulated (faked) on 6 square faces of a cube arranged in a field of perlin noise with particles moving to adjacent faces when they leave another face. This works ok, but not great, leaving visible artifacts (though less artifacts than wrapping a seamless rectangle around a sphere). It also does not work well if you want to introduce belts of counter rotating flows parallel to the equator of the planet -- things get a little too tricky for me near the edges of faces and on the top and bottom squares of the cube. I think the better way to do it is do the flows in real 3d on the surface of the sphere, then generate the cube map textures from that data, which is what I'm currently working on, but it's not really there yet.

You say you have tried Latitude / Longitude Projection (seamless rectangle)? Did you scale vx or dx to account for changing circumference cos(lat)? Should be simpler than trying to get the Cubed-Sphere Grid (cube map) right I think.

Edit:

Using spherical coordinates for particles positions and velocity should work for cubemaps I think. You just have to figure out the transform from spherical to cubemap coords :twisted:

Yeah, I think I know how to do it, just need to actually do it, and debug it. I don't think I can run the sim on the faces of the cube map easily, or I can't figure out how to get rid of velocity discontinuities at the edges of the faces, and it makes doing counter rotating velocity bands more complicated than I can deal with. After trying for awhile I have concluded it would be easier to do the sim in 3d proper, and get the cubemap images from the 3d data.


smcameron 28 Apr 2014, 04:52

So I have spent the last several days trying to do a proper 3D version of my fake fluid flow stuff.

Having some problems.

1. Cannot seem to get a divergence free velocity field on the surface of a sphere like I can for a 2D plane. Not totally sure why. Might have to do with error deciding if the noise gradient is "uphill" or "downhill". Adding a fudge factor to correct (somewhat) for one error in that area helped (reduced divergence) but what i thought should be a perfect correction was worse than the fudge factor. So... yuck. Not sure what's going on there.

2. Still have issues with discontinuities at cubemap face boundaries. Drat. The whole point of doing the sim in real 3D was to get rid of those. Haven't really tried to debug that, might turn out to be something simple, but... not happy to see those discontinuities.

3. libpng sucks. :) The initial particle colors are taking from an starting image. Right now that image must be 1024x1024 or it won't work. That's due to me not being able to figure out wtf is going on with libpng. Seems like it should be simple, but... it is the exact opposite of simple. Or I'm suffering some kind of brain lock on the issue, I don't know. Spent entirely too much time on it before just manually scaling the input image to the same size as the output images and giving up on that aspect for the time being. (if 1 and 2 can't be solved, 3 doesn't matter.)

Oh, btw, if you want to play with this mess, I checked it into master of space-nerds-in-space repo on github. The program is gaseous-giganticus. You will need a 1024x1024 png image as a starting point in the current directory that is named "gas.png" (you have to make this yourself. I suggest some cropped image of sedimentary rock formations from arizona found by google image search. Antelope canyon is also a good gis term. but anything will do, so long as it is cropped/scaled to 1024x1024 and name gas.png.) Then it will dump out (and overwrite, many times) files called tmpg-0.png (and 1,2,3,4,5 as well as 0). You can view those with, e.g. gqview or other image viewing program, and also mapped onto a sphere with mesh_viewer (part of space nerds in space code) by "mesh_viewer -p tmpg-" command.

A pic of one cube map face output. The gray areas, and esp. gray areas bordered by black with particles leaving the area are the divergences.

And on a sphere:

Those are with, iirc, 1M particles. 8M particles looks a bit better (divergences are somewhat hidden by the mass of particles.)

-- steve


ashdnazg » 30 Apr 2014, 22:47

I've been following your project for quite a while, and I must say it's incredible! (I plan to try it with my friends when it's possible).

Anyway, as libpng sucks, I usually use stb_image: http://www.nothings.org/stb_image.c , which is wizardry at it's best (you just stbi_load at stuff and you get an array of pixels back). That's, unless you got things to work, which is even better :)


smcameron » 03 May 2014, 23:44

Fixed a few problems.. it's working pretty well...


charlie 04 May 2014, 02:15

That is stunning. Well done.


farcodev » 08 May 2014, 02:29

Pretty cool, thumbs up!


smcameron 11 May 2014, 00:16

Some more progress on the procedural gas giants...


smcameron 15 May 2014, 01:19

I presented gaseous-giganticus at this month's meeting of the Houston Recreatonal Computer Programming Group. Here's a little write-up.


smcameron 12 Jun 2014, 05:50

No big updates to report, but I have been working on procedural generation of earthlike planets...

Here is a presentation about my program "earthlike", in the space nerds in space codebase to produce "earthlike" cubemap planet textures. Procedural Generation of Earthlike Planets. Use arrow keys to navigate the slideshow.

Also, I have been adding some code to enable custom physical devices to interface with Space Nerds In Space. Not too much to show for now, but there's this:

https://www.youtube.com/watch?v=w6vwbhHMmI4&feature=youtu.be

--steve


NaN 12 Jun 2014, 11:03

Awesome stuff. I remember Sean O'Neil having some nice procedural planets with craters code. His focus was more on continuous level of detail though. Unfortunately his website seems to be gone http://www.sponeil.org . I think I had his code somewhere, need to check my backups and maybe upload it to github/sourceforge.


NaN 14 Jun 2014, 09:18

Found the code: https://github.com/logzero/sandbox The interesting bits will be in src/Planet/PlanetaryObject I think. No pics unfortunately, will have to get it building/running on my current system first.


NaN 19 Jun 2014, 14:04

Here is how it looks like:

There seem to be distortions near cube map edges though.


smcameron 20 Jun 2014, 01:29

Thanks NaN. Wish I were actually good at writing shaders...

-- steve


smcameron 21 Jul 2014, 17:55 If you're interested in Space Nerds In Space and you run Arch linux, you may be interested in this: https://aur.archlinux.org/packages/snis-git/


smcameron 22 Jul 2014, 13:25

Compare:

https://www.youtube.com/watch?v=sQFYuQbg-HQ&feature=youtu.be

Today, above, vs. one year ago.


victort 26 Jul 2014, 00:32

Hi,

I've recently discovered Space Nerds In Space, and I'm totally impressed, but i can't shake the feeling that it wouldn't be amiss to suggest the author of SNIS take a(nother?) look at a GPL'd game called Pioneer Space Sim (http://pioneerspacesim.net)..

Both SNIS and Pioneer are GPL'd games. It seems like they should.. like.. go on a date, maybe.. at least flirt a little.

It would be a wonderful path to greatly expand the universe SNIS is shaping up to take place in, and it would certainly benefit Pioneer to have an angle on becoming an excellent multiplayer game...

anyway, i just wanted to register, and put my two cents in on it. These are both incredibly good works of space nerdery, I thoroughly enjoy both games, it'd be a shame if they didn't at least know about each other.. maybe some sexting?

Alas, i am not much of a developer myself. I have no way to assess both codebases and know how surmountable any integration might be.. For all i know, from a coding standpoint, it's a ridiculous suggestion.. It's.. just.. the conditions both games exist under.. the general rising climate of the popularity of space nerdery.. it's.. now just seems like an amazing time to suggest such.. um.. couplings..

as a space nerd reveling in this sudden outburst of awesome games (on linux, no less) out in the world, just imagine for a moment...

That was all..

US$0.02++

-m


smcameron 27 Jul 2014, 21:51

Improved planet rings, now using 1D textures so I can fit 256 rings into the same texture space as 1 ring previously required.

https://www.youtube.com/watch?v=RdXC_apBsnI&feature=youtu.be


smcameron 27 Jul 2014, 22:41

victort:

Hi,

I've recently discovered Space Nerds In Space, and I'm totally impressed, but i can't shake the feeling that it wouldn't be amiss to suggest the author of SNIS take a(nother?) look at a GPL'd game called Pioneer Space Sim (http://pioneerspacesim.net)..

Both SNIS and Pioneer are GPL'd games. It seems like they should.. like.. go on a date, maybe.. at least flirt a little.

It would be a wonderful path to greatly expand the universe SNIS is shaping up to take place in, and it would certainly benefit Pioneer to have an angle on becoming an excellent multiplayer game...

anyway, i just wanted to register, and put my two cents in on it. These are both incredibly good works of space nerdery, I thoroughly enjoy both games, it'd be a shame if they didn't at least know about each other.. maybe some sexting?

Alas, i am not much of a developer myself. I have no way to assess both codebases and know how surmountable any integration might be.. For all i know, from a coding standpoint, it's a ridiculous suggestion.. It's.. just.. the conditions both games exist under.. the general rising climate of the popularity of space nerdery.. it's.. now just seems like an amazing time to suggest such.. um.. couplings..

as a space nerd reveling in this sudden outburst of awesome games (on linux, no less) out in the world, just imagine for a moment...

That was all..

US$0.02++

-m

I'm aware of Pioneer. Merging the projects isn't going to happen for a variety of technical reasons, and I'll leave it at that. That being said, I have from time to time peeked at their shader code, and they're welcome to use, for example, my gas giant planet texture generator if they wanted to.

smcameron 28 Aug 2014, 13:14

Here is a slide deck from a talk I gave last night at a local game developers meetup: Procedurally Generating Gas Giant Planet Textures.


charlie 10 Oct 2014, 23:27

Any updates? I just saw this on a humble bundle and thought, "That looks like a crap version of SNIS!" They may have better marketing, though...


smcameron » 12 Oct 2014, 04:15

Hi Charlie. Sorry about the radio silence on the SNIS front. I have been looking for a job lately, so that has taken up all of my time for the past month. As far as "... crap version of SNIS!" LOL! If you take a look again at the very first post in this very thread you'll notice that this "crap version of SNIS", called "Artemis: Spaceship Bridge Simulator" is in fact one and the same as the very inspiration for SNIS. And before I even got very far with it, I emailed Thom Robertson to be sure he was ok with me re-using the same basic idea -- not that doing so was necessary, but it just seemed a decent thing to do. With his blessing, I proceeded with SNIS.


Pollux568 13 Dec 2014, 19:25

Hi smcameron,

just a small note to say that I discovered the concept of bridge simulator with Artemis last year. Then I've heard about the SNIS project, and I have been really really interested. There are some features which makes this game more interesting than Artemis in my point of view, above all the full 3D displacement, the far bigger world with more realistic distances, the feeling of an alive world (with many ships). And the total compatibility with Linux (I've tested it on my Linux Mint distribution, works perfectly :) ).

One thing prevents me however to organize LAN party on the subject, it is the lack of missions/objectives (but I might have missed a point). Although it is an open world sandbox game, it could be interesting to have global objectives (for example, destroy an enemy base or escort another ship).

I can't wait for further improvements of the game, keep motivated, it is worth !


smcameron » 21 Dec 2014, 05:02

Hello Pollux568, and thanks for the kind words.

I am aware of the lack of missions, etc. within SNIS. There is some capability for missions, but it is a bit, let's say half-baked and under-documented.

If you switch to the "demon screen", and type in "lua abc.lua", and if there is a script in share/snis/luascripts named ABC.LUA (has to be uppercase -- you could consider that a bug) it will run the script, which can do many things. There are some example scripts in share/snis/luascripts which you may want to take a look at.

CLEAR_ALL.LUA
COLLISION.LUA
HELLO.LUA
initialize.lua
SAVING-PLANET-ERPH.LUA
SILLY-SPACE-BATTLE.LUA
TRAINING-MISSION-1.LUA
TRAINING-MISSION-2.LUA
So, for example, you can go to the "demon screen" and type "lua saving-planet-erph.lua" and it will run that script. You can take a look at the scripts and potentially make your own missions. Documentation (what there is of it) for what the scripts can do is in lua-api.txt See: https://github.com/smcameron/space-nerds-in-space/blob/master/lua-api.txt My hope was that users might create some mission scripts for SNIS. The api isn't set in stone yet though, but I do try to not break the api unnecessarily and not adding stupid things to the api that will need to be changed later (time will tell if I am successful at not breaking it.) So I guess what I am saying is that I'm aware of the lack of missions, and have tried to put in some infrastructure to allow missions be built for the game. The missions generally have to make heavy use of the comms system to be able to inform the player of what is supposed to do (generally, making starbases pretend to make requests for the players to go do stuff.) I am not sure how well that scheme really works, but I'm not sure how else to do it. On another topic, to explain the lack of development activity on SNIS lately, about 3 months ago, in an interesting twist, I ended up not having a job for a bit, and spent about a month getting a new job -- which worked out pretty well, I think, since I did get a job at, of all places, GOOGLE! So, for the last 2 months, I have been doing nothing but trying to get my house ready to sell so that I can move across the country. Consequently, for the last 3 months, I have not worked on Space Nerds In Space at all. Once I start working again (in about 2 weeks!), I expect it will likely eat my brain for quite a while until things settle down to some sense of normalcy at which time maybe I can get back to working on SNIS some more. Thanks for giving SNIS a try.

smcameron » 25 Jan 2015, 06:31

So, getting settled in at my new job, had some time today to play around with gaseous-giganticus, the procedural gas giant texture generation program that is part of Space Nerds In Space, and so I made a little video about how to use it. Well, the audio isn't sync'ed to the video, and the video runs too fast (which, in this case is probably a good thing as it's a demo of a rather compute intensive and slow program.) This lets you get to see it actually working, instead of only still shots of the output of the program, which might be interesting.

https://www.youtube.com/watch?v=8nx5yPpQh2M&feature=youtu.be


Pollux568 03 Feb 2015, 05:33

Congratulations for your job ! Do you think your work on SNIS has helped you to be recruited ? Has your job any connection with the game ?

I'll try the LUA scripts - but sadly I've never coded in LUA, so I don't know if I'll be able to do anything of interest...

By the way, the gas giants looks awesome with these textures and lights, great job :)


smcameron 04 Feb 2015, 06:06

Pollux568:

Congratulations for your job ! Do you think your work on SNIS has helped you to be recruited ? Has your job any connection with the game ?

I'll try the LUA scripts - but sadly I've never coded in LUA, so I don't know if I'll be able to do anything of interest...

By the way, the gas giants looks awesome with these textures and lights, great job :)

Thanks. I don't think the game had much to do with getting the job, except indirectly, as I (re)learned some things while programming the game about TCP/IP and multithreaded programming, and knowing those things may have come in handy to know during the interviews. The job has nothing to do with games, graphics or anything like that.


smcameron » 08 Feb 2015, 03:07

Thanks to Iván Sánchez Ortega, it should now be possible to build a Debian package for Space Nerds In Space. I have not tried doing so myself, however. If you'd like to try it, there are some instructions here: https://github.com/smcameron/space-nerds-in-space/pull/49

How to build the Debian package by yourself, short version:
sudo apt-get install dpkg-dev debhelper devscripts
cd /place/where/you/cloned/space-nerds-in-space
dpkg-buildpackage

If something is wrong (e.g. missing build dependency), look at the output of dpkg-buildpackage. If the build is successful, the .deb will be located at /place/where/you/cloned/space-nerds-in-space/../snis-version.deb

In order to get the Git commit messages into the Debian changelog (and bump versions), look at git-buildpackage and git-dch

If you trust a random internet guy to compile things for you, you may or may not find a .deb package here: https://github.com/IvanSanchez/space-nerds-in-space/releases/tag/v0.20140108

smcameron 01 Apr 2015, 06:42

I have made a fun little experiment with morphing nebulae. It is right now only a half-baked implementation in that the morphing happens entirely on the client and no attempt is made to keep different clients to have the same morphing behavior so that all clients see a consistent view. It's a fairly subtle effect, and I am not sure it's worth it in that it's really just something that's fun for me as a programmer, but doesn't really add anything to the game play, so this might not ever actually make it into the game.

https://www.youtube.com/watch?v=RADFjxcXmbM&feature=youtu.be


andrewj 01 Apr 2015, 09:28

If it doesn't affect gameplay (having different effects on each client), then you may as well keep it. Little things like this add up, make for a richer experience.


Vandar 01 Apr 2015, 10:26

Very nice planets you do have there. Some years ago I tried to make planets, too, but my results were not so nice as yours. Good work :)


smcameron 01 Apr 2015, 20:20

Here's a video that shows the effect a little better and explains how it works. (Youtube says it's 95% processed so it might not play just yet).

https://www.youtube.com/watch?v=jab82mKhLdk&feature=youtu.be


smcameron 09 Apr 2015, 07:52

Working on some Space Monster code lately...

https://www.youtube.com/watch?v=Pw1BR29O70Y&feature=youtu.be"


eugeneloza 09 Apr 2015, 09:26

Looks awesome!!!


Vandar 09 Apr 2015, 11:46 The "masters of Orion II" send greetings!


smcameron 11 Apr 2015, 05:17

Refined the motion of the tentacles a bit... still not checked in. Everything is done server side right now and network traffic is 3 quaternions plus x,y,z for each joint of each tentacle -- 8 tentacles, 10 joints per tentacle... 4 floats per quaternion... means 15 floats per joint * 80 joints * 4 bytes per float == 4800 bytes per spacemonster per update. Need to push a bunch of this to the client side so it doesn't need to go over the network. So, still just in the proof of concept stage at this point.

https://www.youtube.com/watch?v=6Eb4gDTT2ys&feature=youtu.be


Vandar 11 Apr 2015, 21:39

Looks good. Having the animation data kept on client side and only transfer animation pattern id's from the server will cut down traffic a lot.


smcameron 12 Apr 2015, 00:26

Vandar: Looks good. Having the animation data kept on client side and only transfer animation pattern id's from the server will cut down traffic a lot.

It's not quite that easy. The "animation data" is procedurally generated on the fly. The trick is to get all the clients to generate exactly the same data at the same time, and allow for late joiners. It's not unsolvable, but not super easy either. For now, I sidestep the problem by generated on the server once and distributing to the clients -- I think I will continue to do it that way, but find a way to drastically shrink what's generated on the server (e.g. maybe I pass a new random seed around to all the clients to seed a per-creature random number generator so the clients can all generated the same data at the same time -- which is pretty much your same idea.)


Vandar 12 Apr 2015, 21:04

I've been using seeded procedural content generation in a few projects of mine, and it works quite fine. So passing the seed and, if needed, additional parameters to the rng of all clients will produce exactly the same outcome on all clients - assuming that your messaging is monotone ordered, i.e. messages are interpreted in the same sequence on all clients (clients still can lag behind, important is only that the sequence is the same).

Good luck :)


Vandar 14 Apr 2015, 15:35 Following this project made me want to add a 3D flight module to my own space exploration game variant. 5 hours learning OpenGL and looking at code examples, und uncounted thoughts of swear-words later, I finally have the basics together. Should be good enough to display something in between Elite and Frontier style worlds, but I'm not sure if I'll go into procedural planet generation like Frontier had it ... now I must couple the display module with the rest of the game.


smcameron 15 Apr 2015, 02:54

Cool. Adding 3D to a 2D game isn't easy for a variety of reasons. Enemy AI, steering, shooting, etc. becomes harder. Making the gameplay fun becomes (to me) more difficult. It's such a fundamental change that you risk damaging the game, or adding so much complexity to it that you can't finish it. The one piece of advice I'd offer is make sure you use consistent coordinate systems everywhere -- that is, x, y, and z axes always point the same way and you always use a consistent handedness of the coord systems used in the game universe and in the rendering system -- Opengl is going to want to most naturally use a particular coordinate system, don't fight it, modify your game to use that coordinate system rather than converting between that coordinate system and a different one within your game. Failing to do that when I first began adding 3D to my game lead to untold hours of debugging insanity. My first attempt failed because of this, and a 2nd attempt involved going back and fixing the coordinate systems to be consistent, and I probably would have failed a 2nd time if not for the help of my friend Jeremy -- or at least it would have taken a lot longer than it did.


Vandar 15 Apr 2015, 10:48

Well, the history of the project is long ... briefly said, it's been 3D data wise all the time, but there was only a map-like projection of space. No enemies, no fights. It's about exploration. Now I'm adding a new view for the data, showing space flight in 3D. Question is, if I want to use billboard sprites for planets, or make them 3D models, furthermore if I want to use procedural generation for the planets (which would be an interesting thing to do). And I'm afraid, once there are visible planets in space, players will want to land there.

Finishing the project ... um, probably will never happen. I started in 1995 or so when I was fascinated by Elite II - Frontier, worked on it for a while, had to dump a lot of code due to technology changes, started over with a new code base, dumped the new codebase, resurrected parts of the old code, translated it from C++ to Java and gave it a new Swing-based UI. At the moment it's not about completing something but a "I want to see if this works", which means embedding OpenGL in a Swing UI driven game. As a side effect I'm learning more about OpenGL, but more or less unintended.

Space monster brings questions: How metabolism works? What's engergy source? How they move?


smcameron 01 May 2015, 07:53

Been working on a (very crude) planetary atmosphere shader lately.


charlie 01 May 2015, 09:45

Eye candy! Nice, very nice.


Vandar 02 May 2015, 21:48

A gorgeous planet! Makes me want to improve my own earth type planet generator, but I doubt I can reach this level.

Do space monsters use bone shaped asteroids as chew toys? I'm wondering :p


smcameron » 03 May 2015, 02:47

About the space monsters... well I have not yet got the code in a state I am happy to commit, so some might say space monsters don't really exist. Perhaps some sort of scientific mission to study the "space monsters" should be undertaken.


Vandar 03 May 2015, 22:32

smcameron:

some might say space monsters don't really exist.

But ... but ... I saw one! It was huge! Larger than the ship. And it had tentacles! Lots of! And it was pale like death :o

Your way to create planets is clearly superior to mine. Although I have clouds and atmosphere effects now, too, they don't look as good as yours. Oh well ... I should port more of the UI panels anyways, to get a playable game again. I'm curious to see where your project is heading to :)


smcameron 04 May 2015, 05:13 I am guessing from looking at this image: http://forum.freegamedev.net/download/file.php?id=9300&mode=view that you are using some noise to generate the terrain. How are you picking your colors? To me it looks like your land is too "green" and your water is too light. I have experimented some and had good luck with picking colors by indexing into a color texture with one axis (in my case, vertical axis) being specified by altitude, and the other axis being specified by a 3D noise function. For land, and water, respectively, these color picking textures worked pretty good:

Producing planets like this (this one is without clouds, but with my atmosphere code):


Vandar 04 May 2015, 15:26

I'm using hand-coded color maps and simpex noise. I suspect that you have both, superior color maps (the textures that you showed), but also a superior noise function, or at least you make better use of your noise function, so that it creates swirly structures and details like the rivers. Better color maps will help my code, too, but adding more complexity to the noise function seems to be a problem, I doubt the player wants to wait more than minute to have the stellar system generated. Actually even 10 seconds of wait appear long ... but with some time there will come ideas :)

PS: I think the biggest difference is the fact that you have a 2-dimensional color picking system, while I have a 1-dimensional one that only uses height.


smcameron 05 May 2015, 03:53

The rivers and things come about because in my heightfield generation code, I sample real earth elevation data from images that I got from here: http://visibleearth.nasa.gov/view.php?id=73934 and use it to modulate my generated terrain E.g. I add a big circular pimple onto my planet, but then essentially multiply the pimple heightfield by a sampled region of some real terrain data, and keep doing that over and over. if the edges of the pimple I am adding into the surface have height zero, then after muliplying, they're still zero. Consequently it all fades together nicely, and I can add in zillions of such wrinkly terrain-modulated pimples and it all blends together. That part probably is pretty tough to do on the GPU I expect. Improving your color picking is probably do-able though.


Vandar » 05 May 2015, 14:43

My planets are precalculted too, so I could do a lot more detailed calculations as well. At the moment creating the Werteizin system with its 24 bodies takes between 1 second and 20 seconds, depending on the texture size and triangle count. One second is fine, 20 seconds stress the players patience quite a bit. I'll try to improve my color maps, the last incarantions of some planet types already look better than the early ones. Some others are in real bad shape, though.

Thanks for your tips, it's interesting to learn how you creature such fine planets :)


smcameron 28 May 2015, 04:27

A short video of some folks trying out Space Nerds In Space at MisCon, Montana's premier science fiction/fantasy convention, in Missoula, Montana this past weekend:

https://www.youtube.com/watch?v=Lkug5JMiFzE&feature=youtu.be


smcameron 31 May 2015, 19:19

Jeremy and I were interviewed by Paul Brown of Open Content and Software Magazine recently via IRC. Here is the result of that: Space Nerds In Space -- The Interview.


smcameron 07 Jul 2015, 06:11

Previously, I seem to recall someone suggesting that I should work on the color scheme of the UI of Space Nerds In Space, as what's there now is a somewhat haphazard mishmash of nominal primary and secondary named colors. Well, I have not really revamped the colors, in fact they are currently the same as they've always been. But, I have made it possible to modify the colors of nearly every UI element independently via a simple config file. Well, it's not as easy as it probably could be, and the names for all the ui elements are probably slightly opaque, but it is tweakable by mere mortals. For example, In a few minutes, I tweaked the colors of the Navigation screen to get this:


smcameron 13 Jul 2015, 07:55 I cooked up a new system for docking with starbases. Now the NAV screen has a button to engage or disengage docking magnets, and starbases can have docking ports. When you approach a docking port with the magnets engaged, then you dock. To undock, turn of the docking magnets. This still isn't complete -- but the concept works at least.

https://www.youtube.com/watch?v=EvWKz1wbFLo&feature=youtu.be


charlie 13 Jul 2015, 12:58

Cool to see you still adding features. :)

Just a word of warning - the sound is way out of sync (lagging maybe 30s+ behind) on the video.


smcameron 24 Jul 2015, 05:17

Another docking demo video. In the previous video, you could "dock" with a docking port, but it didn't actually do anything -- to have the systems on your ship repaired and replenished, you still had to dock the old way, which was just to get on comms and request to dock while floating vaguely next to a starbase. Now, requesting permission to dock via comms gets you only that -- permission to dock for a period of 3 minutes. During that three minutes, you can dock with a docking port, and get your ships systems repaired and replenished. If you don't dock within 3 minutes, the permission expires, and you'll have to ask again. Attempting to dock without first asking permission via comms won't work. Pressing F1 while on the navigation screen gives a summary of the process.

https://www.youtube.com/watch?v=uM9bylVnKmM&feature=youtu.be


smcameron 02 Aug 2015, 04:46 Have added a mining system to Space Nerds In Space. Here's a little demo. (I reverted to my old system of pointing a camera at the screen to evade the audio sync problem).

https://www.youtube.com/watch?v=5wAKVxg9TCs&feature=youtu.be


btaggart 14 Aug 2015, 21:48

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'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.

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

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

Thanks in advance for any help.

Ben.


smcameron 16 Aug 2015, 02:41

btaggart:

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 16 Aug 2015, 03:12

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 16 Aug 2015, 05:43

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.

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.)


by btaggart 17 Aug 2015, 17:21

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. 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 18 Aug 2015, 05:52

btaggart:
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...

$ 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 24 Aug 2015, 05:03

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:

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 » 24 Aug 2015, 05:23 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/scripts/spaceshipNames.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 » 31 Aug 2015, 06:00 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&feature=youtu.be


Vandar 31 Aug 2015, 14:34

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 02 Nov 2015, 06:29

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:

    + 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 08 Nov 2015, 20:09

Still tinkering with clouds...


smcameron 09 Nov 2015, 02:35

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 09 Nov 2015, 05:17

Wow, seems like you store a lot of data in the cloud! ;)

Keep up the good work. :)


andrewj 10 Nov 2015, 08:07

yeah, very very nice!


smcameron 30 Nov 2015, 03:07

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 30 Nov 2015, 11:24

Looks fantastic, even if rotationally incorrect. :P


smcameron » 08 Dec 2015, 08:23

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 15 Dec 2015, 23:31

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/Exoplaneten-Bislang-groesster-Atmosphaeren-Katalog-beantwortet-erste-Fragen-3043302.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 16 Dec 2015, 01:21 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 16 Dec 2015, 14:37 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 16 Dec 2015, 16:44

Vandar {l Wrote}: 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 17 Dec 2015, 09:01

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 17 Dec 2015, 16:42

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 18 Dec 2015, 05:36

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 20 Dec 2015, 00:55

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


charlie 21 Dec 2015, 01:05 That is pretty god damn awesome.


andrewj 21 Dec 2015, 02:23

The craters look like they are splattered onto a texture, without any height map or normal map affecting the lighting.


smcameron 21 Dec 2015, 02:30

That is because there is no height map or normal map affecting the lighting. The texture colors are generated (baked in) from a height map, and the craters are splatted into the height map prior to generating the colors.

My program does generate corresponding height maps and normal maps, but my engine doesn't know how to use them. Feel free to send me a patch.


andrewj 22 Dec 2015, 01:52

Ahh I see, your approach sounds fine, I just think with a better lighting system it could go from looking good to looking amazing.


Julius 22 Dec 2015, 04:30

Not sure if at that scale, shadows (unless at extreme dusk/dawn angles) would be really visible?


smcameron 22 Dec 2015, 06:04

Julius:

Not sure if at that scale, shadows (unless at extreme dusk/dawn angles) would be really visible?

Certainly using a normal map in the lighting calculations won't get you the kind of long shadows you see if you look up images of "lunar terminator", like this image from NASA:

which, that would be cool, but to do that I think I'd need to do shadow mapping, and... I so far haven't even managed to do normal mapping, so this seems unlikely.

I think the normal mapping would definitely help to make things look more "3D", but it would probably be easy to kind of "over do" the effect and unwittingly produce a caricature of what it really should look like.

Just looking at the normal maps I currently generate, I'm pretty sure I am already "over doing" it a bit (but since I am not actually *using* the normal maps yet...no big deal.) You can kind of get an idea what the lighting effects of the normal maps would be just by looking at the normal maps used as if they were color textures:


Vandar 22 Dec 2015, 16:00

When I had been working on the planets for Solarex, they had some hundreds of thousands of triangles already. Still a triangle spans some dozens of miles, so only the biggest craters could have real heights.

At times I think a space flight simulation must have planets in several detail levels, or able to add details on the fly when the player gets closer to a planet.

The point when my concept failed was the low orbit, from when the surface should become a real surface and not just an spherical image, because descending further you'll soon fly over plains, and in between mountains. It's not possible to keep the whole planet in memory on that level of detail, so there must be a transition from sphere to sphere segment (and if the player flies onward, a concept to attach new sphere segments seamlesslyy to the one already generated). This was beyond my skills.

SNIS still has superior planets compared to mine, and the craters make them even better. Good work there!


andrewj 25 Dec 2015, 13:42

I can see on the normal map image what feels missing to me: it is basically because there is just a rim, the whole middle of the crator (inside the rim) seems completely flat.

I would expect the inside of the crater to be more like the shape of a wok.

If that is a caricature and totally unrealistic, for me that doesn't matter if the results looks good.


smcameron 25 Dec 2015, 19:21

The craters are certainly still a work in progress. That being said, about the flat interiors of the craters I will say a few things.

1) It seems to be in line with photos of lunar craters, esp. the large ones: http://www.madpc.co.uk/~peterl/Moon/Craters/Apennines.html I expect this is because the larger impacts essentially liquefy at the point of impact, and so level out (but I am no lunar geologist, so that may not be correct.)

2) What you think "looks good" may be largely down to what you're expecting to see. I've spent quite a lot of time lately looking at lunar craters, so that flat interiors of the craters don't seem too out of place to me, at least in the case of the larger craters.

3) The craters actually do slam a bowl shaped depression into the height map. However, the height map is of limited precision (1 bytte in the current implementation) and if the terrain is already close to zero (likely) then it can and often does "bottom out" ate zero, producing the flatness that you noticed. Fixing that is probably a matter of tuning the algorithm a bit to get a height map that's not naturally so close to zero.

The main complaints I have so far with the craters are:

1) the height map perturbations are tloo large scale compared to the terrain generation height map perturbations, resulting in clipping and or overflow at 0 and at 255.

2) Not nearly enough small craters.

3) The colors are determined by altitude and by position in a 3d noise field to offset into a color map. Sometimes this works well, giving the "rays" a contrasting color, but sometimes it doesn't work well. It might be neat if the craters actually did some kind of "color displacement". Then again what I've got now might be good enough, esp. if I can get the normal maps working.

4) Probably should only have "rays" on the larger craters, not on every crater.

So yeah, I am not totally happy with the craters, but neither am I totally unhappy with them.


Vandar » 25 Dec 2015, 23:18

smcameron: So yeah, I am not totally happy with the craters, but neither am I totally unhappy with them.

They are definitely quite good as they are.

smcameron 29 Dec 2015, 23:42

My first attempt at getting normal mapping to work -- I have never been quite so shocked to see something appear to work immediately as with this code right here. I was bracing myself for about a month worth of debugging hell -- instead I get this! Woohoo!

(I suspect there are artifacts near the edges of each face of the cube map, but they are surprisingly subtle if they are there.)

https://www.youtube.com/watch?v=bBCXbUjAuxk&feature=youtu.be

Edit: and on playing around with it some more, it definitely has some problems, so my month worth of debugging likely still lies ahead.


smcameron 16 Jan 2016, 21:58

Ok, I think I have got normal mapping working (I still need to make it work with the shader that does the ring shadows, but I don't think that will be too hard.) The way the craters influence the normal maps needs some work, but the other terrain features look great.


smcameron 16 Jan 2016, 23:19

And now it's working in the ring-shadowing shader:


smcameron 17 Jan 2016, 02:08

Found a bug in the code which produces my normal map images that was giving me a little trouble. Now it all seems to be working pretty well.


Arthur 17 Jan 2016, 12:21

That's no moon, it's... oh actually it looks like a moon. Good work, this looks better and better. :)


smcameron 20 Jan 2016, 08:09

Now that I've got normal mapping for the planets working, I've got some new assets in the space-nerds-in-space-assets repository, the Karado star system. https://github.com/smcameron/space-nerds-in-space-assets/tree/master/share/snis/solarsystems

A few pics:


smcameron 27 Jan 2016, 05:30

Been a while since I made an update video. This one shows progress on the multi-server and warp gate system that I first mentioned back in August of last year. I am still working on it, and while I have made a lot of progress, it's a pretty big job and I've got about 30 uncommitted patches in my current stack, and still a ways to go. But it does now reload per-solarsystem textures on transiting between solarsystems and that is (mostly) working now, which means that you can quite easily *tell* when you travelled from one solarsystem to another since the planets and skybox, etc. now look different. It is still (and perhaps will always be) a requirement that the client have the necessary textures resident locally, but that is a detail. And the video shows off a bit of the fruits of the most recent adventures in normal mapping that have monopolized this thread for the last month or so. Without further ado:

https://www.youtube.com/watch?v=Qq7ID2zn75I&feature=youtu.be


smcameron 04 Apr 2016, 01:24

Been messing around with natural language processing kinds of things...

https://www.youtube.com/watch?v=Uge43ACAtos&feature=youtu.be


charlie 04 Apr 2016, 11:32

Your project is seriously cool. Your updates never cease to impress me. Thank you and long may it continue.


smcameron 10 Apr 2016, 03:33

Figured out how to make pocketsphinx use a custom vocabulary which improves its accuracy considerably. Also wrote some code to convert spelled out numbers like "two hundred thirty eight" to "238" which enables a lot of things.

https://www.youtube.com/watch?v=3EZNzcF4_4g&feature=youtu.be


Julius 10 Apr 2016, 13:13

Any plans to make a VR (Google Cardbord etc.) enabled bridge that also allows networked play?


smcameron 10 Apr 2016, 16:16

Julius:

Any plans to make a VR (Google Cardbord etc.) enabled bridge that also allows networked play?

Not really, no. To do that, the game would become a first person shooter, essentially, and I'd need an interior model of the space ship that you could wander around, etc. This seems like a huge amount of work, and all the UI's I've done so far would have to be... rendered to textures and pasted into virtual monitors inside the bridge interiror, or something along those lines (and probably redesigned and simplified to enable operating them via VR), and it would just be a radical overhaul of the game that even if I wanted to do, I'm not sure I'd want to bite off such a large piece of work. And all that is ignoring any porting issues of taking a C program and getting it running on Android, which I really don't know too much about. If I were to try to go for a VR route, I think I'd stick to dedicated systems built specifically for it, like the Rift (which was at one time going to support linux but I think they may have dropped that feature -- haven't been paying attention.) I think turning the game into a a VR FPS kind of takes away a bit from the collaborative in-person experience of the game, which probably isn't a good thing, since that is the main differentiating thing about the game.

One could argue that having a voice activated computer that can do everything on the ship might also take away from that experience -- what are the players needed for if the captain can just say, "computer do this, do that", and the thing drives itself?) But, such a computer is star trek canon, and kind of ridiculously cool that it's actually possible to attempt to create such a thing, and not even very difficult, so... it gets a pass. And well, the computer cannot fire or aim the guns, and while it's a neat novelty, it doesn't actually work so well that it's super convenient, and it can be ignored easily if it detracts from the multiplayer in-person experience.

There is a non-free game called "Pulsar: Lost Colony" that you can look up which is a multi-player bridge sim that is done as a first person shooter style where you wander around a virtual bridge that has virtual terminals for stations, etc, and I know at one time they were talking about supporting occulus rift, and even had some prototype going, but I do not know if that is still on their full feature list. It wouldn't surprise me if they cut it or put it on the back burner just due to lack of people able to take advantage of it and uncertainty about the hardware or for other reasons (eg. performance requirements). Here's a video of their prototype: https://www.youtube.com/watch?v=g3KqLGOVYPg


Julius » 11 Apr 2016, 12:28

I don't really think you need a full walkable 3D bridge, as you basically never move from the chair/station. What can be done very easily with the Cardboard SDK is a stereoscopic 360° rendered picture/looping video in which you can freely look around and interact with predefined points.

The jmonkey3D engine also has a more or less ready made support for Cardboard/Occulus etc. if that fits the bill better.

While I agree that this game shines with in-person multiplayer, simple VR support would be probably the next best thing for playing it over the internet and communicating with your friends via voice chat.

P.S.: To my own surprise the Google Cardboard works actually much better than expected (if you have the right phone/headset combination).


smcameron » 17 Apr 2016, 18:25

More minor improvements in the voice recognition -- not sure it's apparent what differences there are from the last video posted. I figured out a little more about how pocketsphinx works, and now it understands more commands, and more different ways of doing the same command, but it is incremental progress, really.

https://www.youtube.com/watch?v=tfcme7maygw&feature=youtu.be


Imerion 18 Apr 2016, 12:14

You're actually adding voice recognition to this? That is so cool! I already thought this game was a dream coming true, but it's even more so now! :D


smcameron 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.

 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.


smcameron 08 May 2016, 07:04

About three years ago I implemented the damage control station with a little robot that you can drive around to repair your ship, and this is tied into the engineering station and power model for all the various systems of the ship. At the time, there was a bit of discussion about whether or not this thing was actually a good idea, or maybe not such a great idea.

I have now made the damage control station "optional." It's optional in the sense that now the "automatic" mode for the robot actually works, and if you turn it on, then the robot can drive itself around and autonomously repair your ship for you without any intervention. There is some intelligence to how it chooses what to repair at any given time -- if shields or warp drive are esp. damaged, it will fix those first, as they tend to be more critical for survival, and otherwise choose to fix approximately the closest and most damaged component. There is doubtless room for improvement, better prioritization of which systems to repair first, and taking into account the overall damage to a system, not just the damage to individual components, etc. If you manually control the robot, you can likely do a quicker job, and make wiser decisions about what to repair next. But if you're short a player, the robot doesn't strictly require a human operator any more.

I don't have a video for this update -- it's not all that interesting to watch. From the programming side, the most interesting thing is the A* pathfinding algorithm which is used to let the robot navigate around the deck where all the systems reside -- not that the A* algorithm is anything new, but I think the API I came up with is quite nice, although the implementation is nothing special, and on a large graph, performance is suboptimal just because I didn't bother to optimize since the graph I am searching is small (~50-100 nodes). It's nice because the caller is not required to represent the search space in any particular way, so long as a list of neighbor nodes may be obtained from a given node, and so long as a cost estimate and distance estimate function can be constructed to estimate the distance/cost between two given nodes. An example of how to use the API is in a_star_test.c.


smcameron 30 May 2016, 05:40

Development update for May, 2016 -- 3D "demon" screen implemented.

https://www.youtube.com/watch?v=ju8pDrY6Tos&feature=youtu.be


charlie 30 May 2016, 14:16 Nice update.


smcameron 13 Jun 2016, 04:05

Lately I have been working on enhancing the capabilities of the Lua API to better enable scripted missions.

The Lua API is documented here: https://github.com/smcameron/space-nerds-in-space/blob/master/lua-api.txt

The following additions have been made in the last few days:

You can now set asteroid speeds (between 0 and 1). This is primarily to allow stationary asteroids.

You can now control the ratios of the ingredients contained within asteroids.

	set_asteroid_speed(id, speed);
Sets the speed of the asteroid with the specified id to the specified value. The speed should be between 0 and 1.
    set_asteroid_minerals(id, carbon, silicates, nickeliron, preciousmetals);
-- sets the proportions of carbon, silicates, nickeliron, preciousmetals. Returns 0.0 on success, nil otherwise. May fail if id doesn't match an asteroid.

Example:

            asteroid = add_asteroid(1000.0, 1000.0, 10000.0);
            set_asteroid_speed(asteroid, 0.0);
            set_asteroid_minerals(asteroid, 90.0, 5.0, 3.0, 2.0);

You can now get a callback based on proximity of two objects to one another. So you can have your mission script react when the player ventures too close to the space-thingy in your mission scripts.

    register_proximity_callback(callback, oid1, oid2, distance);
-- when the objects indicated by oid1 and oid2 are within the specified distance of one another, the specified callback is called passing the two object ids.

Example:

            function mycallback(oid1, oid2, distance)
                    print "Player has come within 300 of starbase_x\n";
            end
            register_proximity_callback("mycallback", player_ids[1], starbase_x, 300);

Timed text windows for mission start explanations, win screens, lose screens, etc. are now supported.

    show_timed_text(id, time_in_seconds, textstring);

shows a text screen with the given textstring for the specified amount of time on all clients of the bridge for the given player ship id. If id is -1, then the message is displayed on all clients of all bridges.

Lua scripts can now be chained with one script starting another when it ends. The specified script is added to a queue, and when the current script ends, the next one on the queue begins.

    enqueue_lua_script(scriptname);
Queue the named lua script for execution;

Many ship attributes may now be queried: {l Code}: {l Select All Code}

    get_ship_attribute(id, attribute_name); 
-- returns the specified attribute of the ship. The type depends on the attribute, though generally will be a number or a string.

The attributes and their types are listed below (output of print_ship_attributes program): The types are as follows (from key_value_parser.h):

       's' - string
       'q' - number (uint64_t)
       'w' - number (uint32_t)
       'h' - number (uint16_t)
       'b' - number (uint8_t)
       'Q' - number (int64_t)
       'W' - number (int32_t)
       'H' - number (int16_t)
       'B' - number (int8_t)
       'd' - number (double)
       'f' - number (float)
Though, to lua, they're all just "numbers."

The attributes are as follows:

                                     Key Type     offset       size      index
                                       x    d         96          8          0
                                       y    d        104          8          0
                                       z    d        112          8          0
                                      vx    d        120          8          0
                                      vy    d        128          8          0
                                      vz    d        136          8          0
                                 heading    d        144          8          0
                                   alive    h        152          2          0
                                    type    w        156          4          0
                               torpedoes    w        168          4          0
                                   power    w        172          4          0
                                 shields    w        176          4          0
                                shipname    s        180        100          0
                                velocity    d        280          8          0
                            yaw_velocity    d        288          8          0
                          pitch_velocity    d        296          8          0
                           roll_velocity    d        304          8          0
                        desired_velocity    d        312          8          0
                        gun_yaw_velocity    d        320          8          0
                             sci_heading    d        328          8          0
                          sci_beam_width    d        336          8          0
                        sci_yaw_velocity    d        344          8          0
              sciball_orientation.vec[0]    f        352          4          0
              sciball_orientation.vec[1]    f        356          4          0
              sciball_orientation.vec[2]    f        360          4          0
              sciball_orientation.vec[3]    f        364          4          0
                          sciball_yawvel    d        432          8          0
                        sciball_pitchvel    d        440          8          0
                         sciball_rollvel    d        448          8          0
                 weap_orientation.vec[0]    f        456          4          0
                 weap_orientation.vec[1]    f        460          4          0
                 weap_orientation.vec[2]    f        464          4          0
                 weap_orientation.vec[3]    f        468          4          0
                             weap_yawvel    d        536          8          0
                           weap_pitchvel    d        544          8          0
                        torpedoes_loaded    b        552          1          0
                       torpedoes_loading    b        553          1          0
                       torpedo_load_time    h        554          2          0
                      phaser_bank_charge    b        556          1          0
                                    fuel    w        560          4          0
                                     rpm    b        564          1          0
                                throttle    b        565          1          0
                                    temp    b        566          1          0
                                shiptype    b        567          1          0
                                 scizoom    b        568          1          0
                                weapzoom    b        569          1          0
                                mainzoom    b        571          1          0
                     requested_warpdrive    b        573          1          0
                        requested_shield    b        574          1          0
                       phaser_wavelength    b        575          1          0
                           phaser_charge    b        576          1          0
                    damage.shield_damage    b        992          1          0
                   damage.impulse_damage    b        993          1          0
                      damage.warp_damage    b        994          1          0
               damage.maneuvering_damage    b        995          1          0
              damage.phaser_banks_damage    b        996          1          0
                   damage.sensors_damage    b        997          1          0
                     damage.comms_damage    b        998          1          0
                   damage.tractor_damage    b        999          1          0
                               view_mode    b       2064          1          0
                              view_angle    d       2072          8          0
               power_data.maneuvering.r1    b       2080          1          0
               power_data.maneuvering.r2    b       2081          1          0
               power_data.maneuvering.r3    b       2082          1          0
                power_data.maneuvering.i    b       2083          1          0
                      power_data.warp.r1    b       2084          1          0
                      power_data.warp.r2    b       2085          1          0
                      power_data.warp.r3    b       2086          1          0
                       power_data.warp.i    b       2087          1          0
                   power_data.impulse.r1    b       2088          1          0
                   power_data.impulse.r2    b       2089          1          0
                   power_data.impulse.r3    b       2090          1          0
                    power_data.impulse.i    b       2091          1          0
                   power_data.sensors.r1    b       2092          1          0
                   power_data.sensors.r2    b       2093          1          0
                   power_data.sensors.r3    b       2094          1          0
                    power_data.sensors.i    b       2095          1          0
                     power_data.comms.r1    b       2096          1          0
                     power_data.comms.r2    b       2097          1          0
                     power_data.comms.r3    b       2098          1          0
                      power_data.comms.i    b       2099          1          0
                   power_data.phasers.r1    b       2100          1          0
                   power_data.phasers.r2    b       2101          1          0
                   power_data.phasers.r3    b       2102          1          0
                    power_data.phasers.i    b       2103          1          0
                   power_data.shields.r1    b       2104          1          0
                   power_data.shields.r2    b       2105          1          0
                   power_data.shields.r3    b       2106          1          0
                    power_data.shields.i    b       2107          1          0
                   power_data.tractor.r1    b       2108          1          0
                   power_data.tractor.r2    b       2109          1          0
                   power_data.tractor.r3    b       2110          1          0
                    power_data.tractor.i    b       2111          1          0
                      power_data.voltage    b       2112          1          0
             coolant_data.maneuvering.r1    b       2128          1          0
             coolant_data.maneuvering.r2    b       2129          1          0
             coolant_data.maneuvering.r3    b       2130          1          0
              coolant_data.maneuvering.i    b       2131          1          0
                    coolant_data.warp.r1    b       2132          1          0
                    coolant_data.warp.r2    b       2133          1          0
                    coolant_data.warp.r3    b       2134          1          0
                     coolant_data.warp.i    b       2135          1          0
                 coolant_data.impulse.r1    b       2136          1          0
                 coolant_data.impulse.r2    b       2137          1          0
                 coolant_data.impulse.r3    b       2138          1          0
                  coolant_data.impulse.i    b       2139          1          0
                 coolant_data.sensors.r1    b       2140          1          0
                 coolant_data.sensors.r2    b       2141          1          0
                 coolant_data.sensors.r3    b       2142          1          0
                  coolant_data.sensors.i    b       2143          1          0
                   coolant_data.comms.r1    b       2144          1          0
                   coolant_data.comms.r2    b       2145          1          0
                   coolant_data.comms.r3    b       2146          1          0
                    coolant_data.comms.i    b       2147          1          0
                 coolant_data.phasers.r1    b       2148          1          0
                 coolant_data.phasers.r2    b       2149          1          0
                 coolant_data.phasers.r3    b       2150          1          0
                  coolant_data.phasers.i    b       2151          1          0
                 coolant_data.shields.r1    b       2152          1          0
                 coolant_data.shields.r2    b       2153          1          0
                 coolant_data.shields.r3    b       2154          1          0
                  coolant_data.shields.i    b       2155          1          0
                 coolant_data.tractor.r1    b       2156          1          0
                 coolant_data.tractor.r2    b       2157          1          0
                 coolant_data.tractor.r3    b       2158          1          0
                  coolant_data.tractor.i    b       2159          1          0
                    coolant_data.voltage    b       2160          1          0
          temperature_data.shield_damage    b       2176          1          0
         temperature_data.impulse_damage    b       2177          1          0
            temperature_data.warp_damage    b       2178          1          0
     temperature_data.maneuvering_damage    b       2179          1          0
    temperature_data.phaser_banks_damage    b       2180          1          0
         temperature_data.sensors_damage    b       2181          1          0
           temperature_data.comms_damage    b       2182          1          0
         temperature_data.tractor_damage    b       2183          1          0
                               warp_time    d       2184          8          0
                              scibeam_a1    d       2192          8          0
                              scibeam_a2    d       2200          8          0
                           scibeam_range    d       2208          8          0
                                 reverse    b       2216          1          0
                                 trident    b       2217          1          0
                       next_torpedo_time    d       2220          8          0
                         next_laser_time    d       2224          8          0
                          lifeform_count    b       2228          1          0
                            tractor_beam    w       2232          4          0
                 overheating_damage_done    b       2236          1          0
              steering_adjustment.vec[0]    f       2240          4          0
              steering_adjustment.vec[1]    f       2244          4          0
              steering_adjustment.vec[2]    f       2248          4          0
                          braking_factor    f       2252          4          0
                             ncargo_bays    W       2448          4          0
                                  wallet    f       2452          4          0
                            threat_level    f       2456          4          0
                         docking_magnets    b       2516          1          0
                        passenger_berths    b       2517          1          0
                             mining_bots    b       2518          1          0
                         mining_bot_name    s       2524         20          0
                              sdata.name    s       2576         20          0
                sdata.science_data_known    h       2596          2          0
                          sdata.subclass    B       2598          1          0
                   sdata.shield_strength    B       2599          1          0
                 sdata.shield_wavelength    B       2600          1          0
                      sdata.shield_width    B       2601          1          0
                      sdata.shield_depth    B       2602          1          0
                           sdata.faction    B       2603          1          0
                              sci_coordx    d       2608          8          0
                              sci_coordz    d       2616          8          0
                      orientation.vec[0]    f       2720          4          0
                      orientation.vec[1]    f       2724          4          0
                      orientation.vec[2]    f       2728          4          0
                      orientation.vec[3]    f       2732          4          0
Example usage:
   player_ids = get_player_ship_ids();
   money_player_has = get_ship_attribute(player_ids[1], "wallet");
   ship_name = get_ship_attribute(player_ids[1], "sdata.name");
Enjoy.

smcameron 20 Jun 2016, 07:07

Some improvements to planetary rings. I spent some time watching videos of the Cassini flyby of Saturn. In particular this one: https://vimeo.com/33933151

This made me realize a few of things. 1) the rings are essentially either opaque or transparent -- there's not a lot of translucency. 2) The side of the rings in sunlight looks different than the opposite side, which is in shade. So, I made a few changes to try to get things to look a bit more realistic. Shadows tend to be stark, not subtle.

Here are three views of the same planet with my changes The rings have a light side and a dark side now.

What things used to look like:


smcameron 03 Jul 2016, 06:35

Here's a video that demonstrates some new functionality of the Lua API of Space Nerds in Space. In particular, it demos the show_timed_text() and text_to_speech() functions. This is a demo of the training-mission-1.lua script, which implements a timed race in which the player has to dock at four starbases in succession, finally returning to the first starbase to dock and complete the race. It took me about 10 minutes to complete the circuit in this run.

https://www.youtube.com/watch?v=nc1n_4vaOSQ&feature=youtu.be


charlie 03 Jul 2016, 20:36

Customary virtual applause from a lurker fanboi. You can't hear but I am clapping!


smcameron 10 Jul 2016, 05:53

Here is a demo of the Saving Planet Erph mission of Space Nerds In Space:

https://www.youtube.com/watch?v=nTBiM5zJi8A&feature=youtu.be

To run this mission, run SNIS as normal, then go to the "demon" screen and type in "lua mainmenu.lua", then select "Saving planet erph" from the menu on the main view screen.


smcameron 12 Jul 2016, 06:29

Github user ProfessorKaos64 has built and hosted Space Nerds In Space binaries for SteamOS Brewmaster and Debian Jessie (have not tried these myself.)


smcameron 17 Jul 2016, 18:03

I have added a new mission script, SPACEPOX.LUA

SPACE POX

Locate and deliver SPACE POX VACCINE to save the crew of the ICARUS station orbiting planet BONX from the SPACE POX which has broken out and is slowly killing them off one by one in a series of unlikely "accidents"

This mission can be kind of difficult The biggest difficulty is finding the space pox vaccine unless you know the trick. Then, the zarkon dreadknights are liable to get you unless you make a quick getaway, but your warp drive will probably not help you.

Here is the script: SPACEPOX.LUA (contains spoilers, obviously).

Found quite a few bugs in the Lua API while making this one. It is a little more difficult than I expected to come up with decent scenarios and implement them.


Imerion 18 Jul 2016, 01:58

That video. Wow. I'm so very very impressed by how cool this project is. Looks amazing, can't wait to get a group together to play it. Perhaps this fall, when I might buy an extra computer. ;)


smcameron 29 Aug 2016, 04:10

A small update. New things are:

https://www.youtube.com/watch?v=_KO6T3UXozI&feature=youtu.be


smcameron 05 Nov 2016, 06:07

Don't really have an update, but just wanted to let people know a couple things. First, I haven't disappeared, and while I haven't done much lately with SNIS, I've not given up on it. Second, today marks exactly 4 years since I made the first post about it here, starting this very thread.

So I wish a happy 4th birthday to all the Space Nerds In Space.


farcodev 06 Nov 2016, 00:13

Happy BDay to your project!

Keep it up!


smcameron 01 Jan 2017, 04:41

Spent a bit of time the last couple of days mucking around trying to improve the look of thruster exhaust plumes....

This forum has a way of cropping the images, so you might have to right click and "view image" to see the entire image.


smcameron 02 Jan 2017, 21:35

Working on some new stuff... not entirely sure this thing is a good idea, but this was on my screen a few minutes ago:


smcameron 03 Jan 2017, 04:22

Ok, got collision detection working for the new Big Honking Death Machine...

https://www.youtube.com/watch?v=WUTmXUIMifQ&feature=youtu.be


smcameron 09 Jan 2017, 04:10

In case anyone might be interested, Here are some slides about how the speech recognition and natural language processing hack works in Space Nerds in Space.

The image on the first slide is busted, but it's not important.

Use arrow keys to navigate. This probably does not work worth a damn on mobile.

And if you don't know what the speech recognition/natural language processing hack is, here's a video from ~6 months ago:

https://www.youtube.com/watch?v=tfcme7maygw&feature=youtu.be


smcameron 17 Jan 2017, 05:03

Inspired by the opening scene of the new Star Wars movie, and the sense of scale it was able to convey, I spent a half hour or so playing around with the camera in SNIS. And this happened:

https://www.youtube.com/watch?v=siPMjrEq8Rw&feature=youtu.be


smcameron » 31 Jan 2017, 14:45

Experimenting with some different ways to control velocity. I don't think this will be put into the game -- makes things seem too small -- but it looks cool.

https://www.youtube.com/watch?v=bvGfYSLtiNM&feature=youtu.be


Imerion 01 Feb 2017, 13:32

Very cool! Especially that giant ship. :D


smcameron 06 Feb 2017, 00:00

FWIW, I have made some improvements to the web page, adding fairly extensive documentation about how to build and run Space Nerds In Space.

http://smcameron.github.io/space-nerds-in-space/


smcameron 21 Feb 2017, 16:24

Here is some GPL'ed 3D turret aiming code someone may find useful. It does rely on some other code (for quaternions and vectors mostly). I figured I'd post this here since I thought other game developers might find it useful, as getting this to work is a bit tricky. The turret may be arbitrarily oriented, it is not required that the turret axes be aligned with any world axes, for example. The turret is rate limited in its motion about its axes (you set the limits.) It currently does not have enforced limits on motion about those axes though -- the turret can pass the guns through its own base, for example. It's on my list of things to do, but it's not done.

See also quat.c, quat.h for the vector and quaternion code it relies on.

Here's a quick demo:

https://www.youtube.com/watch?v=JVBWHlVaY9U&feature=youtu.be


lynxmonkey 28 Mar 2017, 05:34

This is, by far, the most amazing game ever! I played Artemis with our crew for a while, that was super fun, but this is a whole new level of awesome. The whole "real time" effect is the best, It's like being in a real life version of Firefly or USS Defiant. Start up the game, pull up a seat, open a beer and hangout, until you're required to do some work. Being a member of this crew, in this space, is like having the best job in the verse.

I'm on comms and have figured out:

request to dock

request a towing service

buy / sell mined stuff to get money

-- I still haven't figured out how to re-fuel the ship, any advice here would be great... please... seriously... I really need help..

otherwise our games will continue to end, with the ships voice telling us the fuel level is critical. I figure it's probably going to involve "/computer do X " or "/hail SB-01 request refuel" ??

Please keep making this great game :)


smcameron 07 Apr 2017, 03:26

lynxmonkey:

This is, by far, the most amazing game ever! I played Artemis with our crew for a while, that was super fun, but this is a whole new level of awesome. The whole "real time" effect is the best, It's like being in a real life version of Firefly or USS Defiant. Start up the game, pull up a seat, open a beer and hangout, until you're required to do some work. Being a member of this crew, in this space, is like having the best job in the verse.

Thanks for the very kind words! Sorry for the slow reply, haven't been checking this forum as frequently as I should.

I'm on comms and have figured out:

request to dock

request a towing service

buy / sell mined stuff to get money

-- I still haven't figured out how to re-fuel the ship, any advice here would be great... please... seriously... I really need help..

otherwise our games will continue to end, with the ships voice telling us the fuel level is critical. I figure it's probably going to involve "/computer do X " or "/hail SB-01 request refuel" ??

Please keep making this great game :)

There are two ways to get out of the "Fuel levels critical" situation, one of which is cheating.

The first way is to hail a starbase, and select option 4, "REQUEST TOWING SERVICE". A tow ship will be dispatched to your location and tow you to the starbase which you contacted. If you have near zero fuel, it will give you a little bit of fuel too, so you can drive to the starbase and dock. Once you dock with the starbase, you will be refueled. It is possible the tow ship might get killed en route to your location, in which case it won't show up (you can call for another one.) It's also possible for the tow ship to be attacked while towing you, in which case it may drop you where ever you might be (middle of nowhere) and run away. Again, you can call another tow truck in that case.

To successfully dock with the starbase (after the tow truck drops you off near it) you need to:

1: make sure docking magnets are engaged (there's a button on the navigation screen)

2: make sure you lower your shields (it will tell you to lower your shields if you forget)

3: request permission to dock while shields are down and when you're pretty close to the starbase (within 5000 units, I think. It will tell you if you're too far.)

4: Navigate to a docking port on the station after permission is granted but before permission expires (you can ask permission again, of course.)

The docking ports vary in appearance, but you can guess which parts of the station they are, some look like this:

or like this:

Once you dock with the port (by ramming it, basically), you will be connected to it. Your ship will be refueled and repaired, and all the systems will be turned off. To undock, turn off the docking magnets (navigation screen) and power on your systems (engineering screen).

The second (cheating) way to get more fuel is as follows. Once it starts saying "Fuel levels Critical!", go to the DEMON screen, and type in "safemode". The next time it says "Fuel levels Critical!", you will get your tank filled. "safemode" also has some side effects, it prevents enemies from deciding to attack you (if they already decided though, they don't quit.) If you type "safemode" a second time, it toggles off (you won't lose your fuel, but enemies might decide to attack). Safemode is a toggle. However there's no indicator of whether it's enabled or not (I should fix it, but I only put it in to help with debugging anyway.)


smcameron 16 Apr 2017, 08:38

I added a "Star Map" to the navigation screen.

https://www.youtube.com/watch?v=fhu04_ymcM0


smcameron 28 Apr 2017, 07:40

Haven't tried these myself, but there's some stuff by Hayden Hughes to build a bootable arch-linux based Space Nerds In Space usb image here: https://github.com/HUg0005/snis-live and some (again, untried by me) prebuilt images linked from the readme there.


smcameron 03 May 2017, 07:03

A couple new features added recently:

1. You can now set up to 10 waypoints on the Science station, either by typing in X, Y, Z coordinates directly, or by marking the ship's current position. The waypoints are selectable from the list of waypoints, or via the short range scanner or via the long range scanner. Once selected, the green arrow on the Navigation screen will point to the waypoint (just as it points towards anything that Science has selected.)

2. Life support system. There's a new system on the damage control screen, life support. There are also power and coolant sliders on the Engineering screen for life support, and a gauge for oxygen, which is produced by the life support system (from e.g. electrolysis of water). If the life support system is damaged (or deprived of power), it will produce less oxygen. Oxygen is consumed at a fixed rate. If the rate of oxygen production is below the rate of consumption, the oxygen levels will slowly decrease. If they get too low, the crew will asphyxiate.

A video demoing the new features: https://www.youtube.com/watch?v=5LmPP7OLtqM


smcameron 25 Jun 2017, 19:47

Some minor progress on Space Nerds In Space. Improved UI sound effects (I think), most buttons make some kind of sound now. Added tooltips to all buttons and sliders. Now you can eject the warp core. I need to work on the warp core ejecting mechanic to make it a bit more meaningful, but the basics are there.

https://www.youtube.com/watch?v=MImkMx3ZNWI&feature=youtu.be

The sci-fi UI sound effects were made with this thing: https://www.modulargrid.net/e/racks/synth/88651/2146 (Warning, this makes noise -- play with the 4 large knobs at the top left.)


smcameron 05 Jul 2017, 06:14

Quick demo of new attitude indicator and yaw/pitch/roll rate indicator on the nav screen:

https://www.youtube.com/watch?v=eNOe1ghJmIg


charlie 05 Jul 2017, 10:39

That is seriously neat!


smcameron 30 Jul 2017, 22:12

Space Nerds In Space Lua Scripting Tutorial videos:

Part 1: https://www.youtube.com/watch?v=p-98bsIYoWI

Part 2: https://youtu.be/K-nt7147ksU

Part 3: https://www.youtube.com/watch?v=8EgWLZfvcYs

Part 4: https://youtu.be/W6vm4m0voQ4


smcameron 08 Sep 2017, 06:13

Experimenting with specular reflection on planetary rings.


smcameron 10 Sep 2017, 03:16

Finally got tired of faffing about with trying to record videos on linux via software methods and sprang for an HD video capture device. Audio is recorded with a Zoom H4N (but with low batteries, so it's a little distorted.)

http://www.youtube.com/watch?v=weZMeTjVPro


smcameron 19 Oct 2017, 06:07

Been thinking about Comms, and how comms always seems to be lacking something very meaningful to do in these bridge simulator type games, so I am revisiting an idea I had about 3 years ago but never really pursued: Add a Real Time Strategy game into Space Nerds In Space, and let Comms be the one to direct the action. Here's a little demo of what I have working so far:

https://www.youtube.com/watch?v=8V8oLyaxsKo


smcameron 21 Oct 2017, 19:51

Don't know if anyone will find this interesting, but I decided to try a little live stream coding session. Mostly it's 30 minutes of me being slightly puzzled. OTH, I found that "obs studio" is actually capable of doing a decent job capturing video, unlike anything else I've tried so far that didn't involve extra hardware.

https://www.youtube.com/watch?v=70dalJo83hg


smcameron 07 Nov 2017, 22:16

Looky what I got... Space Nerd accoutrements. It will probably take a few days before I get all this working with Space Nerds In Space.


smcameron 09 Nov 2017, 04:22

So I've got the basics working with this HOTAS joystick setup today-- not counting the rudder pedals -- my cheapo "open box special" turned out to be missing a RJ12 to USB adapter that's apparently needed for the rudder pedals. D'oh! (I suspect someone broke or lost their adapter, went to Fry's and bought this thing, extracted the adapter, then returned it, sans adapter, and then I bought it as an "open box special.")

There is now a joystick config file (example default config here: https://github.com/smcameron/space-nerds-in-space/blob/master/share/snis/joystick_config.txt)

Have to say, it's pretty cool!

I still need to add more "functions" that are hookable to the joysticks (e.g. Currently it's not possible to connect "Reverse", "Engage warp", "toggle docking magnets", and other misc. things to the various joystick buttons, but there's no reason it couldn't be, and this sort of thing I will get to in the next few days.)

In case anyone plays around with this (ha!) and adds some config for their particular joystick, I am trying to collect such configurations, and have an issue to do so here: https://github.com/smcameron/space-nerds-in-space/issues/118


smcameron 10 Nov 2017, 06:47

So, while watching a review of this HOTAS joystick/throttle/rudder pedals combo, I realized that the missing RJ12 to USB adapter is actually not a problem after all because the throttle has an RJ12 socket into which you can plug the rudder pedals, and I tried it out, and it seems to work, with the rudder pedals showing up as an additional 3 axes on the throttle device. Also, I've committed changes to allow mapping almost everything on the Navigation screen to joystick buttons and axes.


Julius 10 Nov 2017, 07:16

Pretty nice... although they would seem a bit out of place on a bridge simulator (as opposed to a dog-fighting space shooter).

Any other plans for input devices? Separate Android touch-screen? Steam controller?


smcameron 10 Nov 2017, 16:49

I don't think it's really out of place for the Nav console, but supposing not everyone agrees with that, it's easy enough to not buy something like this and not plug it in. In any case, someone specifically asked for this capability, and it's easy enough, so I didn't see a reason not to do it.

As for other input devices, no plans for phones, the steam controller should be very easy as I presume it shows up as just another input device, so it should just be a matter of seeing what it shows up as in /dev/input/by-id and adding some entries into the joystick config file. But, kind of hard to do that when I do not own a steam controller. Feel free to send patches. Github issue to collect joystick configs here: https://github.com/smcameron/space-nerds-in-space/issues/118


smcameron 03 Dec 2017, 22:51

Tutorial video showing all the features of the Navigation screen: https://www.youtube.com/watch?v=-aUQsmFpOzM