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".
- 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
Moderate memory and performance penalty.
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
- 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
( 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
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
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 email@example.com.