The Gemstone of Balance and Other Stories (GGame Engine)

by Gary Arndt
(Refer to the "Credit" section, below, for information regarding other sources such as Ultima II)

A game inspired by, and in the spirit of, early CRPG games such as the Ultima series (by Richard Garriot)


********************************************************************************
Introduction
********************************************************************************

You are alone in the wilderness.  You have nothing with you except a small amount of food.  But you have just discovered a treasure chest ahead.  Unfortunately, so has a group of goblins.  The question is what you should do.  Though you are not unskilled, you are completely unarmed.  If you fight, you may well lose.  If you run away, they may chase you.  But there must be some way to survive.

So begins scenario 2, "The Gemstone of Balance"

OR ...

You are the last survivor of your village, which was overrun by the hordes of monsters coming from the swamps nearby ...

So begins scenario 1

OR ...

You find yourself in a familiar tale of an evil enchantress ...

So begins scenario 3

OR ...

Another story begins, one you wrote


This game is not one story, but multiple stories.  It will run in a wide variety of possible ways depending on the scenario in question.  It is both a collection of pre-made stories and the basis for playing stories you or others have created separately.

It is very important to point out immediately that because this game is designed in the style of early computer role-playing games, you must read at least some of this manual.  The next section clarifies how much, but it only amounts to the first few pages.

Further, if you are looking for a "quick reference card", the answer is that it is actually available using any of several different methods:

1: There is help info build into the game that is accessed with the F1 key (the traditional Windows help key)
2: The "Summary" section of this manual
3: "Output help to text file" in the game options menu will write the F1 text to a file

Any one of these should provide everything you need to know without the need for a physical copy.  However, if you would prefer a physical copy, then print the "Summary" section, or a file you write via the options menu, or you could even print screen shots of the in-game help screen.


********************************************************************************
Documentation
********************************************************************************

Because this game is intentionally designed in the style of early computer role-playing games, the documentation is important in order to understand how to play it (although players familiar with Ultima will probably recognized some of the more basic features).  This is not a limitation of the style of such games, but rather one of the benefits because it allows for a variety of interesting options rather than oversimplifying them.  Further, the documentation from such games was often part of the experience and even enjoyment of the game.  I remember reading a variety of such manuals and getting more and more interested and inspired as I did so with regards to the various gameplay features, the story, the setting, and the style.

While I don't have any fancy artwork for this manual, and sadly can't send you all printed manuals, a cloth map, and a metal ankh :), hopefully this manual is not only informative, but also at least somewhat interesting.

That said, due to the nature of this game, this manual has ended up being more about how to play the game and related details than simply a compilation of fun things like a history, a list of monsters, etc. so I'd suggest reading only the earlier and more essential sections to begin with and waiting on the more lengthy and complex details after having played the game at least a little so that they are more meaningful and interesting.

This manual is arranged in several categories that somewhat follow a progression of detail.  The most essential sections include "Summary", "Scenarios", and "Basic game details".  More information that should be extremely useful is available in "Further details" and "Definitions" (and also refer to "Definitions" any time a term used in this documentation is unclear).  "Configuration details" is useful if you want to change anything such as the font.  "Custom scenarios" and "Data files" are intended mainly for anyone who wants to design scenarios for this game, and are not necessary to play the game, although they may provide some additional insights.  The last several sections are entirely optional and cover peripheral topics (such as "Credit").

You have probably already seen the separate install documentation since that would usually be required before this manual has become accessible, but if not, be aware that it exists and, as the name implies, explains how to install this game.

Although documented in more detail later, it should at least be mentioned right now that the game contains a built-in help summary.  If you are looking for a "cheat sheet" or "quick reference card", this is it (or refer to the parallel info in the "Summary" section).  Use the F1 key to access this.

If you want, you can write the F1 info to a file using "Output help to text file" in the game options menu (the menu available via the F2 key once you are in the game).

In some of the scenarios, I have included some in-game documentation, such as some books in scenario 2 that describe the various creatures and weaponry used in that scenario.  This information is not so necessary to play the game that it had to be included in this manual, but it is very useful to find, just as with other such information discovered throughout the course of gameplay.


Printing documentation

It is not actually necessary to print out a physical copy of this manual or any other documentation.  Even when the game is configured to run as full screen (which is the default), it still runs in a manner which allows switching to other programs in the usual manner (for example, the Windows "Alt+Tab" hotkey).  Unlike a lot of games, doing so is fast and does not cause problems in the game program.  In other words, you can toggle between the game and the manual or other document very quickly and easily.

That said, if you feel the need for a physical reference card, you can generate it using one of the following methods, whichever you find easier:

1: Print the the "Summary" section of this manual.  The easiest way to do this is to copy/paste the section into a new document then print that (otherwise, you have to deal with exact positioning while selecting printing options in order to avoid printing the entire manual).

2: Use the "Output help to text file" in the game options menu and print the resulting file.  For example, you could specify a name such as "refcard.txt" or "printme.txt" (which would then be created in the root game directory), open it in the program of your choice, and print it.

3: Print screen shots of the in-game help screen (F1)


Summary of sections

Summary: Lightly touches on the overall interface, duplicates and expands on the content of the in-game help info (F1), an essential section to read (although you can just take a quick look through the commands to get an idea of what is available)

Scenarios: Provides some basic information about the subject then details the specifics of each included scenario.  This is an essential section to read, although there is no need to read the details of scenarios other than the one you plan to play.

Basic game details: Gives an overview of how to play the game, an essential section to read

Further details: Gives detailed information about a variety of gameplay subjects.  While this information should be extremely useful, it is NOT essential to read this section before playing the game.  That said, it would be a good idea to at least take a quick look at the "Summary of topics" at the beginning of the section in order to understand what is there.

Configuration details: Gives more details regarding configuration (such as changing the font).  While this information should be extremely useful, it is most definitely NOT essential to read this section before playing the game.  That said, it would be a good idea to at least take a quick look at it in order to understand what is there.

Definitions: Provides a list of terms.  Refer to this section anytime a term is unclear.  While extremely useful, it is NOT essential to read this section before playing the game.  That said, it would be a good idea to at least take a quick look through it in order to understand what is there.  Note that some details about how the game functions is also clarified in some cases.

Keymap: Describes how to use the keymap feature.  This feature is entirely optional, so this is not an essential section to read unless you want to use the feature.

Text style and conventions: Details about these in the documentation, in the game itself, and in scenario construction tools.  It is by no means an essential section.  If you are curious about things like why I use brackets the way I do, read this section.

Custom scenarios: This is for anyone interested in designing their own scenarios.  It is by no means an essential section if you are just playing the game.

Data files: These are important details related to designing custom scenarios.  It is by no means an essential section if you are just playing the game.

Data contributions: This is to proactively address the subject just in case.  It is by no means an essential section.

Potential future work: In case of curiosity, just a few notes about the subject

About this game: In case of curiosity, discusses a little bit about the game design itself in a general sense, not how to play or anything essential

About the author: In case of curiosity, tells you a little bit about me

License-related issues: Subjects related to use of this game other than just playing it, not an essential section if all you are doing is playing the game

Credit: I wrote nearly everything from scratch, but there are a few exceptions that should be noted, not an essential section if you are just playing the game

Disclaimer: This is intended to proactively address any potential misunderstandings with regards to the scenario content


A note regarding the public release

Much of this manual was written years ago, although it has been significantly updated since then and should be correct.  I have recently decided to create a public release, but some of the peripheral information in this document may not apply (such as the section that discusses graphical contributions).


********************************************************************************
Summary
********************************************************************************

Starting the game

Run one of the "GameS[NUMBER]*.bat" files to start the game for the given scenario number, then select an option from the startup menu.  Options there allow you to start the game quickly with a pre-generated character or create a new character.  After saving the game the first time, you can also continue from the last general save point, or load from a particular named saved game.


Commands

The game uses a set of commands very similar to the early Ultima games but with significant modifications, enhancements, and additions.

Up arrow: Move north (overhead) or move forwards (first person)
Down arrow: Move south (overhead) or move backwards (first person)
Left arrow: Move west (overhead) or turn left (first person)
Right arrow: Move east (overhead) or turn right (first person)

A: Attack
B: Board vehicle (ship, horse, etc.)
C: Cast spell (may require spell item)
D: Descend rope, ladder, stairs, etc.
E: Enter location (town, dungeon, etc.)
F: Fire vehicle's weapons (note that some don't have weapons)
G: Get item (treasure chest, weapon, etc.)
H: Hyperspace (while in space ship after launching)
I: Ignite a light source such as a torch (requires said item)
J: Jump
K: "Klimb" (climb) a rope, ladder, stairs, etc.
L: Launch/land a vehicle (aircraft, etc.)
M: Magic, set current spell
N: Negate time (requires magic item)
O: Offer gold
P: Pass turn
Q: Quit and/or save game
R: Ready weapon, shield, or ammo
S: Steal
T: Talk
U: Unlock (requires key)
V: View (requires magic item)
W: Wear armor
X: Exit vehicle
Y: Yell
Z: Display PC stats

Spacebar: Pass turn

Control-D: Drop
Control-I: Display PC inventory list
Control-L: Look
Control-Q: Quit (no save)
Control-R: Rest
Control-U: Use
Control-Z: Display detailed PC stats list

Enter: Show object state (current selection)
Control-Enter: Show object state (select)

F1: Quick help (full text screen)
F2: Options menu (save named game, quit to main menu, and more)
F3: Save named game
F4: Load named game
F8: Toggle screen locking
F9: Toggle full text screen

Control-F1: Quick help (no full text screen)
Control-F8: Screen locking options

Control-Up/Down arrow: Move text display up or down by 1 line
Page Up/Down: Move text display up or down by 1 page

Note that additions or even changes to the above are possible by using a keymap file.  Refer to the "Keymap" section for more details.


********************************************************************************
Scenarios
********************************************************************************

Like many newer games, this game is divided into two distinct components: the engine and the scenarios.

From a player perspective (most people reading this), a scenario is a whole, distinct game.  From a designer perspective, a scenario is a set of data files that define a given way in which the game will run.

The engine is the game program, the component that allow scenarios to run.  This engine allows multiple scenarios, meaning, from a player perspective, there may be more than one game available to play using this same program (these can be selected using different startup methods or within the main menu).

Further, any user that desires to do so may also design new scenarios.  This scenario designer may alter or create data files to create a new scenario and does not need to alter the engine or necessarily understand anything about computer programming (see the section on custom scenarios for more details).


Scenario 2: The Gemstone of Balance

This is another original scenario, this one much longer than scenario 1 (detailed below).  It was created in a style more like the later Ultima and similar CRPG games and uses a number of more advanced game features.  All of the data, including the tileset, was created from scratch (except the crashing sound, which was modified from a public domain sound).

This scenario should be playable from beginning to end.  Even so, I want to add more details to it in the future; I consider this to be a work in progress that I'd like to continue to expand further.

Your character background is up to you: perhaps you were the last survivor of a village overrun by monsters or bandits, perhaps you have just washed up on shore having survived a shipwreck, etc..  In any case, you start with very few supplies, but you have come across a nearby treasure that may make up for it.  However, so has a group of goblins.  Your first decision is whether or not to enter into conflict with them over the treasure.

Please note that survival at the beginning of the game can be difficult.  It is very important to be aware that you can retreat from any group combat, although retreat is not assured, especially if they get close or there are a lot of them.  Most types of enemies will retreat if they are losing badly enough, although some types of creatures such as the undead are fearless.  An individual creature will retreat if it is wounded enough, and killing or driving off some of them in group combat is enough to make the rest of the group retreat.  However, higher level characters will probably want the additional rewards for killing the entire group.  Also keep in mind that combat is not the only way to earn experience and gold.  Since this is not a linear game, all areas are accessible from the beginning of the game (although some are more difficult to reach than others).  However, some areas are very difficult and may be well beyond the capabilities of a beginning character.  It is not unreasonable to leave such an area and come back later.  Completing all of the quests and areas is not required, and many are entirely optional, but each will make the final quest of the game easier.

In the tradition of the Ultima series, some quests are (essentially or literally) required but you may still opt to reach to nearly the end of the game without doing these.  This could potentially be frusterating for players who are used to linear games.  However, if you explore the game well, the need to do these quests will become apparent before such a time.  Or, if you encounter a nearly impossible situation near the end of the game, you may want to go back and explore more carefully (a hint: There may be a good reason the enemy leader in the game is so powerful...).

Your ultimate goal will be discovered through the course of the game, but this scenario assumes that you are playing a hero, and your goal will therefore correspond.

There is a lot to explore in this scenario, including many overland regions, many towns, many dungeons, a variety of special areas, etc..  While exploring is often dangerous, there are many rewards for doing so.  There are a very large number of interesting and useful monetary treasures, weapons, armor, shields, special items, spells, vehicles, and other rewards in this scenario.  Note that some areas and towns are different sizes.  For example, the town of Seaport has multiple levels and continues on separate maps to both the north and south.  Less interesting towns result in nothing more than some text with a few limited options (largely because if I implemented each of those towns fully, I'd probably be 100 years old before I was done with this scenario!).  A lot of towns are a more traditional size of one map with one level.  Be aware that talking to NPC's often reveals very helpful or even required information about the scenario.

As with scenario 1, you may create a character from scratch or use the pre-made character, Zaranth.  There is only one race (human) currently available, but I hope to add more in the future.  Similarly, I am not done implementing the rogue class (although it can be selected, it has very few special abilities so is weaker than the other classes).  Classes that are implemented include the fighter, cleric, and wizard.

There are 90 character points available to distribute to the attributes, the minimum value that can be assigned to each is 10, and the maximum value is 30.  Note that although the game often uses an approach similar to other RPG's and CRPG's, the values for these attributes do NOT follow the same common values where 10 is average, 18 very high, 3 very low, etc., but rather fall between the values 10 and 30 (10 being considered average for a commoner and 15 average for someone more capable like the PC).  This is for implementation and balance reasons related to the current internal calculations being based on 1-100 rather than 1-20.


Scenario 1: Unnamed, incomplete demo

This is a short scenario, using the Ultima II tileset and some similar genre concepts.

That said, it is an original design that is very different from, and much shorter than, Ultima II.  Note that this is only one of many possible scenarios, and was designed to put a first playable game in place.  The game engine itself is capable of much more than this, but a simple scenario was a good place to start.

In this scenario, you are the last survivor of your village, which was overrun by the hordes of monsters coming from the swamps nearby.  You start with no weapons or armor, just a bit of skill and luck.  All the other nearby villages have also been destroyed, but you hold out hope that the great city to the northwest across the river has not yet have been overrun.

Your ultimate goal is to defeat the hordes that are coming from the great swamp.  They seem organized, focused, and with purpose; they likely have a leader.  You may do this for your own survival, for revenge, to save everyone in the land, or for some other purpose; this depends entirely on your character concept.  You first goal is, however, simple survival; you must make it to the city alive.  Once there, you can begin to build up your weapons and supplies, fighting back the hordes, until you are skilled enough to enter the great swamp and begin to determine how to destroy the leader of this horde.

I tried to make it somewhat challenging to start the game, in the spirit of early CRPGs.  It may take a few tries to survive, although I did make the enemies slightly less powerful after I playtested it.  Food and hit points are important to initial survival.  It should not be possible to buy really good weapons and armor until you have purchased less powerful ones to make it possible to survive and earn treasure faster.  However, do not hesitate too long to begin exploring and looking for greater treasures, as it is much more interesting and rewarding to do so than just killing monsters outside the city over and over to slowly earn tiny amounts of gold and experience.

The default character for this scenario is named "Zaranth" (after my first Ultima character), a human male fighter.  As in Ultima II, there are 90 character points available to distribute to the attributes and the minimum value that can be assigned to each is 10.  This scenario was created and tested for a human fighter, so even using character creation the only selection available in this version of the scenario is a human fighter.

Note that although this scenario is fairly playable overall, it is currently not yet complete enough to be labelled as more than an incomplete demo.  The main issue is that the data's game-related values such as weapon damage, creature values, etc. are currently set to placeholders values rather than being properly balanced.  Further, the scenario has not been well-tested in quite a long time and many changes have been made to the engine since the last time I did so.

An optional enhanced graphics design for the interior of dungeons and towers is available as a special option.  To activate it, run the "Config-S1.bat" file.  That same technique can be used to switch back again.  It is not used by default because the standard version for this scenario is already slightly improved from the more authentic version used in the Ultima II scenario.  Also, the creature graphics it includes does not match their overhead versions and are a bit too advanced for the style of the scenario.  However, it looks really good and may be a nice change of pace if you get tired of looking at the old graphics after a while :)


Scenario 3: Incomplete Ultima II demo

(Please see the "credit" information, below, for Ultima information.)

This is the Ultima II scenario.  It is not yet complete, but what is complete should be very close to the original game.

I need to be very clear that the purpose of this scenario is NOT to take the place of the original game, but to demonstrate the capabilities of this engine and share my enthusiasm for the Ultima series.  If you enjoy this demonstration version, I would highly recommend getting a copy of the Apple IIe version of this game (along with a Apple emulator such as AppleWin), as the game was originally written for that machine and the original PC port version was inferior to the Apple version when I played it (I suspect that someone has probably made a fan patch by now to improve the PC version, but it still seems like playing the Apple version would provide the most authentic experience).

That said, purchasing a copy of that PC version would give the user a valid license, which is required to play it.  Please make certain that you own a copy of the game before doing so.

This scenario is playable, but not complete and does not yet exactly mirror the original version.  That said, I have fixed various problems that existed in the original game (such as the horse now providing a food rate benefit rather than a penalty, when exiting a port town with a ship the border now actually shows water rather than land, the sea serpent's water is now animated, etc.), made a few minor changes for consistency with the later games in the series, and the interface enhancements should make the play experience more fluid (enhanced save game features, enhanced text area interface, etc.).  Unfortunately, currently missing are properly balanced game-related values such as appropriate weapon damage and creature values (the data currently defines values that are just placeholders), the exact calculations of combat (the engine currently uses something more akin to traditional tabletop games such as d20), the special mechanisms of the final battle, an animated version of the starfield in space, and a few other details here and there (although I do hope to resolve these in the future).


A note regardling historical accuracy

Not everything in my own scenarios necessarily reflects reality (this is primarily a fantasy game, after all :) ).  While I respect historical accuracy, my definition for a particular vehicle, weapon, etc. sometimes intentionally diverges.  I believe that the term for this approach is "artistic license".


