Let's Talk about Gravity

Authoring Inform 7
1

Hi everyone,

This topic may turn into a discussion on design, but I feel it’s primarily a question of best coding practices. Sorry if I got it wrong.

I’m creating a small game / proof of concept for a puzzle in another game, based on elements of the magic system in Brandon Sanderson’s “Stormlight Archive”. If you’re a fantasy fan, I highly recommend it! I’m not sure what the rules are about derivative works, so I want to make it clear that the ideas here aren’t mine, and that I’m not selling this in any way.

Readers of Stormlight will be familiar with the concepts of the three lashings, but for those unfamiliar, here is what I want to do. I tried to make the following section containing the explanation collapsible, but am not sure how.

The player will have the magical ability to impermanently alter the definition of their personal gravity (including their inventory) and/or any visible object they choose, called a “basic lashing”. This effectively changes the direction of down for whatever is being lashed in this way, e.g. Turning the ceiling into the floor.

As well as basic lashings, they will also be able to perform full lashings and reverse lashings. A full lashing causes an object to adhere to a chosen surface without being able to freely move (such as binding a door to its frame or sticking an object to the wall), while a reverse lashing causes the lashed object to draw other objects toward it; sort of like a basic lashing, but making the surface attractive to something rather than attracting something to the surface.

At the moment, my primary focus is the first type, changing the direction of “down” for the player and visible objects. I already have a reasonable idea of how to get the game to observe the players orientation in the body text of the room description. Either by writing different room descriptions for the various orientations and directions the player could be facing in (“A room has some text called the ceiling-down description”, etc), or by writing an activity to change the room description body text based on orientation.

Other aspects seem more complex to me. Inform has some pretty good ideas about what is physically acceptable, and I intend to quite literally turn those ideas upside down, so here is where the questions start.

When the player is (say) standing on the north wall, their concept of direction will be completely different to when they had their feet sensibly on the ground. Assuming a perfectly square room, and that the player is still facing the same way, the former south wall is now the ceiling (up), while the former ceiling is now the north wall. If the player were then to walk up this wall and lash themself to the ceiling, the whole compass would then be the other way around. They might also want to turn around to see the room, which could be tilted at a number of admittedly nauseating angles.

Is there a way to rotate the compass in three dimensions so that the game will understand where the player wants to go based on their new understanding of what is where? Or is re-mapping every direction and adjacent room on each orientation change my best bet. I also considered doing away with the standard compass entirely and inventing a new set of subjective directions, but this sort of ruins the puzzle in the thing.

My second question has to do with the existing surfaces that the player and/or their targeted objects might occupy, and adjusting the player’s scope appropriately.

If a player is standing on the ceiling and they drop something without lashing it first, it’ll fall to the floor (player’s up), because gravity isn’t a lie, it’s just being lied to. But if they accommodate that eventuality, where does the object go?

I’ve considered creating a kind of enterable scenery supporter for valid surfaces and placing them in each room, but this poses a problem. If the player lashes something to the ceiling when they are on the floor, they shouldn’t be able to reach it unless they too are on the ceiling. Likewise, if they drop something while they’re hanging out up there and it falls down, it shouldn’t be accessible until they’re near it. How might I go about making that possible?

I’m aware this is probably going to be a lot of work, especially dealing with the strange scenarios the player could find themself in, e.g. Should there be a check to prevent the player from falling through a doorway and cracking their silly skull on the opposite wall of the adjacent room? What if the player lashes an object high up on a wall? How should the game decide when the binding force on objects runs out?

But I’ve always had fun with the idea of playing with gravity, and would enjoy doing it in a game, so I’m prepared. Opinions and advice appreciated, and I hope someone else has fun with this idea too. I searched for similar topics, but couldn’t find anything with the queries I tried.

Hope everyone’s well!

2

Sounds pretty cool!

shudders at the amount of work involved

I could see you conceptualizing it so each room has an enterable scenery supporter called “the ceiling” “the east wall” etc, and then working with rules to allow whether the player can “enter” or put items onto the ceiling or the east wall and how everything interacts. Just use Inform’s rules to work out and determine whether the ceiling-supporter is “reachable” from the floor or another surface-supporter. And then a gravity rule that causes dropped items to go to the correct supporter when dropped. Default message say things like (on the east wall is a pair of boots) without mentioning that things are “right side up” so that should work…

Probably the first thing to study is reachability rules:
http://inform7.com/book/WI_12_18.html

