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 Generators
TavernMaker 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 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"
even without changing the program. We hope that users will develop
a lot of such "add-ons".
even without changing the program. We hope that users will develop a lot of such "add-ons".