Last Few Mobile Bugs, and Flight Planning

Hey Folks! A little bit of catch-up this morning before jumping back on the orbital plotter.

Tiago sent me his latest update, and we're basically down to 3 issues, and two procedural tasks for me to do once the launch is initiated. In other words, we're almost good to go!

Of course, we'll still need to test these latest changes. And flipping the launch switch has a series of steps and things to wait for. But this is about as close as we've ever been!

For the orbital plotter, I'm starting work on a way to plan a route to a point in the System. And for that to work, we need to know not only the current situation, but what it will look like when we get there. Trips are measured in days, weeks, or sometimes months, and a lot can change in that time.

So one approach I'm going to use is a "projected positions" plot on the system map. You can see where everything is in blue, and where everything will be in orange. More specifically, where things will be at t, 2t, 3t, and 4t, where "t" is some amount of time in the future.

For example, we can see Mars is at its current blue position, and then adjust the tool to show us the positions for it over the next 4 days at 1-day increments. This way, we can set a heading and thrust amount, and plot our ship's projected position at those times, making adjustments until the final projection of our ship is near the final projection of Mars.

If you've ever done animation or stuff in Flash, this is sort of like working with animation frames on a timeline and "onion skinning."

And, of course, this is totally experimental. I'm just thinking it's a way for users to fairly intuitively plot a path from A to B in an orbiting system with long transit times. And it follows the design goal of flying the ship indirectly through "beep boop" control panel stuff. Lots of flipping switches, turning knobs, punching buttons, etc.

We'll see soon enough if this is usable!


spacecowboy's picture

As far as plotting points goes, will this be just clicking and watching it fly or doing some minor orbital stuff, such as direct transfers and orbital transfers as well as thrust and other things?

Asthepanda2iscool2's picture

The space game is going to be quite complex, to say the least. When you posted the first few screenshots I though "FTL+NS". Obviously, this has neither a hex map, or a FTL beacon map.
Hope it works out in the end!

Quick question:
Is there any way to set the player spawn in NS to be random? Would I just remove input values for the spawn area, or would that break the game?

Rar! Rar rar rar! Thanks for reading :)

Malacodor's picture

Not being a fan of KSP, I was sceptical about a too realisitc approach, but your description sounds pretty usable.

Ran around with a clown mask before it was cool

ra1's picture

Perhaps if you are near a planet with a "near-orbital" vector, the game could automatically correct for the player, thereby putting them into a good orbit.

dcfedor's picture

@spacemedic, a lot of this is TBD based on prototyping and testing. I'm aiming for a mix of engaging and realistic, without getting frustrating. The player should feel like science matters, and carelessness costs, but also can play the game without fighter-pilot reflexes and studying orbital mechanics for 20 hours.

The current thinking is plotting a course on a flight computer and letting autopilot (AP) do it's thing for the bulk of the time (trivial course-corrections, controlled burn times). And for certain maneuvers, maybe letting the player take over.

Also, it's worth mentioning that the universe assumes fusion rocket tech is good enough to sustain ~1-2 gs for most intra-system trips. This means the ship has artificial gravity opposite direction of travel.

It also means the flight paths are less orbital and more direct. Or at least a mix of the two. So most trips are going to be player plotting a course, AP aligning and initiating burn, AP accelerating halfway there, AP warning crew of 0 g rotation maneuver, AP rotating, AP burn-decelerating on the tail end, and AP aligning for docking.

The path may arc a bit due to passing by grav wells, and this may require AP to suspend and alert crew for re-plotting. AP may also defer to the crew for maneuvers like the midway flip or final docking.

But again, we'll need to see how it feels before deciding.

@Asthepanda2iscool2, complex, yes. But hopefully not complicated! The ultimate goal is fun, after all :) Fantasy-fulfillment of operating a space frigate and chumming around with the crew.

Re: modding NS to have a random starting location, you can probably do it two ways pretty easily.

First, by choosing bogus coordinates past the edge of the map. If the game sees the starting hex ID as too large, it'll choose one randomly on the map. So if X,Y was something like 10000,10000, that should work (depending on how big the map is, and if 10000 is big enough to pass the edges).

Alternately, if the gamevars specify an impassable starting hex, it'll also choose one at random. So if you choose 0,0 on the standard map (which is ocean, I think), that might also work.

@Malacodor, yeah, that's sort of the fine line I'd like to tread. More accessible than KSP, more realistic than most other games. Playing the game shouldn't require a degree in hard science, only an appreciation for hard science.

@ra1, this'll be an interesting area to experiment with. I am expecting there to be both stations to dock with, and celestial bodies to land upon. In either case, velocity-matching is going to be crucial to avoiding a crash or wild miss.

In most cases, the transit distances are so large that the whole trip will have to be planned around arriving at the right spot, at the right time, with the right velocity. There's room for error, of course, but that means lost time, fuel, supplies at best.

In other words, if you use the flight nav to plot a course to Mars, some (probably large) chunk of that trip is going to be gradually matching Mars's velocity at the destination time/coords, and the flight nav is going to do its best to plot it for you.

Of course, I could probably also make it possible to "wing it" by exposing thrust controls directly to the player. And I probably will for those times when the flight nav is on the fritz, or other crises :)

Dan Fedor - Founder, Blue Bottle Games

Asthepanda2iscool2's picture

Do you mean just changing the creature source? If so, that hasn't worked for me. The only way I was able to change the start was by making a new encounter, and having everything have a nX and nY of 19.
So I know half of what I'm doing?

Rar! Rar rar rar! Thanks for reading :)

dcfedor's picture

Not the CreatureSource, the GameVars table.

There should be "nStartHexX" and "nStartHexY" in the gamevars.xml file. In vanilla, they are set to X=20, Y=164. This is the position at which the player will spawn when a new game starts. It's the Cryo Facility on the map (20 hexes east, 164 hexes south from the NW corner of the map).

You should be able to change these both to 0, which would equal the ocean tile in the NW corner. The game will see that it is impassable, and try to find another hex at random before spawning the player in a new game.

Dan Fedor - Founder, Blue Bottle Games

Asthepanda2iscool2's picture

Thanks! Like I said, I've been able to change the start position, but I was using an encounter to do so.

Rar! Rar rar rar! Thanks for reading :)