Fun vs. Simulation

18 views
Skip to first unread message

Jamieson Norrish

unread,
Oct 16, 1994, 8:25:21 AM10/16/94
to
In article <37nn9o$7...@nntp.interaccess.com> sharvey@interaccess (
S.P.Harvey) writes:

Is it possible for too many simulation elements to ruin the
enjoyment of a game?

Certainly it is possible, although I think it's a question that can
only be asked in the context of individual games. Things like sleeping
aren't too bad, I shouldn't think, because it shouldn't interrupt the
flow of the game too much. On the other hand, eating and drinking can
be a real curse. The problem, as I see it, can be solved in one of
several ways - removing the offending bit of simulation, increasing
the level of abstraction, or implementing complementary simulation
elements.

The first is obvious - just get rid of the requirement to eat or
drink. The second is one I haven't ever seen discussed here - increase
the level of abstraction to the point where it isn't burdensome to the
player. For eating, make it that under general circumstances, when the
character is hungry and types "eat food", the computer moves the clock
forward a bit, reduces the amount of food in the game/coins in the
character's pocket/whatever, and the character is no longer hungry. No
need for trips to the fridge then, while still maintaining the
simulation. In exceptional circumstances, when there isn't a readily
available source of food, then a more detailed model might be needed.

The third solution is to add in some elements which might make life
easier. For example, getting food generally isn't a problem for most
people in the modern world. Add in a place where there is a good
supply of food, allow people to go hungry, make sure time isn't
running too fast (and if it is for a reason, then it might be worth
removing eating and drinking totally, unless it's important at some
point), that sort of thing.

But really, it depends on what sort of game you want; not every game
is going to suit a high level of abstraction or lack of simulation,
just as many games would die if too much enforced simulation (those
things which the character has to do) was present.

Jamie

S.P.Harvey

unread,
Oct 15, 1994, 8:31:50 PM10/15/94
to
Jamieson Norrish (ja...@akeake.its.vuw.ac.nz) wrote:
: The second is one I haven't ever seen discussed here - increase

: the level of abstraction to the point where it isn't burdensome to the
: player. For eating, make it that under general circumstances, when the
: character is hungry and types "eat food", the computer moves the clock
: forward a bit, reduces the amount of food in the game/coins in the
: character's pocket/whatever, and the character is no longer hungry. No
: need for trips to the fridge then, while still maintaining the
: simulation. In exceptional circumstances, when there isn't a readily
: available source of food, then a more detailed model might be needed.

I had actually thought of something parallel to the line Jamie has been
working along. I had considered automating the eating/drinking functions
totally, provided sufficient food/drink is available. If the player is
carrying a canteen, the game library would periodically cause the player
to sip some water. Also, if the player passes a convienent source of
water (say a drinking fountain), he'll automatically stop and have a
drink.

Unfortunately, this isn't quite as practical when food comes into play.

Digression point: can we make a player thirsty without making him/her
hungry? Or is this a total violation? The reason I ask is that food in
IF is usually completely obvious: "oh, okay, a loaf of bread, I can eat
that", where water often has many variant uses.

Scott


--
----------------------| S.P. Harvey |--------------------------
"True! - nervous - very, very dreadfully nervous I had been and am;
but why _will_ you say that I am mad?" - Poe, 'The Tell-Tale Heart'
----------------------| sha...@interaccess.com |--------------------------

Mark B Sachs

unread,
Oct 15, 1994, 11:33:26 PM10/15/94
to
In article <JAMIE.94O...@akeake.its.vuw.ac.nz> ja...@akeake.its.vuw.ac.nz (Jamieson Norrish) writes:
>The third solution is to add in some elements which might make life
>easier. For example, getting food generally isn't a problem for most
>people in the modern world. Add in a place where there is a good
>supply of food, allow people to go hungry, make sure time isn't
>running too fast (and if it is for a reason, then it might be worth
>removing eating and drinking totally, unless it's important at some
>point), that sort of thing.

It might be a good idea to just look at how Planetfall did it. It
follows this model basically; you have a little food to start with,
and so it becomes urgent to solve a puzzle (finding the kitchen access
card) that allows you to enter the kitchen. From that point onward,
you have all the food you need.

I suppose the lesson one can draw from this is that you should only
make requirements to eat and sleep, _if that's important in some way
to the game_. In Planetfall, you're marooned on an alien planet and
so one of your challenges, were that a real situation, would be to
find enough food to survive; so the eating requirement serves a
dramatic purpose. In the desert game being discussed, drinking would
presumably be important (if you were really in the desert, it would
be very important indeed to you!) and so I don't see why it shouldn't
be in the game.

Sleeping is OK, as long as it's a very rare occurance. Sleeping every
hundred turns would be a royal pain; just as you're getting into a
puzzle, you have to leave and find a bed and... Sleeping every _several_
hundred turns a la Planetfall (and Stationfall) is better and, indeed,
helps to add distinctiveness to the succeeding parts of the game.

-Mark

S.P.Harvey

unread,
Oct 15, 1994, 12:54:16 AM10/15/94
to

Okay, how about this spin:

Is it possible for too many simulation elements to ruin the enjoyment of

a game? I'm not speaking of the funny but exaggerated depiction earlier
of "move left leg" "move right leg"... I mean things like forcing the
player to eat, drink, and sleep. While these are good "simulation"
effects, they're somewhat bothersome in terms of enjoying the game.
Especially if the food and drink are limited quantities in the game,
which is often the case.

I'm still undecided about the above effects. I've got sleep and drink
mechanisms already in place in my code (very easy to do), but are turned
off. My game takes place largely in the desert, so drinking is a crucial
element in a simulation. I can't quite decide if I'm going to hassle the
player with constantly finding water to drink, food to eat, and a safe
place to sleep every 100 turns.

I admit the unreality of spending day after day in the desert and never
taking a drink, but there's such a thing as artistic license. No matter
how often you drink in Enchanter, you never have to urinate.

Scott


--
----------------------| S.P. Harvey |--------------------------

"I do not know which to prefer, / The beauty of inflections /
Or the beauty of innuendoes / The blackbird whistling /
Or just after." - Wallace Stevens
----------------------| sha...@interaccess.com |--------------------------

Message has been deleted

Steven Grady

unread,
Oct 17, 1994, 2:03:14 PM10/17/94
to
It occurs to me that one way of resolving this would be to more accurately
model time passing. Rather than have the same amount of time pass with
each "move", actions might have a corresponding "time to complete"
attribute. One result of this would be that when interesting things
are happening (e.g. exploring a room, reading some letters, talking to
someone), a lot of "moves" might only take a few minutes, whereas if
the player is doing something like traveling a great distance, one
move might correspond to many hours. Only in the latter situation
would issues like food and sleep occurrences the player has to deal with
often, and in such cases they might legitimately be considered important
to the storyline.

This doesn't really address the original question of the importance
of simulating irrelevant elements for the sake of realism. But
there might be occasions where more detailed simulation aids
playability..

Steven

Reply all
Reply to author
Forward
0 new messages