Fife Package Specification

From FIFE development wiki
Jump to: navigation, search

This article is outdated and needs to be reviewed! Outdated.png

The content of this article is outdated and should be treated as such. We cannot guarantee the accuracy of the information presented here.

Notes about content packaging

  • packages should be such, that you can select them from different sources and mix n' match for your own game
  • packages may only provide partial content (e.g. scripts or cursors are missing)
  • packages should hold "project information", i.e. author, licence and version (some other fields as well)
  • it should be possible to deliver packages in compressed format
  • for clarity's sake, actual games could conform to similar structure as packages that they are using (that creates sort of "super packages")
  • packages should have one clear entrypoint in case they contain something playable
  • packages should hold documentation how it is used
  • stuff in packages should conform to naming conventions, so that e.g. dataset generators are made possible; conventions also help to find stuff between different packages
  • each element that is converted to engine element (e.g. object, cursor) should have namespace information, so that they can be uniquely identified

Common Conventions

Filename Case

As a rule of thumb all filenames you use for assets should be lower case. You can use a mix of lowercase and uppercase but you may run into problems when you are working with different operating systems (some operating systems have case sensitive filesystems).

Package Root Structure

The following list defines the elements found from the package root structure. See chapters below for further explanations on each element.

  • objects, type=folder, mandatory=no, count=0..1. Contains object definitions for the package
  • cursors, type=folder, mandatory=no, count=0..1. Contains cursor definitions for the package
  • fonts, type=folder, mandatory=no, count=0..1. Contains font definitions for the package
  • gui, type=folder, mandatory=no, count=0..1. Contains gui definitions for the package
  • maps, type=folder, mandatory=no, count=0..1. Contains map definitions for the package
  • scripts, type=folder, mandatory=no, count=0..1. Contains scripts for the package
  • sounds, type=folder, mandatory=no, count=0..1. Contains generic sounds for the package
  • music, type=folder, mandatory=no, count=0..1. Contains music for the package
  • imports, type=folder, mandatory=no, count=0..1. Contains import definitions for the package
  • saves, type=folder, mandatory=no, count=0..1. Contains save games related to this package
  • packages, type=folder, mandatory=no, count=0..1. Contains sub-packages for this package. Used e.g. with games using content packages provided by others
  •, type=file. mandatory=no, count=0..1. Main execution entrypoint for the package. E.g. launches the game in case package contains one
  • package.xml, type=file, mandatory=yes, count=1. Describes the package in more detail (e.g. version number, license and author)'


Objects folder contain the engine object definitions and their integral content parts (like sounds, graphics and animations).

The following replacements are done in the structure below:

  • <object_name> Denotes the name of the object (e.g. "MyHero", "ChickenWithBanana" or "JamesBong")
  • <action_name> Denotes the name of the action (e.g. "Eat", "Use")
  • <direction> Denotes a numeric, three digit direction specifier (e.g. 000, 045 or 225)
  • <sequence_id> Denotes a numeric, four digit sequence identifier (e.g. 0000, 0324 or 8334)
  • <imgtype> Denotes image file postfix, e.g. "png"
  • <action_sound> Denotes sound file for action, e.g. "eatmunch.ogg" or "eatgulp.ogg"


  • <object_name>, type=folder, mandatory=no, count=0..n
    • object.xml, type=file, mandatory=yes, count=1. xml description file (dataset) for the object
    • <direction>.<imgtype>, type=file, mandatory=yes, count=1..n. "static" images for the object. These images are used e.g. with editor when instances are placed on map
    • <action_name>, type=folder, mandatory=no, count=0..n. contains object's single action definition
      • <direction>, type=folder, mandatory=yes, count=1..n. Folder containing animations for given direction
        • animation.xml, type=file, mandatory=yes, count=1. Describes the animation used in this action
        • <sequence_id>.<imgtype>, type=file, mandatory=yes, count=1..n. Frames for the animation
      • <action_sound>, type=file, mandatory=no, count=0..n. Sounds associated with this action


Cursors folder contain the cursors used in the client

The following replacements are done in the structure below:

  • <cursor_name> Denotes the name of a cursor (e.g. mypointingcursor)
  • <sequence_id> Denotes a numeric, four digit sequence identifier (e.g. 0000, 0324 or 8334)
  • <imgtype> Denotes image file postfix, e.g. "png"


  • <cursor_name>.xml, type=file, mandatory=no, count=0..n. Defines cursor resource (dataset)
  • <cursor_name>, type=folder, mandatory=no, count=0..n. Contains images for cursor
    • animation.xml, type=file, mandatory=no, count=1. Defines animation.xml file for cursor (in case cursor is animation)
    • <cursor_name>.<imgtype>, type=file, mandatory=yes, count=1..n. Defines image(s) used for this cursor. Multiple images may be used in case of animated cursors


Fonts folder contain the fonts used in the client

The following replacements are done in the structure below:

  • <font_name> Denotes the xml dataset definition for font file (e.g. myfont.xml)
  • <font_file> concrete font file (e.g. myfont.ttf)


  • <font_name>, type=file, mandatory=yes, count=0..n
  • <font_file>, type=file, mandatory=yes, count=0..n




Maps contain the map files used in the game.

The following replacements are done in the structure below:

  • <map_name> Denotes the name of a map (e.g. "city_underground1.xml"


  • <map_name>, type=file, mandatory=no, count=0..n


Scripts folder contains the script files used in this package. Structure is free form.


The misc/ folder contains various other utilities associated with the package that don't fit the previously defined structure. For example, 3d modeling rigs for creating new content.