Navigating and Piloting at 1G... for multiplayer?

[Boxx]

Hi all, the problem with Hohmann transfers is the time it takes to go to the next planet!!

Just imagine that our engines could deliver a continuous thrust at 1G during days or weeks. It would take a couple of days to reach Mars or Jupiter. It would be even safer for the body.... Well, turning off the "limited fuel" option, I developed a navigation tool to fly at 1G. Indeed, I reached Jupiter's moon Callisto, departing from Mars/Deimos, in about 5.5 days of flight: here attached is my flight record for playback (in the coming days, I will add a system.dat file to comment on the milestones).

The tool is still manually interfaced with Orbiter 2016 (under Matlab/Octave) but I am thinking that it could become a great approach to play in Real-Time with Multiple Players (RTMP). No time-warp, no need for weeks of boring interplanetary transfers and, again, safer for the crew! The maximum acceleration applied during the flight was 1.07G during the braking phase to Callisto. Feedback welcome

 

[Face]

Hy Boxx,

nice work there! Having a tool to navigate with 1G flight-plans is certainly a much appreciated addition to one's Orbiter tool box.

However, I think this tool alone will not solve the problem that multiplayer suffers from in the context of Orbiter. To me, this problem looks like follows:

1. Too small a community. Here I don't mean the Orbiter community itself, which is already small compared to other games/sims, I mean the community of people wanting to engage in multiplayer in Orbiter. You'd say that this is just the same, but my personal experience is that most Orbiter users do not want to engage with other people inside the simulation, because their personal play-style better fits to single-player mode.
2. No robust persistence. Running an Orbiter simulation session usually consists of 2 alternating phases: intense controlled real-time flight and time-accelerated observed coasting. If you use Orbiter in its natural single-player mode, just leaving the simulation by shutting it down, and coming back later is always possible in both phases. Your progress persists and you can just pick up where you left it. Multiplayer obviously has a problem with this: on the one hand you can't simply freeze the object states, lest they are "left behind" the global progress, on the other hand you can't just leave them in the simulation unpropagated, producing awkward situations with objects defying gravity and the like. On the gripping hand at last, you have to persist the personal progress on the server side robust enough to survive shutdowns and/or bug crashes.
3. Lack of content. This boils down to the question: "why should I play with others in Orbiter?" You'd now say that there are so many reasons to have multiplayer, but after like 15 years of multiplayer implementation I can tell you that in practice, there really are not that many at all. Sure, the first orbital meet-up with docking is interesting, the first mission control game-play is funny, hanging around a space-port and doing quick race events is cool, but in the end, that's about it. What people quickly miss in multiplayer sessions in Orbiter is progress. They can do their own narrative, their own missions, their own VSA easier in single-player mode, and so they do.
4. Dimensions. On thing that makes it particularly hard for multiplayer in Orbiter is time accelerating, or better yet: the dimensions involved in the simulation. With this I mean that we have huge velocities, huge distances, huge travel-times to take into account. Orbiter's way to deal with those dimensions is by means of time-warping the whole "universe", so to say. Where traditional multiplayer games/sims would simply accelerate the single user in the fixed environment, Orbiter accelerates everything. It does so in order to maintain a realistic means of travel, i.e. simulate the trajectory as it would be in real life.

My naive approach with OMP - just slapping a multiplayer architecture onto the sandbox - failed for each of these aspects:

1. It focused on P2P to offer twitch-based operation even for 500+ users, yet the maximum ever recorded was like 15 users.
2. OMP doesn't do persistence at all. Everything is done on clients, the server is merely a broker to let clients do handshakes.
3. There is zero content in OMP (let's ignore the missile toy here). It tries to keep up the sandbox nature of Orbiter.
4. Although there is architecture in place to deal with the huge velocity problem (relative state vectors instead of absolute one), OMP is practically real-time only, thus not dealing with the huge distance/travel-time. People had some tools to accommodate for this (server time skipping, jump feature), but it was a workaround.

As you can see here, your tool would perhaps help with dimensions, but even then it would make other things worse, particularly the community part, because most would shun the "unrealistic" 1G trajectory just to overcome the inherent failures of OMP.

Therefore, I have long put OMP development on hold in favor of a different project that I call Orbiter Multiplayer Universe, or OMPU. In this project, I try to tackle the points mentioned as follows:

• Gamify the simulation, although staying within the simulation parameters. This basically means that I dropped the sandbox nature, and instead added economics to the mix. I hope this helps with 3 (content) and 1 (community).
• Be persistent right from start. The project is cloud-based and saves user data in big tables. This means that your progress is not lost if the client or (a) server crashes. Should help with 2 (persistence).
• Deal with the time-acceleration problem. This is done with the space-time-bubble concept and an accelerated mainline. Should help with 4 (dimensions).

In essence the last point means that each user is free to hop between space-time-bubbles - thus can time-accelerate the simulation as usual - but has to join the bubble he wants to do economics in. One space-time-bubble is special: the server one. In this bubble, all station and port interaction is done. In addition, this bubble is always time-accelerated x20. So instead of artificially accelerating objects in a fixed x1 environment, the concept keeps the realistic trajectories in a fixed x20 environment, resulting in faster travel times for faster content play. On approach to objects in the accelerated main-line, the "space" part of the space-time-bubble concept comes in: you can "lease" access to the object for a limited time by means of dock/undock or land/start clearance, which will drop you into a space-time-bubble with the server object at x1 acceleration. Once you completed your dock or land operation, you'll be accelerated again and be free for trading/interaction. This helps with causality of content interaction while still keeping game-play changes to a minimum.

So why x20? The reason is that realistic space travel takes a while. Let's check some examples of possible game play:

• Resupply ISS: user starts with DG from KSC, picks up cargo, flies to ISS, delivers cargo, flies back. How long does it take? Usually, an Orbiter user would wait until the station is "over" the launch side, then start, circularize, align plane, sync, approach, dock. Depending on the start MJD, it could take up to 7 hours waiting for the optimal position, then perhaps 6 hours for the complete transfer. For the return, lets add another 11 to again compensate for position waiting. Just guestimating here. We will end up with 24 hours in x1, or a day, of game-play length for such an easy mission. Now in the single-player mode, the user would accelerate up to x1000 for the first 7 hours, then start in x1, climb to orbit, circularize. The align and sync phase might already happen in the x100 acceleration. This would bring us to perhaps half an hour game-play for the first 13 x1 simulation hours. The server time-line would have advanced 10 hours in that game-play time, so the player is at position, but has to wait for 3 in-sim hours in order to sync with the server now, which will take 9 real-life minutes. After that, he can do the cargo delivery. The return trip might take him a little longer, due to the atmo flight, let's say 45mins real-time until touch-down. The server has advanced 15 hours in that time, so before another cargo mission can be done, the player has to catch up the 4 hours difference by means of accelerating faster than x20 on the ground, let's say x1000. This would take him under 5 minutes of waiting until he can continue to do other missions. Why the waiting? Because other players might have changed the economy as well. That cargo you want to deliver? Perhaps another player already delivered something, so now there is no need for it anymore. Or the price dropped, or other things could be brought back. LEO game-play: 30+9+45+5=89mins vs. 1 day sim-time.
• Race to the moon: user A starts a high speed trajectory, user B a slow transfer to get his vessel to the moon, both want to deliver a flag to tranquility base. Due to the demanding high speed flight-plan, user A takes 6 hours of real-time to get it done, user B's traditional approach is mostly coasting along, easily skipped with high time-acc, thus only using 1 hour of real-time game play. However, since A's flight-plan takes like 24 in-sim hours to the moon, while B's 3 days. When both want to deliver that flag, they have to wait for the server to sync. Since user A played for 6 hours, the server advanced 120 in-sim hours, or 5 days. The trajectory took him only 1 day, so he can catch up the 4 days by means of high time-acc, let's say x1000, which will take under 6 minutes. So after 6 hours and 6 minutes, user A can deliver the flag. User B played for 1 hour, the server advanced for 20 hours. However, the trajectory took him 3 days in-sim, so user B has to wait until the server catches up. He can only do so by stopping completely and waiting for the x20 to catch up, taking approx. 2h30mins. So user B can deliver the flag after 3.5 hours, which makes him win. As you can see, the causality is broken, because user A took too long in real-time to do his flight, but on the other hand, it is not, because it is as if user A took a nap for 2 in-sim days before he headed over to the delivery place. If user A managed to fly his trajectory in like 3 hours real-time, he would have won the race, although B was faster in real-time. The example demonstrates that while the accelerated server time-line is making the economy more fair under individual time acceleration, it is no silver bullet. Of course the example is exaggerating the real-time game-play of A, but it shows the concept. Moon game-play (in a fair scenario): 3.5 hours vs. 3 day sim-time.
• Explore Europa: user simulates the Europa Clipper mission, with 5.5 years duration and grav-assists after 4 and 14 months, respectively. The server timeline for the 3 points in time (4m, 14m, 5.5y) would be approx 6, 21 and 100 days. So the player would start the mission in x1, establish the trajectory to the first grav-assist (Mars), then log off and return after about a week, do the grav-assist in x1, establish the trajectory again and log off, return after about 2 weeks, do the second grav-assist (Earth), then log off again and let it rest for approx 2.5 months. This long real-life time is comparable to long exploration game-play in games like e.g. Elite: Dangerous. Jupiter game-play: approx 3 months vs. 5.5 years sim-time.

What would be interesting now - and that brings me back on topic after this wall of text - is how a 1G mission would look like in this setup, if we assume that the 1G propagation keeps on running during the offline phases as well. Perhaps you can detail a typical flight-plan with your method regarding actual game-play timings.

 

[Owenmck]

Another good thing about OMPU is the fact that you can possess multiple “users.” This is useful, as I could have a vessel I owned around the moons of Jupiter, and another at Earth. So, say someone wanted to trade something at Jupiter, but I was at Earth. It would be a long trip out, with a long wait for the server to catch up. But if I had a different vessel that I was in control of in the area, this would become feasible.

Also, if orbiter starts using astronaut classes as well as vessel class, multiplayer could be astronaut based rather than vessel based. So I could only pilot vessels that my character is currently inside. Probably won’t happen as there are several issues with this, but just my two cents.

As for the 1G idea, I think this sounds really cool and I think I’ll try out a few flights with it

 

[Boxx]

Thank you, Face and Owenmck, for these thoughts. These topics must be addressed in my "1G" approach, indeed, and I will come back on them...

First, I want to provide this new example, simple + short + commented: from Low Earth Orbit (at ISS) to a circularized Low Lunar Orbit (112km altitude) in less than 4 hours of flight. The attached .zip contains a typical Flight Plan (ascii .txt), the scenario file (.scn) and the playback subfolder (for Flights folder) with comments. Below, the plot shows the chronograms of Altitude w.r.t. Moon, Velocity w.r.t. Moon and "felt" acceleration (non-gravitational).

The Flight Plan consists of 2 sets of maneuvers (after ~40mn of flight and after ~2H to re-align and flip), then the last 40 minutes were piloted strictly visualy (no computation, it was cool!). Directions are computed in Equatorial grid (cape in Azimuth, Elevation) and Euler angles to be input in the Scenario Editor as I could not find any MFD for that. This is an important issue for 1G and I can comment on that.

I hope it will help figure out how it looks like and what kind of missions can be addressed (quick answer is "deep space"). My Matlab/Octave tool will be made available, however I don't think it will be easy to use and I'd better think about an MFD solution!!

 

[Boxx]

Regarding the space-time-bubble concept:

if I understand correctly: I am in my bubble while the server runs at x20, I do my things (at variable acceleration rates) and, when I'm ready to re-sync, assuming my bubble's time is ahead the server's time (otherwise I have to accelerate my time to be ahead of the server's time), then the server picks me up when its own time reaches mine and both "worlds" are synchronized, correct? Then, there is not any mulitplayer game-play (only updated worlds from time to time) because in my bubble I'm alone and in the server's bubble there is not any interaction expected.

