Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

List of things that causes automatic playing (Long)

9 views
Skip to first unread message

Jan Thorsby

unread,
Feb 22, 2005, 4:59:27 PM2/22/05
to
List of things that causes automatic playing

By automatic playing I mean when a player types in commands more or less
automatically without thinking much. None of the things listed is necessary
always bad, and there are probably instances when they don't really lead to
automatic playing.

1. Mazes

One is generally requires to type in lots of commands to explore them even
when one has figured out how to solve them.

2. Many rooms

Traveling between rooms doesn't take much thinking, and the more rooms the
more traveling.

3. Rooms that are far apart from each other.

The closer the various rooms are to each other the fewer commands the player
has to type to travel between the rooms. More connections between rooms
usually means less average distance between them.

4. Two related objects far apart

Likely to cause the player to travel back and forth a lot.

5. Unusual links between the rooms.

For instance if you go north to get from room A to room B, but you go east
to get from room B to room A. Likely to cause mild confusion and waste the
time of some players, even if you tell the player that he changes course
when he goes between the rooms.

6. Many needless objects

A player is likely to try to interact at least a little with most of the
objects in the game.

7. Time limits/eating puzzle

If a game has a time limit and the player is unable to keep it, the player
is likely to play the game again and just type in all the commands over
again minus the useless ones. A time limit that last through a large part of
the game is more likely to be annoying than a time limit for just for one
scene of the game. An eating puzzle is when the player dies if he does not
eat after a certain amount of turns. It is in effect a time limit.

8. Limited resources

Say a game has a resource that it possible to use up, for instance food,
matches or ammunition. If a player uses it up, he is likely to just play the
game over again and type much of the same command, just being more careful
with the resources.

9. Games that can be made unwinnable

If an action makes a game unwinnable, a player is likely to play the game
again and this time just refrain from doing that action. This is
particularly annoying if the action is early in the game, and the player don't
find out it made the game unwinnable until late in the game.

10. Randomness

If there is a scene with a random element in the game, for instance a random
fight or a random poker game, a player is likely to just keep playing that
scene until he gets the result he wants.

11. Limited carrying capacity

Some games have a limit on how mange objects a player can carry. This often
leads to the player going back and forth a lot to pick up things he had
previously left behind. In many games it also leads to the game potentially
being made unwinnable, because the player may not have a vital object when
needed.

12. Having to type more commands than should be required to show ones
intention

For instance say there is a closed door to the north. If the player types
"north" it is fairly clear that he intends to open the door and go north.
But the game may not let him go north until he has first typed "open door".
Machinery is often needlessly complicated to operate.

13. Having to do something complex more than once

The most common reason for this is probably when one needs to solve a puzzle
to get into a room, and then later every time one whishes to enter that room
one must solve the puzzle over again. This can be solved if there is another
exit into the room that can only be opened from inside the room.

14. Very easy puzzles

A very easy puzzle can be things like: unlock a locked door, buy something
in a store or give an object to a person who has asked for such an object.
These easy puzzles can be important to a story but are arguably useless from
a gaming point of view. If they are not important to the story one might
consider eliminating them.

15. The examine command and the search command

If the game has an examine command many player are likely to examine most of
the objects in the game. This means typing a lot of command without much
thinking. Use of the search command is probably less automatic, but arguable
don't require much thinking either since it is possibly to just go around
and search everything also. The same goes for "look inside", "look under"
and "look behind".

16. Menu-based conversation

When a game has menu-based conversation it is often possible to go through
the same conversation more than once and choose other options. Many players
are likely to just go through all the options.

17. The "ask about" command

In many games it is possible to "ask NPC about topic". This is not quite as
automatic as menu-based conversations tend to be. However the surest way to
be sure to get all the information is to make a list of everything mentioned
in the game that may be a topic, and then ask all the NPCs about that topic.
The number of automatic commands this creates is roughly: the number of
topics times the number of NPCs. Many games also have a "tell NPC about
topic" command, which will lead to even more automatic commands.

In many games "ask about" and "tell about" is synonymous, but the player is
not told this. In those cases the number of automatic commands can be
reduces if one remove one of the commands, or possible replaces both with a
"talk about" command.

18. Sections that must be replayed

A few games have sections that are supposed to be played several times.
Perhaps the player is supposed to learn by death, or perhaps the game is
about some kind of time loop. In these cases it might be a good idea to make
these sections as short as possible to reduce the number of commands the
player has to do over again.


