What do non programmer types want in an IF language ?
David Fisher
> It is natural that programming languages are designed and
> implemented mostly by programmer types. However, I don't
> think it is impossible to design a language that is better
> suited for the non-programmer type of person, it's just
> very hard for the programmer to see what the non-programmer
> needs in such a language.
Lelah Conrad - Jun 15 1998
> Here in the IF universe, many of us are writer-types, not
> necessarily programmer types. We are hobbyists who have found
> a new way to write, and who are intrigued by it. There is a
> thread that keeps coming up over and over again .....
> where someone says, hey, I'd like to write this stuff, but
> can't you make it easier?
OK you non programmer types ... what would you like to see in an IF language
(or not see) ?
David Fisher
(Being a programmer type with many preconceived ideas)
wgm...@bellsouth.net
that probably applies here. Back some 45 years ago (when I first
started programming) there were no languages, only ones and zeroes put
in with switches and buttons. Eventually, we got to the point of
having GWBASIC. It was a nice simple language and, as the name
implies, very basic. Things like DO .. END DO. Now, we have Visual
Basic .NET. The level of complexity here is not so much due to the
perverse nature of language designers as it is to the needs of
programmers.
I guess the answer is that while a simple DO loop is fine, the demands
of today's users drive the need for ever more complex languages.
Don't blame Microsoft or even Bill Gates for this one, it's just
the way life works!
Greg
PS: I'm just starting with IF and some of the language constructs
are driving me barking mad!
Ian Haberkorn
> OK you non programmer types ... what would you like to see in an IF
language
> (or not see) ?
I have some Inform experience. Contrary to some other posts I feel that
most of its features are necessary to describe a complex world. What
troubled me a lot initially was the grammar. So I want:
A Graphical User Interface! Here comes the wishlist regardless of
feasibility:
An area on the screen where I can put rooms that are boxes with some
basic information (name, contained objects...).
I can connect rooms with lines, right-click on the line for its type
(one-way a to b, b to a or twoway) or conditions (key in inventory,
troll dead or whatever) and comments when passing ("You step over the
dead troll, careful not to stain your shoes.").
An area for absent objects and for inventory. If I want them somewhere
else I just drag & drop them.
A scaleable part of the screen that displays more containment
information, properties (textboxes) and attributes (checklist) of the
object in focus.
Containment has more possibilities, like behind, under...
Double-clicking an object or room gives me a zoom-view, so I can do
some graphical furnishing (put desk in room, put drawer in desk).
Alternative: A tree view of all objects that I can rearrange by drag
and drop.
Hovering over an attribute explains its meaning.
A "meta" area or window for classes, variables...
When I select an object, other objects it interacts with are
highlighted.
When I search for an attribute or a class, all objects carrying that
attribute - or of the corresponding class are highlighted.
Being able to switch to the Inform sourcecode of the game.
An interpreter for debugging. When I type "break" (or whatever) I am
taken to the editor and the current location/attributes of objects and
variables are displayed. I can trace back and forward to see what
happened in response to what.
Online grammar check when I leave the focus of an object or a text box.
A copy-paste function for objects.
An import functionality for objects from other sources.
A "check spelling" mode listing all statements that can be printed in
the course of the game.
Some more classes, like "vehicle".
---
That's all I can think of for now. I believe, someone writing sth like
this would become an instant IF legend!
Ian
Adam Thornton
wgm...@bellsouth.net <wgm...@bellsouth.net> wrote:
>I think there is an unfortunate maxim with anything computer related
>that probably applies here. Back some 45 years ago (when I first
>started programming) there were no languages, only ones and zeroes put
>in with switches and buttons.
Pish and tosh! In 1960, FORTRAN, LISP, COBOL, and ALGOL were all
already extant.
OK, perhaps not on *your* computer, but still.
Adam
Andy M
"Ian Haberkorn" <haber...@yahoo.com> wrote in message
news:1116001560.9...@g44g2000cwa.googlegroups.com...
> David Fisher schrieb:
>> OK you non programmer types ... what would you like to see in an IF
> language
>> (or not see) ?
>
> I have some Inform experience. Contrary to some other posts I feel that
> most of its features are necessary to describe a complex world. What
> troubled me a lot initially was the grammar. So I want:
>
> A Graphical User Interface! Here comes the wishlist regardless of
> feasibility:
>
This would be indeed be super-sweet. There are already a handful of tools
that implement a graph using drag-able boxes and lines, they're typically
used to represent flowcharts or an OOP hierarchy. Maybe someone could find
such a program that is open-source and modify it accordingly? Even a basic
implementation of what Ian is talking about, without some of the more
complicated bells and whistles, could be a huge time-saver.
Andy
JohnnyMrNinja
David Fisher wrote:
> OK you non programmer types ... what would you like to see in an IF
language
> (or not see) ?
I hate to be taboo and actually answer the question, but I've been
looking into ALAN a little and I quite like the look of it. While you
can look at an Inform source and get an idea what's happening, looking
at an ALAN source with no prior knowledge you can understand *every*
part, with no confusing symbols. Not that you can immedeatly write it,
but "Isa" is more clear than "==" but not "=" or whatever.
What I like about Inform is that you can do a lot of things, and do
them well. Also that I can play the compiled games with the same
program I play The Lurking Horror (and that Z-terps exsist on anything
with electrical current). The biggest plus of starting with Inform (and
probably TADS) is the pre-existing support. Tons of libraries, tools,
documentation, etc. Just go to RAIF or IFArchive.org and you got it.
You rarely even have to ask a question, as it's probably already been
discussed at length.
> David Fisher
> (Being a programmer type with many preconceived ideas)
I gather you're thinking of developing a non-programming IF language
targeting glulx? What about an ALAN glulx compiler?
letmes...@gmail.com
I slowly left inform programing because it seemed to obtuse for me. I
think the main thing is that the language does not have built-if
functions for rising standars in modern IF.
Example. In early games collision detection was limited due to
processor power (and by collision I just mean overlap), but not pixel
level detection can be done based on alpha channels.
I have no desire for a graphical interphase. Inform is not a visual
output, so I don't need a visual interface. While a map maker would be
nice, it encourages the "compass" directionality and resulting boxy
map.
I don't need a something where I can write "but a red box in the
courtyard and the player wins if he finds it"... poof I have a game.
Yet this is the rection given when any "smartening" of the compiler is
requested. I think adjectives as standard are long overdue. What I
would like to see are parsers and compilers that can do more with the
information supplied in the code. The new Triform is the most recent
edition to this.
I think debug information should be output, when possible in an
interface more complex that the game itself. I would be nice if a
tester could have an open multi-window with the game, variable states,
and text history open all at once.
David Fisher
news:1115991479.2...@f14g2000cwb.googlegroups.com...
> PS: I'm just starting with IF and some of the language constructs
> are driving me barking mad!
I would love to hear some examples of the things that are driving you mad
...
David Fisher
David Fisher
news:1116001560.9...@g44g2000cwa.googlegroups.com...
>> OK you non programmer types ... what would you like to see
>> in an IF language (or not see) ?
>
> I have some Inform experience. Contrary to some other posts I feel that
> most of its features are necessary to describe a complex world. What
> troubled me a lot initially was the grammar. So I want:
>
> A Graphical User Interface!
So to attempt a paraphrase: You are happy with the Inform language, but you
would like more tools to help write and debug it - preferrably GUI based,
with links that let you edit the code manually as well.
Would this solve the problems that you initially had with the grammar ? In
other words, was there anything you needed to do that would be unlikely to
be performed by the GUI you describe ?
I am just thinking that a set of GUI tools would make a lot of things faster
(and easier to check, manage, etc), but would not necessarily help when it
comes to tricky grammar ... The only way I can imigine it helping with
grammar is if you create something with the GUI and then examine the code
that is produced. But you would still need to learn the "tricky" parts of
the language to do things not included in the GUI.
Thanks,
David Fisher
David Fisher
news:1116045874.4...@z14g2000cwz.googlegroups.com...
>
> David Fisher wrote:
>> OK you non programmer types ... what would you like to see
>> in an IF language (or not see) ?
>
> I hate to be taboo and actually answer the question, but I've
> been looking into ALAN a little and I quite like the look of it.
> While you can look at an Inform source and get an idea what's
> happening, looking at an ALAN source with no prior knowledge
> you can understand *every* part, with no confusing symbols.
> Not that you can immedeatly write it, but "Isa" is more clear
> than "==" but not "=" or whatever.
OK, so lots of punctuation and symbols make code less readable and more
confusing ...
This is a bit tricky, because a really verbose language where everything is
spelled out in words gets pretty tedious to write after a while. Some
possible solutions:
- a really good editor that performs auto-completion of keywords (eg. type
"be" and press tab, and it changes it to "begin" - assuming "begin" is a
keyword in that language).
- an Inform (or whatever language)-to-English translator that produces a
more readable version of the code (but unfortunately not one that can be
modified or compiled)
- make the set of symbols used by the language as small and consistent as
possible.
Or ...
Another option is to make game creation less like writing a computer
program, and more like creating a database of objects and their
relationships with each other - not entered using a text editor at all ...
just thinking aloud, don't mind me. :-)
> I gather you're thinking of developing a non-programming IF
> language targeting glulx? What about an ALAN glulx compiler?
You've been reading my other posts ! :-)
Yes, I like the idea of using Glulx as a target, because of all the existing
interpreters out there. At the moment I am in "exploring the possibilities"
mode ...
I am not so much thinking of a "non-programming IF language" (because
programming always comes into it somewhere) - just something that is
approachable to people without that kind of background. I also think the
existing languages are very good, but there are some things which can't be
easily written in those languages that I have in mind ... so I am thinking
more of creating something different than porting an existing language such
as ALAN.
David Fisher
David Fisher
news:1116048655....@z14g2000cwz.googlegroups.com...
> What I would like to see are parsers and compilers that
> can do more with the information supplied in the code.
> The new Triform is the most recent addition to this.
Thanks for the input - could you explain a little more about what you mean
by compilers doing "more with the information supplied in the code" ?
David Fisher
Ian Haberkorn
> So to attempt a paraphrase: You are happy with the Inform language,
but you
> would like more tools to help write and debug it - preferrably GUI
based,
> with links that let you edit the code manually as well.
Actually it's the other way around: A GUI would help a lot in writing
(visualizing what can be and is being done); and some debugging
features would just come naturally.
> Would this solve the problems that you initially had with the grammar
? In
> other words, was there anything you needed to do that would be
unlikely to
> be performed by the GUI you describe ?
I'd put the problems I had learning Inform into 3 categories (and
whether I believe a different language could help me):
1) Logic problem/object behaviour: I can express my expectations of an
object in words, but not in logical statements ("When I am near, the
alarm should go off.").
This problem can be solved only by me or by library objects. The
language itself cannot really help me. (no 'library troll' vs.
individual troll discussion here)
2) I know how the logic works, but I don't know the "vocabulary" (When
I break the vase it turns into 'glass shards'. How can I get the parser
to describe it in plural now? How do I make a dog follow the PC?)
This was a matter of a lot of looking up things in the IBG and DM4. A
language can help me by using expressions that are easy to understand.
Inform usually does ('has plural' is pretty straightforward).
3) I know the logic and the vocabulary, but the game still doesn't do
what I want. (No output from the compiler - again!)
Grammar. I can't count how often I messed up ,:;[;{] et. al. Why
doesn't <= work? A language can be more or less intuitive in choosing
the symbols, but delimiters of some sort and meaning need to be there.
--------
I think, a GUI as outlined in the first post could have helped me A LOT
in the following ways:
- showing what's available: I can see the attributes and get a quick
reference to their meaning. Same with properties or system variables.
- Providing structure: Properties are separated by comma, Routines by
[; ] etc. that I need to keep track of. My dream GUI has a variable
part of the screen reserved for the features of the current object.
Properties would be individual boxes. No need for [; and indenting.
- Quick checking: when I leave the property box the code within is
checked for open braces, ifs or loops... I am immediately notified of
the error.
- and probably much more. The ideas are not very refined...
Ian
J. Robinson Wheeler
Ian Haberkorn wrote:
> Grammar. I can't count how often I messed up ,:;[;{] et. al. Why
> doesn't <= work?
Hmm. <= and >= do work in Inform, so I'm not sure what you
mean. However, ~= is pretty weird, I'll admit.
--
J. Robinson Wheeler Games: http://raddial.com/if/
JRW Digital Media Movie: http://thekroneexperiment.com/
letmes...@gmail.com
derived form the properties of objects rather than hard coding.
Some examples exist, such as supplying the weight of size of an object,
which in turn has an effect "capacity".
>From that example, allow me to jump to a more impossible example. Such
as defining, Class Battery, Class Metal... and being able to make
circuitry.
Somewhere in between, there is a lot of room to grow. As I mentioned
before, Triform seems to be a step in the right direction. To make a
door you simply make the door and say what to area it connects.
The argument against things like this always entails level of control.
But I don't believe this should be incompatible with good default
functionality. Writing great automatic doors should not deter or block
those who want a hire degree of customization.
While some IF systems are, in fact, very easy to program, they seem to
suffer from weaker parsing and disambiguation. Systems which can
decipher more disambiguation seem to require much more programming in a
"add-on" way rather than with integration.
One example of "doing more with the code" would be the use of
additives, which continues to surprise me in not being standard in all
IF systems. I think TADS has it and Inform has extensions.
Another example is have to create exceptions, rather than better
standard behavior in the case of being inside objects, or in the air...
again those tend a bit to uncomfortable towards an unreachable
simulationism.... however much ground could be covered.
Toni Ylisirniö
> Another option is to make game creation less like writing a computer
> program, and more like creating a database of objects and their
> relationships with each other - not entered using a text editor at all ...
> just thinking aloud, don't mind me. :-)
I once mused about deriving a IF environment from a MUSH server (MUD
like thingy). You would create the game "online" by issuing commands
inside the game...
> @dig/teleport Forest
Forest created with room number 42.
> @desc here=You are in a forest.
Forest/DESCRIBE Set.
> @create trees
Created: Object #43.
> @desc trees=You see a lot of pine trees all around you.
trees/DESCRBIE Set.
> look
Forest(#42R)
You are in a forest.
You see trees(#43Tn).
>
Et cetera, et cetera...
I didn't do much more than muse about it though. There would be numerous
problems with the idea, not least that MUSH isn't designed for IF.
The parser is extremely simple for one, so you'd have to import parsing
rules from some other environment, implement yourself, or just settle
on a 2 word parser (equivalent). Not very good idea in this day and
age...
David Fisher
news:QNEhe.1004$w03...@reader1.news.jippii.net...
>
> I once mused about deriving a IF environment from a MUSH server (MUD
> like thingy). You would create the game "online" by issuing commands
> inside the game...
[snip example]
> I didn't do much more than muse about it though. There would be numerous
> problems with the idea, not least that MUSH isn't designed
> for IF. The parser is extremely simple for one, so you'd have to import
> parsing rules from some other environment, implement yourself,
> or just settle on a 2 word parser (equivalent). Not very good idea in
> this day and age...
Some other people have had thoughts along these lines as well:
"Authorship as IF":
http://groups-beta.google.com/group/rec.arts.int-fiction/browse_frm/thread/e481f1fed5d9e558/20808263ffa30016
"Writing the game while playing it":
http://groups-beta.google.com/group/rec.arts.int-fiction/browse_thread/thread/433668552cb70dd0/353cf2f5d8c41d03
David Fisher
David Fisher
news:1116141995....@z14g2000cwz.googlegroups.com...
>
>>> What I would like to see are parsers and compilers that
>>> can do more with the information supplied in the code.
>>> The new Triform is the most recent addition to this.
>>
>> Thanks for the input - could you explain a little more
>> about what you mean by compilers doing "more with the
>> information supplied in the code" ?
>
What kind of language would be best to do this kind of thing ?
For example, if the library supplied a "telephone" object, how would you
want to be able to use it in your program ?
Using one possible language:
DownstairsPhone isa telephone
when actor (X) picks up:
if phone is ringing:
{ some code}
otherwise:
"You hear a dial tone"
when actor (x) hangs up:
{ some code }
when actor (X) calls number (N):
{ some code }
when actor (X) calls actor (Y):
{ some code }
when phone rings:
{ some code }
Or maybe like this:
telephone DownstairsPhone
"pick up *", "pick * up":
isRinging => { some code }
=> "You hear a dial tone"
"hang up", "hang up *": { some code }
"call/phone/ring { number n }": { some code }
"call/phone/ring [up] { actor x }": { some code }
event downstairsPhoneRings: { some code }
Or maybe something that looks like a transcript:
player: pick up the phone || pick the phone up
#1: phone is ringing
out: You pick up the phone and say "Hello ?" ... but there is no answer.
#2: phone is not ringing
out: You hear a dial tone
---
Do any of these ways look appealing ?
David Fisher
letmes...@gmail.com
Using one possible language:
Or maybe like this:
---
The third way... the most natural language... is definitely the least
appealing. I guess I feel a totally programmer-less language would
just be too canned to produce a good game. Many things exist now with
nearly no need to program.
I think it's a matter of making programing easier. The grammar in
inform still drives me crazy, the exact syntax for putting functions in
place, where to put commas, when to put semi colons has never felt
logical nor simplistic. It is consistent only to itself. I've found
tads more "c-like" but at the loss of a language (aka english french)
centric programming.
Little things, like "guess they syntax" can drive non or
semi-programmers crazy way before "understanding programing" can.
I feel Inform (not to pick on it, it's actully my language of choice)
very sytaxictly (is that a word?) messy.
I really feel a totally non-programmer interface is not attainable
without major sacrifices, templating or both. Both of which lower the
game quality.
What is needed is good base and default actions, with the ablity to
override in a class-like OOP matter that does not "hard code" fixes.
This would bridge a single language between beginner and advanced
programer alike.
There have been things I wanted to do in Inform that ground to a hault
when the only choice was to interrupt the parsing! If I could override
that... I'd have written my own!
There are pages of argument on what language to use based on syntax,
capability etc.. and I have my own wants. But my choice of platform
comes form the point of view of a player. Someone who reads you book
doesn't care if you wrote it in word, notebad, typed it, or wrote it on
1000 napkins. They see the final book and buy it based on context. I
choose Inform because I like the way the games runs and the "feel" of
the parser and interpreters.
When making an interactive game... two things are very important.
1. the words the players see
2. keeping a world model consistent with those words
In most text adventures it's possible to write code that results in....
You have an apple
>drop apple
Dropped
>Inv
You are carying:
An apple
I'd flock to the language that made it the hardest to do that.
Lets take Triform and Inform for example.
You can make a 2 way door like this.
==== code ====
Object -> StoneDoor "stone door"
with name 'door' 'massive' 'big' 'stone' 'yellow',
description
"It's just a big stone door.",
when_closed
"The passage is barred by a massive door of yellow stone.",
when_open
"The great yellow stone door is open.",
door_to [; if (self in Corridor) return Shrine; return
Corridor; ],
door_dir [; if (self in Shrine) return n_to; return s_to; ],
with_key stone_key,
found_in Corridor Shrine,
has static door openable lockable locked;
==== end code ====
not a lot of if thens.. but why do they have to be there at all?
Triform has a fix for this.
Again I refer to a better "base" a better "default" set. Without
impairing advanced programers.
So lets see.. if I wanted a phone.. hmm
First an object.
Object phone "Telephone"
now... when it's ringing.. do I just send text to that fact? Or do I
give it a "ringing" attribute or state? (these are rhetorical
questions)
In any text environment it's very easy to "just deliver the text"..
"The phone is ringing"....
but what if the moment the game had decided to "ring" the phone.. I'd
had already taken it off the hook?
Do we go to the trouble of setting up a phone "model" with all the
functions explained?
Again I think there is a balance. Hardcoding all the text makes it
harder to make object interact. Spending too much time on modeling
sends us into to much coding for objects that may have no real addition
to the story, game, or puzzle.
I think the forum is often filled with "solutions in a vacuum".
Solutions that work for a room or problem, but open a host of trouble
for the rest of the game.
I need a language where object can play well together :-)
I think I"ll go try to code a phone now.
letmes...@gmail.com
open call to program this out and see what works, what doesn't and what
could make it easier.
Room living_room "Living Room"
with description "A modest place"
has light;
Thing -> phone "A phone"
with
description
[;
if (self has ringing)
"An old rotary phone, which is ringing"
else
"An old rotary phone";
],
name "phone",
adjective 'rotary',
has -ringing;
Graham Holden
>What kind of language would be best to do this kind of thing ?
>For example, if the library supplied a "telephone" object, how would
>you
>want to be able to use it in your program ?
>
Sorry about this...
I don't care what the syntax is, so long as default behaviour of said
object is something like:
class Telephone
with
before[;
pick-up:
if( Parent(self) ofclass Booth )
deadflag = 1 ;
Regards,
Graham Holden (g-holden AT dircon DOT co DOT uk)
--
There are 10 types of people in the world;
those that understand binary and those that don't.
David Fisher
news:1116333156.1...@g14g2000cwa.googlegroups.com...
>>
>> David Fisher wrote:
>>
>> What kind of language would be best to do this kind of thing ?
>> For example, if the library supplied a "telephone" object, how
>> would you want to be able to use it in your program ?
>
> inform still drives me crazy, the exact syntax for putting functions in
> place, where to put commas, when to put semi colons has never felt
> logical nor simplistic. It is consistent only to itself. I've found
> tads more "c-like" but at the loss of a language (aka english french)
> centric programming.
Could you explain what you mean by "the loss of language centric
programming" ?
> What is needed is good base and default actions, with the ability
> to override in a class-like OOP matter that does not "hard code"
> fixes. This would bridge a single language between beginner and
> advanced programer alike.
I agree ...
One of the trickiest things is allowing the writer to override the default
behaviour in a simple, consistent kind of way (sometimes called providing
"hooks" into the code). "Easily configurable objects" are the ideal for IF
(including non-material "objects" like a conversation, the weather, etc).
> When making an interactive game... two things are very important.
>
> 1. the words the players see
> 2. keeping a world model consistent with those words
Another IF ideal - the above mentioned "configurable objects" must behave in
a way that maintains an accurate and consistent world model, and (as you say
later) must also interact with other objects in a safe, consistent way.
Just thinking about this ... the more a game designer "reconfigures" the
default objects and/or adds more of their own, the more they will have to
take responsibility for keeping the world consistent themselves. If all
objects just stick to their default behaviour, the language/library designer
can make sure that everything "plays well together" and acts in a consistent
way - but if things start behaving in a more custom way, then the original
designers can't ensure anything at all. The game writer will need to (1)
understand the original "rules" of the system - what the world being
"consistent" actually means, and (2) work out the new rules implied by the
changes they have made.
Ick. Could get very complex ...
> So lets see.. if I wanted a phone.. hmm
...
> Do we go to the trouble of setting up a phone "model" with all the
> functions explained?
>
> Again I think there is a balance. Hardcoding all the text makes it
> harder to make object interact. Spending too much time on modeling
> sends us into to much coding for objects that may have no real addition
> to the story, game, or puzzle.
But to do what you are wanting (which is to make sure all the objects behave
sensibly, wherever you insert them into a game), the model does have to be
pretty thorough. Which is worth it for re-usable objects, but maybe not for
things which are only used in a single game.
> I think I"ll go try to code a phone now.
Just for interest, here is a specification for a phone:
1) Player can refer to it as "phone" or "telephone" (configurable - can add
more names as well, but can't disable these two).
2) It is a physical object with the following properties:
2a) It has a cord, referrable as "[<phone>] (cord|wire)". This can be
"(unplugged|disconnected) [from (<phone>|socket|plug|wall [plug])]". The
same syntax applies to the phone as well, ie. "disconnect phone" does the
same thing as "disconnect phone cord". The cord is a kind of "rope object"
(uh, oh !), initially attached to the wall plug and the phone. Being a rope
object, it can be cut. It also has a certain length (default value =
whatever), which allows someone who is carrying the phone to take it that
distance away from the plug and still talk on the phone.
2b) The phone may be working or not (default = working).
2c) The phone may be on or off the hook (default = on the hook).
2d) It can be configured to be a rotary or digital phone (default = rotary).
2e) A digital phone may optionally have a "redial" button and other custom
buttons (transfer, speaker, conference call, etc). See 3d etc for the effect
of pressing the redial button.
2f) It has a default bulk and weight of (... whatever ...). It cannot be
moved unless the phone cord is cut or unplugged.
2g) It may currently be "ringing" or not. It may not be ringing if the phone
is not working, off the hook or disconnected (including the cord being cut).
The ring tone (ie. message displayed to the player) may be configured. By
default, the message just says that the phone is "ringing". The volume /
loudness of the ring is (... whatever ...), which is also configurable. (The
volume affects the distance away you can hear the phone from). There is a
"caller" object (usually an actor) associated with the phone ringing.
3) The following special actions may be performed on the phone:
3a) "pick up <phone>". This is not the same as "take <phone>" (see 2a for
requirements about the phone cord for taking the phone). If the phone was
ringing, it stops ringing, and a conversation is initiated with the "caller"
(which must be handled by the game author). The PC has first opportunity to
speak in the conversation. If the phone was not ringing, the PC either hears
a dial tone (if the phone was on the hook, is working and the cord is not
disconnected), an "engaged" signal (if the phone was off the hook, working &
not disconnected) or nothing (if the phone is not working or is
disconnected). All of these messages are configurable.
3b) "put down <phone>" or "hang up [<phone>]". This ends any conversation in
progress and causes the phone to be on the hook.
3c) "dial|call|ring [up]|phone (number|person|place)". If the player has
picked up the phone (and not put it down again :-) ) and the phone is
working & connected, this initiates a phone call. This must be handled by
the game author in one of the following ways: zero or more "rings" (for a
certain maximum number of turns), followed by a "stopped ringing" message or
a conversation being initiated; an "engaged" message; or a custom message
(eg. "the number you have just dialled is not connected ...")
3d) If the "redial" button is pressed, it is handled the same way as if the
PC picked up the phone and called the last number again. By default, the
last number is initially "none".
3e) If the phone is digital (see 2d), there also is a "hash" and a "star"
button. Pressing these keys or the number keys during a conversation has a
custom effect (ie. handled by the game author). By default, pressing one of
these buttons during the conversation causes a "beep" sound audible to both
the caller and the callee.
Simple, huh ?
This may seem a bit "over the top", but thinking like a player instead of an
author, it might be annoying if some of the above things were not
implemented, eg. if the phone cord was not detachable, or if you couldn't
ring up a person by name (assuming you already knew their number).
So ... what is the best interface for a game author who wants to use this
phone in an IF game ?
David Fisher
David Fisher
news:URwie.13995$Le2....@nasal.pacific.net.au...
Left out a few things ...
2f) Change "cannot be moved" to: cannot be moved further than the phone cord
allows without pulling out the plug (see 2a). If it is carried further than
this distance, the plug at either the wall or at the phone will become
disconnected (random)
2g) Add: The phone has a maximum number of rings before it stops
automatically (then the caller must explicitly redial the number).
2h) The phone may optionally have a display with "caller id". When the phone
is ringing, a custom message is displayed (supplied by the game author).
3c) Add: The PC can also "dial a random number|dial [a number] at random".
By default there is no answer (configurable by game author).
3c) Also add: During a conversation, background noises are audible to both
parties (the caller and the callee).
3f) If the phone is dropped, it becomes off the hook. If the phone is
"attacked", it stops working (2b).
David "put everything in quotes" Fisher
David Fisher
And some more ...
2i) The phone line may be working or not (default = connected). That is, the
phone might be working & the cord connected, but the phone line (outside the
house, etc) might have been cut (or there might be a blackout, etc).
2j) You can also have a cordless phone ...
3g) It is possible to plug a phone into a vacant phone plug (eg. to replace
a non-working phone with a working one). (I can imagine a puzzle where you
have to do this :-)
3h) Several phones may share the same line, in which case their ringing is
in sync and it is possible to listen on one phone to the conversation on
another phone (as happens in several movies). A noise on the other phone
will alert the caller & callee that someone is on the other line.
Whew ... is that all ? :-P
David Fisher
Toni Ylisirniö
> Whew ... is that all ? :-P
Non numbered additions:
* Phone has two cords. One goes from phone to wall, one from phone to
headset (assuming non-cordless one, cordless has only cord that goes
to wall). Some models (new mostly) can detach either cords via plug,
and both can obviously be cut.
- You can carry the phone to distance determined by the cord to wall
- You can additionally carry the headset another unit of distance.
- If headset is carried too far, you can't touch the phone itself
- No hangup, dialing, etc...
* Often phone can be set to audible ring, or inaudible ring. (Or even
variable levels of volume). Digital ones often have light that blinks
while ringing (possible to notice ringing in extremely noisy
environment)
* Some models allow you to adjust the volume of the headset.
- Noise in the environment may require higher speaker volume
* Speaking of speakers... A speakerphone.
- All people in room hear, all people in room can speak
- Two speakerphones in same room == bad idea.
* Cordless phone can be rendered unusable by radio interference
* (Common) Cordless phones can be eavesdropped with radio receiver
* Cordless phone contains batteries in the headeset
* Digital phones may have batteries in them (for non dial functions,
memory etc...)
* Regular phones are powered by phone line (around -50 volts while open,
up to -90 or over while ringing, (practically) no power while line not
open)
And let us not get into cellphones... ;)
Toni Ylisirniö
> * Cordless phone contains batteries in the headeset
* Not nescessarily dry cells. May be rechargables and basestation
contains recharger (and a power cord).
> * Digital phones may have batteries in them (for non dial functions,
> memory etc...)
* And/or digital phones may have a power cord in addition. (Total of 3
ropes hooked to single object!)
* Headset cord is typically coiled, making it in addition to rope, be
a weak spring. You can't stretch it out to full length without something
holding the ends. (Otherwise it springs back)
David Fisher
Lots of good thoughts, but the idea is still to create a full-function
telephone that might go in a library somewhere - some of these ideas are a
little elaborate ! (Not that some of mine aren't, too ...)
Back to the original question: What is the best way to provide a "telephone"
object in a library for some language so that all of the configurable parts
are *really simple* to replace with custom code ?
David Fisher
Ian Haberkorn
pretty good example for the mixed blessings of preformed library
objects.
If you provided one with all the features described, there'd probably
be more than 200 lines of code to roughly 'understand'. Additionally,
there'd be lots of pitfalls for unwanted interaction to take care of
(what can be done with the cords alone...).
A player encountering such a complex object will assume there's a
puzzle behind it and will spend time taking it apart etc.
Coding a simple phone on the other hand can be much quicker than the
above task.
Concluding, I believe that by providing a complex library object might
eliminate the work of writing it, but may replace it with the work of
understanding it, customizing it and anticipating interaction attempts
with all its parts.
In any case, I don't think that standard objects can really substitute
knowledge of the language by a greater degree. To make things easier
for a beginner I'd rather support tutorials and structural help (like
the GUI mentioned above).
Ian
Rikard Peterson
David Fisher wrote in
news:URwie.13995$Le2....@nasal.pacific.net.au:
> 1) Player can refer to it as "phone" or "telephone" (configurable
> - can add more names as well, but can't disable these two).
Why can't those two be disabled? I can't think of an example where it'd
be useful to do so with this phone object, but if you build a system
with objects like that, I think it's very likely that people will want
to remove names when they think of a brilliant way to transform one
object into another.
Rikard
Sophie Fruehling
>Just for interest, here is a specification for a phone:
<snip huge list>
>Simple, huh ?
>
>This may seem a bit "over the top", but thinking like a player instead of an
>author, it might be annoying if some of the above things were not
>implemented, eg. if the phone cord was not detachable, or if you couldn't
>ring up a person by name (assuming you already knew their number).
I don't think it's useful to allow everything you can think of that
the player could come up with, unless it's important to playing the
game. IMO, if you have to go into such detail (and I don't think you
do), it would be better for a general library phone to have default
messages to explain why the player *can't* unplug the phone, for
example. (Like most Inform standard library verbs *don't* do anything
by default.)
If we are trying to model "real life" to some extent, I think it's
the wrong way to go to make everything manipulable. In real life, I'm
sitting in a room full of objects I could take, drop, open, close,
unplug, etc. but I don't, because I've got better things to do. ;)
It's easy to lose focus as a player if you can do too much. IMO, the
player should be subtly guided by the author to want to do what is
necessary to make the game move forward.
Of course, this has nothing to do with IF languages, just a general
thought.
--
Sophie Frühling
"El arte no viste pantalones."
-- Rubén Darío
cub...@aol.com
Ian Haberkorn wrote:
> The telephone (and especially your model with two cords etc.) is a
> pretty good example for the mixed blessings of preformed library
> objects.
>
> If you provided one with all the features described, there'd probably
> be more than 200 lines of code to roughly 'understand'. Additionally,
> there'd be lots of pitfalls for unwanted interaction to take care of
> (what can be done with the cords alone...).
might be somewhat reduced by stealing techniques from Object-Oriented
Programming. "Under the hood" of any given game, there are only a
relatively few Actions the player can perform in the first place; if a
pre-formed library object has reasonable built-in default responses to
those Actions, a game-author can just plug that puppy into his game and
not care. The author will still have to fiddle with the library object
when he wants to do something non-standard with it, of course -- but
since that's *always* going to be true, *regardless*, I do not see that
as a crippling flaw in this notion.
[snip the rest]
David Fisher
"Rikard Peterson" <trumg...@bigfoot.com> wrote in message
news:Xns965A6A45F7C17tr...@127.0.0.1...
Good point ... I guess absolutely everything should be configurable,
including the object name.
Looking forward to the combined can opener and telephone object appearing in
your next game, :-)
David Fisher
David Fisher
"Sophie Fruehling" <sfrue...@LOVELY-SPAM.aon.at> wrote in message
news:37mm81tssk1mrrurb...@4ax.com...
I think a compromise might be to allow the game author to enable or disable
things like the telephone cord being detachable (which could be "false" by
default). The point is to make it simple for them to use a prefabricated
object without much extra coding, and it seems reasonable to make the phone
cord detachable in some games (where it is needed for puzzle) & maybe not in
others (if it would spoil a puzzle). The problem with making a "library"
object is that you need to try and make things general enough for everyone's
needs (which is very hard to predict) ...
The general message I get from comments in the RAIF archives is that players
are disappointed when a clever solution occurs to them for a problem ("Aha !
I could use the telephone cord !") - and the game does not allow it. I tend
more towards a "simulationist" approach where you can do a lot of logical
things (like removing the cord from a telephone) which might not imply that
you *have* to do them to win the game, rather than a "restrictive" approach
where you can be sure that if the game allows you to do something, it must
be important. I really think this is less annoying to players in general.
David Fisher
David Fisher
news:1116449360....@g47g2000cwa.googlegroups.com...
>
> Ian Haberkorn wrote:
>> The telephone (and especially your model with two cords etc.) is a
>> pretty good example for the mixed blessings of preformed library
>> objects.
>>
>> If you provided one with all the features described, there'd probably
>> be more than 200 lines of code to roughly 'understand'.
[ snip & move next comment further down this post ]
> It seems to me that the headaches of unanticipated interactions
> might be somewhat reduced by stealing techniques from Object-Oriented
> Programming. "Under the hood" of any given game, there are only a
> relatively few Actions the player can perform in the first place; if a
> pre-formed library object has reasonable built-in default responses to
> those Actions, a game-author can just plug that puppy into his game and
> not care.
That's the intention ...hopefully the object would be a kind of "black box"
where the source code does not need to be examined by the game author
(assuming sufficient documentation of the parameters & behaviour of the
object). When I write C/C++ programs, I don't tend to look at the source
code for library functions - just the manual pages / documentation (and
often the source code isn't available anyway).
> Ian Haberkorn wrote further:
>> Additionally, there'd be lots of pitfalls for unwanted interaction
>> to take care of (what can be done with the cords alone...).
The game author would certainly need to be aware of the implications of
including certain objects in their game. This is true whether you write it
yourself or use a library version, though.
Maybe there is a need for an "auto beta tester" program that tries
everything & dumps the output to a file so you can examine it and see if
anything unexpected happened. It would need to be a "white box" not a "black
box" test, though (I feel like throwing technical terms around today :-) ) -
ie. with knowledge of the code it is testing. Otherwise it might try saying
"pick up frog" in every room in the game, even if there is no frog ...
[New thread started: "auto beta tester"]
David Fisher
letmes...@gmail.com
Thinking back to one of my favorite games... planetfall. I was trying
to remember what made it so real for me what made it fall apart.
So far, and mind you this may be a very personal view, I've always been
happier with a smarter parser than a more complex object.
If an object is very limited in what it can do, I don't mind, but it
helps if the accompanying text can explain it.
>TAKE PHONE
You should not touch other's property!
However... I do mind when I play "guess the verb" for those very
limited actions. My own goal would not be to make the object and there
for its actions complex, but rather provide the most ways to "say" it.
>PICK UP PHONE
You should not touch other's property!
>ANSWER PHONE
You lift the receiver and say hello.
I think once you make the object model super complex, you've lost the
point for most cases. It's not to simulate, but rather... to "play
well with others".
The most simple example I can think of is the proper use of adjetives
to aid disabiguation.
The goal of the "phone" object should not be separte from it's purpose
in the game. One should start with a model of "play" and/or a
trascript and build something to fit that transcript... adding more
based on testing.
OOP methods should be applied where ever possible so that properties
can be changed, inhereted, and overridden.
So backing off this growing phone model... how about a senario.
A lost cell phone which you hear more loudly as you get closer. Until
till you finally discover and answer it.
Remember, in IF you can help or hinder as much as you like... but what
does it really add to the game?
>Answer phone
You'll have to pick it up first
>Pick up phone
Don't take other's property
>Lift reciver
You hold it in the air
WAAAAAAAAAAAAAAAARRRRRRGGGG!!!
Again.. I feel avoiding "guess the verb" ranks above simulation.
letmes...@gmail.com
Here's a common senario I see with first time players.
Library
You in a library, you she shelfves of books here.
>GO TO SHELVES
They are already here!
Any thoughts? I thing one idea would be to pass "go to" to "examine"
in this case.. where a person will percieve an objected as a "sub
location".
David Fisher
news:1116462376.5...@g14g2000cwa.googlegroups.com...
> wow that's one complex phone.
>
> Thinking back to one of my favorite games... planetfall. I was trying
> to remember what made it so real for me what made it fall apart.
>
> So far, and mind you this may be a very personal view, I've always been
> happier with a smarter parser than a more complex object.
>
> If an object is very limited in what it can do, I don't mind, but it
> helps if the accompanying text can explain it.
>
>>TAKE PHONE
> You should not touch other's property!
I guess that's the point ... that everything is "thought of" rather than
necessarily "implemented". But I am coming from the point of view of an
existing library of configurable objects. So part of the configuration for
each object would be: Would you like a certain behaviour to be activated for
the object ? If so, customise the default behaviour ... if not, customise
the messages that say "you can't do that".
> The most simple example I can think of is the proper use of
> adjectives to aid disambiguation.
Proper parsing, etc. would hopefully be included in the library object ...
though this is more game-specific, so the game author is more responsible
for this one than a library author. Maybe the associated documentation for
the library object should give a list of things to remember (recommended
synonyms, etc) ?
> The goal of the "phone" object should not be separate from it's purpose
> in the game. One should start with a model of "play" and/or a
> transcript and build something to fit that transcript... adding more
> based on testing.
>
> OOP methods should be applied where ever possible so that properties
> can be changed, inhereted, and overridden.
That's the idea ...
So, back to the original question again: What would a re-usable library
object look like ? How would it be used (configured & integrated into the
code) ?
David Fisher
David Fisher
<letmes...@gmail.com> wrote in message
news:1116462608....@z14g2000cwz.googlegroups.com...
With your permission (I hope !) - another new thread, ["Go to shelves"].
Just to make future RAIF archive explorers more happy ...
:-) (see, I'm happy already)
David Fisher