WhatIF Syntax (Ruby IF)
JamesEdw...@gmail.com
implementing my own IF language. Back then, I was talking about using
Perl. I experimented with many different IF related Perl tasks after
the excellent advice I got here, but never got to the point where I
felt my work was ready to show off.
Then I shifted focus to Ruby and picked up a partner.
Together, we are working on WhatIF, our domain language for IF, using
the Ruby programming language. My own explorations in Perl taught me
much and my partner is another great asset and now we do believe we
have something to share.
The project isn't yet public and we're still in early development, but
we're very interested in any (constructive) feedback we can get from
the IF community. ("Use Inform!" is not to be confused with the word
constructive here.)
We're going to show off parts of our work as they are ready. Today, we
would like to give you a peek at the syntax we're leaning towards.
Obviously, this isn't final, but it is the result of much effort on our
part and our best guess at this point. Your feedback, could help shape
changes in our development. That's why we're here.
We are currently hard at work on our parser and that's the next thing
we intend to share. We intend to give you access to a working
prototype and invite you to break it with sinister inputs, so you can
watch us squirm. That should be great fun for all, so stay tuned...
However, as I said, today is about syntax. You can find our current
thoughts on Cloak of Darkness syntax here:
http://if.grayproductions.net/cloak.html
We've tried to comment on our thinking in there, as needed. This is
not a 5 minute thrown together syntax file and we've discussed most of
the choices in here at some length. We've mocked up sections of the
code to prove concepts and discussed our implementation ideas. Again,
this is currently our best guess.
Given that, we're very open to feedback from the experts. We think
that's all of you game writers. So if you know a little Ruby or are
just curious about our ideas for IF syntax, please take a little time
to examine the above and share any thoughts you may have about it.
Thanks for your time.
James Edward Gray II
Sean E. McCardell
P.S. For those curious about our project, here is an early peek at our
README file:
Welcome to WhatIF
by James Edward Gray II
What if...
This project is the combined vision of James and Sean to marry
Interactive Fiction and the Ruby programming language. We're reversing
the traditional IF approach and bringing IF abilities to our language
of choice instead of using an IF language.
We are indeed aware of how refined these languages are and we do
respect them. However, as programmers, we are sometimes frustrated by
the limitations of these languages. We want to keep the ease of
writing, but we don't want to sacrifice the power of a real programming
language to get it. We've studied IF languages and learned tons from
them, but now we want more...
WhatIF is a domain specific IF language for Interactive Fiction games,
written in Ruby. That means that you only need to require the WhatIF
library and begin writing your game with the full power of Ruby at your
fingertips. However, thanks to WhatIF, you gain all the standard IF
tools, right alongside your Ruby syntax. It really is the best of both
worlds.
Even better, because we now have a powerful programming language
running the show, we can use techniques like metaprogramming, code
generation, and reflection to really make the IF engine handle the
dirty work. We're lazy and we want you to be too!
We're committed to building the next generation of Interactive Fiction
software with WhatIF. We want it to be as easy to write stories in as
any other language, and be more flexible besides. You can dig as deep
as you like.
But please, don't take our word for it. Explore WhatIF yourself and
see what IF has become...
Eizua
[snip]
> We are currently hard at work on our parser and that's the next thing
> we intend to share. We intend to give you access to a working
> prototype and invite you to break it with sinister inputs, so you can
> watch us squirm. That should be great fun for all, so stay tuned...
> However, as I said, today is about syntax. You can find our current
> thoughts on Cloak of Darkness syntax here:
>
> http://if.grayproductions.net/cloak.html
>
[snip]
I'm no expert, but the sample code you have there looks interesting.
Good luck on the parser. From what I've heard here that's the hardest
part in creating an IF language.
David Fisher
news:1117142207.2...@o13g2000cwo.googlegroups.com...
>
> ... we are working on WhatIF, our domain language for IF, using
> the Ruby programming language. My own explorations in Perl
> taught me much and my partner is another great asset and now
> we do believe we have something to share.
> You can find our current thoughts on Cloak of Darkness syntax
> here:
>
> http://if.grayproductions.net/cloak.html
>
> So if you know a little Ruby or are just curious about our ideas
> for IF syntax, please take a little time to examine the above and
> share any thoughts you may have about it.
I don't know Ruby, but it looks good so far ...
The Cloak of Darkness code includes the lines:
on :drop, :put do |event|
if cloak.where_am_i == :cloakroom
Small suggestion - since an object's location would be frequently referenced
in the code, maybe something shorter than where_am_i might be better
(cloak.loc ?)
Further down in the code:
# Exits...
foyer.n = "You've only just arrived, and besides, the weather outside
seems to be getting worse."
In TADS 3 you can separate the concept of "room connections" from "cannot go
that way" messages. This is useful if you want to do something like finding
the shortest path between two rooms. I guess you could test if the type of
foyer.n was a string or an actual room, though ... it just seems nicer to me
to separate these two concepts.
Have you had any thoughts about implementing "undo" in WhatIF ?
David Fisher
samwyse
> However, as I said, today is about syntax. You can find our current
> thoughts on Cloak of Darkness syntax here:
>
> http://if.grayproductions.net/cloak.html
>
> We've tried to comment on our thinking in there, as needed. This is
> not a 5 minute thrown together syntax file and we've discussed most of
> the choices in here at some length. We've mocked up sections of the
> code to prove concepts and discussed our implementation ideas. Again,
> this is currently our best guess.
>
> Given that, we're very open to feedback from the experts. We think
> that's all of you game writers. So if you know a little Ruby or are
> just curious about our ideas for IF syntax, please take a little time
> to examine the above and share any thoughts you may have about it.
You seem to have a lot of "foo.this" and "foo.that" in your code. I'm
not sure if what I'm about to suggest is possible, but in some languages
you can say something like this:
with foo {
.this = 1;
.that = 2;
}
Something like that could save a lot of typing. (In fact, now that I'm
thinkinag about it, why doesn't Inform support that? There could even
be an implicit "with self" wrapped around methods.)
RootShell
> However, as I said, today is about syntax. You can find our current
> thoughts on Cloak of Darkness syntax here:
>
> http://if.grayproductions.net/cloak.html
>
> We've tried to comment on our thinking in there, as needed. This is
> not a 5 minute thrown together syntax file and we've discussed most of
> the choices in here at some length. We've mocked up sections of the
> code to prove concepts and discussed our implementation ideas. Again,
> this is currently our best guess.
A lighter background would make it a lot easier to read the sample code :)
Look's promissing, keep working.
Kind Regards,
RootShell
--
RootShell, Lisbon, Portugal, Europe, Earth ;)
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use -> RootShell AT netcabo DOT pt
JamesEdw...@gmail.com
I'll dig into TADS 3 a little and see how they do exits. I will say
that I like the current system though. Many of our accessors will
support many different types of settings and then just do the right
thing, based on what you feed them. Duck Typing is our friend. I also
have plans to have exits support more than just Strings and Places...
:)
Thanks for the suggestions.
James Edward Gray II
JamesEdw...@gmail.com
thing :name do |thing|
thing.whatever...
end
with an implied "sefl" (using Ruby's instance_eval(), for the curious):
thing :name do
whatever...
end
Truth be told, our first design looked exactly like that.
Unfortunately, there are a few complications to doing things that way
and it made us force a couple of special cases on the author. (At
times, you would be required to prepend "self." to get the expected
behavior, for example. The nested declarations were also problematic
here.) In the end, we dumped the idea for in favor of clear and
concise declarations.
Remember that you can set the name of the passed variable, so you can
make it quite short:
thing :name do |t| t.whatever... end
I'm afraid that's the best we can do on this issue.
James Edward Gray II
letmes...@gmail.com
reminds me of when I tried to give up line numbering in BASIC!
I agree that where_am_I should be shorter. why not "is_in?"
On problem I have with Inform syntax is that it is hard to see where to
"insert" code. It's not "where" to put the code, but weather to use
comma's vs semicolons or nothing at all.
David Fisher
news:1117238735....@g43g2000cwa.googlegroups.com...
>
> Thanks for the suggestions.
That's OK ...
Still wondering - have you thought about implementing "undo" in WhatIF ? It
could be a major problem for some (all ?) players if it is not possible ...
David Fisher
JamesEdw...@gmail.com
"undo". That's why it's been done in several different projects now.
:) We can of course, do the same.
For me, "undo" is more of a stylistic problem. It just doesn't feel
right to me. I'm not convinced there isn't something better out there
waiting to be discovered.
To be clear, I recognize the need for such a feature and why it exist.
WhatIF will address that need. I like to think we might find a
different angle to approach the problem from, but if not, you'll likely
see some kind of "undo", yes.
We've not done a lot of design in this area yet and I like to think
we're digging up some unique ideas in the IF space (Sean deserves a
huge portion of the credit here!). Maybe we'll surprise you with an
all-new "undo". Give us some time to think on it...
And thanks again for the interest!
James Edward Gray II
David Fisher
news:1117576582.7...@z14g2000cwz.googlegroups.com...
> Obviously, there are no significant technical hurdles to implementing
> "undo". That's why it's been done in several different projects now.
> :) We can of course, do the same.
A quote from an old thread (by Zarf, so it must be right ;-) ):
"It's a truism in software development that if you want to implement
undo -- for any program -- you have to design it in from the start.
Retrofitting undo is a nightmare. True of IF also."
> For me, "undo" is more of a stylistic problem. It just doesn't feel
> right to me. I'm not convinced there isn't something better out there
> waiting to be discovered.
I'd love to hear about it when you discover it ...
Some other interesting threads:
"Is Undo cheating ?"
http://groups-beta.google.com/group/rec.arts.int-fiction/browse_frm/thread/889e6c7af83a48ca/519b432015586de8
"How important is Undo ?" (warning: off topic tangent half way through !)
http://groups-beta.google.com/group/rec.games.int-fiction/browse_frm/thread/9595541d6d983e2e/f7ab61129a9e0a8f
> We've not done a lot of design in this area yet and I like to think
> we're digging up some unique ideas in the IF space (Sean deserves a
> huge portion of the credit here!). Maybe we'll surprise you with an
> all-new "undo". Give us some time to think on it...
A random idea: a lot of games set "check points" that you go back to when
you die ... although it can be irritating to be forced to replay parts of
the game. On the other hand, "undo" can make random events meaningless (eg.
combat), and maybe going back to the last check point could help with this.
I think it should ultimately be in the hands of the game author, though ...
Good luck with it all,
David Fisher
samwyse
> A random idea: a lot of games set "check points" that you go back to when
> you die ... although it can be irritating to be forced to replay parts of
> the game. On the other hand, "undo" can make random events meaningless (eg.
> combat), and maybe going back to the last check point could help with this.
> I think it should ultimately be in the hands of the game author, though ...
An interesting idea. In Inform, at least, UNDO is implemented via a
simple checkpoint mechanism that is built-into the Z-machine. The
standard library sets a checkpoint during each turn, and UNDO resets to
that checkpoint. Common problems with this mechanism revolve around
code that skips the checkpoint, usually menu-based conversation systems.
On the other hand, it isn't difficult to disable the checkpoints
during scenes driven by random numbers, i.e. combat; the only trick is
to avoid over-disabling it.
Alex Watson
> A random idea: a lot of games set "check points" that you go back to when
> you die ... although it can be irritating to be forced to replay parts of
> the game. On the other hand, "undo" can make random events meaningless (eg.
Slight tangent: because of the pseudorandom nature of random number
generators, most random events actually happen predictably. So undo
can't actually prevent them from happening. (Obviously it can allow the
play to be more prepared etc.)
Alex
Sean E. McCardell
> In TADS 3 you can separate the concept of "room connections" from "cannot go
> that way" messages. This is useful if you want to do something like finding
> the shortest path between two rooms. I guess you could test if the type of
> foyer.n was a string or an actual room, though ... it just seems nicer to me
> to separate these two concepts.
Thanks for the suggestion. This would also be useful for implementing
an "exits" command. I've just been poking around in the TADS3 "Getting
Started" guide, and the examples on travel cover some points that we
(or at least I) hadn't thought of--we'll definitely keep them in mind
as we continue to develop the syntax for WhatIF.
--Sean E. McCardell
David Fisher
news:429e36d0$0$23714$db0f...@news.zen.co.uk...
> David Fisher wrote:
>>
>> ... "undo" can make random events meaningless (eg. combat)
> Slight tangent: because of the pseudorandom nature of random number
> generators, most random events actually happen predictably. So undo can't
> actually prevent them from happening. (Obviously it can allow the play to
> be more prepared etc.)
I see your point - but you can still get around this if you can get the
random number generator to be called before you do the action again (eg. run
away and come back later). Or you could try a different action altogether,
knowing what will & won't be successful (which is unrealistic).
David Fisher
Matthew Russotto
Since "undo" rarely undoes the RNG state, it often does work to
modify random events in the player's favor.
--
There's no such thing as a free lunch, but certain accounting practices can
result in a fully-depreciated one.
Alex Watson
>>Slight tangent: because of the pseudorandom nature of random number
>>generators, most random events actually happen predictably. So undo
>>can't actually prevent them from happening. (Obviously it can allow the
>>play to be more prepared etc.)
>
>
> Since "undo" rarely undoes the RNG state, it often does work to
> modify random events in the player's favor.
That's a good point; do you know if it does in Inform? Because I seem to
recall having random events repeat across undos in the past. But
possibly that was just coincidence; it was more chance observation than
systematic testing :)
Alex
Matthew Russotto
Alex Watson <alexw...@deadspam.com> wrote:
>Matthew Russotto wrote:
>>
>> Since "undo" rarely undoes the RNG state, it often does work to
>> modify random events in the player's favor.
>
>That's a good point; do you know if it does in Inform? Because I seem to
>recall having random events repeat across undos in the past. But
>possibly that was just coincidence; it was more chance observation than
>systematic testing :)
It's up to the interpreter.
Andrew Plotkin
> In article <429f4a29$0$2604$da0f...@news.zen.co.uk>,
> Alex Watson <alexw...@deadspam.com> wrote:
> >Matthew Russotto wrote:
> >>
> >> Since "undo" rarely undoes the RNG state, it often does work to
> >> modify random events in the player's favor.
> >
> >That's a good point; do you know if it does in Inform? Because I seem to
> >recall having random events repeat across undos in the past. But
> >possibly that was just coincidence; it was more chance observation than
> >systematic testing :)
>
> It's up to the interpreter.
But Matthew was correct when he said it "rarely" undoes the RNG. I
don't know of an interpreter that does.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.