sir...@hotmail.com

unread,
Feb 22, 2005, 5:48:36 PM2/22/05
to
These lists are a good idea and well done. I don't agree with 17,
though. :)

All the other items in your list deal with things that the game imposes
on the player, but the automatic playing with the 'ask/tell about'
command is something a player does either out of habit or insufficient
clues by the game, both of which I think are seperate issues.

You mention that "the surest way to get all information is to make a
list..." so maybe 17 would be valid if the goal of the game was to 'get
all information'. Maybe that too is just bad clues or a bad desgin
which forces information overload on the player.

Aside from that, well done.

-- Sir Pyke.

Michael Roy

unread,
Feb 22, 2005, 9:10:12 PM2/22/05
to
Jan Thorsby wrote:

> List of things that causes automatic playing

An interesting list--thanks for posting it.

> 2. Many rooms
>
> Traveling between rooms doesn't take much thinking, and the more rooms the
> more traveling.
>
> 3. Rooms that are far apart from each other.
>
> The closer the various rooms are to each other the fewer commands the player
> has to type to travel between the rooms. More connections between rooms
> usually means less average distance between them.

How are 2 and 3 different?

Also, more connections between rooms means more time on auto-pilot
mapping all of the exits to make sure they really do just link the same
rooms.

> 4. Two related objects far apart
>
> Likely to cause the player to travel back and forth a lot.

Not these days. Inventory max is usually set so high that it's hardly
noticed.

> 5. Unusual links between the rooms.
>
> For instance if you go north to get from room A to room B, but you go east
> to get from room B to room A. Likely to cause mild confusion and waste the
> time of some players, even if you tell the player that he changes course
> when he goes between the rooms.

Absolutely hate this one and I've never seen a situation in which it's
needed. Since compass directions are an artificial convenience anyway,
why not just make them convenient? But I'd put it on the "list of
annoying things" rather than the auto-play list.

> 6. Many needless objects
>
> A player is likely to try to interact at least a little with most of the
> objects in the game.

Isn't this the exact opposite of automatic playing? I can see what you
mean if the type of interaction consists of "EXAMINE FOO" (which is why
I like that Anchorhead automatically did an examine on anything you
picked up), but the whole purpose of IF is interaction, exploration, and
manipulation. Whether they're needed or not, if a game doesn't give me
a steady flow of items to interact with, I'm likely to just quit.

> 8. Limited resources
>
> Say a game has a resource that it possible to use up, for instance food,
> matches or ammunition. If a player uses it up, he is likely to just play the
> game over again and type much of the same command, just being more careful
> with the resources.

However, this can be an integral and satisfying part of the game. E.g.,
the one-use fix-it scroll in Enchanter and the magic well in Fyleet.
They lead to replay, but Enchanter at least gives you a warning and in
both cases they allow you to temporarily get around a puzzle that's
giving you trouble so that you can keep doing things even when you're
stuck. IMO, the time saved by being allowed to explore other parts of
the game by misusing the silver bullet outweights the time lost in
automatic replay.

> 9. Games that can be made unwinnable
>
> If an action makes a game unwinnable, a player is likely to play the game
> again and this time just refrain from doing that action. This is
> particularly annoying if the action is early in the game, and the player don't
> find out it made the game unwinnable until late in the game.

Yes, but this is basically a generalized version of #8.

> 11. Limited carrying capacity

This is the same thing as #4.

> 12. Having to type more commands than should be required to show ones
> intention
>
> For instance say there is a closed door to the north. If the player types
> "north" it is fairly clear that he intends to open the door and go north.
> But the game may not let him go north until he has first typed "open door".
> Machinery is often needlessly complicated to operate.

Agreed.

> 13. Having to do something complex more than once
>
> The most common reason for this is probably when one needs to solve a puzzle
> to get into a room, and then later every time one whishes to enter that room
> one must solve the puzzle over again. This can be solved if there is another
> exit into the room that can only be opened from inside the room.

Alternatively, the game can automatically re-solve the puzzle when you
type a direction in the future, a la library in Plundered Hearts.

> 15. The examine command and the search command
>
> If the game has an examine command many player are likely to examine most of
> the objects in the game. This means typing a lot of command without much
> thinking. Use of the search command is probably less automatic, but arguable
> don't require much thinking either since it is possibly to just go around
> and search everything also. The same goes for "look inside", "look under"
> and "look behind".

