...and the villains they fight are monsters. This is, of course, an over-simplification since players can also fight each other, if they are Player-Killers or on a 'dangerous' map. But let's stay laser-focused on the basics.

When a new player experiences your world for the first time, they must create a hero character from a list of character classes which you provide (warrior, wizard, etc.) You define those character classes in the levels table. (usually inside of the file levels.txt which is #included by quest.txt)

The levels table defines, for each character class, the starting abilities of such characters, the maximum capabilities, and the funny names to be used for different levels. (a level 1 Fighter Class character might be a "baby" or a "weenie" or, if you're a more serious type, a "student")

Use the /q editor to modify this file. (type "/q levels.txt")

You will probably to start with a copy of the evergreen levels.txt file and then copy and paste to get the classes you want. This file is also loaded with detailed comments as to how the tables should be laid out.

WoS characters start out at level 1 and can level up to 100. You can define a unique level-name for every level or, like most people, only change attributes every 10 levels or so. (Missing lines are considered to be 'the same as the line before them'. So if you define a level name for level 10 as "padewan" and level 20 as "adept" then levels 11-19 will also be called "padewan")

Each class definition may include up to 100 level-lines. The first line (line zero) is special as it defines some extra characteristics of the class. After line zero, but before line 1, you can optionally add some special commands which might identify what items or tokens a new character in that class is born with, where they first appear on the map, what their starting special skills are, etc.

You can not include these commands later in the table with the hope they will not take effect until that level is achieved, cool though that might be.

For example, the rows for 'class 7' (every class has a unique ID#) would have this sort of structure to it:

0700, <special information about class>
SPECIAL_COMMAND
ANOTHER_SPECIAL_COMMAND
0701, <information about level 1 of the class>
0702, <information about level 2 of the class>
...
0799, <information about level 99/100 of the class>

Note that the number at the front of the line is a 2-digit class ID and a 2-digit level number all mushed into a single 4-digit number. The top 2-digits will be the same for every row of a given class. And each class needs a unique 2-digit number there. For example 1203 would be class 12, level 3.

Check the comments in the levels.txt file for the allowed class ID range. Currently it is 1-88.

Designer Tip: To check for errors in your character class definitions (it's pretty easy to make mistakes in this file), type /funpak to open the funpak diagnostic window, then type /reload to reload your quest file. If you have obvious errors in your tables they will be reported in the funpak as the file is loaded (be sure to save your changes before typing /reload of course!)

The most common error is to copy and paste one class to make a number, but not remember to set the 'class number' in every line of the new class's definition.

Class Balancing

If player-killing is going to be a big deal in your world, you will want to be sure that no class has an unfair advantage over any other class. This can be a pretty difficult thing to achieve. To aid you in your effort, use the battle commands (type /battle, /battle2, or /battle3)

These commands stage thousands of 'mock battles' between each possible combination of classes defined in your levels table (fighter versus wizard, fighter versus warrior, wizard versus warrior, etc.) and summarize the overall advantage each class has over another. You should keep tweaking your class values until they are all within a hit or two of equality.

Unless your world doesn't need balance, or there are other factors to consider (for example in Evergreen the 'scavenger' class is allowed a small hit advantage because they are not allowed to carry gold, buy items, or accept gifts and must make do with what they find dropped by monsters they kill.)

You might also find the /class n command useful. It prints a summary of class n. Note that if you edit the levels table, you must save your work and give the /reload command before the changes take effect in the world.

Hidden Classes and Class Morphing

For the most part, the character classes you define will all be available to the new player when they first create their hero character. They will appear in a list, with some comments you specify. Once selected, the hero character will usually stick with that class forever. (Players can create additional hero characters to experience the other classes you offer).

However, you may want to hide some classes (this just means they do not appear in the list and cannot be selected for use by a new hero character). This is done by one of the special commands - HIDDEN_CLASS (see levels.txt for the full list of special commands).

For these hidden classes to ever be used, you will need to have a scene script somewhere in your world which rewards (or punishes) a player by changing their class (by setting the appropriate hero cookie). There are some additional rules an limitations on class morphing, which are described in the levels.txt file.

Players will spend 90% of their time fighting monsters. Successfully conquering monsters is how their hero characters grow in level and ability. A satisfying monster experience (not too hard, and not too easy) is what will keep your players coming back in an obsessive-compulsive frenzy.

It is your job to define a list of all possible monsters in your world's monsters table (usually inside the file monsters.txt which is #included by quest.txt) Again, you will want to start with a copy of the Evergreen monsters.txt file, which has comments describing every column of the table.

The monsters table has one line per monster, with each monster having a unique monster ID number and several columns of facts about that monster (its name, maximum HitPoints, the sound it makes when it attacks, etc. There are a lot of columns in this table.)

You can use the /q editor (type "/q monsters.txt") to edit this file manually, or you can use the property editor (type "/q props.txt" and then select the monster category). The property editor is easier and more fun, but manually editing the file is probably more powerful.

Unlike heroes, where the player gets to pick the 'skin' which represents the character, you must call out the skin for each of your monsters. See custom skins and art submissions for information on the format of the graphic file to use for monsters.

Designer Tip: Defining your monsters in the monster table is a good first step, but if you want your players to actually encounter a monster in battle, you will need to do at least one of the following:

• Place monsters at specific map locations (using the link editor)
• Associate monster groups with specific map links (using the link editor)
• Call out specific monsters using the FIGHT command in a scene.

Monster Algorithms

As mentioned before, there are many columns of data to be defined for each monster. When creating a new monster you will probably do some sort of copy and paste of the line representing an existing monster, and then customize it for your new monster.

Remember that your new monster must have a unique monster ID #. If you have two monsters with the same ID, that will be reported as an error in /funpak the next time you /reload.

Your new monster also deserves a unique name and skin, but that is not absolutely required (it's just a darn good idea).

Most of the other columns can be set to special values which mean "generate this for me automatically based on the monster's level." These are referred to generally as the 'monster algorithms' and are both a bane and a blessing to the budding world designer.

It can be a lot of work to properly tune a monster so that it pays a reasonable reward for the difficulty experienced in killing it. If you let the engine pick these values fo you, your job is easier, but all 'level 12' monsters end up being about the same. If you manually choose every single value, then you have more control and can make more interesting monsters, but you can also make inappropriate monsters.

For example: a level 1, easy-to-kill, monster which pays an absurdly large amount of experience points. Players will quickly discover such loopholes and avoid the challenges you intended to place before them.

Read the comments in monsters.txt for the 'algorithm' value for each column. It's usually 0 or -1, depending on the column.