Simple and Advanced IF Languages Joined?
Daniel Phillips
So I was taking a well-needed jog/walk to and from the local Subway
restaurant, and on the way back I thought of something that, to me,
could provide a solution to my anticipated problem with more complex
puzzles. Admittedly, this idea is a bit silly and simple, perhaps
even heathenous to some, but I see it as possibly working. Please bap
me on the head with an intricate parser if I'm wrong.
My text adventure authoring system of choice is ALAN. It has an
unfortunate lack of games (ok, I'm wrong; things can change in four or
five years), but a good community and author supporting it. I find it
a clean and intuitive language that would serve me well. But as with
any "easy" language that's not TADS or Inform, it might run into
problems or bulkiness with certain complex puzzles.
Solution? Create a separate puzzle file written in a complex language
of one's choice, be it Inform or TADs or another. When the solution
to that puzzle has been reached, it'll output a codeword that can be
said in the main game, and then output another codeword to use in the
puzzle file to transfer the player to another puzzle when he or she is
ready.
Or, alternatively, there can be an interchange. To solve a puzzle
that's actually part of the main game, the game will output a code
word to use to unlock a puzzle area in the puzzle file. Then, when
that puzzle is completed, the puzzle file will output a codeword to
use in the main game to indicate to it that the puzzle was solved.
This does mean more hassle on the part of both the player and author,
as well as the breezing through of complex puzzles using just code
words. But those are some of the consequences of this method.
Might as well just combine two text authoring systems in one, maybe? I
would cringe at the prospect of having to deal with two similar
languages in one, though. Eep.
Please let me know if the idea I proposed has been done before, and
how it turned out.
Before I sign off, I better outline some definitions because I found
confusion. Hey it's late, or early, depending on the view.
- advanced - authoring programs often best with prior programming
knowledge.
- simple - not meant to be insulting by any means; often authoring
programs that can be easier to understand and learn
- main game - the bulk of the game programmed in the author's choice
- puzzle file - programmed in another language and contains those
nagging puzzles that just don't seem to work out in the main game;
keeps the author from having to rewrite the whole game
- whole g...nm
Thanks,
Daniel
P.S. Have I proved my writing prowess? Is someone looking for someone
to collaborate with at some point in the future? My search continues
here and there.
Daniel Phillips
bandi...@toppler.zworg.com
[+]bandito[-]spam = [-]toppler.[+]zworg.com
Be warned, may mistakingly bounce back as spam.
Adam Thornton
>of one's choice, be it Inform or TADs or another.
Surely the pain of implementing this and handling the glue between the
two is larger than the difficulty of learning one of the complex
systems?
Adam
Quintin Stone
> Surely the pain of implementing this and handling the glue between the
> two is larger than the difficulty of learning one of the complex
> systems?
I would think so. I mean, if you are able to code your big, complicated
puzzle in one of the more complex languages, why would really need a
simpler language to do your simplier puzzles?
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/
davidw
"Quintin Stone" <st...@rps.net> wrote in message
news:Pine.LNX.4.44.03101...@yes.rps.net...
> On Fri, 10 Oct 2003, Adam Thornton wrote:
>
>
> I would think so. I mean, if you are able to code your big, complicated
> puzzle in one of the more complex languages, why would really need a
> simpler language to do your simplier puzzles?
Maybe it's faster to write the simpler puzzles in Alan than it is in Tads,
or just easier. I've often heard it said that Tads makes complicated
programming techniques more simple than an "easier" system so maybe the
reverse also applies.
Adam Thornton
davidw <m...@dwhyld.plus.com> wrote:
>Maybe it's faster to write the simpler puzzles in Alan than it is in Tads,
>or just easier. I've often heard it said that Tads makes complicated
>programming techniques more simple than an "easier" system so maybe the
>reverse also applies.
Even if it does, though, structuring the callouts/callbacks between the
systems sounds like harder work than just implementing it all in the
more complex system. Really, if you're good at Alan, you can pick up
Hugo, or TADS, or Inform, without a great deal of effort. They're all,
if not isomorphic, at least kinda-sorta-similar. It's not like you're
jumping between FORTRAN, Forth, Lisp, Prolog, and APL, for instance.
Not to mention Intercal and Befunge.
Adam
John Colagioia
The only reason that comes to mind for me is possibly feeling too much
time has been invested in the existing codebase. If you have a
hundred-thousand line Alan game, and the key puzzle just isn't working
well, then the advice, "just translate your game to Inform (or TADS or
whatever)" might not be remarkably welcome.
If the languages were remarkably different (they're not, as you point
but if...), then there'd be some advantage there, as well.
Of course, one solution to this problem is the solution that big
chunks of the programming industry use. No, don't outsource to a
country with no minimum wage, wise-guy. Integrate and script, rather
than combine.
In the simplest case, I could envision a game getting to a tricky
point and saying, "go play the enclosed Z-code file, and input this
keyphrase at the first prompt," to direct you to the puzzle. Solving
the puzzle would give you the information you'd need to "finish" the
"puzzle stub" in the main game.
Of course, such an author would surely be hounded until his
(accelerated) dying days for making the player jump between five
different environments...
A more civilized author might try to hack a bunch of interpreters and
gamefiles together, though, and literally script between them. Then
there'd be a protocol to direct the player's actions (and a unified
interface), rather than the vile callout work you mention above (which
is annoying when the languages are as similar and simple as Pascal and
C).
Mary K. Kuhner
>> Surely the pain of implementing this and handling the glue between the
>> two is larger than the difficulty of learning one of the complex
>> systems?
>I would think so. I mean, if you are able to code your big, complicated
>puzzle in one of the more complex languages, why would really need a
>simpler language to do your simplier puzzles?
My experience, as an IF beginner learning Inform, was that there were
two sticking points.
The first one was getting *anything* to work at all, because there is
a bit of boilerplate that has to be right. The easiest solution turned
out to be using the sample game provided with Inform, and just
modifying it rather than making a new one.
The second one was coding hard stuff. Liquids, yikes! Animals!
Drastic scenery changes!
Using a simpler language may get you past the first hurdle, but that
wasn't really such a bad hurdle for me. (Admittedly I am a pretty
experienced programmer; I'd love to hear from IF authors who aren't.)
It won't get you past the second; in fact it may make things worse.
Okay, I lie. I did hit one Inform-specific ball of wax: having an
object that the PC may want to get onto/off of had a lot of boobytraps,
especially if "up" and "down" are desired as synonyms for "enter"
and "leave." This might have been easier in another language, I
don't know for sure.
Mary Kuhner mkku...@eskimo.com
Quintin Stone
> A more civilized author might try to hack a bunch of interpreters and
> gamefiles together, though, and literally script between them. Then
> there'd be a protocol to direct the player's actions (and a unified
> interface), rather than the vile callout work you mention above (which
> is annoying when the languages are as similar and simple as Pascal and
> C).
Big problem if the player doesn't have the second interpreter already
installed. I would say something about platform compatibility, but from
what I've seen the simpler game languages seem to only run on Windows
anyway.
Daniel Phillips
wrote:
(Hey, cool, I already got more responses as I was writing this! :-)
Please forgive any redunance that you might see.)
I agree, although I'm not sure about it being more difficult than
learning the complex languages (it's indeed a hassle, though). I
haven't tried this for myself yet. This is one of the difficulties
that I found with what I've proposed. And I think the logic that if
one can program a few complex puzzles, that person might as well learn
the other language for the complex puzzles is a very good point. I
follow davidw's thought, too, though.
But perhaps I can propose some what-ifs that may validate my idea?
- An author is happily coding away in a "simple" authoring system,
confident in its ability to handle the puzzles dreamed of for his/her
game. Many pages of good code and prose have been weaved. But as
with anything, ideas can be expanded or complicated. There turns out
to be one or two (out of 20 to 40) nagging puzzles that the simple
authoring system can't seem to handle well if at all. Another option
is, of course, to simply exclude the puzzle, simplify it, or take the
time to try to work it out.*
- There's a collaboration effort going on, but the majority of, or the
most active author(s), favor the "simpler" system. But they run into
a coding problem 30 pages through with a chessboard puzzle, which one
of the helpers that has just been giving ideas up to this point
happens to be able to code in another system. Rather than switch
systems all together, the author(s) writing in the simple system just
continues on without any further hair pulling, perhaps providing a
code word to unlock any other portions of the game, while the other
author unfamiliar with the simpler system just codes out the puzzle in
his or her own system.
* actually inspired in a way by Stephen Granade's article in XYZZY
News, "Interactive Fiction in Five Easy Years!" -
http://www.xyzzynews.com//xyzzy.8e.html . Thanks, Stephen, your
article actually gave me a *lot* of inspiration when I first read it
lately and years ago! :-) And while I'm giving credits here, I will
not neglect to point out C.E. Forman's article, "Game Design at the
Drawing Board" at http://www.xyzzynews.com/xyzzy.4e.html . And of
course there is Whizzard's guide which is lurking somewhere on the
'Net. Thanks, guys.
Stephen Granade
> On Fri, 10 Oct 2003 14:40:33 +0000 (UTC), ad...@fsf.net (Adam Thornton)
> wrote:
>
> * actually inspired in a way by Stephen Granade's article in XYZZY
> News, "Interactive Fiction in Five Easy Years!" -
> http://www.xyzzynews.com//xyzzy.8e.html . Thanks, Stephen, your
> article actually gave me a *lot* of inspiration when I first read it
> lately and years ago! :-)
Huh, cool. I'm glad you found it useful.
Stephen
--
Stephen Granade
ste...@granades.com
Joe Mason
It's pretty common in "real" programming to use a simpler language for
prototyping and just use the more complicated languages for the
difficult functions - Python folks swear by this, for instance. Often
you don't actually build glue between the two, you just prototype with a
scripting language and then rewrite it in C++.
But I'm not sure how much that would apply to IF, where a lot of the
difference between languages is in the standard library, not just the
details of syntax. The advantage of Inform and TADS over simpler
systems (dunno about Alan in particular) is that the world model is much
richer so it lets you approach the problems in a different way. I'm not
sure the two would even work well together if you could write a glue
layer.
An automatic translator (such as the one for the Scott Adams adventures)
might be a better way to go. Prototype in Alan, and then have a
translator that spits out well layed out Inform files that you can add
to with the more complicated stuff.
Joe
Norman Perlmutter
<bandi...@toppler.zworg.com> wrote:
My main concren is that this woud make the existence of puzzles too
obvious. I like to solve a good puzzle, but I like to feel like I'm
exploring the game world at the same time. I like the puzzles to blend
with the game, rather than feel separate from it.
Norman
Uli Kusterer
Joe Mason <j...@notcharles.ca> wrote:
> An automatic translator (such as the one for the Scott Adams adventures)
> might be a better way to go. Prototype in Alan, and then have a
> translator that spits out well layed out Inform files that you can add
> to with the more complicated stuff.
Plugh (http://www.plugh.info) would also be a nice example of this. It's a GUI tool to allow doing
the basic development of your game (laying out rooms, objects, actors),
and it spits out TADS code. You can even massage that to do the more
complex parts of your game, if you need more flexibility than the
built-in code editor lets you do.
Cheers,
-- Uli
http://www.zathras.de
John Colagioia
> On Fri, 10 Oct 2003, John Colagioia wrote:
>>A more civilized author might try to hack a bunch of interpreters and
>>gamefiles together, though, and literally script between them. Then
>>there'd be a protocol to direct the player's actions (and a unified
>>interface), rather than the vile callout work you mention above (which
>>is annoying when the languages are as similar and simple as Pascal and
>>C).
> Big problem if the player doesn't have the second interpreter already
> installed.
I wouldn't call it a *big* problem, any more than I'd call "most
people don't have an ADRIFT runtime" a problem. It's part of the
stuff you'd need to run the game.
Besides, if such a protocol existed (not that I'm advocating my
approach), combined interpreters that hide the protocol-y bits would
surely follow if the game were sufficiently good (or someone thought
it was a good enough idea for a weekend project).
> I would say something about platform compatibility, but from
> what I've seen the simpler game languages seem to only run on Windows
> anyway.
Plus, I've honestly never understood why that's necessarily the
horror it's often made out to be. Don't get me wrong. I *like*
programs that are nicely portable (as long as they keep to the
"local" user interface conventions, at least). I'm just not sure
it should be the priority it's often suggested to be.
After all, it's been many iterations through the question "can TADS
fit on my (insert name of small machine here)," and the answer has
almost always been "probably not." Yet there isn't a groan when
someone releases a TADS game.
Although, as I think about it, it occurs to me that there's still
probably an obvious solution to both problems: Include, in this
hypothetical inter-game protocol, an "interpreter test" message and
a "bypass puzzle" message.
In such a case, if the Z-Machine (for example) isn't present, the
coordinating program might (after implicitly saving the game) either
notify the user that the interpreter is missing and look for
guidance, or just skip the player past the puzzle with the
equivalent of a "win" verb (and mention that the puzzle was skipped).
Daniel Phillips
<ste...@granades.com> wrote:
>>
>> * actually inspired in a way by Stephen Granade's article in XYZZY
>> News, "Interactive Fiction in Five Easy Years!" -
>> http://www.xyzzynews.com//xyzzy.8e.html . Thanks, Stephen, your
>> article actually gave me a *lot* of inspiration when I first read it
>> lately and years ago! :-)
>
>Huh, cool. I'm glad you found it useful.
>
>Stephen
Yes. I don't know what it is about that article that keeps me
referring back to it many times. Come to think of it, have you
transferred your original notes to computer in some form other than
the game itself and would be willing to share? That would be
interesting to see--I'm always interested in seeing notes and word
scribbles to give me an idea how the creative design process goes.
David Thornley
John Colagioia <JCola...@csi.com> wrote:
>Quintin Stone wrote:
>> On Fri, 10 Oct 2003, John Colagioia wrote:
>>>A more civilized author might try to hack a bunch of interpreters and
>>>gamefiles together, though, and literally script between them. Then
That means that the author is providing the whole package, the game
bundled with two different interpreters and glue code, rather than
just a game file. That is a lot of code bloat, and may not be
appreciated by players without high-speed net access.
>>>there'd be a protocol to direct the player's actions (and a unified
>>>interface), rather than the vile callout work you mention above (which
>>>is annoying when the languages are as similar and simple as Pascal and
>>>C).
There isn't one. It would have to be argued about and implemented
by people who may not like the whole idea. I'm betting on the vile
callout work, sometimes between languages more different than C
and Pascal. Look, if there's no protocol between C and Pascal, why
would you expect one between zcode and whatever Alan uses?
>> Big problem if the player doesn't have the second interpreter already
>> installed.
>
>I wouldn't call it a *big* problem, any more than I'd call "most
>people don't have an ADRIFT runtime" a problem. It's part of the
>stuff you'd need to run the game.
>
The more you require to run a game, the fewer people who are going
to play it. The more a potential player has to do, other than
download an interpreter and use the installation process, the more
likely the player is to be discouraged.
Moreover, right now there are different interpreters on many systems,
and a given player is likely to prefer one, and will resent being
forced to use another.
>Besides, if such a protocol existed (not that I'm advocating my
>approach), combined interpreters that hide the protocol-y bits would
>surely follow if the game were sufficiently good (or someone thought
>it was a good enough idea for a weekend project).
>
Even given that this community is very much tool-happy, I think you
are overly hopeful here. Nor do I see that this is just going to
be a weekend project, even if the protocol is established (which
is *not* a weekend project). For this to happen, there would have
to be an awful lot of really good games.
>> I would say something about platform compatibility, but from
>> what I've seen the simpler game languages seem to only run on Windows
>> anyway.
>
>Plus, I've honestly never understood why that's necessarily the
>horror it's often made out to be.
Not a horror, but a limitation. This community uses very diverse
operating systems, and limiting to one (even a Microsoft one) is
going to exclude people.
>After all, it's been many iterations through the question "can TADS
>fit on my (insert name of small machine here)," and the answer has
>almost always been "probably not." Yet there isn't a groan when
>someone releases a TADS game.
>
The "small machine" in question is normally a PDA of some time, and
the general practice is that the PDA is not the main machine, so
the fact that language X doesn't run on PalmOS doesn't mean that
people can't play it: instead, it means that it is less convenient
for people to play it.
And, in fact, this is recognized as a disadvantage of TADS 2, and
there is interest in making a PDA version of TADS 3.
>Although, as I think about it, it occurs to me that there's still
>probably an obvious solution to both problems: Include, in this
>hypothetical inter-game protocol, an "interpreter test" message and
>a "bypass puzzle" message.
>
>In such a case, if the Z-Machine (for example) isn't present, the
>coordinating program might (after implicitly saving the game) either
>notify the user that the interpreter is missing and look for
>guidance, or just skip the player past the puzzle with the
>equivalent of a "win" verb (and mention that the puzzle was skipped).
>
I don't see this as contributing to player experience.
Now, let's look at the proposal.
The proposal is to allow games to be written in two languages,
one simple and one full-featured. I still don't see the utility
of this. A true software nerd does not usually mind writing
simple things in a complex language, and somebody who is not a
true software nerd usually doesn't want to learn more than one
language for a project. So, I see minimal benefit for the game
author here.
Assuming the tool-writers go ahead and implement everything
you suggest, it's still jarring for the player, who is playing
along in ADRIFT or Alan or whatever and is suddenly thrown into
an entirely different interpreter. Moreover, this is an extremely
flagrant clue that the puzzle is going to be complicated.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Thomas Nilsson
"Joe Mason" <j...@notcharles.ca> skrev i meddelandet
news:slrnboefs...@gate.notcharles.ca...
<snip>
>
> An automatic translator (such as the one for the Scott Adams adventures)
> might be a better way to go. Prototype in Alan, and then have a
> translator that spits out well layed out Inform files that you can add
> to with the more complicated stuff.
>
> Joe
The major disadvantage with this "generate from model/prototype" approach is
that the original source is no longer the source. This means that you will
have to "maintain" your original work in the second, more advanced,
language. Which brings us back to having to learn two langauges, use the
"easy" one for a while and at some point transfer to the "advanced" one,
losing the original advantage of an "easier" language.
To avoid forcing the author into "burning the bridges" (and make the
generation approach feasible) you really need a "round-trip" editing and
generation cycle. (Meaning that you can seemlessly go between the two
representations.) This has been tried in software modelling and programming.
(Generate your UML model into C++, edit the code and return to the model,
next time you generate your C++ editings should still be there.) But it
requires some kind of common ground, such as a common meta-model with formal
mapping and re-mapping of constructs. And if this is possible with two
languages, why do we need the more "advanced" language? Convenience? Speed?
Clarity?
I'd suggest talking to the author of the "easy" language and explain your
problem. Show him/her your puzzle and explain why you think it is
impossible/hard/inconvenient to do in the "easy" language. Suggest features
that would enable you to do the more complicated in the "easy" language. At
least I would really appreciate this type of concrete feedback on my
language (Alan, as if you didn't know...).
/Thomas
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 2003-10-09
Stephen Granade
> On Fri, 10 Oct 2003 22:58:11 GMT, Stephen Granade
> <ste...@granades.com> wrote:
> >>
> >> * actually inspired in a way by Stephen Granade's article in XYZZY
> >> News, "Interactive Fiction in Five Easy Years!" -
> >> http://www.xyzzynews.com//xyzzy.8e.html . Thanks, Stephen, your
> >> article actually gave me a *lot* of inspiration when I first read it
> >> lately and years ago! :-)
> >
> >Huh, cool. I'm glad you found it useful.
>
> Yes. I don't know what it is about that article that keeps me
> referring back to it many times. Come to think of it, have you
> transferred your original notes to computer in some form other than
> the game itself and would be willing to share? That would be
> interesting to see--I'm always interested in seeing notes and word
> scribbles to give me an idea how the creative design process goes.
I don't have those notes still available. I do have a whole sheaf of
notes regarding Losing Your Grip.