It’s a lot to think about!

3

Oh gods yeah it is.

I’ll have a look at those rules. I knew there were rules for reaching inside, but was a bit stumped otherwise. Thanks!

4

One thing to consider - you might go absolutely crazy doing every possible wall surface. You could cut it down to just reverse gravity to represent this concept - or just reverse and sideways gravity - assume if a player is on “the wall” they can reach any wall. Simplifying is good.

It’s a common mistake in Inform when starting out to try and simulate everything in excruciating detail. Make sure all the work you are doing is in service to the story you are telling and the puzzles you want to create, rather than just simulating for simulation’s sake. You might want to limit this effect to certain areas so you don’t have to worry about the player ganking all your other game mechanics - kind of how in Portal you can only put portals on light gray walls? I’m sure that was a concession to not break puzzles and to keep the player from breaking the game for scope so they wouldn’t have to account for every situation.

6 Likes
5

I’m not good at Inform 7, so I’ll leave the actual code up to the experts… But for the concept, I like Hanon’s idea about walls and ceilings being supporters. That makes the most sense to me.

I think you can extend the generic room object to automatically add walls and a ceiling for that room upon room creation? I’m not sure though. Or maybe have a “gravity-less room” type. And assuming you go outside, some rooms may only have an east wall which would be the side of a building.

For grabbing objects, I think the scoping would be annoying not only to code but also for the user. Like if you put something on the east wall and you’re on the ceiling, it’d be annoying for the game to tell me “you can’t reach that” and I’d have to move to the east wall first. A decent tradeoff may be to automatically move your character to that wall to grab it. You can do a check before moving to see if that’s a valid place to move to. Like if the floor is electrified, don’t move there and then fail the “take” action.

As for directions, I think maybe you should leave them alone. East doesn’t move to the other side of the planet just because you’re upside down. You could always try using the “enter kitchen” method of navigation if it helps not break the immersion.

Anyway, good luck. That seems like a ton of work. :sweat_smile:

2 Likes
6

Thanks for the feedback, I had the same idea about going. I thought it would enhance the puzzle, but then I realised that realistically if you’re crawling up a wall, you’re hardly going to be concerned about checking your compass, and more on what’s around you and where you’re headed.

As for scope, I’ll need to think about that more. You make a good point, but I have yet to decide whether or not some of the puzzles will require you to plan where things need to be to make something work. Also, changing your orientation like that does expend finite resources, so doing it for the user could get annoying if they want to experiment or straight up forget something isn’t at hand.

All of that said, I appreciate the response! :slight_smile:

3 Likes
7

This seems like it would either get a lot more confusing or perhaps a lot simpler–because as tayruh said, north/south/east/west aren’t relative to the player’s orientation. If I have lashed myself so I am standing on the north wall, the north wall is still north of me–in the direction of the north pole. It’s just that it’s also down.

Now one thing you could do is switch purely to relative directions, left right back and forth as well as up and down, which would require the game to keep track of orientation. This might be fun if you want to make a game of disorienting the player. But it would be a ton of work, and you would probably want to have something where you do the map in absolute directions and have a system for translating them back and forth to relative directions. (One finger of the monkey’s paw curls down.) Uh, this is the sort of thing that as soon as I recommend it, I feel compelled to try to code it up. See you in a couple of weeks.

The thing that makes it simpler is, if you stick to absolute dimensions, especially if you just allow floor-to-ceiling switches like Hanon very wisely suggested, then you can just leave the compass directions the way they are. It’s trickier if you can stand on a wall because then there isn’t any way to refer to the former “up.”

(Also IMO the three lashings are butter, cream, and brown sugar.)

1 Like
8

I have definitely been corrected on my notion of compass directions, which I find interesting, rather than embarrassing. Slightly unrelated, but it seems my brain likes to think of compass directions as relative directions whenever I’m playing text IF. Could be the result of imagining non-physical spaces as a blind person, as I started out playing IF very young, before I understood how compass directions really work.

I’m cycling between wanting to try to code this system, and just going with Hanon’s or tayruh’s suggestions. So if you do ever give this a go, I’d be interested to see your method, even in an academic sense.

But what’s really important here is now I want oatmeal and I don’t think I have any. Thanks. :stuck_out_tongue:

9

I think the issue is that most people think of west as left and east as right and north as forward and south as back. And when it’s drawn on a map, that’s how it looks. But that’s only because we’re assuming the character is always facing north.

