home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / games / volume5 / monster / part01 / mon5.pas < prev    next >
Pascal/Delphi Source File  |  1988-11-30  |  4KB  |  104 lines
  1.  
  2.  
  3. { Notes to other who may inherit this program:
  4.  
  5.     Change all occurances in this file of dolpher to the account which
  6.     you will use for maintenance of this program.  That account will
  7.     have special administrative powers.
  8.  
  9.     This program uses several data files.  These files are in a directory
  10.     specified by the variable root in procedure init.  In my implementation,
  11.     I have a default ACL on the directory allowing everyone READ and WRITE
  12.     access to the files created in that directory.  Whoever plays the game
  13.     must be able to write to these data files.
  14.  
  15.  
  16. Written by Rich Skrenta, 1988.
  17.  
  18.  
  19.  
  20.  
  21. Brief program organization overview:
  22. ------------------------------------
  23.  
  24. Monster's Shared Files:
  25.  
  26. Monster uses several shared files for communication.
  27. Each shared file is accessed within Monster by a group of 3 procedures of the
  28. form:    getX(), freeX and putX.
  29.  
  30. getX takes an integer and attempts to get and lock that record from the
  31. appropriate data file.  If it encounters a "collision", it waits a short
  32. random amount of time and tries again.  After maxerr collisions it prints
  33. a deadlock warning message.
  34.  
  35. If data is to be read but not changed, a freeX should immediately follow
  36. the getX so that other Monster processes can access the record.  If the
  37. record is to be written then a putX must eventually follow the getX.
  38.  
  39.  
  40. Monster's Record Allocation:
  41.  
  42. Monster dynamically allocates some resources such as description blocks and
  43. lines and player log entries.  The allocation is from a bitmap.  I chose a
  44. bitmap over a linked list to make the multiuser access to the database
  45. more stable.  A particular resource (such as log entries) will have a
  46. particular bitmap in the file INDEXFILE.  A getindex(I_LOG) will retrieve
  47. the bitmap for it.  
  48.  
  49. Actually allocation and deallocation is done through the group of functions
  50. alloc_X and delete_X.  If alloc_X returns true, the allocation was successful,
  51. and the integer parameter is the number of the block allocated.
  52.  
  53. The top available record in each group is stored in indexrec.  To increase
  54. the top, the new records must be initially written so that garbage data is
  55. not in them and the getX routines can locate them.  This can be done with
  56. the addX(n) group of routines, which add capacity to resources.
  57.  
  58.  
  59.  
  60. Parsing in Monster:
  61.  
  62. The main parser(s) use a first-unique-characters method to lookup command
  63. keywords and parameters.  The format of these functions is lookup_x(n,s).
  64. If it returns true, it successfully found an unambiguous match to string s.
  65. The integer index will be in n.
  66.  
  67. If an unambiguating match is needed (for example, if someone makes a new room,
  68. the match to see if the name exists shouldn't disambiguate), the group of
  69. routines exact_X(n,s) are called.  They function similarly to lookup_x(n,s).
  70.  
  71. The customization subsystems and the editor use very primitive parsers
  72. which only use first character match and integer arguments.
  73.  
  74.  
  75.  
  76. Asynchronous events in Monster:
  77.  
  78. When someone comes into a room, the other players in that room need
  79. to be notified, even if they might be typing a command on their terminal.
  80.  
  81. This is done in a two part process (producer/consumer problem):
  82.  
  83. When an event takes place, the player's Monster that caused the event
  84. makes a call to log_event.  Parameters include the slot of the sender (which
  85. person in the room caused the event), the actual event that occurred
  86. (E_something) and parameters.  Log_event works by sticking the event
  87. into a circular buffer associated with the room (room may be specified on
  88. log_event).
  89.  
  90. Note: there is not an event record for every room; instead, the event
  91.       record used is  ROOM # mod ACTUAL NUMBER of EVENT RECORDS
  92.  
  93. The other half of the process occurrs when a player's Monster calls
  94. grab_line to get some input.  Grab line looks for keystrokes, and if
  95. there are none, it calls checkevent and then sleeps for a short time
  96. (.1 - .2 seconds).  Checkevent loads the event record associated with this
  97. room and compare's the player's buffer pointer with the record's buffer
  98. pointer.  If they are different, checkevent bites off events and sends them
  99. to handle_event until there are no more events to be processed.  Checkevent
  100. ignores events logged by it's own player.
  101.  
  102.  
  103. }
  104.