From: aces@mcode.amdahl.com (Jeffrey D. Smith)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: VISIONARY.... who's got it?
Date: 15 Apr 92 14:51:43 GMT
Reply-To: jds30@amail.amdahl.com
Organization: Amdahl Corporation, Sunnyvale Ca.

In article <KENTD.92Apr13102130@zappa.FtCollins.NCR.com>, kentd@FtCollins.NCR.com (Kent Dalton) writes:
> >>>>> On 11 Apr 92 03:43:23 GMT, mikep@hpmwtd.HP.COM (Mike Powell) said:
> 
[stuff deleted]

> 
> Mike> 	Doesn't anyone own this one?????
> 
> Yes.
Me, too.  I have version 1.20, and I'm awaiting the AREXX version 1.5.

> 
[more stuff deleted]

> 
> Mike> 	Opinions on this program?????
> 
> It's not bad. I've only gone partway through the tutorial at this point,
> so here are my first impressions... It uses MED as its music standard
> and supports IFF animations in addition to still images. The language
Actually, it does not support directly IFF animations.  You have to
call an AmigaDOS routine to "play" the animation.  When the DOS command
finishes, you're VISIONARY program then continues.  You can create
your own code to animate stuff using double buffering.

> itself oriented toward defining rooms and objects and then setting up
> action code to allow the player to interact with them. This makes text
It's very close to the "Sierra style" of adventure games where each
"room" is a scene with specific tasks.  The King's Quest IV game
would be a snap with VISIONARY.  King's Quest V not so easy, because
you don't have any control over the appearance of the mouse cursor.
(The VISIONARY mouse cursor is always an ugly hand.)

You cannot currently import/export your "character" data to a sequel,
because VISIONARY does not have "ordinary" file I/O capabilities.  The
announced AREXX support may provide some relief.

> style adventures very easy to implement, Graphical DM-type stuff is
> doable but much harder.
VISIONARY comes with a sample dungeon game (one level).  It is
interesting, but not a good starting point for DM-style construction.
The entire dungeon is one huge "room" in VISIONARY terminology.

The DM-style game uses asynchronous subtasks for monsters.  The
equivalent VISIONARY mechanism is NPC.  An NPC is just like an OBJECT,
except that the NPC code section is executed for each TURN.  You
can set up a main loop which issues commands via the GHOST "xxx",TURN.

This is how you get a continuously running dungeon where all of your
monsters are wandering around even though your party is not necessarily
in the same location.  You'll also want to define each dungeon square
as a VISIONARY room with the appropriate connections to adjacent
squares.  It's rather tedious, even for small dungeons 20x20 squares
per level and ten levels. (VISIONARY does not support arrays, but
you can kludge them with bit maps. UGH!)

Note that ANYTHING that moves or interacts with the environment must
be an NPC.  That includes doors, teleporters, stairs and pits (special
case of teleporter), rocks and fireballs (because they can be thrown
or fly through the air), as well as your "standard" monsters.

Buttons, keyholes, pressure plates, etc. must be designed to send
a "message" to the appropriate NPC (like a door) to cause it to
react appropriately (like opening or closing).

The biggest problem with VISIONARY is that all of these wonderful
ideas require you to EXPLICITLY hardcode room names, object names,
and NPC names to refer to their attribute flags.  Also, VISIONARY
assigns room numbers and object/npc numbers in a manner that is not
easy to determine at run time.  Even though you can determine what
room number a particular object is in, you cannot easily determine
the converse: What objects/npcs are in a particular room?  It is
a simple loop if your game has 10 objects, but what if your game
has 10,000 objects?  Even a 68040 won't help.  You'll need an object
oriented approach where each object "annouces" its presence in the
room to the display engine (npc).

Another headache is that sending an object-oriented message between
monsters, doors, buttons, plates, exploding fireballs, etc. is 
difficult (you must use the GHOST command).  VISIONARY only recognizes
objects/npcs that are either in the player's inventory or in the
current room.  Obviously, a fireball flying down the hallway and
striking a monster is neither in the player's inventory nor the
current room.  I've solved this problem, but I'll let you dwell
on it for a while.

Another problem with VISIONARY is timing.  How do you get a fireball
to fly through a hallway at the same speed regardless of whether
the game is running on a 7 Mhz 68000 or a 28Mhz 68040?  I've somewhat
solved this problem, but I'll let you dwell on it for a while.

Finally, how can you tie all of this together so that you can
easily define your dungeon map with teleporters, buttons, plates,
doors, monsters, objects, niches, spinners, spells, etc.?  Remember that
all interactions between object, npc, and player must use hardcoded
names.  I've also solved this, but I'll let you dwell on it, also.

As a side note, the VISIONARY Interactive Editor (VIE) is a disappointment.
It is a glorified text editor, with the ability to insert file
templates for room, object, npc, etc. definitions.  You, the game
designer, must fill in the smarts.  My VIE is buggy, the cut/copy
and paste function is broken; I never use it.

Cheers.

Jeffrey D. Smith