I have figured out how to create virtual spaces in Visual Basic 5 (taking
that language to an extremely advanced level) that you can walk around in.
It's more than just a theory--it's actual working code. I am working on the
"things" and "actors" in those spaces now. I am using objects and
collections to implement this, and reading and writing these collections to
disk. The work comes in two parts. One is the interpreter/game builder, and
two is the object file it uses. If I were to build an SDK for it, I would
probably not give out the VB5 code except by personal request. Instead, I
would give out the interpreter/game builder and one could use that to
generate the object file that "is" the game. If one wanted to actually get
into the heart of the intrepreter/game builder, then they would need the VB5
code and I could pass that on by request.
One of the biggest disadvantages over using my code versus Inform is that
with Inform you can do more than just create objects and set
properties--with Inform, you can have real code. However, since I don't have
the brainpower to write a compiler, I'm hardcoding the bag of game tricks
into the intrepreter and all you have to do is set properties on an object
file. To some, this is a major disadvantage. To others, this is a simpler
way to do things. For instance, I have to set a property on Place objects
so that you cannot enter a room without possessing some sort of object in
your inventory (known as the Inventory property of the Player object).
However, I've got a lot to do ahead--I want to allow the game author to be
able to implement complex things like shrinking rooms, elevators, spaceships
(moving vehicle-like spaces), time travel, sinking floors, etc.
In a sense, one could think of my design as like InstallShield Express IDE
versus InstallShield Pro IDE.
The interpreter "is" the IDE in my game design. In the intrepreter, at least
for now, you can type GODMODE XYZZY (instead of something "mortal-like" like
TAKE TREASURE) and you become a "god" of the object file. As god, you can
then create rooms simply by walking there (GO NORTH, etc.) and naming them,
defining certain properties, placing thing and actor objects inside, setting
properties on those things/actors, and moving on. When you switch back to
MORTALMODE, you can then become a "player" in the game. So far, the only
thing I have true about this GODMODE is in creation of places--things and
actors are yet to come.
From a VB programmer standpoint, one of the big breakthroughs for me is that
I have a property on the Place object (aka, Location, Space, by any other
nomenclature) for the object key of each adjacent Place object. BTW, if you
don't know VB, an object key doesn't mean like key to unlock door--it's a
hashing name like "key20324". So, for instance, in any Place object class,
you would see string properties for NorthPlace, SouthPlace, UpPlace,
DownPlace, WestPlace, and EastPlace, indicating the string key that the
interpreter would use to hunt down the other Place object.
I think what I'm trying to say here is that--yes--you can generate IF (and I
believe someday even very good IF) in advanced Visual Basic using objects
and collections. However, it is a mammoth task and it is best chewed off in
little bits rather than attacking the entire problem at once.
I am disappointed in that I don't have the brainpower able to generate
z-files directly from this. I like z-files in the fact that they are very
compressed (mostly due to ZSCII char set) and that they are almost the
defacto standard of the IF "industry". I looked into z-file formats however,
and found them too monsterously hard to implement from my code--the old char
set, the instruction set, etc. The question also comes to mind, "Why would
you even want to do that?" However, I think there is a large opportunity for
me to figure out how to convert my object files into Inform script (*.INF)
and then run them through the Inform compiler to make the z-files.
You know what to do to reply.
I'd like to encourage you in your efforts. A lot could be done to make IF
easier to write. You may not get a lot of encouragement here--not because
people don't like your ideas, but because they don't like your platform--and
I think what you're doing has a lot of potential.
I think the idea of a GOD mode in IF, whereby an author creates the game by
playing it, is a new one (for me, anyway) and has some interesting potential.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
I think it has potential too. A more recent development in the IF world
is a growing recognition of the need to complement the growing power of IF
systems with a more powerfull and intuitive way of designing them. Hence
all the IDE efforts, StoryHarp environment, etc. which all aim in some way
to make it easier to design IF.
Just remember that Visual Basic is Win95/NT only. Whilst PCs dominate in the
standard computing environments, Interactive Fiction by tradition has an
extremely wide computer base, and indeed within this newsgroup there is no
indication that the majority in fact own (or at least use by preference)
So when releasing a Windows only tool be carefull not to alienate those who
won't be able to use it.
Paul Gilbert | p...@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 5, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.
> I think the idea of a GOD mode in IF, whereby an author creates the game
> playing it, is a new one (for me, anyway) and has some interesting
Echo that here.
Send replies to username@service, where username is jonadab
and service is zerospam.com
Visit Jonadab's Domain: http://www.bright.net/~jonadab/
> <personal opinion>
> Just remember that Visual Basic is Win95/NT only. Whilst PCs dominate in
> standard computing environments, Interactive Fiction by tradition has an
> extremely wide computer base, and indeed within this newsgroup there is
> indication that the majority in fact own (or at least use by preference)
> So when releasing a Windows only tool be carefull not to alienate those
> won't be able to use it.
> </personal opinion>
A good measure in this regard would be to attempt to provide either an
interpreter other systems or a translater to another language. This would
allow the games to be played on other systems even if your design tools are
not supported by those systems. Just a suggestion, and I wouldn't
necessarily expect that sort of thing in version 1.0.
(Everything I write is my opinion, or I wouldn't write it.)
One of the many uses for peanut butter:
76. Donate massive amounts of it the the American Diabetes Association.
(Need more uses? see http://members.kconline.com/kerr/pb.htm)
It seems to be relatively new in the single-user IF area,
but it's been around for a long time in multi-user systems
such as MUDs and MOOs.
A traditional MOO has a set of meta-commands for creating
rooms and objects and setting their properties, but has
little or no programming capabilities.
MUDs (e.g. lpmud) tend to be much more programming-oriented.
POO (a Python MOO) is kind of a mixture. It has MOO-like
creation commands, plus the ability to add Python code
to objects to customise behaviour.
Although these systems can be described as create-by-playing
in the sense that creating and playing are carried out
hand in hand, there is still a clear distinction between
creating and playing. The creation commands are very
obviously meta-commands rather than actions performed
in the game universe, particularly where code-writing
I have some ideas for a true create-by-playing system,
based on a self-consistent system of game physics,
where all creation is done by actions within the
game universe. For example, to make a new room, you
obtain a shovel and dig, and to make a new object,
you have to find the raw materials and manufacture
What's more, I'd like it to be possible to create
objects with novel behaviour - something that in all
existing systems requires writing code. But in my
system it would be done by constructing mechanisms
which function according to the game physics.
To achieve this within the framework of a text
interface, I suspect the physics is going to need
a partially magical flavour. Perhaps mostly magical.
In any case, it will probably turn out to be quite
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
That's sort of like an idea I've been playing with myself lately for
MUDs... or rather a combination of this and the meta-commands for explicit
creation of things by the game administrators. The rest of the things,
including an implementation of dynamic building (if the need for a certain
business or something is determined in the area, the game world would
arrange to have one set up... though it will take time and the stages of
construction will show) controlled by the game world itself. This would
also come into play, say, if someone burned a building down. The game
world would arrange to have one set up in its place, perhaps not in the
exact same location, but nearby.
Brian Smith "Mr. Gideon... you're not
aval...@earthling.net paying attention..."
- Eric Draven, The Crow
You'd still want a "God" mode to allow the determination of where the
raw materials were, wouldn't you?
> What's more, I'd like it to be possible to create
> objects with novel behaviour - something that in all
> existing systems requires writing code. But in my
> system it would be done by constructing mechanisms
> which function according to the game physics.
> To achieve this within the framework of a text
> interface, I suspect the physics is going to need
> a partially magical flavour. Perhaps mostly magical.
> In any case, it will probably turn out to be quite
I'd be interested to see something like this. (I'd pay $50 for one!)
Is this going to be a fantasy game, then? I can't imagine how one would
"find" the raw materials to build, say, an Oldsmobile, unless you also have
to develop a society and an infrastructure capable of large-scale mining,
smelting, and manufacturing. To say nothing of the chemical processes that go
into creating the rubber for the tires.
Of course, no problem if it's just a matter of spears and hatchets.
> It seems to be relatively new in the single-user IF area,
> but it's been around for a long time in multi-user systems
> such as MUDs and MOOs.
The first I think was "monster". TinyMUD appears to have been based
largely on that, with almost no resemblance to the original MUD (which
only allowed wizards to create areas). TinyMUD evolved (devolved?)
into a whole gaggle of odd non-MUD-like systems, ranging from slight
variants to the building style, to things with whole programming
languages, to inexplicably popular things that were difficult to use.
What they all allowed, was for any J. Random Player to start adding
lots of rooms and objects. The overwhelming majority of time, this
resulted in crap. Very few bothered with good descriptions, and even
fewer kept any coherence with the surroundings (one of the first
variants was to limit the amount one could build). Most of the places
ended up with one or two rooms that almost everyone hung out in. They
devolved into social chat rooms or roleplaying arenas (the sort of
roleplaying where you have to imagine everything, you roleplay normal
everyday events). The biggest cause of the decline is the inherent
lack of editorial control.
Their resemblance to IF is minimal.
Things that evolved from the original MUD are much more IF like, but
they didn't allow "create-by-playing". (note that many of these had
little editorial control also, and their quality suffered as a result)
In general, I think that mass collaboration results in a surreal mess.
Doing this single-player might actually be an improvement.
Probably, but it would be used extremely rarely.
Maybe only initially, to set the universe up with
a generous supply of whatever is necessary.
> I can't imagine how one would
> "find" the raw materials to build, say, an Oldsmobile, unless you also have
> to develop a society and an infrastructure capable of large-scale mining,
> smelting, and manufacturing.
I've no intention of trying to model real-word physics
anywhere near this accurately, for obvious reasons!
In my system (if it ever gets implemented) it will, most
likely, be possible to construct an Oldsmobile, but it
will be done in a way almost, but not quite, entirely
unlike the way it would be done in the real universe.
One of the "fantastic" characteristics of my universe
is that an object's appearance doesn't necessarily have
anything to do with it's properties. When you construct
a new object, its properties depend on the steps you
carry out to construct it. But you get to specify any
appearance (i.e. description string) that you like.
Physically, the Oldsmobile would be just a large,
mobile container with some form of motive power. To
build it you would need one or more objects providing
enough mass, a tool capable of reshaping other objects,
and maybe some other things. Maybe "mobility" would be
a primitive property, in which case you would need a
tool capable of imparting it. Then you would add a
description saying that it's a "Lovely old vintage
car" or whatever purple prose takes your fancy.
It's all rather less than half-baked so far...
The second thing is that I'm standardizing on the interpreter. I am putting
down framers on what the 1.0 interpreter supports, how it works, and what
the source code looks like. I plan to make the source widely available when
I'm at that point.
So far, things are going very well. I have a world of places, things, and
actors and I'm now adding properties on them that make the game "work". You
can walk around and build this world, then save it to disk, call it back,
add more, etc.
You know what to do to reply.
Paul Francis Gilbert wrote in message
This will be done, I suspect, because my system will be documented
thoroughly and all code is open source. Plus, if anyone is thinking of
porting my 1.0 interpreter to another system, I will give them extensive
email support for free. (call me crazy)
The IDE could be rewritten in hundreds of different ways as long as they all
read and write the same HTML-like file. In fact, I'm going to provide 2 IDEs
as an example. One will be built into the interpreter (where you can switch
it to God mode) and the other will look sort of like an Explorer window.
This IDE could be implemented on many different platforms.
As for the player, I think once people see my body of work in VB, they could
easily port it to another system if they know another system.
I'm doing this simply because it's a tough programming challenge for me and
has a lot of rewards in fun. It's a nice diversion from my programming day
job--where everything is so serious and hush-hush.
You know what to do to reply.
Jonadab wrote in message <01bd9f0d$5357dbe0$LocalHost@jonadab>...
I don't know what MOO's you've been using, but LambdaMOO, possibly the
most famous of them all, has a superb, elegant programming language based
around lists. Looks rather C-like. It's object oriented and is perfect for
MOO programming. You could do complex IF with ease in it.
Hmm... that's an idea. Write a cut-down, one-player LambdaMOO database,
and then write IF for it. Distribute the database, run it on any port of
the LambdaMOO engine...
> okbl...@usa.net wrote
> > I think the idea of a GOD mode in IF, whereby an author creates the game
> > playing it, is a new one (for me, anyway) and has some interesting
> Echo that here.
> > okbl...@usa.net wrote
> > > I think the idea of a GOD mode in IF, whereby an author creates the game
> > by
> > > playing it, is a new one (for me, anyway) and has some interesting
> > potential.
> > >
In fact, it has been done, more or less. I remember an online game
back when there were a lot of local dial-up BBSes, where you could do
that. It wasn't fantastic, but every player could make their own rooms,
simple objects, lock and keys, and describe things however they wanted to.
Total chaos could be prevented by disallowing players "digging" new rooms
in locations intended to be static. Of course, inter-object interaction
was virtually non-existant, and it wasn't one of those things anyone
played a lot.
> I also like the idea of a GOD mode in IF. Another interesting possibility
> would be to make it sort of interactive, so that the author and a beta tester
> could sit down and, as the beta tester tried things, the author could enter
> the responses, and have them become part of the code. I guess I'm
> specifically thinking about interaction between the player and non-player
> characters here, but it could be extended to other aspects as well.
I don't know if I can really see that being a present-day reality of
automation-- but it could be a good way to perform a rapid prototype of
incomplete sections of the game, and an aid to the author in designing the
game, if he remembers to save the script.