So what? Having to search, look under, etc. can be annoying, but
examine is convenient. Room descriptions can be long as it is; examine
allows players to take in things in more manageable chunks.

> 16. Menu-based conversation
>
> When a game has menu-based conversation it is often possible to go through
> the same conversation more than once and choose other options. Many players
> are likely to just go through all the options.

Arguably the player's fault and not the game's.

> 17. The "ask about" command
>
> In many games it is possible to "ask NPC about topic". This is not quite as
> automatic as menu-based conversations tend to be. However the surest way to
> be sure to get all the information is to make a list of everything mentioned
> in the game that may be a topic, and then ask all the NPCs about that topic.
> The number of automatic commands this creates is roughly: the number of
> topics times the number of NPCs. Many games also have a "tell NPC about
> topic" command, which will lead to even more automatic commands.

I don't think anyone actually tries this. Who's ever tried ASK NPC
ABOUT NORTH WALL? There are just too many combinations. For that
matter, if one knows that a game has x(k) verbs requring k arguments, y
nouns, and can be won in n turns, they could technically just feed in
all n*[sum{x(k)*(y^k)}] possible move lists until they win. Clearly, no
one will try this.

> In many games "ask about" and "tell about" is synonymous, but the player is
> not told this. In those cases the number of automatic commands can be
> reduces if one remove one of the commands, or possible replaces both with a
> "talk about" command.

Better yet, just don't make them synonymous. Because, after all, they
aren't.

> 18. Sections that must be replayed
>
> A few games have sections that are supposed to be played several times.
> Perhaps the player is supposed to learn by death, or perhaps the game is
> about some kind of time loop. In these cases it might be a good idea to make
> these sections as short as possible to reduce the number of commands the
> player has to do over again.

In the example-types you've given, the replay is the whole point of the
section/game. As such, the whole point of the replay is not to do
things the same way and making it too short could remove the whole point
of the section (but cf. Rematch for a good example of how to do this in
only one move).

Michael

PJ

unread,
Feb 23, 2005, 8:02:31 AM2/23/05
to
Jan Thorsby wrote:
> List of things that causes automatic playing
> By automatic playing I mean when a player types in commands more or
less
> automatically without thinking much. None of the things listed is
necessary
> always bad, and there are probably instances when they don't really
lead to
> automatic playing.
>
> 1. Mazes

Actually, the problem with mazes tends to be that you can't easily put
them on "autoplay." You have to memorize the way through in a much
more structured fashion that memorizing the generalized layout in a
largish game like Dreamhold. In a maze, one wrong turn and you're lost
again. Until you've been through them repeatedly and drawn a map,
mazes are too generally too difficult for "autoplay" to occur, that's
why players don't like them so much.

> 2. Many rooms


> 3. Rooms that are far apart from each other.

I agree with Michael Roy that these are really the same problem. I
would note also, however, that many players have posted on here and
r.g.i.f that they don't mind this at all. I have railed against "wide
map" and "sprawling" IF several times, but even some top authors have
said that the map should serve the author's purpose and that as long as
it does, the rapid "autoplay" required to retrace their steps is not
troublesome. I don't agree -- it bugs ME -- but many players love
sprawling maps with lots to explore, necessitating a certain amoutn of
"autoplay" as the game proceeds.

> 4. Two related objects far apart

This again is the same issue as 2 & 3. You wouldn't roam back and
forth even in wide map IF if the objects weren't widely separated. So
this is the prime condition within wide map IF that causes the roaming.

> 5. Unusual links between the rooms.

This I don't think is your autoplay problem. This is a "exception"
condition that frequently interrupts "autoplay" and irritates people
BECAUSE it interrupts autoplay (at least until you memorize the unusual
links, e.g., the mirror room or the slide in Zork).

> 6. Many needless objects

This is not your "autoplay" condition but is almost a basic condition
of playing IF. Unless you want to do a pure CYOA game, examining
objects and deducing their uses IS the game many times. While I agree
that some games are overly larded with objects, it is also true that
most players will get frustrated if (a) game descriptions are thin (2)
scenery objects in those descriptions AREN'T implemented and (3)
there's nothing to look at or do in most rooms. Interacting with
objects IS IF, not an example of autoplay.

> 7. Time limits/eating puzzle

