Archive/portal64-still-alive
1
0
Fork 0
mirror of https://github.com/mwpenny/portal64-still-alive.git synced 2024-10-20 10:37:37 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity
portal64-still-alive/documentation/levels/file_formats.md
Matt Penny 1885688090 Start documenting level objects 
* Button
* Clock
* Switch
2024-02-01 00:08:35 -05:00

2.6 KiB
Raw Blame History

Level File Formats

Levels

Each level of the game is defined via two files:

  1. Blender (.blend) file
  2. YAML (.yaml) file

These files are located in the assets/test_chambers/<level_name>/ directory corresponding to a given level.

Level layout (Blender file)

A level's .blend file specifies fundamental 3D elements such as layout and collision as well as the objects contained within (e.g., cubes, doors, elevators, etc.) and any animations, such as for moving platforms. These files can be edited in Blender as with any other .blend file. Reusable objects are defined in their own .blend files located in the assets/models/ directory and then referenced from the level .blend files which use them.

At export time, level object data beyond position, rotation, etc. is generally not read from .blend files. Rather, objects use a naming convention which tells the exporter their type and parameters so information like the mesh and material data can be looked up elsewhere. This naming convention is also what hooks the objects up to code. To learn more about what can appear in a level and how to configure it, see Level Objects.

Level scripting (YAML file)

The second file that makes up a level is its .yaml file. This file contains its cutscene steps and signal operators. At build time, the data in these files is used to generate corresponding C code. See the linked pages for more details.

Materials

As mentioned above, material data for objects is not read from their .blend files. This is also true for static level geometry. Instead, all materials are defined in .skm.yaml files located in the assets/materials/ directory. These YAML files specify textures, colors, as well as other more complex RDP/RSP settings. They are currently used at export time to generate display lists using libultra. Since one of the goals of this project is to build a library-independent abstraction layer, it is currently not a priority to document the format of these files.

When exporting a level, only the name of each material is used. The actual material information is looked up in the .skm.yaml files using the name. This means that a level's appearance in Blender will not necessarily match the game. However, for convenience, assets/materials/materials.blend contains Blender versions of the various materials so that it is easier to apply them and also get a reasonable visual approximation while editing.

TODO

  • Asset pipeline
  • Blender scripts
  • Skeletool
  • Exporter scripts
  • Material YAML file structure (ideally after library-independent abstraction is done)