Jumping to @Orwenmck's ideas, I also understand that a bubble is defined by the objects you put in it, not by any geographical limits. But one bubble can only become multi-player if its time-acceleration is constant (namely x1) for everybody in that bubble.

Well, my 1G-approach is fully compatible with your space-time-bubble concept: before a maneuver, you re-sync locally from the server, make your computation, then your maneuvers, then propagate ahead the server's time and re-sync again... and so on. Again, instead of 3 months IRL = 5.5 years sim-time, you'll get there in 5.5 days sim-time = Mars-Jupiter (6.6 hours IRL, including maneuvers, but still intense actually!). IMO, the problem with traditional navigation there is the "way back from Europa", how do other players interact during 2x5.5=11 years in their own bubble?! It looks to me like a game-play centered on one mission at one time... isnt'it? Could parallel scenarios be run? not sure...

Anyway, what I see in this concept is that you can transfer state vectors from a bubble to another bubble, paving the way to a multi-server implementation and that's very interesting. My idea with 1G is, of course, to set up x1 acceleration in all bubbles... or maybe x0.1 for beginners in multiplayer flight-schools

(I'll come back about the other topics a bit later)

 

[Face]

Regarding the space-time-bubble concept:

if I understand correctly: I am in my bubble while the server runs at x20, I do my things (at variable acceleration rates) and, when I'm ready to re-sync, assuming my bubble's time is ahead the server's time (otherwise I have to accelerate my time to be ahead of the server's time), then the server picks me up when its own time reaches mine and both "worlds" are synchronized, correct? Then, there is not any mulitplayer game-play (only updated worlds from time to time) because in my bubble I'm alone and in the server's bubble there is not any interaction expected.

