Game_Feature_Ideas/Locomotion
SDxWiki

DWM I don't think we had a single page to ruminate on this topic, but someone correct me if I'm wrong.

I've talked a lot with other members about various models of movement. As I've often stated, I think that Independence War got a lot of things rights in this regard, with respect to scaling modes of motion to realistic astrophysical distances, and playability. So I'll borrow some ideas from it. They use a three-tier model.

Each tier of motion has its own idiosyncracies. The details are probably important in determining the requirements on various game systems, so I'll put forth a relatively detailed model as a proposal here.

Newtonian Motion

This uses a Newtonian model of motion, or something very close to it, within the limits imposed by networking and computational consideration. (I assume that we will guess at these limits, and refine our understanding as development proceeds.) Because of limitations that we build into the other modes of motion, this mode is where all combat takes place. Mass, thrust, and inertia have realistic effects. Auto-pilot and flight-assist software, which will be standard equipment on player ships, will make motion in this mode tractable for even the newcomer. Such software can be overriden by more experienced players to take advantage of the unique possibilities of low-g maneuvering.

Ship capabilities will make it unfeasible to achieve any significant fraction of c (light speed), so relativistic effects can be ignored. (Hence 'Newtonian' Motion. This is one reason that artificial limits might have to be built into the game.)

'Bubble' zoning should allow for a smooth transition over large distances, although such travel would be slow. (Concept mentioned somewhere by Istvan; sounds similar to systems that I've been advocating verbally.)

JDH Please consider putting a link here to explain the concept more - thanks Istvan In brief, this method is one in which the client is only fed data on the immediate locality, range arbitrarily set at design-time. Client discards data on objects that leave the local bubble. Advantage #1 is no jarring "zone loads" in which the client is fed info on all local objects when a "zone border" is crossed. Advantage #2 is no "zone borders" which awareness cannot cross (EQ has this serious problem: stand by a zone border and run across it if endangered, AI enemy can't find you, stops pursuit). Basic disadvantage is relative lag in crowded areas (nearly all games suffer from this anyway). DAoC uses this method very effectively. I'm not familiar with the technical server -> client data transfer and handshake issues that result from this design decision, but I am aware that when playing DAoC, my connection is almost constantly active, which is an indicator relating to overall bandwidth needs (and expenses!).

Optional: Fuel limitations prevent traversal of (typical) interplanetary distances in any reasonable amount of time. However, there probably should not be any 'hard' limit on this.

Istvan Right, if some nut can stay online long enough, he should be able to do a Hohmann coast to his destination, even using very little fuel. DWM Good point, wasn't thinking of that. Istvan This issue is directly related to how the game handles player logout. What if a player could set up an orbit and logout until about when he expects to be near his destination? Game timescale (1:1 with realtime?) is also related. DWM Another good point. But even if a ship can coast with its player off-line, if we adjust ship capabilities appropriately, the best someone could do is strand themselves far away from everything. Just make sure every ship has an emergency beacon tuned to the Shadow Knights' Towing and Emergency Refueling Service. :) To what extent the coasting, unpiloted ship is simulated is a matter that could be debated. 1:1 timescale is the only way to go, IMO. If you speed up the passage of time, player interaction is slow compared to the world clock (since we can't speed the players up, without resorting to illegal drugs). That's the wrong direction to go -- if anything, if a player is considered a machine consciousness (see ideas on The Shape Of The Game), then they would interact faster. So best to leave the timescale alone.

Most in-system unmanned ships travel exclusively in Newtonian mode.

JDH What's the significance of this statement?

Istvan My thought would be that under that constraint the AI only has to deal with the Newtonian flight model, with no other considerations impinging on design of any flight-capable AI.'' Some large manned haulers do, too, because the equipment for very large ships to travel in Sublight Fast mode (next section) is prohibitively expensive. DWM My intention here is merely to add some color to the local fauna: slow haulers moving in-system cargo. Also to emphasize that S-space equipment is expensive, not used when not needed. Istvan But won't every player ship have S-space capability, to permit reasonable travel times? DWM Probably. But I'm assuming that not every ship is a player ship. Some NPC and automated in-system traffic might be strictly Newtonian.

Some items from the "Features" area that relate to flight model discussion:

Istvan Recourse to fictional entanglement-based comms is traditional in sci-fi. Recommend shorthand term "ansible" for the devices. I was going to use a gate-based or jump-point based travel system in a game design I had been thinking about that would avoid the velocity modelling issues. It's worth considering that travel times are a very big deal for players, especially casual ones.

Sublight Skipping

(IWar's LDS mode: Linear Displacement System.) To traverse in-system distance in times that are reasonable for game play, speeds are needed that cannot be reached in Newtonian Motion mode. Velocities that approach light speed seem to be about right for such travel. Need numbers to support this. I'm expecting times of, say an hour or so to traverse the full extent of a solar system.

Istvan Back-of-envelope: diameter 80 AU (2x Pluto orbital rad.) * 150 million km / AU = 12 x 10^9 km across. 1 hr = 3600 sec, 12 x 10^9 km / 3600 sec = 3.3 x 10^6 km/sec. c ~= 3 x 10^5 km/sec. Therefore a velocity of about 10c is required to traverse the diameter of our solar system in an hour. This does NOT represent an "average speed" of c or less, which is logically impossible within the scope of the time constraint. "Sublight Skipping" ain't sublight. DWM OK, maybe the time constraint should be chucked. Maybe ten hours to bisect Pluto's orbit isn't unreasonable -- after all, there ain't much out there, most of the interesting stuff will be closer in. Using Jupiter's orbit instead of Pluto's, you get roughly 1600x10^6 km diameter. At approximately lightspeed, this gives you about 1.5 hours. Mars' orbit, at about 450^10^6 km diameter, is about 25 minutes. Note also that this travel mode could be entirely dropped, I recommend it only for the fun factor of cruising around in-system. But a ship capable of sustained jump obviously wouldn't need this mode. Energy and financial costs of the various travel modes obviously need to be tweaked for playability depending on what our 'physics' ends up looking like. Istvan Well, we're staring directly in the face of the problem I tried to address in Ecliptic with the "paraspace" idea. If you ditch the sublight skipping, and use only sustained jump, then jump travel times to any location within the same system are always very small. That makes any star system subjectively tiny to the player-observer, because travel time creates the illusion of size. Within star systems, you'd have "flash crowd" effects, because everyone could rapidly "teleport" to any point of interest at any time it's interesting, which is likely to make combat incidents and other events problematic. The thing I tried to do with "paraspace" was inflate "short travel times" in the inner system, and reduce "long travel times" in the outer system, such that travel always involved a chunk of subjective time, but also that Jupiter-Pluto could be done in a similar, reasonable, amount of time as Earth-Mars. I would advocate keeping the "sublight skipping" - but I'd stop calling it "sublight", and add a mass-well or spatial-curvature technobabble factor to the travel rate such that "skip drive" is slower close to the sun, and faster further out. If two planets are in opposition (opposite sides of the sun), people might even find it advantageous in terms of travel time to travel outward from Planet A, choose a distant point about 50 AU out but 90 degrees around the system, then aim for a point outward from the destination planet, and then bore straight inward to the target, minimizing the depth of the gravity well at all points on the trip. "Spacetime Curvature" might even end up being a constantly-displayed readout on the Navigational interface, and while you are running your skip drive you'd see it change in real time. If it increases too much to suit, you might cut your drive, point outward from the star, and turn it back on, trying to minimize your overall travel time....

This mode works by allowing the ship to skip through real space. While out of real space, the ship is displaced relative to real space. An inertial distortion field surrounds the ship, 'squeezing' it out of normal space and into S-space. (S for mathematical Singularity, suggested name only.) The winking in-and-out is achieved by a oscillating the field characteristics; the field generator takes a considerable amount of energy, but by oscillating right around the necessary transition conditions, energy use is much lower than for superlight sustained jump mode. (See next section.) Displacement is determined by real velocity and field characteristics. (Not modelled in detail, just the net effect.) Ship control feels very much like Newtonian Motion. However, because of the huge speeds relative to the size of in-system objects, auto-pilot control is almost always used in this mode.

The time spent in real space is a small fraction of total time, so collisions are rare. The ship's automation monitors space density and gravitational fields at each rematerialization, and a reserve of energy is kept that is used to immediately, acyclically 'kick' the field to abort rematerialization when intersection with an object is imminent. This means that collisions cannot occur unless extended travel through a dense environment (within a planet, start, or asteroid field) exhausts the energy reserve.

It's worth mentioning that while skipping, a ship is in effect moving faster than light on each hop, but on average is moving at sublight speeds. A large additional energy increment is required to sustain a field that enables an average superlight velocity over any large time interval. That's discussed in the next section.

In-system ships designed to carry human passengers are almost always capable of this mode of travel, as are lifeboats on large, manned in-system haulers. For interstellar vessels, this mode of motion is merely a low-power application of their sustained jump drives (next section).

Istvan Um. Surprisingly to me, this travel mode is little different from a fictional travel method called "stutterwarp" described by GDW in the Traveller:2300 (later 2300AD) paper-and-pencil SFRPG dating from the 80's. The technobabble was slightly different: "stutterwarp" relied upon a very short-range quantum tunnelling effect (real physics). A field was generated that permitted the state-model of the entire contents of the field (the ship) to be expressed as a single aggregate wavicle (technobabble), at which time the engine was cycled, forcing a tunnelling event that would move the ship a fraction of a millimeter in a direction "forward" (no application of aligning the engine(s) in a way not parallel to the ships axis was ever discussed - I can think of several uses). The engine would of course be cycled at a tremendous per second rate, creating translight pseudovelocities. The game assumed a pseudoinertia, but I saw that as only necessary to make the ship-to-ship wargame rules more intuitive (turn rates). Other limitations were placed on travel using this system that we would probably have no need of. I believe GDW is years defunct, and I don't know who holds rights to their intellectual property, but this could be researched. DWM Interesting. I wouldn't worry about rights to such ideas; this one pops up in various guises in scifi, as does almost every concept we've bandied about. As long as we don't steal any proper names from Star Wars, we ought to be OK. :) Istvan Sure, but we'll want whatever term we use for it to be original, or get permission to use a particular someone's, unless we use a very generic term ("skip drive").

Sustained Jump

(Here I diverge considerably from IWar's model, inspired more by Hamilton's fiction, and by a desire to enhance exploratory gameplay.)

Sustained jump mode is achieved using the same field technology that Sublight Skipping does. Instead of oscillating rapidly, fields are built up to much higher energy levels and sustained for long time periods. There are several things about sustained jumps that make them risky and complicated.

First, displacement is exactly proportional to initial real-space velocity and to the duration of critical field strength. Both of these parameters are subject to small errors, the effects of which are magnified by jump distance. Truly long jumps (a hundred lightyears or more?) can leave a ship so far from its intended position that it can take up to an hour to get an accurate navigational fix. (Is this justifiable? What kind of error delta am I talking about here?) The accuracy problem can be addressed by systems which can lock onto S-space beacons. (More on this later.)

Jump accuracy is improved in the presence of gravitational fields at the destination. The effect is particularly noticeable in longer jumps.

Typical long-distance travel routes tend to consist of a series of medium-length jumps between beacons or massive astrophysical objects. Navigators must make tradeoffs between accuracy and total travel time.

Of course, in a time-critical, high-pressure situation (such as combat), one may not have the leisure of achieving a specific real-space velocity before jumping. Forced retreats from space battles often result in routed fleets being scattered over wide areas of space. Regrouping can take quite a bit of time. A really hot flight jockey might be able to jump very quickly in a pinch, if he has a good enough feel for the relationship between speed and jump distance, and he can recognize constellations in the sky around him.

Istvan Only a computer could do this - assuming accurate identification of bright stars from spectra. At issue is the "depth" of constellations in space and the variance of stellar distances and angular displacement as a ship travels from star to star. Taking an hour to capture spectra, match against known stars, and triangulate to determine position is not unreasonable if the local star's spectrum is not stored in the nav database. A human might be able to guess well and pick a broad direction for the next jump to get closer to home, but that's about it. DWM Exactly the kind of sloppy jump I had in mind. Details to be tweaked for playability.

Strong jump fields have differentials that can induce enormous stresses on physical objects. Consequently, interstellar ships have characteristically smooth exterior surfaces that closely match the field contours. All protrusions must be retracted into the hull a minute or so before jump. This usually implies that that a ship is sensor-blind prior to jump, and for a few seconds after jump. It also usually means that main drive systems have to be similarly shut down.

Jumping is not instantaneous. Longer jumps take more time. (This parameter, and the time it takes to locate position after an inaccurate jump, should be tweaked to make for interesting gameplay.)

S-space superfine displacement automation (SFDA) is available that can be used to adjust a jump to approach a designated S-space beacon. Knowing your precise starting location and homing on such a beacon can greatly increase the accuracy of a jump. S-space beacons are relatively expensive and very energy-hungry devices. Private beacons use encryption methods to hide their signals in S-space noise. An SFDA needs the public key of a beacon in order to home on it. Public beacons are not encrypted, and their locations are noted in cartographic databases. JDH Hey! I recognize that bit ;-0 DWM :)

Most beacons transmit location information of all ships within a certain distance of the beacon. This allows an SFDA to fine-tune the last nanoseconds of a jump to ensure comfortable reentry distances from other ships. Lacking this information, jumping into a crowded beacon zone is a game of Russian roullette, although the odds are still vastly in your favor.

Real-space inertia is preserved during a jump; you re-enter real-space moving as you were at jump initiation.

Moving fleets across long distances can be a real challenge. Typically, one or more scouts carrying S-beacons are sent into a system first, with the fleet following once the beacon lights up. To improve accuracy, fleets often regroup near a target, near a massive gravitational object. The final to-target jump is kept short to improve accuracy. Of course, smart defenders will place sensors at likely nearby regrouping points in order to detect such activity. Certain types of sensors can detect an incoming jump instantaneously from a considerable distance, making such monitoring feasible, albeit expensive.

Istvan: One disadvantage to a free-flight locomotion model (or set of models as described above) is inability to control access to "territory". While this is a very interesting and classic issue in space logistics, space war theory, and science fiction, it will also present very practical problems to game design. It may be very good to present players and organizations with these sorts of problems in the game environment, but it is another matter entirely to create those same problems for ourselves as designers.

The JumpGate model is simplistic, using static gates to control access to discrete volumes of space. That model has the advantage that travel regulation and territorial control can occur on the basis of control of gates (which concepts JumpGate does not actually incorporate). A less simplistic variant on the gate-travel model was used in a recent game called Terminus, which I considered inspirational for some of the ideas present in the Ecliptic whitepaper.

I propose an alternative system for in-game locomotion that combines a Newtonian model with a gate-travel model for potential access regulation. A Newtonian model's advantage of establishing "edges" to gameplay based on reasonable travel times rather than physical boundaries remains in force. Gameplay would cluster in space around gate objects. This model is extensible to large interstellar spaces without strain. I think it has design advantages that may be very favorable over the "free-flight/free-access" system described above, and I'm interested in discussing the potential of each approach. It may very well be that some of the problems I visualize with the free-flight travel method can be overcome - I have not had time to really consider all the issues, but will try to expound upon some of them here and in other design pages.

Incidentally, I've put on my personal "to-do" list to obtain a copy of IWar in order to look at the flight model directly.

DWM: Personally, I've always found the gate model too restrictive for my taste, but I understand that it might be easier to implement. I have some ideas (very old ones actually, going back almost to my college days) on how to make the free-travel model implementable, though. I'll post more on this soon, together with a more thorough look at 'bubble zoning'.

I tried to address the problem of controlling territory in my last paragraph. The idea is to control territory using automated monitors and/or defensive systems. For example, an automated sensor might expect any incoming vessel to identify itself and provide a secret key. For a property close to civilized space, failure to provide this key might simply cause a call to go out to the local authorities -- basically, a burglar alarm. In other areas, players might prefer a system that launches automated attacks instead. This will give people something to spend money on, and gives them a sense of building their own castle.

The sensor idea wouldn't work well, of course, if all space were equally good space to travel in. Hence the invented limitation that jumps are more accurate near strong gravitational fields. Exactly how inaccurate jumps are is something that can be tweaked. What I hope is that we can end up with something that has the flavor of both free roaming and gates -- except that rather than having gates, we'll have 'highly preferred' destination areas. Also, we have to assume that the sensors can detect incoming jumps over pretty large ranges, instantaneously -- easy to arrange in an invented physics system. :)

And of course, since space is very large, you might be quite successful just be being secretive about a remote stakeout -- incentive not to register a claim, but rather just exploit it. (Presumably, ownership registration is a matter of public record -- seems necessary for such a system to work, just like in the real world.)

Be sure to get IWar2, not IWar -- the latter only ran with Voodoo cards or software rendering, and is quite dated now. (Darn computers evolve too fast.) I just got my copy of IWar2 a few days ago, ordered from [Chips & Bits]. I don't plan on installing it until my new joystick arrives (the new Thrustmaster [Cougar], which won't be for at least three weeks.

Istvan: I can't imagine a security or defense system that can cover an entire star system. A notification system, sure. A defensive or interdiction system, I can't imagine it, space is too big. There'd be absolutely no way to keep an interloper from either recharging/refueling, or poaching resources, if you or your org/gov't claims any sizable volume of space.

DWM I disagree, provided you have adequate technological and financial resources. (If you don't, then you shouldn't try to control an entire solar system -- likely only governments could even contemplate this.) There's no reason that automated attack devices can't use any and all of the modes of locomotion described on this page. A sustained jump in-system should take very little time.

Note that territory control and access becomes much less problematic if there is any sort of limitation on travel, such as a limit on jump distance based on available power/fuel, with either an arbitrary absolute upper limit, or an upper limit based on economic constraints (e.g. the biggest available jump capacitor gets you fifteen light years). This makes astrogation potentially interesting, and certain stars can become strategic "choke points" rather easily.

(later...) Another thought, more on the extent of space in the environment: If access to interstellar travel is restricted in some way, then reasonable travel time automatically creates virtual edges that a player can never directly encounter (which disrupts the immersiveness of the game experience). If we don't restrict interstellar travel, then it can be assumed that a statistical sample of the player base will "strike for the edge" at once. Maybe the player's ship itself will never encounter an "edge" - but at some point their navigation system will, when the player can't select another star to jump to in a particular direction.

DWM Again, I have some ideas on addressing the problem of position tracking over huge distances. It involves Hierarchical Coordinates. Unfortunately, I seem to have thrown out my very old notes on this, so I'll have to recreate it. The biggest problem might be the size of the base database of stellar systems, where the system seeds are stored. Our own galaxy contains about 100,000 million stars. For the sake of argument, say that you want to model the whole galaxy -- so that inter-galactic distances provide the natural barrier that players can't ever traverse, by virtue of the game's pseudo-physics. If our base database only included stars above a certain size, how much smaller could we make it? How much of the 'feel' of the galaxy is lost be culling this way? Perhaps another possibility is to start the game far out on a galactic spiral arm. This limits the number of systems near you, assuming the gaps between arms cannot be traversed due to pseudo-physics limitations. Model details in the base database down the arm towards the center, far enough to satisfy explorers, and place an artificial limit somewhere. If the limit is far enough out, I doubt anyone would be dissapointed when they hit it. A base database of tens of thousands of systems should be feasible, I think. Very little information is needed for each system. And remember that the basic information is immutable, and thus could be replicated on each client.

