[GAME] Space Nerds In Space

1234579

Comments

  • edited January 2019
    kwadroke said:

    Here are some pictures of a test run of Space Nerds in Space on Raspberry Pis I took from earlier this week
    Very interested in the idea of using Pi 3's with touchscreens. Unfortunately your images are not appearing. :neutral: Or at least not appearing when I originally wanted to post this comment a while back.

  • That post was almost six years ago, and I doubt the game will run well on a Pi anymore. Feel free to try, but I don't think it will be a good experience, I expect the little Pi just doesn't have enough horsepower.
  • Ah...whoops. Serves me right for not checking timestamps. I suspect you are right, although newer Pi 3's with the QuadCore ARM Cortex-A53 running at 1.2GHz and a Broadcom VideoCore IV GPU may fair better than what was available 6 years ago. :)

    That said, there are more powerful alternatives available in the SingleBoardPC market, such as the LattePanda Alpha 86-4, Rock Pi 4, Le Potato, UDOO x86 ULTRA (Intel Quad Core @ 2Ghz), the 16-core based Parallella, and so on... hard to keep track of all the options now-a-days.
  • Yup. If you do try something out, let me know how it goes. If it is able to run OK on a Pi 3, that would be super cool. Probably some of the stations (comms, engineering, damage control, maybe science) would run alright, maybe even on an older Pi. Nav, Weapons, Main view and Demon (in 3d mode) stations would be more demanding.
  • I haven't tried to get SNIS running on the RPi for a while now. The last time I tried was on a Pi 1, if I remember correctly.
  • Today I have been experimenting with procedurally generated "greeble" normal map textures. I don't think I will use this in its current form -- not quite good enough -- but it shows promise:

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

    The code for generating the normal map texture is here... I'll probably work on it a bit more. It probably won't ever be able to make a directly usable normal map, but will probably be useful if you cut and paste from the generated normal map into a custom normal map. So, maybe it will be a "procedurally assisted" normal map tool rather than a procedurally generated normal map tool.

    https://github.com/smcameron/groovygreebler
  • A bit of game play footage from earlier...

    https://www.youtube.com/watch?v=3fFl0VH-4zA
  • edited February 2019
    Nice footage! Did all computers run on an installed linux distro or have you tried out the arch live-cd on some of them? I am asking because I tried that live-cd, but had the problem that sound was not working, looks like pulseaudio is not running.

    Here is some feedback concerning the Raspberry Pi: I tried snis on my Pi 2 a while ago, and it did not work, as it froze/produced a black screen - tried different ram allocation/driver combinations, but no luck. However, somehow I overlooked that the limited client don't need opengl at all. So after your comment on the other thread I tried it again with the limited client and it worked!
    Of course, weapons and mainscreen should'nt be used with that client version and like you said, nav also isn't usable (about 1-3 FPS).
    Unfortunately, it seems that science also has problems. Might be coincidence, but I had 3 crashes, all happened when I was on science at the detail view.
    So what's left is engineering, damage control and comms, that seem to work just fine.
    So while it is not possible to run a whole bridge using Pi's, at least for some stations it seems to be possible. Maybe on the Pi3 there are even more stations that can be used.

  • Thanks for the feed back about the Pi. In this case all the stations had linux installed natively and we compiled the code on each one. Lucky for me there are a lot of people around here who run linux.
  • Experimenting with specular reflection on planets without using a specular map...

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

    Still need to tweak it a bit though.
  • Just some video of cruising around, looking at stuff.

    https://www.youtube.com/watch?v=OexArz3oNTk
  • Added a new mission script, "El Cubo de la Muerte", run by typing"cubomuerte" on the demon screen.
  • For the benefit of some star wars LARPers, you can now change the typeface used by the game. Type "set current_typeface=1" on the demon screen to get the alien typeface, "set current_typeface=0" to get the normal ascii typeface.

    image
  • smcameron said:

    For the benefit of some star wars LARPers, you can now change the typeface used by the game.

    Very cool.

    Where's the translation to the original Klingon? :wink:

  • Posted this on my patreon site, thought I'd post it here as well.

    In thinking about how to make Comms more interesting and fun, taking into account that it is almost completely a text based interface, the idea had occurred to me to put some interactive-fiction like elements in. For example, maybe there's a mission in which you find a derelict ship and you send a robot over to investigate, commanding it via Comms in the manner of Zork and those old infocom games.

    Now I already have a Zork-like parser built into the game for "the computer", however that's in C, and I don't want to build it into the game just for a particular mission. And exposing that to Lua seems like a lot of work. Like more than I want to bite off. And not really knowing Lua particularly well, the idea of writing interactive fiction in Lua directly seemed somewhat daunting and unappealing. So, for a long time, I just kind of shelved this idea as being sort of "not worth it." But lately I started thinking about it again, and thought, well, maybe I should dig into Lua a bit. So this morning I started looking at an old and very small toy project I had done in python that implemented some basic interactive fiction features. I had done that project as a way of learning python. I decided to see what it would take to do the same thing in Lua. Turns out Lua's tables are not all that different than python's dictionaries, similar enough that porting this python code to Lua was actually pretty straightforward, and the resulting code is surprisingly similar to the python code. You can see it here: https://github.com/smcameron/smcamerons-lua-adventure The python one is here: https://github.com/smcameron/smcamerons-python-adventure

    So with that under my belt, I think it should be totally possible to write a Lua mission script that incorporates these interactive-fiction ideas so I can make this concept of Comms directing a remote robot around on a derelict ship a reality. Probably want to keep it short, maybe break it up into several different segments, I don't want to make a mission that amounts to "Drive the ship over there and then play Zork for 3 hours," but I think this idea has a lot of potential to make Comms more interesting, and it's good for me to get a little more proficient with Lua.
  • edited August 2019
    You might want to look into how the AGI (early sierra advanture games) did their text parsing:
    https://wiki.scummvm.org/index.php?title=AGIWiki

    Important bit is that they had quite a large word list, of which many words are just ignored by the parser. Meaning "open door" and "please open the big door" are both seen the same. This was combined with list of synonyms for each word, so "look" and "examine" would mean exactly the same.

    (text entry on our setup is on the on-screen keyboard, which is a pain to use)
  • Got a proof of concept of the interactive fiction thing working with COMMS. You can try it by running "testintfic" from the demon screen, then switching to channel 1234 on comms.

    image
  • image

    First playtest of STURNVULF mission script

    2018-08-16 -- Tonight at HackRVA in Richmond, VA, I and a few other people tried a play test session of the new STURNVULF mission script, which has an interactive-fiction-like element as part of it, similar to old Infocom games like Zork. In this mission, your crew is informed of a ship called the STURNVULF's last known position, and that a previous rescue ship sent to the aid of the STURNVULF was destroyed, probably by Zarkons, but not before landing a rescue robot on the STURNVULF.

    You fly your ship out and locate the STURNVULF, and can command the rescue robot via COMMS in the usual interactive-fiction manner to try to figure out what's going on. There are survivors to rescue and planted bombs to deal with.

    The playtesting mostly went alright, with no outright crashes or lockups of the system per se, but not without a few hiccups. Overall I was satisfied with the near lack of bugs, especially since I made 23 commits related to the STURNVULF mission today, right up until a couple hours before we began playtesting, and many more in the days leading up to now. But there were a few bugs and tweaks needed.

    The gist of the mission is that while COMMS is busy wrangling the remote robot aboard the STURNVULF, Zarkons periodically appear to harrass the rest of your crew.

    It soon became apparent that the frequency of Zarkons appearing was too great, and within short order, the ship was spinning around helplessly with badly damaged maneuvering. Giving the ship 1000 missiles and greatly decreasing the frequency of Zarkon appearances made the crew's job manageable enough that COMMS could make progress while the rest of the crew could wrangle the Zarkons without too much drama. This worked pretty well for the most part.

    However, it took COMMS quite a long time to work through the little adventure I had set for them. In fact it took long enough that we ran out of fuel twice, and had to call a Mantis tow ship twice to be towed in for fuel and general repairs. This interrupts COMMS adventure, because you must be nearby the STURNVULF for the robot to receive your communications. And the first time we tried calling the tow ship, none were around, so I had to go into the Demon screen and add in a Mantis tow ship so that we could summon it again. After that summoning the tow ship worked flawlessly.

    So that's all fine, more or less, but the pacing was perhaps a little slower and longer-running than would be ideal. There was a bit of "guess the verb" or "guess the noun" or "guess the phrasing" happening with the adventure game as well. This is probably to be expected given the whole thing is a bunch of Lua script I threw together in the last 2 weeks. I have significantly leveled up in my Lua programming abilities over the last 2 weeks as a result of this, so that's nice.

    There were some (justified) complaints about the NAV screen, esp. about the SCIENCE Arrow, and how it's difficult to tell if it's point towards you or away from you. Having played with it a lot myself, I suppose I'm accustomed to it and can figure it out quite easily, but for people that are new to it, or who have not played the game in a few months, visually it can be pretty ambiguous and confusing. Need to think about how to improve that without making it too ugly.

    There were at least two outright bugs in the script. 1) at some point (maybe 2 hours(!) into the mission) we got a "comparing number with nil" error. I have the log file on my laptop, I don't remember the precise line. I think it was in add_zarkons(), probably zarkon was nil unexpectedly. 2) The script creates a custom button on the SCIENCE screen, ("TRANSPORTER") used to beam survivors off the STURNVULF. At some point, this button disappeared, making it impossible to transport any more survivors off the STURNVULF. I think it may be after we docked with a starbase for refuelling, perhaps that clears the custom buttons. I will need to look into that.

    Replayability of the mission is probably not very good, as once you've figured out all the little puzzles in the little adventure game, the novelty of them is gone, and it becomes much less interesting. So creating this type of mission script is *very* high effort (especially this first one of this type, subsequent ones would be easier as much of it is abstracted and generalized ... by which I mean all the stuff in share/snis/luascripts/MISSIONS/lib/interactive-fiction.lua) for very low replayability. But, I will say it did give a feeling of a much more detailed context about what the mission was about. It was much more of a proper Star Trek like feeling to have this little robot being directed by COMMS rummaging around on the disabled ship trying to figure out what happened while the rest of the crew fights off the Zarkons, rather than just the usual "go over there and blow those guys up for no very real reason" type of mission.

    The (natural and expected) slowness of COMMS figuring out the little adventure game was to some degree at odds with the desired pacing of the rest of the crew. I tried to throw COMMS up on the MAIN VIEW and the rest of the crew could enjoy what was going on there between Zarkon encounters, but the Zarkon encounters were distracting enough that the unfolding story was hard to follow very closely. After I adjusted the Zarkon encounter frequency to be low enough, there were many instances between encounters when the crew would become distracted and then be caught off guard by the next encounter.

    Overall, I'd say the idea of putting interactive-fiction into COMMS was a qualified success -- very good for COMMS, maybe not quite perfect for the rest of the crew, the pacing needs work, and the mission becomes too long for the rest of the crew.

    There were some problems compiling the game on SuSE leap 15.1. 1) Needed to install pkg-config and pkg-config_files. 2) Needed to set pkg-config-path environment variable (to what? Need to find this out.) 3) All references to lua 5.2 needed to be changed to lua 5.3. Note, we only compiled snis_client (via "make bin/snis_client") which shouldn't need lua at all. I don't know if the differences between lua 5.3 and lua 5.2 are significant enough to break things. I normally use lua 5.2 on my systems.

    If you would like to try the little COMMS adventure from the terminal without the whole surrounding SNIS infrastructure, you can run "lua share/snis/luascripts/MISSIONS/STURNVULF.LUA There will be some slight differences in how the transporting of survivors works, and the "win condition" doesn't really trigger in this stand alone mode, but if you just want to play with the little adventure game by itself, you can.

    BTW, the tweaks I made to missiles and to the zarkon encounter frequency have not been committed to github, so the STURNVULF mission that's in github right now will be a *very* tough (read: impossibly tough) mission. I'll probably work on updating it in the next few days.
  • image

    Improved heading indicators for SCIENCE and COMMS

    Some feedback I got from the most recent play testing session was that the directional arrow indicators on the NAV screen showing what direction WEAPONS was currently pointing and the direction of the current SCIENCE selection were a bit ambiguous, sort of like the Necker cube. It could be hard to tell if the arrows were pointing mostly away from you, or mostly towards you. You could move the ship, and watch the motion of the arrows and figure it out if you had previous experience with the screen and knew the behavior, but for new players, moving the ship sometimes just makes the arrows move in a confusing way if you're brain has already latched onto the "wrong" interpretation of the Necker cube, so to speak.

    I have tried to mitigate this problem in two ways. First, I have added tails onto the arrows and second, I have added "contact patches" (indicated by the white arrows in the picture above) which show the point directly above the central disc where the arrow's head and tail lie. I hope that these will give even new player's brains enough 3D cues to automatically latch onto the correct interpretation.
  • The problem I see with those new arrows is that they look pretty similar to normal objects, almost like (huge) rockets, wich can confusing, too. Maye you can draw them just as lines instead of polygons? That said, your attempt using the contact patches might be enough and more clear anyway.
  • I think the key to making these bridge sim games fun is getting the right people involved. https://www.youtube.com/watch?v=3ITUYo7CRg0
  • edited October 2019
    Code breaking mini-game idea...

    Trying to think up some mission scripts, I had an idea for a coded message containing clues which the crew has to decipher. The code would be a simple substitution cipher, with each letter of the alphabet randomly switched with another letter of the alphabet. Given a large enough ciphertext and knowing the language of the plaintext (e.g. English), and knowing the frequency with which letters occur in the target language (e.g. ETAONIRSH...), and knowing a few common bigrams, (TH, HE, IN, ER,...) such ciphers are pretty easy to crack. With some help from the computer (e.g. automated frequency analysis, and allowing the user to try out substitutions easily), it might make a fun mini game that the whole crew might participate in.

    What I'm imagining is two windows, on top, the ciphertext, and on bottom, the plaintext (or, possibly alternating lines of ciphertext and plaintext instead). Initially the plaintext window will just contain an underscore for every character. Below the plaintext window is the alphabet, and the players may type in possible substitutions for each letter, which instantly are displayed in the plaintext window. Additionally, the most frequently occurring 2 or 3 unsubstituted characters in the ciphertext are identified.

    So it becomes a bit like a game of hangman, or "Wheel of Fortune", you make some substitutions and see if you can recognize what might be some words. You see a letter by itself, and you know it's probably the word "a". You see the most common letter, and presume it is most likely to be "e", the next most common is most likely "t", etc. A three letter word occurring many time is likely to be "THE". As you make substitutions, more and more of the message becomes apparent, and more and more obvious guesses for letter substitutions become apparent, and eventually the message is revealed.

    Or, at least that's how I imagine it working.

    I could code the entire thing in Lua (though the UI would necessarily be uglier and done entirely within the COMMS window) or I could do a little C programming and make a special "code breaking" computer that would be nicer to use, though it seems a bit too special purpose.

    What do you guys think? Is this idea worth exploring?

    Edit: Perhaps similar to this game: http://www.hanginghyena.com/cryptograms_casual

  • I have laid the foundation for the de-ciphering mini game, and here's a demo of it. No mission scripts yet take advantage of this system though.

    https://www.youtube.com/watch?v=bwAARa-dDH0
  • Just a little video demoing the process I use to debug NPC ship movement.

    https://www.youtube.com/watch?v=HcVyhEIIKa0
  • Hunting NaNs

    What are NaNs? A better question might be what aren't NaNs. NaN stands for "Not a Number", and NaNs are special floating point values that can occur when you attempt to do things like divide by zero or other "impossible" mathematical operations. Most typically in my experience, NaN generation due to dividing by zero happens when you attempt to normalize a vector with zero magnitude. Once NaNs are generated, they typically spread through any calculation in which they are used, corrupting all sorts of calculations and causing weird behavior for anything depending on those calculations (most typically, NPC ship movement.)

    Since Space Nerds in Space seems to work pretty well for the most part, I sort of presumed that NaNs weren't really something I was bumping into much -- that my code was correct enough that I wasn't generally dividing by zero much if at all. And I suppose that must have been mostly true -- mostly true in that the game did work well enough, seemingly. But then I tried actually taking a look to see whether any NaNs were scurrying around down in there.

    Oh my god... So many NaNs! So the way that you figure out whether you've got NaNs is to enable floating point exceptions to terminate your program and produce a core dump. The code to do so looks like this:

    feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);

    Then you compile everything without optimization and run it, and see what blows up. Well things blew up *immediately*, leaving a core file for debugging. For a day or so, this cycle continued: Compile, run, explode, debug, fix. Many NaNs knew what it was to be roasted in the depths of the core that day, I can tell you!

    After awhile, I slew enough NaN generating bugs that things no longer exploded immediately, but required several minutes of running before exploding. Now, I think I only have one NaN bug left (that I know of). And I have a fix for that one, I'm just not certain my fix is really right, so I want to think about it some more before I commit it (or some better fix).

    In any case, if you're interested in the gory details, you can check out the bug report on github: https://github.com/smcameron/space-nerds-in-space/issues/236
  • You da key master, man!
  • Heh. Thanks for confirming that anyone actually even reads this thread.
  • Good read! A square root of a negative number is also NaN.

    NaN is really evil. But the worst part is. NaN does not equal NaN. Which has resulted in a network traffic bug in EE. Most of the network code just checks "value not the same as last time? Send it." So if a NaN gets in there, it just keeps sending it at 60 updates per second. As it is never equal to the previous value.
    This happened with a spaceship variable that was not initailized, but also not really used when it was not initialized. So it had no ingame effect, other then spiking network traffic.

    I didn't know you could enable exceptions for floating point operations. Good to know.
    But an overflow results in infinity, not NaN. Which is not as bad as NaN.
Sign In or Register to comment.