********************************************************************************
Basic game details
********************************************************************************

Entering text

The game will often prompt you for information.  In some cases, this means entering a single keystroke.  In other cases, this means entering some text.

Keep the following points in mind when entering text:
- The terms "return key" and "enter key" are interchangeable
- Complete the entry by pressing the return key
- You can often abort by pressing the return key with no text
- The backspace key can be used to go back and change what you have typed
- The escape key can typically be used to erase the line of text
- In some cases, there is a limit to how many characters can be typed


Character creation

You may use the default character or create a character from scratch.

The default character is defined by the particular scenario, but the attribute points are always distributed evenly.

If you create a character from scratch, you may choose the interface to use.  All of the interfaces allow you to choose the name, class, race, gender, and how to distribute attribute points.

The available interfaces include the enhanced interface, the traditional interface, and the prompt interface.  Note that build-in quick instructions are also available that include the attribute point limits for the scenario in question, a summary of the available commands, and some brief notes regarding the behavior of the interface in question.

The enhanced interface has an appearance very similar to the traditional interface but is far more user-friendly.

The traditional interface is intended to somewhat authentically support the Ultima II scenario and therefore has a design that is intentionally somewhat limited (although a few non-obtrusive enhancements were included such as being able to type longer numbers, support for various screen sizes, scrolling when there is too much information to display at once, and being able to exit the screen).

If you wish to exit the screen and go back to the main menu in the enhanced interface, press the ESCAPE key.

In the traditional interface, enter no value for the current field and press the return key (note that the escape key does NOT do this since it will erase the line of text as usual).

When entering attribute values in the enhanced interface, if you enter an invalid value it will attempt to automatically correct the value.  If it cannot do so, it will erase the line so that you can try again.

In the traditional interface, it will always erase what you have done so that you can try again.  This is not a bug, but rather an intentional part of the design.

Each scenario may have a different requirement for the values that can be used.  Refer to the scenario details or the built-in quick instructions for the specifics.  For example, scenario 2 has a minimum attribute value of 10 and a maximum of 30.

The prompt interface was the original character creation prototype and is included in case anyone happens to prefer it.  It appears in the text display area rather than as full screen and interactively asks questions.  It may well be the most intuitive interface because everything is explained interactively, but as a result it is also more cumbersome.


Character creation - Enhanced interface summary

Commands:

Backspace: Delete previous character
Escape: Cancel and exit the screen
Return: Go to the next entry
Up/Down arrow: Navigate between entries
Control-Up/Down arrow: Scroll screen by line
Page Up/Down: Scroll screen by page

Notes:
- All values must be complete to verify
- Empty values are valid for navigation purposes
- No text, space, and 0 are some empty values
- The line will reset for an invalid value
- Some text is automatically corrected
- Points update only when changing entries


Character creation - Traditional interface summary

Commands:

Backspace: Delete previous character
Escape: Erase line
Return: Complete entry or if no entry then cancel
Control-Up/Down arrow: Scroll screen by line
Page Up/Down: Scroll screen by page

Notes:
- Any attribute mistakes will restart all
- Any mistakes elsewhere will restart the line


Playing the game

This game runs in the style of early CRPG games such as the early Ultima games.  No mouse is used.  Use the keyboard commands listed above to interact with the game.  For example, move around using the arrow keys, attack enemies using "A", enter locations using "E", view character information using "Z", etc..  That said, there are many enhancements to the basic style.

If you forget a command, F1 (the traditional help key) is a quick in-game reference.  Note that you can use the Page Up/Down keys and Control-Up/Down arrow keys to scroll back through any text that has already gone by.

Do not expect everything to work exactly as it does in the traditional manner.  A huge number of enhancements to the basic interface approach have been made (although the most basic, default behaviors are usually very close to the similar interfaces).  Some commands will offer additional prompts, allow entry of numbers greater than a single digit (and therefore require a return key), etc..  Special verbosity options allow different types of text messages (authentic, more detailed, etc.), etc..  It is possible to scroll up and down through text and to switch back and forth to a full screen text mode.

Some scenarios (such as scenario 2) make use of a huge number of enhanced or advanced gameplay features, just a few examples being a variety of additional commands such as "Use" and "Look" (among others), new ways of using basic commands such as using "Ready" for a shield or ammo, the character stats screen showing additional details, encumbrance, ship hull points that take the place of character hit points when you board the vehicle, creatures being able to attack vehicles directly in combat maps, vehicle cargo, vehicle repairs, vehicle upgrades, boarding or exiting vehicles with other vehicles, renaming vehicles, interactive containers, zoom-in combat (similar to a later style), retreat checks, retreat tracking, dungeon rooms (similar to a later style), enhanced dungeon graphics, resting, complex item interaction, dropping items, a complex magic system, PC morale, point modifiers, complex/interactive conversations (similar to a later style), a wide variety of unique situations built with the extensive scripting mechanism, and many others.

Note that a feature of the similar interfaces was intentionally not implemented: There is no automatic pass (timeout on entering a command), because (with respect to the games that used them), timeouts are not appropriate for turn-based games and take away from the gameplay experience.  That said, this does not apply to the very few action-based sequences (such as flying an air vehicle or landing a spaceship in some scenarios), which do benefit from timed input.

Some commands require a direction.  Use the arrow keys to indicate the direction or the spacebar to indicate "HERE" (current position).


Saving and loading the game

Saves and loads may be done traditionally using a single, current save game (via "Q"), or any number of named games may also be used (via the other save options).  Be warned that, just as with the traditional approach, the single "current" save frequently updates as the game is played (such as when switching to a different map when it is possible to save on that map).  However, named save games are never automatically updated.


Text screen

The text that is usually displayed at the bottom of the screen is buffered so that you can scroll up and down to review something that has already gone by.  Also, the full screen F9 feature is a good tool when any text is long and difficult to read such as the Control-I or Control-Z lists, long conversation text, etc..  Note that the F1 quick help does this automatically (although you can use Control-F1 if you do not want it to do so).

An automatic pause system is available, which is activated by default in some scenarios.  This will pause so that most text does not scroll by until the user presses a key.  It can be toggled on/off using the options menu.  When it is displayed, press any key to continue, or "Q" (quit) to temporarily turn it off for the duration of the current series of messages.


A few tips

While all of the information necessary to play is documented elsewhere throughout this manual, here are a few tips:

- Although it has been mentioned several times elsewhere, it is worth reiterating that the F1 help key can be very useful (along with the Page Up/Down keys and Control-Up/Down arrow keys).

- In the character creation screen, don't forget that entering any invalid values will cause it to attempt to auto-correct in the enhanced interface or simply always reset in the traditional interface.  If you are finding this screen difficult, remember that every scenario may have different requirements.  If you are using the traditional interface, you may also want to consider trying the enhanced interface.  For more details, refer to the "Character creation" topic above and/or the "Scenarios" section above.

- You won't survive long in most scenarios without food.  One of the first things you should do is find a settlement where you can buy food.  Food in more complex scenarios such as scenario 2 may be available for different prices and even offer different benefits (for example, the food from a pub may well cost a lot more than standard rations but provide a bonus to PC morale).

- In the tradition of early-style CRPG's, you are not powerful at the very beginning of these scenarios and must think carefully to survive.  You do not start out being able to win every fight and should not simply attack every enemy you see.  While exploring is an essential part of the game, you should probably not stray too far from settlements early on.  And if you enter a particularly dangerous place like a dungeon early on, you are likely to be killed.

- Many dungeons are entered through an opening that immediately leads to a ladder.  Therefore, if you enter a dungeon, find yourself in the dark, and wish to leave, you will need to climb up the ladder to do so (the 'K' command).

- All of the included scenarios are non-linear games of exploration.  Exploring is dangerous, but essential and offers many rewards for successfully doing so.  If something is too difficult, you may have to come back when you are more powerful.  You have to discover where you need to go and what you need to do; you are not told like in a linear game.

- Do not be surprised if you encounter something too difficult for you and are killed; games of this type can be difficult, particularly given the random element to many situations (such as how many creatures you encounter, if you hit or miss, etc.).  Be sure and save the game frequently so that you can simply reload if this happens.  That said, if you are being killed a lot then you may want to reconsider your tactics.  In particular, there are a number of possible tactics in scenarios such as scenario 2 that can actually make the game almost too easy at times.

- The Talk command works only in the 4 cardinal compass directions (N, E, S, W) and must be to an adjacent NPC.  However, an exception to the later is that it will go past certain objects on the screen like over a table or through a window.  For example, that means that if a merchant you want to talk to is standing on the other side of a table, you can talk to the merchant by using the command towards the adjacent table in the direction of the NPC.  In other words, you can talk over that table.

- It is very helpful to talk to as many NPC's as you can since there are usually a very large number of them with a lot of important information or additional interactions (sometimes outright required to solve the scenario).  Merchants can do things like buy and/or sell items or vehicles, or, in more complex scenarios such as scenario 2, offer services such as ship repair or teaching spells.  Scenario 2 includes NPC's with a great deal of information that will help to play the game such as combat tactics, information vital to survival, information about the world, information that helps with various quests, and a great deal more.  Some NPC's offer direct assistance such as a cleric that can provide healing and such.

Here are a few more tips that only apply to scenarios that use more complex features (such as scenario 2):

- As mentioned earlier, you are not powerful at the very beginning of the game.  Strategy both inside and outside of combat is very important.  If you are going through healing potions like water, then you probably need to reconsider your combat tactics.  You should not simply attack every enemy you see.  When possible, you should choose where you want to fight.  Don't forget about any special items you may have or are able to get.  Don't forget about any special benefits you may be able to get in settlements.  If a combat is too difficult, you may have to retreat.  Retreat can fail, but is far more likely if you think strategically about it; if you start a combat and see that you are clearly overmatched, then you are far more likely to get away sooner than waiting until the danger increases.  If you are careful, you can use retreating to your advantage.  Scenario 2 starts out with an encounter, but your character has minimal skills and no weapons or armor so you cannot assume that you will necessarily win if you simply charge into combat; you are much better off thinking strategically about your options.  Scenarios such as scenario 2 often have healing and many other important benefits available in settlements that can vastly improve your chances of success both inside and outside of combat.  And some NPC's can help you with strategy.  While exploring is an essential part of the game, you probably should not stray too far from settlements until you are more powerful.  And as mentioned earlier, you should not enter a dangerous place such as a dungeon yet.

- The Use command is often essential.  While documented in more detail elsewhere, the basic idea is that it can be used for several different purposes when no other command is appropriate.  For example, to use a torch you would normally use "I" for the Ignite command.  But there is no specific command to use a potion, so you would use "Control-U" for the Use command followed by "I" for Inventory, then select the potion from the list of usable items that is displayed.

- Some NPC's use the complex conversation system.  A lot of these conversations support the traditional keywords "name", "job", and "bye".  The term "look" is also often supported.  Pressing return without any keyword will always exit any complex conversation (or any other keyword-based interaction).  Although traditional, it is still worth clarifying that other potential keywords may become apparent in the course of the conversation.  For example, if a fisherman tells you about his boat, you may want to try the keyword "boat".

- Some scenarios provide information in the form of text that automatically appears when you step onto particular positions.  This can serve a number of purposes (and can often be things other than text), but one important purpose can be to indicate if there is a sign outside a building door that tells you if it is a type of shop where you can buy food, weapons, or armor.

- The Rest command can be very helpful.  Resting is used in some games to restore HP, and while that is also possible in this game for custom scenarios, none of the included scenarios that allow resting provide more than a very small HP benefit for doing so.  Instead, the primary benefits are providing PC morale and restoring spell points.  HP should be restored using other methods.  The benefits of resting to provide PC morale should not be underestimated and restoring SP is vital for spellcasters.  That said, consider paying for an inn room if you want to avoid the risk of an ambush.

- Settlements in scenarios such as scenario 2 can be very different from each other in very important ways.  For example, in scenario 2 there is a small town near where the PC starts that provides some basic services, some prices that are cheaper and some that are more expensive, and generally sells only more basic items, whereas there is a huge city farther away that consists of many maps (including multiple levels), has NPC's that sell more rare items, provides a variety of more advanced services, and has some prices that are more expensive but also a few that are cheaper.  There is typically a very different atmosphere between the various settlements, and there are often many unique NPC's that have unique information and such (the exception being a few generic settlements in distant lands, although even those sometimes have differences).


Screen resolution and layout

To be clear, changing anything about the screen resolution and layout is entirely optional (unless there is some unusual problem you are trying to resolve).

The game will attempt to automatically adjust to different resolutions.  Most design work was done using 32-bit color at 1024x768dpi, but the game can be played on other resolutions.  Some testing was done on these, particularly 800x600dpi.  In some cases, it may be helpful to refine the layout by making adjustments to the screen settings in the configuration file (DATA[ID]\main.cfg or game.cfg).  Changes can be made to the window mode (window vs. full screen), font, font size, number of tiles, text areas sizes and positions, and almost every other aspect of the layout.  Many preset settings and values are already in the files; uncomment these to enabled them, or enter new settings from scratch using these as examples.

The "Configuration details" section provides more information on some of these subjects.


********************************************************************************
Further details
********************************************************************************

Summary of topics

The following topics are included in this section:

- Movement and maps
- Passing a turn
- Food, water, rest, and health
- Darkness and visibility
- Combat
- Adverse conditions
- Inventory
- Items
- Vehicles
- Character information
- Ability scores
- Levels
- Conversation
- Magic
- Crimes
- Checks and rolls
- PC morale
- Point modifiers
- Look and show object state
- Ending the game
- Options menu
- Screen locking
- Changing the font


Movement and maps

Movement is achieved one step at a time with the arrow keys (although in some cases you may want to hold down a key to move continually).  Some scenarios use a first person perspective in some areas, but the standard display is overhead.

Each area is called a map.  Maps are considered to have variable degrees of scale.  In other words, a square of one map may designate a larger area than another.  For example, one map may show the entire world, another a continent, and another a town even though they may be the same size in number of squares.  Note that scale usually determines the rate at which food is consumed as well as various other rates.

There are several methods to change from one map to another.

It is often possible to cross the edge of a map, which is called a border.  If it is not possible to cross a given border, a message will be displayed explaining this.  If it is possible, a verification prompt is often displayed.

There are often locations within a given map.  The "enter" command is usually used to go into these locations.  In some cases, stepping on a location is enough to enter it.  For example, on a large scale map there may be a village, town, castle, dungeon, tower, etc. that you enter by stepping onto it, then pressing the "enter" command.  In another case, there may be a portal that you enter automatically after you step into it.  Note that some locations are hidden (for example, indicated only by a message when you step onto them), so the command may work in unexpected places.

Maps are sometimes logically arranged by height or depth, meaning you can move upwards or downwards from one map to another.  Ropes, ladders, stairs, and any variety of other means often allow access to other maps by using the "(k)limb" and "descend" commands.  Some others may be used automatically as soon as you step onto them.

Some maps in some scenarios use group combat (such as the overland maps in scenario 2).  An attack with such a group causes a "zoom-in" combat map to be entered, where the combat takes place against the individual enemies in the group.  When the combat ends, you automatically exit the map back to the original map.

Special means may sometimes be used to change maps.  For example, an item or conversation may cause you to teleport or automatically travel to another map.

Some locations allow access only on foot, while others allow entry with vehicles such as ships.  If a location does not allow entry by another means for the vehicle in question (such as a harbor for a ship), it will either not be possible to move the vehicle onto it or will display a message when you try to enter it indicating that is the case.  For example, a town on the seacoast may or may not have a port, so it may or may not be possible to enter with a ship.  A dungeon will probably not allow entry while on horseback.  Etc..

Everything on a map can be interacted with in some way.  Stepping on a given position is sometimes enough to trigger some behavior, but many other commands may also be used.  See the list of commands and the additional details in this section for more information.

A few more details:

You (and other NPC's) can only move onto particular terrain.  Using a vehicle (such as a ship) may change these options.  Different types of creatures and vehicles often have different capabilities with regards to being able to move onto a given type of terrain.  For example, a ship and a sea serpent can only move in water.

Terrain can be used to conceal secret passages, etc..  For example, what looks like a wall may, in fact, be unblocked terrain that indicates a secret door.  Or seemingly impassable mountains may contain a pass.  In many cases, you may have to try moving onto the position to know for certain.  That said, you usually won't want to walk around bumping into every wall or mountain :), but if you have a reason to suspect there may be something there, then this may be a good idea.  For example, if you map a dungeon carefully and there's a mysterious gap in the map blocked by walls, there may be a secret door somewhere, although it may just be a gap or you have to use a portal to get there or some such.

In some scenarios such as scenario 2, some terrain causes a delay.  The delay often differs depending on the terrain in question.  For example, the delay in forest may well be higher than the delay in brush.  As with differing capabilities for moving onto particular terrain, different vehicles and creatures often have different delays on the given terrain.  For example, a native desert creature will usually move faster than you on desert, but you can improve this by using a camel (and yes, there is desert and camels in scenario 2 :) ).

The "look" command may be used to view information about any square on the map.

The "show object state" command may be used to view the status of multiple objects on the map (such as who you have not talked to yet, creatures that are delayed, and more).

The "use" command may function on some items on the ground.  For example, in scenario 2 you may use this command to drink from some fountains.

There are a few differences on a first person perspective map.  The movement keys indicate movement with respect to forward motion rather than compass direction.  Some commands will not prompt for direction, but instead use the current position or the position directly ahead.  Some commands are not available at all.  In an Ultima-style game, this perspective is most often used only in dungeon-like settings.


Passing a turn

A turn may be passed for a variety of reasons by using the space bar or "P".  Common reasons include waiting for an enemy to advance, an NPC to move out of the way, or the wind to change direction when sailing.


Food, water, rest, and health