Bimodal Insystem FTL

Istvan On the basis of discussion above, I propose high-speed locomotion based on two available modes: orbiting subspace gate facilities placed at various useful locations throughout the simulated solar system, and limited (very expensive or military-only at the environment's initial state) "jump drives" that allow a craft to enter subspace without a gate facility.

Under this model - FTL navigation will occur in subspace using the vessel's Newtonian flight engines. Distance travelled in subspace will "map" to normal space according to a relationship between spatial mapping and gravitational density: subspace is "stretched" in proximity to a mass, such that "distances" in subspace are longer close to a mass than they are far away from a mass. The governing mass for this relationship will be the Sun. The objective is to create travel times that are similar in scale for Earth-Mars journeys (avg distance ~1.2 AU) and for Saturn-Neptune journeys (avg distance ~24 AU or more).

Note - I definitely want to avoid paired gates, so that space isn't cluttered with several gates clustered together in an orbit (the Mars-Earth gate, the Mars-Jupiter gate, etc.). This means either that the destination gate must be preselected before entry (if subspace navigation is static ("set-and-go")), or that subpsace travel is interactive, and once in subspace a pilot may navigate his ship "on the other side" to the gate of his choosing. Either choice has interesting implications. The latter choice means we have to create an environment like "hyperspace" was depicted in Babylon 5, an alternate spacetime in which navigation appears to occur normally (and in which combat could occur!). The former choice would work more like the "Star Wars" hyperdrive - but means that players will not be "locked" to the computer during the jump (in which case I'd want a timer indicating how long before normal-space breakout, so you know how long you have to make that run for a beer or to use the head. Heck, for coolness, we ought to have a "breakout" alarm that chimes for the last fifteen seconds.), which is a gameplay issue. It looks to me like most everybody has been operating on an assumption of a travel method that is "set and go" for a while. Is this the case? It might simplify some issues (there goes my plan for a "hidden base deep in subspace", though :-) ).

