Search form

Still Waiting...

Hey Folks! Hope everyone had a good weekend. Mine was quieter than expected, largely due to the app status. There's little to do right now on NEO Scavenger mobile except to wait for Apple to verify the latest build.

I don't think Apple does any app review on weekends, so I decided not to bother waiting for them to clarify their rejection. There was a debug button in that build which should'nt have been, so that required a new build anyway. And during the upload, I could add a note specifically to address their missing button concern. If that does the trick, I can proceed to submit the Android version!

And worst-case scenario, the IAP button is still a problem, and I need to make a change and upload a build. Nothing lost by resubmitting with the debug button removed in the meantime.

But no change today as of 5pm Pacific, so it looks like I'll have to wait another day at least.

Since that was in a holding pattern, I decided to dust-off the orbital plotter for the space prototype. Last time I left it, it could plot a course to arrive at some destination at a full stop, accounting for the constant movement of the target over the trip. (Basically, arriving where the planet will be.)

This is all fine if you're starting from and stopping at a stand-still, which will pretty much never be the case in space :) (Most of the time, you'll be both starting and stopping a trip at a stand-still relative to a moving body like a planet or station, so basically orbiting.)

Adding a component to match the target's velocity at the end turned out to be not too bad. I had that working in short order. Basically, it was the same as the stand-still approach plus an acceleration component to match velocities applied over the whole trip. (Assuming a zero starting v makes the equations extremely simple.)

However, that still assumes a starting velocity of zero, which is still pretty unlikely.

So now I'm trying to do the calculus of a ship with a starting velocity making a gentle rendezvous with a planet/body hours/days/weeks away at safe accelerations. This is turning out to be a bit trickier.

For one thing, assuming a non-zero starting velocity means my ship can't just point at where the planet will be after a direct flight. Using the above rendezvous code will get my ship into a position near the planet with a zero relative velocity, but potentially still too far away to be useful depending on the starting v. I'll have to account for this starting v's effects over the whole trip, and counter them with a thrust component. And the minute you add non-zero starting v to these equations, they get a lot more complicated. No more factoring entire chunks away to zero :)

Taking a step back, here's a refresher on the "why" of this course-plotter. (This is for me as much as for you, thinking out loud to make sure I'm not insane :)

I don't want the player to dogfight-fly their ship around. For the most part, they won't be flying realtime to their destinations. Instead, they'll log in a course, hit "engage," and walk away to deal with other things on the ship (like maintenance, crew drama, etc.).

The ship will follow that course for hours/days/weeks of in-game time until something "significant" interrupts things. Maybe a ship is detected on an intercept course, or has passed through a grav well long enough to get off-course, or space debris is dangerously close, or the engines blow, leaving the ship to drift. Whatever happened, the course plotter sounds the alarm to let the crew know they're needed.

Then, the player moves the crew to the controls, opens the plotter, and decides whether to cancel the alarm and continue the course. Re-plot a course. Take evasive maneuvers. Or whatever.

So getting this thing setup to project a long-haul course across the System and execute it is kind of inside the core game loop. The Kerbal Space Program approach is to project current course/orbit and let players fast-forward until key points where they execute maneuvers manually. (Or it was last I played it.)

I'd be okay with players being summoned to deal with mid-course back-flips to reverse thrust. That fits, in my mind. But part of me thinks the ship needs to at least show you how this 2-phase burn maneuver will work out in order for the player to trust committing months of in-game transit time to it. They need to see the route on screen to decide if it's safe/good.

And arguably, you'll want the computer doing most of the fine orientation and burn time executions anyway, since even tiny errors due to human input could be catastrophic at interplanetary/monthly scales :)

I'm waiting to submit Google until Apple is ready, because I can tell Apple to wait once it's approved. Google, on the other hand, launches it immediately after approval. And their approval process could be anywhere from 2 to 48 hours.

So basically, I'm getting the Apple version ready and "on deck," and then submitting Google. And once Google releases it, I'll manually release the Apple version to coincide.

As promised, mobile is complicated and unwieldy, right up to the last minute :)

@Malacodor, I think that might work if the target were not accelerated by gravity (e.g. planets are orbiting the Sun). Then, I could just assume the ship is at zero velocity and the planet is faster/slower based on relative velocities.

However, many/most of the targets players travel to are going to be accelerating/orbiting. So I won't be able to use that cheat :)

(Well, I could, I suppose. Just pretend the orbital acceleration is approximated by some velocity vector. It'd work for small enough periods of time. But I'm unsure if that would work in trans-System flights.)