Orbital Plotter Love

Hey Folks! While Tiago works on the Android save patch, I decided to try and get some more prototyping done on the plotter. And it's getting pretty close to usable.

One of the most obvious changes today was switching the line renderer to use colored solid lines instead of textured lines. I like the visuals slightly less, but it allows me to prototype a lot faster if I can just plug color values in rather than making new textures for each new color.

And with that change, it became easier to do things like custom colors for different celestial body types (sun, planet, asteroid, centaur, etc.). I also could make projections dimmer versions of the original. And as you can see around the sun in the image above, I now have gravity wells in a dark red. They roughly correspond to 25% Earth g, which is also about 25% of typical ship thrust. It's sort of an arbitrary number, but represents a zone where the pull will significantly alter trajectory compared to a 1g thrust.

And that brings us to the next point. Gravity works now! Not only on the realtime ship position, but also on projected future positions. The image above shows projected ship positions bending around the sun's grav well as the ship attempts to reach the course destination crosshairs. It's still far from perfect, as the step size affects how granular the calculations get. And depending on how close one of the steps is to a grav well, it can over/underestimate that well's effects.

I briefly attempted to account for this, but didn't make much progress. I'll skip that for now, since it's maybe good enough for now, and not the most valuable way to spend my time.

I also rearranged and added some new UI bits as I went. One of the big changes is a new "FOLLOW" button, which basically locks the camera to the ship as it moves around. Useful for finding a ship when off-screen, or keeping a watchful eye on surroundings.

At this point, there are still some improvements I can think of, but it might be a good time to switch back to the crew simulator and take this for a test drive with an actual ship and crew. In theory, I should be able to swap-in a real ship for the test one I've been using, and raise this UI when a crew member interacts with a console. And when the player hits the "ENGAGE" button, the actual ship will start navigating.

Then, I can start testing things like whether the timeline is workable or needs fast-forward. I can also probably pick some arbitrary "good enough" distance and speed at which the game thinks the player reached a destination. E.g. if they approach within 500,000km with a relative velocity < 5km/s, consider them docked. Or maybe switch to a docking minigame. (I hate that word, but that'd basically be accurate. E.g. align the docking rings and adjust reaction control thrusters to connect)

If I can get something like that working, we actually have the beginning of a game loop!

  1. Choose destination
  2. Calculate course, duration, etc.
  3. Buy supplies for trip
  4. Undock
  5. Engage course
  6. Drama happens for days
  7. Reach destination
  8. Docking "minigame"
  9. Do stuff at destination
  10. Repeat

And if bad/interesting stuff happens during #6 (or any stage), course gets aborted or diverted, or the ship continues drifting, etc.

Of course, I still have to add a bunch of what I said up there. But some major portions are already done. Namely 1, 2, 5, 6, and 7. But keep in mind that this plotter UI was #s 1-2, and took months to do. Similarly, #6 is a whole ball of yarn that took months, as well. And it's pretty darned spartan :)

In other words, we're a ways off yet from playing anything. But the skeleton of a game is almost there!

Comments

Marc13Bautista's picture
Marc13Bautista

Hey, that's pretty good!

Free Elusive Skill = Athletic x4 in ATN Enclave encounter

Rovlad's picture
Rovlad

Pretty sure autopilots could handle auto-docking that far in the future, I mean space stations are already (kind of) doing this stuff, only needing human input as a failsafe or in case of unforeseen circumstances.
And NEO Scavenger already had a full-fledged AI right here on post-apocalyptic Earth. Pretty sure it was hinted that it wasn't the only one either. :)
On the other hand, as long as it's immersive, fun, not a chore and can't be an absolutely catastrophic failure (e.g. "you missed a ring, game over"), then who cares.

ra1's picture
ra1

In a previous post, you mentioned problems about simulating the game at fast speeds due to rounding/precision problems. One possible workaround would be to still simulate those fast speeds at the normal rate (or the fastest rate you can without getting errors), but hide some of those steps from the player. This of course presumes that you have enough CPU to do this.

So, if normal speed has 10 calculations per second, then at 10x speed you would still calculate all 100 frames, but only show every 10th frame to the player.

dcfedor's picture
dcfedor

@Marc13Bautista, thanks!

@Rovlad, yeah, that's the thinking. The game is safely enough in the future that I can gloss-over anything I need to, but if it's still fun to do, I'll probably expose it. In space sims I've played before, I kinda wanted the experience the first few times, then was fine letting the AI do it to get it over with faster.

Though, if I give players the option to let the autopilot handle it and they insist on manual override, they will certainly die in a fire if they screw up. Serve's 'em right. Hotshots :)

@ra1, that's definitely one approach. I'm sort of waiting to see how much of an issue this turns out to be, which is why I might shift gears to other systems for a while. If the max fast-forward is only 2-4x normal speed, it might not matter.

There are also some integration methods that can be used to solve this sort of stuff accurately, rather than brute-forcing it. That requires me to work harder now in exchange for CPUs working less in the future :)

Dan Fedor - Founder, Blue Bottle Games