Your last deduction is incorrect. You can sync to every bubble you want, and in every bubble, you see the other objects in this bubble as well. It is full multiplayer everywhere. However, if you want to trade with the global economics, you have to be in the special x20 server bubble. You can still trade with a fellow player in his x1 bubble, or in yours.

For example, if you plan a fleet trip with your friends to the moon, each of you can launch in his own bubble to LEO (seeing only his own vessels), then decide who should be the "leader" controlling the fleets time-acc, join that leader's bubble, then see each other while flying to the moon with the time-acc the leader selects for the fleet's current flight-plan phase. Once you reach your target, everybody can switch to the server bubble in order to sync for e.g. space-port trading.

Except for the economics part, this is already implemented and tested with a few beta-testers. In addition, there is the possibility to see "ghosts", which are vessels from other bubbles you only see on your instruments (e.g. for orbit estimations), but not as meshes.

 

[Boxx]

then decide who should be the "leader" controlling the fleets time-acc, join that leader's bubble, then see each other while flying to the moon with the time-acc the leader selects

Ok, it makes sense. The concept is really cool, indeed. I think that 1G-Piloting makes no difference. Maybe the server's bubble would be a bit too quick... I can't wait to give it a try, anyway.

By the way, good news for pilots: I made some tests and it appears that, at close range (in Earth's orbits), the 1G-Piloting does not even request any special Navigation tool. Then, I will soon publish a commented playback as a tutorial for anybody who wants to try 1G-piloting.

My naive approach with OMP - just slapping a multiplayer architecture onto the sandbox - failed for each of these aspects:

Your experience is of high value (it makes me remind your "pole" some time ago), let's see the 4 issues:

1. Community: individual's play-style vs. collective game-play? you talk about gamifying, I'd rather separate between a "distribution" (a minimum set of technical features for multiplayer, where I think 1G-Nav is key) and a "universe" (i.e. the scenario behind the persistent objects for 1 instance of the distribution, which requires development, animation and maintenance... and salaries... it's another story...).
2. Persistence: IMO, your space-time-bubble concept is a good approach to dispatch what should be persistent and where (clients, server(s)...), how syncs are done, what is computed in clients, what is in server... hence, architecture = distribution-related.
3. Content: I'd put a warning, a "distribution" should include many features and objects already (vessels, interactions...), but everything that is "too much" (?) related to the scenario, should not be included at a distribution level. An example is the monitoring of "acceleration", IMO it must be in the distribution because n-G accelerations are no-sense in Orbiter realism as well as 0-G during months... see also below.
4. Dimensions: your space-time-bubble concept is nice, it looks to me distribution-related and the set up of an instance should allow the change of acceleration rates. In my 1G-idea, I would put everything at x1;

For Community as well as for Content (of a distribution, not of a scenario yet), I think we should focus on the very spirit of Orbiter = "You can pilot in space, but don't insult your intelligence". OMP/OMPU cannot and shall not be in competition with Star Citizen or Elite Dangerous and the reason is that "piloting" is our game-play (let's make a pole?), not theirs.

I want to suggest something in this spirit: if piloting is our game-play, then the health of the crew is related to the physical laws and should be the main driver => let's model simplified effects of acceleration, weightlessness and duration of flights, which is much more intrinsic than the number of kg of propellant (imagine new engines...).

Also, if orbiter starts using astronaut classes as well as vessel class, multiplayer could be astronaut based rather than vessel based.

I second that!, which is completely in line with my hopes: we should distinguish between a vessel, an orbinaut (the avatar inside, depending on the number of seats) and the user. I think that the user controls ("hires"?) an orbinaut at one time and this orbinaut is a "pilot" or a co-pilot or a passenger of the vessel... the pilot's user decides who is in control of the vessel, among pilot and co-pilots, at any given time...

This is only for discussion of course but I think, one day, we could freeze some game-play requirements.

 

[Face]

For Community as well as for Content (of a distribution, not of a scenario yet), I think we should focus on the very spirit of Orbiter = "You can pilot in space, but don't insult your intelligence". OMP/OMPU cannot and shall not be in competition with Star Citizen or Elite Dangerous and the reason is that "piloting" is our game-play (let's make a pole?), not theirs.

Well, that's a rather bold statement to make if your initial proposal made pilots believe that there is a magic tank in their vessel supporting a 1G trajectory. I think we should go forward without discussing what a supposed spirit of Orbiter shall be or not.

The poll you referenced was made for the MMORPG idea of another user, not for OMP itself. Even for that project - that never went anywhere AFAIK - there were only around 50 people interested. The "massive" part is a bit underwhelming, I'd say. That's what my community point was about.

Regarding SC and ED: I don't see a competition, even if some aspects (economy, space flight) are similar. That said, SC and ED could really use some of it, seeing in what incredibly sorry state both games are currently: SC is eternal alpha, but cashes in money with "pledges", ED completely botched its latest DLC "Odyssey", effectively destroying their user-base with faulty planet tech. I mentioned ED in my post only to highlight that even in an arcade-like game, exploration game-play can take months in real-time.

I want to suggest something in this spirit: if piloting is our game-play, then the health of the crew is related to the physical laws and should be the main driver => let's model simplified effects of acceleration, weightlessness and duration of flights, which is much more intrinsic than the number of kg of propellant (imagine new engines...).

Yes, logistics like that are what I would count in under "content". If people not only travel to trade, but also have to trade to travel, it adds to the game-play and increases fun for the player. This is the reason why I think a step back from the open sandbox-nature of Orbiter is important to make a multiplayer experience interesting. If everybody can just spawn everything they want, with every MFD they want, or even use ScnEditor to skip-jump their ship, there will quickly be no real sense of progress.
However, I will certainly start small. Implementing one or two "commodities" at first - with one being the already established fuel resources - is challenging enough already. It will nevertheless demonstrate the concept.

Gamification is the key here, I'd say. There is a reason why most people rather say "I've been inspired by KSP" instead of saying "Orbiter brought me into the business".

 

[Face]

Ok, it makes sense. The concept is really cool, indeed. I think that 1G-Piloting makes no difference. Maybe the server's bubble would be a bit too quick... I can't wait to give it a try, anyway.

You can try it out already. The closed beta-testing is managed via a Discord channel, so if you have an account there, I can send you an invitation.

 

[jedidia]

OMP/OMPU cannot and shall not be in competition with Star Citizen or Elite Dangerous and the reason is that "piloting" is our game-play

I'd think the major reason is that it lacks a hundred million dollars or so in budget...

 

[Boxx]

if your initial proposal made pilots believe that there is a magic tank in their vessel supporting a 1G trajectory.

New engines & throttle:
No magic tank, but new engines, yes. My tests were performed with unlimited fuel for 2 reasons: 1) existing engines for DeltaGlider with Isp 4E4 seconds (see note 1) would indeed use the full fuel too quick, 2) there is not any G-driven throttle, which would make the acceleration increase over time, while the mass decreases.

Then, let's keep the existing fuel management (with limited fuel) and change the vessel class a little. I did the maths for DeltaGlider... but I'm not a rocket scientist so, please, somebody, double-check my numbers My dreamed new engines would look like that:

• Isp changed from 4E4 seconds (see note 1) to 2.46E5 seconds, that's "only" a x6 technological improvement of the propulsion (see note 2)
• then, the exhaust velocity is 2400km/s = 0.008 c (speed of light). OK, that's quiet a fictional technological break and we could call it a kind of nuclear fusion engine (suggestions welcome), I would even suggest to create engines up to Isp 1E6 seconds (0.033 c exhaust velocity)
• keep Engine thrusts like they are (main at 2x160kN, retro at 2x34kN, hover at 3x110kN).

Then a G-driven Throttle would deliver 1G in these conditions, with DeltaGlider's empty mass of 12E3 kg:

• at full tanks (13E3kg, total mass 25E3kg): 101g/s of propellant, 245kN = Throttle at 73%
• at 50% tanks (6.5E3kg, total mass 18.5E3kg): 75g/s of propellant, 181kN = Throttle at 57%
• at empty tanks (last drops, total mass 12E3kg): 49g/s of propellant, 118kN = Throttle at 37%

Reversely, if the Throttle is applied at 100% = 320kN, the engines produce an acceleration of 1.31G at full tanks (25E3kg total mass), 1.77G at half tanks (18.5E3kg), 2.72G at empty tanks (last drops, 12E3kg). These accelerations are valid whatever the propulsion...

With such engines, the DeltaGlider would be an excellent commute vessel with a maximum autonomy of 2 days at 1G (estimated with the 75g/s average, as it varies over time), i.e. you can go to the Moon in 4 hours, including some navigation mistakes (comfortable margin) and come back without refilling. But larger vessels would be required to travel at larger distances (with additional tanks, e.g. Shuttle-A), which makes a lot of sense to me.

(1) DeltaGlider's doc says 3E4 m/s for Isp but I guess this is a typo (Isp is in seconds and exhaust velocity should be much higher than that... to be checked)
(2) x12 to x19 if compared with nowadays propulsion (ranging from 13E3 s., with Rolls-Royce aircraft engines, to 21E3 s. with future VasimR space prop)

logistics like that are what I would count in under "content". [...] Implementing one or two "commodities" at first - with one being the already established fuel resources - is challenging enough already. It will nevertheless demonstrate the concept.

On-board Resources:
With engines and throttle controls like above in mind, and also with In-Site Resource Utilization (ISRU) in mind, I'd say that commodities air, water and food should and could be managed in a very simple way and in addition of the propellant in all vessels (you just triple the variables of fuel but the functions are even simpler)

• no more air => I've got a few minutes to send a distress call and get rescued (multiplayer game-play)
• no more water => a few hours to reach a station or a rocky planet / moon / asteroid that can be equipped to this aim (persistence)
• no more food => a few days to come back to Earth (or any - large - facility that produces or stores food, like a wheel-class orbital station, that already exists)

Then, trade to travel or travel to trade? Both. I would count air, water and food in the core functions of Orbiter (distribution, not scenario), exactly like propellant, in the name of realism. Maybe the properties for ISRU to be attached to various objects is more scenario-related (what objects can refill fuel, air, water, food). Already, Orbiter refills the tanks any time we land (or dock?).

You can try it out already. The closed beta-testing is managed via a Discord channel, so if you have an account there, I can send you an invitation.

Oh great, yes, please! It can take me a couple of days to test and understand but I'm definitely interested!!!!

Regarding SC and ED: I don't see a competition, even if some aspects (economy, space flight) are similar. That said, SC and ED could really use some of it, seeing in what incredibly sorry state both games are currently

[Orbiter] lacks a hundred million dollars or so in budget...

No, no, no, I don't think so, sorry jedidia, although 1% of this budget could greatly help Orbiter
From the user's point of view, free Orbiter vs. 59€ (or $US...) for a SC or ED pack would not explain the huge community and interest for Orbiter for 20+ years. There is a "something" that makes Orbiter different: add-ons / openness? "realism" for physics while piloting?. Hence, the "positioning" topic.