Visual Authoring System for Interactive Fiction
Jason Hutchens
In my spare time I would like to develop a visual authoring
system for IF. Such a system would allow non-programmers to
write IF easily, as all operations would involve graphical
symbols (apart from description text).
Obviously, such a system would take several years to develop
(especially as I am doing an honours thesis and coursework
at the same time), but I think that it woulb be a great
development environment to allow traditional authors to
dip their toe into the world of IF.
I was wondering if any of you have any comments to make on
such an environment, and have any suggestions for the
interface etc. Basically, my ideas are:
* Allow the author to quickly lay down a "map" by drawing
it on-screen, connecting locations with lines.
* Double-clicking on a location would pop-up a frame where
the author could set the default values of variables,
populate the location with objects and write descriptive
text.
* Objects would be created by creating a "tree" of object.
i.e: Objects inherit values from their parents etc.
Locations would have a similar tree hierarchy.
* Copies of these objects could be dragged from the object
storage window directly into the location window, and
further modified if necessary.
* The user may add any type of variable etc to a class of
objects.
The only difficulty would be making it easy to write the
rules for parsing user input, given that the author may
create their own variables for each object and that these
values may need to be checked. Perhaps some sort of
graphical language may be employed?
Initially, I will probably just implement the part of the
system that allows the creation of maps, and extend the
system later when I have some time.
Ideally, the system would generate code that could execute
on any platform. The interpreter would probably initially
only be text-based, but could be extended to a GUI with
graphics, map etc.
I welcome your feedback.
--
Cheers,
- Jas.
---
Jason Hutchens
I welcome your feedback.
Cheers,
- Jas.
--
---
Mr. Jason L Hutchens (Honours Student in Information Technology) _--_|\
Centre for Intelligent Information Processing Systems / \
Dept. of Electrical & Electronic Engineering *_.--._/
The University of Western Australia v
NEDLANDS WA 6009 Australia Email: hu...@ciips.ee.uwa.edu.au
Paul DuBois
Jason Hutchens <hu...@ee.uwa.edu.au> wrote:
>Hi,
>
>In my spare time I would like to develop a visual authoring
>system for IF. Such a system would allow non-programmers to
>write IF easily, as all operations would involve graphical
>symbols (apart from description text).
[...]
Nifty idea. Instead of trying to re-invent the wheel, why not write a
front end that can spit out TADS and/or INFORM code? I'd buy that for a
dollar! (well... probably more)
The question of course is, what do you write it in? tcl/tk? X? esp/goc?
--
Paul DuBois have a day :| p...@soda.berkeley.edu
Bill Blohm
: I was wondering if any of you have any comments to make on
: such an environment, and have any suggestions for the
: interface etc. Basically, my ideas are:
: * Allow the author to quickly lay down a "map" by drawing
: it on-screen, connecting locations with lines.
: * Double-clicking on a location would pop-up a frame where
: the author could set the default values of variables,
: populate the location with objects and write descriptive
: text.
: * Objects would be created by creating a "tree" of object.
: i.e: Objects inherit values from their parents etc.
: Locations would have a similar tree hierarchy.
: * Copies of these objects could be dragged from the object
: storage window directly into the location window, and
: further modified if necessary.
: * The user may add any type of variable etc to a class of
: objects.
One thing you would want to keep in mind in setting up such a
mapping interface is to allow the move of an entire location
from one place to another without losing the links to the next
location(s). For example, I draw out three rooms, then from
one room I decide to create another, hidden location. But I
need to put it on the map between two other locations that I
put together without enough room in between to insert this new
room. Hence I need to move one room over a little but don't
want to lose all my links.
If you do set up this mapping interface, might I volunteer to
test it out? I go thru so many erasers it isn't funny!
Bill B.
Gerry Kevin Wilson
Jason Hutchens <hu...@ee.uwa.edu.au> wrote:
>Hi,
>
>In my spare time I would like to develop a visual authoring
>system for IF. Such a system would allow non-programmers to
>write IF easily, as all operations would involve graphical
>symbols (apart from description text).
>
>Obviously, such a system would take several years to develop
>(especially as I am doing an honours thesis and coursework
>at the same time), but I think that it woulb be a great
>development environment to allow traditional authors to
>dip their toe into the world of IF.
>
>I was wondering if any of you have any comments to make on
>such an environment, and have any suggestions for the
>interface etc. Basically, my ideas are:
>
>* Allow the author to quickly lay down a "map" by drawing
> it on-screen, connecting locations with lines.
Ok, first of all. Why not just make a programming shell for TADS and
Inform? Then you'll already have an established base of customers.
Next, here are some basic ideas on user interface and screen layout:
First off, you have a central working area that never gets covered up by
any menus or other obstructions. It's important to me to be able to see
my work as much as possible. Put a number ofinstant object icons on the
side of the screen, either the left or the right, user-configurable. Not
everyone is right handed. Across the top you have some pull-down menus
for the user to play with, or perhaps a 'pull-across' version that will
leave the central work area free of obstructions. In any event, allow
the user to load various templates, maps, etc. in a user friendly
manner. The object icons I would suggest for the side of the screen are:
Last used or edited item.
Room
User-defined
User-defined
User-defined
Current Scenery object.
Let me explain a few of these. Last item used is simply that. If the
user has created an object in another part of the program, or edited an
item already in place on the map, it appears here. Put a scrollbar next
to it to scroll back through the last few items as well. User-defined
lets the user put some of his most commonly used items permanently on the
menu, and the scenery object is a special thing I will explain later.
And now some comments on moving objects and placing exits:
When a user clicks on an object icon, it is highlighted. The cursor
then changes to match that icon. The player can move the cursor into the
work area and 'stamp' copies of the object wherever he likes. Every
stamp is followed by a request for more info that can be turned off in
configuration. The program keeps track of objects by #s to keep them
seperate, and runs a check at the end to make sure that no two objects
have the same identifier. To create a path between two rooms, click the
right button on a room, and either drag to another or click on a second
room, user configurable (all the best programs let the user decide how
things work.) Then, a menu pops up to the side, and arrows point from the
first room to the second. The menu is a list of the normal directions
found in text adventures, and the arrows are to remind the user which way
the exit is going. Again, the menu has three configurable choices, and
an Other, which prompts for both directions of travel between the rooms.
You might allow for one-way travel as well. Fancier options here include
adding a dead end, which just gives a message when traveled down and
doesn't move the player. Prompt the user for the message. Example: I
have two rooms, Maze, and End of Maze. I want Maze south of EOM. So, I
click on Maze, and since I have 'exit drag' turned off, I then click on
EOM. A flashing line appears between them, with arrows pointing towards
EOM. Then, a window to the left of my work area opens up. It has 8
compass directions, up, down, in, out, and I have defined 'dive' (a
special exit which requires an 'out' to return from), 'teleport' (A one
way exit used by certain rooms in my game), and 'beta' (debugging paths
that I will remove before final release of the game). Anyways, I click
on 'North', since the arrows are pointing from Maze to EOM. The program
automagically sticks a south on the other room. If I right click on the
path again, the program will ask of I want to redefine, or perhaps a
double-click is sufficient. Anyways, I also happen to have edited a vase
recently, and I want it to go in EOM. So, I click on the vase, and click
on EOM. The vase vanishes, since I had marked it as unique (more on that
later. :) The vase is now in EOM.
>* Double-clicking on a location would pop-up a frame where
> the author could set the default values of variables,
> populate the location with objects and write descriptive
> text.
In addition, put a 'global' object in a corner somewhere to let the user
edit global variables.
>* Objects would be created by creating a "tree" of object.
> i.e: Objects inherit values from their parents etc.
> Locations would have a similar tree hierarchy.
Ok, simple object creation. I pull across a menu, select create object,
and a different screen comes up. On this screen, there are a number of
icons across the main work area, a sidebar that replaces the object icons
of the map screen, and the good old main menu at the top. The icons in
the work area all represent classes. They can be clicked on and off
easily. They are arranged in a tree format, to show how they are
connected. Any portion of the trees may be clicked, not just the bottom
'leaves'. Any number of icons may be on. Finally, in the sidebar is a
combination of fill-in-the-blank boxes, and check boxes. Object name,
nouns, adjectives, short description, and long description are all
there. The check boxes include some important variables (pulled out of
that particular class), and one line of checks that says [] Class []
Scenery [] Unique. More on that later.
>* Copies of these objects could be dragged from the object
> storage window directly into the location window, and
> further modified if necessary.
>
>* The user may add any type of variable etc to a class of
> objects.
>
>The only difficulty would be making it easy to write the
>rules for parsing user input, given that the author may
>create their own variables for each object and that these
>values may need to be checked. Perhaps some sort of
>graphical language may be employed?
Stick with a programming shell. There are already some excellent kits
out there, they just need some more programmer friendliness.
>Initially, I will probably just implement the part of the
>system that allows the creation of maps, and extend the
>system later when I have some time.
I'd be willing to help you create a TADS version of your mapper, since
I'm already familiar with TADS. I could explain how to handle
directions, add new ones, etc.
>Ideally, the system would generate code that could execute
>on any platform. The interpreter would probably initially
>only be text-based, but could be extended to a GUI with
>graphics, map etc.
Again, I would rather have a shell than learn another language.
>I welcome your feedback.
Final words:
Explanation of Scenery: In every text adventure, there are a number of
useless items just there for show. Often, the programmer wants to have
them appear in more than one room. These are scenery objects. TADS
really has no user friendly way to handle scenery. It's a dreary process
of putting one room after another on a certain list to make sure it shows
up properly. Even then, I'm always having to look at my rooms and figure
out where a particular bit of scenery goes again. The way I'd like to
see it work is: User double-clicks or right clicks on scenery icon on
main map screen. A list of scenery objects pops up and he selects one.
The new scenery item takes its place on the sidebar. The user clicks on
it, and it is highlighted. Also, any room that has that scenery in it is
highlighted. User clicks on rooms to add or remove the scenery from
them. Very simple, no?
Differences in the handling of classes and uniques: Uniques act more
like a physical object, being moved around on the map, disappearing from
the sidebar when used, etc. Classes generic objects of a certain class
of object, like a template. They are the objects you are asked to fill
in the info for. Uniques can be picked back up out of rooms and moved to
another room easily.
There, that's about all I can think of right now, but I'm sure I could
come up with more desired features given time. However, if you decide to
do a minimal implementation, start with the map and exits, and a scenery
handler. Again, I'd be willing to supply you with TADs code for the
neccessary stuff. If you went all out and did the full version, you
could probably charge $25-35 a pop. You've got one customer already at
least. :)
--
<~~TREV ERA~~~~~~~~~~~~~SIGHT~UNSEEN~~~~~~~~NO~RELEASE~DATE~YET~~~~~~|~~~~~~~>
< I W In the jungle of the big city, a predator stalks one | ~~\ >
< GO SOFT he considers easy prey, a blind student. Feel the fear | /~\ | >
<_______________________...@uclink.berkeley.edu__|_\__/__>
john t baker
>Obviously, such a system would take several years to develop
>(especially as I am doing an honours thesis and coursework
>at the same time), but I think that it woulb be a great
>development environment to allow traditional authors to
>dip their toe into the world of IF.
Your idea and list of feature sounds great. Are you planning on the
program generating an executable or game file directly, or for it to generate
source code which is then compiled into an executable or game file?
I would prefer to see the latter, because invariably with graphical
development systems, I end up having to do something comparable to
pulling teeth to get it to do what could be done with a few lines of
code if I could just put them *right* where I wanted them.
If it is the latter, I suggest this: Both to immediately gather a wider
audience and to get a great tool out there faster, have it generate source
code for packages that are already written. Set a switch here, and you get
TADS code. Set another switch, you get Inform code, etc.
On a non-related subject, how come I never see any offers for TADS
coders over on misc.jobs.offered? :)
--
John Baker
"It ain't an easy life being a self-parody."
- John Baker
Adam Thornton
Paul DuBois <p...@soda.berkeley.edu> wrote:
>The question of course is, what do you write it in? tcl/tk? X? esp/goc?
Depends. Tcl/tk is fairly generic, but does presuppose a Unix box
(actually, TCL and a good curses library should work on almost anything).
THat's probably the way to go.
Unless of course you have OS/2. Then VX-REXX is the _only_ way to go.
Adam
--
ad...@io.com | ad...@netcom.com | ad...@phoenix.princeton.edu | Viva HEGGA!
"Double integral is also the shape of lovers curled asleep" : Pynchon
64,928 | TEAM OS/2 | "Ich habe einen Bierbauch!" | Linux | Fnord
You can have my PGP key when you pry it from my cold, dead braincells.
David Baggett
Gerry Kevin Wilson <whiz...@uclink.berkeley.edu> wrote:
>TADS really has no user friendly way to handle scenery. It's a dreary
>process of putting one room after another on a certain list to make sure it
>shows up properly. Even then, I'm always having to look at my rooms and
>figure out where a particular bit of scenery goes again.
The standard ADV.T has no simple mechanism for this, but you can add some
code yourself that will fix this problem. What I've done for walls in
Legend is to change the location method so that it always returns the
player's location when the room the player is in has
walls = true // walls in this location
That way I can turn walls on and off in the room code, not in the Walls
object.
Basically, I have a class for items that are in lots of places. These
items have a field "roomprop" which determines whether or not they're
present in each room. E.g. if
roomprop = &ceiling
then the object will only show up in rooms that have ceiling = true.
You can obviously just make room classes that set these properties too,
as in
Orange_Grove: Everywhere
roomprop = &orange_grove
sdesc = "orange grove"
ldesc = ...
;
class Grove_Location: room
orange_grove = true // This location is in the orange grove
;
Twisty_Maze_1: Grove_Location
sdesc = "Lost in the Orange Grove"
ldesc = "You are in a maze of twisted citrus trees, all alike."
;
But of course a visual programming system would make these kinds
of things even easier.
Dave Baggett
__
d...@ai.mit.edu MIT AI Lab He who has the highest Kibo # when he dies wins.
ADVENTIONS: We make Kuul text adventures! Email for a catalog of releases.
Paul Munn
[...]
: In my spare time I would like to develop a visual authoring
: system for IF. Such a system would allow non-programmers to
: write IF easily, as all operations would involve graphical
: symbols (apart from description text).
[...]
: The only difficulty would be making it easy to write the
: rules for parsing user input, given that the author may
: create their own variables for each object and that these
: values may need to be checked. Perhaps some sort of
: graphical language may be employed?
: Initially, I will probably just implement the part of the
: system that allows the creation of maps, and extend the
: system later when I have some time.
: Ideally, the system would generate code that could execute
: on any platform. The interpreter would probably initially
: only be text-based, but could be extended to a GUI with
: graphics, map etc.
[...]
I don't mean to discourage you, but perhaps you should write an authoring
system add-on for one of the popular existing systems. I am thinking of
TADS in particular. TADS code is C-like, and since there exist packages
that, for example, write C code in the place of pictures you draw, why not
make something similar for TADS?
TADS already has quite sophisticated parser input handling and an excellent
object-oriented ability. Your program would onlyi need to know how to
output it correctly, a snap if you register TADS for a happy $40 and get the
fantastic 200+ page manual.
TADS text code can be compiled on a variety of systems, including Macintosh
and UNIX systems, so the code your program writes would be distributable
across multiple platforms already.
Although it is rumored that there is a new form of TADS, TADS/G (meaning
TADS/Graphical), under production, it would most likely be downward
compatible, allowing the code from the authoring add-on to work.
The problem for you, of course, might be making your authoring tool
available across platforms, which TADS users would want. Perhaps making it
a text-mode, no frills, ANSI-language-written system would be easier for
porting, but then again, that wouldn't be too pretty. It would work, but it
wouldn't be pretty.
Just some suggestions.
Yours,
Paul Munn pm...@westnet.com
--
----------
"When strict with oneself, one rarely fails." -- Confucious.
pm...@westnet.com // Paul F. Munn
Greg Ewing
designed to put out Alan code, and it gave you a way of
graphically laying out room networks. If there's enough
interest I might be tempted to resurrect the project.
In article <2v1gng$5...@hpbs3591.boi.hp.com>, bbl...@boi.hp.com (Bill
Blohm) writes:
|> One thing you would want to keep in mind in setting up such a
|> mapping interface is to allow the move of an entire location
|> from one place to another without losing the links to the next
|> location(s).
|> For example, I draw out three rooms, then from
|> one room I decide to create another, hidden location. But I
|> need to put it on the map between two other locations that I
|> put together without enough room in between to insert this new
|> room.
My solution to this (intially, at least) was as follows.
Each room was assigned a location on a 2-dimensional grid.
To create a new room, you could either (a) select a vacant
grid cell and give the "create rooom" command, or (b)
select the space *between* two grid locations and give
the "insert room" command. In the latter case, the entire
grid was split either horizontally or vertically and the
two halves moved apart one place, creating a new row or
column of vacant locations. All existing links between
rooms were preserved.
Not the best solution, perhaps, but it worked well enough
for an initial version!
|> Bill B.
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.|
gr...@cosc.canterbury.ac.nz +--------------------------------------+
David Baggett
Greg Ewing <gr...@huia.canterbury.ac.nz> wrote:
>My solution to this (intially, at least) was as follows.
>Each room was assigned a location on a 2-dimensional grid.
>...
A general note about graphing maps: You can't necessarily draw an arbitrary
graph of locations on a screen in grid fashion, or even without the lines
between locations crossing. Graphs that you can lay out without any
crossing lines are called *planar* graphs. There are some simple graphs
which aren't planar; for example, a fully connected graph with five nodes
is not planar.
A visual map editor would probably want to do something different for
nonplanar graphs, since overlapping lines make things confusing.
Fortunately, you can check to see if a graph is planar in polynomial time.
(I don't know how, but I know you can; it's in the literature, probably
coauthored by Tarjan like every other graph algorithm paper.)
In any case, there is a decent amount of literature on "nice" 2D graph
layout which you'll want to look at before writing a visual map editor.
You do *not* want to try to hack such an algorithm from scratch -- it's
tricky.
Greg Ewing
Baggett) writes:
|> A general note about graphing maps: You can't necessarily draw an arbitrary
|> graph of locations on a screen in grid fashion, or even without the lines
|> between locations crossing.
That's true, but we're not really trying to solve the general problem
of taking an arbitrary graph and drawing a planar view of it.
My system made no attempt to prevent links from crossing - it was
up to the user not to create any crossing links if s/he didn't
want them.
|> A visual map editor would probably want to do something different for
|> nonplanar graphs, since overlapping lines make things confusing.
My design was eventually to have allowed multiple, separate grids
with free-form links connecting them. Up and down links, for example,
would appear as some sort of "staircase" symbol; traversing one
would take you to a different grid. That way you could layer a
non-planar graph into approximately planar subgraphs.
|> Dave Baggett
|> __
|> d...@ai.mit.edu MIT AI Lab He who has the highest Kibo # when he
dies wins.
Greg Ewing, Computer Science Dept, +--------------------------------------+
David Baggett
Greg Ewing <gr...@huia.canterbury.ac.nz> wrote:
>That's true, but we're not really trying to solve the general problem
>of taking an arbitrary graph and drawing a planar view of it.
From the discussion, I envisioned a system where you'd be able to click on
a location and add an exit to another location. The program would then
redraw the map for you so that no (or few) lines crossed. This is the kind
of thing I'd want, at least. Actually, such a mapper would be nice to
have just for *playing* games...
You should certainly support weird topologies since they're quite common in
adventure games. (Part of the fun of all-text games is that you can make
things you couldn't possibly draw.)
Dave Baggett
__
d...@ai.mit.edu MIT AI Lab He who has the highest Kibo # when he dies wins.