Budding IF Engine Author (With A Few Questions...)
Steven M. Castellotti
few
months (as both part of a Software Engineering project as well as a
personal dream-realization kinda thing) and am growing very near a
public
release. I just had a few questions, and hoped that someone might be
kind
enough to point me in the right directions.
First some quick information about my Engine:
Name : The Cycon Online Gaming Engine (The COG Engine)
License : GPL (Freely redistributable and modifyable source code)
Language : Java
Environment : Applet-based, so it will run in under any Java-Capable
Browser
Format : Text/Graphics Mixed, All Text, or All Graphical
Programming Format : Series of text files, one for basic game
infomation,
one for room objects, one for item objects, on for obstruction objects,
and one for events.
The initial gamestate is set up through the first four files, and events
which modify that environment. For example:
Combine Item[Rope] with Item[Hook] -> Adds Item[Grappling Hook] to
Inventory;
Split Item[Grappling Hook] -> Adds Item[Rope] to Inventory and Adds
Item[Hook] to Inventory;
Use Item[Grappling Hook] on Obstruction[Rope Bridge (Broken)]
(Requires CurrentRoom Room(116)Direction[East]) ->
Removes Obstruction[Rope Bridge (Broken)] from Room(83)Direction[West]
and Removes Obstruction[Rope Bridge (Broken)] from
Room(116)Direction[East]
and TextMessage [You swing your grappling hook out and down towards the
broken rope bridge
swaying in the wind. The hook catches on your target and you begin to
haul the line in.
When you can finally reach the end of the bridge, you grab it and
firmly
tie it back onto
the post on this side of the cliff. You shouldn't have any trouble
crossing the bridge anymore.];
...and so on.
1) After perusing through various messages on this list and through
various web pages, it has occured to me that I'm certainly not the first
person to think of designing and developing their own IF Compiler/Gaming
Engine. Besides the fact that I will be handing in the inital version as
my Software Engineering project at my university, I am wondering whether
am I wasting my time. I have already put a great deal of time into this
project (it is far more a personal goal than an academic persuit) but
considering the vastness and wide availablity of other engines, would I
be
better off contributing my time and effort to another, well established
project?
2) As my project will be released under the GPL, it will be an
open-source
endeavor, with a development team consisteing of anyone interesting in
participating. This is very important to my goal. Is anyone aware of any
similar projects, in which the source code is available for other
developers to incorporate into their own projects without oweing
royalties
to the orginal author?
3) Can anyone at least suggest an Engine or two that I might be able to
look at and refer to from a design perspective? I am starting from
scratch
here, and though I feel that I've come up with a pretty rugged design so
far, I feel that I would benefit from seeing what others have already
produced. I have so far heard the names INFORM, TADS, HUGO, and ALAN
mentioned repeated, and will begin looking at those engines, but since
my
design is more along the lines of an online Java Applet, the language
and
overall goal of my project appears considerably different from such
projects (although I must admit that I have only begun the most cursory
glance over those projects).
Any comments would be appreciated. When the project becomes
stable
enough for public release, I will make it a point to post the
announcement
on this list. I am looking at another month, perhaps two before that
will
happen. Anyone interested in more information, feel free to reply with a
request by email, so as to not clog up the list with an off-topic
discussion.
Thank you for your time.
-Steven M. Castellotti
Ste...@innocent.com
TenthStone
<Ste...@Innocent.com> wrote:
>Hello all, I've been working on my own IF Engine for the past few
>months.
>3) Can anyone at least suggest an Engine or two that I might be able to
>look at and refer to from a design perspective? I am starting from
>scratch here, and though I feel that I've come up with a pretty rugged design
>so far, I feel that I would benefit from seeing what others have already
>produced. I have so far heard the names INFORM, TADS, HUGO, and ALAN
>mentioned repeated, and will begin looking at those engines, but since
>my design is more along the lines of an online Java Applet, the language
>and overall goal of my project appears considerably different from such
>projects (although I must admit that I have only begun the most cursory
>glance over those projects).
An interpreter for Infocom's ZIP portable code format, which is that
produced by Inform, has been ported to the web via Java:
http://www.pond.com/~russotto/zplet/ifol.htm
and is in all likelihood going to be your best source. For basic IF
requirements and modeling, the four engines you mention should
be sufficient.
On a more opinionated note, I think your efforts are noteworthy.
However, if one of the requirements of your project is that it gains
at least 10 users, you may have to wait awhile and put a lot more work
into it. Even then, you might only have a user base of one.
Every new system needs an attraction, something to pull people to it.
If you want to be original, there are at least three fields open at
this time:
1. Natural language compilation. Takes English and turns it into
code. This is well-nigh impossible.
2. Natural language parsing. Even if it were written in a completely
different system, your ideas on taking standard English and adapting
it into a command that the game can understand would be well
appreciated.
3. GUI development. A powerful, simple system for writing IF in a
GUI environment; whether the work itself would be graphical or not
could be optional.
All of these relate to ease of use, either for the writer or for the
reader. All of these would be extremely difficult.
For a longer, more humourous IF wishlist consult
ftp://ftp.gmd.de/if-archive/programming/RAIF-POOL.announce
Steven M. Castellotti
> However, if one of the requirements of your project is that it gains
> at least 10 users, you may have to wait awhile and put a lot more work
> into it. Even then, you might only have a user base of one.
Well, I must admit that I have certainly considered this, and
will
not be terribly dissapointed if this ends up being the case. Just the
same, I have a great deal of vision for this project, and the very act
of
learning how to work in certain feature would be enough of a benefit for
me. If the Engine develops a following, that would certainly be an added
bonus, but I think that I would be simply satisfied in knowing that I
had
acheived a personal dream...
> Every new system needs an attraction, something to pull people to it.
> If you want to be original, there are at least three fields open at
> this time:
>
> 1. Natural language compilation. Takes English and turns it into
> code. This is well-nigh impossible.
Agreed. I wouldn't even want to attempt anything on such a
level.
> 2. Natural language parsing. Even if it were written in a completely
> different system, your ideas on taking standard English and adapting
> it into a command that the game can understand would be well
> appreciated.
I feel that I have already achieved this goal. As I've said
before, game creation for my engine simply involves the creation of five
individual text files, in accordance to a special format, very much like
filling out a series of forms. The first one specifies game information
about the game's setup (such as the game's name, the default settings
for
the player such as points and health, and the location of graphics for
the
compass, etc.). The next three files describe the various rooms, items,
and obstructions and their positions in the environment when the game
begins. Finally, the "Events" file is the real meat of the game. The
Events file describes what sort of actions the player can make in the
game, the effect that it has, and what requirements must be met. This
may
sound somewhat complicated, however I think a few examples from my own
game would be more than sufficient to illustrate my ideas:
From the Rooms file:
Room # : 1
Room Name : Beachfront
GraphicURL : http://hawk.vill.edu/~s99g02/COG/Images/Cycon-Room(001).jpg
Text Description (Long) : You are standing on a large beachfront. In
front
of you
lies a huge forest with a wide assortment of trees, including a few
abnormally
large ones. You notice that the western portion of this island is made
up
of a
series of cliffs and rocky terrain.
Text Description (Short) : You are on a beachfront.
Direction Description : You can see a shady spot to under a tree the
NorthWest, a
forest starts to the NorthEast, and the beach extends both SouthWest
and
SouthEast.
There is also a path that leads into the forest to the North.
Directions : North(8), NorthEast(3), NorthWest(5), SouthEast(2),
SouthWest(4)
Directional Object : North
Transition (Text) : As you walk into the forest, you're eyes take a
moment to
adjust to the dim light.
From the Items file:
Item # : 1
Item Name : Dagger
Aliases : Knife
Environment GraphicURL :
http://hawk.vill.edu/~s99g02/COG/Images/ItemTemplate(Green).jpg
Environment Graphic Coordinates (X,Y) : 200, 400
Text Description : This dagger is heavier than you might expect; it
seems
to be made of a strong and
smooth metal that is a blueish-grey and does not shine, unlike any you
have ever seen before. The grip
is wrapped in some sort of animal hide. This dagger feels very good in
your hand.
Notes : Found under the rock in room #7
Item # : 2
Item Name : Rock
Aliases : Stone
Environment GraphicURL :
http://hawk.vill.edu/~s99g02/COG/Images/ItemTemplate(Green).jpg
Environment Graphic Coordinates (X,Y) : 200, 400
Text Description : This is a normal rock, not different from the many
others laying around this area.
Location : Room(7)
Notes : Dagger is underneath the rock.
As a quick note, in the current version of the Engine "obstructions" are
defined as anything that prevents movement from one room to another.
This
would include enemies as well as physical objects. From the Obstructions
file:
Obstruction # : 1
Obstruction Name : Savage
Environment GraphicURL :
http://hawk.vill.edu/~s99g02/COG/Images/ObstructionTemplate(Red).jpg
Environment Graphic Coordinates (X,Y) : 190, 170
Text Description : This crude, fierce looking individual appears to have
every intent of killing you.
Type : Antagonist
Locations : Room[Savage]Direction[West]
Visible : Yes
Notes : Use the Dagger to kill him, and he will leave the Bow behind.
Obstruction # : 3
Obstruction Name : Boulder
Environment GraphicURL :
http://hawk.vill.edu/~s99g02/COG/Images/ObstructionTemplate(Orange).jpg
Environment Graphic Coordinates (X,Y) : 190, 170
Text Description : This large boulder blocks all passage to the North
Type : Obstacle
Locations : Room(46)Direction[North]
Visible : Yes
Obstruction # : 5
Obstruction Name : Distance - From Ledge to Tree Stump
Text Description : The distance from the top of the cliff to the ledge
below it is too great for you to climb!
Type : Obstacle
Locations : Room(98)Direction[Up], Room(104)Direction[Down]
Visible : No
And that brings me to the "Events" file:
Move Item[Rock] ->
Removes Item[Rock] from CurrentRoom
and Adds Item[Dagger] to CurrentRoom;
Attack Obstruction[Savage] with Item[Dagger] ->
Removes Obstruction[Savage] from CurrentRoom
and Adds Item[Bow] to CurrentRoom;
Combine Item[Rope] with Item[Arrow] -> Adds Item[Rope Tied to Arrow] to
Inventory;
Spilt Item[Rope Tied to Arrow] -> Adds Item[Rope] to Inventory and Adds
Item[Arrow] to Inventory;
Use Item[Rope Tied to Arrow] on Obstruction(5)
(Requires InventoryContains Item[Bow]) ->
Removes Item[Rope Tied to Arrow] from Inventory
and Adds Item[Arrow with Rope in Stump] to Room(98)
and Adds Item[Arrow with Rope in Stump] to Room(104)
and Removes Obstruction(5) from Room(98)Direction[Up]
and Removes Obstruction(5) from Room(104)Direction[Down];
and Removes Item[Tree Stump] from Room(98)
and Removes Item[Tree Stump] from Room(104)
Get Item[Arrow with Rope in Stump] ->
Adds Item[Rope Tied to Arrow] to Inventory
and Adds Obstruction(5) to Room(98)Direction[Up]
and Adds Obstruction(5) to Room(104)Direction[Down];
and Adds Item[Tree Stump] to Room(98)
and Adds Item[Tree Stump] to Room(104)
and Removes Item[Arrow with Rope in Stump] from Room(98);
and Removes Item[Arrow with Rope in Stump] from Room(104);
Admittedly, the Events file will therefore become quite messy quite
quickly, but no moreso than the files for other engines that I've looked
over. YMMV. The five files are parsed into memory, and then all of the
data is serialized (a java construct) and exported into a single
database
file by a separate program called Text2Cog. This file is what the COG
Engine reads in, and the means through which different games can be used
by the same engine. By having an external program perform all of the
parsing before hand, the number of files the Engine Applet must access
is
reduced, as is processing overhead during game execution.
> 3. GUI development. A powerful, simple system for writing IF in a
> GUI environment; whether the work itself would be graphical or not
> could be optional.
I'm surprised that you mentioned this, because development is
planned for just such a utility. As I've mentioned before, the creation
of
a game is very much akin to filling out a form, and such a development
scheme lends itself very well to GUI Development. We already have a
program called Cog2Text which re-creates all of the text files for a
particular game. By combining Text2Cog and Cog2Text into a separate
applet, games can be created easily, with the potential for exportation
into a format (text) which can be then modified by any computer. I have
every intention of working on my game on my Zaurus or on a Palm Pilot.
Also, the GUI development application could use parts of the COG Engine
to
keep track of where items have been placed and that sort of thing.
I actually plan to write an Applet for the development GUI.
While
file reading-writing and other security issues would make for
complications, games could then be potentially developed online, and
parts
of the engine could be incorporated into the application. In this way,
you
can write up your game, enter COG Engine mode, walk around, and when you
find something you want to change, you could break back into Development
mode.
> All of these relate to ease of use, either for the writer or for the
> reader. All of these would be extremely difficult.
Agreed, I think these two features will improve the ease of game
improvement, but it's the difficulty that I welcome (and have already
begun to overcome)!
-Steven M. Castellotti
Ste...@Innocent.com
PS:
> An interpreter for Infocom's ZIP portable code format, which is that
> produced by Inform, has been ported to the web via Java:
> http://www.pond.com/~russotto/zplet/ifol.htm
> and is in all likelihood going to be your best source. For basic IF
> requirements and modeling, the four engines you mention should
> be sufficient.
Thank you very much for that link, however I would like to point
out that I found the webpage's address actually ends with "ifol.html"
(as
opposed to ".htm"). Thank heaven for directory browsing... (c:
TenthStone
<Ste...@Innocent.com> wrote:
>If the Engine develops a following, that would certainly be an added
>bonus, but I think that I would be simply satisfied in knowing that I
>had acheived a personal dream...
Ah.
>> 2. Natural language parsing. Even if it were written in a completely
>> different system, your ideas on taking standard English and adapting
>> it into a command that the game can understand would be well
>> appreciated.
>
> I feel that I have already achieved this goal. As I've said
>before, game creation for my engine simply involves the creation of five
>individual text files, in accordance to a special format, very much like
>filling out a series of forms.
I'm afraid you haven't understood what I meant. Parsing is the
science of taking player input such as:
>Place the iron bar underneath the trap door and close it.
and translating it into
move "ironbar" into position "under" "trapdoor"
close "trapdoor"
i.e. something the program can understand. Natural language parsing
is along the lines of being able to understand:
>Carefully wedge the piece of paper between Great Expectations and
The Great Gatsby with the shoe horn.
which is why it hasn't nearly been perfected yet.
>The first one specifies game information
>about the game's setup (such as the game's name, the default settings
>for the player such as points and health, and the location of graphics for
>the compass, etc.). The next three files describe the various rooms, items,
>and obstructions and their positions in the environment when the game
>begins. Finally, the "Events" file is the real meat of the game. The
>Events file describes what sort of actions the player can make in the
>game, the effect that it has, and what requirements must be met.
>This may sound somewhat complicated, however I think a few examples
>from my own game would be more than sufficient to illustrate my ideas:
This doesn't sound as much complicated as just a rather difficult way
of going about the business.
>Item # : 1
>Item Name : Dagger
>Aliases : Knife
>Environment GraphicURL :
>http://hawk.vill.edu/~s99g02/COG/Images/ItemTemplate(Green).jpg
>Environment Graphic Coordinates (X,Y) : 200, 400
>Text Description : This dagger is heavier than you might expect; it
>seems
>to be made of a strong and
> smooth metal that is a blueish-grey and does not shine, unlike any you
>have ever seen before. The grip
> is wrapped in some sort of animal hide. This dagger feels very good in
>your hand.
>Notes : Found under the rock in room #7
>Move Item[Rock] ->
> Removes Item[Rock] from CurrentRoom
> and Adds Item[Dagger] to CurrentRoom;
Yes, I can definitely see why this system would rather give itself
over to a graphical development interface.
>Item # : 2
>Item Name : Rock
>Aliases : Stone
>Environment GraphicURL :
>http://hawk.vill.edu/~s99g02/COG/Images/ItemTemplate(Green).jpg
>Environment Graphic Coordinates (X,Y) : 200, 400
>Text Description : This is a normal rock, not different from the many
>others laying around this area.
>Location : Room(7)
>Notes : Dagger is underneath the rock.
So, essentially you can either refer to rooms as "CurrentRoom" or by
an array index? You might want to work on this.
Does this system not support adjectives at all?
>As a quick note, in the current version of the Engine "obstructions" are
>defined as anything that prevents movement from one room to another.
>This would include enemies as well as physical objects.
Interesting. And how does define a non-obstruction NPC? (non-player
character)
No less messy, perhaps, but significantly less organised. There is
a difference.
>YMMV. The five files are parsed into memory, and then all of the
>data is serialized (a java construct) and exported into a single
>database
>file by a separate program called Text2Cog. This file is what the COG
>Engine reads in, and the means through which different games can be used
>by the same engine. By having an external program perform all of the
>parsing before hand, the number of files the Engine Applet must access
>is reduced, as is processing overhead during game execution.
Right. That's normally called "compilation".
Rob
>>YMMV. The five files are parsed into memory, and then all of the
>>data is serialized (a java construct) and exported into a single
>>database
>>file by a separate program called Text2Cog. This file is what the COG
>>Engine reads in, and the means through which different games can be used
>>by the same engine. By having an external program perform all of the
>>parsing before hand, the number of files the Engine Applet must access
>>is reduced, as is processing overhead during game execution.
>Right. That's normally called "compilation".
Haw Haw Haw! Man, if thats not sarcasm I don't know what is! One thing
that always get me about all these 'new developments' is they almost always
never appear. I heard someone refer to it as 'vaporware' and that is a good
phrase in my opinion!
R.o.b.
Steven M. Castellotti
>
> science of taking player input such as:
>
> >Place the iron bar underneath the trap door and close it.
>
> and translating it into
>
> move "ironbar" into position "under" "trapdoor"
> close "trapdoor"
>
> i.e. something the program can understand. Natural language parsing
> is along the lines of being able to understand:
>
> >Carefully wedge the piece of paper between Great Expectations and
> The Great Gatsby with the shoe horn.
>
> which is why it hasn't nearly been perfected yet.
Ah, I understand what you mean now. No, suffice it to say that I don't
have the intention inserting natural language parsing into my Game
Engine, at least not at this time. In fact, I may even move far away
from that area. I'm not trying to create a "Zork with pictures" type of
gaming experience. I think that other engines, such as Hugo for instance
are better suited to move into those sorts of areas. I'm focusing my
Engine on the ability to create a game more like Myst, as easily as
possible. I would also like to find a way to allow game creators to
create puzzles to insert into their games, though they will no doubt
have write code for that. I envision a Room object that you would enter
that when you left returned a boolean as to whether or not the puzzle
was solved. Something simple like that.
Perhaps you may feel that I am in that case moving away from
"interactive fiction" as it currently stands, and perhaps you'd be
correct. I think that I am instead simply the possibility of
incorporating multimedia into the the realm in a new way. I always found
Myst to have a surprisingly simple interface, while at the same time
providing a very rich gaming experience. Indeed, you have almost nothing
but a point-and-click interface based on "hotspots" that change the
mouse pointer to indicate actions. I have quite a few ideas about how to
implement this, but it will have to wait until development of the GUI
game creation application is underway.
Once I reach that point, I hope move in more of an RPG direction, first
by adding in a fighting engine, and then support for multiple party
members. Finally, I envision a series of servlet/applet connections that
will allow inter-applet (and therefore player) communication, so that
multiple people can play at the same time. But that's all down the road.
> So, essentially you can either refer to rooms as "CurrentRoom" or by
> an array index? You might want to work on this.
It depends on the context of the action. As the player moves through
the game, there is an object called "Player.CurrentRoom" which basically
points to the corresponding object in the Room Array. Ok, so granted,
Java doesn't support pointers in this manner, so I've kinda had to work
around that. When parsing an event script during gameplay, a
"CurrentRoom" just resolves to the cooresponding room in the index. I'm
not sure what might be wrong with that, perhaps you could elaborate?
> Does this system not support adjectives at all?
I don't think so. It depends on what you mean. If you're talking about
two different rocks in the same room, and one is blue and the other one
is red, and the player types in "get blue rock" they would get the
correct rock, because all items have unique names. They also have
aliases, but they are looked up second. If there is only the blue rock
in the room, and the play types "get rock", then the item "blue rock"
must have in their alias string the word "rock". If they tried "get
rock" when there are both colors in the room, the game engine would look
at all of the items in the current room, and then their aliases. If it
found two items in the same room with the same alias, it would then ask
"which rock?"
I may not understand what you mean by adjectives however.
> >As a quick note, in the current version of the Engine "obstructions" are
> >defined as anything that prevents movement from one room to another.
> >This would include enemies as well as physical objects.
>
> Interesting. And how does define a non-obstruction NPC? (non-player
> character)
It currently doesn't. While the Engine is very far from *ahem*
"vaporware", it does not currently support a great deal of the types of
objects that other engines support. My group is just working one step at
a time here (c: If you're wondering how I expect to implement NPC's, I
have a very simple answer: I don't know yet. Granted, under the current
scheme I may run into trouble figuring out how to do it, and may even
get stuck. However, when I started this project I didn't know how I
would work out events either, and I was not aware of any current
projects that might exist out there. If I'd known that such projects
fall under the category of "interactive fiction" then I probably would
have had a much easier time, but I only learned that recently. I'll have
the benefit of refering to other, existing projects when the time comes
around to provide NPC's. My main focus on this project is to make
everything as easy as possible for the Game Creators, so I will next
work on the Game Creation Application, something which I don't expect to
be very troublesome. I'll start adding new features after that. I've
found so far that things just "have a way of working out" so I'll let
you know after I figure it out!
> >Admittedly, the Events file will therefore become quite messy quite
> >quickly, but no moreso than the files for other engines that I've looked
> >over.
>
> No less messy, perhaps, but significantly less organised. There is
> a difference.
This is true. I'm largely hoping that the Game Creation Application
will make this sort of thing more managable. I hope. (c:
-Steve Castellotti
Ste...@innocent.com
TenthStone
<Ste...@Innocent.com> wrote:
>> >> 2. Natural language parsing. Even if it were written in a completely
>>
>> I'm afraid you haven't understood what I meant. Parsing is the
>> science of taking player input such as:
>>
>> >Place the iron bar underneath the trap door and close it.
>>
>> and translating it into
>>
>> move "ironbar" into position "under" "trapdoor"
>> close "trapdoor"
>>
>> i.e. something the program can understand. Natural language parsing
>> is along the lines of being able to understand:
>>
>> >Carefully wedge the piece of paper between Great Expectations and
>> The Great Gatsby with the shoe horn.
>>
>> which is why it hasn't nearly been perfected yet.
>
> Ah, I understand what you mean now. No, suffice it to say that I don't
>have the intention inserting natural language parsing into my Game
>Engine, at least not at this time. In fact, I may even move far away
>from that area. I'm not trying to create a "Zork with pictures" type of
>gaming experience.
Oh. Then you're not creating either a "graphics with text" or "text
only" system -- you're making a "graphics only" system (these three
options were the ones listed in your first post).
>I'm focusing my Engine on the ability to create a game more like Myst,
>as easily as possible. I would also like to find a way to allow game creators
>to create puzzles to insert into their games, though they will no doubt
>have write [sic] code for that. I envision a Room object that you would enter
>that when you left returned a boolean as to whether or not the puzzle
>was solved. Something simple like that.
Well, the engine that Sierra used for several of its graphical
adventures is available for comparison; it's similar to Myst,
but fundamentally different in some key areas. Possibly very
different -- I'm not sure which of Sierra's adventures were written in
it.
> Perhaps you may feel that I am in that case moving away from
>"interactive fiction" as it currently stands, and perhaps you'd be
>correct.
Not really. Most of us embrace a fairly loose definition of IF.
That our local brand of interactive fiction is so heavily
text-adventure based is a result of many things; prominently,
lack of resources and/or time. However, what's also important
is that most of us don't care to use graphics -- for various reasons,
we feel that a primarily text-based medium is better.
What you may find is that the sort of people with the time, resources,
and drive to create a graphical adventure are the sort of people who
can, and will, have their own engine written for them. But don't let
that discourage you -- perhaps you're writing the Doom engine of the
future, endlessly re-used by other companies.
>I think that I am instead simply the possibility of
>incorporating multimedia into the the realm in a new way. I always found
>Myst to have a surprisingly simple interface, while at the same time
>providing a very rich gaming experience. Indeed, you have almost nothing
>but a point-and-click interface based on "hotspots" that change the
>mouse pointer to indicate actions.
Yes, and that's certainly one way of going about it. However, for
something as complicated as what you wrote in your sample code, you'll
have to evolve past the Myst interface. For instance, you'll probably
need a multiple-object inventory.
> Once I reach that point, I hope move in more of an RPG direction, first
>by adding in a fighting engine, and then support for multiple party
>members. Finally, I envision a series of servlet/applet connections that
>will allow inter-applet (and therefore player) communication, so that
>multiple people can play at the same time. But that's all down the road.
So, you're combining Ultima, King's Quest, and MUDs. Well, no, it's
pretty much a graphical MUD with more puzzles and two-dimensional
graphics. Hmm -- an interesting idea, but you're right that it's a
good stretch from IF.
>> So, essentially you can either refer to rooms as "CurrentRoom" or by
>> an array index? You might want to work on this.
>
> It depends on the context of the action. As the player moves through
>the game, there is an object called "Player.CurrentRoom" which basically
>points to the corresponding object in the Room Array. Ok, so granted,
>Java doesn't support pointers in this manner, so I've kinda had to work
>around that. When parsing an event script during gameplay, a
>"CurrentRoom" just resolves to the cooresponding room in the index. I'm
>not sure what might be wrong with that, perhaps you could elaborate?
I have no reason to complain of CurrentRoom. What you may want to
work on is the even occaisional necessity of the programmer's using
index numbers. Usually, if you want to make something easy to use you
try to avoid numbers. CurrentRoom is a good idea, but if there were
some sort of aliasing that would be preferable (that is, being able to
refer to a room called "The Great Hall of Quendor" as "great_hall"
instead of "47".
> I may not understand what you mean by adjectives however.
You understood well enough.
Is your engine going to use text inputs or not? I'd advise that you
not try to implement two different types of interfaces into the same
engine.
>While the Engine is very far from *ahem* "vaporware", it does not currently
>support a great deal of the types of objects that other engines support.
Have you considered a more general approach? That is, simply
providing an object model and interface system to the programmer?
I mean, is there any particular reason why the engine needs to
differentiate between NPCs and normal objects? Sure, one may walk
around (or not), but that's just special code, and everything has
special code.
Most of the current systems do use a more flexible class-based system.
It tends to be very helpful when one wants to try something new.
Steven M. Castellotti
First just let me say that this discussion has already been of immense
help to my project, and I thank you very much for the comments!
> > Ah, I understand what you mean now. No, suffice it to say that I don't
> >have the intention inserting natural language parsing into my Game
> >Engine, at least not at this time. In fact, I may even move far away
> >from that area. I'm not trying to create a "Zork with pictures" type of
> >gaming experience.
>
> Oh. Then you're not creating either a "graphics with text" or "text
> only" system -- you're making a "graphics only" system (these three
> options were the ones listed in your first post).
Well, I suppose that it really depends on the game. The way the Engine
is currently set up, the GUI Initialization is written into a class
file, separate from the rest of the Engine. This allows a plug-in,
module-oriented GUI style that can differ from game to game. Java is
very helpful in this manner. I append all of my text to a TextArea panel
referred to as "OutputArea". However, there is nothing within the engine
that dictates the shape, form, or positioning of the TextArea. Not only
does this allow in-depth customization to what the player will see, I
can exclude certain panels, so that there would, say only a commandline
and a very large TextArea. Bingo, I have a Text-Only game.
The way the Engine is currently set up, I can have either a "text only"
or a "graphics with text" system. I don't have the option of a "graphic
only" system, yet, so that is the direciton that development will be
continuinig in. If I reach the point in which the first two modes of
operation begin to inhibit development of the graphic only system, I
will probably force a codebase split into two separate engines. The
basic format for creating a game would remain similar enough that
someone could create either style game with the same creation
application, but would have feed it into one of the two engines.
> What you may find is that the sort of people with the time, resources,
> and drive to create a graphical adventure are the sort of people who
> can, and will, have their own engine written for them. But don't let
> that discourage you -- perhaps you're writing the Doom engine of the
> future, endlessly re-used by other companies.
Good point. I can only hope that my engine is well-suited enough for
other people's projects that someone besides myself might find it
useful! In porting my own game to the engine, I've found that the most
time-consuming part of creating the game has been creating the graphics.
At the same time, working on the graphics has produced some of the most
pleasing results. I love to travel, and have had the opportunity to do
so extensively over the past few years (I'm in college). I also have a
habit of taking a great deal of pictures on my trips. Last summer, a
three-week cross-country trip yeilded 34 rolls of film. I figured out on
a trip to visit with my roommate's family in Puerto Rico that a certain
dock out in Old San Juan looked almost exactly the way I pictured the
one in my game, give or take a few elements. You see, I'm not very good
at drawing, but I am quite experienced with the modification of
pictures, under the GIMP and Photoshop. Ever since then, I've been
taking parts of pictures from one trip, combining them with parts of
other pictures, and putting all of the elements together to match the
way I've pictured them in my head, years ago, when creating the game...
> >I think that I am instead simply the possibility of
> >incorporating multimedia into the the realm in a new way. I always found
> >Myst to have a surprisingly simple interface, while at the same time
> >providing a very rich gaming experience. Indeed, you have almost nothing
> >but a point-and-click interface based on "hotspots" that change the
> >mouse pointer to indicate actions.
>
> Yes, and that's certainly one way of going about it. However, for
> something as complicated as what you wrote in your sample code, you'll
> have to evolve past the Myst interface. For instance, you'll probably
> need a multiple-object inventory.
And evolving is exactly what I intend to do. I play to use Myst as an
example for moving around rooms, and possibly for picking up objects.
When it comes to actually using the objects, I have a few ideas, but
nothing really specifc. I think I'm getting to the point where it would
be far easier to show you than to tell you, but luckily, I expect the
first release to occur within the next month, possibly sooner.
> So, you're combining Ultima, King's Quest, and MUDs. Well, no, it's
> pretty much a graphical MUD with more puzzles and two-dimensional
> graphics. Hmm -- an interesting idea, but you're right that it's a
> good stretch from IF.
(c: Yeah, I'm definately going to end up with an interesting mosiac of
different gaming styles all wrapped up into the same package. The basis
of the engine is that it will useful only from a first-person
perspective. Third-person games, whether overhead such as Ultima or
side-view such as King's Quest would be better-suited to an entirely
different type of engine; or at least that's my current thinking. I can
think of a few ways to bend a GUI-based system to work from either a
first-person or a third-person perspective, using the same engine, but
the main goal of my project is to make game creation as simple as
possible, and I'm not sure that such a goal would be served by bending
the engine every-which-way, trying to suit everyone's needs...
> I have no reason to complain of CurrentRoom. What you may want to
> work on is the even occaisional necessity of the programmer's using
> index numbers. Usually, if you want to make something easy to use you
> try to avoid numbers. CurrentRoom is a good idea, but if there were
> some sort of aliasing that would be preferable (that is, being able to
> refer to a room called "The Great Hall of Quendor" as "great_hall"
> instead of "47".
Right, and I think we've got that all taken care of. The current way we
deal with that sort of thing is when you are writing your game, you can
refer to a room/item/obstruction like this:
Item(1)
Item[Savage]
Obstruction[Boulder]
Room(47)Direction[West]
...and so on. When the game-module-parser is reading an object, if it
is refered to inside of parenthesis, the number of the object is what is
being referred to. If the reference is contained inside of brackets,
then the string refers to the name field of the object (and yes, the
name fields themselves may contain parenthesis).
Incidentally, we're also working to abstract the idea of "directions"
themselves. My game uses the stanard 8-compass points, plus up and down,
but for various reasons, someone else's game will not be restricted to
that set.
> Is your engine going to use text inputs or not? I'd advise that you
> not try to implement two different types of interfaces into the same
> engine.
Well, it hasn't been a problem so far (actually, it's been a necessity,
as we continue development on the graphical end of things), but I may
have to drop this option sooner or later, and end up creating two
separate engines, as described above. In the meantime, it seems to work
ok with both type of interfaces; interacting with the graphcial
environment slowly produces the equivalent command line structure, and
therefore everything evaluated the same way.
> >While the Engine is very far from *ahem* "vaporware", it does not currently
> >support a great deal of the types of objects that other engines support.
>
> Have you considered a more general approach? That is, simply
> providing an object model and interface system to the programmer?
> I mean, is there any particular reason why the engine needs to
> differentiate between NPCs and normal objects? Sure, one may walk
> around (or not), but that's just special code, and everything has
> special code.
>
> Most of the current systems do use a more flexible class-based system.
> It tends to be very helpful when one wants to try something new.
That's a very interesting idea, and would be helpful if I want to
create items in a game that can talk or otherwise interact with the
player. I'll have to think about it. I want the highest level of
flexibility possible, without over-complicating the rest of the way the
engine works. Just how far I can move in one direction without affecting
the other will dictate how I end up implementing elements such as NPC's.
-Steve Castellotti
Ste...@innocent.com
TenthStone
<Ste...@innocent.com> wrote:
> First just let me say that this discussion has already been of immense
>help to my project, and I thank you very much for the comments!
That's what we're here for. That and other things.
Large potential sections of this response have been edited out because
the only thing I could think to say was "That's an interesting way to
do it." Let that apply to the post in general.
> Good point. I can only hope that my engine is well-suited enough for
>other people's projects that someone besides myself might find it
>useful!
That's what I call the Implementor's Dream.
>You see, I'm not very good at drawing, but I am quite experienced with
>the modification of pictures, under the GIMP and Photoshop. Ever since
>then, I've been taking parts of pictures from one trip, combining them with
>parts of other pictures, and putting all of the elements together to match the
>way I've pictured them in my head, years ago, when creating the game...
Well, you'll need a very high-res, high-color graphics format (if you
want pictures to look reasonable). You'll be looking a fairly large
files.
>> Yes, and that's certainly one way of going about it. However, for
>> something as complicated as what you wrote in your sample code, you'll
>> have to evolve past the Myst interface. For instance, you'll probably
>> need a multiple-object inventory.
>
> And evolving is exactly what I intend to do. I play to use Myst as an
>example for moving around rooms, and possibly for picking up objects.
>When it comes to actually using the objects, I have a few ideas, but
>nothing really specifc. I think I'm getting to the point where it would
>be far easier to show you than to tell you, but luckily, I expect the
>first release to occur within the next month, possibly sooner.
I suppose the question that you're tackling is whether it should use
a general "USE" form of command, or whether you'll need to develop
a more advanced system. (A "USE" system is like that in King's Quest;
clicking an item onto another is interpreted as "use object on place".
Text IF, of course, requires that a verb be supplied as well, and
that has its own problems.)
To some degree, most rec.arts.int-fiction (raif) readers are probably
biased towards this second system; it's what we've been using for
years. However, what exactly this should entail is up to debate.
When he wrote the TADS manual, Michael Roberts advised thinking
of every action as if it were a "use", and then simply change the
verb at the end. On the other hand, a "use" interface does tend to
make things a matter of routine: "I'll just take this object," the
player thinks "and click it onto everything that looks interesting in
the room." Of course, there are parallels to that in text, as well.
Personally, I prefer the second system; I think it's more challenging
when done right, because the player almost has to have a clear idea of
what he or she is doing when attempting something. "Use" seems, to
me, to be much like blundering around in a toolshop with a hammer
trying to see what can be fixed with it.
Of course, maybe I've misunderstand what line your "ideas" are taking
completely.
>> So, you're combining Ultima, King's Quest, and MUDs. Well, no, it's
>> pretty much a graphical MUD with more puzzles and two-dimensional
>> graphics. Hmm -- an interesting idea, but you're right that it's a
>> good stretch from IF.
>
> (c: Yeah, I'm definately going to end up with an interesting mosiac of
>different gaming styles all wrapped up into the same package. The basis
>of the engine is that it will useful only from a first-person
>perspective. Third-person games, whether overhead such as Ultima or
>side-view such as King's Quest would be better-suited to an entirely
>different type of engine; or at least that's my current thinking. I can
>think of a few ways to bend a GUI-based system to work from either a
>first-person or a third-person perspective, using the same engine, but
>the main goal of my project is to make game creation as simple as
>possible, and I'm not sure that such a goal would be served by bending
>the engine every-which-way, trying to suit everyone's needs...
Heretic, I believe, has a fair number of puzzles; of course, most of
those approach the mundanity of "get the key", but it may give you
some ideas on how to implement a puzzle in first-person perspective
(Myst may not be so helpful here because of the lack of inventory).
I assume, however, that the perspective is fixed in a room (that is,
that there's no freedom of movement).
In a graphical adventure game you will probably need some sort of
animation (otherwise, everything looks like a slideshow), and you will
probably find that that is easier to implement in third-person
perspective.
>When the game-module-parser is reading an object, if it is refered to inside
>of parenthesis, the number of the object is what is being referred to.
>If the reference is contained inside of brackets, then the string refers
>to the name field of the object (and yes, the name fields themselves
>may contain parenthesis).
Okay, that's satisfactory. Thanks.
> Incidentally, we're also working to abstract the idea of "directions"
>themselves. My game uses the stanard 8-compass points, plus up and down,
>but for various reasons, someone else's game will not be restricted to
>that set.
One idea from the realm of MUDs is referring to directions by the name
of their goal. (That is, if the kitchen is to the north one may type
"kitchen" and it would be treated the same as if "north" had been
typed.) Of course, we haven't got any parallel system that I know of
in IF.
Steven M. Castellotti
release of
the COG Engine have been completed. The next week or two in between now
and the initial public release will be devoted to extensive testing,
debugging, and documentation. I'm very excited about this, and again I
thank everyone who has responeded to my initial questions.
> >You see, I'm not very good at drawing, but I am quite experienced with
> >the modification of pictures, under the GIMP and Photoshop. Ever since
> >then, I've been taking parts of pictures from one trip, combining them with
> >parts of other pictures, and putting all of the elements together to match the
> >way I've pictured them in my head, years ago, when creating the game...
>
> Well, you'll need a very high-res, high-color graphics format (if you
> want pictures to look reasonable). You'll be looking a fairly large
> files.
Yes, I've noticed this already. The pictures that I'm using for
my own
game are 640x480 true color jpg's. One of the nice things about the
Engine's Layout is that you can define your own graphic size, and all of
the various components will automatically resize to fit around them. The
same is true of the applet size itself, you set the size through an html
parameter, and the engine will scale to fit that space.
The problem of course with having my graphics so large and with
such
great color depth is that they range from about 150k-200k each, so the
download for each graphic can be rather long. I'll probably have to
dither down the colors, and possibly reduce the size if necessary.
Graphics are cached, so once they are loaded, returning to a room almost
instantaneously displays that room's graphic. I may do some work with
threads sooner or later so that the engine is constantly downloading the
graphics of the rooms adjecent to the current room, so that loading time
will be sped up.
No, I think that you were right on track with how I was handling
things
at that point. However, just yesterday I figured out a way to simplify
the whole process, as well as allow game creators to create and define
their own verbs (something which I wasn't sure how I might be able to
implement previously). The "new" command line parser permits any engine
or user defined verb, followed by an object, then arbitrary text, and
then another object (or just a verb, or a verb and one object, etc.).
This, for now pretty much covers most of the things that people might
want to be able to do in a game. Sure, there are examples in games like
Zork in which you have to type out 20 different things in the same
command or it won't work, but that complicates the parser beyond a point
that I'm comfortable with.
My current thinking, from a graphical perspective, is to allow
the
player to "divide up" the graphic area into something similar to an HTML
map. I don't know how to do maps in html, but I may just allow the Game
Creator to use the identical formatting as html, since there are already
a few tools out there (from what I've been told) that allow someone to
create an html map just by drawing on the picture. There are also plenty
of examples of html maps out there sitting around. If that doesn't pan
out, I may end up implementing something akin to RIP graphics from the
latter days of BBS's.
If the user wants to define their own verb, using the graphical
system,
they don't only give it a name, but also a graphic for the cursor. The
user can right-click to change their cursor into a different verb icon,
and when they click on an object (either on screen or in their
inventory) the command line is being formed (whether the commandline is
visible or not). A double-click executes the commandline. Simple as
that.
> Heretic, I believe, has a fair number of puzzles; of course, most of
> those approach the mundanity of "get the key", but it may give you
> some ideas on how to implement a puzzle in first-person perspective
> (Myst may not be so helpful here because of the lack of inventory).
> I assume, however, that the perspective is fixed in a room (that is,
> that there's no freedom of movement).
Yes and no. The perspective is fixed in that you can't look
around by
just moving the mouse cursor around in the graphic window. Well, at
least not yet anyway. There are ways of doing such things under Java.
The Discovery Channel's webpage has a "photo of the day" section that
contains a new 360 degree java-enabled picture every week of an exotic
location. I don't know how to write anything like that (at least not at
this point), but if someone else does... well that's what makes Open
Source such a wonderful thing. Zork Nemesis did something like this, in
which you could move from location to location with a mouse click, and
then "sit-n-spin" and look around the new location. It's one step less
free than a fully-3d engine (such as the Quake Series), but for this
type of game, it's still pretty nice.
In the meantime, I can at least do what Myst does, which is to
divide
up a location into a series of smaller rooms, each with a different
graphic. Remember, the default eight compass points and up and down are
not required to be used by anyone's game. They can may NorthWest (for
instance) into "turn left". when they move in that direction it moves
them into a different room object, but one that contains all the same
properties as the one before it. This new room would have a graphic that
matches the previous room, only from a different perspective. There is
quite a bit of flexibility under the current system.
> In a graphical adventure game you will probably need some sort of
> animation (otherwise, everything looks like a slideshow), and you will
> probably find that that is easier to implement in third-person
> perspective.
This is true. I haven't been able to think of a pratical way to
animate
graphics, at least not yet. I wanna make sure that the basics are all
hacked out of the way first, and then I'll start working on adding new
features again...
-Steven M. Castellotti
Ste...@innocent.com
TenthStone
<Ste...@Innocent.com> wrote:
>The problem of course with having my graphics so large and with such
>great color depth is that they range from about 150k-200k each, so the
>download for each graphic can be rather long. I'll probably have to
>dither down the colors, and possibly reduce the size if necessary.
>Graphics are cached, so once they are loaded, returning to a room almost
>instantaneously displays that room's graphic. I may do some work with
>threads sooner or later so that the engine is constantly downloading the
>graphics of the rooms adjecent to the current room, so that loading time
>will be sped up.
A 150K graphic is far, far too large to be downloading regularly off
the internet. If a game ever became popular, most hosting services
would start skinning the author alive on bandwidth fees.
In fact, a 100K graphic is far too large to be downloading. That's a
15-second delay, even on a 56K connection. Don't forget animation,
either. You may find that you want some style of continuously-running
animation in some frames, especially in those with water.
You will probably find that if there are going to be considerable
delays between locations, most players will ask very quickly for a
teleportation system (such as the map in King's Quest III (?)).
>
>No, I think that you were right on track with how I was handling things
>at that point. However, just yesterday I figured out a way to simplify
>the whole process, as well as allow game creators to create and define
>their own verbs (something which I wasn't sure how I might be able to
>implement previously). The "new" command line parser permits any engine
>or user defined verb, followed by an object, then arbitrary text, and
>then another object (or just a verb, or a verb and one object, etc.).
>This, for now pretty much covers most of the things that people might
>want to be able to do in a game. Sure, there are examples in games like
>Zork in which you have to type out 20 different things in the same
>command or it won't work, but that complicates the parser beyond a point
>that I'm comfortable with.
I'd comment that that might be a point beyond which the player would
be more comfortable, but in all fairness, multiple commands per line
is not the most widely used feature of a parser. At least, not with
any players that I know of.
How large is your game at this point if you're finding it easier to
determine that an object has been referred to than that a preposition
has been used?
Beyond that, your text system will be fairly effective.
>If the user wants to define their own verb, using the graphical system,
>they don't only give it a name, but also a graphic for the cursor. The
>user can right-click to change their cursor into a different verb icon,
>and when they click on an object (either on screen or in their
>inventory) the command line is being formed (whether the commandline is
>visible or not). A double-click executes the commandline. Simple as
>that.
So, right-clicking opens up a menu of verbs? Would this list be
specific to the object, or universal? How would one input an
object-free verb, assuming that the command line was not being used?
It's never as simple as that.
>The perspective is fixed in that you can't look around by just moving the
>mouse cursor around in the graphic window. Well, at least not yet anyway.
>There are ways of doing such things under Java. The Discovery Channel's
>webpage has a "photo of the day" section that contains a new 360 degree
>java-enabled picture every week of an exotic location.
That would require a panoramic shot, which is certainly possible but
which would be quite interesting to implement. I'm sure that the
"photo of the day" does not have hotspots.
>In the meantime, I can at least do what Myst does, which is to divide
>up a location into a series of smaller rooms, each with a different
>graphic.
That would be significantly easier to do than a panorama.
>Remember, the default eight compass points and up and down are
>not required to be used by anyone's game. They can may NorthWest (for
>instance) into "turn left". when they move in that direction it moves
>them into a different room object, but one that contains all the same
>properties as the one before it. This new room would have a graphic that
>matches the previous room, only from a different perspective. There is
>quite a bit of flexibility under the current system.
If this is going to be an often-used alternative, you may want to
write some way of easing the pain.
>I haven't been able to think of a pratical way to animate graphics, at least
>not yet. I wanna make sure that the basics are all hacked out of the way
>first, and then I'll start working on adding new features again...
Well, what I'm saying is that animation is going be to rather basic
to your gaphics system. Adding it on later may involve substantial
rewrites. Still, it's your call.
Steven M. Castellotti
15th!
> A 150K graphic is far, far too large to be downloading regularly off
> the internet. If a game ever became popular, most hosting services
> would start skinning the author alive on bandwidth fees.
>
> In fact, a 100K graphic is far too large to be downloading. That's a
> 15-second delay, even on a 56K connection. Don't forget animation,
> either. You may find that you want some style of continuously-running
> animation in some frames, especially in those with water.
Well, actually I was off about the graphic file size. The actual jpg's
range from about 35k to 55k per room. That's at 640x480 at 24-bit true
color. Those are also unmodified graphics, saved at a 75%
quality/compession ratio. There are any number of tools out there that
can reduce the size of a graphic file without detracting from the
overall quality of the picture.
There is of course another thing to keep in mind. Using 640x480 pixels
of desktop area just for the graphic (to say nothing of the rest of the
GUI) means a large investment in desktop space. If I reduce the size of
a 43k image to 320x200 I end up with a 13k graphic file, still true
color, without any additional tools. This is probably the size that I
will use for 640x480 browsers, simply because it leaves much more room
for the text area.
The GUI is totally dynamic in this respect, it will expand or contract
around whatever graphic or or space you give the applet. The preferred
graphic size is written into the info text file, and the size of the
applet is determined by html parameters.
> You will probably find that if there are going to be considerable
> delays between locations, most players will ask very quickly for a
> teleportation system (such as the map in King's Quest III (?)).
I have never seen the King's Quest III map feature, so I'm not too
familiar with what you are talking about. I am however very interested
in implementing a mapping feature, but am not too sure about how to go
mapping 3-D space onto a 2-D map. The idea of direction abstraction
further complicates this issue.
However, as far as the loading time, this is less of an issue than you
might think. Java supports threads, and I plan to make the actual
downloading of the image a thread-based operation. In this way, when you
enter a new room, a download thread will be initialized. If you want to
keep on moving, and the image has not been downloaded yet, that's ok,
because we're dealing with a separate thread.
> How large is your game at this point if you're finding it easier to
> determine that an object has been referred to than that a preposition
> has been used?
Right now, the command line will accept the phrase "Use rope tied to
arrow on tree stump" where use is the verb, rope tied to arrow is the
first object and tree stump is the second object. Even though the game
also includes such items/aliases as rope, arrow, and tree, it
successfully parses around this, making sure that the correct items are
in your inventory. There's still a few minor issues with alias parsing,
but I'm pretty close to nailing down those bugs right now.
> So, right-clicking opens up a menu of verbs? Would this list be
> specific to the object, or universal? How would one input an
> object-free verb, assuming that the command line was not being used?
The only only object-free verbs in the game right now are the direction
names and the look command. There is a graphical compass to take care of
the movements, and if you click in the center of the compass it calls
look. I was thinking more along the lines of the graphical sierra
adventures, as opposed to a menu with verbs, although that is certainly
a possibility. Zork Nemesis implements a similar interface, as I recall
(it being a few years since I've played that game), and that game
included an inventory. They implemented a "use only" type of structure,
but I'm expecting to do things just a little bit differently...
> That would require a panoramic shot, which is certainly possible but
> which would be quite interesting to implement. I'm sure that the
> "photo of the day" does not have hotspots.
Yeah, and I'm really not too sure how I would go about doing this. If
we're talking about a panoramic picture, that wouldn't be excessively
difficult, just unwrap the picture, lay it end to end on the screen, and
divide it up into hotspots the same way you would with an html map. When
the game displays the image, it can figure out which pixel you are
clicking on, and which area on the map it refers to.
The real problem comes in with 360 degree rotation. I suppose the the
same type of mapping structure could be used, only this time the graphic
is layed out on the desktop the way a curved map of the earth might be
displayed, and the wire-frame html mapping model could be applyied here
as well.
> >In the meantime, I can at least do what Myst does, which is to divide
> >up a location into a series of smaller rooms, each with a different
> >graphic.
>
> That would be significantly easier to do than a panorama.
True, but neither impossible nor unrealistic in my opinion. (c:
> >I haven't been able to think of a pratical way to animate graphics, at least
> >not yet. I wanna make sure that the basics are all hacked out of the way
> >first, and then I'll start working on adding new features again...
>
> Well, what I'm saying is that animation is going be to rather basic
> to your gaphics system. Adding it on later may involve substantial
> rewrites. Still, it's your call.
This is true, and I am fully prepared to do this. The graphic system is
rather uncomplicated currently, you simply provide the URL in your text
file, and the Engine displays whatever image it finds at that location.
The routine is very simple. How one might go about implementing
animation is a whole other issue. Maybe it would be as simple as
allowing animated gifs. I'm not really sure.
-Steven M. Castellotti
Ste...@innocent.com
TenthStone
<Ste...@innocent.com> wrote:
> Well, actually I was off about the graphic file size. The actual jpg's
>range from about 35k to 55k per room.
Okay, that's acceptable for an internet connection.
> There is of course another thing to keep in mind. Using 640x480 pixels
>of desktop area just for the graphic (to say nothing of the rest of the
>GUI) means a large investment in desktop space. If I reduce the size of
>a 43k image to 320x200 I end up with a 13k graphic file, still true
>color, without any additional tools. This is probably the size that I
>will use for 640x480 browsers, simply because it leaves much more room
>for the text area.
Well, except that 320x200 might be rather too small for any resolution
greater than 640x480. Remember, not everyone is viewing this on a
17-inch monitor.
>> You will probably find that if there are going to be considerable
>> delays between locations, most players will ask very quickly for a
>> teleportation system (such as the map in King's Quest III (?)).
>
> I have never seen the King's Quest III map feature, so I'm not too
>familiar with what you are talking about. I am however very interested
>in implementing a mapping feature, but am not too sure about how to go
>mapping 3-D space onto a 2-D map. The idea of direction abstraction
>further complicates this issue.
The KQ3 map is just a teleportation device. It's not a mapping
feature. You can move from one part of the game to the other,
instantaneously, just by looking at the map and touching a certain
part of it.
> However, as far as the loading time, this is less of an issue than you
>might think. Java supports threads, and I plan to make the actual
>downloading of the image a thread-based operation. In this way, when you
>enter a new room, a download thread will be initialized. If you want to
>keep on moving, and the image has not been downloaded yet, that's ok,
>because we're dealing with a separate thread.
Threads or no, if the only time I spend in a room is clicking out of
it the download time won't appear any shorter.
> The only only object-free verbs in the game right now are the direction
>names and the look command. There is a graphical compass to take care of
>the movements, and if you click in the center of the compass it calls
>look. I was thinking more along the lines of the graphical sierra
>adventures, as opposed to a menu with verbs, although that is certainly
>a possibility. Zork Nemesis implements a similar interface, as I recall
>(it being a few years since I've played that game), and that game
>included an inventory. They implemented a "use only" type of structure,
>but I'm expecting to do things just a little bit differently...
What you're talking about, then, is a graphical adventure with an
optional text-based interface which merely simulates action
performable by the graphics. Alright, that's fine.
> The real problem comes in with 360 degree rotation. I suppose the the
>same type of mapping structure could be used, only this time the graphic
>is layed out on the desktop the way a curved map of the earth might be
>displayed, and the wire-frame html mapping model could be applyied here
>as well.
And that's way outside of my domain of knowledge, sorry.
>> >I haven't been able to think of a pratical way to animate graphics, at least
>> >not yet. I wanna make sure that the basics are all hacked out of the way
>> >first, and then I'll start working on adding new features again...
>>
>> Well, what I'm saying is that animation is going be to rather basic
>> to your gaphics system. Adding it on later may involve substantial
>> rewrites. Still, it's your call.
>
> This is true, and I am fully prepared to do this. The graphic system is
>rather uncomplicated currently, you simply provide the URL in your text
>file, and the Engine displays whatever image it finds at that location.
>The routine is very simple. How one might go about implementing
>animation is a whole other issue. Maybe it would be as simple as
>allowing animated gifs. I'm not really sure.
Hmm. Animating the entire scene would be inefficient. How easily can
the graphics scene itself be seamlessly divided? What I'm thinking of
is the sort of design often seen on web pages, where one changeable
graphic fits among a set of other constant graphics.
Steven M. Castellotti
> >of desktop area just for the graphic (to say nothing of the rest of the
> >GUI) means a large investment in desktop space. If I reduce the size of
> >a 43k image to 320x200 I end up with a 13k graphic file, still true
> >color, without any additional tools. This is probably the size that I
> >will use for 640x480 browsers, simply because it leaves much more room
> >for the text area.
>
> Well, except that 320x200 might be rather too small for any resolution
> greater than 640x480. Remember, not everyone is viewing this on a
> 17-inch monitor.
What I will probably end up doing is compiling two separate versions of
my story files, one that points to the 320x200 graphics and one that
points to the larger ones. On the web page I will have a link for low
bandwidth/low resolution or high bandwidth/high resolution. It's a small
matter of a find-and-replace on the text files, and a batch process in
the GIMP to resize the photos. Shouldn't be too bad.
> The KQ3 map is just a teleportation device. It's not a mapping
> feature. You can move from one part of the game to the other,
> instantaneously, just by looking at the map and touching a certain
> part of it.
That's an interesting idea. I don't think that would be very difficult
to implement either. Hmm. So many new features, so little time. . .
> Threads or no, if the only time I spend in a room is clicking out of
> it the download time won't appear any shorter.
It will if I kill the thread any time an ActionEvent occurs (which in a
Java Applet would be defined as a return carriage on the command line,
or a mouse click on a panel or button) Under this scheme, the player
enters the room, the text description is thrown up, and a new thread is
created to download and then display the graphic. If they enter a
command that will move them out of the room before the graphic is
loaded, the download thread is killed and a new one is begun as they
move into the next room.
> Hmm. Animating the entire scene would be inefficient. How easily can
> the graphics scene itself be seamlessly divided? What I'm thinking of
> is the sort of design often seen on web pages, where one changeable
> graphic fits among a set of other constant graphics.
Animations presents a variety of problems and potential solutions. I'm
not sure that implementing just one would be enough. Java has pretty
decent funtionality in the area of graphics, and I plan to really start
exploring the possibilities once my finals are out of the way, sometime
next week. There's the new Java 2 / Swing API to review, because Sun has
overhauled the entire graphical interface. There may be a very simple
answer just lying in wait somewhere inside the O'Reilly book that's been
sucking up shelf space for the past couple months.
In the end, the most important thing for my project is to provide as
much functionality as possible without over-complicating game creation.
I am most interested in introducing new people into the realm of
interactive fiction. Once they're in, if they find a different Engine
that either more powerful or more suited to their needs, that's fine by
me.
-Steve
TenthStone
<Ste...@Innocent.com> wrote:
> What I will probably end up doing is compiling two separate versions of
>my story files, one that points to the 320x200 graphics and one that
>points to the larger ones. On the web page I will have a link for low
>bandwidth/low resolution or high bandwidth/high resolution. It's a small
>matter of a find-and-replace on the text files, and a batch process in
>the GIMP to resize the photos. Shouldn't be too bad.
Sounds okay.
>> The KQ3 map is just a teleportation device. It's not a mapping
>> feature. You can move from one part of the game to the other,
>> instantaneously, just by looking at the map and touching a certain
>> part of it.
>
> That's an interesting idea. I don't think that would be very difficult
>to implement either. Hmm. So many new features, so little time. . .
One of the facts of life is that its always best to write a game along
with writing a new engine; that way, you quickly learn what features
need to be added.
I'm not sure if a teleportation map is that necessary, though. It
certainly shouldn't be mandatory in the engine.
> It will if I kill the thread any time an ActionEvent occurs (which in a
>Java Applet would be defined as a return carriage on the command line,
>or a mouse click on a panel or button) Under this scheme, the player
>enters the room, the text description is thrown up, and a new thread is
>created to download and then display the graphic. If they enter a
>command that will move them out of the room before the graphic is
>loaded, the download thread is killed and a new one is begun as they
>move into the next room.
Ah, yes. That's a good method... I had confused the thread idea with
the mention of opening threads to download the graphics in adjacent
rooms.
> In the end, the most important thing for my project is to provide as
>much functionality as possible without over-complicating game creation.
That's fine, but remember that it's possible to have an engine with
several degrees of complexity. It should be simple to write a simple
game, but a more complex one is invariably going to take more work --
it's just a matter of whether your engine supports it.
>I am most interested in introducing new people into the realm of
>interactive fiction. Once they're in, if they find a different Engine
>that either more powerful or more suited to their needs, that's fine by
>me.
That's a laudable goal, and I thank you.
David Given
mcc...@erols.com (TenthStone) writes:
> On Sun, 02 May 1999 11:50:23 -0500, "Steven M. Castellotti"
> <Ste...@Innocent.com> wrote:
>> What I will probably end up doing is compiling two separate versions of
>>my story files, one that points to the 320x200 graphics and one that
>>points to the larger ones. On the web page I will have a link for low
>>bandwidth/low resolution or high bandwidth/high resolution. It's a small
>>matter of a find-and-replace on the text files, and a batch process in
>>the GIMP to resize the photos. Shouldn't be too bad.
Or, you could use vector graphics, which are (a) smaller, (b) can be
scaled to any size very easily, and (c) if done properly are of higher
quality. The w3c has just ratified a vector graphics format, too.
--
+- David Given ---------------McQ-+
| Work: d...@tao-group.com | "Premature optimisation is the root of all
| Play: dgi...@iname.com | evil." --- Don Knuth, quoting Tony Hoare
+- http://wired.st-and.ac.uk/~dg -+
Steven M. Castellotti
> scaled to any size very easily, and (c) if done properly are of higher
> quality. The w3c has just ratified a vector graphics format, too.
...that certainly sounds very interesting. Would you happen to have a
URL handy that I might be able to peruse?
Thanks in advance
-Steve Castellotti
Ste...@innocent.com
David Given
"Steven M. Castellotti" <Ste...@Innocent.com> writes:
>> Or, you could use vector graphics, which are (a) smaller, (b) can be
>> scaled to any size very easily, and (c) if done properly are of higher
>> quality. The w3c has just ratified a vector graphics format, too.
>
> ...that certainly sounds very interesting. Would you happen to have a
Try here:
--
+- David Given ---------------McQ-+
| Work: d...@tao-group.com | Evil empires: the USA and the USSR --- one
| Play: dgi...@iname.com | down, one to go!
+- http://wired.st-and.ac.uk/~dg -+
Steven M. Castellotti
> >> scaled to any size very easily, and (c) if done properly are of higher
> >> quality. The w3c has just ratified a vector graphics format, too.
> >
> > ...that certainly sounds very interesting. Would you happen to have a
> > URL handy that I might be able to peruse?
>
> Try here:
>
> http://www.w3.org/Graphics/
Thank you very much for the link, it was very helpful!
-Steve Castellotti
Ste...@innocent.com