If we were to say things like “the kitchen is to the right”. The player could be like “But I just looked at the grandfather clock that was described as being on the wall next to the door that I just entered. Does that mean I’m now facing the other direction and the kitchen is to my left?”

That’s a whole can of worms that nobody wants to touch, so everyone just uses compass directions for simplicity even though nobody IRL ever says “the kitchen lies to the east”, because no one has a compass on them at all times. But this odd naming convention saves a lot of headache both for the developer and the player.

10

A possibly interesting thing: the campus of my university (the University of Vermont) is on a hill, so when you go east you’re almost always going up. So the old printed campus maps would have east at the top. Now when I look at the online map which is from Google and has north at the top, I find it very disorienting! (I’m very easily disoriented though.)

ETA: And the absolute cardinal direction thing reminds me of this thread about, among other things, languages where everyone always orients themselves by absolute directions.

2 Likes
11

OK, here is the sort of thing that you might wind up having to do if you want to take the relative directions approach. I didn’t do any inventory, or any modeling of the surfaces of the room, just facing in all six directions, shifting directions in all six directions, and using the relative directions for the player’s movement as well as in the room descriptions.

"Weapon of Choice" by Matt Weiner

Use American dialect and the serial comma.

Section 1 - New Directions

The left is a direction. The opposite of left is the right.
The right is a direction. The opposite of right is the left.
The forward is a direction. The opposite of forward is the back.

The back is a direction. The opposite of back is the forward.
The higher is a direction. The opposite of higher is the lower. The printed name of higher is "up".
The lower is a direction. The opposite of lower is the higher. The printed name of lower is "down".

A direction can be relative. Left, right, forward, back, higher, and lower are relative.
A direction can be vertical. Higher and lower are vertical.
Definition: a direction is horizontal if it is relative and it is not vertical.

[trying to avoid having the player refer to the original up and down]
The up is privately-named. The down is privately-named.

Understand "u/up" as higher. Understand "d/down" as lower.

Does the player mean doing something with up: it is very unlikely.
Does the player mean doing something with down: it is very unlikely.

Section 2 - Orientation and Calculating Directions

The player has a direction called orientation. The orientation of the player is north. [initially, chosen arbitrarily]
The player has a direction called gravity. The gravity of the player is down. [initially, *not* chosen arbitrarily]

A direction has a list of directions called the rightwards ring. [When your gravity is this direction, a direction on this list is rightwards of the one before it. Probably possible to automate this but oy. ]
The rightwards ring of down is {north, east, south, west}.
The rightwards ring of up is {north, west, south, east}.
The rightwards ring of south is {down, east, up, west}.
The rightwards ring of north is {down, west, up, east}. 
The rightwards ring of west is {down, south, up, north}.
The rightwards ring of east is {down, north, up, south}.

A direction has a number called the ring offset. [how many steps we have to go in the rightwards ring to get to the relative direction... so if you're facing north, and you want to go back, you find the direction that is 2 after north in the rightwards ring of the player's gravity. Which should always be south.]
The ring offset of forward is 0. 
The ring offset of right is 1.
The ring offset of back is 2.
The ring offset of left is 3.

