Glk Hugo beta materials
David A. Cornelson
>For the time being, while I'm making relatively frequent updates to the Glk
>Hugo source (and Win32 executables), instead of uploading them to
ftp.gmd.de
>and constantly bothering Volker and David, they can be found at
>
> http://www.geocities.com/hollywood/academy/5976/glk
>
>as "glksrc.zip" (the source) and "hugo25glk.zip" (Win32 executables).
>
>Last night's archives are there now.
Kent,
You're obviously a very talented programmer and not terribly afraid of
Windows either.
I'm curious. You built the Win32 debugger for Hugo, which I have to admit is
pulling me towards switching from Inform. Is there any chance you may extend
this to an IDE with syntax checking and highlighting as well as instant
compiles?
I think it's the next logical step in Hugo and would likely bring a ton of
people into the Hugo world that would normally choose Inform.
Just curious.
Jarb
Kent Tessman
Hugo source (and Win32 executables), instead of uploading them to ftp.gmd.de
and constantly bothering Volker and David, they can be found at
http://www.geocities.com/hollywood/academy/5976/glk
as "glksrc.zip" (the source) and "hugo25glk.zip" (Win32 executables).
Last night's archives are there now.
--Kent
_____
Kent Tessman
The General Coffee Company Film Productions
http://www.geocities.com/hollywood/academy/5976/
David A. Cornelson
>David A. Cornelson (dcorn...@placet.com) wrote:
>
>> Another thing I've wanted to see is the ability to write a game that
needs
>> more than one console to play. Multiple PC's. with the internet and the
>
>So, what *should* an IF interprocess API do?
>
Is there anyway to build it so that there is a standard 'container' that is
send and received? Then the interface or middleware (TCP/IP, Serial,
LAN/WAN) is just a separate piece if code that can be implemented by
different people for different servers and clients.
For instance...
Linux TCP/IP Server could accept information from a Win32 TCP/IP client
Win32 Lan Server could accept information from an Apple Lan Server client
Then, each of these pieces of code would be on top of the glk interface to
either the
hosting IF server or the IF client(s).
Jarb
Kent Tessman
>
>Kent,
>
>You're obviously a very talented programmer and not terribly afraid of
>Windows either.
>
>I'm curious. You built the Win32 debugger for Hugo, which I have to admit
is
>pulling me towards switching from Inform. Is there any chance you may
extend
>this to an IDE with syntax checking and highlighting as well as instant
>compiles?
>
>I think it's the next logical step in Hugo and would likely bring a ton of
>people into the Hugo world that would normally choose Inform.
Thank you for the kind words. (Although obviously credit for the clean and
easy implementation of the Glk library for Win32 goes to David Kinder.)
I've toyed with the idea of extending the debugger core (i.e., not just
Windows, but DOS and whatever other debugger ports there are or will be) to
include IDE features like those you mention. I've received varying
responses to this idea. A lot of people like their editor and might be
loathe to use an IDE that doesn't provide enough (or even the same)
features. (I, for example, use UltraEdit for almost everything--including
djgpp development debugging with RHIDE and LCC-Win32 under WEdit--although I
do use VC++'s IDE because it provides enough features.)
An alternative might be to develop one or more plug-ins for editors such as
UltraEdit in order to integrate Hugo more fully into them. That would allow
Hugo programmers to use whatever editing features, syntax-coloring, etc.
their editor of choice provides.
But to do a full(er) IDE would be more of a challenge, and therefore
potentially more fun for me, so that has its appeal.
I'm open to comments/opinions/suggestions.
--Kent (who says you can program in Windows and still be afraid of it)
David A. Cornelson
"Kent Tessman" <tes...@remove-to-reply.interlog.com> wrote:
> David A. Cornelson wrote in message <79617b$4...@newsops.execpc.com>...
> >
Yerwelcome...
> I've toyed with the idea <snip>
> A lot of people like their editor and might be loathe to use an IDE that
> doesn't provide enough (or even the same) features.
I use UltraEdit too, but a new interface is part of the challenge!
> An alternative might be to develop one or more plug-ins for editors
If people want to use UltraEdit, let them, but new development should come
from the Hugo foundation.
As far as a wish list is concerned, I'd like to see the following:
- Windows for Objects, Properties, Attributes that associate to each other.
For instance, if I look up the Kitchen in the Object Browser, it will have
two branches, Properties and Attributes. If I click on Properties, I get a
list of coded proerties in bold text and uncoded properties in plain text.
Same for Attributes.
- Source Level Debugger. Obviously, it would be awesome to step through the
source and be able to change things on the fly. Also, at any given point,
the Object Viewer should display the current 'state' of Attributes,
Variables, Daemons, etc.
- Syntax checking (and highlighting, but less important). As Microsoft does,
add a line-level syntax checker that tells you if the statement you entered
is correct. I would even force statements to have all caps or start with a
cap, or all lowercase depending on user preferences.
I guess highlighting helps for class, object, property, and attribute names.
------
Another thing I've wanted to see is the ability to write a game that needs
more than one console to play. Multiple PC's. with the internet and the
ability to host games so easily, I would think it wouldn't be impossible to
write a Hugo Server and Hugo clients. This is would take IF to a whole new
arena of interaction. I know the muds are good for this, but it would be nice
if you didn't necessarily need a whole 'mud' to build a multiple PC game.
Jarb
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Andrew Plotkin
> Another thing I've wanted to see is the ability to write a game that needs
> more than one console to play. Multiple PC's. with the internet and the
> ability to host games so easily, I would think it wouldn't be impossible to
> write a Hugo Server and Hugo clients. This is would take IF to a whole new
> arena of interaction. I know the muds are good for this, but it would be nice
> if you didn't necessarily need a whole 'mud' to build a multiple PC game.
This has come up a few times. It's always sort of been in the back of my
mind as something to add to Glk, when I had time to get around to it.
Everyone's sure it would be a Neat Idea. *I'm* sure it would be a Neat
Idea. On the other hand, that doesn't tell me much about what to
implement.
So, what *should* an IF interprocess API do?
A plain stream, or should you specify a block of data with length? The
latter makes messaging code really easy. The former would make it really
easy to write a MUD server, which people could connect to with existing
telnet or mud-client programs. Or I could require both, which is
additional complication (and I hate complication.)
What's the connection strategy? The easy path is to always use TCP/IP, so
that you connect to a (machinename,port) pair. On the other hand, Jacob
Munkhammar has suggested allowing LAN communication as well. I don't know
much about that. Then there's modem/serial port stuff, which is another
whole set of headaches. Allow any or all of the above?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Eric Hoffman
What's the connection strategy? The easy path is to always use TCP/IP, so
that you connect to a (machinename,port) pair. On the other hand, Jacob
Munkhammar has suggested allowing LAN communication as well. I don't know
much about that. Then there's modem/serial port stuff, which is another
whole set of headaches. Allow any or all of the above?
in this age and for this application there really isn't much excuse to
use anything but garden variety TCP. Media technology changes, and the
only reason to tie an application closely to it (and accept the loss
of quasi-ubiquitous connectivity) is to match some explicit performance
requirement
a far more interesting issue is how to create something which is both
multiplayer and works as a coherent piece of interactive fiction..the
world doesn't need more muds in the current style.
David A. Cornelson
> >
In regards to Multiple PC IF...
I was thinking about this last night...
What would the code look like and how would it 'work'?
Well, the server program would need to know how many PC's there were and wait
for all PC spots to be filled.
For instance:
I connect to MultiPCSampleGame and see...
******** Sample Transcript *********
MultiPC Interactive Fiction
SampleGame
What is your name or handle? Jarb
There are three player character's in this game (choose one):
1) A monkey
2) A chicken
3) A lion
> 1
Waiting for monkey and chicken to join....
Telling ddyte that Jarb is the monkey....
ddyte selects chicken...
Waiting for lion to join....
Telling whizzard that Jarb is monkey and ddyte is chicken and whizzard is lion
Game loading...
******** End Transcript *********
Okay. So how would we code this?
My guess is that we would have to define each PC...I'm using Inform syntax
since that's what I'm familiar with...
Object monkey "monkey"
with name 'monkey'
description "Small hairy thing...",
has playercharacter;
Object chicken "chicken"
with name 'chicken'
description "Small feathery thing...",
has playercharacter;
Object lion "lion"
with name 'lion'
description "Large hairy thing...",
has playercharacter;
Now we need to have separate loading procedures...how would this work? Would
we have a property associated with the playercharacter item that handles
loading? Probably...the first connect loads the normal 'Initialise' routine
and when all PC's have connected, is completed for each player. Then,
individual processing, such as setting PC's initial location and other PC
setup code would be in the PC object....
Object monkey "monkey"
with name 'monkey'
description "Small hairy thing...",
main [; location=tree; ],
has playercharacter animate;
Object chicken "chicken"
with name 'chicken'
description "Small feathery thing...",
main [; location=field; ],
has playercharacter;
Object lion "lion"
with name 'lion'
description "Large hairy thing...",
main [; location=forest; ],
has playercharacter;
Continued in Next Post
David A. Cornelson
"David A. Cornelson" <dcorn...@placet.com> wrote:
> Andrew Plotkin wrote in message ...
> >David A. Cornelson (dcorn...@placet.com) wrote:
> >
Next step is howto handle each turn for players...
If I'm the monkey and I get out of the tree, do I have to 'wait' for the
chicken and lion to do something before my turn ends? That would be a pain. So
the answer is no, my turn continues and I drop down to the forest where the
lion is. In a sense, the lion and chicken have 'lost' a turn or have been
automatically given a 'wait' command.
Then there's the consequence of the Before and After routines.
The monkey made the move so its After will execute first.
Then, it's not appropriate for the lion's Before routine to get executed
because you may want different behavior its own commands, than behavior for
'reactions'.
So there needs to be a new property...React_When, which is executed after a
different PC's turn ends....but how to print different messages for the lion
and monkey comes up too....
Object lion "lion"
with name 'lion',
description "A large hairy creature",
main [; location=forest; ],
react_when [; if (monkey in location) {
send kill_monkey_routine to monkey.terminal;
send monkey_screams_routine to chicken.terminal;
"A monkey drops from the trees and into your waiting
paws...yummm!";
}
],
has playercharacter animate;
[ kill_monkey_routine;
dead_flag=1;
"A lions knocks you down with a large claw and eats you! You're dead!";
];
[ monkey_screams_routine;
"You are hear a loud scream from the forest, apparently a monkey
being eaten by a lion.";
];
It adds a level of complexity to writing even a simple game, but it be fun to
do this!
Zarf? Graham? Kent? Mike?
Andrew Plotkin
> Andrew Plotkin wrote in message ...
> >David A. Cornelson (dcorn...@placet.com) wrote:
> >
> needs
> >> more than one console to play. Multiple PC's. with the internet and the
> >
> Is there anyway to build it so that there is a standard 'container' that is
> send and received? Then the interface or middleware (TCP/IP, Serial,
> LAN/WAN) is just a separate piece if code that can be implemented by
> different people for different servers and clients.
>
> For instance...
>
> Linux TCP/IP Server could accept information from a Win32 TCP/IP client
> Win32 Lan Server could accept information from an Apple Lan Server client
Of course, "Apple LAN" is probably AppleTalk, which bears no relation to
whatever Windows thinks is a LAN. :)
I'm tending to agree with the opposition here, that everybody can use TCP
and like it. At least as the "standard option". Might leave room in the
interface for other connection methods, but I wouldn't spend time
implementing them.
Andrew Plotkin
> If I'm the monkey and I get out of the tree, do I have to 'wait' for the
> chicken and lion to do something before my turn ends? That would be a pain. So
> the answer is no, my turn continues and I drop down to the forest where the
> lion is. In a sense, the lion and chicken have 'lost' a turn or have been
> automatically given a 'wait' command.
> Then there's the consequence of the Before and After routines.
> So there needs to be a new property...React_When, which is executed after a
> different PC's turn ends....but how to print different messages for the lion
> and monkey comes up too....
I'd think you'd go nuts trying to implement this as three separate
single-player libraries hooked together. Your use of "dead_flag", for
example.
Use the standard model; actions and routines, as usual. Instead of the
normal print statement, have the MUD-like variety:
print_near(actor, str);
print_near_2(actor, str, str2);
print_near_3(actor, actor2, str, str2, str3);
Plus a few more to print in different rooms, for long-range effects.
The rest looks semantically like what you have, but I dunno about this
terminal and routine business. Move objects around and print.
Also, this is all well above the level of Glk and the VM. Glk lets you
send packets of data. The rest is your problem. :)
Iain Merrick
[...]
> Use the standard model; actions and routines, as usual. Instead of the
> normal print statement, have the MUD-like variety:
>
> print_near(actor, str);
> print_near_2(actor, str, str2);
> print_near_3(actor, actor2, str, str2, str3);
>
> Plus a few more to print in different rooms, for long-range effects.
>
> The rest looks semantically like what you have, but I dunno about this
> terminal and routine business. Move objects around and print.
>
> Also, this is all well above the level of Glk and the VM. Glk lets you
> send packets of data. The rest is your problem. :)
Instead of message-passing, why not just have a nice simple
client-server model for Glk? The server would run the game itself; the
clients would just be dumb 'Glk terminals'.
As far as the server is concerned, each client would just be another Glk
window; it could split these windows in the usual way, and add text and
wait for input and so on. (The current spec is flexible enough that
programs can handle multiple inputs, IIRC.)
It wouldn't be trivial to implement, but the API wouldn't have to change
very much: perhaps a couple of functions and callbacks to handle the
opening and closing of connections.
True distributed programs could be handled on a different layer; in
fact, I don't see that program-to-program communication has to be
handled by Glk at all. At most, Glk should offer a very low-level
message-passing system (low-level enough that it could be used to build
a _non_-message-passing system without too much overhead.)
--
Iain Merrick
Andrew Plotkin
> > Also, this is all well above the level of Glk and the VM. Glk lets you
> > send packets of data. The rest is your problem. :)
> Instead of message-passing, why not just have a nice simple
> client-server model for Glk? The server would run the game itself; the
> clients would just be dumb 'Glk terminals'.
Because it's really easy to write client-server on top of message-passing.
But you can't write general message-passing on top of client-server.
> It wouldn't be trivial to implement, but the API wouldn't have to change
> very much: perhaps a couple of functions and callbacks to handle the
> opening and closing of connections.
API change is not a useful metric of difficulty.
Iain Merrick
> Iain Merrick (i...@cs.york.ac.uk) wrote:
> > > Also, this is all well above the level of Glk and the VM. Glk lets you
> > > send packets of data. The rest is your problem. :)
>
> > Instead of message-passing, why not just have a nice simple
> > client-server model for Glk? The server would run the game itself; the
> > clients would just be dumb 'Glk terminals'.
>
> Because it's really easy to write client-server on top of message-passing.
> But you can't write general message-passing on top of client-server.
Okay, I guess the client-server model could fit in a layer above the
message-passing model. But it would be nice if it was at least a
_standardised_ extra layer, because:
- (I think) the client-server model would be easy to use, and flexible
enough for most IF-style tasks.
- with a standardised client/server system, the same Glk client could be
used to connect to arbitrary Glk server programs (as long as they follow
the standard).
> > It wouldn't be trivial to implement, but the API wouldn't have to change
> > very much: perhaps a couple of functions and callbacks to handle the
> > opening and closing of connections.
>
> API change is not a useful metric of difficulty.
Well... not for the library implementor, certainly.
Andrew Plotkin
> Okay, I guess the client-server model could fit in a layer above the
> message-passing model. But it would be nice if it was at least a
> _standardised_ extra layer, because:
> - (I think) the client-server model would be easy to use, and flexible
> enough for most IF-style tasks.
> - with a standardised client/server system, the same Glk client could be
> used to connect to arbitrary Glk server programs (as long as they follow
> the standard).
I agree with this. However, if the standard can be implemented in portable
code on top of a non-portable layer, I say keep them separate and
distribute the portable code from a single source. Particularly if the
amount of code is small -- then it's a cut-and-paste FAQ, rather than
several people trying to work to a standard.
One possible such client-server standard, BTW, is more-or-less-telnet.
Text goes in, text comes out. If the underlying API allows it (which I'm
still thinking about), people could actually use MUD clients or Glk
clients (or write MUD clients in Glk, for that matter!)
I'm not throwing any weight behind this, just suggesting it.
> > > It wouldn't be trivial to implement, but the API wouldn't have to change
> > > very much: perhaps a couple of functions and callbacks to handle the
> > > opening and closing of connections.
> >
> > API change is not a useful metric of difficulty.
>
> Well... not for the library implementor, certainly.
One core observation I made going into this, way back: the library
implementor is the bottleneck. And the compiler implementor, if there is
such a thing. You can always find people willing to use a feature, even if
it's persnickety and painful, as long as it's actually *implemented*.
Erik Hetzner
> I'd think you'd go nuts trying to implement this as three separate
> single-player libraries hooked together. Your use of "dead_flag", for
> example.
Without a doubt.
> Use the standard model; actions and routines, as usual. Instead of the
> normal print statement, have the MUD-like variety:
> print_near(actor, str);
> print_near_2(actor, str, str2);
> print_near_3(actor, actor2, str, str2, str3);
Or, for example:
Propogate (eat, cookie);
And have propogate a big fancy function that figures out who ought
to know that Joe has eaten a cookie.
> The rest looks semantically like what you have, but I dunno about this
> terminal and routine business. Move objects around and print.
> Also, this is all well above the level of Glk and the VM. Glk lets you
> send packets of data. The rest is your problem. :)
I'll have to read more of the Glk spec. But something like this is possible
even with Inform; though one would have to hack together some sort
of system for output streams besides the screen and transcript (though
using the transcript would allow for a primitive second player
input/output stream).
--
Erik Hetzner <e...@uclink4.berkeley.edu>
David A. Cornelson
>Andrew Plotkin <erky...@netcom.com> wrote:
>> I'd think you'd go nuts trying to implement this as three separate
>> single-player libraries hooked together. Your use of "dead_flag", for
>> example.
>
>even with Inform; though one would have to hack together some sort
>of system for output streams besides the screen and transcript (though
>using the transcript would allow for a primitive second player
>input/output stream).
>--
I'd just like to add that my examples for multiple PC IF were just ideas.
Don't get into the details. I was just trying to show some code. The
functionality we all agree on is that there needs to be some way to send
logic to different PC's and handle the input/output streaming well.
Erik, you sound like you could actually do this. For a test, is there anyway
to make a simple Inform game that could handle two PC's?
Jarb