One significant concern - I planned the FTL travel methodology for Ecliptic in such a way that you couldn't exit "subspace" without a gate (i.e no jump drives at all). This was to retain control over expansion, while simultaneously keeping interstellar travel times quite reasonable. The travel time to Alpha Centauri in subspace wouldn't be much longer than travel time to Neptune, depending upon the location of the gate(s) dropped into the aCen system. If we have "jump drives" that can enter and exit subspace at will, (A) the second any player gets hold of such a drive, we need to have all aspects of interstellar travel completely available, and (B) the question of why those powers that already have access to such drives aren't already exploiting the far stars needs to be answered in the storyline (maybe they are, but you get the point). Many games are capitalizing on retention of player interest through opening new regions of the game "world". It seemed to me that this "star system at a time approach" could be done quite painlessly, without requiring any interstellar-focused development prior to release, and the opening of new systems one at a time would have a "hype factor" that might be useful.

DWM Hmmm. Your point about controlling the opening of new systems, and the effect this has on player enjoyment, is a very good one.

Unfortunately, as you point out at the end, free jumping seems incompatible with this idea. Even if free jumping carried heavy penalties in accuracy, some players would manage to explore new systems, making those systems basically unavailable for any subsequent 'custom design' to make them particularly interesting for a controlled opening. If we go this route, then free jumping should probably be dropped entirely, or be utterly controlled by NPCs. (The latter is likely to cause high annoyance to some players, but if the technology needed is massive enough, it can be justified -- like a 1,000 km long slingshot or something.)