To decide which direction is the direction (N - a number) after (way - a direction) in (directionlist - list of directions):
	let maxentries be the number of entries in directionlist;
	repeat with J running from 1 to maxentries:
		if entry J in directionlist is the way:
			let M be J plus N;
			if M > maxentries, now M is M - maxentries;
			decide on entry M of directionlist; [this ends the "to decide" phrase]
	say "error: [way] is not in [directionlist].";  [so we never fall through here unless we couldn't find the way]
	decide on north. [why not]
	
To decide which direction is the direction (turning - direction) of/from (facing - direction) based on (floor - direction):
	if turning is not relative:
		decide on turning;
	if turning is higher:
		decide on the opposite of floor;
	if turning is lower:
		decide on the floor;
	otherwise:
		let R be the ring offset of the turning;
		decide on the direction R after the facing in the rightwards ring of the floor.
		
To decide which direction is the apparent direction of (axis - direction):
	if the axis is relative:
		decide on the axis;
	otherwise if the axis is the gravity of the player:
		decide on lower;
	otherwise if the axis is the opposite of the gravity of the player:
		decide on higher;
	otherwise if the axis is the orientation of the player:
		decide on forward;
	otherwise if the axis is the direction 1 after the orientation of the player in the rightwards ring of the gravity of the player:
		decide on right;
	otherwise if the axis is the direction 2 after the orientation of the player in the rightwards ring of the gravity of the player:
		decide on back;
	otherwise if the axis is the direction 3 after the orientation of the player in the rightwards ring of the gravity of the player:
		decide on left;
	otherwise:
		say "Error in apparent directions! Possible noncardinal direction.";
		decide on forward.
		

Section 3 - Turning and Going

Spinning is an action applying to one visible thing. Understand "turn [direction]" as spinning.

Before spinning when the noun is not relative: say "[disorientation-text of the noun]." instead.

Check spinning when the noun is vertical:
	say "Turn [noun] for what?" instead. [this should be replaced with a more helpful message]
	
Carry out spinning:
	now the orientation of the player is the direction the noun from the orientation of the player based on the gravity of the player.
	
Report spinning:
	say "You face [noun].";
	try looking.

Understand nothing as going. [we want to keep the going action for its mechanics, but redirect all "go" commands to a pre-going action, which then calls a going action if all goes well with it.]

[Unfortunately the thing where a plain old direction is understood as going appears to be hard-coded into the parser, so I have to try an awful kludge to get around it.]
After reading a command when the player's command matches "[direction]":
	let T be "[the player's command]";
	change the text of the player's command to "go [T]".

Pre-going is an action applying to one visible thing.

Understand "go [direction]" as pre-going.

Before pre-going when the noun is not relative: say "[disorientation-text of the noun]." instead.

The new direction faced is a direction that varies. [since this has to be passed from the pre-going action to the going action, we make it a global.]

Carry out pre-going a direction (called the facing):
	let the way be the direction the facing of the orientation of the player based on the gravity of the player;
	if the facing is vertical:
		now the new direction faced is the orientation of the player;
	otherwise:
		now the new direction faced is the way;
	try going the way.
	
Carry out going:
	now the orientation of the player is the new direction faced.

To say disorientation-text of (way - a direction): say "You're disoriented enough that you're not sure which way is [way]".

Section 4 - Lashing

Lashing is an action applying to one visible thing. Understand "lash [direction]" as lashing.

Before lashing when the noun is not relative: say "[disorientation-text of the noun]." instead. [honestly, it would probably be a good idea to wrap all these up in a kind of action.]

Check lashing lower:
	say "The gravity is already down." instead.

Carry out lashing:
	let the new gravity be the direction the noun from the orientation of the player based on the gravity of the player; [the "new gravity" is a temporary variable]
	if the orientation of the player is not listed in the rightwards ring of the new gravity:[the player lashed forward or back, and they can't stay facing the direction they were]
		if the noun is forward: 
			now the orientation of the player is the opposite of the gravity of the player; [the old gravity; the player falls forward onto their face and gets up facing the opposite of the way their feet had been]
		otherwise if the noun is back:
			now the orientation of the player is the gravity of the player; [again, that's the old gravity; they fall onto their back and get up facing where their feet had been]
		otherwise: [we shouldn't reach this case]
			now the orientation of the player is entry 1 in the rightwards ring of the new gravity;
	now the gravity of the player is the new gravity.
	
Report lashing:
	if the noun is forward:
		say "You shift gravity forward, fall on your face, and struggle to your feet.";
	otherwise if the noun is back:
		say "You shift gravity back, crack your head painfully against what is now the floor, and stand back up.";
	otherwise: 
		say "You shift gravity and nimbly sidestep so you remain facing the way you had been.";
	try looking.


Section 5 - Scenario

Lobby is room. Elevator Bank is east of Lobby. Mezzanine is above Lobby. Hallway is east of Mezzanine. Hallway is above Elevator Bank. Restaurant is west of Lobby. Kitchen is south of Restaurant. 

After looking: 
	say "You're not supposed to know this, but you're facing [orientation of the player], and your gravity is [gravity of the player].";
	let apparent direction list be a list of directions;
	repeat with the way running through the list of available directions:
		add the apparent direction of the way to the apparent direction list;
	say "You might be able to go [apparent direction list]."
	
Definition: a direction (called the way) is available if the room-or-door the way from the location is not nothing.
3 Likes
12

This gives me a fantastic idea of how to start, and some strategies for gravity management, even if the direction system isn’t identical. I appreciate you.

I’ll have a good look over this once I’ve had some sleep. I may have some questions, most likely about the mechanics of the ring, but it also may make more sense when I’m less tired.

Thanks again, Matt. :grinning:

1 Like