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