Hacking NEC PC Games/Area formats and Dialogue

Area files (also called level or map files) consist of a header part explaining the area's characteristics followed by the data describing the area.

Elements of Area Headers

edit

Things you might expect to find inside an area header

  • a "magic number" denoting the format of the area's file
  • the area's name and/or number
  • the rectangular (or cubic) dimensions of the area
  • the tileset (list of graphics) used in the area, expressed as a filename or numerical reference
  • the number and placement of characters in the area
  • the number and placement of items
  • the number and placement of scripted events
  • an external reference, either numeric or as a written file name, to the area's collection of character dialogues
  • an external reference, either numeric or as a written file name, to the area's collection of event scripts
  • an external reference, either numeric or as a written file name, to the area's background music

Area Data

edit

The meaning of an area's data depends on the game's world geometry, which can be either 2D or 3D.

A 2D game's area data tends to consist of a tileset reference for each cell in the area's rectangular grid. These tiles may have graphical and physical aspects (passible/impassible, breakable/unbreakable, doors/boundaries between other areas etc.) If the game world allows for layered maps in a simulated 3D space, then the tiles will be layered also, numbering by column, then row, and finally depth. However some games go farther than this, describing maps as references to pre-arranged tile groups and cell data, which can save significantly on the information needed to describe the area.

In the case of a 3D game, there may be multiple divisions and methods used both for performance reasons and to cut down on unique features which require more space. A 3D game area does not have a tileset but consists of model references at particularly locations coupled with elevations of the (always present) floor and map features.

Area data is usually compressed. In the case of 2D world geometry run-length encoding may be used. In other cases a dictionary approach may be more suitable. The use of dictionary compression increases the probability that the area file's data will be completely or mostly self-contained, with its dialogue and scripts coded inside the file itself rather than as references to other files, the entire area simply compressed/decompressed in one go.