I find it annoying to have to replay games just to get the number of
turns right, so I will go along with the larger point here. But some
games make brilliant uses of time limits in a way that is intrinsic to
the puzzle. (All Things Devours, for example.) It it not necessarily
annoying to have to be extremely efficient and manage time well; it's
only annoying if it doesn't really add anything to the key puzzles you
are trying to solve.

> 8. Limited resources

This is the same caveat as the previous one. Time is just another
resource, as your eating puzzle example makes clear.

> 9. Games that can be made unwinnable

Again, I have to agree with the point, but the design sin has nothing
to do with "autoplay." Game designers, in my opinion, should NOT allow
the player to get into unwinnable situations without causing a
death/end-game scenario. But other people have different ideas about
that.

> 10. Randomness

If the outcomes of the randomness are sufficiently different, then this
might not be "autoplay" but rather an enjoyable way to attain different
endings in the game.
>
> 11. Limited carrying capacity

See unwinnability answer above. Limited capacity shouldn't put the
game in an unwinnable state. But as for carrying capacity, the problem
is not the inventory itself but the sprawling maps many people use. If
you're going to have a severe inventory limit, you can't have a 70
room, 200 object, wide-open game and expect folks to love you for it.
In a small game, or a game constructed as a series of rooms where you
don't need what you left behind once you move to the next scene,
carrying capacity limitations can enhance the mimetic effect.

> 12. Having to type more commands than should be required to show ones

> intention

I agree that most doors should auto-open. But the truth is, most of
the time that people put doors in a game they first lock them. So,
what really should happen is that when you finally find the key, you
shouldn't have to type "unlock door. open door. north." Instead,
"Open door with key. North." But, in general, it's a matter of art
and skill how verbs get implemented, and what is obvious form to one
person is not always obvious to someone else, so this is a hard one to
pin down.

> 13. Having to do something complex more than once
>
> The most common reason for this is probably when one needs to solve a
puzzle
> to get into a room, and then later every time one whishes to enter
that room
> one must solve the puzzle over again. This can be solved if there is
another
> exit into the room that can only be opened from inside the room.

I agree on this. Most games leave the portal open once you've solved
the puzzle, however. I'm trying to think of one that doesn't, but
nothing complex comes to mind. Isle of the Cult is a good example of
where that situation might have occured, but the author creates a
clever "automatic" solution to your problem once you've done it once.

> 14. Very easy puzzles
>
> A very easy puzzle can be things like: unlock a locked door, buy
something
> in a store or give an object to a person who has asked for such an
object.
> These easy puzzles can be important to a story but are arguably
useless from
> a gaming point of view. If they are not important to the story one
might
> consider eliminating them.

Well, is this autoplay or just "warm ups"? The note you hit right on
the head, though, is "if they are not important to the story." In my
opinion, anything -- hard, easy, what have you -- should be eliminated
if it's not important to the story.

> 15. The examine command and the search command

I think you covered this in point 6 with the objects. Players do "x"
and "search" because that's how you interact initially with most
objects. But it's a condition of the game, really. Those commands are
your eyes, your main sensory inputs. Without them, how do you play the
game? (Though it would be interesting to have a whole game where the
PC is blind and must rely only on touch, hearing, and smell commands as
the main inputs.)

> 16. Menu-based conversation
>
> When a game has menu-based conversation it is often possible to go
through
> the same conversation more than once and choose other options. Many
players
> are likely to just go through all the options.

Well, the real negative here for me is that often those conversations
do little or nothing to advance the game. When I go through all the
options in a menu, I do so for two reasons (a) is there something here
which advances the game and (b) is the author's conversation funny
enough that I want to see all the responses? If neither is the case,
then the PC/NPC interaction should'nt really take place.

> 17. The "ask about" command
>
> In many games it is possible to "ask NPC about topic". This is not
quite as
> automatic as menu-based conversations tend to be. However the surest
way to
> be sure to get all the information is to make a list of everything
mentioned
> in the game that may be a topic, and then ask all the NPCs about that
topic.
> The number of automatic commands this creates is roughly: the number
of
> topics times the number of NPCs. Many games also have a "tell NPC
about
> topic" command, which will lead to even more automatic commands.
>
> In many games "ask about" and "tell about" is synonymous, but the
player is
> not told this. In those cases the number of automatic commands can be

> reduces if one remove one of the commands, or possible replaces both
with a
> "talk about" command.

