<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Author" CONTENT="jpm">
<META NAME="GENERATOR" CONTENT="Mozilla/4.08 [en] (Win16; I) [Netscape]">
<TITLE>IRE Developer's Information</TITLE>
</HEAD>
<BODY>
<CENTER>
<H1>
IRE</H1></CENTER>
<CENTER>IT-HE Roleplaying Game Engine</CENTER>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<CENTER>
<H2>
Developer Documentation</H2></CENTER>
<CENTER>version 0.6 -11/8/1999
<P>Made with Netscape Composer, DRDOS, Win 3.1, and Win95 when necessary
<BR>Written by Joseph P Morris
<BR>Proofread by Alan P Keane
<BR>(C) 1999 Joseph P Morris
<BR>Any trademarks in this document are the property of their respective
owners.
<BR>This is free software and as such there is no warranty whatsoever.
Use at your own risk..</CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>
<HR WIDTH="100%">
<P>Update history:
<P>0.5.03 - 11/08/99 - Corrected a critical error in the documentation
<BLOCKQUOTE>
<LI>
add_quantity and take_quantity had the last 2 parameters the WRONG WAY
AROUND: this would cause a crash.</LI>
</BLOCKQUOTE>
0.5.02 - 23/07/99 - Documented some forgotten functions
<BLOCKQUOTE>
<LI>
Documented forgotten function object_set_behaviour</LI>
<LI>
Documented new conversation functions [goto] (5.3.2) and [set_behaviour]
(5.4.1)</LI>
<LI>
Documented new features in flat.gam resource file (chapter 6)</LI>
</BLOCKQUOTE>
0.5.01 - 22/06/99 - Final checks for R 0.5
<BLOCKQUOTE>
<LI>
Documented forgotten functions transfer_to_pocket, force_from_pocket</LI>
<LI>
Documented forgotton functions choose_member and choose_leader</LI>
<LI>
Documented new function get_number</LI>
</BLOCKQUOTE>
0.5.0 - 05/6/99 - Release 0.50, totally new conversation engine
<BLOCKQUOTE>
<LI>
Inserted a new chapter 5: programming conversations (with the new script
system)</LI>
<LI>
Updated 1.4.1 so it is not obsolete anymore</LI>
<LI>
Updated 3.2.3 to add new flags and keywords</LI>
<LI>
Documented new Section:Rooftiles in 3.2.9</LI>
<LI>
Added new variables game_minute, game_hour, game_day, game_month, game_year</LI>
<LI>
Added undocumented functions transfer_object, get_first_object</LI>
<LI>
Added new functions replace_object,move_forward, move_backward, turn_l,
turn_r</LI>
<LI>
Added new functions add_quantity, take_quantity, wait_for_animation, lightning</LI>
<LI>
Added new functions find_object_with_tag, find_container</LI>
<LI>
Added new functions get_pflag, set_pflag, get_user_flag, set_user_flag,
get_yn</LI>
<LI>
Updated screenshots of editor.</LI>
<LI>
Added section 2.2.9 - setting an object's owner</LI>
<LI>
Added section 2.2.10 - editing an object's statistics</LI>
<LI>
Added section 2.2.11 - editing an object's behaviour</LI>
</BLOCKQUOTE>
0.4.1 - 28/3/99 - Release 0.41, VRM system changed to SeeR
<BLOCKQUOTE>
<LI>
Mentioned the graphical script editor in section 3.1.</LI>
<LI>
Updated the description of VRMs and how they are compiled in section 4.1</LI>
<LI>
Added new description of how you must use flags since 0.041</LI>
<LI>
Added new VRM functions get_flag and set_flag, see above</LI>
</BLOCKQUOTE>
0.4.0 - 18/1/99 - Release 0.4, rewrite of core map system
<BLOCKQUOTE>
<LI>
Removed sections 2.2.8 to 2.2.10, about obsolete features of the editor.</LI>
<LI>
Added new section 2.2.8, about editing objects inside containers</LI>
<LI>
Added new VRM functions redraw_map, line_of_sight, move_to_top and in_pocket</LI>
<LI>
Updated create_object and get_top_object, get_best_object etc.</LI>
<LI>
Added new vrm function <B>move_object</B> <B>which you must use instead
of modifying the X and Y coordinates</B></LI>
<LI>
Added new functions spill_contents and spill_contents_at</LI>
<LI>
Added new flags etc to section 3.2.3 and 4.2.4</LI>
<LI>
Added NODRIFT command to Section: Sound in section 3.2.7</LI>
<LI>
Added Section 3.2.7 and 3.2.8 to the index (oops)</LI>
<LI>
Added Part 5, about the .GAM file</LI>
<LI>
Described partially-solid objects in section 3.2.3</LI>
</BLOCKQUOTE>
0.3.1 - 5/9/98
<BLOCKQUOTE>
<LI>
Added section 2.1.4, about cut and paste</LI>
<LI>
Added section 2.1.5, about the tile randomiser</LI>
<LI>
Added section 2.1.6, about bulk replace</LI>
<LI>
Added two new .cel files to section 1.4.1</LI>
<LI>
set_darkness changed to a single level instead of RGB levels</LI>
</BLOCKQUOTE>
0.3.0 - 15/6/98
<BLOCKQUOTE>
<LI>
Fixed some typos.</LI>
<LI>
Added 'light' and 'enemy' to section 4.2.4</LI>
<LI>
Added new function 'set_darkness' to section 4.3.4</LI>
</BLOCKQUOTE>
0.2.8 - 15/6/98
<BLOCKQUOTE>
<LI>
Added new function 'delay' to section 4.3.2</LI>
<LI>
Added new function 'start_song' to section 4.3.2</LI>
<LI>
Updated entry for 'stop_song' in section 4.3.2</LI>
</BLOCKQUOTE>
0.2.7 - 11/6/98
<BLOCKQUOTE>
<LI>
Added new function 'rnd' to section 4.3.2</LI>
<LI>
Added new function 'restart' to section 4.3.4</LI>
</BLOCKQUOTE>
0.2.6 - 10/6/98
<BLOCKQUOTE>
<LI>
Added the 'ifHurt' parameter to section 3.2.3</LI>
<LI>
Fixed typo in the example of section 4.3.2</LI>
<LI>
Added 'object->stats->oldhp' to section 4.2.4</LI>
</BLOCKQUOTE>
0.2.5 - 9/6/98
<BLOCKQUOTE>
<LI>
Sections 1.4.4 and 1.4.5 are re-written because the music is now script-controlled.not
loaded incrementally.</LI>
<LI>
Added the overlay flag to section 3.2.2</LI>
<LI>
Added the post_overlay flag to section 3.2.3</LI>
<LI>
Added the wielded flag to section 3.2.3</LI>
<LI>
Wrote about the ifDead parameter for objects in section 3.2.3</LI>
<LI>
Added Section 3.2.7, about the new sound loaders</LI>
<LI>
Added Section 3.2.8 about the new music loaders.</LI>
<LI>
Added the new system variable 'victim' to section 4.2.4</LI>
<LI>
Described new function set_object_sequence in section 4.3.1</LI>
<LI>
Described new printxy function in section 4.3.2</LI>
</BLOCKQUOTE>
0.2.4 - 21/5/98
<BLOCKQUOTE>
<LI>
Wrote about the automatic object placement in section 2.2.8 and 3.2.3</LI>
<LI>
How to put objects into containers. Section 2.2.10</LI>
</BLOCKQUOTE>
0.2.3 - 20/5/98
<UL>
<LI>
Updated screenshots of the editor to latest version.</LI>
<LI>
Forgot a number of vital things in the pascal-c chart.</LI>
<LI>
Update tag documentation in the editor.</LI>
<LI>
Added TRANSLUCENT flag to section 3.2.3 and 4.2.4</LI>
</UL>
0.2.2 - 15/5/98
<UL>
<LI>
Added CONTAINER flag to section 3.2.3 and 4.2.4</LI>
<LI>
Added is_solid to section 4.3.1</LI>
<LI>
weight_object is now called weigh_object. This was a typo in the
documentation.</LI>
</UL>
<HR WIDTH="100%">
<P>Contents
<P>Part 1 : Introduction
<BLOCKQUOTE>1.1 What is the IRE?
<BR>1.2 What do I need to edit the IRE?
<BR>1.3 File formats
<BLOCKQUOTE>1.3.1 - Graphics
<BR>1.3.2 - Sounds
<BR>1.3.3 - Music</BLOCKQUOTE>
1.4 Where the files should be stored
<BLOCKQUOTE>1.4.1 - RES
<BR>1.4.2 - RES\BACKINGS
<BR>1.4.3 - RES\CODE
<BR>1.4.4 - RES\MUSIC
<BR>1.4.5 - RES\SOUND
<BR>1.4.6 - RES\SPRITES</BLOCKQUOTE>
1.5 How the program searches for files</BLOCKQUOTE>
Part 2 : The IRE map editor
<BLOCKQUOTE>2.1 Backgrounds
<BLOCKQUOTE>2.1.1 getting familiar with the editor
<BR>2.1.2 placing tiles on the map
<BR>2.1.3 selecting tiles
<BR>2.1.4 cut and paste
<BR>2.1.5 Randomising tiles
<BR>2.1.6 Bulk Replacing</BLOCKQUOTE>
2.2 Sprites
<BLOCKQUOTE>2.2.1 The editor in sprites mode
<BR>2.2.2 Creating sprites
<BR>2.2.3 Moving sprites
<BR>2.2.4 Changing sprites
<BR>2.2.5 Setting the direction
<BR>2.2.6 Deleting sprites
<BR>2.2.7 Tagging Objects
<BR>2.2.8 Editing Containers
<BR>2.2.9 Setting a character's individual name
<BR>2.2.10 Editing an object's individual statistics
<BR>2.2.11 Editing an object's individual behaviour</BLOCKQUOTE>
2.3 Rooftops
<BLOCKQUOTE>2.3.1 The editor in rooftops mode
<BR>2.3.2 Editing rooftops</BLOCKQUOTE>
</BLOCKQUOTE>
Part 3 : The IRE script file
<BLOCKQUOTE>3.1 What is the script file and what does it do?
<BR>3.2 Script file sections
<BLOCKQUOTE>3.2.1 Section: Sprites
<BR>3.2.2 Section: Sequences
<BR>3.2.3 Section: Characters
<BR>3.2.4 Section: Descriptions
<BR>3.2.5 Section: Code
<BR>3.2.6 Section: Tiles
<BR>3.2.7 Section: Sounds
<BR>3.2.8 Section: Music
<BR>3.2.9 Section: Rooftiles</BLOCKQUOTE>
</BLOCKQUOTE>
Part 4 : The IRE VRM system
<BLOCKQUOTE>4.1 What are VRM files?
<BLOCKQUOTE>4.1.1 The VRM concept
<BR>4.1.2 How VRMs are made
<BR>4.1.3 A VRM tutorial
<BR>4.1.4 Rules for writing VRMs
<BR>4.1.5 How the example works
<BR>4.1.6 Data Types</BLOCKQUOTE>
4.2 The OBJECT
<BLOCKQUOTE>4.2.1 Introducing the OBJECT
<BR>4.2.2 Creating an OBJECT from scratch
<BR>4.2.3 Modifying OBJECTs
<BR>4.2.4 OBJECT Reference guide
<BR>4.2.5 The TILE</BLOCKQUOTE>
4.3 Function Reference
<BLOCKQUOTE>4.3.1 Object functions
<BR>4.3.2 IO functions
<BR>4.3.3 Flow control functions
<BR>4.3.4 Miscellaneous functions</BLOCKQUOTE>
4.4 System Variables
<BR>4.5 Keyboard Macros</BLOCKQUOTE>
Part 5 : Programming Conversations
<BLOCKQUOTE>5.1 Overview
<BR>5.2 Page structure and simple commands
<BLOCKQUOTE>5.2.1 Simple Linking
<BR>5.2.2 Interactive Linking
<BR>5.2.3 Images
<BR>5.2.4 Setting the text colour
<BR>5.3 Advanced conversations - Conditional branching
<BLOCKQUOTE>5.3.1 Checking for an object
<BR>5.3.2 Important tips
<BR>5.3.3 Checking for a party member
<BR>5.3.4 Using your own flags
<BR>5.3.5 Personal flags</BLOCKQUOTE>
</BLOCKQUOTE>
5.4 Manipulating the game world
<BLOCKQUOTE>5.4.1 Calling VRM functions
<BR>5.4.2 Creating and destroying objects
<BR>5.4.3 The theory of the conservation of money</BLOCKQUOTE>
</BLOCKQUOTE>
Part 6 : Game description files
<BLOCKQUOTE>6.1 Crucial lines
<BR>6.2 The text console
<BR>6.3 Loading screen</BLOCKQUOTE>
Part 7 : Conclusion and Contact info
<P>
<HR WIDTH="100%">
<BR>
<BR>
<BR>
<CENTER>
<H2>
Part 1 - Introduction</H2></CENTER>
<H3>
1.1 - What is the IRE?</H3>
In 1993 I got hold of a computer roleplaying game called Ultima 6.
This game changed my life forever.
<BR>Previously I'd seen DCworld, an Ultima 5-type game editor. Ultima
6 was a whole new level above DCworld, like the difference between Wolfenstein
and Doom.
<BR>When I buy new hardware, the bottom line is, will U6 work? No
U6, no sale.
<P>I spent the next few years in Ultima 6, hacking it, twisting it, folding
it into new shapes.
<BR>I wrote a set of tools which hack the program, and allow you create
new worlds, but there is a limit.
<BR>Ultima 6 has some pretty strange data structures which I never did
figure out completely.
<P>In '94 I started an abortive attempt to make a U6 clone, which was codenamed
U6C. I couldn't draw a player and it bombed.
<P>After the failure of Avios to run satisfactorily on the P200 I am using,
despite intense optimisation, I decided to stop working on it, and turned
instead to making a 'perfect' ultima 6 type game. This is what I
have so far.
<P>The IRE is a Computer Role-Playing Game which takes most of its ideas
from Ultima 6, and some from Ultima 7.
<P>The main difference between the design of U6 and IRE, is that IRE is
designed from the ground up to allow someone to edit it. Ultima 6
was not designed this way.
<BR>
<H3>
1.2 - What will I need to edit the IRE?</H3>
There are many features you can edit, and you will need a variety of programs
to edit each different part of the game.
<BR>Most editors are provided, but some you will have to acquire yourself.
<P>First, we shall look at all the resources that the game can use.
<P><B>Map files</B>
<P>The map file is the world in which the player inhabits. At present
the engine can only support one map per game, although this will probably
change later.
<P><B>Font</B>
<P>The font is the character set used in the game. The characters
are fixed-space 8x8 letters, and are stored in the raw bit-packed format
used by Arthur Barr's font editor.
<P><B>Script file</B>
<P>The script file is central to IRE. It is a description file that
describes a game written using IRE.
<BR>It tells the program which sprites will be loaded, it binds the sprites
into animation sequences and defines the behaviour of all characters and
objects in the game.
<P>The script file is described in detail in Chapter 3.
<P><B>VRM files</B>
<P>Although the script coordinates everything, it is the VRM files which
do the actual work.
<BR>VRMs (or Virtual Runnable Modules) are written in C (using my library
functions) and get loaded into the game as it starts. Each game event
is driven by a corresponding VRM.
<P>VRM programming is described in detail in Chapter 4.
<P><B>Internal graphics</B>
<P>Certain parts of the IRE system have their own sprites, such as the
mouse pointer and the volume slider. These graphics are not controlled
by the script file (although they might be later), and the program will
attempt to load them itself. The internal graphics are 256-colour
and stored in the Animator .CEL format. You can also use PCX if you
prefer.
<BR>If you need to convert between CEL and another format, try using PICTVIEW
by Jan Patera.
<P><B>Sprites and tiles</B>
<P>Sprites and tiles are all defined in the script file, and are loaded
in as the script is parsed.
<BR>They are stored in .CEL or .PCX format, and may have either 256 colours
or 16.7 million.
<P><B>Backing pictures</B>
<P>At present backing pictures are loaded in by the program, like the internal
graphics of the mouse pointer and the volume slider. They must be
in PCX format and either 640x400 in size, or 640x480.
<BR>They can be 8-bit or 24-bit PCX files.
<P><B>Game package</B>
<P>Once you have a finished game and you are ready to distribute it, you
can pack all the datafiles into one large resource file. IRE uses
the .rar files from Eugene Roschal's fine archiver, RAR.
<BR>The files must NOT be compressed or the game will be unable to read
them.
<BR>Set the compression method to STORE (ALT-M) in order to do this.
<BR>
<P><B>Summary</B>
<BR>
<TABLE BORDER COLS=3 >
<TR>
<TD>
<CENTER><B>Property to edit</B></CENTER>
</TD>
<TD>
<CENTER><B>Recommended Editor</B></CENTER>
</TD>
<TD>
<CENTER><B>Comments</B></CENTER>
</TD>
</TR>
<TR>
<TD>Map files</TD>
<TD>The IRE editor</TD>
<TD></TD>
</TR>
<TR>
<TD>Font</TD>
<TD>Arthur's font editor (supplied)</TD>
<TD></TD>
</TR>
<TR>
<TD>Script file</TD>
<TD>Any text editor</TD>
<TD>This is covered in part three</TD>
</TR>
<TR>
<TD>VRM files</TD>
<TD>SEERC is supplied to build them</TD>
<TD>This is covered in part four</TD>
</TR>
<TR>
<TD>Internal graphics</TD>
<TD>Autodesk Animator</TD>
<TD>You can use PICTVIEW by Jan Patera to convert graphics to CEL files</TD>
</TR>
<TR>
<TD>Sprites and Tiles</TD>
<TD>Any PCX editor</TD>
<TD></TD>
</TR>
<TR>
<TD>Backing pictures</TD>
<TD>Any PCX editor</TD>
<TD></TD>
</TR>
<TR>
<TD>Game package</TD>
<TD>The RAR archiver, shareware</TD>
<TD></TD>
</TR>
</TABLE>
<H3>
1.3 - File formats</H3>
The program uses a fairly narrow selection of file formats, so you may
have to use some conversion software to get the data from your favourite
package into IRE.
<H4>
1.3.1 - Graphics formats</H4>
The IRE uses two main graphics formats, .CEL and .PCX.
<BR>In future releases, all the loaders will be able to take either format,
but at present, some will only take one or the other.
<P><B>PCX files.</B>
<P>PCX files are straightforward, so any package that creates a .PCX should
produce something readable by IRE.
<P>Here are some known caveats:
<P>The PCX files must be compressed using the runlength method. This
is the standard, but if you do somehow manage to make an uncompressed PCX
file, the program will likely choke on it.
<P>The PCX files must be either 8-bit or 24-bit. 1,2,4 or 16-bit
PCX files will be rejected and the program will stop with an error.
<P><B>CEL files.</B>
<P>The .CEL files refer to Autodesk Animator .CEL files. This means
Autodesk Animator, <I>not</I> Animator Pro. Animator Pro uses .FLI
files and just calls them .CEL files.
<P>If you try and load a .CEL file created by Animator Pro, IRE will go
back to DOS with a panic message saying that the .CEL file you gave it
"is not a .CEL file".
<P>If you don't have the original Animator, use .PCX files instead of .CEL.
<P>Alternatively, get RSE 2.00, a freeware program which is able to read
and write .CEL files compatible with IRE.
<P><B>Graphics sizes.</B>
<UL>
<LI>
For sprites, any size of PCX file will do.</LI>
<LI>
CEL files should not exceed 320x200. Files larger than this have
not been tested, but might be achievable with PICTVIEW.</LI>
<LI>
The map tiles must be 32x32 in size, or very interesting things will start
to happen.</LI>
<LI>
Backing pictures must be either 640x400 or 640x480, or the backing appears
corrupted.</LI>
</UL>
<H4>
1.3.2 - Sound formats</H4>
The IRE sound engine can load .WAV files produced by most applications.
<BR>The .WAV files can be 8 or 16 bit, and any frequency up to 44Khz is
allowed.
<P>Stereo .WAV files are <I>not</I> supported however.
<P>I don't know if .WAV files can be compressed, but it they can, that
won't work either.
<BR>
<H4>
1.3.3 - Music formats</H4>
The IRE music player uses MOD files, a digital music system originating
from the Commodore Amiga's somewhat creative sound circuits. Lack
of any music chips at all gave rise to the .MOD file, a four-channel digital
music system.
<P>The IRE's sound engine can support the following types of .MOD file:
<BR>
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD>File name</TD>
<TD WIDTH="25%">Name</TD>
<TD>Channels</TD>
<TD>Comments</TD>
</TR>
<TR>
<TD WIDTH="15%">.MOD</TD>
<TD WIDTH="25%">Protracker module</TD>
<TD WIDTH="10%">4</TD>
<TD>Generic module format</TD>
</TR>
<TR>
<TD>.MTM</TD>
<TD>?</TD>
<TD>16</TD>
<TD>More obscure format</TD>
</TR>
<TR>
<TD>.S3M</TD>
<TD>Screamtracker III</TD>
<TD>32</TD>
<TD>Popular module format</TD>
</TR>
<TR>
<TD>.STM</TD>
<TD>Screamtracker II</TD>
<TD>4</TD>
<TD>PC extension to the MOD format</TD>
</TR>
<TR>
<TD>.ULT</TD>
<TD>Ultratracker</TD>
<TD>32</TD>
<TD>Originated on the (late) GUS soundcard</TD>
</TR>
<TR>
<TD>.XM</TD>
<TD>Fastracker</TD>
<TD>32</TD>
<TD>Rival format to S3M
<BR>Both FT1 and FT2 variants supported</TD>
</TR>
</TABLE>
<P>Before you race off, remember that there is a maximum of 32 channels
available to the sound engine.
<P><I>If you use all 32 for the music there will be none left for the sound
effects.</I>
<P>The amount of channels reserved for the music and sound is set in the
game's config file, <I>not</I> the script file. By default it is
16+4, i.e. 20 channels in total.
<BR>
<H3>
1.4 - Where the files should go</H3>
It is important to understand how IRE looks for it's resources, so that
you know where to put the new files.
<P>Each IRE game will have a directory of its own, and it will look for
the files in various subdirectories
<BR>in the tree.
<P>By default, IRE will look in the RES directory, so we'll refer to as
the RES directory in future.
<BR>(RES is shorthand for resources).
<P>Note that it does not have to be RES, and you should call your directory
something else when you develop an IRE game.
<BR>(It's controlled by your .GAM file, which is described in Part 7)
<P>If you've followed the previous section, you should have some idea of
the resources that each IRE game will use.
<P>Unless the file is requested by the system itself, it can go anywhere
you like, as the script file will contain the full path of each file.
<P>Internal Graphics and the script file itself, must go in particular
places, which will be described in detail later. Where you put the
other resources is up to you.
<P>The files are generally organised in this way:
<P><IMG SRC="filetree.gif" HEIGHT=145 WIDTH=138>
<BR>
<BR>
<P><B>1.4.1 - RES</B>
<P>The RES directory <I>must</I> contain the following files:
<BR>
<TABLE BORDER WIDTH="75%" >
<TR>
<TD>main.txt</TD>
<TD>The script file</TD>
</TR>
<TR>
<TD>arrow00.cel</TD>
<TD>The mouse pointer image</TD>
</TR>
<TR>
<TD>soundbar.cel</TD>
<TD>The volume slider backing image</TD>
</TR>
<TR>
<TD>slider1.cel</TD>
<TD>The slider that has been selected</TD>
</TR>
<TR>
<TD>slider2.cel</TD>
<TD>The slider that is not selected</TD>
</TR>
<TR>
<TD>font.dat</TD>
<TD>The typeface used in the game</TD>
</TR>
<TR>
<TD>eyesore.cel</TD>
<TD>Used by the editor for the 'Random Tile'</TD>
</TR>
<TR>
<TD>warning.cel</TD>
<TD>Shown if the Random Tile appears in the game</TD>
</TR>
<TR>
<TD>credits.dat</TD>
<TD>ANSI credits at end, like ENDOOM in Doom</TD>
</TR>
<TR>
<TD>help.txt</TD>
<TD>A conversation file that is run when F1 is pressed, see Part 5</TD>
</TR>
</TABLE>
<P><B>1.4.2 - RES\BACKINGS</B>
<P>The RES\BACKINGS directory <I>must</I> contain the following file:
<BR>
<TABLE BORDER WIDTH="75%" >
<TR>
<TD>panel.pcx</TD>
<TD>The background image of the game status area</TD>
</TR>
</TABLE>
Additionally, I store the map tiles in this directory, but as each sprite's
location is defined in the script file, this is just a matter of preference.
<BR>
<P><B>1.4.3 - RES\CODE</B>
<P>You need a place to store the VRM files used in the game, I called mine
RES\CODE.
<BR>Again, the VRMs are defined in the script file, so you can put them
anywhere you like,
<BR>RES\VRM might be another choice.
<P>You could keep them on another drive, or even just in the RES\ directory,
although that would be untidy.
<BR>
<P><B>1.4.4 - RES\MUSIC</B>
<P>You need a place to store the music files. I keep them in RES\MUSIC.
<BR>As of kernel version 0.025, the music is defined in the script file,
so you can put them anywhere you like,
<BR>RES\MODS might be another choice.
<P>You could keep them on another drive, or even just in the RES\ directory,
although that would be untidy.
<P><B>1.4.5 - RES\SOUND</B>
<P>You need a place to store the sound effects. I keep them in RES\SOUND.
<BR>As of kernel version 0.025, the music is defined in the script file,
so you can put them anywhere you like,
<BR>RES\WAVS might be another choice.
<P><B>1.4.6 - RES\SPRITES</B>
<P>You need a place to store the sprites used in the game, I called mine
RES\SPRITES.
<BR>Again, the sprites and other game images are defined in the script
file, so you can put them anywhere you like, maybe RES\OBJECTS.
<H3>
1.5 - The search order</H3>
The search order is quite important.
<P>When it tries to load a file, it will look for it in the following order:
<BR>
<OL>
<LI>
In the IRE directory, e.g. C:\IRE\</LI>
<LI>
In the RES directory, e.g. C:\IRE\RES\</LI>
<LI>
In a specified .RAR file, e.g. RES.RAR</LI>
</OL>
So, if a file is found in the IRE directory it will take precedence over
a file found in either of the other two places.
<P>NOTE: The map editor will ONLY load maps from the IRE directory,
and not from the RES or RAR sources. All other files, the graphics
and such can be loaded from other sources.
<BR>
<P>
<HR WIDTH="100%">
<BR>
<BR>
<BR>
<CENTER>
<H2>
Part 2 - The map editor</H2></CENTER>
The IRE map consists of three layers:
<P>A Background
<BR>Objects and characters
<BR>Rooftops
<BR>
<BR>
<H3>
2.1 Editing the background</H3>
Backgrounds are made up of tiles, which are 32x32 in size.
<BR> These tiles are arranged in a huge grid, which makes up the map.
<H4>
2.1.1 - getting familiar with the editor</H4>
This is a screenshot of the editor in Background mode, we will refer to
it as the editor is described.
<P>First, look the main window. This is the map, as it will
appear when the game is being played.
<BR>You can pan around the map using the cursor keys, or the four arrow
buttons to the right of the window.
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="editback.gif" HEIGHT=480 WIDTH=640></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>Also, note the two black panels on the far right-hand side of the screen.
<P>They control the screen display, and allow you to switch off the other
layers of the level if you find they get in the way while you are editing.
<P>"SPRITES ON" means that the movable objects in the game, such as the
player, other characters and similar things will be displayed. If
you click once in the black area, it will read "SPRITES OFF" instead, and
any sprites visible on the map will disappear while you are editing the
backgrounds.
<P>Similarly, "ROOFTOPS ON" means that the highest-level objects in the
game, normally the roofs of buildings, will be displayed. If you
click in the black area, it will change to "ROOFTOPS OFF". Rooftops
are not displayed by default, as you are mainly going to edit the insides
of buildings and that
<BR>is generally impossible with the roof in the way.
<H4>
2.1.2 Placing tiles on the map</H4>
At it's most simple, map editing consists of just clicking on the map,
and drawing the tiles on it.
<P>Looking to the right of the main map window, are two small squares,
marked 'L' and 'R'.
<BR>This shows the currently selected tiles, which will appear when you
click on the map.
<P>The tile in the 'L' window is the tile that will appear if you click
with the left button, and the 'R' tile is the tile that will appear if
you click with the right mouse button.
<P>This means that you can use the left mouse button to do most of your
drawing, and set the right-button to a common sort of tile and use it to
erase mistakes without having to select another tile from the list.
<H4>
2.1.3 Selecting tiles</H4>
Looking back at the editor screenshot, there is a bar at the bottom which
contains all the tiles you can use in the map.
<P>The bar has some buttons at either end, allowing you to scroll around
the tiles, one at a time or at high speed, through the list of tiles.
<P>To choose a tile, move the mouse over the bar, and click on the tile
you want, with the mouse button you wish to contain this tile.
<P>For example, if you click on a wall with the left button, the wall will
appear on the 'L' box, and drawing with the left button will draw walls.
<P>Now, you can doodle around on the map with that particular tile.
<P>Adding new kinds of tile is dealt with in Chapter 3.
<H4>
2.1.4 Prefabs</H4>
Support for prefabricated parts is not fully implemented at this stage,
so if you use the buttons they work like cut-and-paste.
<BR>Clicking on 'Get Prefab' will copy the current screenful of tiles into
a 'clipboard', and 'Put Prefab' will put the contents of the clipboard
onto the screen.
<P>When it is completed, the Prefab system will support hundreds of clipboards
that are stored to disk so you can create a library of commonly-used map
sections.
<H4>
2.1.5 Randomising tiles</H4>
Introduced in IRE 0.3, is support for randomising sections of the map,
for instance to make grass that does not repeat.
<P>To achieve this, do the following:
<P>1. Click on the 'Random Tile' button at the bottom of the screen.
This looks hideous to remind you that the tiles are still on the map.
<P>2. Draw the 'Random Tile' over the section you want to be randomised.
If it's a fairly large area, you can use the 'Clear L' or 'Clear R' buttons
to fill the screen with the current tile.
<P>3. Now, choose the tiles that you want it to pick from. These
must be grouped together on the tile bar: you cannot choose from different
tiles scattered everywhere.
<P>4. To do this, Left-Click on the first tile in the group, and Right-Click
on the last tile in the group.
<P>(For example, with the grass, left-click on the first tile, and right-click
on the seventh), the editor will pick tiles <I>between</I> these two.
<P>5. Click on the Randomise button. All the yellow tiles will
be replaced with a selection from the group you chose in step 4.
<H4>
2.1.6 Bulk Replace</H4>
Suppose you wanted to turn all the grass in the map into something else.
You can 'reverse' the action of the randomiser above, in a similar manner.
<P>1. Choose the group of tiles that you want to isolate, for example
the grass. Like Step 4 in the Randomiser, you must use the Left and
Right buttons to choose the first and last tile to be replaced.
<P>2. Click on 'Replace Tiles', and all the tiles in the group you've
selected will turn into the Random Tiles!
<P>3. Now you can use the randomiser to turn them into mud or whatever
you fancy.
<BR>
<H3>
2.2 - Editing Sprites</H3>
<H4>
2.2.1 - The editor in Sprites mode</H4>
This is a screenshot of the editor in Sprite mode. There are some
subtle differences between Background and Sprite mode, so we will look
at each item again.
<P>First, look the main window. This is still the map, but note that
the character has a white box around him. This is because the player
has been selected, and he is the object being edited.
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="editspri.gif" HEIGHT=480 WIDTH=640></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>Now, look again at the two black panels on the far right-hand side of
the screen.
<P>"ROOFTOPS OFF" has not changed at all, but "SPRITES ON" has changed
to "EXCLUDE OFF".
<P>This switch still controls the display of the sprites, but now it will
switch off <I>most</I> of the sprites if it is enabled, instead of the
whole lot.
<BR>Specifically, "EXCLUDE ON" will display only the currently selected
object, i.e. the one with the white box. It is used for situations
when the other objects get in the way of the one you are positioning.
<H4>
2.2.2 - Creating a new sprite</H4>
To create a new sprite, click on the button marked 'New Item'.
<P>When you do this, a box will appear, showing you a list of all the objects
in the game, and displaying a picture of each one.
<P>When you've found the one you want, using the cursor keys to scroll,
press ENTER and the object will appear in the middle of the screen.
<P>The object will be highlighted with the white selection box, and you
can drag it to the proper place.
<P>To create copies of this object quickly, you can press INS (or INSERT)
on the keyboard, and a copy of the object will appear wherever the mouse
pointer is on the map. If the mouse pointer is not over the map,
no object will be created.
<P>The INS method creates a copy of the selected object. If no object
is selected, it will pop up the creation list and the object will appear
in the centre of the screen, like 'New Item'.
<P><B>Individual Names</B>
<P>An object can have its own special name, for example 'Kenny McKormick',
which is used when you talk to the person, among other things.
<P>Below the map is the panel marked 'Individual Name:'. You can
click on this to enter the object's individual name.
<H4>
2.2.3 - Selecting and moving objects</H4>
To select an object, just left-click on it, and it should become highlighted.
<BR>If another object has already been selected first, left-click on an
empty space to clear the selection first.
<P>You can move objects by dragging them around the map with the left button,
or, you can instantly move an object (without dragging) by right-clicking
where you want the object to go. This is often useful if the selected
object is off-screen.
<H4>
2.2.4 - Changing an object's direction</H4>
Looking at the screenshot again, there is a second set of arrow-buttons
in the middle of the screen, on the right hand side.
<P>When an object is selected, <I>one</I> of these arrows should be depressed.
<BR>This is the direction in which the object is facing.
<P>For example, the player can face in any of the four directions.
To make the player face left, select the player and click on the left arrow
button.
<BR>The player should now face left.
<P>Many simple objects only have one direction, in which case the arrow
buttons will have no effect. Doors and windows usually have two directions,
Up/down for the horizontal position, and Left/Right for the vertical position.
<P>The directions an object has are defined in the script file.
<H4>
2.2.5 - Changing the object's type</H4>
At some stage you will decide that you want to change one object into another.
<BR>You can do this by selecting the object, and then clicking on the 'Edit
Item' button, (or pressing ENTER).
<P>This will pop up the creation list again, and the object will change
to the new type. (By default, it will highlight the type of object it was
before in the menu.)
<BR>
<H4>
2.2.6 - Deleting an object</H4>
To delete and object first select it, and then click on 'Delete Item',
or press the 'DEL' key if you prefer.
<P>There will be no warning before the sprite is removed, so take care.
<H4>
2.2.7 - Tagging objects</H4>
On the bottom right hand side of the screen are three buttons, 'Find Tag',
an entry box and 'Next Free Tag'.
<P>The entry box is used to assign a control value to certain objects.
<P>What the object does will depend on the script assigned to it in the
main script file, but it will often be necessary to mark certain objects
with a tag.
<P>One of the main uses of tags will be locked doors.
<BR>A door can be open, shut, or locked shut.
<BR>There will also be a key to lock or unlock the door.
<P>In these cases, the key and the door must both have the same Tag number
for the key to fit the door.
<P>Click on the number in the black entry box to enter a different tag
number.
<P>The button marked 'find tag' will ask you for a number, and then search
all the objects in the game to find one with the appropriate tag number.
It will not be able to show the object if it is inside a container.
<P>The button marked 'Next free tag' will find the first tag number which
does not exist in the game.
<H4>
2.2.8 - Containers</H4>
In release 0.4 it is now possible to edit containers.
<BR>(Some objects, such as bottles, will contain objects inside as soon
as they are created. These are determined by the script file.)
<P>Container editing is done using the new 'Edit Pockets' button.
<BR>First, select the object you wish to modify. When it is highlighted,
you can click on 'Edit Pockets', which will display a list of the objects
which are in the container. You should see this:
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="editpock.gif" HEIGHT=480 WIDTH=640></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>There are currently four things you can do with containers:
<P>1. Create a new object inside a container
<BR>2. Delete an object inside a container
<BR>3. Move an object out of a container
<BR>4. Bring an outside object into the container.
<P><B>Creating and Removing objects</B>
<P>'Create object' is the button used to create an object. Clicking
on this will bring up the familiar creation menu.
<P>To remove an object, first click on the object you want to remove in
the list. It will turn red, indicating that it has been selected.
<BR>Then click on 'Remove object' and the chosen object will disappear.
<P><B>Moving Objects out of the container.</B>
<P>First, highlight the object you want to move out of the container.
<BR>Then click on 'Move Outside' and the object will disappear from the
list. When you leave the pocket editing window, you will
<BR>find the object on top of the container.
<P><B>Bringing Objects in to the container.</B>
<P>First, get out of the pocket editor.
<BR>Select the container, and place it ON TOP of the object you want to
be inside the container.
<BR>Now, making sure the object is highlighted, click on 'Edit Pockets',
and choose 'Bring Inside'.
<BR>Press 'Y' to continue and the object will be there.
<P><B>CAVEAT</B>: It is not currently possible to edit the properties of
an object while it is inside a container. If you wish to adjust the
direction or tag number of an object in a container, you will have to move
it out of the container first.
<BR>
<H4>
2.2.9 - Setting an object's owner</H4>
In release 0.5 objects can now have owners, who get angry if their object
is stolen.
<BR>In order for this to work, you must specify who owns the object.
<P>At the bottom of the panel is a field marked 'Object is property of:'.
<BR>If you click on this while an object is selected, you will be asked
to click on the person who owns the object.
<P>Here is the screen you will see:
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="setowner.gif" HEIGHT=480 WIDTH=640></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>TYou can pan around the map to find the person who owns it, and click
on them. They will be highlighted red when an object they own has
been selected.
<P>Alternatively you can choose the person from a list (of all objects
which are marked as 'Person' and have an individual name).
<P>If you decide that the object should be public property, you can click
on 'Make Public Property'.
<BR>
<H4>
2.2.10 - Changing an object's statistics</H4>
In release 0.5 it is now possible to change the statistics of a single
object without using the scriptfile.
<BR>This allows you to create special variations of an object by giving
it individual properties.
<BR>It also allows you to specify the number of objects in a pile if you
have a group item, such as a heap of coins.
<P>This is done using the 'Statistics' button.
<P>First, select the object you wish to modify. When it is highlighted,
you can click on 'Statistics', which will display the properties you can
edit. You should see this:
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="editstat.gif" HEIGHT=480 WIDTH=640></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>This should be self-explanatory.
<P><B>2.2.11 - Changing an object's behavior</B>
<P>In release 0.5 you can also change the way an individual object interacts
with the rest of the world, by giving it its own unique set of functions.
<P>This is done using the 'Behaviour' button.
<P>First, select the object you wish to modify. When it is highlighted,
you can click on 'Behaviour', which will display the properties you can
edit. You should see this:
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="editbeha.gif" HEIGHT=480 WIDTH=640></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>Each of the boxes (except Speech File) is a VRM function which is called
when the event happens. You can choose this from a list.
<P>Speech File is the only one which is not a VRM file: instead you enter
the path to the file containing the conversation.
<BR>In the current release, there is no list of files. However the
program will check if the filename you have entered is correct, and warn
you if it does not exist.
<BR>
<H3>
2.3 - Editing Rooftops</H3>
<H4>
2.3.1 - The editor in Rooftop mode</H4>
This is a screenshot of the editor in Rooftop mode.
<BR>As you can see, the editor is exactly the same as for Background Tiles,
so familiarise yourself with the Background editor first.
<CENTER>
<P><IMG SRC="editroof.gif" HEIGHT=480 WIDTH=640></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<H4>
2.3.2 - Editing rooftops</H4>
Rooftops are similar in concept to Background tiles, except that background
tiles will interact with sprites.
<P>Rooftops are completely separate and are for decorative purposes only.
<P>As the name implies, Rooftops are special tiles that are drawn above
everything else in the game. They are not always drawn, and the rooftop
layer can be shown or removed at will by VRM scripts. By default,
they will be removed if the player is underneath a tile.
<P>At the bottom of the screen is the set of tiles that can be used.
These are defined in the script file.
<BR>Each tile is a single frame, and it may or may not cause the roof to
disappear when the player is underneath it.
<BR>(You don't want this to happen when the player is standing outside
the building and the roof is overhanging.)
<P>Basically you just click and paint the roof tiles. The first tile
in the list is blank and can be used to erase bits of roof.
<BR>
<HR WIDTH="100%">
<BR>
<BR>
<BR>
<CENTER>
<H2>
Part 3 - The Script File</H2></CENTER>
<H3>
3.1 - What is the script file and what does it do?</H3>
Although you can use the default objects and their behaviours to good effect,
as a 'super-ultima-6' engine, you will at some stage want to add your own
graphics and objects to the game.
<P>To do this you must go into the main script file.
<BR>You can either do this manually, or you can use the graphical Script
editor, SCRIPTER.
<BR>Scripter is not documented yet, but if you read this chapter and then
play around with it, it should be easy enough to pick up.
<BR>
<P>The IRE script file is a description file that describes a game written
using
<BR>IRE. It tells the program which sprites will be loaded, it binds
the sprites
<BR>into animation sequences and defines the behaviour of characters in
the game.
<P>The script file is parsed by the game (and the editor) as it starts
up, and any errors it detects will be reported at this stage, with a red
and green error report (except in Linux and BeOS which are black-and-white).
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="error.gif" HEIGHT=201 WIDTH=313></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>If you intend to start playing around with script files, It is a good
idea to print this document out for reference.
<P>Here are some rules for writing script files:
<UL>
<LI>
The script file consists of several sections.</LI>
<LI>
Each section starts with the statement 'SECTION: sprites' for example.
The colon is necessary.</LI>
<LI>
# is used as a comment. Anything following a # will be ignored.</LI>
<LI>
The compiler will often IGNORE anything it does not understand.</LI>
<LI>
The case of the letters in the script file does not matter. For instance,
'WORD' is the same as 'word'.</LI>
<LI>
Spaces, whitespace and commas are all treated as spaces, and will appear
as a single space in the error dumps. Comments will not appear in
the error dump.</LI>
</UL>
<H3>
3.2 - Script file sections</H3>
Let's look at each section in turn.
<H4>
3.2.1 - Section: sprites</H4>
The sprites section is used to declare sprites that will be used in the
game.
<BR>All moving images and map tiles that appear in the game must be declared
here.
<P>The sprites section is basically a list consisting of the following
form:
<BR>
<PRE><TT><FONT SIZE=+1>SECTION: sprites</FONT></TT></PRE>
<TT><FONT SIZE=+1> name filename</FONT></TT>
<BR><TT><FONT SIZE=+1> name2 filename2</FONT></TT>
<BR><TT><FONT SIZE=+1> name3 filename3</FONT></TT>
<P>'name' is the title of the sprite. Every time you want to refer
to this image,
<BR>you should call it by this name.
<P>'filename' is the file containing the image. Images are stored
as autodesk animator .CEL files, or .PCX files.
<P>The list will continue until the next section is reached.
<BR>
<P>EXAMPLE:
<BLOCKQUOTE><TT>SECTION: sprites</TT>
<BLOCKQUOTE><TT>left_frame sprites\left01.cel</TT>
<BR><TT>left_frame2 sprites\left02.cel</TT>
<BR><TT>left_frame3 sprites\left03.cel</TT>
<P><TT>right_frame sprites\right01.cel</TT>
<BR><TT>right_frame2 sprites\right02.cel</TT>
<BR><TT>right_frame3 sprites\right03.cel</TT>
<P><TT>up_frame sprites\up01.cel</TT>
<BR><TT>up_frame2 sprites\up02.cel</TT>
<BR><TT>up_frame3 sprites\up03.cel</TT>
<P><TT>down_frame sprites\down01.cel</TT>
<BR><TT>down_frame2 sprites\down02.cel</TT>
<BR><TT>down_frame3 sprites\down03.cel</TT>
<BR> </BLOCKQUOTE>
</BLOCKQUOTE>
<H4>
3.2.2 - Section: sequences</H4>
The sequences section is used to declare all animation sequences.
<BR>Any animation, character or object that appears in the game must have
its
<BR>animation declared here.
<P>There are two ways to declare sequences, the 'traditional' way, and
the Quick
<BR>way.
<P>Traditionally, sequences are declared like this:
<P><TT>SECTION: sequences</TT>
<BLOCKQUOTE><TT>name sequence_name</TT>
<BR><TT><options></TT>
<BR><TT>framelist:</TT>
<BR><TT>frame1</TT>
<BR><TT>frame2</TT>
<BR><TT>...</TT>
<BR><TT>END</TT></BLOCKQUOTE>
'name'
<BR>NAME is the title of this animation. Every time you want to refer
to this animation, (in other parts of the script, or the Rooftops editor)
you will use this name.
<P>'framelist:'
<BR>FRAMELIST: marks the start of the list of frames. All frames in the
list are entries in the SPRITES section.
<P>'END'
<BR>END marks the end of the list of frames.
<BR>I.E, everything between framelist: and END will be treated as a frame,
and the program will try to find it in the sprite list.
<P><options>
<BR>You don't literally type '<options>'. Instead, this is the
part where you can specify some flags to control the animation.
<P>The following flags are understood by the game:
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD>pingpong</TD>
<TD>This makes the animation play backwards when it finishes.
<BR>E.g. frame 1, frame 2, frame 3, frame 2, frame 1</TD>
</TR>
<TR>
<TD>loops</TD>
<TD>This will make the animation repeat endlessly.</TD>
</TR>
<TR>
<TD>stepped</TD>
<TD>This makes the animation play only after each turn of the game, rather
than continuously.</TD>
</TR>
<TR>
<TD>overlay <sprite></TD>
<TD>This will make the specified sprite appear on top of the animation.
The overlay will be a single frame, not a real animation. For example,
the blood on the dead player is an overlay.</TD>
</TR>
</TABLE>
<P>'LOOPED' or 'LOOP' can be used as alternatives to 'LOOPS'.
<BR>
<P>Quick sequences
<P>Although the sequence declarations are OK for most things, it is over-long
for simple sequences which only need one frame. For example, map
tiles will usually consist of a single frame, and the above declaration
is overkill.
<P>To speed this up, I added a quicker, easier way to define simple sequences
<BR>for map tiles and other single-frame entities.
<P>These are called QuickNames, and they are a one-line sequence definition.
<P>Suppose you wanted to declare this sequence:
<BLOCKQUOTE><TT>name GrassTile</TT>
<BR><TT>framelist:</TT>
<BR><TT>grasstile00</TT>
<BR><TT>END</TT></BLOCKQUOTE>
Using a QuickName to declare the tile, it would be done this way:
<BR>
<BLOCKQUOTE>quickname GrassTile grasstile00</BLOCKQUOTE>
..which is a lot simpler (though much less flexible).
<P>For reference only, it can be noted that the actual declaration of a
QuickName
<BR>consists of three words.
<BR>
<BR>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" >
<TR>
<TD>1. quickname</TD>
<TD>Start the declaration</TD>
</TR>
<TR>
<TD WIDTH="25%">2. sequence_name</TD>
<TD>Identifying name of the sequence being created</TD>
</TR>
<TR>
<TD>3. sprite_name</TD>
<TD>A sprite from the SPRITES: section</TD>
</TR>
</TABLE>
<P>EXAMPLES:
<P><TT> SECTION: sequences</TT>
<P><TT> name MoveLeft</TT>
<BR><TT> framelist:</TT>
<BR><TT> left_frame</TT>
<BR><TT> left_frame2</TT>
<BR><TT> left_frame3</TT>
<BR><TT> END</TT>
<P><TT> name Moveright</TT>
<BR><TT> framelist:</TT>
<BR><TT> right_frame</TT>
<BR><TT> right_frame2</TT>
<BR><TT> right_frame3</TT>
<BR><TT> END</TT>
<P><TT> name Moveup</TT>
<BR><TT> framelist:</TT>
<BR><TT> up_frame</TT>
<BR><TT> up_frame2</TT>
<BR><TT> up_frame3</TT>
<BR><TT> END</TT>
<P><TT> name Movedown</TT>
<BR><TT> framelist:</TT>
<BR><TT> down_frame</TT>
<BR><TT> down_frame2</TT>
<BR><TT> down_frame3</TT>
<BR><TT> END</TT>
<P><TT> name Dead_Guy</TT>
<BR><TT> overlay blood</TT>
<BR><TT> framelist:</TT>
<BR><TT> dead_guy</TT>
<BR><TT> END</TT>
<P><TT> quickname First_Tile
tile_frame_1</TT>
<BR><TT> quickname Second_Tile
tile_frame_2</TT>
<H4>
3.2.3 - Section: Characters</H4>
The characters section is probably the most complex section in the script.
<BR>It is used to define characters that exist in the game. The editor
refers to characters as 'Sprites'. There must be at least one character
(the player).
<P>Characters are defined in this way:
<BR>
<BLOCKQUOTE><TT>SECTION: characters</TT>
<BLOCKQUOTE><TT>name charname</TT>
<BR><TT>hp 99</TT>
<BR><TT>dexterity 99</TT>
<BR><TT>weight 99</TT>
<BR><TT>damage 99</TT>
<BR><TT>description "You see a Thing."</TT>
<BR><TT>short "Thing"</TT>
<P><TT>ifDead thing_is_destroyed</TT>
<BR><TT>ifUsed thing_is_used</TT>
<BR><TT>ifTriggered thing_is_stood_on</TT>
<BR><TT>solid</TT>
<BR><TT>fixed</TT>
<P><TT>up up_sequence</TT>
<BR><TT>down down_sequence</TT>
<BR><TT>left left_sequence</TT>
<BR><TT>right right_sequence</TT></BLOCKQUOTE>
</BLOCKQUOTE>
<P><BR>'name'
<BR>NAME is the description of the character. It is used in the editor,
and in VRM files, if a new object is to be created. Name is required.
<P>'hp'
<BR>HP is the initial health of the character. If it is not present,
the health is assumed to be 100. It has a maximum value of 2 billion
health points. If it drops below 0, the object dies. If it
drops below -10000 the object is vapourised!
<P>'dexterity'
<BR>DEXTERITY is not yet used. It has a maximum value of 2 billion.
<P>'strength'
<BR>STRENGTH is used to determine how many objects this character can carry.
It is only useful if this really <I>is</I> a character. Strength
is implemented in the character's VRM file, not by the actual game itself.
It has a maximum value of 2 billion.
<P>'intelligence'
<BR>INTELLIGENCE is not yet used, but it will be used by VRM code to do
something later on. It has a maximum value of 2 billion.
<P>'weight'
<BR>WEIGHT is used in conjunction with Strength. In my default files,
a character of strength 30 can carry a total of 30 weight points.
Weight is used by the function 'weight_total', in VRM files. It has a maximum
value of 2 billion.
<P>'damage'
<BR>DAMAGE is used in my VRM files as the amount of damage that the object
will do if it is used as a weapon.
<BR>In the case of the player or another person, damage is the amount of
damage caused by his or her fists. It has a maximum value of 2 billion.
<P>'light'
<BR>LIGHT is the amount of light the object casts, it can be either 0,
1 or -1.
<BR>0 means it casts no light at all, 1 means it casts light and -1 means
it casts darkness instead of light.
<P>'description'
<BR>DESCRIPTION is a text description of the object which is displayed
when you Look at it. If no description is supplied, the game will
say 'you see nothing of interest.'. (This can be modified, looking
is done through VRM files).
<P>Descriptions can be done in two ways. Either you specify the text
of the description in quotes, or you can put the name of an entry from
the Description section.
<P>'short'
<BR>SHORT is usually a single-word text description of the object which
is displayed when you USE, GET or DROP it. If no description is supplied,
the game will say 'no description'. Watch out for this message when
testing your game.
<P>'ifUsed'
<BR>IFUSED will call a VRM function if the player Uses the object.
<BR>The parameter will be a VRM in the Code section.
<P>'ifTriggered'
<BR>IFUSED will call a VRM function if the player steps on the object.
<BR>The parameter will be a VRM in the Code section.
<BR><B>NOTE!</B> <I>current_object</I> will point to the object that was
stood on, and <I>victim</I> will point to the player, or whoever trod on
it.
<P>'ifDead' (also 'ifKilled')
<BR>IFDEAD will call a VRM function if the object is destroyed.
This happens when the health reaches 0.
<BR>The parameter will be a VRM in the Code section. If no VRM is specified,
nothing will happen until it reaches -10000 when it will disappear and
anything in it's pocket will be emptied out on the spot where it stood.
<P>'ifHurt' (also 'ifDamaged')
<BR>IFHURT will call a VRM function if the object takes damage.
(That is, if the health at the end of the turn is less than it was at the
start of the turn).
<BR>The parameter will be a VRM in the Code section. If no VRM is specified,
nothing will happen.
<BR>I use it in my demo to make the people shout when they are hit, and
to make the bombs explode in a chain reaction.
<P>'ifLookedAt' (also 'iflook', 'iflooked')
<BR>IFLOOKEDAT will call a VRM function when the player looks at the object.
This can be used for things like bottles, or allowing the player to know
what's in a container without opening it. Or, it could be used to make
a Basilisk...
<BR>The parameter will be a VRM in the Code section. If no VRM is specified,
nothing will happen.
<P>'onInit'
<BR>ONINIT will call a VRM function when the object is first created.
It has not been tested.
<P>'behaviour' (also 'behavior')
<BR>BEHAVIOUR will call a VRM function every turn of the game loop.
This is used to make the player work as well as
<BR>any other object that moves of it's own accord.
<BR>The parameter will be a VRM in the Code section. If no VRM is specified,
nothing will happen.
<P>'Conversation'
<BR>This is the conversation file that the game will run if the player
talks to this object. It is NOT a VRM file, it is an interpreted
text file. I keep mine in RES\PEOPLE.
<BR>See Part 5 to learn about writing conversations.
<P>'contains'
<BR>This is an object which the person will be carrying when they are created
(either in the editor or at run-time). For example 'contains knife'
will mean that the person will be created with a 'knife', which is another
object in the scriptfile.
<BR>You can have up to 8 'contains object' lines per character.
<P>'resurrect_as'
<BR>If an object is dead, it can be resurrected unless otherwise stated.
<BR>Normally the object will change form when it is killed, and will return
to its original form when resurrected.
<BR>However, you can use 'resurrect_as object' to make the object come
back as something else.
<BR><B>NOTE:</B> resurrect_as has only been lightly tested and may not
work.
<P>'no_resurrect'
<BR>A flag to prevent the object from being able to be resurrected.
<P>'solid'
<BR>SOLID is a flag that means this object will be solid and the player
cannot walk through it.
<P>'blockslight'
<BR>BLOCKSLIGHT is a flag that means this object will block light created
by
a nearby light source.
<P>'fixed'
<BR>FIXED is a flag that means this object is nailed to the ground and
the player cannot pick it up. It also prevents the object from being
pushed, or even moving by itself.
<BR><B>NOTE!</B> When any object enters a container it will become fixed
(to prevent it from trying to move about) and will stop being fixed when
it leaves the pocket.
<P>'tabletop'
<BR>TABLETOP is a flag that means this object is solid and cannot be walked
upon, but objects can be pushed and dropped on top if it.
<P>'invisible'
<BR>INVISIBLE is a flag that means this object can only be seen in the
editor, not in the game itself. (Useful for tripwires etc)
<P>'container'
<BR>CONTAINER is a flag that means that things can be dropped into this
object and move into its pocket in the game. (In the map editor,
you can move objects into anything.)
<P>'translucent'
<BR>TRANSLUCENT is a flag that means this will be drawn using the new translucency
code.
<BR>You will be able to see other things through the object.
<P>'post_overlay'
<BR>POST_OVERLAY. If the current object's sequence has an overlay
attached, the overlay will be drawn ABOVE all other sprites. The
object will appear below the roof, however.
<BR>It is used in the demo to make the door appear above anything else,
and also in the chairs, to make the back appear above the player.
If the object has no overlay, the flag will have no effect.
<BR><B>NOTE: </B>There can be up to 255 objects which do this onscreen
at once. If this limit is exceeded, the rest will not be drawn.
<P>'wielded'
<BR>WIELDED is a flag that is used by my default VRMs. If it is set,
the object can be wielded as a weapon or shield etc.
<BR>Wielded is not used by the engine at all.
<P>'fragile'
<BR>FRAGILE is a flag that is used by my default VRMs. If it is set,
the object will break if thrown too far.
<BR>Fragile is not used by the engine at all.
<P>'SpikeProof'
<BR>SPIKEPROOF is a flag that prevents this object from setting off any
Triggers.
<BR><B>NOTE:</B> Spikeproof objects cannot be dropped into a container
either.
<P>'Person'
<BR>PERSON is a flag that is used to determine if an object is intelligent
or not. It will also apply to animals and monsters.
<BR>At present it is only used in one place: If it is set, the object won't
be able to walk onto a tabletop.
<P>'Quantity'
<BR>QUANTITY is a flag that means that a single object can actually be
a group of objects, like a pile of gold coins.
<BR>For example: 'Look at gold coins: You see 1000 gold coins.'
<BR>The actual quantity of objects will be set by the map editor, or by
VRM code, if the object is created at run-time.
<P>Directions.
<BR>The next few entries will be the character's movement frames.
<BR>To use these, you must specify the direction, then the animation which
is played when the character goes in this direction. The animation
will be an entry from the SEQUENCES section.
<BR>The following directions are supported internally and MUST be defined:
<BLOCKQUOTE>up
<BR>down
<BR>left
<BR>right</BLOCKQUOTE>
<B>Partially-Solid Objects</B>
<P>You <I>really</I> want to use the graphical editor for this one!
<P>If you have a large object, you might not want <I>all</I> of it to be
solid.
<BR>For example, the doors. The door consists of two halves, the
door and the adjacent wall. The player must be able to walk through
only ONE part of the door.
<P>In order to control this, you need to specify two things: The
size of the solid part, and the offset from the top-left hand corner.
Because the door can either be horizontal or vertical, we must specify
both axes separately.
<P>The vertical door has a width and height of 1x2, but the solid area
is just 1x1. And it doesn't start at 0,0 anymore, but 0,1.
<BR>So, we have a 1x1 solid area at 0,1.
<P>Here is a helpful diagram:
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="area1.gif" HEIGHT=266 WIDTH=464></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>And here's one for the Horizontal:
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="area2.gif" HEIGHT=276 WIDTH=555></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>You would specify this in the character's description using the SETSOLID
command.
<P>SETSOLID has five parameters, the axis, (V or H) the offset (+x,+y)
and the size of the solid area (+w,+h)
<P>For the vertical door, which has an offset of 0,1 and a solid area of
1x1 the command is:
<P>SETSOLID V 0 1 1 1
<P>The horizontal door is 2x1, and the solid area is again, 1x1.
But it is at an offset of 0,0.
<BR>So the command for this is:
<P>SETSOLID H 0 0 1 1
<P>If setsolid is not used for a large object, the game will assume the
entire object is solid.
<P>If you don't follow, take a look at the examples in the main.txt file
and use the graphical editor instead.
<P><B>Active Areas</B>
<P>Active areas are just the same as partially-solid objects, but the areas
which are not covered do not interact with the game at all,
<BR>so looking at that square or using it will have no effect.
<P>These are specified using:
<P>SETACTIVEAREA (axis) (x offset) (y offset) (width) (height)
<P>If no active area is specified, it will assume the entire object is
active.
<BR>See Partially-solid objects, above.
<BR>
<BR>
<BR>
<H4>
3.2.4 - Section: Descriptions</H4>
Descriptions are not used in the graphical Script Editor! In fact,
they will be removed entirely from the script file when it is saved.
<BR>But this doesn't matter, since it was just to make life easier before
the editor was written :-)
<BR>If you don't want to use the editor (why not?), read on....
<BR>
<BR>
<P>Descriptions were briefly mentioned in the above section. They
are a way of defining a set of commonly-used text strings for descriptions
in characters and tiles.
<BR>They will be used especially in tiles, as there will be a lot of tiles
which need the same description.
<P>Like the Sprites section, the Descriptions section is just a list.
<P>Each entry is in the form:
<P>LABEL String
<P>Where LABEL is a unique identifier for the description, which will be
used in the Characters section.
<BR>String is just the text of the description, no quotes.
<P>For example:
<P>SECTION: Descriptions
<BLOCKQUOTE><TT>grass
You see some lush green grass</TT>
<BR><TT>stonewall You see a thick stone wall</TT>
<BR><TT>player Hi, Mom!</TT></BLOCKQUOTE>
<H4>
3.2.5 - Section: Code</H4>
Like the Sprites and Description sections, Code is just a list.
<P>Each entry is a function that is contained in a .VRM file. VRM
files are kept in the subdirectory CODE by default, but this just a matter
of preference.
<P>Example:
<P>SECTION: CODE
<BLOCKQUOTE><TT>mainproc code\mainproc.vrm</TT>
<BR><TT>follower code\follower.vrm</TT>
<BR><TT>schedule code\schedule.vrm</TT></BLOCKQUOTE>
<BLOCKQUOTE><TT>player code\player.vrm</TT>
<BR><TT>opendoor code\opendoor.vrm</TT>
<BR><TT>closedoor code\closedor.vrm</TT></BLOCKQUOTE>
The first three code entries are special and <I>must</I> be supplied.
<BR>MAINPROC is called once when the game begins. You can set up
things at this stage. If you don't need to do this, you can just
have an empty function in the file.
<P>FOLLOWER is called each turn of the game, if you have any followers
in the game. Followers are created when someone joins your party,
and their behaviour is set to call this function each time they move.
A reasonable default behaviour is to centre on the player, using a simple
tracking algorithm.
<P>SCHEDULE is called each turn of the game. For this reason, it
must take up as little time as possible! It can be used to simulate
multitasking but most people will use it to run time-based functions.
The demo uses it to make the player come out of the acid trips after a
certain number of turns.
<H4>
3.2.6 - Section: tiles</H4>
ATTENTION! The current version of the graphical script editor does
NOT handle tiles yet!
<BR>You will need to read this bit...
<P>The tiles section is used to declare all map tiles that can be used
in the game.
<P>Map tiles are declared in a 3 or 4 line declaration like this:
<P>SECTION: tiles
<BLOCKQUOTE><TT>name grass</TT>
<BR><TT>sequence grass_sequence</TT>
<BR><TT>description "You see some lush green grass"</TT>
<BR><TT>solid</TT></BLOCKQUOTE>
'name'
<BR>NAME is the title of this tile. It is used by the compiler to
tell where each entry begins. The name is not usually used by the
game except possibly for debugging.
<P>'sequence'
<BR>SEQUENCE is the animation sequence that is used whenever the tile is
displayed. Mostly it will be a single-frame animation sequence defined
using quickname, but for other things, such as water, it can be a full
animating sequence. The name you put here must be in the Sequences
section.
<P>'description'
<BR>DESCRIPTION is a text description of the object which is displayed
when you Look at it. If no description is supplied, the game will
say 'you see nothing of interest.'.
<BR>Descriptions can be done in two ways. Either you specify the
text of the description in quotes, or you can put the name of an entry
from the Description section.
<P>'solid'
<BR>SOLID is optional. If it is present, the tile will be impassible,
like a wall. If it is not present, the player and any NPCs in the
game
<BR>will be able to move through it.
<P>'blockslight'
<BR>BLOCKSLIGHT is optional. If it is present, the tile will block
light from a nearby lightsource.
<H4>
3.2.7 - Section: Sounds</H4>
SOUNDS is nearly just a list. Since 0.04, it can also have an optional
parameter, NODRIFT.
<BR>If NODRIFT is going to be used, it must be the third entry on the line.
<BR>It locks the sound to it's original frequency. If NODRIFT is
omitted, the sound will be played at a random pitch, close to the original
frequency.
<P>Each entry is the name of a sound that is contained in a .WAV file.
WAV files are kept in the subdirectory SOUND by default, but this just
a matter of preference.
<P>Example:
<P>SECTION: SOUNDS
<BLOCKQUOTE>ouch
sound\ouch.wav NODRIFT # Ouch
is always played at a fixed pitch
<BR>close_door sound\closdoor.wav
# Close_Door will not necessarily be played at original pitch.</BLOCKQUOTE>
The name will be used in VRM code to play a sound file.
<BR>E.g. play_sound("ouch");
<H4>
3.2.8 - Section: Music</H4>
Like the Sounds section, Music is just a list.
<P>Each entry is the name of a song that is contained in a .MOD or .S3M
file. The files are kept in the subdirectory MUSIC by default, but
this just a matter of preference.
<BR>For a full list of the sound formats supported, see section 1.4.?
<P>Example:
<P>SECTION: MUSIC
<BLOCKQUOTE>intro
music\intro.mod
<BR>theme music\theme.xm</BLOCKQUOTE>
The name will be used in VRM code to play a song file.
<BR>E.g. play_song("intro");
<BR>
<H4>
3.2.9 - Section: rooftiles</H4>
ATTENTION! The current version of the graphical script editor does
NOT handle tiles yet!
<BR>You will need to read this bit...
<P>The rooftiles section is used to declare all tiles that can be used
to make a roof.
<BR>There can be up to 255. The first one is automatically created
by the system (it is blank).
<P>Roof tiles are declared in a completely different manner to anything
else.
<BR>It is just a list of of files, with a single optional flag, and no
name.
<P>The order is important: this is the order they will be presented in
the editor, and it cannot be changed without affecting the map.
<P><TT>SECTION: rooftiles</TT>
<BLOCKQUOTE><TT>root/tile1.cel</TT>
<BR><TT>roof/tile2.cel</TT>
<BR><TT>roof/tile3.cel stand_under</TT>
<BR><TT>roof/tile4.cel</TT>
<BR><TT>roof/tile5.cel stand_under</TT></BLOCKQUOTE>
By default, the tiles will cause the roof to disappear if the player is
standing underneath one.
<BR>However, sometimes you can have tiles which overhang the side of the
roof, especially on the left and top sides of the building.
<BR>In this case you don't want them to disappear if the player is there.
For these tiles, add the flag 'stand_under' to the end of the line.
<P>
<HR WIDTH="100%">
<BR>
<BR>
<BR>
<CENTER>
<H2>
Part 4 - The VRM System</H2></CENTER>
<H3>
4.1 - What are VRMs?</H3>
<H4>
4.1.1 - The VRM concept</H4>
VRMs, or Virtual Runnable Modules, are a system of interpreted files, containing
the code necessary to cause events that happen in the game.
<P>In Quake, by Id Software, every event that happens in the game is written
in a small chunk of script language, called Quake-C, which is compiled
into bytecode and parsed by the game.
<P>IRE uses this same approach.
<BR>Each game event is written in C, and compiled using a compiler called
SEERC. The compiled code is a .VRM file, which is loaded into
the game as it starts up.
<BR>
<H4>
4.1.2 - How VRMs are made</H4>
The programming is done in C, but you can easily pick it up if you know
PASCAL or some dialects of BASIC.
<BR>The differences between these languages is very slight, conceptually,
but they use different symbols and have varying degrees of 'strictness'.
<P>Of course, it's better if you do have a basic grasp of C.
<P>VRMS are written using my special library of functions, for convenience
and for security. You cannot use any other functions than are in
this library. A VRM, once compiled, will run on any platform.
<P>However it's a good idea to include the source code for the VRMs, in
case the VRM binary format ever changes.
<P>To make a VRM, you must first produce a source file using your favourite
text editor, and save it with a .CPP file extension, somewhere inside the
res/code directory
<P>Then you type BUILD from the res/code directory, and the system will
look for and compile any VRMs that have changed.
<BR>You should now have a .VRM file corresponding to the .CPP file you
just wrote!
<P>If any errors occurred, you will get some warning messages during compilation.
<BR>Any warnings are considered BAD. You might have a .VRM file out
the other end, but it probably won't work until all the warnings are gone.
<P>Now, if the script file has an entry for OBJECTS.CPP, and if there is
a call to the VRM, you will see the VRM work!
<P>I think it's time for a quick tutorial now.
<BR>
<H4>
4.1.3 - A tutorial of a simple VRM</H4>
In this tutorial, we'll see how to use most of the information in the guide
so far, to create a simple object.
<P>First, go into you chosen paint package, and draw a straight line, or
something that looks like a sewing needle.
<P>Save it to RES\SPRITES\needle.PCX (or .CEL)
<P>Next, edit main.txt in the RES\ directory.
<P>Look for SECTION: Sprites
<BR>Go to the end of the list, and add a new entry:
<PRE> Needle SPRITES\needle.pcx</PRE>
(Or, needle.cel, depending on what format you used)
<P>Now, go to SECTION: Sequences
<BR>Go to the end of the sequence list, and add a new entry:
<PRE> quickname Needle Needle</PRE>
Now, go to SECTION: Characters
<BR>Got to the end of the character section, and add a new entry:
<P><TT> name Needle</TT>
<BR><TT> up Needle</TT>
<BR><TT> down Needle</TT>
<BR><TT> left Needle</TT>
<BR><TT> right Needle</TT>
<BR><TT> weight 3</TT>
<BR><TT> description "You see a sharp
sewing needle"</TT>
<BR><TT> ifUsed
NeedleCode</TT>
<P>Now, there is one last entry to make to the script file.
<BR>Go to SECTION: Code, and add the new entry:
<PRE> NeedleCode CODE\needle.vrm</PRE>
Now, we should be ready to make the VRM.
<P>Go into the RES\CODE directory, and create a new file, called NEEDLE.CPP.
<BR>The file should read as follows:
<P><TT> // Needle - a sample VRM. This line is
a comment, by the way.</TT>
<BR><TT> #include "vrm.hpp"</TT>
<BR><TT> PROC</TT>
<P><TT> print("Ouch!\n");</TT>
<P><TT> ENDPROC</TT>
<BR><TT> // Stop typing..</TT>
<P>Now, quit from the editor, and type..
<BR>
<BLOCKQUOTE>BUILD</BLOCKQUOTE>
..on the command line. If you typed it correctly, it should chunter
for a bit, and you will have a nice NEEDLE.VRM file.
<P>Now, go back to the main IRE directory, and run the editor.
<BR>
<BLOCKQUOTE>ED -edit test1</BLOCKQUOTE>
Go into Sprites mode, and you should be able to create a needle.
<BR>Place it somewhere near the player, so you can find it easily.
<P>Now, run the game! Find the needle, use it, and the player should
be able to prick their thumb on the needle.
<BR>
<H4>
4.1.4 - Basic rules for writing VRMs</H4>
Now we've made a VRM and compiled it, we'll take a look at how it works.
<BR>But first, know the basic rules of VRM-writing.
<P>These are the ground rules. Venerate them and Obey them in All
Things.
<OL>
<LI>
You must have the line #include "vrm.hpp" before the code starts.</LI>
<LI>
You must have the lines PROC and ENDPROC, and your code must go between
them.</LI>
<LI>
Single-line comments begin with // and the rest of that line is ignored.</LI>
<LI>
Multi-line comments start with /* and everything is ignored until */</LI>
<LI>
When defining variables you should stick to letters and the underbar _
symbol.</LI>
<LI>
You can't have spaces in the names of variables.</LI>
<LI>
You can have numbers ONLY if there is a letter or an _ in front of the
number.</LI>
<LI>
C <I>is</I> case-sensitive, so 'CHAR' is <I>not</I> the same as 'char'</LI>
<LI>
Blocks start and end with '{' and '}' respectively.</LI>
</OL>
C is like pascal, but the conventions and symbols used are highly abbreviated,
and look very strange at first sight.
<P>Simple Pascal to C conversion guide...
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD><B>PASCAL</B></TD>
<TD><B>C</B></TD>
<TD><B>DESCRIPTION</B></TD>
</TR>
<TR>
<TD>BEGIN</TD>
<TD>{</TD>
<TD>Start a block of code</TD>
</TR>
<TR>
<TD>END</TD>
<TD>}</TD>
<TD>End a block of code</TD>
</TR>
<TR>
<TD>(*</TD>
<TD>/*</TD>
<TD>Start a comment</TD>
</TR>
<TR>
<TD>*)</TD>
<TD>*/</TD>
<TD>End a comment</TD>
</TR>
<TR>
<TD>if a = b then</TD>
<TD>if (a == b)</TD>
<TD>If A and B are equal</TD>
</TR>
<TR>
<TD>a AND b</TD>
<TD>(a && b)</TD>
<TD>logical AND in an IF statement</TD>
</TR>
<TR>
<TD>a OR b</TD>
<TD>(a || b)</TD>
<TD>logical OR in an IF statement</TD>
</TR>
<TR>
<TD>a XOR b</TD>
<TD>(a ^^ b)</TD>
<TD>logical XOR in an IF statement</TD>
</TR>
<TR>
<TD>if NOT a then</TD>
<TD>if (!a)</TD>
<TD>if a is not true (i.e. a is zero)</TD>
</TR>
<TR>
<TD>a := b;</TD>
<TD>a = b;</TD>
<TD>let a = b</TD>
</TR>
</TABLE>
<BR>
<BR>
<H4>
4.1.5 - How does the example code work?</H4>
Now, with the ground rules in your head, or printed out, let's look at
the code line-by-line...
<BR>
<PRE> // Needle - a sample VRM. This line is a comment, by the way.</PRE>
<PRE> #include "vrm.hpp"</PRE>
<PRE> PROC</PRE>
<PRE> print("Ouch!\n");</PRE>
<PRE> ENDPROC</PRE>
<PRE> // Stop typing..</PRE>
The first line is just a comment. It is ignored.
<P>The next line, '#include "vrm.hpp"' is needed to set up the compiler.
<BR>Don't worry about it, just remember to put it there.
<P>Then we have the PROC line. This tells the compiler that the module
is here,
<BR>and everything after it will be compiled up until the ENDPROC line.
<BR>(It's actually a #define macro to simplify the process of setting up
a VRM function)
<P>Now we have the actual code.
<P>print("Ouch!\n");
<P>This will print a string in the standard C way, which might be a bit
of a shock to PASCAL or BASIC programmers.
<P>I'll go into detail later, but basically, it prints the text out on
the console.
<BR>The '\n' at the end is a special code, meaning end-of-line, and the
next string or number to be printed will appear on the line below.
<P>After that, we have the ENDPROC line, which tells the compiler that
this is the end of the procedure.
<P>And finally we have another comment.
<BR>
<BR>
<H4>
4.1.6 - Data types</H4>
The following data types can be used to declare your variables.
<P>C data types. All C data types are supported, but these are the
most useful ones:
<BR> STRING is a special addition of mine, it maps onto 'char *'
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD>NAME</TD>
<TD>TYPE</TD>
<TD>DESCRIPTION</TD>
</TR>
<TR>
<TD>char</TD>
<TD>a single letter</TD>
<TD>Can also be a number from -128 to 127</TD>
</TR>
<TR>
<TD>unsigned char</TD>
<TD>same as char</TD>
<TD>This is a number from 0 to 255</TD>
</TR>
<TR>
<TD>short</TD>
<TD>number</TD>
<TD>A number from -32768 to 32767</TD>
</TR>
<TR>
<TD>unsigned short</TD>
<TD>number</TD>
<TD>A number from 0 to 65535</TD>
</TR>
<TR>
<TD>int</TD>
<TD>number</TD>
<TD>A number from -2147483647 to 2147483648</TD>
</TR>
<TR>
<TD>unsigned int</TD>
<TD>number</TD>
<TD>A number from 0 to 4294967296</TD>
</TR>
<TR>
<TD>char *</TD>
<TD>text string</TD>
<TD>A fixed length text string</TD>
</TR>
</TABLE>
Notes for advanced users:
<UL>
<LI>
Do not use LONG! It will change to a 64-bit quantity later but has
been disabled for now.</LI>
<LI>
LONG LONG is not supported either.</LI>
<LI>
Floating point support is not tested, so use it only if you know what you're
doing.</LI>
<LI>
Never try something stupid like adding two strings together.. it won't
work!</LI>
</UL>
An example of declaring variables, and assigning values to them.
<BR>This has no apparent effect whatsoever, but it demonstrates the logic
involved.
<P><TT>PROC</TT>
<BLOCKQUOTE><TT>char character;</TT>
<BR><TT>short number;</TT>
<BR><TT>STRING str;</TT>
<P><TT>character = 'a';</TT>
<BR><TT>character = 120; // Pascal goes apeshit if you
try to do this.. ..but this is not pascal.</TT>
<P><TT>number = 3;</TT>
<BR><TT>number = 1 + 2;</TT>
<P><TT>string = "This is a string";</TT></BLOCKQUOTE>
<TT>ENDPROC</TT>
<BR>
<BR>
<H3>
4.2 - The OBJECT</H3>
<H4>
4.2.1 - Introducing the OBJECT</H4>
In addition to the traditional int and char, there is also.. OBJECT!
<P>OBJECT is a pointer to a Thing that appears in the game, that is, a
Sprite in the editor, and a Character in the script file.
<P>Each OBJECT is a group of ints, chars and other gubbins that makes up
an object in the game.
<P>If you know C, then you'll know what I mean when I say that it is a
pointer to a structure, and each member of the OBJECT is accessed using
object->member notation. If you don't know C that well, then just
do as I say and it will be fine :-)
<BR>
<H4>
4.2.2 - Creating an object from scratch</H4>
You won't often need to do this, but here goes...
<P>Normally, an OBJECT is declared as follows:
<BR>
<BLOCKQUOTE>OBJECT *myobject;</BLOCKQUOTE>
However, you must note that 'myobject' <I>is not yet there</I>!
<BR>It exists, but it is 'empty', and the game will exit prematurely if
you try to use it at this point.
<P>To actually create the object, you will need to call my function, <I>create_object</I>.
<BR>You must have some idea of which object to create at this point.
<P>To create a needle from the tutorial, you would use the code:
<BR>
<BLOCKQUOTE>OBJECT *new_needle;
<BR>new_needle = create_object("needle",10,10);</BLOCKQUOTE>
and lo, a needle will appear at coordinates 10,10 on the map.
<P>When using create_object, the name you specify is a name in 'Section:
Characters'. If you try to create an object that is not in the section:
characters list, the game will exit and display the following error:
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P><IMG SRC="error2.gif" HEIGHT=171 WIDTH=624></CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<P>...where 'OBJECTPANEL' is the name of the object that it tried to create.
<BR>
<P>Now, creating objects is extremely useful, but mostly you will be modifying
existing objects that are internal to the game.
<BR>
<H4>
4.2.3 - Modifying objects</H4>
<P><BR>Each OBJECT is a collection of all the properties that the game
character has. The character's position, their health, even their
appearance and behaviour can all be controlled by fiddling around with
the properties of the character's OBJECT.
<P>The object which you are going to spend a lot of time fiddling around
with is the player.
<BR>The player has a special variable you can use, so you don't have to
hunt for them. This is called, surprisingly, <I>player</I>.
<P>I'll use the player to demonstrate the parts you can modify. If
you look in vrm.hpp, you will see there are others. But you don't
want to mess with those.
<P>Each part of an object is addressed using the form object->part.
This may sound confusing, but an example should help.
<BR>To set the player's health to 100, you would say:
<P> player->stats->hp = 100;
<P>Where 'player' is the object being modified, and 'stats->hp' is the
amount of health, the part of the player we are changing.
<BR>
<H4>
4.2.4 - Object reference guide</H4>
You can look at and modify the following parts of an object safely:
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD>object->stats->hp</TD>
<TD>number</TD>
<TD>The object's health. When this is 0, the object dies, or is destroyed</TD>
</TR>
<TR>
<TD>object->stats->str</TD>
<TD>number</TD>
<TD>The object's strength</TD>
</TR>
<TR>
<TD>object->stats->intel</TD>
<TD>number</TD>
<TD>The object's intelligence</TD>
</TR>
<TR>
<TD>object->stats->weight</TD>
<TD>number</TD>
<TD>The object's weight</TD>
</TR>
<TR>
<TD>object->stats->damage</TD>
<TD>number</TD>
<TD>The amount of damage the object can do as a weapon.</TD>
</TR>
<TR>
<TD>object->stats->quantity</TD>
<TD>number</TD>
<TD>Quantity of objects in a group or pile, for example 1000 gold coins.</TD>
</TR>
<TR>
<TD>object->tag</TD>
<TD>number</TD>
<TD>Unique ID number for events, like the unique ID of a key for a door.</TD>
</TR>
<TR>
<TD>object->light</TD>
<TD>-1, 0, 1</TD>
<TD>If 1 or more, the object emits a circular light pattern of fixed intensity.
<BR>If -1 or less, the object emits a circular pattern of DARKNESS.
<BR>Future releases will support varying intensity and patterns.</TD>
</TR>
</TABLE>
<P>In addition, there is also object->user[0] through to object->user[9],
which is a group of 10 variables set aside for VRM writers to use how they
want :-)
<P>The following parts of an object you can look at, but you <I>should
not modify</I> unless you know what you're doing.:
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD WIDTH="25%"><B>Member</B></TD>
<TD WIDTH="10%"><B>Type</B></TD>
<TD><B>Description</B></TD>
</TR>
<TR>
<TD>object->name</TD>
<TD>string</TD>
<TD>The name of the object. Same string as used in create_object(name)</TD>
</TR>
<TR>
<TD>object->desc</TD>
<TD>string</TD>
<TD>The description you see when you look at it.</TD>
</TR>
<TR>
<TD>object->personalname</TD>
<TD>string</TD>
<TD>The individual name of the object, set in the map editor, or NULL for
none.</TD>
</TR>
<TR>
<TD>object->w</TD>
<TD>number</TD>
<TD>width of the object in pixels</TD>
</TR>
<TR>
<TD>object->h</TD>
<TD>number</TD>
<TD>height of the object in pixels</TD>
</TR>
<TR>
<TD>object->mw</TD>
<TD>number</TD>
<TD>width of the object in map squares </TD>
</TR>
<TR>
<TD>object->mh</TD>
<TD>number</TD>
<TD>height of the object in map squares</TD>
</TR>
<TR>
<TD>object->curdir</TD>
<TD>number</TD>
<TD>Direction the object is facing. 0 = up, 1 = down, 2 = left, 3 = right</TD>
</TR>
<TR>
<TD>object->pocket</TD>
<TD>OBJECT *</TD>
<TD>The first entry in a list of objects inside this object's pocket.
For bags etc..</TD>
</TR>
<TR>
<TD>object->wield[..]</TD>
<TD>OBJECT *[ ]</TD>
<TD>An array of objects that the character is wielding. wield[0] to wield[7]
<BR>You can wield weapons by modifying this, but don't do anything silly.</TD>
</TR>
<TR>
<TD>object->stats->oldhp</TD>
<TD>number</TD>
<TD>The object's health points at the start of the turn. Modifying
this may disrupt the operation of 'ifHurt', see section 3.2.3. </TD>
</TR>
<TR>
<TD>object->stats->pFlags</TD>
<TD>number</TD>
<TD>Conversation flags specific to this object. You should not use
this directly, use get_pflag and set_pflag instead.</TD>
</TR>
<TR>
<TD>object->enemy</TD>
<TD>OBJECT *</TD>
<TD>This object is the NPC's enemy, they may relieve their stress on this
object.</TD>
</TR>
<TR>
<TD>object->owner</TD>
<TD>OBJECT *</TD>
<TD>This is the object which the current object belongs to. If you
steal it when they are looking, they will beat the hell out of you.
NULL if public property.</TD>
</TR>
<TR>
<TD>object->next</TD>
<TD>OBJECT *</TD>
<TD>This is the next object in the map square that the object is in.
The objects afterwards will appear above it.</TD>
</TR>
</TABLE>
<TABLE BORDER COLS=1 WIDTH="100%" >
<TR>
<TD>
<H3>
<B>Warning:</B></H3>
<B>Unavoidable Changes in 0.041</B>
<P>Since release 0.041, you can not use the traditional method of getting
at the flags! If you try to, the VRM will not compile.
<BR>You must now use <B>get_flag</B> and <B>set_flag</B> instead!
<P><B>Unavoidable Changes in 0.040</B>
<P>Since release 0.04, you must NEVER modify the object's X and Y positions,
or the game will bomb out.
<BR>Use <B>move_object</B> wherever you want to move an object around the
map.
<BR> </TD>
</TR>
</TABLE>
<P>There are three objects that have special purposes..
<P><B>player</B>
<BR>
<P>We have already looked at player. Player always points to the
object you are currently controlling, whether it is the player themselves,
or a follower who you have switched control to.
<P><B>current_object</B>
<P>This is the 'current object'. Many VRMs are designed to perform
a certain action on an object, such as moving it, opening it, closing
etc. When the VRM code starts running, <I>current_object</I> will
have been set to the object you are supposed to modify.
<P>From the IRE demo, here is an example:
<BR>
<BLOCKQUOTE>PROC
<BLOCKQUOTE>change_object(current_object,"StoneDoor1_Open");
<BR>play_sound(0);</BLOCKQUOTE>
ENDPROC</BLOCKQUOTE>
When you go up to the door and USE it, the game sets <I>current_object</I>
to point to the door you are opening.
<BR>Then, the VRM that opens the door calls change_object() to change the
current object (the door) into an open door.
<BR>Then it plays the door opening sound, (which is stolen from the VERGE
project, the recently-revived and neat-looking rival to IRE)
<P><B> victim</B>
<P>Victim is used by the IsTriggered mechanism described in section 3.2.3.
<BR>When the VRM code starts running, <I>current_object</I> will have been
set to the object that is being triggered, and <I>victim</I> will be the
object you are supposed to modify.
<P>From the IRE demo, here is an example:
<BR>
<BLOCKQUOTE>PROC
<BLOCKQUOTE>victim->stats->hp -= current_object->stats->damage;</BLOCKQUOTE>
ENDPROC</BLOCKQUOTE>
When you tread on The Death, it becomes the current_object. You become
the victim.
<BR>The VRM will therefore deduct a certain amount of health from the victim.
<BR>(In the demo, The Death does 10000 damage points, slaying you instantly)
<BR>
<H4>
4.2.5 - The TILE</H4>
<P><BR>TILES are similar to objects, but they deal with the fixed tiles
that make up the map.
<P>The only way you will ever see the TILES, is when you use the function
get_tile(x,y), which returns the TILE at that position on the map.
<P>The TILE will be declared as, for example, TILE *tilepointer;
<P>You can never create or destroy tiles.
<P>Here is a list of the members of a TILE what you should know about:
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD WIDTH="25%"><B>Member</B></TD>
<TD WIDTH="10%"><B>Type</B></TD>
<TD><B>Description</B></TD>
</TR>
<TR>
<TD>tile->name</TD>
<TD>string</TD>
<TD>The name of the object. Same string as used in create_object(name)</TD>
</TR>
<TR>
<TD>tile->desc</TD>
<TD>string</TD>
<TD>The description you see when you look at the tile</TD>
</TR>
</TABLE>
<H3>
4.3 - Functions Reference</H3>
When programming VRMs, you will use my functions. You have no choice
:-)
<BR>They shield all the nasty stuff like creating objects, traversing the
lists and shit from you, the VRM developer.
<BR>(Of course, if you want to see the nasty stuff, or make your own functions,
look in the source code)
<P>This is a list of all the functions currently supported by the engine....
<BR>
<H4>
4.3.1 - Object functions</H4>
<B>set_flag</B> (new in 0.041)
<P>Format: void set_flag(OBJECT *object, FLAG_TYPE, int ONE_OR_ZERO);
<P>Description: Allows you to set a controlling flag in an object.
<P>Input: The OBJECT which is to be modified, and the flag to change
(See below for the list) and the new value it will take.
<BR>
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD WIDTH="25%"><B>Flag</B></TD>
<TD><B>Description</B></TD>
</TR>
<TR>
<TD>IS_ON</TD>
<TD>If 1, the object is usable. If 0, it has been 'killed' and is not really
there.
<BR>Setting it to 1 again will bring he object 'back to life'.</TD>
</TR>
<TR>
<TD>IS_PARTY</TD>
<TD>Is the object a party member? If so, you can walk through it
and swap places</TD>
</TR>
<TR>
<TD>IS_FIXED</TD>
<TD>Can the object be picked up, pushed around or move by itself? Fixed
to the ground if 1. Objects automatically become fixed when put in
a container, and un-fixed when they leave.</TD>
</TR>
<TR>
<TD>IS_SOLID</TD>
<TD>Can you walk over it or is it solid? Impassible if 1</TD>
</TR>
<TR>
<TD>IS_TABLETOP</TD>
<TD>If 1, you can drop objects on it, even though it is solid.</TD>
</TR>
<TR>
<TD>IS_CONTAINER</TD>
<TD>If 1, then you can drop other objects into it, and it will move them
into its object->pocket list. Affects move_from_pocket</TD>
</TR>
<TR>
<TD>IS_TRANSLUCENT</TD>
<TD>If 1, the object is drawn semi-transparently. No other effects.</TD>
</TR>
<TR>
<TD>CAN_WIELD</TD>
<TD>If 1, the object can be wielded by the player (Not enforced by the
engine)</TD>
</TR>
<TR>
<TD>IS_SPIKEPROOF</TD>
<TD>If 1, the object does not respond to triggers, and cannot be dropped
in containers.</TD>
</TR>
<TR>
<TD>IS_FRAGILE</TD>
<TD>If 1, the object will break if thrown too far. (Not enforced
by the engine)</TD>
</TR>
<TR>
<TD>IS_INVISIBLE</TD>
<TD>If 1, the object cannot be seen on the map and will not always interact.</TD>
</TR>
<TR>
<TD>IS_YOURS</TD>
<TD>If 1, the object is Your Property (Not enforced by the engine)</TD>
</TR>
<TR>
<TD>DOES_BLOCKLIGHT</TD>
<TD>If 1, the object will block light from a light source.</TD>
</TR>
<TR>
<TD>IS_PERSON</TD>
<TD>If 1, the object cannot walk onto a tabletop, other effects will come
later too</TD>
</TR>
<TR>
<TD>SEEK_STATE</TD>
<TD>Reserved for moving NPCs</TD>
</TR>
<TR>
<TD>IS_QUANTITY</TD>
<TD>If 1, the object can be a group of objects. For example, one
object could be a pile of 1000 gold coins, (which could be split into several
piles of 250 gold coins or similar).</TD>
</TR>
</TABLE>
<P>Returns: nothing.
<P>Since IRE 0.041, you MUST use this function instead of accessing the
flags directly.
<BR>
<P>Example:
<BLOCKQUOTE>
<BR>set_flag(player,IS_TRANSLUCENT,1);</BLOCKQUOTE>
<B>get_flag</B> (new in 0.041)
<P>Format: int get_flag(OBJECT *object, FLAG_TYPE);
<P>Description: Allows you to find out whether a controlling flag is set
or not.
<P>Input: The OBJECT which is to be modified, and the flag to change
(See <B>set_flag</B> for the list)
<P>Returns: 1 if the flag is set, or 0 if it isn't set.
<P>Since IRE 0.041, you MUST use this function instead of accessing the
flags directly.
<BR>
<P>Example:
<BLOCKQUOTE>
<BR>if( get_flag(player,IS_TRANSLUCENT))
<BR> print("The player is high
as a kite\n");</BLOCKQUOTE>
<P><BR><B>set_pflag</B> (new in 0.05)
<P>Format: void set_pflag(OBJECT *object, int flag_no, int ONE_OR_ZERO);
<P>Description: Allows you to set a conversation flag in an object.
See Part 5 for more detail about this.
<P>Input: The OBJECT which is to be modified, and the flag to change
(a number between 0 and 31) and the new value it will take.
<P>Returns: nothing
<P>Example:
<BR>
<BLOCKQUOTE>set_pflag(object,31,1); // Set flag 31 to be TRUE for
this object</BLOCKQUOTE>
<B>get_pflag</B> (new in 0.05)
<P>Format: int get_pflag(OBJECT *object, int flag_no);
<P>Description: Allows you to examine a conversation flag in an object.
See Part 5 for more detail about this.
<P>Input: The OBJECT which is to be scrutinised, and the flag to
examine (a number between 0 and 31).
<P>Returns: 0 if the flag is false, or something else if it is true.
<P>Example:
<BR>
<BLOCKQUOTE>if(get_pflag(object,2))
<BR> {
<BR> printf("He is angry and will not speak to you.\n");
<BR> return;
<BR> }</BLOCKQUOTE>
<P><BR><B>set_user_flag</B> (new in 0.05)
<P>Format: void set_user_flag(STRING flag_name, int ONE_OR_ZERO);
<P>Description: Allows you to set a named conversation flag that is accessable
throughout the game. If the named flag does not exist, a new one
will be created with that name. See Part 5 for more detail about
this.
<P>Input: The flag to change (a string) and the new value it will
take.
<P>Returns: nothing
<P>Example:
<BR>
<BLOCKQUOTE>set_user_flag("killed_the_king",1);</BLOCKQUOTE>
<B>get_user_flag</B> (new in 0.05)
<P>Format: int get_user_flag(STRING flag_name);
<P>Description: Allows you to examine a named conversation flag that is
accessable throughout the game. If the named flag does not exist,
it returns FALSE. See Part 5 for more detail about this.
<P>Input: The flag to examine (a string)..
<P>Returns: 1 if the flag is true, 0 if the flag is flase or does not exist
yet.
<P>Example:
<BR>
<BLOCKQUOTE>if(get_user_flag("killed_the_king"))
<BR> printf("TREASON! HIGH TREASON!\n");</BLOCKQUOTE>
<B>move_object</B> (new in 0.04)
<P>Format: int move_object(OBJECT *object, int x, int y);
<P>Description: Moves the object around the map. If you modify the coordinates
directly, the game will fall over.
<P>Input: The OBJECT which is to be moved, and the new position it
will occupy.
<P>Returns: 1 if the move was successful, 0 if it was blocked by an obstruction.
<P>Since IRE 0.04, you MUST use this function or risk calamity.
<BR>
<P>Example:
<BLOCKQUOTE>
<BR>move_object(player,player->x+1,player->y+1);</BLOCKQUOTE>
<P><BR><B>transfer_object</B> (new in 0.04 but undocumented)
<P>Format: void transfer_object(OBJECT *object, int x, int y);
<P>Description: Moves the object around the map <I>without checking</I>.
Can move through walls or on top of solid objects.
<P>Input: The OBJECT which is to be moved, and the new position it
will occupy.
<P>Returns: Nothing. If it fails (unlikely) the game will abort with
an error message.
<P>See move_object above.
<BR>
<P><B>create_object</B>
<P>Format: OBJECT *create_object(STRING name, int x, int y);
<P>Description: Creates a new object and adds it into the list of Things.
<P>Input: A STRING with the name of the sprite to create, (from CHARACTERS),
the coordinates where it will appear.
<P>Returns: The newly-created object.
<P>Since IRE 0.04, the X and Y coordinates must be specified.
<BR>
<P>Example:
<BLOCKQUOTE> OBJECT *enemy;
<BR> enemy = create_object("evil_dude",10,10);</BLOCKQUOTE>
<P><BR><B>remove_object</B>
<P>Format: remove_object(OBJECT *victim);
<P>Description: Destroys an object and frees the resources it is using.
<P>Input: The OBJECT to be removed.
<P>Returns: nothing.
<BR>
<P>(pointless) Example:
<BR>
<BLOCKQUOTE>OBJECT *enemy;
<BR>enemy = create_object("evil_dude");
<BR>remove_object(enemy);</BLOCKQUOTE>
<B>change_object</B>
<P>Format: change_object(OBJECT *object, STRING name);
<P>Description: Changes an existing object into another type of object.
Most of the statistics such as health, strength etc remain unchanged.
<P>Input: The OBJECT you are going to change, A STRING with the name
of the new object type, (from CHARACTERS).
<P>Returns: nothing.
<BR>
<P>Example:
<BLOCKQUOTE>OBJECT *enemy;
<BR>enemy = create_object("evil_dude");
<BR>change_object(enemy, "really_evil_dude");</BLOCKQUOTE>
<B>replace_object</B> (new in 0.05)
<P>Format: replace_object(OBJECT *object, STRING name);
<P>Description: Changes an existing object into another type of object
completely, discarding all previous statistics and other info.
<BR>Input: The OBJECT you are going to change, A STRING with the
name of the new object type, (from CHARACTERS).
<P>Returns: nothing.
<BR>
<P>Example:
<BLOCKQUOTE>OBJECT *enemy;
<BR>enemy = create_object("evil_dude");
<BR>replace_object(enemy, "pumpkin");</BLOCKQUOTE>
<B>set_object_direction</B>
<P>Format: set_object_direction(OBJECT *object, long DIRECTION);
<P>Description: Set the direction that the object is facing.
<P>Input: The OBJECT you are going to change, A number 0-3, or preferably,
one of the following macros:
<BR>
<BLOCKQUOTE>UP
<BR>DOWN
<BR>LEFT
<BR>RIGHT</BLOCKQUOTE>
Returns: nothing.
<BR>
<P>Example:
<BLOCKQUOTE>OBJECT *enemy;
<BR>enemy = create_object("evil_dude");
<BR>set_object_direction(enemy, UP); // Face upwards, (North)</BLOCKQUOTE>
<B>set_object_sequence</B>
<P>Format: set_object_sequence(OBJECT *object, STRING sequence);
<P>Description: This will change the appearance of the object, so that
a special animation sequence is displayed instead, until the object moves.
It has no physical effects on the object, only its appearance.
<P>Input: The OBJECT you are going to change, A string, which must
be one of the entries in SECTION: SEQUENCES from the script file.
<P>Returns: nothing.
<BR>
<P>Example:
<BLOCKQUOTE>OBJECT *enemy;
<BR>enemy = create_object("evil_dude",10,10);
<BR>if(enemy->user[0] == bored)
<BR> set_object_sequence(enemy, "evil_dude_twiddling_thumbs");</BLOCKQUOTE>
<B>set_object_behaviour</B>
<P>Format: set_object_behaviour(OBJECT *object, STRING new_vrm);
<P>Description: Set the VRM function which will be called for this object
each turn.
<P>Input: The OBJECT you are going to change, A string, which must
be one of the entries in SECTION: CODE from the script file, or else NULL.
If the string is NULL, the object's behaviour will be deactivated and it
will do nothing each turn.
<P>Returns: nothing.
<BR>
<P>Example:
<BLOCKQUOTE>OBJECT *enemy;
<BR>enemy = create_object("evil_dude",10,10);
<BR>if(enemy->user[0] == hungry)
<BR> set_object_behaviour(enemy, "find_some_food");</BLOCKQUOTE>
<B>get_object</B>
<P>Format: OBJECT * get_object(short x, short y);
<P>Description: Looks at the map square X,Y, and returns the object in
this position. If there are more than one object in this space, it
will return the one on the top of the pile.
<P>Input: The X and Y coordinates of the map square to be investigated.
<P>Returns: The object it found, or NULL if nothing was found. MAKE
SURE you check that this is not NULL, otherwise the game will crash out.
<BR>
<P>Example:
<BLOCKQUOTE>OBJECT *it;
<BR>it = get_object(100,100);
<BR>if( it != NULL)
<BR> print("We found something!");</BLOCKQUOTE>
<B>get_top_object</B>
<P>Format: OBJECT * get_top_object(short x, short y);
<P>get_top_object is obsolete. Please use get_object instead.
<BR>
<P><B>get_best_object</B>
<P>Format: OBJECT * get_best_object(short x, short y);
<P>get_best_object is obsolete. Please use get_object instead.
<P><B>get_first_object</B> (new in 0.040 but undocumented)
<P>Format: OBJECT * get_first_object(short x, short y);
<P>Description: Looks at the map square X,Y, and returns the object in
this position. If there are more than one object in this space, it
will return the one at the <I>bottom</I> of the pile.
<P>Input: The X and Y coordinates of the map square to be investigated.
<P>Returns: The object it found, or NULL if nothing was found. MAKE
SURE you check that this is not NULL, otherwise the game will crash out.
<BR>
<P>Example:
<BLOCKQUOTE>OBJECT *it;
<BR>it = get_first_object(100,100);
<BR>if( it != NULL)
<BR> print("We found something!");</BLOCKQUOTE>
<P><BR><B>find_object_with_tag</B> (new in 0.05)
<P>Format: OBJECT * find_object_with_tag(int tag, STRING name);
<P>Description: Looks through the entire map and returns the first object
of type 'name' with the matching tag, or NULL if none could be found..
<P>Input: The tag number to search for, and an optional object type
to search for, or NULL if any object will do.
<P>Returns: The object it found, or NULL if nothing was found. MAKE
SURE you check that this is not NULL, otherwise the game will crash out.
<BR>
<P>Examples:
<BLOCKQUOTE><TT>OBJECT *it;</TT>
<BR><TT>it = find_object_with_tag(15,NULL); // any type of object will
do</TT>
<BR><TT>if( it != NULL)</TT>
<BR><TT> print("We found something!");</TT>
<P><TT>it = find_object_with_tag(15,"door"); // only a door will do</TT>
<BR><TT>if( it != NULL)</TT>
<BR><TT> print("We found a door!");</TT>
<BR> </BLOCKQUOTE>
<B>find_container</B> (new in 0.05)
<P>Format: OBJECT * find_container(OBJECT *object);
<P>Description: Looks through the entire map and returns the object that
contains the specified object.
<P>Input: The object which you want to find the container for.
<P>Returns: The object it found, or NULL if nothing was found. MAKE
SURE you check that this is not NULL, otherwise the game will crash out.
<BR>
<P>Example:
<BLOCKQUOTE><TT>it = find_container(object);</TT>
<BR><TT>if( it != NULL)</TT>
<BR><TT> print("We found the container which has %s in
it.",object->name);</TT></BLOCKQUOTE>
<P><BR><B>show_object</B>
<P>Format: show_object(OBJECT *object, int x,int y);
<P>Description: Displays an OBJECT on the screen, without any relation
to the map whatsoever. Used for status area and suchlike.
<P>Input: The object to be projected, and the X and Y coordinates
<I>on
the screen</I> where the object will appear.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>OBJECT *object = NULL; // Zero to begin with
<P>PROC
<P>if(object == NULL)
<BLOCKQUOTE>object = create_object("cursor");</BLOCKQUOTE>
show_object(100,100,object);
<P>ENDPROC
<BR> </BLOCKQUOTE>
<B>object_is_called</B>
<P>Format: short object_is_called(OBJECT *object, STRING name);
<P>Description: This returns a non-zero value if the NAME string is the
same as the object's name. Returns 0 if no match.
<P>Input: The object being tested, and the name we are looking for.
<P>Returns: non-zero on a success, 0 on error..
<P>Example:
<BR>
<BLOCKQUOTE>if( object_is_called(object,"door"))
<BLOCKQUOTE>print("it is a door");</BLOCKQUOTE>
</BLOCKQUOTE>
<B>move_to_pocket</B>
<P>Format: move_to_pocket(OBJECT *object, OBJECT *pocket);
<P>Description: This moves OBJECT into the pocket of the object POCKET.
<BR>
To preserve the integrity of the game, certain things are disallowed.
You cannot move an object into its own pocket,
<BR>
or pick up an object marked as a Person. If you need to do either
of these, use transfer_to_pocket.
<BR>
No checking is performed as regards weight!
<BR>
move_to_pocket correctly handles grouped objects such as a pile of coins.
<P>Input: The object to move, and the object which has the pocket
we are interested in.
<P>Returns: none.
<P>Example:
<BLOCKQUOTE>move_to_pocket(current_object,player);</BLOCKQUOTE>
<P><BR><B>transfer_to_pocket</B>
<P>Format: transfer_to_pocket(OBJECT *object, OBJECT *pocket);
<P>Description: This moves OBJECT into the pocket of the object POCKET.
<BR>
It can be used to move people, inclusding the player, into a container,
which is illegal when using move_to_pocket.
<BR>
Use with care, since the game will not work correctly if the player is
incapacitated.
<BR>
transfer_to_pocket correctly handles grouped objects such as a pile of
coins.
<P>Input: The object to move, and the object which has the pocket
we are interested in.
<P>Returns: none.
<P>Example:
<BLOCKQUOTE>transfer_to_pocket(player,vehicle);</BLOCKQUOTE>
<B>move_from_pocket</B>
<P>Format: long move_from_pocket(OBJECT *object, OBJECT
*pocket, short X, short Y);
<P>Description: This moves OBJECT out of the pocket of the object POCKET,
and put it on map square X,Y. If something else is in the way, it
will return 0, allowing you to print 'blocked' or such.
<P>Input: The object to move, object which has the pocket we are
interested in, nd the X,Y of the place to drop it.
<P>Returns: 0 if the operation failed, because there was something in the
way. 1 on success.
<P>Example:
<BLOCKQUOTE>move_from_pocket(current_object,player,100,100);</BLOCKQUOTE>
<P><BR><B>force_from_pocket</B>
<P>Format: long force_from_pocket(OBJECT *object, OBJECT
*pocket, short X, short Y);
<P>Description: This moves OBJECT out of the pocket of the object POCKET,
and put it on map square X,Y. It doesn't check to see whether the
object can go into the square or not: it just does it.
<P>Input: The object to move, object which has the pocket we are
interested in, nd the X,Y of the place to drop it.
<P>Returns: 0 if the operation failed, because the object didn't exist
or the destination was outside the map. 1 on success.
<P>Example:
<BLOCKQUOTE>force_from_pocket(current_object,player,100,100);</BLOCKQUOTE>
<B>weigh_object</B>
<P>Format: long weigh_object(OBJECT *object);
<P>Description: Returns the total weight of an object, and all within it.
<P>BUG: If you have a bag inside a bag, it will not sum the weight
of the inner bag.
<BR>
<P>Input: The object to weight, and all objects within it.
<P>Returns: Weight of the object and all who sail in her.
<P>Example:
<BR>
<BLOCKQUOTE>if( weigh_object(player) > 5000)
<BLOCKQUOTE>printf("Sire! He is weighted down with loot!\n");</BLOCKQUOTE>
</BLOCKQUOTE>
<B>add_to_party</B>
<P>Format: long add_to_party(OBJECT *new_member);
<P>Description: Adds a character to the party if possible.
<P>Input: The OBJECT (preferably a <I>character</I> but doesn't have
to be), which will be added to the party.
<P>Returns: -1 if the operation failed, (too many in party) or the number
of the new guy.
<P>Example:
<BR>
<BLOCKQUOTE>OBJECT *brick;
<P>if(add_to_party(brick) < 0 )
<BLOCKQUOTE>print("The brick doesn't want to join because the party is
too large\n");</BLOCKQUOTE>
</BLOCKQUOTE>
<B>choose_member</B>
<P>Format: int choose_member(int member);
<P>Description: Makes the party member 'member' take control and become
the player.
<P>Input: The number of the party member who will become the player.
<P>Returns: 0 if the member was not in the party or q if the operation
succeeded.
<P>Example:
<BR>
<BLOCKQUOTE>int brick_id;
<P>brick_id = add_to_party(brick);
<BR>choose_member(brick);</BLOCKQUOTE>
<P><BR><B>choose_leader</B>
<P>Format: int choose_leader(int member);
<P>Description: Makes the party member 'member' take control of the party.
All other members will follow him or her.
<P>Input: The number of the party member who will lead the party.
<P>Returns: 0 if the member was not in the party or 1 if the operation
succeeded.
<P>Example:
<BR>
<BLOCKQUOTE>int brick_id;
<P>brick_id = add_to_party(brick);
<BR>choose_member(brick);</BLOCKQUOTE>
<P><BR><B>is_solid</B>
<P>Format: int is_solid(int x; int y);
<P>Description: Checks if the map square at x,y is clear of any obstructions.
<P>Input: The x,y co-ordinates of the map square to examine.
<P>Returns: 1 if there is an obstruction there, 0 if not.
<P>Example:
<BR>
<BLOCKQUOTE>if( is_solid(100,100))
<BLOCKQUOTE>printf("Map square 100,100 is blocked\n");</BLOCKQUOTE>
</BLOCKQUOTE>
<B>in_pocket</B>
<P>Format: int in_pocket(OBJECT *obj);
<P>Description: Scans the entire world, looking for this object.
Returns 1 if the object is not where it thinks it is, which normally indicates
the object is inside a container.
<BR>in_pocket will take a comparatively long time to do, so perform any
quicker tests first when possible.
<P>Input: The object to check out.
<P>Returns: 1 if the object is inside a container, 0 if it is lying on
the ground.
<P>Example:
<BR>
<BLOCKQUOTE>if( in_pocket(player))
<BLOCKQUOTE>printf("Holy Gee, this is awful!\n");</BLOCKQUOTE>
</BLOCKQUOTE>
<B>line_of_sight</B> (new in 0.041)
<P>Format: int line_of_sight(int xa, int ya, int xb,
int yb);
<P>Description: This will draw an imaginary line between the two positions
on the map.
<BR>If there is an obstruction, it will return 0. If there is a clear
path between the points, it will return 1.
<P>Input: The two sets of X,Y coordinates, which it will try to find
a line-of-sight between.
<P>Returns: 1 if there is a clear line of sight, 0 if there is an obstruction.
<P>Example:
<BR>
<BLOCKQUOTE>if( line_of_sight(player->x,player->y,enemy->x,enemy->y))
<BLOCKQUOTE>printf("Time to die!\n");</BLOCKQUOTE>
</BLOCKQUOTE>
<B>move_to_top</B>
<P>Format: void move_to_top(OBJECT *object);
<P>Description: This will move the object to the top of the pile for the
square it is sitting on.
<BR>(It actually works by transferring the object to 0,0 and then back
to the previous position, so it is now at the top of the heap).
<P>Input: The object to adjust.
<P>Returns: none.
<P>Example:
<BLOCKQUOTE>move_to_top(player);</BLOCKQUOTE>
<B>spill_contents</B>
<P>Format: void spill_contents(OBJECT *object);
<P>Description: Removes all the contents of a container, and puts them
in a pile above it.
<P>Input: The object to have its contents spilled.
<P>Returns: none.
<P>Example:
<BR>
<BLOCKQUOTE>spill_contents(chest);</BLOCKQUOTE>
<B>spill_contents_at</B>
<P>Format: void spill_contents_at(OBJECT *object, int x, int y);
<P>Description: Removes all the contents of a container, and puts them
in a pile elsewhere.
<P>Input: The object to have its contents spilled, the position where
the spillage will occur.
<P>Returns: none.
<P>Example:
<BR>
<BLOCKQUOTE>spill_contents_at(chest,chest->x,chest->y+1);</BLOCKQUOTE>
<B>move_forward</B> (new in 0.05)
<P>Format: int move_forward(OBJECT *object);
<P>Description: Moves the object one step forward in the direction it is
facing.
<P>Input: The OBJECT which is to be moved.
<P>Returns: 1 if the move was successful, 0 if it was blocked by an obstruction.
<BR>
<P>Example:
<BLOCKQUOTE>
<BR>move_forward(player);</BLOCKQUOTE>
<B>move_backward</B> (new in 0.05)
<P>Format: int move_backward(OBJECT *object);
<P>Description: Moves the object one step backward in the opposite direction
to the one it is facing.
<P>Input: The OBJECT which is to be moved.
<P>Returns: 1 if the move was successful, 0 if it was blocked by an obstruction.
<BR>
<P>Example:
<BLOCKQUOTE>
<BR>move_backward(player);</BLOCKQUOTE>
<P><BR><B>turn_l</B> (new in 0.05)
<P>Format: int turn_l(OBJECT *object);
<P>Description: Rotates the object 90 degrees anti-clockwise.
<P>Input: The OBJECT which is to be rotated.
<P>Returns: The direction the object is now facing.
<BR>
<P>Example:
<BLOCKQUOTE>
<BR>turn_l(player);</BLOCKQUOTE>
<P><BR><B>turn_r</B> (new in 0.05)
<P>Format: int turn_r(OBJECT *object);
<P>Description: Rotates the object 90 degrees clockwise.
<P>Input: The OBJECT which is to be rotated.
<P>Returns: The direction the object is now facing.
<BR>
<P>Example:
<BLOCKQUOTE>
<BR>turn_r(player);</BLOCKQUOTE>
<P><BR><B>add_quantity</B> (new in 0.05)
<P>Format: void add_quantity(OBJECT *container, STRING type, int
quantity);
<P>Description: Creates a quantity of a single type of object and places
them in another object's pockets.
<BR>If the object to be created has its QUANTITY flag set, a single object
will be created and its quantity value set to the specified amount.
If it does not have the QUANTITY flag, then the requested quantity will
be the number of objects created.
<P>Input: The container which will receive these objects, the type
of object and the number of objects to create.
<P>Returns: Nothing.
<BR>
<P>Example:
<BLOCKQUOTE>printf("The pharoah showers you with gold!\n");
<BR>add_quantity(player,"gold_coins",1000000);</BLOCKQUOTE>
<P><BR><B>take_quantity</B> (new in 0.05)
<P>Format: int take_quantity(OBJECT *container, STRING type, int
quantity);
<P>Description: Destroys a quantity of a single type of object from another
object's pockets.
<BR>If the requested amount is not in the object's pockets it returns 0.
<P>Input: The container which will lose these objects, the type of
object and the number of objects to destroy.
<P>Returns: 1 on success, 0 if there wasn't that many objects there.
<BR>
<P>Example:
<BLOCKQUOTE>if(!take_quantity(player,"gold_coins",10000))
<BR> printf("I'm sorry sir, you can't afford it.\n");</BLOCKQUOTE>
<H4>
4.3.2 - IO functions</H4>
<B>print</B> (and printf)
<P>Format: print(STRING text, parameters....);
<P>Description: prints some text on the console. Corresponds to printf
in real C.
<P>Input: A string, which may contain control codes, followed by
zero or more parameters ..
<P>Control codes:
<BR>
<BR>
<TABLE BORDER WIDTH="100%" >
<TR>
<TD WIDTH="15%"><B>Control code</B></TD>
<TD><B>Description</B></TD>
</TR>
<TR>
<TD>\n</TD>
<TD>Begin new line. Only \n at the end of the string will work
correctly, \n in front will have odd results.</TD>
</TR>
<TR>
<TD>\\</TD>
<TD>A slash, \ (Single slash is used
to start a control code, like \n)</TD>
</TR>
<TR>
<TD>\"</TD>
<TD>A quote, " (the string is started by
quotes. In BASIC you use """ , but in C is is \")</TD>
</TR>
<TR>
<TD>%d</TD>
<TD>A decimal number appears at this point. E.g. print("found
%d things",100); prints 'found 100 things'</TD>
</TR>
<TR>
<TD>%c</TD>
<TD>A character appears at this point. E.g. print("[%c]",'a');
prints '[a]'</TD>
</TR>
<TR>
<TD>%s</TD>
<TD>A string appears at this point.</TD>
</TR>
<TR>
<TD>%%</TD>
<TD>A percentage, % (single % is used to print a parameter, like
%d)</TD>
</TR>
</TABLE>
<BR>
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>STRING str1="cow";
<BR>STRING str2="moon";
<P>printf("This is a string\n");
<BR>printf("%d + %d = %d\n",1,1,2);
<BR>printf("The %s jumped over the %s\n",str1,str2);
<BR> </BLOCKQUOTE>
Output:
<P>This is a string
<BR>1 + 1 = 2
<BR>The cow jumped over the moon
<P><B>printxy</B>
<P>Format: printxy(int x,int y, STRING text, parameters....);
<P>Description: prints some text directlt on the screen, not to the console.
The text will not appear until the next redraw.
<P>Input: Two numbers, the X and Y coordinates where the text will
appear. The TEXT and PARAMETERS are the same format as print, which
is described above.
<BR>
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>printxy(32,32,"Thiswill appear in the game window");</BLOCKQUOTE>
<B>clear</B>
<P>Format: clear();
<P>Description: clears all text from the game console..
<P>Input: nothing.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>print("You won't see this\n");
<BR>clear();</BLOCKQUOTE>
<B>play_song</B>
<P>Format: play_song(STRING song_name);
<P>Description: Plays a song.
<P>Input: The song name. This will be one of the entries in
'SECTION: MUSIC' of the script file.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>play_song("intro");</BLOCKQUOTE>
<B>play_sound</B>
<P>Format: play_sound(STRING sound_name);
<P>Description: Plays a sound.
<P>Input: The sound name. This will be one of the entries in
'SECTION: SOUNDS' of the script file.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>play_sound("ouch");</BLOCKQUOTE>
<B>stop_song</B>
<P>Format: stop_song();
<P>Description: Dips the volume of the music to 0. Does not stop
the actual playing of the music.
<BR><I>You must call start_song() afterwards</I>.
<P>Input: none.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>stop_song();</BLOCKQUOTE>
<B>start_song</B>
<P>Format: start_song();
<P>Description: Resets the volume to it's original level, before stop_song()
was called.
<BR><I>You must have called stop_song() beforehand, or it will have no
effect.</I>
<P>Input: none.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>start_song();</BLOCKQUOTE>
<B>get_input</B>
<P>Format: get_input();
<P>Description: Gets a fresh key from the user, and puts it into the system
variable, <I>key</I>.
<P>Input: none.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>get_input();
<BR>if (key == KEY_UP)
<BLOCKQUOTE>print("You pressed UP\n");</BLOCKQUOTE>
</BLOCKQUOTE>
<B>get_yn</B>
<P>Format: get_yn(STRING question);
<P>Description: Prints a question (followed by 'are you sure?') and waits
for the user to press Y or N.
<P>Input: A string containing the question.
<P>Returns: 1 if the user pressed Y, otherwise 0.
<P>Example:
<BR>
<BLOCKQUOTE>if(get_yn("Commit suicide"))
<BR> call_vrm("kill_player");</BLOCKQUOTE>
<P><BR><B>get_number</B>
<P>Format: get_number(int default);
<P>Description: Prints the number given as a default, and allows the user
to edit it.
<P>Input: A number, which is the default if the user just presses
Enter.
<P>Returns: The new number, or 0 if the user pressed Escape.
<P>Example:
<BR>
<BLOCKQUOTE>int num;
<BR>printf("Enter a number:\n");
<BR>num = get_number(100);
<BR>printf("The user typed %d\n",num);</BLOCKQUOTE>
<P><BR><B>redraw</B>
<P>Format: redraw();
<P>Description: Updates the entire screen display. This happens in the
main loop anyway, but if your VRM has taken control, to choose a spell
or something, you'll want to do this.
<P>Input: none.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>show_object(100,100,object); // Draw the object
<BR>redraw(); // Update the display to make it appear immediately</BLOCKQUOTE>
<B>redraw_map</B>
<P>Format: redraw_map();
<P>Description: Updates the entire screen display, and redraws the map,
recalculating the light levels too.
<BR>This happens in the main loop anyway, but if your VRM has taken control,
to choose a spell or something, you'll want to do this.
<P>Input: none.
<P>Returns: nothing.
<P>Example: (Fades the viewport to black)
<BLOCKQUOTE>int ctr;
<BR>for(ctr=0;ctr<255;ctr++)
<BR> {
<BR> set_darkness(ctr);
<BR> redraw_map();
<BR> waitfor(2);
<BR> }</BLOCKQUOTE>
<B>lightning</B> (new in 0.05)
<P>Format: lightning(duration);
<P>Description: Flashes the screen blue-white for a number of game ticks.
This number is in 35ths of a second and should be at least 2. It
will not appear visible until the next update of the screen (e.g.,redraw_map).
<P>Input: Length of the lightning flash in 1/35ths of a second.
<P>Returns: nothing.
<P>Example:
<BLOCKQUOTE>lightning(2);</BLOCKQUOTE>
<H4>
4.3.3 - flow control functions</H4>
<B>call_vrm</B>
<P>Format: call_vrm(STRING name);
<P>Description: Calls another VRM, using the name from Section: CODE.
<P>Input: The name of the VRM to call.
<P>Returns: nothing.
<P>Example:
<BR>
<BLOCKQUOTE>call_vrm("object_vrm");</BLOCKQUOTE>
<H4>
4.3.4 - miscellaneous functions</H4>
<B>get_tile</B>
<P>Format: TILE * get_tile(short x, short y);
<P>Description: Looks at the map square X,Y, and returns the TILE in this
position. See 4.2.5 for more info.
<P>Input: The X and Y coordinates of the map square to be investigated.
<P>Returns: A pointer to the tile. Unless the coordinates
were off the map, it will always return something.
<BR>
<P>Example:
<BLOCKQUOTE>TILE *t;
<BR>t = get_tile(100,100);
<BR>print("The tile at 100,100 is described as.. '%s'\n",t->desc)</BLOCKQUOTE>
<B>restart</B>
<P>Format: restart( );
<P>Description: Reloads the map and sets everything back to it's default
state.
<P>Input: None.
<P>Returns: None.
<BR>
<P>Example:
<BLOCKQUOTE>if(everyone == dead)
<BR> restart();</BLOCKQUOTE>
<B>set_darkness</B>
<P>Format: set_darkness(int level);
<P>Description: Sets the amount of darkness, 0-255.
<P>Input: Amount of darkness to apply. 0 is daylight, and 255 is
total blackness.
<P>Returns: None.
<BR>
<P>Example:
<BLOCKQUOTE>set_darkness(192); // Make everything quite
dark, but not pitch black.</BLOCKQUOTE>
<B>random</B>
<P>Format: int rnd(int max_number);
<P>Description: rnd returns a random number from 0 up to the number you
specify as the maximum, -1.
<BR>For example, rnd(3) will return either 0,1 or 2.
<P>Input: The maximum number it should return, plus one.
<P>Returns: The random number.
<P>Example:
<BLOCKQUOTE>int t;
<BR>t = rnd(4);
<BR>if(t == 0)
<BR> print("It was a zero\n");
<BR>if(t == 1)
<BR> print("It was a one\n");
<BR>if(t == 2)
<BR> print("It was a two\n");
<BR>if(t == 3)
<BR> print("It was a three\n");</BLOCKQUOTE>
<B>waitfor</B>
<P>Format: void waitfor(int time);
<P>Description: <I>waitfor</I> waits for a number of time units, before
execution is resumed.
<BR>Each time unit is 1/35 of a second (because IRE uses a 35Hz timebase).
<P>For example, waitfor(35) will delay one second.
<BR>It does not stop the animation.
<P>Input: The number of 1/35ths of a second to pause.
<P>Returns: None.
<P>Example:
<BLOCKQUOTE>waitfor(35); // delay one second</BLOCKQUOTE>
<P><BR> <B>wait_for_animation</B> (new in 0.05)
<P>Format: void wait_for_animation(OBJECT *obj);
<P>Description: <I>wait_for_animation</I> waits for an object to finish
animating before execution is resumed. It is useful for special effects
or plot-critical scenes. It will return immediately if the object
has an animation that loops.
<P>Input: The object with the animation to wait on.
<P>Returns: None.
<P>Example:
<BLOCKQUOTE>set_sequence(arch_villain,"arch_villain_dying");
<BR>wait_for_animation(arch_villain);</BLOCKQUOTE>
<H4>
4.4 - System Variables</H4>
<B>show_roof</B>
<P>show_roof is a CHAR.
<P>show_roof can be set to either 1 or 0.
<BR>If show_roof is 1, the ROOFTOP layer is displayed and you cannot see
inside buildings.
<BR>If show_roof is 0, the ROOFTOP layer is not displayed, and you see
the insides of buildings.
<BR>
<BR>
<P><B>storage</B>
<P>storage is an array of LONGs, which you can use to store things.
Mainly they are used to communicate between VRMs.
<BR>STORAGE is always available at any point. There are up to 1024
elements in the storage array, and future releases will have more.
<P>storage[0] is the first storage item, and storage[1023] is the last.
NEVER use storage[1024] because it does not exist!
<P><B>objectstore</B>
<P>objectstore is an array of unallocated OBJECTS, which you can use to
store things. Mainly they are used to communicate between VRMs. For
instance, objectstore[0] might point to the player. By using create_object
you can add new objects
<BR>in the objectstore. The status areas in the demo work this way.
<P>OBJECTSTORE is always available at any point. There are up to
128 elements in the storage array, and future releases will have more.
<P>objectstore[0] is the first storage item, and objectstore[127] is the
last. NEVER use objectstore[128] because it does not exist!
<BR>
<P><B>key</B>
<P>key is the current keypress. When the user presses a key, the
value of the key they have pressed will end up here.
<BR>If you need to get a fresh keypress in a VRM, use the function get_input.
Otherwise key will contain the last keypress from the main loop.
<P>See also 4.5, the Keyboard List
<BR>
<P><B>current_object, victim</B>
<P>See section 4.2.4
<P><B>game_minute, game_hour, game_day,game_month, game_year</B>
<P>These allow you to examine and control the current time in the game.
<BR>The game system follows earth time, with each turn taking one second,
and so-on.
<P>It differs from the earth calendar in that each month is always
30 days, although this may be customisable in future releases.
<BR>
<H4>
4.5 - Keyboard Macros</H4>
Use these whenever you want to see if a key has been pressed.
<P>Example:
<BR>
<BLOCKQUOTE>if( key == KEY_UP)
<BLOCKQUOTE>print("You pressed UP");</BLOCKQUOTE>
</BLOCKQUOTE>
<B>Function Keys</B>
<BLOCKQUOTE>KEY_F1
<BR>KEY_F2 (Used by the system)
<BR>KEY_F3 (Used by the system)
<BR>KEY_F4
<BR>KEY_F5
<BR>KEY_F6
<BR>KEY_F7
<BR>KEY_F8
<BR>KEY_F9
<BR>KEY_F10 (Used by the system)
<BR>KEY_F11
<BR>KEY_F12</BLOCKQUOTE>
<B>Numeric keyboard keys</B>
<BR>
<BLOCKQUOTE>KEY_ESC
<BR>KEY_1
<BR>KEY_2
<BR>KEY_3
<BR>KEY_4
<BR>KEY_5
<BR>KEY_6
<BR>KEY_7
<BR>KEY_8
<BR>KEY_9
<BR>KEY_0</BLOCKQUOTE>
<B>Main keyboard section</B>
<BR>
<BLOCKQUOTE>KEY_TAB
<BR>KEY_Q
<BR>KEY_W
<BR>KEY_E
<BR>KEY_R
<BR>KEY_T
<BR>KEY_Y
<BR>KEY_U
<BR>KEY_I
<BR>KEY_O
<BR>KEY_P
<BR>KEY_ENTER
<BR>KEY_A
<BR>KEY_S
<BR>KEY_D
<BR>KEY_F
<BR>KEY_G
<BR>KEY_H
<BR>KEY_J
<BR>KEY_K
<BR>KEY_L
<BR>KEY_Z
<BR>KEY_X
<BR>KEY_C
<BR>KEY_V
<BR>KEY_B
<BR>KEY_N
<BR>KEY_M
<BR>KEY_COMMA
<BR>KEY_DOT
<BR>KEY_SPACE</BLOCKQUOTE>
<B>Arrow Keys</B>
<BR>
<BLOCKQUOTE>KEY_UP
<BR>KEY_DOWN
<BR>KEY_LEFT
<BR>KEY_RIGHT</BLOCKQUOTE>
<HR WIDTH="100%">
<BR>
<CENTER>
<H2>
Part 5 - Editing Conversations</H2></CENTER>
<H3>
5.1 Overview</H3>
Conversations in IRE 0.05 and above are made using a simple language a
bit like HTML.
<BR>A conversation can be started in one of two ways:
<P>1. The player Talks to an object or a person
<BR>2. A VRM routine calls the function talk_to(name,start)
<P>When a conversation takes place, the game will load in the file containing
the conversation and process it interactively like a web browser.
<P>Conversations are based on pages. At the top of the page is an
image, normally a portrait of the person you're talking to.
<BR>Below this is the text of the conversation, and at the bottom are the
choices you get of what to say.
<BR>Each choice is a link to another page, or a link to "exit" which ends
the conversation.
<P>Commands can also be embedded into the page, which can create objects,
remove objects, change flags, and call VRM functions.
<BR>You can also use commands to make different things happen depending
on whether a flag is true or false.
<P>More commands will be added in the future as necessary.
<BR>
<H3>
5.2 Page structure and simple commands</H3>
Like HTML, pages are defined as text files with commands.
<BR>All commands are enclosed in [brackets] and they may affect all text
until the end of the line.
<P>Each page has it's own title. When the conversation starts it
will look for the page called 'Start', although it may also look for other
pages too in future.
<P>The page starts with the command:
<BR>[page="start"]
<P>..and continues until the command:
<BR>[endpage]
<P>Everything between these two commands will be displayed on the screen,
unless it is another command.
<P>The commands you will need to know to make simple conversations are:
<P>[nextpage=""]
<BR>[link=""]
<BR>[linkto=""]
<BR>[image=""]
<BR>[colour="#xxxxxx"]
<P><B>Important tips!</B>
<UL>
<LI>
Anything outside the [page=""] line and the [endpage] line, is ignored.
You can put comments there.</LI>
<LI>
There is no fixed limit to the size of the conversation file, as long as
it will fit in memory.</LI>
<LI>
If you put the word $PLAYER anywhere in the text, it will be replaced by
the player's individual name.</LI>
<LI>
Similarly $CHARNAME will be replaced by the individual name of the character
you're talking to.</LI>
</UL>
<P><BR><B>5.2.1 Simple page linking</B>
<P>There are two ways to link pages. [nextpage=""] is the most simple,
so I'll explain it first.
<P>Here's an example:
<P>[page="start"]
<P>This is the first page.
<BR>Press a key for the second page...
<BR>[nextpage="page2"]
<BR>[endpage]
<P>[page="page2"]
<P>This is the second page!
<BR>Press a key to finish.
<BR>[nextpage="exit"]
<BR>[endpage]
<P>This will display two lines:
<P><TT>This is the first page.</TT>
<BR><TT>Press a key for the second page...</TT>
<P>When you press a key, the page will change and read two more lines:
<P><TT>This is the second page!</TT>
<BR><TT>Press a key to finish.</TT>
<P>..and when you press a key the conversation will end.
<P>The command [nextpage="page2"] makes the program wait for a key to be
pressed, and then it looks for a page titled 'page2' and displays that.
<P>The command [nextpage="exit"] makes the conversation finish when a key
is pressed.
<P><B>5.2.2 Interactive page linking</B>
<P>Now let's look at [link=""] and [linkto=""]
<P>These two commands are used together to provide the choices at the bottom
of the page.
<BR>[link=""] displays the message at the bottom, and [linkto=""] is the
page that the link will take you to.
<BR>LINK must come first, and LINKTO just afterwards, otherwise it may
fail.
<P>Here's an example:
<P>[page="start"]
<BR>You see a shifty-looking man in a trenchcoat.
<P>"Pssst! Wanna buy some stuff?"
<P>[link="What 'stuff' have you got?"]
<BR>[linkto="whatstuff"]
<BR>[link="No! Get lost!"]
<BR>[linkto="getlost"]
<BR>[endpage]
<BR>
<P>[page="whatstuff"]
<BR>"The usual contrabands..Mars bars.. M&Ms... Terry's chocolate oranges.."
<P>[link="Not today man, the feds are everywhere"]
<BR>[linkto="nottoday"]
<BR>[link="You're off your rocker!"]
<BR>[linkto="getlost"]
<BR>[endpage]
<BR>
<P>[page="getlost"]
<BR>"Suit yerself.."
<P>He walks away in a huff.
<BR>[nextpage="exit"]
<BR>[endpage]
<BR>
<P>[page="nottoday"]
<BR>"Wo! Thanks for the tip, man."
<P>He looks both ways and slips off into the night.
<BR>[nextpage="exit"]
<BR>[endpage]
<BR>
<P>You should be able to work out what that does. If not, put it
into a file and try it out.
<P>You can have a maximum of 10 links per page (this will take a lot of
screen room!).
<P><B>5.2.3 Images</B>
<P>The portrait at the top of the screen is set using the [image=""] command.
<BR>You must put this as the first command after the [page=""] line.
<BR>The word in quotes is the title of a Sprite found in the "Section:
sprites" part of the scriptfile, main.txt.
<BR>See chapter 3.2.1 of this document.
<P>Here's an example:
<P>[page="start"]
<BR>[image="greengrocer"]
<P>You see a small greengrocer.
<P>"Good day sir, how can I help you?"
<P> :
<BR> :
<BR> :
<P>[endpage]
<P>You must specify a portait for <I>each</I> page. This allows you
to change the character's expression from page to page.
<P>You can also specify a background image if you don't like the blackness.
<BR>This is done with the following command:
<P>[backing="filename.pcx"]
<P>The game will not look in the Scriptfile for this image, it will be
loaded directly from disk.
<P>This is actually what happens if you press F1 for help in The Flat.
It loads a conversation called "help.txt" which is in the FLAT/ directory,
and this is what it does:
<P>[page="start"]
<BR>[backing="backings/help1.pcx"]
<BR>[nextpage="exit"]
<BR>[endpage]
<P>This feature is considered experimental.
<P><B>5.2.4 Setting the text colour</B>
<P>You may wish to change the colour of text in the body of the conversation.
<BR>This is done using the [colour=""] command. (You may also use
[color=""] if you prefer)
<BR>It works in the same way as HTML, except that it only lasts for the
rest of the line.
<P>The colour is in quotes, and it is specified with a # followed by six
hex values, just like HTML.
<BR>The first two set the amount of red in the colour (00-ff), the second
two set the amount of green (00-ff) and the last two the amount of blue
in the colour (00-ff).
<P>You can get little java applets and things to work out the colours,
just look for a good page about web design.
<BR>Here are some of the most commonly-used colours:
<P>red: #ff0000
<BR>green: #00ff00
<BR>blue: #0000ff
<BR>pink: #ff00ff
<BR>yellow: #ffff00
<BR>cyan: #00ffff
<BR>orange: #ff8000
<BR>grey: #808080
<P>Black would be #000000, but you can't change the background colour yet,
so this would be invisible.
<BR>White is #ffffff, but this is the default anyway.
<P>Generally I use medium grey [colour="#808080"] for narration, and leave
the rest of the text white.
<P>Returning to the sweet-pusher as an example:
<P>[page="start"]
<BR>[colour="#808080"]You see a shifty-looking man in a trenchcoat.
<P>"Pssst! Wanna buy some stuff?"
<P>[link="What 'stuff' have you got?"]
<BR>[linkto="whatstuff"]
<BR>[link="No! Get lost!"]
<BR>[linkto="getlost"]
<BR>[endpage]
<BR>
<H3>
5.3 Advanced Conversations: conditional branching</H3>
Sometimes you want to have the same person behave differently when things
happen in the game.
<BR>For example, you've just come across an important object in the game.
You should now be able to ask people about it, by making new choices appear.
<P>This is done with flags. A flag is a message that can either be
true or false, depending on what has happened previously.
<P><B>5.3.1 Checking for an object</B>
<P>The simplest case is 'Am I carrying such-and-such an object?'
The result will either be true(yes) or false (no).
<P>Here's an example. It's not really a conversation, but anyhow.
If you're carrying 'The Death', it says so, otherwise it says you're not
carrying it.
<P>[page="start"]
<BR>System test: are you carrying that nasty weapon, THE DEATH?
<P>[am_carrying the_death]
<BR>[if true]Yes, you are carrying it.
<BR>[if_not true]No, you are not carrying it.
<BR>[endpage]
<P>Now, how does it work?
<P>[am_carrying the_death]
<P>This looks in the player's pocket for an object named 'the_death'.
<BR>If it is in your pocket, it will set the flag 'True' to be true.
<P>The next part is clever.
<BR>[if true]Yes, you are carrying it.
<P>[if true] Examines the flag called 'true', and then decides what to
do. If 'true' is set true, it prints the text. Otherwise it
does nothing at all.
<P>[if_not true]No, you are not carrying it.
<P>This again looks at the flag called 'true'. But it does the opposite
thing! If 'true' is NOT true, it prints the text, else it does nothing.
<P>Because both of these are looking for one of the two possible states,
ONE of them will be displayed and the other won't.
<P>You can also use [if false] instead of [if_not true].
<P>(For the advanced reader: TRUE and FALSE are separate flags, but they
are always set to be opposite.)
<P><B>5.3.2 Important tips!</B>
<UL>
<LI>
You can check the same flag as many times as you like without it changing,
so you can have multiple lines.</LI>
</UL>
E.g.
<P>[am_carrying mobile_phone]
<BR>[if true]"You have played this game for far too long, mortal!"
<BR>[if true]"It's time to go to bed..."
<BR>
<UL>
<LI>
What comes after the [if] command does not have to be text, it can be another
command, too.</LI>
</UL>
E.g.
<P>[am_carrying large_stereo]
<BR>[if true]"This is a library, sir. I'm afraid I must ask you to
leave."
<BR>[if true][nextpage="exit"]
<BR>[if false]"Welcome to the library. How can I help you?"
<BR>[if false][nextpage="howcanihelp"]
<P>In this case, the librarian will ask you to leave and stop talking if
you have the ghetto-blaster. If you don't, they will go onto a different
page and continue the conversation.
<P>If you want to do more complex actions conditionally, you can either
use everal IF lines, or use the GOTO command to switch to another page.
[goto=] is the same as [nextpage=], but it switches instantly, without
waiting for a keypress.
<P>Here's and example:
<P>[page="something"]
<BR>[if murdered_king][goto="murderedking"]
<BR>[if murdered_queen][goto="murderedqueen"]
<P>"Hello!"
<BR> :
<BR> :
<BR> :
<BR>[endpage]
<P>[page="murderedking"]
<BR>"My God! You've murdered His Royal Highness! GUARDS!!!"
<P>[nextpage="exit"]
<BR>[callvrm="callguards"]
<BR>[endpage]
<P>[page="murderedqueen"]
<BR>"My God! You've murdered Her Majesty! GUARDS!!!"
<P>[nextpage="exit"]
<BR>[callvrm="callguards"]
<BR>[endpage]
<BR>
<P><B>5.3.3 Checking for a party member</B>
<P>Similarly to looking for an object, you will also want to see if a particular
person is in your party.
<P>[is_in_party gordon_harris]
<BR>[if true]"Ah, any friend of Gordon's is a friend of mine."
<BR>[if true][nextpage="page2"]
<BR>[if false]"I don't know you, stranger!"
<BR>[if false][nextpage="exit"]
<P><B>5.3.4 Using your own flags</B>
<P>You are not just lumbered with True and False, you can create any number
of flags you like, up to 8192.
<P>The commands you use to create flags are SET and CLEAR, which make the
flag be true or false, depending on which one you used. (Set makes
a flag true, clear makes it false).
<P>The flags are automatically created as you try to use them. If
you try to set or clear a flag which doesn't exist yet, it is created there
and then. If you try to test a flag which doesn't exist , it is assumed
to be false.
<P>For example:
<P>[if_not already_met]"Hello, I'm Gordon Harris."
<BR>"How can I help you?"
<BR>[set already_met]
<P>The first time you have this conversation, he says "Hello, I'm Gordon
Harris", because the flag already_met is false.
<BR>Then it prints "How can I help you?" which always appears.
<BR>Finally it sets the flag 'already_met' to be True, so the introduction
will not be shown again, unless you do [clear already_met].
<P><B>5.3.5 Personal Flags</B>
<P>The flags described above are fine for many circumstances, but they
are 'global', that is, all the characters see the flag the same.
<BR>Clearly this is not good for the above example, since by meeting Gordon
Harris, you would also have 'met' all the other characters in the game.
<P>Once solution would be to have lots and lots of flags, for example 'met_gordon_harris'
and 'met_kevin_parrot' etc, but this would be untidy.
<P>Instead, there are 32 numbered flags, which are specific to the current
person you're talking to.
<BR>These are called 'Personal Flags', or p-flags for short.
<P>As I mentioned, the p-flags do not have names, they are numbered from
0 to 31.
<BR>If you need to keep track of each p-flag number, you can write a memo
at the top of the file, before the first [page=""] line.
<P>They have their own special [if] commands:
<P>[if_pflag n] (or [if_personal_flag
n])
<BR>[if_not_pflag n] (or [if_not_personal_flag n])
<P>[set_pflag n] (or [set_personal_flag
n])
<BR>[clear_pflag n] (or [clear_personal_flag n])
<P>Here's an example:
<P>[if_not_pflag 0]"Hello, I'm Gordon Harris."
<BR>"How can I help you?"
<BR>[set_pflag 0]
<P>This time, it uses the personal flag specific to Gordon Harris.
In fact, if you had more than one copy of Gordon Harris in the game, you
would still be able to meet both of them individually.
<BR>
<H3>
5.4 Manipulating the game world</H3>
<P><BR>This is the most neat part of the conversation system.
<P>By manipulating the environment , you will be able to do really neat
stuff, like buying and selling, creating and destroying objects, and by
calling a VRM function, absolutely anything else.
<P><B>5.4.1 Calling VRM functions</B>
<P>There are now three ways to call VRM functions from a conversation.
<P>1. [callvrm="function"]
<BR>2. [on_exit_callvrm="function"]
<BR>3. [set_behaviour="function"]
<P>[callvrm=]
<P>This calls the VRM function immediately. You should not call redraw()
in the VRM function you are using, or the display will become corrupted.
<P>VRM functions can interact with the conversation too, by setting flags
(such as True and False) and p-flags.
<BR>This is a way to get information about the game state if there isn't
a command to do that in the conversation.
<BR>You can also use it to move objects around, or open doors by talking
to an intercom.
<P>[on_exit_callvrm=]
<P>This calls the VRM as soon as the conversation ends.
<BR>This should be used when the VRM will redraw the screen, or you are
doing something drastic such as killing the player.
<P>When the VRM is called, current_object will be set to the character
you're talking to.
<P>For example:
<P>[page="start"]
<BR>"Hello."
<P>[link="You're a b*st*rd!"]
<BR>[linkto="bstard"]
<BR>[endpage]
<P>[page="bstard"]
<BR>[if_not_pflag 0]"Never say that to me again!"
<BR>[if_not_pflag 0][nextpage="exit"]
<BR>[if_pflag 0]"Now you die!"
<BR>[if_pflag 0][on_exit_callvrm="killplayer"]
<BR>[if_pflag 0][nextpage="exit"]
<BR>[set_pflag 0]
<BR>[endpage]
<P>If you insult this guy twice, he kills you, by calling the VRM function
'killplayer'.
<P>[set_behaviour=]
<P>This changes the behaviour of the current object so that it calls this
VRM every turn.
<P>For example:
<P>[set_behaviour="enemy_flee"]
<P>or:
<P>"In the beginning there was Darkness, and the Darkness was without form
and void."
<BR>"And in addition to the Darkness there was also Me."
<BR>"And I moved upon the face of the Darkness and I saw that I was alone."
<P>"Let there be light."
<BR>[set_behaviour="thermostellar_device_explode"]
<BR>[nextpage="exit"]
<P><B>5.4.2 Creating and destroying objects</B>
<P>You can create objects directly in the player's pockets.
<BR>This has several uses, besides the obvious one in Ultima 6, where the
King gives you a key when you talk to him.
<BR>It can also be used for trading, by creating the money in the player's
backpack and destroying the object you sold, or vice-versa.
<P>At present [create] does not check to see whether there is room in your
backpack to carry the object.
<BR>However [destroy] (or [remove]) does check to see whether the object
<I>is</I>
in your backpack, so that the angry trader can poke you in the eye if you
try to sell something you don't have.
<P>This check is performed of course, by setting the global flags TRUE
and FALSE to the appropriate value afterwards.
<P>You also specify the amount of objects you want to create or destroy.
In some cases this will be ignored, if the object is indivisible, but for
other cases such as money, it will add or remove various quantities of
that object from your backpack.
<P>If you want to take away an amount of something, it will return FALSE
if you don't have that much, to prevent you from being able to short-change
the trader.
<P>Here's an example, selling a TV set:
<P>[destroy 1 tv]
<BR>[if false]"What are you trying to pull?"
<BR>[if true][create 1000 gold_coins]
<BR>[if true]"Done!"
<BR>[nextpage="start"]
<P>Here's another, buying a TV set:
<P>[destroy 2000 gold_coins]
<BR>[if false]"You can't afford it!"
<BR>[if true]"Thankyou, sir!"
<BR>[if true][create 1 tv]
<BR>[nextpage="start"]
<BR>
<P><B>5.4.3 The theory of the Conservation of Money</B>
<P>Now that example was very crude. The money was actually destroyed
and the object was created on-demand.
<P>This is what Ultima 6 and Ultima 7 do, but you might prefer it if the
money and goods actually change hands.
<P>This would mean that you could actually kill the trader after taking
the money and get the TV back afterwards, but you would also have to make
sure the trader is stuffed with cash, or <I>he</I> won't be able to afford
the TV when you try to sell it!
<P>If you prefer to work this way, instead of using CREATE and DESTROY,
use GIVE and TAKE.
<BR>But don't blame me if the King gives the player the only copy of the
key to the castle and the player loses it..
<P>[take n objects]
<P>This takes the specified object (or an amount of them)from the player's
backpack and transfers it into the backpack of the character you're talking
to. No loss!
<P>Similarly,
<BR>[give n objects]
<BR>..will take the specified object(s) from the backpack of the character
you're talking to, and transfer them to the player's backpack.
<P>As an example, here's the buying and selling the TV again, but with
the money and the TV being moved around instead of created and destroyed.
<P>[take 1 tv]
<BR>[if false]"What are you trying to pull?"
<BR>[if true][give 1000 gold_coins]
<BR>[if true]"Done!"
<BR>[nextpage="start"]
<P>Here's another, buying a TV set:
<P>[take 2000 gold_coins]
<BR>[if false]"You can't afford it!"
<BR>[if true]"Thankyou, sir!"
<BR>[if true][give 1 tv]
<BR>[nextpage="start"]
<P>Neither of these examples take into account whether the trader has the
money or the TV.
<BR>This is more complex, since GIVE will change the state of TRUE and
FALSE, so we'll need to use a temporary flag.
<P>Here's the finished version..
<P>[clear temp]
<BR>[take 1 tv]
<BR>[if false]"What are you trying to pull?"
<BR>[if false][nextpage="exit"]
<BR>[if true][set temp]
<BR>[if temp][give 1000 gold_coins]
<BR>[if temp][if true]"Done!"
<BR>[if temp][if false]"I'm sorry sir, I seem to have exceeded my budget
for acquisitions."
<BR>[if temp][if false][give 1 tv]
<BR>[nextpage="start"]
<BR>
<P>[clear temp]
<BR>[take 2000 gold_coins]
<BR>[if false]"You can't afford it!"
<BR>[if true][set temp]
<BR>[if temp][give 1 tv]
<BR>[if temp][if true]"Thankyou, sir!"
<BR>[if temp][if false]"I'm sorry sir, we're out of stock."
<BR>[if temp][if false][give 2000 gold_coins]
<BR>[nextpage="start"]
<BR>
<P>
<HR WIDTH="100%">
<BR>
<BR>
<BR>
<CENTER>
<H2>
Part 6 - Game description files</H2></CENTER>
A finished IRE game will consist of two files, something like:
<P>MYGAME.RAR
<BR>MYGAME.GAM
<P>The .RAR file will contain the resources, all the sound, graphics and
level data.
<BR>The .GAM file is a text file containing the descriptions needed to
make the .RAR file work.
<P>Typically it will look like this:
<BR>
<P><TT>#</TT>
<BR><TT># Generic Description file</TT>
<BR><TT>#</TT>
<P><TT>-file mygame.rar</TT>
<BR><TT>-resdir mygame</TT>
<BR><TT>-mapfile level1</TT>
<P><TT>-console_x 16</TT>
<BR><TT>-console_y 320</TT>
<BR><TT>-console_w 75</TT>
<BR><TT>-console_h 17</TT>
<P><TT>-destroy_hp 150</TT>
<H3>
6.1 Crucial lines</H3>
The first three lines are most important.
<BR>These tell the IRE game runner where to load the data from, what directory
it is kept in, and what the world file is.
<P>'-file mygame.rar'
<BR>This is the name of the .RAR file where all the resources are kept.
<P>'-resdir mygame'
<BR>This is the name of the directory inside the RAR file, where all the
resources can be found.
<BR>I used RES for my general experiments, and FLAT for The Flat.
<P>'-mapfile level1'
<BR>This is the world file which the game will try to load. It will
look for level1.MAP, level1.MZ1 and level1.MZ2.
<BR>
<H3>
6.2 The text console</H3>
These lines control the position and size of the text console.
<P>'-console_x' specifies the X position of the console.
<BR>'-console_y' specifies the Y position of the console.
<P>'-console_w' specifies the width of the console in CHARACTERS.
Not in pixels.
<BR>'-console_h' specifies the height of the console in LINES. Not
in pixels.
<BR>
<H3>
6.3 Loading Screen</H3>
You can also have a loading screen for your game.
<BR>This is controlled by using the -LOG command.
<P>There are three types of LOG:
<P>'-log full'
<BR>This is the default. It runs in text mode, and displays full
diagnostic information.
<P>'-log partial PICTURE.PCX'
<BR>This will switch to graphics mode early on, and display the .PCX picture,
with full diagnostic information superimposed.
<P>'-log none PICTURE.PCX'
<BR>This will switch to graphics mode, and display the picture, but it
will not show any diagnostic information as the game loads.
<P>If you use '-log partial', you will want to specify where the information
appears and how much there is.
<BR>This is done using '-logxy'
<P>'-logxy Xposition Yposition Lines'
<BR>This consists of three numbers on the same line.
<BR>First, the X-coordinate where the text will appear.
<BR>Secondly, the Y coordinate where the text will appear.
<BR>Finally, the number of lines of text that will be displayed.
<BR>It is assumed that the width will always be around 60 columns.
<P>For example:
<P>-log partial mypic.pcx
<BR>-logxy 0 380 10
<P>Will display the picture mypic.pcx, and display 10 lines of text starting
at 0,380
<BR>
<H3>
6.4 Game parameters</H3>
<P><BR>'-destroy_hp'
<P>This sets the health level which the object is destroyed at.
<BR>When any object's health is discovered to have fallen below this value,
it will be obliterated.
<P>The default is -150 health points.
<P>
<HR WIDTH="100%">
<BR>
<BR>
<BR>
<CENTER>
<H2>
Part 7 - Conclusion</H2></CENTER>
Thanks for reading this and showing your interest in IRE. If you
like IRE, spread the word.
<BR>Have fun editing!.
<P><B>Online References:</B>
<P>About IRE:
<P> <A HREF="http://fly.to/ire">http://fly.to/ire</A>
<P>IT-HE Homepage:
<P> <A HREF="http://members.tripod.com/~JPMorris">http://members.tripod.com/~JPMorris</A>
<P>PICTVIEW, which can convert to and from .CEL files:
<P><A HREF="http://pascal.fjfi.cvut.cz/~patera">http://pascal.fjfi.cvut.cz/~patera</A>
<BR>
<P><B>Contact Info:</B>
<P>If you have any questions at all about IRE or VRM programming, feel
free to email me...
<P><A HREF="mailto:DOUG-15@bigfoot.com">DOUG-15@bigfoot.com</A>
<BR> <A HREF="mailto:b52g@usa.net">b52g@usa.net</A>
<P>If you didn't get an answer for a few days, try this instead....
<P> <A HREF="mailto:boff@globalnet.co.uk">boff@globalnet.co.uk</A>
<P>
<HR WIDTH="100%">
<BR>
<BR>
<BR>
<BR>
<CENTER>
<P>End of Document</CENTER>
<BR>
<P><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>