Many scenarios require food for survival.  If the food counter reaches 0, the character is either killed or begins to lose HP, depending on the scenario.  You can purchase more food from particular merchants.  Finding where to do so is normally one of the first things you should do when starting a game.  In some scenarios (such as scenario 2) there are other means of gaining food (in scenario 2, some particular NPC's will help you out if you are particularly low on food).

Water is not tracked in the same way for several reasons.  First of all, some of the food supply can be assumed to also track any supplimental water that is needed on a regular basis.  Also, it is assumed that you can scavenge for this in most areas (drink and refill waterskins at streams, etc.).  However, some very arid terrain may require a special supply of extra water, in which case it would show up as a standard item in inventory.

It is assumed that rest and sleep take place as part of normal movement, particularly because the scale on some maps is extremely large.  Day and night is not implemented in this game, but the same reasons would apply as with rest and sleep.

That said, it is possible to explicitly rest in some cases.  This represents a more extended period of rest, above and beyond that which is implied.  The benefits can differ depending on the situation, but the main purpose (at least in the included scenarios) is to improve PC morale or restore spell points, although some HP may also be restored.  In scenario 2, it is possible to rest at outdoor locations, dungeons, inns, and some special locations, but not anywhere in a settlement (other than an inn) or on any other maps that are at a small scale.  The quality of the rest and the chances of being ambushed depend on the situation.  Generally, an inn will provide better rest and a safer environment, while a dungeon will provide poor rest and a high chance of being ambushed.  Some terrain and inns are more comfortable and/or safe than others.  The rest command is used away from settlements, while an inn requires speaking to an innkeeper.

Hit points may be restored using a variety of methods depending on the scenario, but in this game, unlike many others, resting is not a primary way to do so (at least not in the included scenarios).  In many scenarios, talking to a particular NPC will allow healing.  In some, such as scenario 2, you may also use particular magic items.  Other methods may be available that may be discovered in the course of playing a given scenario.


Darkness and visibility

Some areas are dark.  While you may move around in these areas in the dark, typically you will want to ignite a light source such as a torch.

Some scenarios use the visibility system.  This means that an area that is out of sight is shown as dark.  The areas that are out of sight will change as you move around the map.  For example, your character may have to move to the other side of a mountain range or wall to see what is on the other side.


Combat

Attacks are accomplished when you use the "attack" or "fire" command, or when an enemy attacks you.  "Attack" uses your currently readied weapon, while "fire" uses the current vehicle's weapon (if it has one).

The chances of an attack being successful depend upon a number of factors, including the skill of the attacker, the weapon being used by the attacker, the type of defender, any armor being worn by the defender (and/or any shield being used), etc..  Of course, a random factor is also involved so it is normal to have to try attacking more than once.

Some scenarios allow the use of ranged weapons (or other items).  For example, a bow in scenario 2 is considered ranged.  In that case, a targetting cursor is displayed.  Position this cursor over the enemy and press return.  The escape key may be used to abort.

Such scenarios may also require ammo for some weapons, such as arrows for bows.  The ammo must be selected with the Ready command (for a PC).  If the type of ammo does not match the type of weapon, attacks with the weapon will not be possible.  If the ammo runs out, attacks with the weapon will not be possible again until more ammo is available and readied.  The Ready command also allows the selection of different types of ammo that can be used by the same weapon (such as magic or special arrows).  Any special abilities of the ammo takes precedence over any of the weapon unless they are entirely different types of powers, in which case they will both function at the same time.

Note that some scenarios such as scenario 2 also require ammo for some vehicle weapons.  The ammo must be loaded into the vehicle's cargo and then readied in a different manner from that of a PC.  Readying vehicle ammo first requires being aboard the vehicle.  Next, select the Use ("U") command with the Vehicle ("V") option to bring up a submenu.  Finally, select the "Ready ammo" ("R") option from this submenu.

In some scenarios such as scenario 2, some weapons, particularly ranged weapons, may take more than 1 turn to use.  When this is the case, the enemies will automatically receive extra turns.

To ready a different weapon, shield, or ammo, use the "Ready" command.  To wear different armor, use the "Wear" command.

Some scenarios define particular weapons as two-handed (2H).  If such a weapon is readied, any shield will be automatically unreadied.  Conversely, if a shield is readied when a 2H weapon is in use, the weapon will be unreadied.

Further, some scenarios allow the use of combat magic (such as the Ultima II scenario), and some allow the use of special items, such as healing potions, wands, etc. (such as scenario 2).

One of the things the Look command indicates is how wounded an NPC is, which is particularly helpful in combat.  Note that the "show object state" command can also provide such information, although in less detail.

On some maps (particularly those that are large-scale), an enemy actually represents a group of enemies and attacking or being attacked will start a zoom-in combat with the individuals of that group.

In such a combat, the combat ends when all of the enemies on the map are gone, either by being defeated, or by retreating, or when you retreat.  If you retreat, the enemy group may or may not disperse depending on a variety of factors (the way the scenario is set up, how many enemies were defeated, if they are fearless, etc.).  If they do not disperse, then the group composition is tracked and will be consistent the next time you meet them in combat, including any losses they may have taken.  Note that in scenario 2, retreat is almost required for very low level characters, but the enemies may be driven off by first defeating enough of them.

Also, in some scenarios (such as scenario 2), retreat from this type of combat is not certain; a retreat check is required.  This is an abstraction that represents their ability to keep you engaged in combat, or circle around and cut you off, etc..  Like many other checks in the game, this one is based on a difficulty target and a roll that is modified by the character's abilities.  In this case, the difficulty increases based on the number of enemies, how powerful they are, and how close they are.  If any of the enemies are limited by adverse conditions (such as being unable to move), they may contribute to the difficulty at a reduced rate or may not contribute at all, depending on the particular adverse condition.  The difficulty is reduced by any allies on the map to distract them and based on the same factors, only in your favor in this case.  The check is modified by several of the character's ability scores and by level.  Critical success and failure is considered.  If an enemy does not have the ability to follow you (such as when the PC is on land and retreats from a creature that can only move in water), no check is required at all.  If you fail to retreat, you waste that turn and may also lose several additional turns depending on how the scenario is configured.  This represents the time it takes to make an unsuccessful attempt to retreat and the turns the enemy gets while you are doing so.

Beyond providing variety for the game, this system also prevents retreat from being too powerful.  Each time you engage the same enemy in combat they are reset to the standard, opposite positions on the combat map, which is reasonable since they are assumed to have fallen into these positions in the time between when you last encountered them and the next.  However, this would make combat far less dangerous since they would never have a chance to catch up to you unless you let them.  A retreat check presents a logical risk for any attempts to disengage from combat in the first place.  Further, it provides another opportunity for combat tactics and consideration of various character attributes.

Note that the retreat check is one of the many systems that is an enhancement and difference from the original approach (in one case it was not possible to retreat at all, and in another it was considered cowardly).  This is also true of retreat tracking, the system that allows enemy groups the potential to persist after you retreat from them rather than always dispersing.

In some scenarios, such as scenario 2, adverse conditions may be applied to the PC or an enemy by a variety of means, including combat actions.  For example, a given creature, weapon, magic item, or spell may cause sleep, poison, stun, immobilized attacks, immobilized movement, etc..


Adverse conditions

Adverse conditions may be applied due to a number of situations, including an attack by particular creatures or weapons, stepping onto dangerous terrain, a dangerous item, a trap, etc..  Some of these conditions may be resisted by special items, while others may not.  Some can be cured after they are applied, while others may not.  The PC can also use some of these on enemies, such as with special items or spells in scenario 2, but many enemies are either immune or have a level of resistance to some of them.  Similarly, NPC's who have a reason to attack other NPC's can also attempt to use them on each other (such as PC allies in scenario 2).

Immobilized attacks: The affected creature may not attack for a particular number of turns.

Immobilized movement: The affected creature may not move for a particular number of turns.

Poison: The affected creature takes damage at some interval until it finds a cure.  In scenario 2, this is accomplished with a potion or the help of a cleric.  In some scenarios (such as scenario 2), the interval depends on the scale of the map in question, just as with food use (but not necessarily at the same rate).

Sleep: The affected creature may not act until it wakes up.  It has a chance to wake up each turn.  During that time, attacks may still be made against the creature.

Stun: The affected creature may not act for a particular number of turns.  During that time, attacks may still be made against the creature.


Inventory

Your inventory may be shown in one of three ways: On the sidebar, on the standard inventory screen, and in the inventory list.  The sidebar shows gold and food, while the standard display shows everything else.  The inventory list shows everything together.

There is a drop command that is useful in some scenarios and merchants will buy selected items in some scenarios.  However, this is not always the case.

Some scenarios use encumbrance, such as scenario 2.  Current and maximum weight is listed in the standard inventory screen and in the inventory list.  An item that increases the total weight by too much may not be picked up.  That said, some partial quantity of a stack of items (like some of the gold coins from a pile of them) will be picked up if there is enough carrying capacity left for some of them.  If an item is given and is too heavy to pick up, it will be dropped on the ground.  Weight can be reduced by dropping items, placing them in containers, or selling them.  Items that are placed on the ground or even in containers are not necessarily secure, depending on the circumstances; they may or may not be gone when you leave and come back.  The drop command will inform you of the security of a given area.  Containers can be used to increase safety.  Some merchants will store items for a fee.  Some particular areas, containers, and merchants provide absolute security.

An item may be placed in or taken from an interactive container with the "use" command.  This also provides an option to list the contents of the container and, in some cases, an option to destroy a selected item.  Some vehicles provide cargo space in the same manner.  Once a vehicle has been boarded, the "use" command provides an additional option to access vehicle cargo.  Not all containers are interactive.  Many are either not usable (belonging to NPC's and such) or disappear once the contents of been taken with the "get" command.

In the scenarios that do not use encumbrance, it is assumed that everything you have obtained is available to you, yet you can assume that much of it is stashed away somewhere.  For example, you may have access to 10 suites of armor, but 9 of those may be stashed away back on your ship.  These scenarios do not require you to go back and get them; they are always available in your inventory.  Switching these items at any time does not effect game balance.

There can be an additional limit on a few items.  For example, in scenario 2 it is only possible to carry one portable boat at a time.  This represents a limitation on items that are particularly cumbersome and where having more than one at a time would be illogical and/or change game balance.  For example, in scenario 2 the portable boat is required in some areas and yet is very fragile (low hull points) so it would be beneficial to carry more than one were it possible.


Items

Items are used by various commands or automatically.

Many commands require a specific item, for example, the "ignite" command uses a light source such as a torch, the "unlock" command uses a key, etc..  The "use" command is only available in some scenarios, such as scenario 2.

Some items are used automatically as needed if they are in your inventory.  For example, in the Ultima II scenario, there are items that automatically resist the powers of particular creatures and other items that are necessary before a given vehicle may be used.  In scenario 2, there are items that automatically resist the negative effects of dangerous terrain.

In some scenarios, a few items are used automatically but can also be used separately.  For example, in scenario 2 there are some quest items that can be examined using the "use" command, but are also used automatically in another manner when a specific point in the quest occurs.

Some items required for specific commands follow:

Board: Some vehicles require special items before they may be boarded or to use them successfully after boarding.  Be careful using this command on vehicles that belong to others (see "crimes", below).

Cast: This requires a magic spell item in scenarios that use the standard magic system

Get: Used to pick up an item that is on the ground.  In some scenarios, hidden items may not be visible (although the "look" command can also be used to search for them).  If the item is a container such as a treasure chest, the container may disappear to indicate it is already used.  This command will also trigger the use of an interactive container.  If the item cannot be picked up, a message may provide more details.  Be careful using this command on items that belong to others (see "crimes", below).

Hyperwarp: In the Ultima II scenario, this requires a special item for fuel

Ignite: This requires a light source such as a torch

Negate: This requires a special magic item

Offer: This requires gold

Ready: To select something other than just hands for making attacks, this requires a weapon.  Similarly, a shield or ammo requires that respective item.

Unlock: This requires a key.  Some scenarios use specific keys.  Be careful using this command on doors that are restricted (see "crimes", below).

Use: This command functions on both ground items (things that have not been picked up) and on inventory items (things in your inventory list).  For ground items, choose the direction from the character with the arrow keys (this also includes interacting with the cargo of vehicles you have not boarded).  For inventory items, press "I" to choose from a menu of usable items.  When a vehicle has been boarded, press "V" to interact with the cargo.  In any of these cases, it may prompt the user further once the particular item is selected.  Note that scenario 2 makes heavy use of this command for both magic and mundane items.

View: This requires a special magic item.  Note that it may not be allowed on some specific maps.  Further, some scenarios such as the Ultima II scenario do not allow this on any FP maps at all, while others such as scenario 2 do allow it.

Wear: To select something other than just clothes/skin, this requires armor


Vehicles

Vehicles include things like ships, smaller boats, horses, etc..  The vehicles that are available may differ significantly between scenarios.  For example, the Ultima II scenario uses 2 modern vehicles, airplanes and rockets, in addition to ships and horses.  Scenario 2 does not use any modern vehicles, but does include boats in addition to ships, including portable boats, and camels in addition to horses.

A vehicle is used by using the "board" command.  To exit the vehicle, use the "exit" command.

Once in a vehicle, the display of the PC usually changes correspondingly.  Some vehicles allow travel on terrain that is not accessible by foot.  For example, a standard boat or ship allows travel on water.  In some scenarios such as scenario 2, a ship may not enter shallow water but a boat may do so.  In some scenarios, a vehicle may help with slow terrain movement on a given terrain types, such as camels in the desert in scenario 2.

Some vehicles partially simulate an improved travel efficiency by reducing the amount of food that is consumed each turn, although speed corresponding to other characters on the map is not necessarily improved.  Other rates may also be improved in some scenarios, such as the frequency of light source usage, poison damage, or desert water usage in scenario 2.  For example, riding a horse reduces the overall amount of food that is used and, in scenario 2, the overall amount of damage applied by poison.

Some vehicles include special weapons that are accessible using the "fire" command.

In some scenarios such as the Ultima II scenario, hit points, armor, and abilities with a given weapon is based entirely on the PC and does not change.  In others, such as scenario 2, some vehicles such as boats and ships have their own hit points (also known as hull points) and AC (known as vehicle AC, or VAC), the PC's abilities further modify the overall VAC (since a better pilot can help keep the vehicle from harm), and the results of using a vehicle weapon is based on a combination of the PC's skills and the type of weapon, just as with any standard weapon.  When a vehicle has its own hull points, the sidebar's display will change correspondly when the vehicle is in use.  The stats displays will show various vehicle-related details when a vehicle is in use.

If the vehicle is not in use, the "look" command may be used to view its current condition.

If a vehicle with hull points is critical to a PC's survival (such as a ship at sea), destruction of that vehicle may lead to the PC's death.  However, any secondary vehicles in cargo or inventory will be made available at that point as choices for an escape craft.

Hull points may be damaged by a variety of methods.  For example, in scenario 2, enemy groups may damage a ship with ranged attacks, such a pirate ship's cannons.  A creature without ranged attacks such as a sea serpent that can't reach the PC in zoom-in combat may instead attack the ship itself.  Storms and whirlpools may also damage a ship.  A boat may be damaged by rapids.  Etc..

In scenarios where hull points are used, it may be possible to repair a damaged vehicle using specific merchants.  The vehicle will need to be on the same map as the merchant in order to do this.

Some vehicles are affected by the wind, such as the various ships in scenario 2.  You may not move if the wind is becalmed, in which case you can wait until the wind changes again (use the "pass" command) or take some other action (for example, you could still exit if you are next to land and walk, fire a weapon at an enemy, board a secondary vehicle that is not affected by wind, cast a spell, etc.).  If you sail directly into the wind, you will be delayed like on rough terrain.  If you do not want to do so, you can move in another direction, wait until the wind changes again, or take some other action.  Wind also affects some creatures, such as the pirate ship in scenario 2.  Some magic may allow changing the wind to help you move or hinder an enemy from moving.

Some vehicles may carry cargo, such as the ships in scenario 2.  These are used in the same manner as standard interactive containers (with the "use" command).  The "destroy" option offers a means to empty a vehicle of any heavy, unwanted cargo (for example, dumping a ship's cargo).

Some vehicles may be portable, such as the portable boat in scenario 2.  In such cases, use the "get" command to pick it up into inventory and the "use" command to place it back onto the map (onto valid terrain, such as water for the portable boat).

In some scenarios such as scenario 2, some vehicles may be placed into another vehicle's cargo directly (for example, a small boat or horse onto a ship).  To do this, remain boarded on the first vehicle (such as a small boat or horse); do not exit it.  Move onto the new vehicle (such as a ship), then use the board command.  It will place the first vehicle into the cargo of the new vehicle or the PC inventory if it is not too heavy (such as a portable boat).  The opposite is also possible, meaning boarding a vehicle stored in the cargo of a current vehicle (such as a boat or horse in the cargo of a ship).  When boarded, the "use" command on the vehicle will offer the option to board a "secondary vehicle", if one is available.  The same basic process is used if a vehicle crucial to survival is destroyed (for example, a small boat being carried by a ship can be used as an escape craft).

Some vehicles may not be used unless a particular item in in inventory.  This is the case in the Ultima II scenario, but the specifics are discovered as part of game play.

Some flying vehicles, such as the airplane in the Ultima II scenario, use a special flying mechanism.  The "launch/land" command is used to toggle between flying and returning to the ground.  Any movement when not flying (if allowed) is nothing more than moving on the ground.  When flying, the vehicle moves at a steady rate in a direction that can be modified with the arrow keys.  You must time your use of the "land" command carefully to land on allowed terrain or you will fail to land.

A flying vehicle may sometimes move on the ground without flying.  The terrain allowed may differ depending on the vehicle and scenario.  For example, the airplane in the Ultima II scenario may only move on open land (grass, not water, not trees, etc.), but a different scenario using various types of airplanes may have one that allows movement on the water (grass and water, but not trees, etc.).

The Ultima II scenario also includes a rocket.  The rocket uses a fairly specific mechanism, although variations on the mechanism are available and could also be used in other scenarios.  The "launch" command is used to enter space.  Special items may be required to enter the rocket and then to survive the launching process.  Once in space, the sidebar changes to indicate an x, y, and z coordinate, and hyperwarp fuel.  The "hyperwarp" command is used to change this position and uses up some of the special fuel, an item which must be in inventory.  In many cases, the coordinate may contain nothing more than empty space.  In some cases, you may enter orbit around a specific planet.  The "land" command may then be used to enter the landing sequence.  The landing sequence is much like the flying mechanism for the airplane, except you have no control over direction and any landing on invalid terrain will result in destruction.  Some coordinates in space will lead to special locations.  For example, entering the coordinates of the sun will result in destruction.


Character information

Various character information may be viewed using a variety of methods.

The sidebar is the text at the bottom, right-hand side of the screen.  This normally displays hit points, food, experience points, and gold, although it can change in special situations to display other information (such as hull points instead of hit points when a ship is used in scenario 2).  In some scenarios such as scenario 2, it also displays the wind direction and spell points (for characters that have spell points).  In some scenarios such as the Ultima II scenario, it changes dramatically when a space vehicle is in use.  It is even possible for a given scenario to change some of what is displayed under normal circumstances such as displaying torches instead of another value (although no built-in scenarios currently use this capability).

Some values will be displayed as inverse text if they are under a particular amount and therefore need to be noted.  For food, this happens under a preset value that is considered low (for example, 100).  In Ultima-style scenarios, the same happens for HP.  In scenarios with an HP max, this happens for HP whenever it is under that max.

Since only a limited number of digits are available, if a numeric value reaches a point where it has more digits than that, it will be displayed with the suffix "K" to indicate that it is displaying in thousands.

Press "Z" to display the standard stats screen, which is presented as a full screen text.  This displays the character name, level, gender, race, and class.  The active weapon, armor, and spell is shown next.  Note that like all full-screen text displays, this screen can be scrolled up and down with the standard text display keys if more space is required than will fit onto the screen at one time.

To the right are some of the items crucial to many scenarios.  In some scenarios, such as the Ultima II scenario, they are torches, keys, and tools.  In others, such as scenario 2, they are gold, food, and torches.  Part of the reason for the difference is that those scenarios do not use some of those items (for example, the keys field is unused because they use only specific keys).

After that are the character ability scores, then the complete inventory of items categorized separately into weapons, armor, spells, and items.  Some scenarios such as scenario 2 also include a shields category.  The "items" field is the general category that lists all the items not categorized separately.  Remember that if there is more text than will fit onto the screen, you may scroll up and down.

In some scenarios such as scenario 2, additional information may be presented depending on various factors, such as vehicle information when using a vehicle, ranged weapon information when using a ranged weapon, etc..

Press "Control-Z" to display the detailed character stats.  This lists many more details about the character and may change depending on various factors such as vehicle information when using a vehicle, ranged weapon information when using a ranged weapon, etc..  Note that this is presented in list format rather than on a full screen like the standard stats screen.  To see more at once, use the F9 key to toggle between full screen text and back again.  Also note that there are many important details useful for scenarios such as scenario 2 that are presented here, such as current condition (which would include poisoned, etc.), combat stats (which may be helpful in understanding the effectiveness of weapons and armor, etc.), PC morale (to check how much remains, how much more can be gained in each category, etc.), point modifiers (to check which ones are currently active, how much remains for each of them, etc.), and so on.

Press "Control-I" to display the detailed inventory list.  This is the corresponding command to the detailed character stats list and works similarly (it is presented as a list, use F9 to see more at once, etc.).  Note that in scenarios that use the corresponding features, this includes addition information about items such as weight and charges.


Ability scores

There are 6 ability scores used in the game.  Most of them have one or more primary purposes.

STR: Strength.  This may increase the damage done in combat.  It increases maximum weight capability in scenarios that use encumbrance.
AGI: Agility (also called dexterity).  This increases the chance to hit in combat.  This may also increase the chance of success for the "steal" command (although note that command has been disabled for now until it can be more properly implemented).  It increases VAC and piloting in scenarios that use them.  This may also be used to evade negative effects that can be dodged.
STA: Stamina (also called constitution).  This may increase AC, depending on the scenario.  This may also be used to evade negative effects related to physical health.  It increases maximum weight capability in scenarios that use encumbrance.
INT: Intelligence.  This may increase the effectiveness of spells, depending on the scenario.  It increases spell points for particular classes (typicaly such as wizard) in scenarios that use the complex magic system.  It also improves prices.  It increases VAC and piloting in scenarios that use them.
WIS: Wisdom.  This may increase the effectiveness of spells, depending on the scenario.  It increases spell points for particular classes (typicaly such as cleric) in scenarios that use the complex magic system.  This may also be used to evade negative effects related to mental strength.
CHA: Charisma.  This improves prices.

Some scenarios such as scenario 2 may use one or more of these in specific situations for an ability check, which is a check made to accomplish some specific objective where a higher score in the ability in question increases the chance of success.  For example, in a particular conversation you may need to convince an NPC of something, so would probably have to make a charisma check.

Some scenarios such as scenario 2 use ability checks based on a combination of other attributes, perception.  This check is based on AGI, INT, and WIS.

Scenarios like scenario 2 tend to make all of the attributes useful for any class, so it is unwise to make anything too low without understanding that doing so may cause difficulties with related events in the game.  For example, a fighter with a low INT and WIS would have a low perception and therefore may fail a check to notice a trap.

Ability scores do not increase or decrease under normal circumstances, but it is possible for them to do so given special events in a given scenario.

Note that the way attributes work in scenarios based on the Ultima II style (scenarios 1 and 3) probably does not match that game exactly at this time (a planned future enhancement is to correct this), but it should still approximate it.


Levels

As a character does things like defeating enemies and solving quests, he or she may gain XP.  With enough XP (the particular amount depending upon the scenario in question), he or she may gain a level.  The new level will increase any of a variety of character capabilities, depending on the scenario.

Levels and the increased capabilities are gained automatically; it is not necessary to take any direct action, although you may want to view a stats screen to find out what has increased.

Scenario 1 and 3 increase particular combat capabilities, but not HP.  Levels are gained based on a static XP requirement.

Scenario 2 increases particular combat capabilities, HP, and SP.  Certain capabilities and checks factor in the current level, such as the power of some spells.  Levels are gained based on an ever-increasing XP requirement.


Conversation

A conversation is started with the "talk/transact" command.

Many NPC's are friendly and often offer information colorful, helpful, or critical for the scenario.  Some NPC's are merchants who offer important goods and/or services.

A conversation may take one of three forms: simple, simple merchant, and complex.

A simple conversation consists of a single response in the form of a line of text (although that may include more than once sentence).  Nothing must be done to exit the conversation.

A simple merchant conversation offers a menu of items or services, a prompt regarding a single item or service, or an immediate service with no prompts, etc..

A complex conversation may consist of any dialog, interaction, or game effects.  When you start a complex conversation, the prompt will change to "> ".  The important difference in a complex conversation is that you must often exit the conversation explicitly (although not always), and the interaction often consists of entering keywords.  This is similar to games such as the later titles in the Ultima series, but includes a very large number of additional features and variations.  Any keyword may or may not lead to additional interaction.  Although they are not always answered, the standard keywords used in scenario 2 are: look, name, job, and bye.  "bye" is usually available to exit a conversation and entering nothing at all (just pressing the enter key) will always do so.  No keyword includes more than one word (in other words, do not use spaces).  Spelling must normally be complete and exact (you cannot use the first few letters only, etc.), although sometimes variations are allowed (such as using a plural) on a case-by-case basis.  Additional keywords are offered through feedback in the conversation or by other means, such as separate conversations.  For example, if someone tells you about the magic sword, and you suspect someone else knows about it, you may want to try using the word "sword", or perhaps "magic".  Any unrecognized keywords are answered with an "unknown" response, such as "I'm sorry, I do not know anything about that", etc..  Note that a conversation may sometimes be ended by the NPC due to the course of the conversation, for example, "He draws his sword and attacks!".

It is also worth noting that in some cases, keywords are not even available until they are mentioned or can lead to different results in the course of the conversation.  For example, if someone tells you about the quest he was on, "quest" may cause him to tell you about it, but then later he may ask you to go on a quest for him and "quest" may instead cause him to explain what you need to do.

Note that in a few cases, a complex conversation or situation using the same mechanism may be initiated through non-standard means.  For example, you may step into a particular position and an NPC initiates dialog, some magic or the use of an item initiates some conversation-like interaction, etc..

Another issue is that the game keeps track of who you have spoken with.  This can be used for a variety of purposes, just some of those being that you may not know an NPC name until after you have spoken with them the first time (doesn't show up in various commands such as "look"), the NPC may respond differently to you the next time you speak to them, and the show object state command has an option to show you who you have not spoken to yet.  That said, it is important to note that just because you have already spoken to an NPC doesn't mean that they won't have something new to say after something else has happened in the game; you may not want to ignore an NPC just because you already have talked to them once or twice.  That doesn't mean that you should talk to every single NPC everytime something important happens, but there are some select NPC's in scenarios such as scenario 2 that will have something new to say at times.

Some scenarios also make use of the "offer" command.  This command allows you to give an NPC some gold in the hopes that they will do something in return.  Some scenarios do not make use of this command, such as scenario 2.  However, this is an important command in scenarios 1 and 3.

Some scenarios also make use of the "yell" command.  This allows you to literally yell out a word.  This may be important for a variety of reasons that would become apparent during the course of the game.  Note that the effectiveness of this may or may not be tied to any specific circumstances, including map and position on the map.  For example, if you wanted to yell out a password, you would want to be in a place where someone would hear you.


Magic

There are two distinct and very different magic systems in the game, the standard magic system and the complex magic system.  The system used depends on the scenario.

The standard magic system works based on spell items.  A spell item must be purchased prior to casting a given spell.  Only casters of a particular type may purchase the corresponding type of item.  For example, in the Ultima II scenario, only a wizard may purchase wizard spell items and only a cleric may purchase cleric spell items.  The exact nature of this item is not clearly defined, but, based on later games in the series, probably consists of the reagents necessary to cast the given spell.

The magic spell to use is selected using the "magic" command, much like a weapon is selected with "ready" or armor with "wear".  The "cast" command is used to actually cast the spell.

The complex magic system works based on spell points (SP).  Each spell has a cost in SP.  If the cost exceeds the SP available, it cannot be cast.  SP's are typically restored by resting and sometimes by other, special means specific to each scenario.  SP works similarly to HP in that there is a maximum, the maximum may increase with levels, etc..

The spells available are specific to each class.  Some classes (such as a wizard in scenario 2) must learn the spells they cast, although they may start out already knowing a few.  Others (such as a cleric in scenario 2) can cast all spells that are within their capabilities.  Spell capability is determined by spell point maximum, which usually increases with each new character level.  Even if something special in the game increases the current spell points beyond the maximum, capability is still determined by the maximum.  For classes that require spells to be learned, there are any number of possibilities, but traditionally include teachers and spell scrolls.

The spell to cast is selected every time, and therefore the "magic" command is not needed.  However, the "cast" command is still used to actually cast the spell.

The particular spells available are specific to each scenario.  Scenario 1 and 3 use the standard magic system and traditional Ultima II spells, although scenario 1 may include additional variations on these.  Scenario 2 uses the complex magic system (as well as a number of magic items that behave similarly to spells), and the spells themselves are often different or at least behave very differently from the spells of the standard magic system.

The complex magic system has a few additional details worth noting:

- The power of some spells increase as the character level increases.  The exact nature of this increase depends on the spell in question.  For example, some spells may last longer, some may allow for a greater total of the enhancements on the target, some may overcome stronger negative effects, etc..

- The spells and powers of NPC's, creatures, and items may behave differently from PC spells.  For example, the power of a given item may or may not necessarily match the behavior of a similar PC spell.

- A spell that applies a point modifier may fail to be cast for a variety of reasons, but two of the most common are that the target already has a point modifier of that category group with the same or greater points or that the target already has a grand total of more modifier points than the caster's abilities.  Refer to the specific section on point modifiers for more information.


Crimes

Some behavior is illegal and/or immoral.  Some scenarios simply prevent or punish you for taking such actions (such as scenario 2), while others support a nefarious PC (such as the Ultima II scenario), although there is still risk in such actions.

Most settlements include guards and/or other defenders.  If you are caught, these defenders will attack you.  In some scenarios (such as scenario 2), NPC's will no longer talk to you.  Also in some scenarios (such as scenario 2), the game will keep track of your status in these regards.  Most of these results apply only to the area in question.  However, in some cases (such as scenario 2), this may be enough to no longer be able to win the game in progress.

The exception to this is that some areas are owned by villains, in which case angering them is entirely appropriate for the hero.

The following include some of the actions that will provoke this:

- Attacks on non-hostile characters
- The "steal" command (although note that command has been disabled for now until it can be more properly implemented)
- Taking an owned item (such as using the "get" command)
- Unlocking an owned door (when this is not allowed)
- Boarding an owned vehicle


Checks and rolls

Like most games of this type, a variety of checks are made in the game when attempting various actions to determine successs or failure.  The chance is a combination of a random factor modified by any number of conditional factors relevant to the particular circumstances of the check.

For example, an attack is based on a random factor modified by the offensive power of the attacker vs. the defensive power of the defender.  The PC's offensive power is based on PC attributes and the weapon in use, and defensive power on PC attributes and the armor and/or shield in use.  Both may also be modified by particular point modifiers and the former by any PC morale.  NPC's are set up with a variety of more direct definitions for their offensive and defensive power.  A more powerful character will have a greater chance of successfully attacking or resisting an attack, but because the result includes a random factor, success or failure is never certain.

Other checks include almost anything, from special situational checks such as convincing an NPC of something during a conversation, to standard checks such as resisting various negative effects of creature powers or particular terrain.

In the tradition of tabletop games, the random factor of these checks are treated as rolls of dice.  This game typically uses a number between 1 and 100.  Modifiers to the roll are relative to that range.

Depending on the type of check, a roll of 1 is often considered an automatic failure and 100 an automatic success in order to represent an instance of particularly good or bad fortune with regards to the particular action in question.

The use of these rolls and modifiers are visible in some of the more verbose output settings and in scenario design (discussed in the "Custom scenarios" section).  Automatic success and failure are sometimes explicitly mentioned in the game, such as a "critical hit" or "critical miss" in combat.


PC morale

Some checks may be modified by a morale bonus for your PC, if the scenario in question uses the mechanism (scenario 2, for example).

A morale bonus can be gained through particular actions in the game and is a pool of points that is used up whenever they are applied to a roll.  The points are also divided into categories based on the type of activity that grants them.  They are limited to a maximum for each category, so the categories cause more diverse activities to grant more overall points.  For example, having meals other than trail rations may grant some morale points in a food category.  Such a meal may well cost more than the rations, but the benefit for the greater cost is morale points.  Higher quality may well grant more points and allow a greater maximum.  For example, a high quality meal may offer a greater bonus with a higher maximum points.  After a given number of meals, the maximum points for that category will be reached and more will not add more points.  But a visit to a minstrel, for example, may grant points into an entirely separate category.

The points granted are displayed, so it is not necessary to fully understand the specifics of the system in order to make use of it.  The basic premise is that diverse activities of higher quality will result in more points.

Only a particular percentage of the total remaining morale points available are used for each roll and there is a maximum.  This means that typically morale points will remain through multiple rolls before they are used up.  It also means that the earlier rolls may apply a greater benefit, while the last rolls using the bonus will only apply 1 point at a time until they are all used up.

Points under the maximum may be refreshed at any time; they do not have to be used up first.  The usage per category is evenly distributed.  For implementation reasons, the total points are tracked separately from the points per categories and the categories are only adjusted downwards to synchronize just before new points are added.  Therefore, if any points have been used, the sum of the categories may be greater than the total, as shown in the character stats information.  In this case, the total is correct and the categories will be adjusted when new points are added.

The idea behind morale points is to rewards players for taking certain actions in the game.  While many other games have the ability to purchase food, drinks, entertainment, etc. at various qualities, they often seem to ignore any benefit for doing so.


Point modifiers

In some scenarios, there are situations that may cause special modifiers to be applied to the PC.

Such a modifier may be a bonus (a positive value) or a penalty (a negative value) and more than one of these may exist at a time.  A common way these modifiers are applied is through the use of spells or powers, although point modifiers are not specific to magic and may be applied for any number of reasons.  While some point modifiers may be applied to general checks throughout the game, many of them are applied only for a particular category such as attack checks, AC, checks to resist various types of negative effects, etc..

For example, in scenario 2 a beneficial spell may create a bonus to the caster's attack rolls, a magic item may create a bonus to the user's AC, an enemy creature may use a power that creates a penalty to the PC's general rolls, etc..

Note that any active point modifiers can be displayed with the detailed PC stats (Control-Z).

Each modifier contains a pool of points that are used up as they are applied.  Typically, only a small, consistent portion of these points are used up at one time.  A given modifier will disappear once it has been used up entirely.  Note that it is possible for some modifiers to spend all points at one time, but this is rare.  For example, a scenario 2 spell may be called "Luck" that provides 50 points with 5 points spent at one time towards general checks.  The next time a general check is made, 5 points are spent to improve the check and the total is decreased to 45 points.  The next check will spend another 5 points with the total decreased to 40 points and so on.  Another spell that behaves in a more rare manner may be called "Heroic Attack" that provides 50 points towards attack checks with all 50 points spent at one time.  The next time an attack roll is made, all 50 points are spent to improve the check and the total is decreased to 0 points, which causes the modifier to disappear.

Note that if the amount normally spent is greater than the points remaining, then only the remaining portion will be applied.  For example, if 5 points would normally be spent but there are only 3 points remaining, then only 3 points are spent.  Also note that a modifier to general checks will be applied towards a variety of specific result categories, but does exclude some of them such as AC.

Modifiers may be specially categorized into groups so that some of them are mutually exclusive while others are not (this is known in some games as "stacking").  For example, a scenario 2 spell that increases general checks may fail to be cast if one has already been applied.  Note these special group categories are an entirely different concept from the result categories (general checks, attack checks, AC, etc.).  For example, both a "Luck" spell and "Bless" spell may create modifiers to the result category of general checks but can still both be applied at the same time because they may well belong to different group categories (the Luck and Bless spells would "stack").  However, a second Luck spell or a "Minor Luck" spell would probably belong to the same group category (which could be considered the "Luck" category) and so could not be applied at the same time.  That said, note that a modifier in the same category CAN be applied successfully if it increases the total current points.  For example, if a Luck spell had previously been used to apply 50 points and those had since decreased to 45, then casting a subsequent Luck spell would restore the total points back up to 50.  Or if Minor Luck applied 25 points and had been previously been cast, then if standard Luck applied 50 points it could be cast in order to increase the points from 25 to 50.

Some modifier sources such as PC spells that apply a modifier may check the total of all modifiers currently on the target in order to limit the total number of points that may be applied to the target at the same time (meaning this is an additional limit to the grand total of ALL active point modifiers on the target, not just the one in question).  When this is the case, the modifier will not be applied if the maximum that the source is able to apply has already been reached.  For example, a spell may fail to be cast if the target has already reached or exceeded the caster's maximum.  Note that in the case of spells, this maximum may increase with the caster's level, meaning this limitation becomes less severe as casters become more powerful.  Also note that if the maximum has not been reached but would be exceeded by applying the new modifier, then only part of the new modifier will be applied (the amount to reach the maximum).  Note that penalties DO count towards the total, making them even more undesirable since this means that they can prevent beneficial modifiers from being applied; they "use up" some of the total points (this is not a design limitation but rather an intentional choice specifically implemented in the design to add an interesting detail to penalties).

Note that point modifiers behave similarly to PC morale in some ways but are also quite different.  For example, PC morale uses a percentage of the remaining points whereas point modifiers are used up at a consistent rate, PC morale always applies to general checks whereas point modifiers often apply only to a particular result category, PC morale has different source categories whereas point modifiers do not track the source, there is only a single overall PC morale point total whereas there can be many different point modifiers, etc..  In other words, they are entirely different systems even though they share a few concepts.  Note that both point modifiers and PC morale will both be applied fully to a single roll at the same time (they do "stack").  For example, if a morale bonus would normally provide 3 points to a general check and a point modifier would normally provide 5 points to a general check, then the next roll will include a bonus of all 8 points.


Look and show object state

Two powerful commands are available to help clarify the environment around you.  They are most useful in scenarios such as scenario 2, but will function in all of them.

The first of these is the "look" command.  This will give detailed information about any visible object in the game.  You can use it on the ground and it will tell you what the terrain is called (for example, "Grass" or "Stone wall").  For a location, it will tell you what it is named or called (for example, "The town of Friel" or "Dungeon").  For an item, it will tell you what it is called are and how much they weigh.  For a creature, it will tell you what it is named or called, any special description, percentage of HP remaining, and any other special details you may want to know such as if it is delayed or an ally.  Note that looking at a creature can be VERY useful in combat.  For a vehicle, it will tell you what it is named or called, any special description, and HP.  Note that when there is a stack of multiple objects, the command will give information for each.

The second of these is the "show object state" command.  This will visually give quick information on one of several subjects, although that information is usually less detailed than that given by the "look" command.  The visual information typically consists of highlighting the objects in question.  Two versions of this command exist, one that repeats what was last used for purposes of ease of use and efficiency, and another that allows selecting the desired sub-option from a menu.

Show object state has the following sub-options:

Not met: Shows creatures that have not yet been met, which can be very helpful in determining who you have not talked to yet.  The can be particularly useful in situations with many NPC's that look similar and/or are moving around a lot.  That said, note that just because you have already talked to an NPC doesn't mean that they won't have something new to say later on when something else has happened in the game.

Not attacking: Shows who is not currently attacking the PC, which can be very helpful in combat.  Note that this presents enemies who are want to attack but can't as white, allies as blue, and any other creatures who are peaceful as green.  Creatures who can attack but are not close enough are not included.  Enemies who are retreating will also show up as white.  Some conditions that prevent enemies from attacking include delay, immobilized attacks, and sleep.  As noted elsewhere, delays can be applied to a creature for a variety of reasons, some of which include slow terrain (such as moving through forest), attack delay (such as for reloading a bow), and magic or special powers (such as stun).  Immobilized attacks and sleep are usually due to magic or special powers.

HP: Shows creatures that have lost HP, which can be very helpful in combat.  Note that this presents some loss in yellow (50% or greater) and severe loss in red (less than 50%).

Note that the "look" command represents an up-close and more detailed look at something, whereas showing the object state represents a quick scan of things that are often farther away.  For example, because of this the "look" command will give more precise information about HP than showing the object state.

Neither command will work on objects that have a special ability to be completely hidden, such as a particular invisible creature on scenario 2.

However, it is very important to note that the "look" command CAN be used to find objects that are simply somewhat hidden such as special locations or items; it can serve as a search command.


Ending the game

Each scenario has a variety of options for how to win and how winning is handled.  Some may simply declare that you have won, while others may present a long series of details.

However, once a scenario has declared that you have won, you are eventually presented with a menu asking what you wish to do next.  This menu should be self-explanatory.  The most common options would be to quit or go back to the main menu.  You may also wish to first save the game if you are tracking the events of the game through named saves.

The same menu is used after character death.  The most common options would be to restart from the current save or to load from a named game.


Options menu

The options menu offers a variety of settings.  Many should be self-explanatory or are discussed elsewhere, but a few details follow.

Quit Game: Quit the game entirely

Quit to Main Menu: Quit the scenario and go back to the main menu

Load, Save, and Restart Game: Load or save a named game, or restart from the current save.  See the section on "Saving and loading the game", above.  Restart is particularly helpful to go back to the most recent save before you ran into a problem.

Toggle Sound: Turn sound off or back on

Toggle Animation: This may be helpful for a variety of reasons, but in particular, I have noticed that for some reason some flatscreen monitors will "flash" during animation (many, many hours of research have not revealed the solution).  If this is the case and becomes bothersome, consider turning animation off.

Toggle Text Pause: Turn automatic text pause on or off.  See the section on "Text Screen" above for details.

Set Verbosity: The standard way of displaying command feedback is configured for a given scenario, but can be changed here to provide a different way of displaying some of the more common output.  Minimum uses the very minimalistic Ultima II style, standard uses something that is more detailed but still attempts to preserve the general Ultima II style, and the others display extra, more verbose information.  The effect is most noticable during combat.

Inventory Options: This brings up a respective secondary menu described below

Reorder Known Spell List: This option allows spellcasters with a known spells list to reorder their list.  This may be helpful for organizational and selection purposes.

Output help to text file: This will write the F1 text to a file.  Refer to the earlier "Printing documentation" section for more details.

Advanced options menu: This brings up a respective secondary menu described below


Inventory Options

Reorder: Standard PC inventory is a fixed list and so, unlike interactive containers such as cargo, is not displayed in the order in which items are added or removed.  Any items that are not in inventory will not be shown, but the display order will otherwise always be in the same order.  That said, this option allows customizing that order.  This may be helpful for organizational and selectionp purposes.

Restore default order: If you have created a custom inventory order, this option allows you to restore the original order.

Set to definition order: This creates a special custom inventory order that matches the item definition order, the same order that was used in older versions.  This option allows you to go back to that order in case you happen to prefer it.  That said, note that this is considered a custom order.


Advanced Options menu

Bug fix options: This provides mechanisms to fix save games that have been corrupted by one of several known bugs that were in older versions.  Separate documentation provides additional details.  Note that it is NOT necessary to use any of these options for save games that were all created by newer versions where the bug wasn't an issue to start with; only use these options if you are absolutely certain that your save games have been corrupted in a specific manner by any of those bugs when you were using an older version.

Toggle Debug Messages: While there are a variety of debug tools built into the game, most of these are unavailable without activating the developer mode.  However, debug messages are those that may most generally help to narrow down any bugs and therefore are available at any time.  There is no reason to activate this under normal circumstances.

Toggle Redraw Debug Mode: These are similar to the standard debug messages but specific to screen redraw information.  As with the standard debug messages, there is no reason to activate this under normal circumstances.

Toggle Draw Mode: Very old machines may display better using an alternate draw mode.  However, this should not be activated under normal circumstances because it has not been fully tested and may prevent important graphics from being displayed.


Screen locking

The PC is typically displayed at the center of the screen.  There are times, however, when it is beneficial to display the PC offset from the center and moving around the screen.  An example of this is for scenarios that use zoom-in combat or dungeon rooms.  Most of the time, the use of screen locking is set up by default by the map in question and no specific user interaction with it is required.  However, it is worth noting that the option does exist to toggle it on and off manually with the F8 key.

When in screen locking mode, if a screen is smaller than the map in question (in terms of tile width and height), then attempting to move past the border will cause the screen to shift in the given direction.  That said, most scenarios that use the feature will have the maps that use it match the default screen size so that doing so is not necessary.  Attempting to move past the border of a map will behave normally.

Note that a special screen-locking option (accessed with Control-F8) allows centering the screen on the PC, while another allows resetting the screen to the default position (if any).


********************************************************************************
Configuration details
********************************************************************************

Here are some additional details regarding configuration.  Refer to the section above for a general overview and more basic information.

Changing the font

The game will automatically use the default font under normal circumstances.  However, it if detects that the default font has been damaged, it will then attempt to use secondary default fonts until it finds one that is undamaged.  If all of the fonts are damaged, it will go back to using the original default font even though it is damaged.

A damaged font will display incorrectly.  The text will appear incorrectly and may shift around.  This is because the system has provided a replacement font that is variable-width instead of the necessary fixed-width font and the game does NOT support variable-width fonts.

If you want to configure the font for any reason, whether to resolve a problem with it or because you simply want to use something else, this is possible.  As mentioned elsewhere, each scenario contains a configuration file that can be modified as needed.  Further, the built-in scenarios all reference a shared file in the root directory named "game.cfg".  You may modify any of these files in order to change a variety of settings including the font.

If you change the shared configuration file, the changes will apply to ALL of the scenarios.  If you change the configuration file in a given DATA directory, the changes will apply only to the scenario in question.

The shared configuration file contains several pre-configured font settings, but you may alter or add others as desired.

ALL of the configuration files are plain text and therefore MUST be modified with an editor that is able to save as plain text (for example, Notepad on Windows).  If you save the file in another format, the file will NOT be read correctly.

It is strongly suggested that before modifying ANY file, made sure you first back up the original version of the file (perhaps copy it and rename it to something like "[origname]-orig.[extension]").

For example, if you wanted to enable the "Courier New" font you could do the following:
- Copy game.cfg to game-orig.cfg
- Open game.cfg in Notepad
- Disable the comment-begin line by adding a preceeding pound sign to it ('#', so it becomes "#/*".
- Save the file
- Launch the game via any scenario and it should now use the new font
- If you wanted to change it back, reverse the steps (change the "#/*" back to "/*" and save the file)


********************************************************************************
Definitions
********************************************************************************

There are terms traditionally used in tabletop and computer role-playing games that are used throughout this manual.  Many people will already know these terms, but a few are defined here, just in case.  Note that there are also some additional details about some of the subjects here with respect to how they are used in this game.  Also note that some common terms are included in order to clarify the context of their use in this game.

Armor class (AC): A measurement of resistance against attacks, in other words, defensive capability

Class (character): A category defining a set of capabilities and related progression for a character, for example, fighter, rogue, cleric, wizard, etc..

Dungeon: This does not refer to a prison, but rather to any dangerous area filled with monsters or other enemies, often a underground series of tunnels.

First person (FP): The view is from the position of the character.  You do not see your character, but what your character would see.

Hit points (HP): The numeric amount of damage a character can take before it is killed.  In some scenarios such as scenario 2, there is a maximum HP that increases as a PC gains levels (which normally indicates that the PC is more adept at surviving damage by increasing the granularity of damage, not that he or she has a stronger body).  In this game, a character is killed when he or she is reduced to 0 HP (or less).

Hull points (HP): Another term for hit points of a vehicle

Level (character): Character level is a measurement of the character's relative power.  A higher level character is more powerful.  Levels are gained as the game is played by earning XP.  In this game, the first level is 0.  Note that the term "level" can also apply to many other contexts.

NPC: "Non-player character", everyone besides your character (including monsters and animals)

Overhead (OH): The view is from overhead and, in this game, your character is most often visible in the center of the screen (although the position may change in some cases).

PC: "Player character", your character.  Not to be confused with the use of "PC" referring to a computer.

Race (character): The type of creature, for example, human, dwarf, elf, etc..  Different races usually affect character capabilities.

Spell points (SP): The numeric amount of magic energy available to cast spells.  These are only used in scenarios that use the complex magic system.  Refer to the magic section for more details.

Tileset: A tile refers to the single square from which the graphics on the screen are shown or to a single graphical element in the FP graphics.  A tileset is a complete set of those tiles that can be used at any one time.

VAC: Vehicle AC

Vehicle: In this game, this definition includes anything that can be boarded, so both traditional vehicles like ships and mounts like horses

XP: "Experience points", a measurement of what the PC has learned through various actions in the game such as defeating enemies and solving quests


********************************************************************************
Keymaps
********************************************************************************

The default layout is appropriate for playing any of the included scenarios.  However, if a player or scenario designer wants to define commands for keys such as 0-9 or even override keys that are already in use by default, this is possible with the keymap feature.

To use this feature, you must edit a text file with a text editor program (such as Notepad on Windows); do NOT use a word processor unless you are absolutely certain you know how to save it as a plain ascii text file.  If you save the file in a format other than ascii text, the file will not be read properly and the feature will not work.

The file should be placed under the scenario directory in question such as "DATA2" for scenario 2 and must be named "keymap.dat".  A sample file exists in the sample directory.  You may use this as an example to create your own file or even copy it to the scenario directory and modify it.  If you copy it, remember that it must be renamed to "keymap.txt" for it to work.  Also, in any case, do not forget that it MUST be saved as plain ascii text.


Syntax

Before the key definitions is a setting named "LIST".  The format is "LIST: [count]" where [count] should be set equal to or greater than the number of definition entries.  You may set this value higher than necessary for the sake of convenience, but setting it too high will result in using up unnecessary system memory.  For example, if you have 7 definition entries you could use "LIST: 7" or even "LIST: 10" so it is easier to add more later, but you should not set it to anything lower than 7.

Each key definition entry consists of a key name, a command name, and a list of special fields such as modifier key definitions.  The key name may be a single keyboard character or one of several special names.

Not only can unused keys can be defined, but also existing keys can be overrided.  That said, only particular keys are supported (other than modifier keys).  These are listed below.

The format is:
[key] [command] [[Special field 1]...[Special field N]]

For example, to define the '1' key as Use:
1 USE

Special fields include the following modifier keys:

S: Shift
C: Control

For example, to define the '1' key with SHIFT as Use:
1 USE S

If you use any modifier keys, it is important to note those entries must be placed BEFORE any that happen to use the same key without a modifier key (this requirement is related to the implemenation being more efficient).  For example, if you define both Shift-A and A, the Shift-A entry must be defined before the A entry.  If you place the key without the modifier first, it will ignore the subsequent entries with modifiers in favor of the key without the modifier key(s).

Note that Alt is not currently supported, but a combination of SHIFT and CONTROL together IS supported.  This means that there are 4 distinct ways to reference any key:
- Without any modifier keys
- With SHIFT
- With CONTROL
- With both SHIFT and CONTROL


Supported keys

A-Z
0-9
Spacebar: SB
Backquote ('`')
Hyphen (minus) ('-')
Equal ('=')
Backspace: BS
Tab: TAB
Brackets ('[' and ']')
Backslash ('\')
Semicolon (';')
Single quote (''')
Enter (return): RET
Comma (',')
Period ('.')
Forward slash ('/')

Use the primary character to define the given key except when listed otherwise (for example, "SB" for the spacebar).  If the key is not listed (such as the function keys) then it is not supported for purposes of this feature.

Key names do NOT include the SHIFT-based character.  For example, the '1' key should never be referenced as the '!' key, but rather as the '1' key with a SHIFT modifier key.  In the same way, letter keys should never be referenced using lower case.


Supported commands

ATTACK
BOARD
CAST
DESCEND
DROP
ENTER
FIRE
GET
HYPERWARP
IGNITE
INVENTORY
JUMP
KLIMB: Climb
LAUNCH
LOOK
MAGIC
NEGATE
OFFER
PASS
QUITSAVE: Quit and/or save
QUITNOSAVE: Quit only
READY
REST
STEAL
TALK
UNLOCK
USE
USEINV: Shortcut to Use-Invetory
USEVEH: Shortcut to Use-Vehicle
VIEW
WEAR
EXIT
YELL
STATS
STATSLIST
SGO: Show game object state (current selection)
SGOSELECT: Show game object state (select)
SGONMET: Shortcut to show creatures not met
SGONATTACK: Shortcut to show creatures who are currently not attacking
SGOHP: Shortcut to show creatures that have lost HP
SGODELAY: Shortcut to show creatures with delay
SGOALLY: Shortcut to show creatures that are allies
LEFT: Arrow key
RIGHT: Arrow key
UP: Arrow key
DOWN: Arrow key
NONE: This makes the key invalid (can be used for overriding keys)


Examples

Define the '1' key as Attack:
1 ATTACK

Define the '1' key with SHIFT as Attack:
1 ATTACK S

Define the '1' key with CONTROL as Attack:
1 ATTACK C

Define the '1' key with SHIFT and CONTROL as Attack:
1 ATTACK S C

Define the '1' key as a shortcut to Use-Inventory:
1 USEINV

Override the 'A' key as Board:
A BOARD

Define the semicolon as Attack:
; ATTACK

Override the spacebar as Attack:
SB ATTACK

Override the 'M' key to be invalid:
M NONE


Further details

The system supports the standard overhead and first-person game user interfaces (for example, standard maps and dungeons), but NOT the special mode interfaces such when using an aircraft or spaceship.  For example, if you define the '1' key as LAUNCH, which is a toggle with land, it will work to launch the vehicle, but will NOT work to land the vehicle because a special mode interface will be in use at that point.

It is recommended to avoid overriding keys unless the key that is being overrided is, in turn, remapped to another key.  Otherwise, the functionality of the given key will be lost.  For example, if 'U' were remapped to Use, then Unlock needs to be remapped to some other key (perhaps Control-U to simply reverse them).

Keys that are in use include A-Z, spacebar, enter, tab, hyphen, and equal (some of the later are only available when in development/cheat mode, but are still always considered to be in use).  Defining one of these means that it is being overrided.  This is true regardless of modifier keys (for example, defining Control-A is still an override even though it is unused since 'A' IS used).

Like most standard data files for this game, the keymap.txt file also supports the pound sign ('#') character at the beginning of the line as a comment and the "/*" and "*/" comment begin and end syntax.  Comments are not processed as entries and therefore allow making notes or easily enabling/disabling entries.

The function keys were intentionally not included in order to prevent core functionality like the options menu from accidentally being lost.  Also, unused function keys may still be used in future versions.

The Alt key is not supported at this time due to an implementation complication.  However, resolving this is a possible future enhancement.

Extensive efficiency testing done on this feature demonstrated that there is no measurable decrease when a keymap file is being used, even with a very large number of definitions on a very old machine.  However, in theory the most efficient keyboard response time will be when no keymap file exists at all (or the file exists but does not contain any actual definitions).  Using overrided keys would be less efficient than unused keys (due to efficiency being a priority in the implementation).  Defining more keys would be less efficient than defining fewer.  However, as noted, efficiency testing demonstrated that this is unlikely to actually have any real effect, so this is just something to keep in mind in case of an unusual situation.


********************************************************************************
Text style and conventions
********************************************************************************

Although I have attempted to be reasonably accurate with regards to formal style regarding grammar and spelling and such both in this manual as well as in other documentation and in text in the game itself, there are a few things I should point out.

First of all, languages evolve and therefore I disagree very strongly with attempting to place limitations on them (trying to make them static) for the sake of tradition and such.  Many of the formal rules on languages (and things like music, too) are actually nothing more than an attempt to backwards-engineer rules for something that follows tendencies but otherwise lacks rules and evolves (essentially an attempt to freeze the evolution of language).  Because of this, I have intentionally made a few choices that do not follow the formal rules.

One of these is using a period after "etc." if it is at the end of a sentence.  The formal rule as I understand it is that there should be only one period to cover both the abbreviation AND the end of the sentence, but to me this is very illogical so I instead use 2 periods if it comes at the end of a sentence.  There will be one period if it is in the middle of a sentence (that needed for the abbreviation) and two if it is at the end (that needed for the abbreviation and that needed for the end of the sentence).  Three periods represents an "ellipsis", for example, "The orc wanders away...".  I point out the later to clarify that two periods after "etc" (so "etc..") is NOT an ellipsis.

There are also rules regarding punctuation inside of quotes vs. those that follow immediately afterwards; I intentionally ignore those in favor of what has the most logical appearance.

There are similar intentional style choices I've made throughout various text; these are choices I've made.  Similarly, I do not concern myself with some of the more obscure grammar rules like the "etc." issue mentioned above, perfection with regards to issues like minor misspelling, I do sometimes use the "smiley face" :) to indicate a tone of humor (just like an exclamation point also indicates tone), etc.. (Yes, the TWO periods here are intentional :) ... and the smiley face, too! :) ... Or, rather, now faceS, plural ... And the elipsis ... ok, I'll try to stop now, sorry ...)

That is not to say that I haven't made some actual errors; there's a lot of text in the various documents and in the game so it is more than likely there are some spelling and grammar errors.  I just wanted to clarify that some things that may appear to be mistakes are actually intentional choices.


Another style issue is that in the game itself, I use brackets to indicate actions that take place outside of the text when a section of text consists of a mixture of dialog and actions.  For example, "[He looks at you with closely.]  Say, you look like you can take care of yourself; would you mind helping me out?".  However, I do not use brackets when there is no mixture.

Brackets are used for data file names and command syntax and such in a very different manner.  A single bracket indicates a description for something that will be replaced (such as a file that is named "SomeFile-[ID].dat" where "[ID]" would be replaced by a numeric ID).  A double bracket indicates the same, except optional (for example, if a command is being documented as "SomeCommand [Type] [[Flag]]", then "[[Flag]]" is an optional parameter).


One blank line indicates the end of a paragraph.  Two blank lines in a row help to mark the end of a topic and the beginning of a new topic.


The "#" symbol (which is called a "pound sign"), is traditionally used at the beginning of a line of text in many scripting languages to mark comments so that no attempt is made to interpret them as commands.  I have adopted this particular convention for my own data files and built-in scripting language, and have added a very large number of comments throughout my scenarios' data files that may be of interest to anyone who wishes to design custom scenarios (when such comments are available; see the notes in the "Custom scenarios" section regarding data file comments for more details).


********************************************************************************
Custom scenarios
********************************************************************************

It is possible to create a new scenario for the game or to modify an existing scenario.  The information in this section is not necessary to play the game.

Almost everything in the game is "externalized", meaning, defined in files that can be created from scratch or modified.  Note that many advanced features are also available for use.


Steps

Following are the steps for creating a new scenario, although much of this information is also useful for altering an existing scenario.

- Make a copy of the entire pre-made data directory, "DATA1".  This copy should reside within the install directory, just as the original does.  As with the original directory, give this new directory a name in the form "DATA[NUMBER]".  The number may be anything that hasn't been used yet.  For example, you may decide to name the new directory "DATA100".  The number used is known as the "data ID".  In the example, the data ID would be "100".  Note that there is no realistic limit on the number of scenarios.

- Modify the data inside the new directory, as needed.  Note that almost all aspects of the game can be changed (see below for a general overview).  Most of the data files can be edited with a text editor such as Notepad (whatever editor is used, just make sure it saves as plain ascii text).  Use the comments and existing settings within these pre-made files as a guide to modifying them or creating new ones (when such comments are available; see the notes below regarding data file comments for more details).  That said, my separate editor program must be used to create or modify tiles and maps, as those cannot be edited with a text editor.  Use the separate manual included with the editor program install for more information regarding how to modify or create tiles, maps, and related data, such as tilesets.

- To play the new scenario, start the game normally with one exception: On the main menu, you must set the data ID corresponding to the new scenario before entering the game.  Otherwise, the default data ID 1 will be used, meaning the directory "DATA1", which is where the first pre-made scenario resides.

- You may optionally copy the "GameS1 - [NAME].bat" file, rename it, and modify it to refer to your own "DATA[NUMBER]\main.cfg" file.  You may want to call this file "GameS[NUMBER] - [NAME].bat", but only the .bat extension is actually required.  In any case, be sure to modify the contents of the new .bat file with your own data directory name; renaming the .bat file is not enough.  The DATA[NUMBER]\main.cfg file's DATASET entry should then be updated to refer to your data ID (the number).  The advantage of this step is related to the fact that some settings in the file must be used prior to displaying the main menu.  The settings in question include the default data ID and the way in which the window is displayed.  In particular, you won't have to change the data ID in the main menu each time you start the game.  You may also change things like if the scenario should run in a window rather than full screen.


Scenario elements

It is possible to alter or add to a very large number of scenario elements.  The following list is just an overview of the elements.  The specific details are available by looking at the pre-made data files.  The data itself will serve as an example, while comments (when available) help explain the parameters of each command.

- Tiles
- Maps
- Sounds
- Tile behavior
- Map behavior
- Map objects definitions (the creatures, locations, vehicles, items, etc. on a map)
- Dungeon "tiles" (graphics) and maps
- View map tiles (used for the overhead maps used when you use the "view" command)
- Game object definitions (the map-specific details of creatures, locations, vehicles, items, and NPCs)
- Terrain definitions
- Encounter tables
- Group definitions
- Treasure tables
- Triggers
- Scripts
- Effect definitions (general things that happen throughout the game)
- Store definitions
- Space definitions
- Scenario general definitions (such as the "win condition")
- Character starting information
- Class/race/gender definitions
- Screen/window layout
- A huge variety of details within each of the above categories.  For example, creature powers are defined within the game object definitions.


General notes

- All ID's are limited to 65535.  Any number exceeding that value will lead to an error.

- ID 0 is typically used to indicate a default value.  Do not attempt to use it as a standard ID.

- Error messages will typically be generated when there is a syntax error in the data.

- The most common error in working with the data files is not setting the buffers for the associated data high enough.  If something is not working correctly, make sure the number of buffers has not been exceeded.

- An extensive cheat system exists for purposes of scenario development.  This is unavailable by default, but may be activated by adding the setting "CHEAT: 1" to the scenario.dat file.  This will make a very large number of cheat options available via the F12 key and "free movement" available via the TAB key.  Any player activating the feature is knowingly cheating, so I see no reason to try to restrict this or hide the feature, as it is very useful (almost essential) for scenario development.  Note that the F12 key sometimes activates a system-level feature in some OS's (I noticed this when debugging the engine source code on NT-based OS's).  If this happens, hold down the control key while pressing F12 to avoid the system-level feature and reach the cheat menu.

- A few special editing/development tools (such as a dungeon graphic design tool, a bitmap import tool, and a sound testing tool) are available within the game itself.  At the main menu, the F2 key activates a special menu with the list of these tools.

- The concept of a tileset is actually divided up by the engine into the tile definitions (tileset) and the frame definitions (frameset).  A frame is a single image used in a tile animation, even if a given tile is not animated (in which case, it only has 1 frame).  A tile may refer to one or more frames stored in a frameset.  The vector engine uses the same basic techniques and the same terms even though a single graphical element is not in the form of an overhead-style frame (except when it is defined to indirectly use such an image).

- The overhead graphics are driven by the overhead tile engine, while the FP graphics are driven by the vector engine.


Additional details

- I wrote several separate programs that are entirely for the purpose of scenario design.  As mentioned above, there is an editor for creating or modifying tiles/graphics and maps.  A plugin system also exists that provides extra flexibility for scenario design.  The installs and documentation for all of those is separate.


Exposed data file comments

In some formal builds I have run the data files through a tool that strips out all of the comments and extra line feeds, as well as removing the extra return character used in some OS's (rather than just the newline character).  This is done for a variety of reasons.

One of these reasons is to avoid exposing comments that I do not want to share at this time, largely because given that they are very numerous and there are many that are extremely lengthy and detailed, I have not had the time to review them all for a level of quality appropriate for release.

Another reason is that it rather significantly reduces the size of the data.

Yet another is that although testing has shown load speeds of textual data to be very quick, it is still more efficient for the engine to avoid parsing comments, extra lines, and extra return characters.

However, this does introduce one issues: There are several references in this manual to there being comments within the data files that help explain how they are used.  Therefore, note that those comments may not be available in some builds.  The plan to solve this is to eventually make some of those comments available separately (possibly as part of a small set of selected sample data files that do get properly reviewed).


Game engine

As noted earlier, this game is carefully divided between the engine and the scenario data.

The term "engine" is actually used in two different ways.  The game engine is the program that reads the data files to make the game run in the specified manner.  The term is also used to refer to some specific sub-components of the game engine.  The "overhead engine" is the component that does things like display the overhead tile perspective graphics.  The "vector engine" is the component that does things like display the first-person perspective dungeon graphics.

The name of the engine has evolved.  It was originally called "TileMaster" (specifically, "TileMaster Engine (v2006)") and the data file headers still use this name.  That name dates from my first design ideas in the 1990's, refers to managing the visual display of game tiles, and is also a play on the tabletop RPG term "Game Master" or "Dungeon Master".  The name was changed to "GGame Engine" for a variety of reasons but the term has not been changed in the data files for the sake of compatibility.

As noted above, it is NOT necessary to modify the engine in order to create a new scenario or to alter an existing one.  The engine was designed to handle a wide variety of settings implemented within a variety of external scenario data files.  A number of customizations can also be made with the basic configuration files.  Several of the data file types support the use of a unique, built-in scripting language.  A plug-in system allows support for more complex modifications including the use of other scripting languages.


********************************************************************************
Data files
********************************************************************************

This information is with regards to custom scenario creation and not necessary to the play the game.

The later part of this section provides explanatory details for a small subset of the commands used in the various data files, as an example.  There are many hundreds of commands between dozens of data file types, and, as mentioned above, the existing data files are a more complete reference.  The information and examples there should be used as a starting point with the information here providing further explanation in some select cases.  For example, to understand the MAPSET.dat "M" command, refer to a MAPSET.dat file.  Then refer to the details given here.

Comments in the data files (when available) usually provide the details for the exact syntax available; that information is not duplicated here.

As noted above, map and tile files are binary data and require the use of the game's editor.  The notes here regarding data file commands apply mainly to files ending with the extension ".dat".


Data file types

Here's a list of many of the various types of data files used in the game (as the game evolves, new ones sometimes get added so this list is not necessarily comprehensive and up to date).  As mentioned previously, the details for the commands used in most of these are not provided in this manual, but there are many comments and examples (when available) in the files that implement the included scenarios.

classes.dat: Class, race, and gender definitions

cspells.dat: Complex spell definitions

dynmapdef[ID].dat: Dynamic map definitions (defines the layout of a dynamic zoom map, for example, for dungeon zoom-in combat)

effects.dat: Effect definitions

egroup[ID].dat: Creature encounter group definitions

enctab[ID].dat: Random encounter tables

Inc-[name].dat: Convention for files included by other files

map[ID].dat: Map definitions (creatures on the map, etc; everything beyond the *.map tile layout)

MAPSET.dat: Mapset definition (the list of maps and their core details, including the relationships between them)

objdefs.dat: Object definitions (many of the core definitions for the scenario, for example, that a creature named an orc exists and how powerful it is, etc.)

pc.dat: The basic definition of the PC and defaults

resistance.dat: Definition of resistance ID's used elsewhere

scenario[ID].dat: Scenario definitions (general definitions and various configuration defaults)

script[name and/or ID].dat: A script file (allows extremely flexible definitions using a fairly simple, high-level custom scripting commands)

space.dat: Space definitions (the layout of the planets and such for those scenarios that use a space ship)

SSET.dat: Sound set (sound definitions)

stores.dat: Definitions for standard merchant stores ("standard" meaning that some stores may instead be implemented using only scripts)

Terrain.dat: Terrain type definitions (define any terrain such as allowed terrain for the PC, NPC's, vehicles, etc., basically providing a cross-reference between the ID's used in other files use and the ID's given in TILESET.dat)

TerrainInfo.dat: Additional terrain definitions, although this currently only consists of speed definitions

TILESET.dat: The overhead tile set (defines the details of the tiles including the references to the files containing the actual graphics)

treasure[[ex]].dat: Treasure definitions.  The "ex" suffix is a temporary naming convention for the file referenced by a completely revised version of the original system.

triglist[ID].dat: Trigger list (a list of trigger definitions, triggers being events that are usually tied to specific map positions, although can also be referenced using some other methods)

VConfig.dat: Vector configuration settings (used by the FP engine to define general settings)

VFSET.dat: The vector frame set (used by the FP engine to define vector graphics, for example, what a dungeon wall looks like, etc.)

VTSET.dat: The vector tile set (used by the FP engine to define vector tiles, for example, the set of frames used in a dungeon graphic, potentially animated)

VMTILESET.dat: The view map tile set (details of the tiles used for the VIEW command)

VMATILESET.dat: An optional view map tile set specific to FP (VMTILESET.dat is the standard one)

zoommapdef[ID].dat: Zoom map definitions (what map is used and related details for a group combat map)


Other files

*.cfg: Configuration file (defines some basic details about the program, such as the type of window, resolution, etc..  Includes some things a player may want to configure.)

[ID or name].map: Binary map file (defines the layout of a map, edit using the editor program)

[ID or name].til: Binary tile file (defines the graphics of a tile or other image, edit using the editor program)

[ID].wav: Binary wave file (defines a sound, edit using an external 3rd party tool)

RDGen.dat: Used by the editor program only (not used when playing the game)

VFDisplay.cfg: Definitions used for the vector frame display tool (as with the editor, this is not used when playing the game)

flags.txt: List of flags.  Not used or processed by the game, but good idea for a scenario designer to keep track of the flags that have been used and their purpose.

TempObjs.txt: List of temporary objects.  Not used or processed by the game, but good idea for a scenario designer to keep track of the temporary objects that have been used and their purpose.  This may include temporary overhead frames, overhead tiles, vector frames, vector tiles, and sounds.


General

There are a few general conventions used in many of these data file commands.  These could also be called data file "definitions", but I use that terms in many other contexts, so the word "commands" is used here to prevent confusion.  Another possible term would have been "settings".

A command normally starts with a name such as "M", "BORDER", etc. then a ": ", then parameters delimited by spaces.  A command normally ends with the end of the line (line feed).  Double quotes may be supported or required for some parameters that support embedded spaces, but do not use them otherwise.

Some commands consist only of a single name without the ": " to activate a particular behavior.  I refer to these as tags.  The default for a tag is exactly the opposite of the name.  For example, NOVM prevents the View player command from being used on the given map.  Without the tag, it is not prevented.  Note that some tags actually may also work as a command in that they also optionally support the syntax WITH the ": ".  The NOVM setting used in the previous example is also an example of this, as it supports an optional power level (for example, "NOVM: 10").

Parameters are often optional and the line may end before they are all defined.  All of these have defaults.  For example, the M command's "EXIT" may take a position and direction, but these are optional and therefore may be skipped so that the defaults (0 offset and current dir) are used.

A few commands use sections.  Sections are ended with a ";".  For example, the M command has 3 sections (basics, view, and move) which are separated by semicolons.

Many commands activate or deactivate a behavior.  Unless stated otherwise, the parameter values available are 0 and 1.  When the value may be set to 0 or 1, the other value is usually also available.  I don't always state that in these explanations because the other value is often simply the default.  For example, maps are not set to dark by default, so the only value typically used is 1.  However, 0 would also be valid (although would not directly accomplish anything directly; perhaps clarity, preparation for any change in default, etc.).

Defaults often depend on the context.  That said, the default position is typically either undefined or 0 0 and the default direction (facing) is typically either to maintain the current direction or north.  In the case of optional commands and such, the default is usually 0, off, none, deactivated, etc., although occasionally it is on by default and settings would be used to turn it off, if desired.

The default value is not always the result due to other settings.  There is often a hierarchy and interconnection of various settings and conditions involved.  For example, there are many methods to define a map transition position.  A border definition may not define the specific destination position.  The last resort default is to use position 0 0, but the type of map transition may dictate something else, a map position defined in MAPSET.dat would first take precedence, perhaps an alternate position to try has also been defined, etc..

The script files follow a somewhat different syntax, but work on similar principles where doing so makes logical sense (many parameters are optional, etc.).

A number of pre-made data files include a header starting with the term "TILEMASTER".  Technically, the header is currently optional in most of the data files, but headers are a good idea because they help to clarify the file type to the programs that parse them rather than those programs having to depend only on other, more limited methods such as the file extension.  Further, they can include additional details such as a version number that can help with compatibility in later revisions of the programs that parse them.  Note that the term "TILEMASTER" is discussed in more detail elsewhere.

Lastly, note that the commands available or the details of an existing command (parameters, defaults, etc., and sometimes even the name itself) may change as the game evolves.  Keeping this information synchronized with the latest changes is not always feasible since there is a lot of information here, so is possible that some of it may become outdated.  The scenario files will typically be more complete and updated since they must match in order to function properly.  The information here is intended more as an example to clarify the overall approach.


MAPSET.dat commands

(New commands have been added and some other changes made, but this has been updated respectively as of this note.  That said, this could still become out of date at any time after this note as yet more changes are made.)

M: The primary map entry.  This starts a map entry, giving the ID.  The ID is used for numerous purposes, including determining the map and data files.  The default file name for the map uses the ID with a ".map" suffix, although a different file may optionally be defined here.  A map start position may also be defined, which may be used for some types of map transitions (the default is 0 0), usually when there is no other position defined for the map transition.

GAMEDAT: Reference a data file other than the default of the ID with a ".dat" suffix.

TEMPLATE: Apply the given map file as a template on top of the existing map.  Maps may be designed as templates by using tile 0 as the "pass through" tile (tile 0 normally is treated as a black "undefined" tile and is the starting value for every position in a new map in the editor).  They are still created as standard maps, simply designed for use as template maps by assuming that tile 0 will show the underlying map.  The intended purpose is to define multiple levels on top of existing levels when the underlying levels are visible, for example, the second and subsequent levels of towns with multi-story buildings and such (it is not an issue when underlying levels can be seen, such as in a typical dungeon).  To clarify, the template in such cases is the map that is on top, not the underlying map.  Any instance of tile 0 does not cover the underlying map so that it shows through.  Multiple template commands may be used to stack multiple levels on top of each other.  For example, if some elements of both the first and second levels were visible underneath the third level, then templates could be used for both the second and third levels.  However, this is not necessary if no elements of the lower map in question shows through.  Anyway, the mechanism is for convenience; the editor can instead be used to apply a template and that resulting map defined normally.  However, using the editor approach means that every change to lower maps requires the process to be repeated for all of the upper maps, so this command is extremely helpful in avoiding that by dynamically applying the maps together at load-time.

ALTSTART: A secondary starting position.  If the player cannot step onto the primary position for some reason, an attempt is made to use this position instead.  For example, if a player enters a location where the primary position is land but happens to be in a boat, this may define a position on water.  Note that there are other ways to handle this situation such as ENTERBORDER location objects (not defined in this file); this is just one method that is helpful for some map designs.

B: A map border entry.  There may be more than one entry to define differences between multiple borders, although each may also provide a single definition for multiple borders.  Border tokens: ALL, N, E, S, W, NE, SE, SW, NW (and more than one can be used for a single definition, although using ALL with anything else is pointless).  If a given border is not defined, defaults are instead used for the various values.

The view type is what is displayed on the squares across each border.  View tokens: DEFAULT, FILL [TILE], WRAP, ECHO.  DEFAULT will display the default of empty tiles (which, as the name implies, is also the the default when the view type is not defined).  FILL fills the view with the tile of the given ID.  WRAP displays what is on the opposite side of the map as if the map is wrapping around.  ECHO displays the edge tile continually outward.

The move type is what happens when a player crosses the border.  Move tokens: LINK [map] [x] [y] [dir], EXIT [map] [x] [y] [dir], WRAP, LINKWRAP [map].  LINK goes to the given map, position, and direction.  EXIT does the same except goes to the most recently-entered location and the x and y are an optional offset from that position, while the direction is absolute, but also optional.  WRAP goes around to the opposite side of the map as if the map is wrapping around.  LINKWRAP goes to the given map at the position corresponding to the opposite side of the map.  The default is that the border is blocked.

BSTART: Define a start position for the most recent border entry.  Depending on the type of map transition being used, this position may be used as the entry point to the map in question.

BMESSAGE: Define a message for the most recent border entry.  The message appears when the player attempts to cross that border.

BCSHIFT: Define a border collision shift method.  0 is none.  1-4 is a compass dir N and clockwise, and 5-8 is the same except reverse the left-to-right search pattern.  The optional "ALL" setting makes it apply to the entire map rather than the current border.  A collision shift will happen if the player enters a map onto an invalid square, usually because a creature has moved there.  When this is active, a search process will attempt to find an adjacent, open square.  The pattern is based on a direction (which is modified by the border crossed, with N being the base condition).  The typical setting is 1, which will cause a search based on N (and modified by the border used).  The first position checked is "behind", so for N that is S.  To reverse the search direction, use S, which is 3.  For example, the player exits a dungeon room in scenario 2 to the north, but an orc is standing on the exit position.  A setting of 1 would cause it to check behind him, to the S.  The room door is there and the position is open, so the player is placed there instead.  If the player had exited the room to the E, the same process would apply, except the position behind would automatically be set to W.

FP: This tag indicates that the FP draw engine should be used for this map.  Without this tag, the default is to use the overhead draw engine.  Note that this replaces a parameter-based command called "TS" that should no longer be used (and the plan is to remove it at some point), but it is worth mentioning since it will still show up in old versions.

DOTRIGGERS: This tag indicates that triggers should always be done when first entering this map (in some cases, they are not done by default).

DRB: Dungeon room border.  This is a shorthand, convenience command for designing dungeon rooms that could otherwise be defined using other commands.  The border should be N, E, S, or W.  The starting position follows this.

UDB: Defines an "up or down" border.  Use U or D.

UDBMAP: Defines the map ID for a UDB.

UDBSTART: Defines the start position for a UDB.

UDBEXIT: This tag indicates that the UDB should use the exit mechanism.

UDCBUFFERING: This tag indicates that the UDB should use the conditional buffering mechanism.  Map buffering is a mechanism which stores a given map in memory during a map transition rather than writing it out to the current save data along with doing the rest of the associated automatic save.  Such buffering is used for a variety of purposes such as dungeons that do not save in some scenarios and not saving prior to entering most dungeon rooms and combat maps and such.  Map buffering normally occurs only when particular grouping definitions match.  Condition buffering is a more flexible method to indicate that buffering should be used anytime a particular condition is true, such as when the map prior to the transition also defines that condition buffering should be used.  One use of this is for a multi-level dungeon room.


map[ID].dat commands

(New commands have been added, so this is out of date)

This file contains multiple sections: the header commands and sections for the 4 game object types.  Although these can currently be mixed together, doing so is not recommended since this behavior may well become unavailable in future versions of the game.

Note that these files are not only used as definitions for a game scenario, but also for saving and loading the game.  Parameters specifically designated as "save parameters" are typically used only when a map saves and then reloads, not by a scenario designer creating the map.  That said, it is possible that some of these may be useful in scenario design.


map[ID].dat header

SAVE: Enable or disable saving the game on this map.

MBUFFER: Enable memory buffering.  A map normally saves to the current game when it transitions to another map.  A map using memory buffering saves to memory buffer instead when a group map ID matches (use GROUP).  When the group ID does not match, the buffer is flushed.  This mechanism is often used to prevent saves but allow map transitions.  For example, the Ult. 2 dungeons should not save but the levels should not reset until the player re-enters.

FBUFFER: Enable file buffering.  This behaves the same way as memory buffering, except uses an external file instead of memory.

USECBUFFERING: Enable conditional buffering, which causes a map to buffer even when the secondary map has no map group ID.  This is necessary to buffer particular maps, and should be used on overland maps that use zoom-in combat.  Maps normally only buffer when their map group ID matches.  In this case, zoom-in maps will also buffer since they have no map group ID.

GROUP: Define a map group ID for the given map.  This can be used for map buffering.  Note that the map group and creature group are totally separate concepts.

UPMAP: Map ID of the map considered to be above this map, for example, the next level up of the dungeon.  The definition may be EXIT instead of an ID, which causes an exit map transition (for example, a ladder that exits a dungeon).  This definition may be used in a variety of situations.  It will be used by location objects in some cases, for example, a ladder (or whatever) defined in a particular manner.  It may also be used by spells in some cases.  Etc..

DOWNMAP: The same as UPMAP except downward.

EXITMAP: This is NOT analogous to UPMAP.  This is used in special cases to reset the exit map data to a given map and position.  Normally, the exit map is set automatically when an ENTER location is used.  However, there are cases where this information should be changed.  For example, a dungeon contains a portal to another dungeon.  If the exit location were not changed, then the exit from the second dungeon would be the wrong one (it would still be the exit to the first dungeon instead).  This issue would be resolved by setting EXITMAP on the map with the portal destination.

DARK: Define if a map requires lighting.

FOOD: Define the food rate modifier of a given map.  This allows some maps to take less food than usual.  For example, a town is smaller scale so may not require the same amount of food per turn as an overland map.  Note that this value currently also serves as the base value for other rates, as well, such as light usage, poison damage, and terrain-related rates (for example, water usage in a desert).

ENCTABLE: Define the random encounter file ID.

EGTABLE: Define the random encounter group file ID.

AIMOVETYPE: Define differing movement types for NPC's.  1 is the default, very simple, and authentic to Ult. 2.  2 is similar but uses random selection for which side to move towards, making it a little less predictable.  3 attempts to move around barriers, but movement may appear somewhat erratic as a result.  4 is better at moving around barriers, but the process is much more complex and not optimal for some maps.  5 is used for maps where the zoom-in representation of vehicles may be attacked.  6 is a new, enhanced, more complex version of 3.  Basically, the type that should be used should be based upon whatever is most appropriate for the particular scenario and/or the particular map.

AIATTACKTYPE: Define differing approaches to combat for NPC's.  NORMAL is the default.  CLOSEST attempts to detect and attack the closest enemy, and is required on maps that use PC allies.  ZOOM attempts is used when a creature attacks as a group, meaning it is used for maps that lead to zoom-in combat.

AIATTACKMAPVEHICLE: Set to 1 to allow creatures to attack the PC's vehicle on a zoom-in map.  A creature will attack the vehicle if they cannot attack or move towards the PC.

RANGEDATTACK: 1 or 0 to allow or disable ranged attacks on the map.

NOREPGROUP: No repuation group, a game object group ID that does not cause any change in reputation.  Normally, if a player commits a crime, it changes their reputation.  However, if the crime is commited against this group, it will not do so.  For example, all the guards on a map are enemies (perhaps guards in an evil prison) but there are also some good NPC's on the map (perhaps prisoners).  If the enemy guards are all in group 1 and that is set as the NOREPGROUP, then the good NPC's won't be affected by any crimes against group 1.  Without that, the good NPC's may react negatively with regards to reputation, such as no longer talking to the PCs.  Note that all map defenders will still attack.  Also note that an alternative is the NPC NOCHECKREP tag, but there are cases where this is a better choice (for example, the area will be altered from evil to good, but then NOCHECKREP would no longer be appropriate).

RANGEDRETREAT: Enemies check to retreat if they cannot attack or move and the PC is attacking at range.  For example, the map is a zoom-in combat map between land and sea, the PC is fighting an enemy without ranged weapons (perhaps scenario 2 sea serpents but no ranged sea dragons), and the PC is standing back from the shore and attacking at range.  The sea serpents will retreat rather than just sitting there waiting to be killed.  This behavior can cause problems in some cases, so it must be activated explicitly for maps where it is appropriate.

TRIGGERLIST: Define the trigger list file ID.

STARTSCRIPT: Define a script file ID to run when the map is loaded.

TURNSCRIPT: Define a script file ID to run each turn.  A normal script runs only once.  A turn script continues to run as long as it uses commands such as WaitTurns.  For example, the Ult. 2 scenario uses a turn script to control the portals and scenario 2 uses a turn script on a particular map to control the continuing power of a special monster.

NOVM: No view map, which prevents the View command from operating on this map.  An optional power value can be specified, in which case the source of the magic used by View must have a power value that is equal to or greater than this power value in order to operate.  The value allows some maps to be more powerfully enchanted against view-related magic than others (which then also allows for some view-related magic to be more powerful than others).  If the value is not specified, then NOVM is absolute, in other words, View can never be used on this map.

ENCCOUNT: A save parameter, encounter count, which tracks how many random encounters have been created for the given map (used in determining the maximum number if that is used).

CRTURN: A save parameter, creature turn, which tracks the current creature turn if they are incomplete (such as due to a group attack that leads to zoom-in combat).

PCREP: A save parameter, PC reputation, which tracks the PC's reputation on a given map.


map[ID].dat creatures

Note that these are only the commands available for specific instances of these creatures.  There are a huge number of others available in the base creature and NPC definitions (located in objdefs.dat).

CLIST: Begin the creature definitions.  Optionally define the list size, which is helpful for large lists.

C: Creature definition.  The ID can be set to a specific value, in which case the command should be placed before those that are auto-numbered (or the AUTOID command can be used to reserve the value).  ID 0 is used to auto-number the ID's when the ID does not matter.  The ID can be used by any of a number of mechanisms to reference the particular creature.  The creature type refers to the base type defined in the object definitions.  The start position is also defined here.  HP may be set to a specific value or, most often, 0 to indicate the maximum for the base type.  NPC type may be set to refer to the NPC base type defined in the object definitions.  Disposition defined here will override the disposition defined in the base creature or NPC type.

ANCHOR: The position that a given NPC will not wander from by more than the NPC anchor amount.  This is a separate value from the creature position because that may change during the game and then be saved.

AGRO: Aggravation distance.  When the PC enters this range, a hostile creature will switch from waiting to attacking.  This allows maps to include encounters that do not occur until the PC gets closer.

RETREAT: A save parameter, retreat count tracks how far a creature has retreated so far.  In authentic retreat mode, a creature retreats a particular distance then begins attacking again.

DELAY: A save parameter, turn delay tracks any remaining turns that must still be skipped.  Delays may be caused by any number of conditions, including a delay after some types of lengthy attack types, a delay caused by a magic effect, etc..

CONDITION: A save parameter that tracks any adverse condition on the creature (see "Adverse conditions", above).

GROUPID: Creature group ID, used for a variety of purposes, but most frequently to define items that a creature will defend.  For example, a creature in group 2 will attack a PC who gets a treasure chest in group 2.  Creatures in a group will defend others members of their own group as well as any items or vehicles in the group.  Note that group 1 is often reserved for general defenders.  NOREPGROUP also uses the group ID.  Note that the creature group and the map group are totally separate concepts.

ATTACKTARGET: Defines the attack targets for the creature.  Note that this particular command provides a means to define all of the targets in one line, which is helpful for for save/load, but is less clear for scenario design than specific commands that do the same thing (refer to the following 4 commands).  A creature may attack the PC and his allies (used for standard enemies), everyone (useful for extremely hostile NPC's), enemies of the PC (used for allies), and/or creatures defined as defenders (can be used to stage large-scale NPC battles, such as an attack on a settlement).  Since combinations may be used, this allows a great deal of flexibility in defining who will attack who.  Many behaviors in the game automatically set these values.  By default, a creature will target only the PC/allies by default and an ally will target only enemies of the PC by default.  An angered creature will add the PC/allies to his targets.

ATTACKSPCS: Attack the PC and his allies.

ATTACKSPCENEMIES: Attacks enemies of the PC.

ATTACKSALL: Attacks everyone.

ATTACKSDEFENDERS: Attacks creatures defined as defenders.

DEFENDER: Designate the creature as a defender.


map[ID].dat vehicles, locations, items

These sections are not yet detailed here.


VFSET.dat

(New commands have been added, so this is out of date)

This stands for "vector frame set".

A frame is one static image used by a tile.  A tile (defined in VTSET.dat) may use one or more frames.  If it uses more than one frame, the tile is animated.  This is the same as with the overhead raster graphics (although in that case both are defined in TILESET.dat).

Vector graphics are used for first-person maps.  The commands are extensive and sometimes complex, and therefore require some further explanation.  See the frames from the included scenarios for examples, particularly since new commands are sometimes added and may not always be documented here, changes may be made to commands without the documentation here being updated, etc..

Note that commands such as COLOR will be effective within the same frame until another color is selected.  Also note that such commands typically have a default and do not have to necessarily be set.

Note that conditional commands do not nest, with the exception of chaining conditions together by using CELSE.  The purpose of conditional commands is primarily for subtle differences like rounding adjustments at differing scales and lines that should only be drawn at a higher scale.  For larger differences, the tiles should refer to entirely separate frames.

LINE [x1] [y1] [x2] [y2]: Draw a line from position 1 to position 2.  The TYPE command can be used: Type 1 means round each flat segments (if any) the opposite direction.

PIXELS [[x1] [y1] [... [xN] [yN]]: Define from 1 to N pixels to draw to the screen.

IMAGE [filename]: Include a raster image.  The image must be in .til format, created in the same manner as a standard overhead tile (but has nothing to do with any overhead tileset).  The TYPE command can be used: Type 1 means reverse the image horizontally.

VFILL [x1] [y1] [x2] [y2]: Draw a verticle fill from the given line position to the next line beneath/above it of the same drawing color or the bottom/top border.  This is intended for a starting line that is more horizontal than verticle (or equally so); otherwise, the line edge pattern is slightly different than a typical line.  The TYPE command can be used: Type 1 means fill the opposite direction.  Type 2 means that for the start position line, round each flat segment (if any) the opposite direction.  Type 3 means do both.

FRAME [ID]: Include another frame in the current frame.  This allows building frames from more basic frames without repeating their definition.  For example, a standard door may start with a standard wall.

COLOR [red] [green] [blue]: Set the current drawing color.  Values should be 0 through 255.  The default is white (255 255 255).  For example, "COLOR 255 0 0" will set maximum red.

REV [x1] [y1] [x2] [y2]: Reverse the screen coordinate starting and ending reference points of lines (including the VFILL line).  Each value must be 0 or 1.  0 indicates the left or bottom, 1 the right or top.  The default is left and bottom (0 0 0 0).  For example, to draw a line starting 5 pixels from the right side of the screen instead of 5 pixels from the left side, set x1 to 1.  This is useful for defining positions symmetrically, particularly when a frame is scaled down automatically as the FP distances increase.

SCALE [x] [y]: Set a scale factor.  This is in addition to the scale factor already included as FP positions change.  The default is none (1.0 1.0).

OFFSET [x] [y]: Move the position by the given amount.  This is in addition to the offset already included as FP positions change.  The default is none (0 0).

RA [x] [y]: Apply a rounding adjustment to the given position.  Rounding adjustments can be found by using the DEBUG command prior to the drawing command in question, most appropriately within the vector frame tool.  This allows adding a fixed decimal amount to the coordinate to shift it into a preferred position when it is scaled down.  The value will apply to the start and end positions.  Also use RA2 if the end positions differ.  The default is none (0.0 0.0).

RA2: Same as RA but applies to the end positions only and will override RA for those positions.

TYPE [value]: This can be used to specify an optional change in behavior to several commands, as listed with those commands.  The default is 0.  Note that, like most similar commands, the value will persist, so be sure and set it back to 0 (or whatever value is needed) before using another command that supports it.

CSCALE [x] [y]: Conditional; do the following block only if the total scale factor is >= to the given amount.  As with rounding adjustments, the appropriate scale factor can be found by using the DEBUG command.

CEND: End a conditional section

CELSE: Else block for a conditional section

DEBUG: Display textual information about the next line.  Unlike most commands, this state is reset after use; it does not persist.


Many more details for various data files could be added here, but for those that aren't detailed here, remember to look at the comments and examples in the various included scenarios (when available).


********************************************************************************
Data contributions
********************************************************************************

[This section was written many years ago and I am leaving it in place just for future reference and to be proactive; I am not prepared for any data contributations at this time.]

Although I worked very hard on my own tiles and am happy with most of them (even though many are fairly primitive), I am not a graphics artist and if anyone would like to consider contributing one or more replacement default tiles, please feel free to do so.  While I'm not currently seeking any help with this (this section is just about trying to be proactive in case it comes up), it would still definitely be appreciated.  That said, please contact me prior to doing so to make sure we are on the same page before putting effort into it.

Note that this section is talking about contributions to the game as I am making it available myself (meaning, I would include the contributions as part of the game as I distribute it).  It is NOT talking about any 3rd-party changes that are made available separately as mods and such (which are, of course, entirely up to the author).

Anyway, in making any data contributions, please keep the following guidelines in mind in order to keep things consistent:

- In changing tiles such as those used by scenario 2, I'd really like to maintain a constant look and feel between those in a given tileset; the altered tiles should not look vastly different in style from the rest of the existing tiles.  It would probably be fine if that means multiple tiles are updated to keep them consistent, but it would be better to avoid any that look out of place with respect to the rest.  For example, if my scenario 2 tileset bench tile (which I've never been entirely happy with) was replaced by a better version, then the style should still look consistent with respect to the other tiles in the tileset (even if it meant that a few more tiles had to also be altered to do so).

- I prefer consistency between colors in lower-resolution graphics, meaning, using the same colors throughout the tileset and using as few as possible.  Therefore, the best colors to use in an existing tileset are those that are already used by other tiles.  So it would be preferable not to introduce 20 new shades of green, for example :)  An example of this approach is how scenario 2 currently uses a fairly limited number of colors between all of its tiles even though it does not technically have to do so.

- This engine supports 32-bit color, high resolution graphics, and a larger number of animation frames than I typically use (such as 24).  However, again, please do not use anything that would look out of place with the rest of an existing tileset.

- Dimensions (width and height) should not be altered within an existing tileset since doing so is not possible except by creating a complete replacement tileset.  For example, scenario 2 uses 10x10 pixels and would not be able to support anything else without replacing ALL of the existing tiles.

- I'd also prefer to keep the number of animation frames consistent.  For example, scenario 2 currently uses 1-2 most of the time.  Introducing a new one that used all 24 may look out of place.  For replacement tilesets, note that the any evenly-divisible value of 24 is available, meaning: 1, 2, 3, 4, 6, 8, 12, and 24.  Anything above 24 will not work, and anything not divisible will not behave correctly (the animation will sometimes skip frames).  Note that I may make this number configurable in the future (there's no reason it has to be 24, just that it has been a good default to be hardwired for the time being), but scenario 2 would probably continue to use 24 for the default tileset.

- A complete replacement tileset is fine.  For that, a totally different style could work since it would theoretically then be consistent within itself (all tiles in the tileset changed so that they all match).  For example, I've sometimes wondered if I would have been better off using a slightly larger size for the scenario 2 tiles rather than 10x10 (I originally had picked 10x10 because I thought it would make it easier for me to design more simple tiles).  That said, anything very high resolution, etc. would probably best be made available as optional rather than the default since the intent is not to by default look any better than the early CRPG's from which these were inspired.

- In creating a complete replacement tileset, be sure not to forget about temp tiles (those that are NOT part of the standard tileset but that are created by scripts to exist temporarily only for a particular situation).  The temp tile sometimes still have files which are in the scenario data like the standard tiles, but these are NOT referenced by the TILESET.dat file.  An example of a temp tile is scenario 2's arctic embankment N (currently 1000.til) that is created only when it is need for a few specific maps.  Also keep in mind that the scripts that create composite temp tiles would also need to be modified to properly correspond (these are temp tiles that are created by referencing other tiles or pieces of other tiles and as a result often do not even have any unique file associated with them), although I may be able to help with that myself.  An example of a composite temp tile is when the head of the PC is copied and pasted from the PC tile onto the bed tile when resting in a bed in scenario 2.  The scripts that do these operations sometimes need to understand the exact sizes and positions and such within the given tiles to do so properly (although in other cases, such as rotating a tile, this is not necessary).

- I do not want to change the Ultima II tileset, although would be happy to include an optional version.  That said, I have made a few non-obtrusive changes in that tileset (such as animating the sea serpent tile's water or including things like different-facing doors in scenario 1) and so that sort of thing is fine.


The dungeon graphics are essentially the same guidelines as for overland tiles, with the following differences:

- I am fairly happy with my high res dungeon graphics (meaning, those used in scenarios such as scenario 2).  Therefore, if you want to contribute a change to that existing tileset, it would probably be best to check with me first and maybe even give me an example of what you are planning.  That said, this is referring to a change to the existing graphics, not any complete optional tileset.

- The high res dungeon graphics use a variety of techniques to save memory.  Please refer to the existing graphics for specific examples, but to list a few general examples, some walls mirror each other, some graphics are built from composites of other graphics, etc..  While memory use issues in this engine should not be an issue on modern machines, I have still been carefully considering such issues in order to be closer to the approach the early games used (in theory, I should be able to port this to DOS, even if I never do so).  That said, any high res graphics optional tileset that requires a large amount of memory is fine; mainly, I just want to be consistent within existing tilesets.

- The high res dungeon graphics do not need to be limited regarding the use of colors, since they use shading and such

- The high res dungeon graphics that are animated sometimes use a higher number of animation frames than typically used for the OH frames


I would be happy to give credit to the author of any contributions.  Although I have absolutely no intention whatsoever to try to make a profit from this game, and although I doubt anyone would ask, it is probably best anyway to proactively clarify that I cannot provide any payment for contributions; this is intended as a free project.


********************************************************************************
Potential future work
********************************************************************************

There is a saying that goes something like "art is never finished, just abandoned".  This is something I really understand given that I have a huge number of other things I'd still to do on this game.

But here are just a few things that may be of particular interest:

Scenario 2

- Implement a few non-obtrusive enhancements to character creation to make it more user-friendly
- Complete a few unfinished areas
- Finish implementing the rogue class
- Further fine-tune the balance of some enemies and such where I'm still not satisfied (for example, for enemies perhaps higher HP for more granularity but with a lower AC and attack to compensate, making it harder to kill them in one hit but not necessarily making them more difficult overall)
- Implement more quests
- Implement more areas


Scenario 1 and 3

- Turn these into real scenarios (not just demo's) by finishing at least the most essential unfinished details such as replacing the placeholder numeric values used in the data with real, balanced values
- Make the internal mechanisms for things like stats vs. combat and such work authentically (the existing approach would remain but become an optional feature selected by scenario and would still be used by scenario 2)
- Implement the details of the final battle in scenario 3
- Check and make more authentic various details of scenario 3 that may still need work
- Animate the starfield in scenario 3


General

- Revise the interface so that the key and result are not hardwired but rather mapped per scenario and/or user option.  For example, scenario 2 does not use the "Hyperspace" command, so the "H" key could be remapped to something else such as "Hole Up and Camp" (which could invoke the "rest" command).  Also, this would further distance the interface from being beholden to supporting scenario 3.
- Finish implementing the multi-character party system and integrate use of it into at least one scenario


A note :) about music ... (sorry, silly joke)

Music can sometimes get a little repetitious in computer games, so when I play a computer game, I often tend after a while to turn it off and listen to something else.  That said, one enhancement that I MAY end up doing at some point is adding some more music (in some ways, it makes too much sense not to do so because I both write and perform music).  On the other hand, I didn't have the ability to listen to computer game music until many years after I played the older-style games on which this game is inspired (I got my first sound card much later), so it could feel out of place in this game.  So I'm not sure whether or not I'll pursue this.  (With all that said, now I feel like I have to point out that some of the games I've played have absolutely fantastic music in them such as Ultima VII, Morrowind, etc.).


********************************************************************************
About this game
********************************************************************************

This is a computer role-playing game written in the style of 1980's games of that genre.  The game is written to reflect depth of gameplay rather than focusing on things like graphics.  Games from that era did not have the luxury of fancy graphics and such.  Instead, they depended on depth of gameplay.  The best among these was, by far, the Ultima series of games, which emphasized non-linear play, exploration, strategic turn-based combat, puzzle-based conversation, and immersive interaction.  Most games since then have unfortunately veered away from depth of gameplay (with a few notable exceptions), and instead relied only upon flashy graphics, linear gameplay, action-based combat, spoon-fed conversations, and limited interaction.

What I have been creating with this game is a game engine that builds upon the early 80's style game, but attempts to add more depth and choices, and the ability to create scenarios.  I am not opposed to enhanced graphics and such in and of themselves (and, in fact, this engine will support high resolution graphics), but I decided to instead focus my efforts on features of the engine that support depth of gameplay and customization.

This game was carefully constructed to consist of two distinct components: an engine that can support various scenarios, and the scenarios themselves.

I started creating this version of the game in 2006 and finished a reasonable version in 2009 (although versions since then have been significantly enhanced).  However, I worked on earlier ideas, tools, and prototypes off and on in years prior to that, as early as 1992 or so when I was still in college and created a map/tile editor in assembly language along with a number of tiles and a few maps based on my tabletop RPG campaign.  In fact, some of the data included in this game and the editor package dates back to designs done in those early years.

Due to my interest in early game design, I made the decision to write the engine using techniques that would allow running this on very old machines.  Everything is written from scratch except some very low-level API calls.  Even the ability to display text (scrolls, wraps, has a buffer, etc.) is written in a manner that uses nothing more than displaying characters at a given position on the screen.  This design makes it feasible to port this engine to DOS or another OS without nearly as many huge changes if I ever wanted to do so (and I had originally planned on supporting DOS rather than just Windows).

To expand further on the design for anyone interested, the engine is written in C++.  As mentioned, everything in the engine was written from scratch.  Everything is implemented as part of the main game engine; no 3rd party code is used or called by the engine aside from a few very low-level API calls provided by the OS and some example code I used as a guide while implementing the low-level aspects of the sound system.  All of the game mechanics implementation, the overhead display engine, the vector display engine, the text display system (even word wrap and scrolling), everything that reads/writes from/to the various data/config files, everything that sets up the window/screen and layout within it, all of the syntax for all of the data/config files, the scripting language, the vector frame language, the format for the map and tile files, the plugin system, the separate tile/map editor, etc., were all designed/written from scratch.  I decided to write everything from scratch in order to have total control over everything, maximum flexibility, the best efficiency possible, a small install footprint, a design conducive to porting to other OS's, and simply because I was interested in how to implement each and every aspect.


********************************************************************************
About the author
********************************************************************************

I first played the Ultima series and many other computer RPG's in the 80's.  I began playing the Ultima series around the time Ultima II or III was released.  Ultima II was the first of these I played.  While I had played some action/etc video games for a few years prior to that, it was Ultima II that really got me interested.  I later played the rest of the series, finding Ultima IV to be the best game ever made (and that still holds true to this day).  In fact, I ended up becoming a software engineer entirely due to my love of these games; I wanted to know how to do that!  Many years later it is great to think that I have finally come full circle and been able to write these games largely due to the things I have learned.  I have had a great deal of enjoyment writing this game and hope others enjoy playing it.

I am also a big fan of tabletop RPG's, particularly AD&D 2nd edition (due to the raw creativity and overall style of that edition).

My favorite movies are the Lord of the Rings and the original (unmodified!) Star Wars movies.  My favorite TV series is Star Trek The Next Generation.  My favorite books are the 2 original Dragonlance trilogies and the Dark Elf series.

I also have some unrelated hobbies such as music and hiking, but I should probably not get into all those because I'd be getting even more off-topic for a computer game discussion and I'd end up going on and on and on ... :)  (I may have put some music-related stuff into scenario 2, though ... :) )

Of other computer role-playing games, I've also particularly enjoyed Morrowind, Oblivion, Baldur's Gate, Planescape, Fallout II, and Neverwinter Nights.  As good as those were, I think some of them would have benefitted from a less action-style interface, however; I still miss the early Ultima style: strategic, turn-based combat, keyword conversations, etc..

As indicated above, it is my wish that turn-based, single-player, non-linear, conversation-heavy games will someday make a comeback.  This game is my contribution.

(By the way, the cats in scenario 2 are based on real cats, even the really weird one, Pixel, my most recent cat, who is even more weird than his digital representation here :) )


********************************************************************************
License-related issues
********************************************************************************

Since this is a niche game designed in an old style, I doubt that this section is necessary.  That said, it should only take a few minutes to clarify this issue, so I will do so, anyway.

I have no plans to sell this game.  This version and all older versions are free.  And of course, no one else should sell my game.

I'd be very pleased and honored if there was enough interest for someone to create 3rd party content for this game.  In fact, as mentioned above, scenario design and modification is directly supported as a major part of the game's design.

There is no problem with someone using this engine to create and distribute 3rd party content for this game such as custom scenarios so long as they are at no cost.  Standard 3rd party scenario packages, mods, etc. are all typically separate from a main computer game install package so there's probably not much more that needs to be said than that.

That said, if for some reason any other approach is used (although this seems very unlikely), then the following points become more important to clarify:

My own install package should always be required.  Do not distribute any of the content of my game in any other way.  If there is a reason to do otherwise, contact me for further discussion.

Always include the credit for my having created the engine, custom scenario mechanisms, and any original data that is used.  For example, the main menu may well indicate the scenario author, but should still say "by Gary Arndt" for the credit of the main game.  Do not remove my name from the engine or related data.  Any distribution information (web page or whatever) should likewise also list my name front and center, so to speak.

A copy of this document should always be part of the install results, particularly since it provides upstream credit.

Although it seems very unlikely this would ever happen, I should also mention that if a scenario author believes that he or she could create a commercial (cost-based) scenario using this system, then contact me about it for further discussion.  If you do not wish to contact me or I cannot be reached for some reason, then any scenario or other product relying on any portion of my game must be without cost and require my own install package (as discussed above).

As stated in the "Credit" section, I have used a few concepts for this game from other sources, which I have carefully listed.  Any misuse of this game by a 3rd party (attempting to sell it for profit without permission, etc.) does not represent any intent on my part to misuse concepts from other sources.

Likewise, concepts that are used from my game should list my name in the credits.  Please attempt to contact me before doing so, as I should be made aware of this.

Again, this all seems very unlikely but I just want to mention it to be proactive.

Thank you.


********************************************************************************
Credit
********************************************************************************

I wrote all the code for this game from scratch.  Likewise, I created almost all of the data from scratch other than the Ultima II demo scenario's hand-translated tiles, maps, sounds, and NPC text.

Ultima II is a game by Richard Garriot of Origin Systems, Inc.

The use of some concepts from Ultima II and some tile, map, sound, and NPC text data is not intended to violate any licenses.  This is a non-profit fan effort.

Although this game was written from scratch, a few features of this engine and some of scenario content used the Apple IIe version of Ultima II as a template.  However, no Ultima II code was copied, hacked, or otherwise used directly.

The Ultima II tiles that were created were translated pixel-by-pixel by hand from the original, Apple IIe version of the game (including some corrections and minor enhancements).  The Ultima II maps, sounds, and NPC text were created similarly.  This engine supports any variety of tilesets, maps, sounds, and NPC text and does NOT require the Ultima II tileset, maps, sounds, or NPC text.  The purpose of translating them was to allow the creation of fan scenarios based on Ultima II such as the one I have included here (scenario 1).  Another scenario included here (scenario 2) demonstrates that NO Ultima data is actually required and that the engine may operate in a vastly different manner from that game depending on how a given scenario is configured.

The optional enhanced FP graphics for scenario 1 include several creature images that were painstakingly colorized from various mono sources.  These are entirely optional and intended only as a demonstration.  The other enhanced graphics (such as the doors and walls) are enhancements created from scratch upon the original versions.

A single sound (the long crash in scenario 2 used for a cave-in, storm, etc.) was modified based on a free public domain source.  All other sounds are original recordings (including my performing some brief music).

A very few select concepts from traditional table top role-playing games are used here.  These are generic RPG concepts used without special licensing for many years in a huge number of computer and tabletop games.  However, an open gaming license for one particular implementation can be found at http://www.d20srd.org.

This is also probably the place to mention that I have carefully and purposely stayed away from looking for comparable projects; I have no wish to negatively impact my enthusiasm due to competition nor to be influenced in any way by any other similar projects, should they exist.  Therefore, if such projects exist, I have no absolutely no association with them, influence from them, nor even any knowledge of them.

Lastly, I'd like to emphasize my deep respect for the original Ultima series and for Richard Garriot and the others that created it.


********************************************************************************
Disclaimer
********************************************************************************

All the original content of this game was written in the style of a tradition computer RPG over the course of several decades with much of that content having being written or planned many years ago.  Very little content is based on anything intended to represent any particular real-world situations and NO content is by any means intended to offend anyone; please do not read too much into the content or attempt to draw too many real-world parallels with this work of fiction.  That said, there are a few limited exceptions, for example scenario 2 DOES in fact have an environmental theme, although that story was designed in the mid-2000's so does not represent any real-world events since then.  However, details such as various NPC's generally do not represent or parallel any particular individual(s) or background.  Also, for the sake of simplicity and in parallel with most older computer RPG's, the PC and NPC designs neither exclude nor attempt to specifically include all of the many varieties of people in the real world; any PC or NPC can fit whatever details anyone imagines as they play the game.  And given that this game was intentionally designed to be modified as desired, custom PC tiles, NPC tiles, NPC dialog, etc. could even be added/altered if anyone wanted to modify those aspects of the game.


********************************************************************************
Contact information
********************************************************************************

TBD; I am still considering the best method for this.  In the meantime, you may be able to contact me through a forum where I may have announced a public release of this game.
