"Magnetic Scrolls games were data-driven. Everything had a little
description which was a bit like the answers to a version of Twenty
Questions. Is it breakable? If you break it, are the bits sharp? Will it
float? Burn? Evaporate? Does it absorb water? Is it a container? How big a
container? And so on. The surprise was actually how few bits of data you
needed to model something which behaved really very like the real world."
(This was discussed in this RAIF thread from 2001:
"Talk of current IF development drifted on to whether it's possible to
create a game in which the player is not really constrained by the author's
intentions. Michael noted that Magnetic Scrolls games were kind of like
this-for example, if an object had the "sharp shards" bit set, dropping or
throwing the object would cause it to shatter into many sharp shards. In
total, 128 bits were used to describe a more or less working universe that
the player could interact with in ways that hadn't been anticipated. As an
example, Michael described an unintentional situation in which one could put
a rat in some liquid nitrogen, snap off its tail and, for a few turns, use
the tail to puncture feed sacks and obtain food."
My question is, does anyone have any more information about this? I would
love to see a list of the object properties used by Magnetic Scrolls.
David Fisher wrote:
> My question is, does anyone have any more information about this? I would
> love to see a list of the object properties used by Magnetic Scrolls.
> David Fisher
I've been doing some digging of my own and unfortunately haven't found
Just out of curiousity, what are you using as an emulator for MS games?
(A) That sounds awesome.
(B) God help me, but I immediately began wondering if Grignr's trick
with the rat (from Eye of Argon) would work. ("... the tediously honed
pelvis bone of the broken rodent.")
|| S. John Ross
|| Husband · Cook · Writer
|| In That Order
I don't actually own any; I just came across these quotes when I was
searching the RAIF archives / internet.
But if I did, I guess I would check out
> I have been researching the simulationy aspects of IF a bit lately, and I
> came across two quotes about the world model used by Magnetic Scrolls.
we can also read this, which is interesting :
> Type that into either and Infocom or Magnetic Scrolls game and, lo and
behold, you cut the rope and the ogre falls roaring into the abyss. Suppose
you don't have the rusty knife. You look around the room you're in. The
walls gleam with phosphorescent moss. In the dim greenish light, you can
see an old pottery vase. You use your common sense: " PICK UP THE OLD
POTTERY VASE. THROW IT AT THE WALL. GET ONE OF THE BROKEN PIECES AND CUT
THE ROPE WITH IT."
> Neither the Infocom implementer nor his counterpart at Magnetic Scrolls
had thought of that solution. While the Infocom answer would be simply to
tell you to go away, or to announce its absolute incomprehension, the
Magnetic Scrolls system would (if it had the right data at the start) say
to itself: "The pottery vase's FRANGIBLE bit is set, as is its
SHARP-WHEN-BROKEN bit so now we have a sharp thing, let's just check the
rope, yep, the rope has its CUTTABLE bit set so you cut the <CUTTABLE-THING
= "rope"> with a <SHARP-THING = "piece of broken vase"> and the ogre falls
roaring into the abyss.
I think it would be possible to add such features in Inform 7 with some good
rulebooks for example.
(one exemple : http://www.inform-fiction.org/I7Downloads/Extensions/Al
Golden/Liquid Handling )
I have't played many Magnetic Scrolls game, but I want to play more of them
All I could dig up was a reference to a text editor called variously
FRED, FRED 23, or FRED 23junior, which was used to enter in the object
properties. It's mentioned here (towards the bottom):
I agree that it would be interesting to see what properties the
implementors of those games used or felt were useful.
Coincidentally, this FRED program seems to be something along the
lines of Juhana Leinonen's new Thing Creator tool, posted here:
If you find out more, keep us posted (as it were).
PS: (OT) David, did you get my email dated 1/6 (subj :[I7 Custom
default messages]bug with entering container)? I wasn't expecting a
response, but seem to be having email trouble and was just wondering.
I agree --- except that depending upon how much simulation you want to
actually do, Inform 7 would quickly bog down. I've already found
Inform can be a performance hog when you do a lot of rules stuff. I
suppose you could just make one area of the simulation very responsive
but then the player would come to expect that and so you'd pretty much
have to use a similar level of simulation all through the game. For my
money, Magnetic Scrolls always had a better system than Infocom even
though I liked many of the Infocom stories better. But maybe a problem
is how you convey to the player that the simulation is so versatile.
Experienced players tend to be conditioned to look for the one thing
that will solve the puzzle or maybe the alternate thing that might
solve the puzzle. But they don't tend to take the whole world itself
and the parts in it as being totally responsive. New players may have
no clue what to expect, so how do you make that clear to them? Some
people might see a totally responsive world model as off-putting
becuase they feel they have to manipulate everything just to figure
out how things work, making the game more complicated. Then the focus
is totally on the mechanics and less on the story. (That's what I felt
with some Magnetic Scrolls games compared to Infocom's for example.)
It's an interesting discussion and it would be neat to see what can be
done but I'm betting Inform is too limited to allow this, at least in
full scope mode. I've been playing around with TADS 3, though, and
I've found that its various classes (including the ability to use mix-
ins) does allow me to do some pretty cool things with simulating how
people could solve puzzles involving smoke, fire, breakable objects,
multi-space locations, etc. So far what I've been doing is just
establishing sets of classes that can respond a certain way based on
properties they have. It's the combining of classes that I'm finding
lets my admittedly simple examples have some interesting effects.
> Some people might see a totally responsive world model as
> off-putting because they feel they have to manipulate everything
> just to figure out how things work, making the game more
> complicated. Then the focus is totally on the mechanics and
> less on the story. (That's what I felt with some Magnetic Scrolls
> games compared to Infocom's for example.)
That's a really interesting point ... I've posted a question on RGIF asking
whether others felt this way with Magnetic Scrolls games as well.
Here are the properties that I can deduce so far:
- container (+capacity)
- sharp shards (if broken, are the bits sharp?)
- floats in water
- can evaporate
- absorbs water
- temperature (which changes over time)
- needle-sharp (can puncture things)
- liquid-like (will pour out of a punctured container, for example)
> PS: (OT) David, did you get my email dated 1/6 (subj :[I7 Custom
> default messages] bug with entering container)? I wasn't expecting a
> response, but seem to be having email trouble and was just wondering.
Yes, the problem is fixed -- I sent a reply, which I've re-sent just now.
> I agree --- except that depending upon how much simulation you want to
> actually do, Inform 7 would quickly bog down. I've already found
> Inform can be a performance hog when you do a lot of rules stuff.
Definitely true :(
> people might see a totally responsive world model as off-putting
> becuase they feel they have to manipulate everything just to figure
> out how things work, making the game more complicated. Then the focus
> is totally on the mechanics and less on the story.
Some other people would delight in it, though (myself probably
included). It sounds almost _inherently_ non-stuffy, and that's a
notion that lights my eyes right up.
Emily Short has written a thoughtful article called "Emergent Puzzle
Solutions" in response to this thread:
> > universe that the player could interact with in ways that hadn't been
> > anticipated. As an example, Michael described an unintentional situation
> > in which one could put a rat in some liquid nitrogen, snap off its tail
> > and, for a few turns, use the tail to puncture feed sacks and obtain
> > food."
I'm sorry, but that is just really sick. I realize I'm not supposed
to be paying attention to that, but I couldn't help it.
> Emily Short has written a thoughtful article called "Emergent Puzzle
> Solutions" in response to this thread:
As soon as I stop laughing, I will click through...
Yeah, it's interesting: Emily and the writers-in are, I think,
exactly on the right track, both in terms of how such a game must be
designed (you'd want the combinatorial possibilities to explode fairly
quickly) and in terms of questioning how such a simulationist
framework could be made into a satisfying narrative.
It seems to me that the fundamental problem with making such a game is
simply in understanding the logic of the game you've made. It seems
in the essay and following discussion three issues are identified:
1. Can you reasonably do the things you imagine you ought to be able
to? Take the door off its hinges and burn it? Or, drag it to the
river, and use it as a raft? Will that put it out? etc. Emily talks
about that one.
2. Can you *not* do things that you ought not be able to do? Also
3. Is there a sufficiently broad range of things that we can
experiment meaningfully. -- A much more difficult problem, and dearer
to our hearts! It seems to me that, if you want to find a way to make
this kind of game, what you absolutely *need* to create as a basic
tool of game design is an "autoplay" feature, where the game itself
understands what goals a player might have and "drives" the pc through
many actions, blindly or with heuristics, like a chess program.
Observing the behavior and results of the autoplayer will give the
programmer/game designer a good level of insight into the logical
landscape he or she has created.
In terms of the other half of the problem, turning simulation into
narrative... well, that is a connundrum: but, given the popularity
of games like _the Sims_, it may be that by exploring text-based
simulation that problem will fall out, or look very different when we