An Introduction To Y A M A Revision 1.07/Beta Contents 1. Introduction To YAMA 2. Basic game concepts 3. How to define items within the database 4. The operation of game tables 5. Summary of database actions 1. Introduction YAMA was inspired by the TinyMUD game system which had the virtue of simplicity, however a powerful game system ws desired, not neccessarily with complex user expandability, but with full user expandability from a database language. The system is based upon ideas that have been used since the time of Scott Adams (of AdventureLand fame), of using a microcoded database containing all of the game definitions. YAMA is designed to run under both BSD and SYSV environments, and to provide a telnet server version for use in internet type networks. 2. Basic Game Concepts YAMA is based around a database, which contains details of all of the items which make up the game 'world'. Items are divided into three classes, each designed to simulate one paticular sort of thing. Rooms simulate places a player can visit. These need not neccessarily be rooms as such.. it could be part of a vast forest, deep in outer space or whatever else you want. Rooms have several unique properties. A room has a description which is intended to explain where you are. It has exits which control where users may move around the game world. Several control flags provide options to make rooms handle such things as darkness. Finally some control flags, and user variables are available for whatever the game designer desires. Objects simulate items that may be manipulated. Objects are not neccessarily just things which can be picked up and carried around, things like doors and puddles are often objects. Objects have several unique properties. The have size and weight which controls whether they can fit into one another, and wether people can carry them. They posess a notion of 'state', and a description for each state. Thus a door might have states for being open, closed and locked. In a similar way to rooms objects have control flags which enable options to be set, and also user variables and control flags. Players are used to simulate active items within the game. All of the users of the game will be players, as may many internally controlled game creatures. Players are given several specific fields for uses which interact with the system. These are :- Location: The room player or object containing this player Level: This governs what degrees of invisibility a user can see Visibility: A player is invisible to all players of level below their visibility. This is useful for invisibility magics. Score: This is only a system field for historical reasons Strength: A player is allowed to carry items of total weight ten times his strength. Messages: Messages to use when a player is present in a room, Arrives in a room, Leaves a room. 3. Defining Items In The Database Before looking at specific fields it is best too look at an overview of database structure. You may find consulting the example database helpful in doing this. The database is a text file, which can be user edited to describe the game. It consists of 'Sections'. Each section is introduced and seperated from the previous sections by an '@' symbol and a section name. eg. @GAMENAME, defines the game name defining section. The order of the sections of the game is mandatory and each section must exist. The sections in order are @GAMENAME:[gamename] This defines the name of the game. This field is only ever used if the system is running under RMOL Chat, in which case it is the application room used by the server. It must always be present @ARCHID This section will allow players deemed to be 'Archwizards' or game controllers to be locked onto specific user ids, for security improvements. This is not implemnted. @ARCHNAME This section defines the item names which are deemed to be archwizards and thus have special powers. They are set up in the database rather than by user flags to maximise security. Note that they are normally player names but can be any item name. @RFLAG @OFLAG @PFLAG These sections define any user bit flags added to the system ones, for rooms objects and players respectively. The total of of user+system ones for each of RFLAG,OFLAG(see below), and PFLAG(also see below) is 16. Exceeding this gives an error. If more bit flags for an item are needed they can be implemented by using one of the user variables in the item to store several bit flags. This is done for players in the example database. @CONSTANTS Constants give names to numeric values. These values can then be used in user flags in the item definitions or anywhere in the tables. This enables more easily readable code to be produced. All constants are of the form NAME=value. @VOCAB Many of the game words are defined here. All verbs and prepositions need to be defined in this table. Nouns are sometimes defined here, but will be added automatically for items, if the noun does not currently exist. If you desire synonyms for nouns they must be inserted here. @ROOM This section declares all of the rooms used in the game, and information about them. In the example database this shows an example of the database facility called 'including' which for programmers is similar in idea to C #include. If a line starts '<' the contents of the file whos name follows the '<' will be read until completion, then the next line of the old file will be read and the old file resumed. The affect is thus exactly the same as if the file mentioned was part of the main file. @PLAYER This shows a similar example. The player definitions detail all of the mobiles in the game, though not the user slots. The system allocates these itself in advance. @OBJECT All of the objects are defined in this section, in much the same way as rooms and players were. @EXIT This section contains a list of all of the exits that connect and link up the rooms. Each entry is written in the form FROM direction TO