Help with the impression of speed

I am new to programming with Inform. For my first project, I have decide to port a game I created for Ludum Dare that I think would work better as IF. See game here: lemmasoft.renai.us/forums/viewto … 11&t=11583

In the game, you switch between a cat, a raccoon, and a shark. The problem was that most people didn’t clue in that the cat moved faster than the raccoon who moved faster than the shark.

The layout of the lab is that there are four pods connected by hallways. I was thinking that I could vary the number of steps in the hallway depending on what animal you were.

Cat:
Pod -> Hallway -> Pod

Raccoon:
Pod -> Hallway -> Hallway -> Hallway -> Pod

Shark (out of water):
Pod -> Hallway -> Hallway -> Hallway -> Hallway -> Hallway -> Hallway -> Hallway -> Pod

Do you think this will work? What would be the best way to code it? One room with a variable that counts how far you’ve gotten? 7 rooms with short cuts for the faster animals? Different version of the whole lab for different animals? (That last one would be cool because then you could modify the descriptions based on the animal.)

Any insights would be helpful.

Susan

I rather like the last one, too. It’s not a huge area to model, so modeling it three times would probably be a nice bit of fun, really :slight_smile: And it could really highlight the advantages (not just speed, but perspective) of the different forms, by recasting the entire world model in their perspective, not just the associated strings/descriptions. Just remember to track the states of objects and such (if one animal breaks a beaker in his world, that same beaker should be broken in the others, too, etc).

Note: you can modify the descriptions based on the animal without doing the different models. It’s actually pretty easy to swap the text around.

Yeah, if the entire world is just those few rooms, I’d go for the last option. It will be the simplest to code.

[Edit: Ah I didn’t notice Ghalev saying basically this, but I’ll keep it here for the code sample:] Options other than the last one will still allow you to alter the room text based on the animal, by the way. It’s as simple as: The description of the Pod is "[if the player is the cat]It smells faintly of tuna [else if the player is the raccoon]You see lots of shiny dials [else if the player is the shark]You are too busy trying to breath to notice much detail[end if]."

I’m sure that those who know what they are doing will have better ideas, but here are a few thoughts:

One of the problems that you will have to face is how to deal with a situation where a particular version of the player character does not keep walking through the hall until it gets to the room at the end, but stops in the middle to do something else (or even turn around). Generally, Inform 7 is not really set up to handle different locations within a room. As a result, I think making the hallway a single room with a counter variable for the number of turns is going to pose some problems. For example, lets say the Shark starts out in Pod 1 and moves north for three turns, headed towards pod 2. Then, it turns around and heads S. As far as I7 is concerned, if you’ve implemented the Hall as a single room then the shark is still in the hall. Unless you have some mechanism based on decreasing the “counter,” going south from the hall would take it back to Pod one (even though it should be still in the hall, just one step closer to Pod 1 then it was before it turned around).

My sense is that it might be better to implement each hall as a series of rooms. However, for animals other than the slowest one, you couldn’t use I7’s automatic movement routines. For example, if the cat (or another fast animal) went north from pod 1, it shouldn’t wind up in Hallway 1 (the hallway room immediately north of Pod 1) but should instead jump ahead to wind up in Hallway 4 (or whatever). Thus, you’d need to use “instead” rules to move the player manually to the appropriate place any time it tried to move when in this part of the game. Also, as a player courtesy, I think you’d want a slightly different description for each “room” in the hall, so the player knows he’s making progress.

Robert Rothman

A problem with implementing three different room maps for the different animals pops up if the player can drop a carried item in the hall while “being” one animal. Where will that item show up if the player then switches to a different animal?

I’ve implemented this kind of thing, where there are really two different rooms that appear to the player to be the same room at different times. You have to move all of the portable stuff that might be in room A over to room B at a certain point in the game. That’s messy, but manageable.

But if you implement the slow-animal map as having numerous adjacent “hallway” rooms, and then the fast animal drops something in its only hallway room, where will the dropped object appear after the player switches to the slow animal?

I was thinking of naming them “Segment 01 of North Hallway”

I had been thinking of just just changing the going message to “You race/waddle/flop to the north” but it makes it easier for the timing of other events if I use the “turn” as a constant unit of time.

Currently, there are not items for them to carry. The original game was coded in a weekend so it isn’t very complex. :slight_smile: It was funny, the people who had played IF games before found the puzzle easy. The people who were used to visual novels found the puzzle hard.

If I do create items to carry, if they dropped in any segment but 04, it would be transported to segment 04 so the fast animal can pick it back up.

Susan

This is not that much of a hassle, actually, if you keep all the telescoping to a simple hallway room. Keep a counter, adjust it for “go north” and “go south” actions.

It’s more work if you want the telescoping to happen in a room with more than two exits.

