I mean, it sounds like the workload can grow really quickly, if every room potentially supports time shifting. Don’t destroy yourself to meet forum opinion…!
But if the workload is manageable, then you know I’m absolutely in your target audience! Front row, even!
One thing I had was: What do you call directions in outer space? I’m thinking maybe ones that can be a one-letter word (N for North, for example) while being different to the already existing letters. My main reason for this is that I want to be able to go in a direction with 3 base directions in it (eg. UNE - Up, North, East; into a corner of a 3D cube).
Depending on the inertial frame you want to use as a reference, the likeliest trio would be towards and away from the center of mass (sunward at a system scale, coreward at the galactic level), with or against the relevant spin (planetary orbits for a system, spiral rotation for the galaxy), then good old up and down.
Of course these aren’t cubic axes, but unless the player is moving at incredibly large scales that won’t matter.
Edit: so C(oreward), R(imward), S(pinward), A(ntispin), and U and D - that’s three reuses of an existing direction abbreviation, but since U and D are meant to be opposite to each other, and orthogonal to S, I don’t think that should require any additional work.
I think @aschultz’s The Cube in the Cavern might have done this? Or maybe it just had all combinations of two directions out of six?
Edit: oops, that was already in the list.
Also, you don’t want to play Hard Puzzle 4 but IIRC it had a bit where you could rotate a section of the game along two axes to control which parts were in reach. Have other games done this?
It also seems plausible enough to repurpose earthbound directions: up and down are away from/toward the local gravity well, east and west are with/against the orbit, north and south are perpendicular to the plane of the orbit.
I vaguely recall astronomers actually using a convention similar to this—isn’t “galactic north” the direction perpendicular to the galactic plane (distinguished from galactic south by right hand rule)?
You could also simply do X, Y, and Z axes. While the positive of each is pretty obvious, I feel like the negative might get annoying; who wants to type -X, -Y, and -Z each time? Not sure what would be an intuitive single letter stand-in though.
This allows movement in 3D space with only a single reference point and no other sense of movement or reference. Spinward/Clockwise/up/down/etc all assume both an established direction of movement and a plane that movement typically occurs in addition to a central point of origin.
Might be useful in environments where no outside frame of reference can be determined by the PC, like submerged in dark water, or drifting in deep intergalactic space.
A, B, and C, obviously!
Cygnet Committee, by pbparjeter, has a map attractively laid out. I just remember it being unusually effective, but I don’t remember details
The map was partially modeled after the map for Babel, which has a kind of hub structure with small loops. There are also a fair number of one way doors that become two-way doors. Babel is one of the best IF maps and easy to remember for those reasons, I think.
In my game, the color scheme also helps as a memory aid (I hope).
Finally there’s also a sort of mind game: it’s set at an angle, where north is actually northeast. If you set a map at an angle, the player’s mental image will be better than the actual image, kind of like how isometric games feel natural with a keyboard if you play long enough.
As an aside, I was thinking about making the core mechanic of that game, the simple walking traversement of time, into an extension that someone could just plug in and go. It seems like the sort of thing that could be used by alot of people. It isn’t anything fancy someone couldn’t figure out themselves by just referring to the manual and cookbook, but it might save someone some time and aggravation.
With that said, I’ve never made an extension, so if there’s no interest, I can just move on too.
It just occurred to me that the Discworld novels use widdershins/hubward (basically clockwise and toward the center). Does anyone know if the graphical adventures retained that system? It looks like there is a MUD too but it doesn’t look like it uses it.
Yeah, though you don’t really use “galactic north” as an axis per se; it’s part of a spherical coordinate system of galactic longitude and latitude that pretty much corresponds to what I outlined, but is I think slightly less intuitive if you’re used to Cartesian coordinate systems.
(I was an astronomy major in college and this is the first time in a decade that’s come in even the slightest but useful, so I was excited for this question!)
(Shivers with excitement)
SPECIAL INTEREST ACTIVATED!!!
Lemme subject this entire forum to a possible realistic approach to orbital/space movement in an IF context!
For the sake of clarity, I’m using “radius” to (interchangeably) refer to either orbital altitude or the actual radius. It would be entirely up to you which one you’re measuring with. Altitude measures from sea level, while radius measures from the center of the gravity well’s body. Most calculations are done with radius, but an IF implementation would likely have a lot of fuzzy approximations and units of measurement anyways.
A “gravity well’s body” refers to something like the Earth, Moon, Sun, galactic core black hole, or whatever. It’s the mass that is primarily shaping your orbit, assuming a Kepler-style approximation (as opposed to an n-body calculation, which I’m 99.99% certain nobody wants to do in an IF title).
These first two directions might not be something you would perform explicitly, depending on the implementation. They would probably be used for describing relative positions instead:
Up for increase in orbital radius
Down for decrease in orbital radius
If we’re talking about a literal direction that the player could “move” in, then “going Up” would just require you to complete a full orbit, as you accelerate/decelerate at each side of the orbit, to both keep it circular and raise the entire thing to your desired radius. This is also known as a Hohmann Transfer.
These directions, however, would be explicitly used by the player when navigating space:
Prograde for forward acceleration along orbital path (Makes the opposite end of your orbit go Up)
Retrograde for backward acceleration along orbital path (Makes the opposite end of your orbit go Down)
Normal for angling the orbit towards the positive axial vector of your orbit
Anti-Normal (AN) for angling the orbit towards the negative axial vector of your orbit
Implementing Normal and Anti-Normal (which change your “inclination”) might be a liiiiiittle overkill. It’s usually engaging enough to assume all orbits share the same inclination, and just play around with orbital radii and angles through time.
You would use Prograde and Retrograde to change your orbit, but it would not really be what moves you forward or backward in the orbit. In reality, time passes, and you continue to move Prograde, whether you want to or not. By using Prograde or Retrograde as a direction, you’re just accelerating, relative to those directions. When a movement turn passes, your ship will have moved some amount in the Prograde direction.
It might be useful to implement these directions as well:
Foreward for looking forward in time
Backward for looking backward in time
These would be more similar to truly “moving” in the Prograde and Retrograde directions, but only as a way of previewing the world. By going Forward, you can see all the positions everything will be in, after the movement turns pass. You can then go Backward to return to the present.
If you are Forward n-number of turns, then there are a few ways you can handle the other directions:
n movement turns have passed.n turns later.I feel like option 1 would be easier to implement and play with, personally, but I have made a game that uses option 2, as well.
Now, we have the question of angle. Ships move along their orbits, which are circular, so relative positions are usually described with the differences in orbital radii, angles.
Normally, we use radians to describe the angles, but, for an approximation, you can also use “spinward” and “anti-spinward”. HOWEVER, these are not likely to be used as orbital directions that the player can use, and would instead be used to help describe where things are placed.
This is because you cannot arbitrarily change your angle in space; this is controlled entirely by the progression of time. So, since these would only be used for description and information-gathering, I’m not listing them as directions.
If an orbiting “target” (be it a ship, moon, etc) is 11 units spinward and 10 units up, while I’m 3 units spinward and 8 units up, then I probably need to go Up 2 units. This is because smaller orbits are always faster, and I will make up for the difference in spinward position by starting at my lower orbit. By the time my orbital radius matches the target’s, we will both have similar spinward positions and equal orbital radii, after only half an orbit. (This is because acceleration/deceleration only affects the opposite end of your orbit, so you will need to complete half of your orbit to see the results of your changes.)
If our spinward positions are still a little off, then all I need to do is accelerate Prograde or Retrograde, which will make my orbit slightly slower or faster, respectively. After a full orbit, I will have removed the spinward difference in angle entirely, and I should be within appropriate range of the target to be considered “in the same space”. At this point, I’ll reverse my pro/retro-grade acceleration to perfectly match the target’s orbital shape, and prevent our angles from falling out of alignment in the future.
This is called a phase orbit! 
Why would I need to wait a full orbit when making fine-tuned adjustments to my target angle offset? Because if my orbital radius near the target is correct, then my acceleration will change the opposite end of my orbit, making it slightly slower or faster, which will make me or my target “catch up”. At half an orbit in the future, my radius does not match the target (because it was changed), and I’m temporarily too far away from the target again. It will take another half-orbit to return to the target’s radius, with my remaining angle offset being removed. At that point, I undo my previous acceleration changes, so that my orbit perfectly matches the shape of the target’s orbit, but we are now at the exact same angle.
BUT WHAT IF I WANT TO USE UP, DOWN, SPINWARD, AND ANTI-SPINWARD AS DIRECTIONS?
Then I have (slightly) good news for you! You can!
(The following section is only useful if you’re only representing orbits as circles, and completely avoiding scenarios where they are ellipses. Any point where they might be elliptic would just be mentioned in passing between turns.)
Using Spinward and Anti-Spinward (AS) as explicit directions would be the same as scheduling full phase orbits to change your angle! When you “move” in either of these directions, you are just passing the duration of a full phase orbit (which could be anything from a few hours to a few days)!
Then, if you want to use Up and Down as explicit directions, you would just be scheduling Hohmann Transfer orbits. These only require a half-orbit to complete, however!
So, what does this mean?
Going US (Up-Spinward) would take 3 halves of an orbit (time may vary greatly). 1 half to change your radius, and 2 halves to change your angle!
Honestly, you would only need to know how much time passes to appropriately change the positions of other ships in the sky. Otherwise, you know you are at least catching up to your target, and getting within contact range, once the time elapses.
(Shivering dissipates)
Anyways, this was something I was working on for an IF project one time. It can definitely be done at varying levels of approximation, but it really depends on how you wanna approach it.
Also, I just want everyone to know that I plan to come back with actual numbers, algorithms, and formulas, which can be customized and implemented to do this in IF (assuming you’re going the circular-orbits-only route, with Up, Down, Spinward, and Anti-Spinward as your directions).
Just can’t do all the numbers right this moment, is all! But I shall return!
Oh my god I am definitely using this. I asked because I am planning to write (as my third game) an unfinished Infocom game - Timesync. It’s an ENORMOUS game with over 50 planets and loads of alien races. In essence, you go around space meeting alien races who watch earth '70s channels and try and find an antidote to a poison made by the Grebulons, the most totally evil race in the galaxy. @inventor200 , is it okay to use your ideas? 
I’m back, with numbers!!
Yes!! Absolutely!! In fact, I would be beyond thrilled and humbled, if anything I posted here was successfully used as a resource for someone else! Sharing is caring! I am super-duper interested in orbital mechanics, and it’s really fun to finally have a reason to write about this without “ruining the wedding reception by bringing a whiteboard for orbital diagrams and calculations”!
In fact, you replied at a very opportune time, as I present to you: How to calculate discreet orbital maneuvers in an interactive fiction context, the guide and sequel!
So, this guide is if you’re using only circular orbits, and using Up/Down/Spinward/Anti-Spinward as your directions. Any moments where orbits are elliptical are handled and resolved “between turns”.
Now, we’re gonna get kinda arbitrary with some numbers, but trust me that I derived these numbers from real-world approximates using formulas, and not just tables, which means everything should be pretty scalable.
First, we are going to define our orbits. As the orbit increases with radius length, we increase its “index number”, starting with an index of 1.
period_segments = index_number * 4
A “period segment” is just some division of an orbit’s period (how long it takes to go all the way around an orbit). We want to be increasing these in multiples of 4, because the math is a bit more friendly this way[1].
[1] Source: Trust me.
Now, in real-world values, the period of the orbit with an index of 1 could be anything, but it doesn’t really matter. For my number-crunching, I chose an around-Earth orbit with a radius of 75,000 kilometers, which gave me a period of 204,417.8248 seconds. Again, doesn’t matter; trust me. If you hunger for math like I do, see here.
So, this means that every standard segment is 51,104.45621 seconds long. Once again, just a fun fact for reference.
Honestly, once we break these down into in-game units, it all becomes based on dimensionless ratios anyway, so you can honestly apply this to literally any planet, as long as you don’t need to provide the real-world radius of your in-game orbit. (Again, if you do need to know the real-world radius of your orbit, then there is math for that, but this goes off the deep end a bit, so I’m not explaining that here.)
Orbital periods interact with each other more-or-less the same way, regardless of gravity.
Disclaimer 1: This system works up through an orbit with index 12. After that, there be dragons, but the segment count is also 48 at that point, which is already kinda big, and you also have 11 other orbits to fly around, so why ask for more?
Disclaimer 2: This system only works in one gravity well at a time. If you’re tracking orbits around Earth and around the Moon, then your units are not guaranteed to line up. You would need to do a lot of math to ensure that.
Again, trying to keep this simple, but still useful; that’s the goal!
Anyways…
MOVING UP AND DOWN:
Let’s say you’re at an orbit with index 5, which gives you 20 segments to fly around on. Think of these “segments” as “board game spaces”. Each turn requires you to move to the next segment, proceeding counter-clockwise around the board (I don’t make the rules on the counter-clockwise bit). Each segment you move, your “orbital position” goes up by 1. Once you return to your first segment, your orbital position resets back to 1, and you start over again. So these 20 segments (from orbit with index 5) gives us positions 1-through-20 to move around.
Remember: Every passing turn sees all ships move to the next segment in their respective orbits.
So, let’s say I want to go up to the orbit with index 7. I need to do a transfer Up 2 orbital indices.
So we plug our stuff into this handy-dandy Hohmann Approximation Formula that I made:
lowest_seg_count = lowest_orbit_index * 4.0
highest_seg_count = highest_orbit_index * 4.0
starting_orbit_seg_count = starting_orbit_index * 4.0
ending_orbit_seg_count = ending_orbit_index * 4.0
transfer_a = lowest_seg_count * 27.0
transfer_b = highest_seg_count * 20.0
transfer_avg = (transfer_a + transfer_b) / 94.0
transfer_segments = CEILING(transfer_avg)
starting_angle = starting_position * 360.0 / starting_orbit_seg_count
ending_angle = starting_angle + 180.0
ending_position = FLOOR(ending_angle * ending_orbit_seg_count / 360.0)
Okay, so now we move all other ships forward in their orbits, according to the value of transfer segments. This represents how much time we are passing during our Hohmann Transfer maneuver.
We now place our ship on the orbit with index 7, and set our position to the value of ending position.
Thus concludes our Up movement.
MOVING SPINWARD AND ANTI-SPINWARD:
We might be trying to intercept a particular ship that is also on the orbit with index 7.
Let’s say our position in the orbit is 19, and the other ship is at position 12.
offset = destination - source
-7 = 12 - 19
-7 = 12 - 19
So we are 7 positions ahead of the target. This means we need to do a phasing orbit.
orbit_seg_count = orbit_index * 4
mid_target_position = target_position
low_target_position = target_position - orbit_seg_count
high_target_position = target_position + orbit_seg_count
mid_offset = mid_target_position - my_position
low_offset = low_target_position - my_position
high_offset = high_target_position - my_position
best_offset = mid_offset
best_phase = ABSOLUTE(mid_offset)
low_phase = ABSOLUTE(low_offset)
high_phase = ABSOLUTE(high_offset)
if (low_phase < best_phase) {
best_offset = low_offset
best_phase = low_phase
}
if (high_phase < best_phase) {
best_offset = high_offset
best_phase = high_phase
}
phase_orbit_seg_count = orbit_seg_count - best_offset
So, we advance all ships along their orbits, according to the value we got for the “phase orbit segment count”, and then we add the “best offset” value to our position, to represent our movement in the phase orbit.
And that’s how we handle both movement and the passage of time while moving Spinward and Anti-Spinward!
In conclusion: Our examples showed us moving Up 2 indices, and 7 positions Anti-Spinward!
Hopefully this is clear! If there are any questions, I often lurk this forum, and will be happy to answer!
Disclaimer: If you need to represent ΔV (fuel costs) for every maneuver, that’s a whole other gigantic can of worms. For now, balance ΔV according to what feels right. Generally, these costs drop significantly as you get further from the body you’re orbiting. If anyone really wants me to write up how this could work, let me know.
I am very much not an astronomer (I took a couple electives in undergrad, though, so I do know how to take pretty pictures at least!) so a lot of my knowledge of this comes from science fiction instead of actual science.
But have you ever read Niven’s The Integral Trees? The setting is basically a torus of breathable air (from a gas giant getting torn apart by a neutron star), so people in the setting spend their entire lives in orbit.
The first rule they have for navigating in the Smoke Ring is “east takes you out; out takes you west; west takes you in; in takes you east; port and starboard bring you back”, which I think matches what you described (pushing in the direction of your orbit moves you away from the gravity well; pushing away from the gravity well puts you in a slower orbit compared to everything else). I’m not sure what the port and starboard part means though—maybe just that moving normal to the plane of orbit doesn’t have weird effects, so you can use them to get yourself back?
I was just thinking of that!
Going out of the orbital plane means that your orbit is now tilted, and intersects the plane. So you’ll drift back to the centerline. (You’d drift up and down through the plane over time, except that there’s air friction, so you wind up at a halt in the main orbit like eveything else.)
This thread got me to wondering if any IF game would have used a tesseract or a hypercube as its landscape.
Searching IFDB, all I could find is David Lo’s 1983 Beyond the Tesseract. (More background can be found at Wikipedia.)
I played for a little bit—it’s pretty interesting! At one point you find a book, and if you read it, you’re set “in” the book, a text adventure inside a text adventure. You also carry a stack, which you can push and pop:
>pop stack
You can't transcend reality in this adventure.
The Wikipedia page indicates the author was inspired by Godel, Escher, Bach, which takes me back and makes me want to reread it…
Joey’s code is approximating larger-scale orbital maneuvers like orbit phasing to move forward/back along your current orbit and Hohmann transfers to move up/down to different orbits, rather than small-scale “what does accelerating in different directions do?” So phasing forward or back takes roughly a full orbit, moving up or down takes what, about a half orbit? It’s a neat way to do it, but it’s also skipping large-ish chunks of time where you’re out in the middle of nowhere. Interesting to think how that simuation method ties into the storytelling…
I seem to have lost it now, but I made a (graphical) 2D thing once that let you accelerate/decelerate in the four directions relative to the orbit (in/out/spinwards/widdershins) and it was really fun to watch how accelerating spinwards/widdershins would expand and contract the ellipse and in/out would mostly rotate the ellipse. I had never quite made that connection before seeing it in action.