Map Markup

Hints in the map, additional markup for volumes, added by the level designer, and/or generated by preproessing tools, and/or extended at runtime and saved. One primary application would be an "AI Map" that assists the monster AI, e.g. by marking "hiding place" or "open space".

Advantage:

• A good many game features depend on high level information that is nowhere available except inside the map designer's head. Given the option, the designer could add such information to the map as Markup Brushes.
• This is a generalization of creating water areas, adding hint brushes and marking some geometry as "detail" - all done for QE4. The difference is that in Q2, the designer guided only the processing tools. In Q3, the designer should be able to guide the game subsystem as well.
• AI could be improved. "Senses" could be implemented for NPC's, as well as high level hints for behavior.
• Physics could be improved, adding new properties to volumes.

Disadvantage:

Moderate memory and performance penalty.

Implementation:

If the Q3 map processing tools just add certain strings to the ones existing in the map, and a single interface is used to query area all attributes based on entity position, mod authors could add whatever their special effects, AI, or physics needs, and have it passed through transparently to the Game Subsystem.

• The Q2/Q3 engine will need some kind of (hierarchical) spatial subdivision, whether BSP based or other. While the actual data structure as such will not, and should not, be exposed to the Game DLL, benefits like PVS, PHS and tracing/clipping of movements are already exposed.

• a builtin area_descript_t struct that contains values, and/or additional gi function pointers that allow for obtaining values. The information contained there and accessible to the Game DLL would originate from two sources, like:
  • generated during or before map processing (like PHS, PVS). Properties like: volume, dark or rather well-lit, overall simple or with detailed structure, rather spherical or elongated etc. are conveniently determined by the level editor and/or by the q3utils.

  • added during map editing (like water, slime). These are attributes that can not be generated automatically. The attributes can range from simple values to complicated descriptions. Applications are:
    • physics - density (buonancy, friction)
    • monster AI hints - "large room", "no cover"
    • behavior hints - "cradle", "hunting ground"
    • navigational aids - "You are in Block 3A"
    • audio subsystem - echo effects. e.g. based on volume

• Extension: the volume_descript_t struct would contain mandatory attributes generated by the q3utils, and possibly tied to the actual spatial subdivison used by Q3. A

    char* gi.LookupVolumeAttribute
             ( vec3_t pos,
               char*  attr_name );
  

  function could provide retrieval of value/attribute strings for the names used in the map file, passed through by q3utils transparently, at the expense of higher costs and slower retrieval.
• a builtin areaID (as the currently visible areanum) could be checked fast, and slow string retrieval would happen only when it changes.
• The existing "areas" are the hook we need to retrieve information:

  
     if ( AREA_HIDING_PLACE && gi.getAreaAttr( self->areanum ) ) 
  
     volume      = gi.getAreaVolume( self->areanum );
     temperature = gi.getAreaTemperature( self->areanum );
     
     if ( CONTENTS_WATER && gi.getAreaContent( self-areanum ) )
  
  

• Markup Brushes that overlap and contain different categories of information ("This Is Factory Level 3" vs. "Here Is Water" vs. "This Is A Hot Room") will create e.g. a BSP with many splits. Per category LUTs are combinatorially cursed.

Remarks: This was partly inspired by, and competes with, the "AI Senses" proposal, and the AI Map from the "Artificial Intelligence" proposal, by Simon Templar and Todd Meijome, respectively.

Submitted 980405, revised 980420, comments to bk@gamers.org.