DarkWanderer
Active member
Preceding legal questions: no, I'm not a good programmer (at least for now), and I'm not going to implement all that written here myself - just because I've got a sober view on my coding capabilities.
The purpose of this text is to create a guidestone for developers, who has the skills and knowledge nesessary to realize the described things, but suffer from an ideological starvation - as I know what it is for the coder to work without the requirements specification. And if anyone gots interested in the topic - I can prepare a full design document.
Ch.I.What to.
So... Let's go abstract of .NET, protocol stacks and other technical details, which often obstruct the view of coders, and realize what we want to get at all.
Let's first answer the main question: what one can expect from multiuser Orbiter?
In order of raising complexity:
1.Simple 2-4 men "LAN" cooperative flight. Vessels interacting with each other (at least docking). Formation atmospheric flight, Earth orbiting. Minimal variant, no comments needed.
2.Same with interplanetary possibility. Exploration scenarios (Vespucci flying to Pluto + 2-3 DG as landing modules) and so on.
3.Multi-user cockpits (+UMMU support). There's no need for it in stock DG, but, for example, flying an XR-2/5 together, or performing a EVA from shuttle with the active help of a pilot will be marked by pilots as at least great .
4.MMO. Many ships on the orbit, hard traffic in KSC. Thinking widely, there's no need to real syncronization of everything and everyone - it will be enough to implement it in a manner of VATSIM (http://en.wikipedia.org/wiki/VATSIM) - thus reducing the client load and unbinding it from specific orbiter version. Enough elegant solution, I think.
5.Real MMO with economics model and/or even warfare. Something like X3 with physics - and the only space sim where pilot skills will matter. A blue dream of any orbiter
, and a task-maximum.
I'm not pretending to invent anything new in genre (Orbit and plane align MFD will be anyway enough to be a new word), so we may stop on that.
Looking back to the proposed variants, we see, that every next (except p.4) in some sense includes the previous ones. For example, p.3 (coop piloting) will require good syncronisation of relative position of (for example) station and ship when docking. p.5 requires some elements and ideas of p.4 - we don't need to transfer all the 50-100-... ships on Earth to the client machine on Mars, and so on. So, we can just examine them one-by-one, not caring of interconnection, what, actually, we will do now.
Ch.II.How to.
The pros and cons of this "ladder" steps are apparent, so let's go through technical issues of each variant realization.
1.Small co-op. This theme was tried many times, coming closer and closer, but there's still no really working and finished project. OMP have come closest to the concept, but - the latest version is 0.2.9.6, and it is dated 2006-09-21. No Joy.
However, in OMP the majority of main problems in this stage were succerssfully addressed, so there's in fact nothing left to discuss.
2."LAN" interplanetary coop. There has been much discussions about possibility of such variant - and the most influencing problem in this case is time acceleration issue. We can conclude 3 ways to solve the problem:
- Hard-syncronized "full-space" time acceleration. The best way to realize it is server-dictated client-server architecture. The choice of concrete TA value either lies on host, or is deduced as minimum of every pilot's choice. Overall acceleration may be limited by least vessel distance to the nearest planet and closing speed. This is the most suitable variant for small sessions.
- "Space-times", proposed on forum. I my personal opinion, this conception seems senseless as people, who separated in a different space-time domain, get isolated from another part of player contingent effectively as they were joined separate server. I might not be getting the point, however, in any case this method fall out the discussion.
- Addition of any kind of futuristic "jump". Will not be quite liked by the most orbiters, but is definitely worth considering in the highlight of MMO possibility. As a factors of fun and complexity:
-- Jump may be committed only via fixed gates (and/or special vessels (->MMO))
-- Jump distance may be fixed (as in Lukyanenko's "The Stars Are Cold Toys" and Face's JumpDrive MFD) and large enough to make the navigation difficult
-- Jump distance may be directly proportional to speed relative in Sun's RS with preservation of impulse. This enables more precise system navigation - master orbiters may commit jump right on the VTOL pad from the orbit.
-- Number of jumps should be strictly limited. Reasons obvious.
This concept seems most suitable for >4-5 players, however, for small multiplayer it is redundant.
3.Multiuser cockpit (or multiple cockpits on one ship). This requires complete rewrite of vessel control code AND creation of addons supporting that feature. However, the result will worth the efforts. If someone gives that a try:
- If possible - users should be bound to UMMUs. That is - complete simulation. If you exit craft - you exit. If you get in - you sit on a free place or don't get in at all if there's no one.
- Control must be given to one user at a time with possibility to any to intercept it.
- Passworded cabin. Obvious reason (above).
More specific issues should arrive after first proof-of-concept (it's more proof-of-possibility here, considering MSFS) appearance.
4.Massive and online. Although word "massive" sounds optimistic, considering that there's only one ISS and one KSC, there soon will be great need in a traffic-controller. This gives us the next required features:
- A network of different high-quality space stations and spaceports to accomodate all the crafts.
- A simple collision model (based e.g. on ellipsoid)
- ATC stationary "vessel" with radar
- Mandatory option 1 of P.3. If not to UMMUS, then to ships at least.
The VATSIM client-server-client structure, however, saves a lot of work and troubles to worry about and seems optimal to be accomodated by current Orbiter community.
Fliyng this way will be much more challenging. However, how to make online flights motivated - that's another story and a topic of Ch.III.
*To be continued*
The purpose of this text is to create a guidestone for developers, who has the skills and knowledge nesessary to realize the described things, but suffer from an ideological starvation - as I know what it is for the coder to work without the requirements specification. And if anyone gots interested in the topic - I can prepare a full design document.
Ch.I.What to.
So... Let's go abstract of .NET, protocol stacks and other technical details, which often obstruct the view of coders, and realize what we want to get at all.
Let's first answer the main question: what one can expect from multiuser Orbiter?
In order of raising complexity:
1.Simple 2-4 men "LAN" cooperative flight. Vessels interacting with each other (at least docking). Formation atmospheric flight, Earth orbiting. Minimal variant, no comments needed.
2.Same with interplanetary possibility. Exploration scenarios (Vespucci flying to Pluto + 2-3 DG as landing modules) and so on.
3.Multi-user cockpits (+UMMU support). There's no need for it in stock DG, but, for example, flying an XR-2/5 together, or performing a EVA from shuttle with the active help of a pilot will be marked by pilots as at least great .
4.MMO. Many ships on the orbit, hard traffic in KSC. Thinking widely, there's no need to real syncronization of everything and everyone - it will be enough to implement it in a manner of VATSIM (http://en.wikipedia.org/wiki/VATSIM) - thus reducing the client load and unbinding it from specific orbiter version. Enough elegant solution, I think.
5.Real MMO with economics model and/or even warfare. Something like X3 with physics - and the only space sim where pilot skills will matter. A blue dream of any orbiter
, and a task-maximum.I'm not pretending to invent anything new in genre (Orbit and plane align MFD will be anyway enough to be a new word
), so we may stop on that.Looking back to the proposed variants, we see, that every next (except p.4) in some sense includes the previous ones. For example, p.3 (coop piloting) will require good syncronisation of relative position of (for example) station and ship when docking. p.5 requires some elements and ideas of p.4 - we don't need to transfer all the 50-100-... ships on Earth to the client machine on Mars, and so on. So, we can just examine them one-by-one, not caring of interconnection, what, actually, we will do now.
Ch.II.How to.
The pros and cons of this "ladder" steps are apparent, so let's go through technical issues of each variant realization.
1.Small co-op. This theme was tried many times, coming closer and closer, but there's still no really working and finished project. OMP have come closest to the concept, but - the latest version is 0.2.9.6, and it is dated 2006-09-21. No Joy.
However, in OMP the majority of main problems in this stage were succerssfully addressed, so there's in fact nothing left to discuss.
2."LAN" interplanetary coop. There has been much discussions about possibility of such variant - and the most influencing problem in this case is time acceleration issue. We can conclude 3 ways to solve the problem:
- Hard-syncronized "full-space" time acceleration. The best way to realize it is server-dictated client-server architecture. The choice of concrete TA value either lies on host, or is deduced as minimum of every pilot's choice. Overall acceleration may be limited by least vessel distance to the nearest planet and closing speed. This is the most suitable variant for small sessions.
- "Space-times", proposed on forum. I my personal opinion, this conception seems senseless as people, who separated in a different space-time domain, get isolated from another part of player contingent effectively as they were joined separate server. I might not be getting the point, however, in any case this method fall out the discussion.
- Addition of any kind of futuristic "jump". Will not be quite liked by the most orbiters, but is definitely worth considering in the highlight of MMO possibility. As a factors of fun and complexity:
-- Jump may be committed only via fixed gates (and/or special vessels (->MMO))
-- Jump distance may be fixed (as in Lukyanenko's "The Stars Are Cold Toys" and Face's JumpDrive MFD) and large enough to make the navigation difficult
-- Jump distance may be directly proportional to speed relative in Sun's RS with preservation of impulse. This enables more precise system navigation - master orbiters may commit jump right on the VTOL pad from the orbit.
-- Number of jumps should be strictly limited. Reasons obvious.
This concept seems most suitable for >4-5 players, however, for small multiplayer it is redundant.
3.Multiuser cockpit (or multiple cockpits on one ship). This requires complete rewrite of vessel control code AND creation of addons supporting that feature. However, the result will worth the efforts. If someone gives that a try:
- If possible - users should be bound to UMMUs. That is - complete simulation. If you exit craft - you exit. If you get in - you sit on a free place or don't get in at all if there's no one.
- Control must be given to one user at a time with possibility to any to intercept it.
- Passworded cabin. Obvious reason (above).
More specific issues should arrive after first proof-of-concept (it's more proof-of-possibility here, considering MSFS) appearance.
4.Massive and online. Although word "massive" sounds optimistic, considering that there's only one ISS and one KSC, there soon will be great need in a traffic-controller. This gives us the next required features:
- A network of different high-quality space stations and spaceports to accomodate all the crafts.
- A simple collision model (based e.g. on ellipsoid)
- ATC stationary "vessel" with radar
- Mandatory option 1 of P.3. If not to UMMUS, then to ships at least.
The VATSIM client-server-client structure, however, saves a lot of work and troubles to worry about and seems optimal to be accomodated by current Orbiter community.
Fliyng this way will be much more challenging. However, how to make online flights motivated - that's another story and a topic of Ch.III.
*To be continued*
Last edited:
