Back In Orbit
Hey Folks! With yesterday's mobile build v1.2.5 still rolling-out, and no apparent fires to extinguish yet, I turned my attention back to the space prototype. And it was a fairly productive day!
One of the first things I added was human-readable velocity and distance info to the current point of reference. This way, we can see things like m, km, Gm, or AU instead of gigantic (or tiny) numbers all in AU. Apart from simply making the user's life easier, it's making my job easier as I can now get a better feel for how accurate it is at-a-glance.
And to further that end, I changed the rendering code for each planet to switch to actual planet size once the on-screen size exceeds a 2-pixel radius. This way, they are visible when really far away, but as one gets closer, I can see how close to the planet's surface I am. (Note, this is all still vector graphics, as we're inside the ship's flight computer console. The image above is what we're seeing at the moment.)
I also made a few changes to the UI terminology to make it clearer. "LOCK" has now become "HOLD," since that's basically what that button does. It "holds" the current target while you browse around. Similarly, I changed "SNAP" to "FREE," since it sounded more like what you'd find on a control panel. I.e. course target switches between FREE (anywhere in space) or not (snapped to nearest object).
Getting into the meat of the code, I made some more changes to the way it compensates for initial velocity during the course-plotting. It turns out I wasn't doing that correctly after all.
And in the process, I also discovered that the course's endpoint gets less accurate the faster the simulation is running, since it has larger time slices over the trip. This isn't a surprise, but I had to be reminded of the impact. I was seeing wildly different results when testing my compensation code, only to realize that slowing it down closer to real-time made it way more accurate. (To the point where I was satisfied it needed no more tweaking.)
In the final game, I'm expecting this won't be an issue, as there won't be much fast-forwarding. The point of the game, after all, is to enjoy and interact with the drama and events during the trip, not skip over it. If there is any fast-forwarding, it should be within a scale that won't break the flight code.
I added a new readout on the panel (not seen above) that shows the projected flight duration, since that's part of the game loop. Players are going to need to make sure they have supplies for the intended trip, so this is a pretty basic need.
Finally, I started adding a gravity component to the flight model. On most trips, it'll only be a minor factor. But there will be cases where it's a big deal, such as massive celestial objects and running out of propellant. (Not to mention, debris and derelicts.)
This is where I ended today. Most of the code is in there, and I think it works generally. However, I've already noticed it screws with the planet rendering, as it appears to project the blue "real-time" planet image into the future when calculating gravity, so I might be operating on the wrong objects. That, and there appears to be no effect yet when flying by the sun, which I think has to do with the gravity code not correctly finding which body acts on a ship at a given point in the future.
So that's where I'll pick up Monday, assuming NS mobile doesn't explode in the meantime. (Fingers are crossed. v1.2.5 should actually make things better, buying me more time to do this project for a bit.)
Have a good weekend, all!