Pondering bridge simulation game creation.



  • image
    Only updating one "cell" per frame, so it's a bit slow in updating. While it can delete multiple cells in a single frame.

    There is also no collision, so I mistakenly flew into the planet.
  • It's been only 4 days since my last post, and you all have probably written 5000 words. Goodness! Going to be full-time job keeping up here, ha! 8-)
  • edited November 2019
    > the planner was jittering between the 2 possible points ...

    Yeah, this, or something akin to it, seems likely to be the cause of many oddities I have observed (e.g. ships "porpoising", oscillating orientations, weird figure 8 movements...). At any given moment, what the ship is doing might make sense, but perhaps over some short time span it oscillates between attempting to do two different things.
  • edited November 2019
    After writing all that stuff about NPC ship movement, I got inspired to try to debug it yet again, so I added a bunch of AI tracing code, and after several hours of messing around with it, I found a couple things wrong that explained a lot. First, NPC ships were not advancing correctly to the next waypoint after arriving at a waypoint. They would only partially advance, but for a time would continue to try to hit the waypoint that they had just arrived at. I should probably refactor the code a bit to make such an error more difficult to make. Second, they were not setting their desired velocity to a non-zero value after arriving at a waypoint, so they continued to sit there for longer than they were meant to. I'm not actually sure how they ever got out of this state, though I think they did.

    I also observed some behavior in which an NPC attempting to reach a waypoint that was nearby but that they were not facing while they were traveling relatively fast would cause them to sort of "orbit" the waypoint without ever reaching it. I relaxed the distance at which they were considered to arrive at the waypoint, and this helps. This probably accounts for some of the "figure 8" maneuvers I would sometimes see them doing.

    I did still see some "porpoising" behavior sometimes, the cause of which is still unknown. I suspect some of the collision avoidance steering behavior code.

    Debugging these guys amounts to watching them on the Demon screen until you see one do something weird, then selected it to get it's ID, then aitrace the ID and watch the console and try to figure out what it thinks it's doing.
  • daid, what is the size of that planet? You could cheat by having atmospheres on all bodies above a certain size and forcing a speed limit. Smaller bodies can probably get away with slower updated. I'd also be interested to see it generate non-sphere asteroids.

    To go on another tangent again, space terrain. I think there are two ways to approach space terrain, long-term strategic (when and where to fight to get an advantage) and the tactical (on no we about to die, look a nebula to hide in!). Gameplay is more varied and rewards captains who pre-plan their fights.

    For my imaginary Expanse-tech-level game the Jupiter system (or a gas giant hybrid of jupiter and saturn) offers a lot of possibilities. I mentioned earlier that the moon positions can be interesting. A Homman (sp?) transfer orbit from Callisto to Io would take about 30 hours based on my rough napkin math. The rings (or even better with Saturn-like rings) will make some orbit changes more treacherous in a 2d map. Jupiter's magnetic field is wicked strong. Callisto is the closest moon anyone can live on the surface for any significant amount of time. The radiation around Io would kill most people in a week. On the other hand we know that antimatter is more plentiful in planetary radiation belts by several orders of magnitude.
  • edited November 2019
    4km planet radius, smallest voxels of 1m. Ship has a speed of 300m/s. Ship has a 10x10x5 collision size, which sort of matches the size of the ship.

    I need to put a bit of a hysteresis on the level of detail switches. And the voxels where sampled at the corner, not in the center, giving some odd results.
  • I've been experimenting a bit with making starbases orbit planets, (which I believe someone in this thread mentioned things orbiting planets to be a desirable feature.) You can try this out in SNIS by typing "starbases_orbit=1" on the Demon screen. It breaks the navigation of the NPC ships though, because they no longer know where the starbases are.

    In trying to fix that, I ran into a few more problems, and it starts to get pretty complicated. The starbases follow a fixed circular orbit, defined by an altitude and a quaternion encoding an axis of rotation and an angular velocity. So in theory, NPC ships could estimate how long it would take to reach a starbase from their current position, and knowing that, calculate where in the orbit the starbase would be after that much time had elapsed. And of course this new position might be a different amount of time away. You might be able to iterate this calculation several times, incorporating an error term and converge on a solution to sufficient accuracy. I'm not entirely sure, but let's suppose you could.

    In SNIS however, NPC ships that have warp capability have some small probability of "just warping" to where they're currently trying to go if it's sufficiently far away. This system would need to be modified to account for the moving starbases. It's no good to predict where a starbase will be in a couple of minutes, when you would arrive by means of conventional thrusters, if you then along the way randomly and instantly warp to that location. Now you're early, and the starbase isn't here yet.

    Additionally in SNIS, the NPC ships don't really "dock" with the starbases (uh, mainly because to dock involves ramming a "docking port" that is mounted on the spinning station, and that's hard to automate.) Instead they just hover near the station, presumably conducting their business with the station via transporters and radio. Well, if the station is orbiting (moving), then this hovering needs to move with the station as well.

    However, in SNIS, an NPC ship's orientation is partially defined by its movement. It always points in the direction it is moving. And it always shoots a spout of fire in the opposite direction, the amount of which is scaled according to how fast the ship is moving. These would have to be changed for this "hovering near a starbase" behavior to accommodate a moving starbase.

    This all starts to seem like an awful lot of work and complexity for something which doesn't really add all that much to the game.
  • Right -- warp drive makes movement around planets trivial so orbital mechanics doesn't add to the gameplay.
  • edited November 2019
    Let's talk a bit about the "game master" screen / tools. The "Demon" screen as it's called in SNIS for some reason began its life as a debugging screen, and still serves that purpose, though it also allows for game master type actions, some of which work better than others.

    You can invoke Lua scripts from this screen which can either be full blown mission scripts, or simply utility or test scripts. The utility scripts I currently have are:
    • CLEAR_ALL.LUA -- deletes all objects except human controlled ships
    • DAMAGE.LUA -- inflict damage on the player (this script needs some work).
    • DESTROY_SHIP.LUA -- destroys the specified ship
    • DISABLE_ANTENNA.LUA -- turns on / off antenna aiming code (nobody uses this).
    • PAY_PLAYER.LUA -- deposits some Z-bucks into the player ship's wallet.
    • PLAYER_SPEED_BOOST.LUA -- sets player ship max speed to ludicrous
    • PLAYER_SPEED_DEFAULT.LUA -- sets player ship max speed to normal
    • REDALERT.LUA -- turns on red alert
    • REGENERATE.LUA -- clears and regenerates (repopulates) the solar system.
    • RESETBRIDGE.LUA -- resets a player ship to good health and fuel
    • RESTORE_SKYBOX.LUA -- restores default skybox (not sure this still works).
    • SAY.LUA -- Triggers text-to-speech on players bridge (allows GM to impersonate computer)
    • SETFACTION.LUA -- changes the faction of a given object (NPC or player ship or starbase)
    • SET_PLANET_DESCRIPTION.LUA -- sets the description of a planet viewable when it is scanned by science.
    • SET_SB_FACTION_MASK.LUA -- allows starbases to reject docking for certain factions.
    Additionally, the GM can kind of poke around visually within the solar system, select objects, move them around, and add new objects of various types, or delete objects. He can take direct control of NPC ships and drive them around and fire the weapons (admittedly, this does not work particularly well, and is something I should probably work on.) NPC ships may be directed to attack other NPC ships or player ships (the interface for doing this is pretty terrible though, and needs some work.)

    Various settings/options for the client and server may be selected via this screen via either menus or a bunch of variables you can set via "the console". Writing a generic "variable tweaking" system turned out to be a great idea.

    A lot of what I've added to this screen amounts to whatever it is I need to work on or debug some feature of the game, and often it's a very minimalist implementation, just enough to barely work. I think there's room for a lot of improvement, esp. for things that are GM centric rather than "guy-debugging-the-code"-centric.

    I'd be curious about what sorts of things EE offers in the way of GM tools and features, or if anyone has ideas for GM features they'd like to see.

  • This all starts to seem like an awful lot of work and complexity for something which doesn't really add all that much to the game.
    This. Unless your game evolves around orbital mechanics (ksp) it adds little.
    If you do do full orbital mechanics, you run into a few issues, like engine strenght, and time "warp" requirements. As well as having a very complex to understand movement system (unless you played enough ksp)

    Thats why I added orbiting for planets in EE only as an estetic thing. It looks nice from a distance.

    I'd be curious about what sorts of things EE offers in the way of GM tools and features, or if anyone has ideas for GM features they'd like to see.
    EE has it's basic, move things around and create new objects. As well as modifying properties of various object, most important ships.
    Special features include the ability to export all items on the current map (or only the selected items) as mission script code. Really useful to setup positions for scripts.
    Another important one is the ability to have mission scripts add custom buttons to the GM screen.

    It does not offer much in the form of debug features. I'm quite adept at debugging with limited information. (Something with debugging systems where attaching a debugger is impossible, and adding a simple print can screw up everything as well)
    EE's release builds to have a crash logging facility buildin. This proved to be extremely valuable tracking down crash causing bugs.

    Two hardest to figure out bugs in EE where that AI ships would suddenly stop and do nothing any more (rare) and collision data not properly cleared. Both where quite tough, because they happened rarely.
    The targeting bug was the toughest. Because the code looked sound, it was just missing a "const". This required first a whole bunch of extra log statements to find it, and then single stepping trough the all the code in a single if condition to find out it took the wrong path, and even that was hard to spot, as it was doing less code then I would have expected.
    Details: It was implicitly casting objects to bools to compare them, instead of using the compare operator, this was an important patch to track these issues down:

    The collision bug, I don't remember exactly the fix. But I found the problem by just reading the code, and walking trough the possible paths in my mind. Resulting in a code path that destroyed the object, but kept the collision data alive in the box2d physics engine.

    Exploring a single level of simplex noise "caves". Looks pretty cool right? It has performance issues which are not visible on the gif, and a lot of other issues. But it looks quite cool already.
  • Just wahooo !! I would like to adapt EE for a submarine simulator, and this feature in EE2 could be amazing ! Great work
  • Nice! Are you looking into any raymarching stuff? I could imagine this cave system rendered as a nebula a la spaceengine although... performance would likely be a concern. Probably a stupid question.
  • Not a stupid question. I'm not looking into realtime raymarching. While the results are really nice, they also put a lot of load on the GPU, and shaders. Which ups the minimal specs quite a bit.

    It would be quite awesome for clouds/nebula. But some of the shader features required for this to work are not available in my targeted specs. (OpenGL ES2.0) as I want the whole thing to work on Android as well. Without the limits that EE1 has.

    These are pretty awesome however: https://www.shadertoy.com/user/Duke
  • edited November 2019
    Cool! Out of curiosity: why do you upload those clips as gif instead of a dedicated video format? Of course gif has a great compatibility, but nowadays mp4 is supported very well by most modern browsers, and would result in a much smaller file. And even if some browser could not play it directly - on slow internet connections, downloading and opening it in a video player would be faster than waiting for the gif to be loaded.
  • Because of this piece of code:

    My engine directly allows gif recording by pressing F3. So it's very quick and easy for me to capture gifs and dump then on my shared folder (which is then directly accessible). No extra tooling needed, no screen recoding software, no encoding software, no waiting. Just F3, play a bit, F3, copy file, copy URL. Done.

    TLDR: Because I'm lazy.
  • How feasible would it be to have a second render target, for those running a decent gaming pc for the main viewscreeen?
  • @daid ah, I see. That's a super cool feature!
  • How feasible would it be to have a second render target, for those running a decent gaming pc for the main viewscreeen?
    Feasible yes, but not a priority. First I should make an actual game I guess.
    Note that one major issue for Android (20% of the devices), RaspiberryPi (2 and 3) and WebGL (depending on your desktop) is the lack of gl_FragDepth:

    Meaning raymarched rendered things won't have depth information, and thus are always rendered in front or back of all other things.
    There are a few ways around this, but they get complex fast and require multiple render passes, which is also not that great for performance, and complex to get right.
  • There is an article in the latest issue of "Seeds" that is called "Procedural Real Scale Planets in Real-Time" which might be of some interest: http://www.procjam.com/seeds/issues/4/issue4.pdf

    However it's lacking in details, and though it links to a github, there appear to be only binaries there, no source: https://github.com/wolfniey/Procedural-Real-Scale-Planet-Generation-in-Real-Time
  • Haven't posted in here in a while.

    But the procjam article is one of the methods I played with. It's quite a good way. But still, it is difficult to get all the details right with any of these methods. Concept is simple, but the devil is in the details. Like subdividing isn't hard, but undoing subdivision that is a lot harder. And partial subdivision leaves all kinds of edge cases.

    My engine also has a limit of 64k of vertices per 3D mesh. So I need to split it into multiple meshes, which complicates things even more.

    (The above has been in a draft post forever)

    Random idea that has been drifting in my mind for a while. How about a very slow text based bridge simulator. Played over the span of days/weeks. For example directly integrated with discord/telegram. Similar to old school MUDs (if anyone knows those)

    You basically sit in a sort of chatroom, and you can give commands through typing. And the game would play out in real time. For example it could take multiple hours to fly towards a destination target. So the helms officer sets up the flight computer to fire the engines until arrival, science uses it's scanners to find the target, and engineering manages that you have enough fuel to get there.

    Science: !scan stations
    Ship: 1 station found at bearing 300, distance 500km
    Engineering: !status
    Ship: Systems at 100% power. Fuel reserves at 80%.
    Ship: Flight speed 10km/minute at 0.42% fuel per minute.
    Helms: !turn 300
    Ship: Rotated to heading 300.
    Helms: !thrust 100% for 50 minutes
    Ship: Firing engines.

    It would require people to work together on longer intervals with shorter "intense" discussion moments. You could chat as much as you want, but proper ship control is only achieved together.

    You might find your ship destroyed the next morning, as you stopped in the middle of the night somewhere in hostile space. So proper real life time planning would be required. Or you might be stranded somewhere because engineering boosted the engines using up more fuel then expected by helms.

    Feedback from the ship could be separated into different chat channels, so you do not have all the information without chatting with your fellow officers. Or multiple officers could control the same part of the ship in different shifts, requiring time schedules. Or you could have a mole on your ship that tries to achieve some alternative goal without the rest of the crew noticing, if you have enough players (for example, try to get the ship stranded without fuel)

  • I've flirted with the idea of a MUD-like thing as well! MUD interfaces have come a long way too, especially with unicode and modern clients. Chat based systems could also be interesting as an irc/matrix/discord thing.

    One thing I like about the slow pace is that you can play with people from around the world. Jumping into different roles would be easier too. The main navigator lives +10 hours and is fast asleep!

  • I got a recent issue reported for SNIS which is interesting from a game design perspective, maybe others would enjoy thinking about some of these things: https://github.com/smcameron/space-nerds-in-space/issues/243

    I will quote the issue as reported here:


    Missiles are too powerful, while torpedos are really hard to use.

    Most fights are either short-lived or never-ending.


    1. Slow down missiles a bit to increase chances of using CHAFF or shooting them down (is that possible?)
    2. Speed up torpedos?
    3. Add some clue to know when blowing a torpedo might damage the enemy (some beep or visual clue that shooting at the torpedo now would have the enemy ship in the range of the explosion)
    4. Make it a bit harder to shoot a missile: Have a «target locking» delay needed before you can shoot the missile, and you need to keep the ship on weapon screen during the delay so that it can be locked.
    5. Make shield more resilient, and try to make it really usefull to use wavelength information. (Something like missile weakening a random wavelength really bad so that if you take the time to adjust wavelength a few shots are enough to finish the job)
    6. Change damage repartition to increase chances of having something broken while the rest works. (This comes from @smcameron idea of having to drive by computer because nav is broken, I feel like situation where you have to keep going with some parts not working might be fun)

    The goal would be to be able to have long interesting battles. Two common scenarios would be one big ship against several small ones (this is what we have in most missions right now), and one big ship against another one (bonus points if this interesting in PvP context).

    Being experienced at the game and team play should be required to win, ideally.


    The more interesting parts (to me) are: "Most fights are either short-lived or never-ending ... The goal would be to be able to have long interesting battles."

    One of the specific fixes for the too-effective-missiles (The player can fire heat-seeking missiles which are super deadly) I have tried so far for SNIS have been to give the NPC ships a special behavior when a missile has locked on to try to evade the missile by moving in a direction perpendicular to the missile's motion (not all that effective as the missiles are faster) and to emit chaff to try to distract the missile. This works ok, though the missiles are still probably too strong, but at least they sometimes now fail to be effective and it might take 2 or 3 missiles where previously 1 would have sufficed. I probably still need to work on the missiles a bit.

    The torpedoes in the game work like this: You aim what amounts to a 1st person gun turret with a mouse, and fire the torpedo with the mouse in the direction the guns are pointed. Once the torpedo is fired, it moves in a straight line at a constant speed in the direction fired. If it comes close enough to an enemy, it will inflict damage. Because the speed is not very fast, you have to lead the enemy. There is a cooldown, and you have a limited number of torpedoes. These all make the torpedoes a bit hard to use. Especially since you also have laser bolts, which are much like torpedoes except they move faster, do less damage, and can be fired much faster. But the misses don't cost much compared to missing with a torpedo, so players tend to lean on the laser. Maybe that's fine. But there does seem to be room for improvement in how the Torpedoes work to make them more fun, and different from the lasers.

    Currently, damage to the player ship is distributed more or less randomly to the different systems on the ship. This means that at any given point in a battle, all of the ships systems will be more or less equally damaged. It might be more interesting to distribute the damage less evenly. One idea I had was to timeslice the distribution of damage, so that (say) for each 30 or 60 or whatever second interval, a new "victim" system would be chosen, and any hits arriving within that time window would be delivered to the same system. This way you would get the sense that the enemy is targeting a specific system, and battles might have different "feeling" from one another depending on which systems were targeted during the battle. Hard to know without trying it whether it's a good idea.

    One thing I noticed a couple of years ago was a long-standing bug with the damage distribution system. The intent was that for each hit of a laser or torpedo on the player ship, damage would be distributed among the systems randomly, and each system would take some fraction of damage. However due to a bug involving unsigned integer math, systems could actually gain health when hit! The result of this bug is that you tended to live when you should have died, and it seemed that you would scrape by by the skin of your teeth. You can see this bug in action in this old video: https://www.youtube.com/watch?v=nTBiM5zJi8A&t=521s

    Around the 6:00 minute mark, if you watch the warp power on the Nav screen, you can see it goes way down, then back up due to changes to the damage to the warp drive components. At the time, I thought this was just the repair robot doing its thing (if I noticed it at all). But the point is, this bug made it seem like I was just barely surviving, and fixing this bug kind of wrecks that behavior (not that that behavior made any kind of sense). However there's a common trick which I am strongly considering implementing, which is to make the last few of the player's "hit points" a lot tougher for the enemy to remove, to encourage this kind of "just barely surviving" outcome.

    Anyway, any ideas you may have for making the battles more interesting would be interesting to read.

  • Warning: This is a spure of the moment trainwreck of thought.

    HP 0 = blow up/dead is a very old game mechanic trope that is easy to understand. A nice explosion at the end helps close that combat loop. But another spin is to set up mission objectives that do not explicitly require destruction of ships, even in combat-centric sessions. Defend a starbase for x amount of time, escort a payload from a to b, etc. Ships no longer have to be destroyed, just disabled or forced to retreat. Fewer satisfying booms though. This leads to...

    ...treating ships as a collection of systems and sub systems instead of a monolithic ship (even more than they are now). This idea stems for a space engineers like survival game I wrote a doc on. The player character doesn't have hit points, but instead can have inflictions - traits that might be permanent or on timers, might be visible to the player or hidden without the right diagnostic tool, and may go away after the timer runs out or kills the player. I liked the interplay that it could give to a medic profession, something more intricate that just pointing a magic heal ray.

    Fighting a ship wouldn't be a generic slugfest seeing who can get the other to 0 hp first. It would be trying to disable the other ship by targeting and taking out their ship's systems. These systems would be both mounted on the surface of the ship (weapons, sensors) and interior locations. Where a ship is hit would influence what is damaged (inflicted) or even destroyed. Treat the ship as voxels (not as a blocky rendering but to model how the ship is being damaged). Simulate heat so a player has to figure out where the in-universe equivalent to a warp core is by looking at an IR view. Different types of weapons and missiles will inflict damage on the ship in different ways.

    Combat for the bridge crew would hopefully be more fun and tactical. Pilot will need to be mindful to keep very damaged sides hidden. If a player's system goes out they could conduct their own basic repairs.

  • There is some interesting discussion here, on the discussion board for Oolite (an open source single player space game inspired by the original Elite game) about NPC pirates, and in game economies, cargo contracts vs. trading commodities directly, etc. http://aegidian.org/bb/viewtopic.php?f=2&t=20569

    There are other threads on that board possibly of interest as well...

    The 370+ page screenshots thread: http://aegidian.org/bb/viewtopic.php?f=2&t=4494&start=5565

    Some talk of shaders, and towards the end you see they have implemented a physically based rendering system (though the shader code appears to be licensed under a GPL-incompatible license, a CC-NC variant, iirc. unfortunately for me... although even if the shaders are a major part of a PBR pipeline... getting/making PBR assets is no small thing either.)

Sign In or Register to comment.