Again, this is not necessarily a negative. I'm not sure its automatic,
either. Often, it is something of a puzzle to get the right answers
out of an NPC. As long as the author makes the NPC's replies
interesting and has some response that ultimately advances the game,
then there's nothing wrong with the ask/tell construct.

> 18. Sections that must be replayed
>
> A few games have sections that are supposed to be played several
times.
> Perhaps the player is supposed to learn by death, or perhaps the game
is
> about some kind of time loop. In these cases it might be a good idea
to make
> these sections as short as possible to reduce the number of commands
the
> player has to do over again.

Well, I suppose that's what save and restore are meant for. It
certainly wouldn't hurt to keep games in tight scenes with controlled
transitions, with little or no dependency between objects/items/events
in one scene and those in the next. I've advocated that the last few
months. It would then be cool if you could simply start in "scene 3"
or whatever, once you understand what you are trying to do. But most
games have a fairly linear buildup of points/objects that requires a
lengthy replay if you don't save and restore. If the author really
wants you to replay one section in a lengthy game, then he/she should
warn you about the need to save often or construct the game so that the
scene can be entered without all the usual buildup.

Another interesting list. Nice job.

PJ

Michael Roy

unread,
Feb 23, 2005, 11:20:19 PM2/23/05
to
PJ wrote:

> Jan Thorsby wrote:
>>13. Having to do something complex more than once
>>
>>The most common reason for this is probably when one needs to solve a
>
> puzzle
>
>>to get into a room, and then later every time one whishes to enter
>
> that room
>
>>one must solve the puzzle over again. This can be solved if there is
>
> another
>
>>exit into the room that can only be opened from inside the room.
>
>
> I agree on this. Most games leave the portal open once you've solved
> the puzzle, however. I'm trying to think of one that doesn't, but
> nothing complex comes to mind. Isle of the Cult is a good example of
> where that situation might have occured, but the author creates a
> clever "automatic" solution to your problem once you've done it once.

I can't think of a complex one either, but even simple resolutions can
be annoying. For example, the procedure for getting into the attic in
Theatre requires only two commands but I was still irked that I couldn't
just say UP after the first time I solved it. Same deal with the hansom
in Sherlock. If some moves are only worthwhile when done in a sequence,
the player should have the option of combining them all into one unless
there's a good reason not to do so (e.g., solving a puzzle for the first
time).

Michael

Jan Thorsby

unread,
Feb 24, 2005, 7:00:46 AM2/24/05
to

"Michael Roy" <inv...@invalid.invalid> skrev i melding
news:3826vmF...@individual.net...

>> 2. Many rooms
>>
>> Traveling between rooms doesn't take much thinking, and the more rooms
>> the more traveling.
>>
>> 3. Rooms that are far apart from each other.
>>
>> The closer the various rooms are to each other the fewer commands the
>> player has to type to travel between the rooms. More connections between
>> rooms usually means less average distance between them.
>
> How are 2 and 3 different?
>
> Also, more connections between rooms means more time on auto-pilot mapping
> all of the exits to make sure they really do just link the same rooms.

I explained 3 badly. How bout this:

3. The rooms are placed so that some of them are far apart

Say you have 10 rooms and they are placed on a line. Then from get to the
first room to the last room you have to "go" 9 times. But if the first room
and the last room were also connected you would never have to "go" more than
5 times to get from any room to any other room. More connections between
rooms usually means less average distance between them. But it also means
the player is likely to spend some time finding out where all the exits
leads, and this is also automatic playing.

>> 4. Two related objects far apart
>>
>> Likely to cause the player to travel back and forth a lot.
>
> Not these days. Inventory max is usually set so high that it's hardly
> noticed.

I ment two unmovable objects.

>> 5. Unusual links between the rooms.
>>
>> For instance if you go north to get from room A to room B, but you go
>> east to get from room B to room A. Likely to cause mild confusion and
>> waste the time of some players, even if you tell the player that he
>> changes course when he goes between the rooms.
>
> Absolutely hate this one and I've never seen a situation in which it's
> needed. Since compass directions are an artificial convenience anyway,
> why not just make them convenient? But I'd put it on the "list of
> annoying things" rather than the auto-play list.

I see your point, but it there is a lot of unusual links the map becomes
like a maze.

