Project TavernMaker
Documentation version 1.0 ,
2003-10-18
How TavernMaker works
The following text will give you good overview of what is going on in TavernMaker. It is a good starting point to understand the program.
If you look for detailed information, you can go straight
away to the algorithm description.
Databases vs. Pure Random GeneratorsTavernMaker does
not really "generate" any graphic or text. Instead it uses
several databases and graphic templates and randomly assembles its
text and graphic output from that information. User-input restricts
the selections, so that the "generated" output fits to the
wishes of the user. The disadvantage of this system: A lot of work
is needed to produce big enough databases. The advantage: All work
is manually created by creative people, which increases quality dramatically
compared to pure random generators which barely mix adjectives and
nouns. Have a look –
a schematic overview
This graphic shows
you schematically how the different programs of WinTavern work together.
Show image Different systems
– the RPS
To keep TavernMaker
open to different languages, roleplaying systems & worlds as well
as completely different generating purposes, the program is very general
and needs configuration files, that tell the program what to do. Such
files are called "Role-Playing-System"-files, or RPS in
short. Each RPS has its own databases, templates, language etc. The
original basic RPS is "AD&D – English", which
generates taverns according to the AD&D standard fantasy world
with English descriptions. A first step –
decisions
Besides the chosen
RPS, WinTavern uses user-input. Generally speaking, a user can choose
the following: The exact meaning
of those settings depends on the RPS. The values in the braces are
those of the standard tavern-generators.
Graphics –
doing the map
In
a first generating step, the basic
type and the size is
used to select a fitting template.
A template is more or less an "empty room" with several
possible backgrounds which are filled with hotspots.
First, one of the backgrounds is chosen and then the hotspots
are filled with icons. (tables, bars, doors, windows etc.) The map
is then returned as graphic output.
Texts – filling
the map
The map generator
returns a map and a list of
filled hotspots (filled with an
icon, e.g. a table). Now some of those (depending on the business) get a description, too ("the tables are used").
According to the hotspots type (a table? a bar? etc.) the databases
are filtered. Then the restriction
(pricing class) and the population
chance (races) restrict the possible descriptions even more. Finally,
the map itself evaluates its icons ("Is there a window near the
table?" etc.) and this information restricts the possible descriptions
even more. From the remaining descriptions, one is chosen for each
"filled hotspot". Descriptions –
for all, or not
Now each "description"
in the database consists of two parts, a public
and a secret one. The public
part (the "description") is what the gamemaster may read
out to the players. ("At this table sit...") the secret
part (the "pick-pocket-list") is put in a separate output
file and is for the gamemaster only. ("The man has a magical
amulet which...") Menus – want
something to drink ?
The menu generation is not yet implemented in the first release version, but it will work similar to the description part. According to the user-settings it will select certain drinks/meals to create a menu out of it. Prices and quality will then be calculated. Formatting –
make things nicer
The text-output
is not only printed as ASCII text, instead the user can select (and
create!) some output-templates to format the output
as a rich-text file (RTF), which are simply nicer and maybe better
structured. Additionally, such
output-templates can be used to display additional information which
was created in addon-scripts. (e.g. a weather forecast) Scripting –
simple programming within the program
All the things told
above make up a nice program capable of a lot of things. We, however,
went a step further and added a lot of additional flexibility to the
descriptions in the database. Those descriptions are not only simply
texts, but may also use a kind of scripting language. Certain words
or numbers may thus be "randomised" and the concept of variables
and calculations as well as separate "item databases" allow
for a maximum of variances in each description. A simple example:
In a description one may read. "The man at this table tells
you the latest news: The king has been murdered!". This would
be a nice description, but it can be made even nicer, by replacing
the actual rumour with a randomly chosen one out of a "rumour-database".
If we create such a database, we would have added a "rumour-generator"
|