Perhaps focusing exploration activities within solar systems will work. As Frank pointed out elsewhere, we'd be doing a poor job if we can't make a solar system interesting. But if Newtonian travel is the only method available besides gates, then there will be a lot of space within a solar system that takes hours -- heck, days, weeks months! -- to get to.

I don't really share your antipathy to paired gates -- wouldn't it be interesting to have certain nexus points, with four or five gates in close proximity, where a lot of traffic meets? Within a solar system, you would have to get to know the web of paired gates to navigate effectively. When enough new star systems open up, a similar network would start to exist on a larger scale. (Hey, fractal gate routes.)Istvan Yah!

I still wonder how gates can be reconciled with 'space piracy', though. Gate owners would rarely let known criminals jump through, and gate-camping could effectively throttle a route entirely. If someone has some good ideas on addressing these issues, I could be convinced that gates are preferable to free jumping.

Istvan One general item is my continuing hope to have players potentially capable of generating any and all infrastructure - which as you point out also potentially conflicts with retention of control. However, this also allows even groups of piratical players to build their own unregulated gates. However, it certainly argues for any gate control to be very decentralized - in the hands of competing governments and corps - just so there is never a situation when a player is "locked out" of any gate system.

Thinking further on the incompatibility between "free jumping" and gates - if instead of a "navigable subspace", which is what I had been visualizing, we try to run with the "set and go" approach (in which you can go for beer when the ships is in transit), perhaps we can include some kind of energy limitation, or "calculation/processing" limitation, on the extremely long jumps (not long temporally, but real-spatially), which prevents interstellar jumps - much the same method as using "fuel limits" on Newtonian flight creating virtual travel borders based on travel time. This way we might get to keep the jump drive as an alternative to gates within the system, still retain the stretching coefficient idea for reasonable travel times, and are also still dependent on some grand construction project to get a new gate out to Alpha Centauri (read "post-release add-on") that players will drool over. Note especially that we can wait to add new systems until crowding becomes an actual factor in balancing the game in Sol system.