Visual Authoring System for Interactive Fiction
Jason Hutchens
Well, thanks to everyone for replying to my original post.
From the responses I received, I have written a rough
requirements spec of the system, and have described what
the initial implementation will be. I have posted this here
for comments.
* The system should be useable by people with minimum
programming experience.
* It should generate source code for external compilation.
Probably this will be TADs code, but the system should be
written in such a way that it is possible to create a
module that will generate different source code (eg: ALAN
or C/C++).
* The graphical editor should be written to be as portable as
possible. This probably requires putting platform dependant
GUI code in separate functions that can be implemented on
the target platform. It should be possible for third-parties
to port the editor to another platform easily.
* The above point suggests that the editor may look quite
different on various platforms. Hence, a styleguide is
probably needed. This would define standard operations etc
such that multiple versions of the editor would be functionally
equivalent.
* Complexity of the underlying system (eg: TADs) should be hidden
from the user, but it should be possible for the expert user to
perform complex functions.
* Minimal assumptions should be made about the format of an
adventure game. These assumptions should be contained in an
external, modifiable definition file. (eg: default exit
directions and their names).
OK, this is quite ambitious. Hence I describe my first sub-goal
below.
* Produce a location/map editor (two-dimensional only) that generates
code for at least two different compilers.
* Allow creation of descriptions of the locations, exits, comments,
and possible scenery objects.
* The system won't draw the map so that the exit paths don't intersect.
This is too complex, plus the system shouldn't make assumptions
about directoin etc. Rather, allow the user to select when the exits
are visible. ie: Exit lines may onle be visible for the selected
location, or higlight the selected locations lines.
* Allow re-positioning of locations without losing their links.
* Extend this system in the future to n-dimensions (multiple editing
windows with links between them). Further extensions include adding
objects selected from a hierarchy of object classes etc, and defining
variables and so on.
I look forward to your responses. 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
Neil K. Guy
There's a HyperCard stack that runs on any Mac on ftp.gmd.de that does
very simple room prototyping. It's not as sophisticated as the ideas
being tossed around here, but it lets you design room interconnections
(using the standard Infocom-like compass rose and up and down
directions) for each room and a list of objects. It then generates
TADS source. Each room takes up a full card, and arrows are
highlighted indicating which directions contain links.
Since it's written in HyperCard you can open up the script window and
modify the HyperTalk script with ease. I've done it to add more
automated room decorations easily. It's written by Jared Reisinger and
is in the if-archive. Again, you need a Mac, HyperCard and TADS.
- Neil K.