You wind up with a certain amount of unrealism, in that you can drop something, move north twice, and pick it up again. But this is a small flaw, and players will overlook it if the effect is good (and you don’t try to condition a puzzle on the simulated details).

That works too.

Here’s a simple way to do it – not thoroughly tested, but it does work. I’ve used the traditional “carrying a banana” test rather than set up a character-switching mechanism:

[code]The Library is a room. “You can enter the hall, to the south.”

The Hall is south of the Library. “A longish north-south hall.” The hall has a number called position. The position of the hall is usually 1.

The Crypt is south of the Hall. “You can enter the hall, to the north.”

The player carries a banana.

Instead of going south in the hall:
if the player carries the banana:
if the position of the hall is 5:
continue the action;
otherwise:
increase the position of the hall by 1;
say “Wow, this is a long hall.”;
otherwise:
continue the action.

Instead of going north in the hall:
if the player carries the banana:
if the position of the hall is 1:
continue the action;
otherwise:
decrease the position of the hall by 1;
say “Wow, this is a long hall.”;
otherwise:
continue the action.[/code]

Jim Aikin: That’s awesome! You do run into trouble if they loop around in a circle.

Hmmmm, maybe set position upon entry into the hallway from the room.

Susan
/me scurries off to write some code

This is my solution based on Jim Aikin’s code. I also included Robert Rothman’s suggestion to let them know how far along the hallway they were.

[code]
A hall is a kind of room. A hall has a number called position. The position of the hall is usually 1.

The Library is a room. “You can enter the hall, to the south or to the east.”

The Great Hallway is a hall. It is south of the Library. “A longish north-south hall.”

The Crypt is south of the Great Hallway. “You can enter the hall to the north or to the east.”

The Creepy Hallway is a hall. It is east of the Crypt. “A longish east-west hall.”

The Kitchen is east of the Creepy Hallway. “You can enter the hall to the west or to the north.”

The Silly Hallway is a hall. It is north of the Kitchen. “A longish north-south hall.”

The Bedroom is north of the Silly Hallway. “You can enter the hall to the south or to the west.”

The Clean Hallway is a hall. It is west of the Bedroom and east of the Library.“A longish east-west hall.”

The player carries a banana.

Carry out going direction (called mydir) to a hall (called myhall):
if mydir is south or mydir is east:
now the position of myhall is 1;
otherwise:
now the position of myhall is 5.

Rule for printing the locale description of a hall when the player carries the banana:
say “You are [position of the location in words] sixth[s] of the way along the [location].”

Instead of going direction (called mydir) in a hall to a room when the player carries the banana:
if mydir is south or mydir is east:
if the position of the location is 5:
continue the action;
otherwise:
increase the position of the location by 1;
say “You are [position of the location in words] sixth[s] of the way along the [location].”;
otherwise:
if the position of the location is 1:
continue the action;
otherwise:
decrease the position of the location by 1;
say “You are [6 - position of the location in words] sixth[s] of the way along the [location].”;

[/code]

I went with the programmical solution since the object of this exercise was to get me used to programming in Inform 7.

I’m not sure of the coding styles used in Inform 7, so if there is an easier or clearer way to do this, let me know!

Susan

The coding style of Inform 7 is, roughly, “to each their own.” :slight_smile:

Roughly is right. Sometimes I have bruises the next day. And not always in the fun way :slight_smile:

@Susan: This:

Carry out going direction (called mydir) to a hall (called myhall): if mydir is south or mydir is east: now the position of myhall is 1; otherwise: now the position of myhall is 5.is functional but over-elaborate. It would be somewhat easier to read if you wrote this instead:

Carry out going a direction to a hall: If the noun is south or the noun is east: Now the position of the room gone to is 1; Otherwise: Now the position of the room gone to is 5. The variable “room gone to” is unique to the going action. In most cases, you’ll only see “the noun” and “the second noun” in action-based rules (e.g. when “removing X from Y”, X is the noun and Y is the second noun. There’s no “thing removed from”.); going is a rather complex action since it also has things like the “vehicle gone by”, and as a result, the second noun simply isn’t versatile enough (since you might e.g. go to a room by a vehicle, and want to make rules about both).

In general, if you find yourself writing “called” in the rule header for an action, there’s a good chance it’s redundant. If it’s the going action, you’ll need to find out the proper name for that variable (from the actions index or the documentation); for other actions, you can usually just stick to “noun” and “second noun”.

The exception is “when”. If your rule is of the form “Check [doing something] when [a condition holds]”, the use of “called” in the condition part is appropriate and useful.

Edit: Note however that many people think using “called” is clearer than talking about “the noun” and “the second noun”. Ultimately it’s up to you.

NYKevin:
Thanks for letting me know.

Reminds me of Perl and the $. At least “the noun” and “the second noun” are English. When I was first learning Perl, $ was a mystical symbol you put there because it made it work. :slight_smile:

Susan