/ circle3.1 / doc / OLD-DOCS / database.doc
database.doc
  1  /* ************************************************************************
  2  *  Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
  3  ************************************************************************* */
  4  
  5                        DATABASE DOCUMENTATION
  6                            "database.doc"
  7  
  8  
  9  1. The world file:
 10  ==================
 11  
 12  This file contains all the rooms, and is loaded once and for all at
 13  boot-time. It follows the this format:
 14  
 15  --------------------------------------------
 16  #<virtual number>
 17  <name>~
 18  <description>~
 19  <zone nr>
 20  <room_flags>
 21  <sector_type>
 22  {<direction fields and extra descriptions>}
 23  'S'
 24  #<virtual number>
 25  
 26  .
 27  .
 28  .
 29  
 30  #99999
 31  $~
 32  
 33  Explanation of fields:
 34  ----------------------
 35  
 36  <Direction fields> follow this format:
 37  
 38  D<exit number>
 39  <general description>~
 40  <keyword list>~
 41  <Door flag> <key number> <to_room>
 42  
 43  Extra descriptions
 44  ------------------
 45  
 46  Format:
 47  
 48  'E'
 49  <blank separated keyword list>~
 50  <description>~
 51  
 52  
 53  -----
 54  NOTE:
 55  
 56  All the text fields above may be left blank, but the '~' should always be
 57  there.
 58  
 59  On the 'virtual' number:
 60  
 61  Since the rooms for this game are expected to be written by several people,
 62  we have made it possible to number the rooms freely. Thus, it is possible to,
 63  say, number the rooms in zone 0 from 0 to 1000, the rooms in zone 1 from 1000
 64  to 2000, and so on. Rooms can then be added to the room file without
 65  upsetting the various references to rooms. In the reset command-tables, as well
 66  as in the exits, references to a given room are made via the virtual number
 67  rather than the array index. At boot-time, these references are substituted
 68  with the actual array indices in order to improve the game-time execution
 69  speed. In such places (ie the special routines for mobs/objs/rooms) where
 70  this substitution cannot take place, a function 'real_room', with prototype
 71  
 72  			int real_room(int virtual_number)
 73  
 74  must be used. This functions performs a binary search on the array of rooms, 
 75  looking for a room with a given virtual number. If found, the function
 76  returns the index to this room; if not, the game is halted. 
 77  
 78  Note: Since a binary search is used, the rooms MUST be sorted (in the
 79  room-file) after their virtual number.
 80  
 81  -----------------------------------------------------------------------------
 82  
 83  2. Objects and monsters
 84  =======================
 85  
 86  The objects and mobiles are stored in two separate files. They are loaded
 87  once at boot-time, and then each time their zone is reset, according to the
 88  information stored in the ZONE-FILE.
 89  
 90  The world is split up into a number of zones that are updated independently.
 91  The exact nature of these updates are defined by the contents of the ZONE-FILE.
 92  
 93  
 94  -----------------------------------------------------------------------------
 95  
 96  2.1. The Monster file:
 97  ======================
 98  
 99  The format of this file is as follows:
100  
101  
102  #<virtual number>
103  <namelist>~
104  <short description>~
105  <long description>~
106  <description>~
107  <action flags> <affection flags> <alignment> <Detailed/Simple flag>
108  
109  IF <Old/Simple flag> != 'S' {
110  
111  <strength> <intelligence> <wisdom> <dexterity> <constitution>
112  <hit low> <hit high> <armour> <mana> <movement> <gold> <exp>
113  <position> <default> <sex> <class> <level> <age> <weight> <height>
114  <condition 0> <condition 1> <condition 2> 
115  <savingthrow 0> <savingthrow 1> <savingthrow 2> <savingthrow 3> <savingthrow 4>
116  
117  } else { /* Simple monsters flag is 'S' */
118  
119  <Level> <Thac0> <AC> <Hit Points (format is xdy+z)> <Damage (as HP)>
120  <Gold> <Exp>
121  <position> <default position> <sex>
122  
123  }
124  #<virtual number>
125  
126  .
127  .
128  .
129  
130  #<virtual number>
131  $~
132  
133  
134  
135  -----------------------------------------------------------------------------
136  
137  2.3. The object file:
138  =====================
139  
140  
141  The format is as follows:
142  
143  #<virtual number>
144  <namelist>~
145  <short description>~
146  <long description>~
147  <action description>~
148  <type flag> <extra flag> <wear flag>
149  <value 0> <value 1> <value 2> <value 3>
150  <weight> <value> <cost/day>
151  'E'
152  <keyword-list>~
153  <extra description>~
154  'E'
155  <keyword-list>~
156  <extra description>~
157  .
158  .
159  .
160  'E'
161  <keyword-list>~
162  <extra description>~
163  'A'
164  <location> <modifier>
165  .
166  .
167  'A'
168  <location> <modifier>
169  #<virtual number>
170  
171  .
172  .
173  .
174  
175  #<virtual number>
176  '$~'
177  
178  -----------------------------------------------------------------------------
179  
180  2.3. The zone-file
181  ==================
182  
183  The zone-file contains the following information for each zone:
184  
185  a) The top room-number of the zone. A room belongs to a zone X if:
186  
187            zone[X-1].top < virtual_room_number <= zone[X]
188  
189  for X > 0. Rooms belong to zone 0 if their number is between 0 and the
190  top of zone 0.
191  
192  b) The LIFESPAN of the zone. When the age of the zone (measured in minutes
193  after last reset) reaches this number, the zone is queued for reset. The
194  zone is then reset as soon as possible (more or less), depending on the 
195  value of the RESET_MODE-variable.
196  
197  c) The RESET_MODE. This may take on of three values:
198  
199    0: Don't reset the zone at all. In this case, the age of the zone is never
200       updated, and it will never be queued for reset. Thus, the value of the
201       lifespan-field is effectively ignored.
202  
203    1: Reset the zone as soon as it is deserted, ie as soon as there are no
204       players located within the zone.
205  
206    2: Reset the zone no matter who or what is in it.
207  
208  d) The COMMAND TABLE. This is a series of commands to execute at reset. The
209     table is terminated by the pseudo-command 'S', and thus follows the 
210     following format:
211  
212     <command>
213     <command>
214  
215     .
216     .
217     .
218  
219     <command>
220     'S'
221  
222     Each command consists of a letter, identifying the command-type, followed
223     by three or four arguments. The first argument, common to all the commands,
224     is called the 'if-flag'. If it is true (nonzero), the command is executed
225     ONLY if the preceding command was executed. If it is false (zero), the
226     command is executed anyway.
227  
228     The commands:
229  
230  	M (load a mobile): 
231             Format: 'M' <if-flag> <mobile nr> <max existing> <room nr>
232  
233  	   mobile nr and room nr should be self-explanatory. The 'max
234  	   existing' parameter specifies the maximum permissible number of
235  	   existing units. In other words: If you only want one manifestation
236  	   of a given monster, you just specify the number '1'. If the max
237  	   number is about to be exceeded, the command won't be executed.
238  
239  	O (load an object):
240  	   Format: 'O' <if-flag> <object nr> <max existing> <room nr>
241  
242        Load an object and place it in a room.	(NOT -1)
243  
244  	G (give object to mobile):
245  	   Format: 'G' <if-flag> <object nr> <max existing>
246  
247        Loads an object, and gives it to the last monster referenced (ie. by the
248        M-command).
249  
250  	   Of course, this command doesn't make sense if a new mobile+object
251  	   pair has not just been created, which is where the if-flag comes
252  	   in handy.   :)
253  
254  	E (object to equipment list of mobile)
255  		Format: 'E' <if-flag> <object nr> <max existing> <equipment position>
256  
257  	 Loads object and places it in the Equipment list of the last monster
258      referenced.
259  
260      Note that it is NOT necessary to precede this command with a 'G' command.
261      Equipment position is one of:
262        WEAR_LIGHT      0
263        WEAR_FINGER_R   1
264        WEAR_FINGER_L   2
265        WEAR_NECK_1     3
266        WEAR_NECK_2     4
267        WEAR_BODY       5
268        WEAR_HEAD       6
269        WEAR_LEGS       7
270        WEAR_FEET       8
271        WEAR_HANDS      9
272        WEAR_ARMS      10
273        WEAR_SHIELD    11
274        WEAR_ABOUT     12
275        WEAR_WAISTE    13
276        WEAR_WRIST_R   14
277        WEAR_WRIST_L   15
278        WIELD          16
279        HOLD           17
280  
281  
282  	P (put object in object):
283  	   Format: 'P' <if-flag> <object_nr1> <max existing> <object nr2>
284  
285  		Loads object1 and places it in object2.
286  
287  	D (set state of door)
288  		Format: 'D' <if-flag> <room nr> <exit nr> <state>
289  
290  		State being one of:
291  		0: Open.
292  		1: Closed.
293  		2: Closed and locked.
294  
295  	R (remove object from room)
296       Format: 'R' <if-flag> <room_nr> <object_nr>
297  
298  
299     More commands will probably be needed, and will be added as required.
300  
301  
302  Format of the zone-file:
303  
304  ---------------------------------------
305  #<arbitrary number (ignored)>
306  <name>~
307  <top of zone>
308  <lifespan>
309  <reset mode>
310  <command>
311  <command>
312  
313  .
314  .
315  .
316  
317  <command>
318  'S'
319  #<arbitrary number>
320  
321  .
322  .
323  .
324  
325  #<arbitrary number>
326  $~
327  
328  
329  
330  
331  
332  
333  
334  2.2. The monster file:
335  ----------------------
336  
337  The format of this file is as follows:
338  
339  
340  ----------------------------------------------
341  #<virtual number>
342  <namelist>~
343  <short description>~
344  <long description>~
345  <description>~
346  <action flags> <affection flags> <Detailed/Simple flag>
347  
348  IF <Old/Simple flag> != 'S' {
349  
350  <strength> <intelligence> <wisdom> <dexterity> <constitution>
351  <hit low> <hit high> <armour> <mana> <movement> <gold> <exp>
352  <position> <default> <sex> <class> <level> <age> <weight> <height>
353  <condition 0> <condition 1> <condition 2> 
354  <savingthrow 0> <savingthrow 1> <savingthrow 2> <savingthrow 3> <savingthrow 4>
355  
356  } else { /* Simple monsters flag should be 'D' */
357  
358  <Level> <Thac0> <AC> <Hit Points (format is xdy+z)> <Damage (as HP)>
359  <Gold> <Exp>
360  <position> <default position> <sex>
361  
362  }
363  #<virtual number>
364  
365  .
366  .
367  .
368  
369  #<virtual number>
370  $~
371  ----------------------------------------------
372  
373  On the skill fields:
374  
375  Format:
376  --------------
377  S<skill number>
378  <learned> <affected by> <duration> <recognize>
379  --------------
380  
381  On the virtual numbers:
382  
383  This number may be considered the 'label' of the mobile, for use in eg. the
384  zonefile (see also the text about the roomfile format). When the mobile is to
385  be referenced from within the code itself, the function real_mobile
386  (real_object for objects) can be used to find indices to the file-index tables
387  (this is only of use when writing special routines). These functions are
388  automatically called from read_object/read_mobile, depending on their 'type'
389  parameter (see db.doc).