>> 17. The "ask about" command
>>
>> In many games it is possible to "ask NPC about topic". This is not quite
>> as automatic as menu-based conversations tend to be. However the surest
>> way to be sure to get all the information is to make a list of everything
>> mentioned in the game that may be a topic, and then ask all the NPCs
>> about that topic. The number of automatic commands this creates is
>> roughly: the number of topics times the number of NPCs. Many games also
>> have a "tell NPC about topic" command, which will lead to even more
>> automatic commands.
>
> I don't think anyone actually tries this. Who's ever tried ASK NPC ABOUT
> NORTH WALL? There are just too many combinations. For that matter, if
> one knows that a game has x(k) verbs requring k arguments, y nouns, and
> can be won in n turns, they could technically just feed in all
> n*[sum{x(k)*(y^k)}] possible move lists until they win. Clearly, no one
> will try this.

I didn't mean one tries to ask about everything in the game. I meant things
like the names of the NPCs, place names, objects that NPCs have mentioned as
being important, etc.


Michael Roy

unread,
Feb 24, 2005, 11:47:07 PM2/24/05
to
Jan Thorsby wrote:

> I explained 3 badly. How bout this:
>
> 3. The rooms are placed so that some of them are far apart
>
> Say you have 10 rooms and they are placed on a line. Then from get to the
> first room to the last room you have to "go" 9 times. But if the first room
> and the last room were also connected you would never have to "go" more than
> 5 times to get from any room to any other room. More connections between
> rooms usually means less average distance between them. But it also means
> the player is likely to spend some time finding out where all the exits
> leads, and this is also automatic playing.

Ah. Think I understand now. However, is this something that an author
can consciously control? Having ten rooms in a line link back to each
other would work in a circular geography like a spaceship or the polar
ice caps, but in many situations links like this just don't exist.
Perhaps one might be able to add a "cut across the grass" room.

>>>4. Two related objects far apart
>>>
>>>Likely to cause the player to travel back and forth a lot.
>>
>>Not these days. Inventory max is usually set so high that it's hardly
>>noticed.
>
> I ment two unmovable objects.

Are there many cases where the player has to manipulate two distant
immovable objects? I can't think of any examples offhand.

>>>17. The "ask about" command
>>>
>>>In many games it is possible to "ask NPC about topic". This is not quite
>>>as automatic as menu-based conversations tend to be. However the surest
>>>way to be sure to get all the information is to make a list of everything
>>>mentioned in the game that may be a topic, and then ask all the NPCs
>>>about that topic. The number of automatic commands this creates is
>>>roughly: the number of topics times the number of NPCs. Many games also
>>>have a "tell NPC about topic" command, which will lead to even more
>>>automatic commands.
>>
>>I don't think anyone actually tries this. Who's ever tried ASK NPC ABOUT
>>NORTH WALL? There are just too many combinations. For that matter, if
>>one knows that a game has x(k) verbs requring k arguments, y nouns, and
>>can be won in n turns, they could technically just feed in all
>>n*[sum{x(k)*(y^k)}] possible move lists until they win. Clearly, no one
>>will try this.

> [ Correction: [sum{x(k)*(y^k)}]^n ]


>
> I didn't mean one tries to ask about everything in the game. I meant things
> like the names of the NPCs, place names, objects that NPCs have mentioned as
> being important, etc.

Now that I think about it, this isn't so far off from a police
interrogation. Naturally, most NPC dialogue shouldn't be like an
interrogation (which it all to often seems to be), but this method does
have at least some merit.

Michael

David Adrien Tanguay

unread,
Feb 25, 2005, 12:09:33 AM2/25/05
to
Jan Thorsby wrote:
>>>2. Many rooms
[...]

>>>3. Rooms that are far apart from each other.
[...]

> I explained 3 badly. How bout this:
>
> 3. The rooms are placed so that some of them are far apart
[...]
>>>4. Two related [unmovable] objects far apart

But these are completely natural and desirable for a game that presents a
long trek, or simply a large game. The problem isn't really the number of
rooms or the distance between them, but the imposition of stopping in
many rooms without doing anything interesting in them (where exploration
counts as interesting), just moving on to the next room. Even a small map
could be annoying if you have to frequently navigate from one end to another
to get things done.

Also, a good "goto" facility (discussed elsethread) can make the traversals
painles. "far" has to be interpretted as a number of player commands, not
just as a geographic measure.

The designer's goal should be to minimise the number of "boring" room
visitations.
--
David Tanguay http://www.sentex.ca/~datanguayh/
Kitchener, Ontario, Canada [43.24N 80.29W]

0 new messages