There are a number of files generate (and pre-generated) that you may find useful.

Export files are those produced by the filmation viewer:

  • debug files
  • raw structure files
  • xml files
  • IsoCis files
  • snapshot files

Import files are those files required by the filmation viewer or supplement the XML output files.:

  • map files
  • xsd file
  • xslt file

These import/export files are also available as a separate download.

 

debug files. During import of the data, all the values read are output to the ??_debug.txt files. These are readable and describe exactly what was read. Because it is generated forward only cross-references are not made.

raw structure files. These files are output to ??_rawstructure.txt files. The format is easy to read and similar to the debug files, except all cross-references are made and id's changed to proper names.

IsoCis files. When done, this will contain the data in a format ready for use inside the IsoCis engine (or your own if you like .ini style files)

map files. These are the files used by the filmation viewer and fully describes the game. The only use (apart from the viewer) would be to look at the byte codes or as a quick cross reference to id's stored in the XML outputs. The map files ending in _user are the custom room layout files created using the editor.

snapshot files. These are the original spectrum games that can be played in an editor. You can only play these if you have already bought the game and own the licence. When you create your own rooms using the editor new snapshot files are created. Again you still need to own a licence to play your created games.

  

filmation.xsd. This file is the XML definition file. It describes the format the XML file should take and can be used to ensure the XML file is valid. While not required to view the file, it can be used to help XML applications to better render/understand the XML file.

filmation.xslt. This file is a sample XML stylesheet. It allows XML viewers (e.g. web browsers) to display the XML file in a HTML format (bullet points, tables, etc). If not required or it does funny things with your view, simply remove the second line of the XML file that references this file.

XML files. This may be the most useful file format. There are two sections. <rooms> contains the actual room data and describes the layout of each room. <template> contains the actual descriptions for the rooms. For example, there is an element called roomsize for each room, which is normally 0,1,2. If you find equivalent element in the template section you will find out more information, such as the number of cells, etc.

Use a tool such as XML Spy with the xsd file to see the actual details of the file.

The main elements for the room objects are <specials> (these are where the special items, e.g. runes in Pentagram, cauldron items in Knight Lore, plug things in Alien 8) may be located. You need to refer to this site to find out the algorithm for actually determining what subset of these rooms get an object.) and <rooms>.

There is one room element for every room in the game. the contents of the room are as follows:

  • roomid. the id of the game, also used to determine its location in Knight Lore and Alien 8 if you do not make use of the links section
  • size. the size of the room. cross-reference the templates section
  • links. what rooms are adjacent in all directions. a handy way of knowing without having to calculate it using the roomid. Room links of -1 mean no link in that direction
  • backgrounds. what backgrounds (walls, doors, etc) are in this room. Use the id supplied and cross-reference the templates section for the actual background description and details.
  • roomblock. what actual room objects are placed (e.g. blocks, tables). The location is stored here. cross-reference the templates section (with the objecttypeid) to find the actual block details

The template section contains the actual details referenced by the rooms elements. The elements here are:

  • roomsizes. contains the details for the room sizes. roomtype here corresponds to size in the room description.
  • backgroundtypes. contains descriptions for the background items. id here corresponds to backgroundobject in the room description. bgtype can be either DOOR, Z, FREE, WALL. Most will either be DOOR or WALL. Knight Lore for some reason uses the cauldron/wizard as a background item, hence the need for FREE (can move anywhere) and Z (may only move in Z axis). Simply make these normal objects if you are planning on making a game yourself. causesexit tells you whether colliding with this item (usually a door) will change rooms.
  • blocks. describes the actual blocks in the game. id here corresponds to objecttypeid in the room description. movementtype is either Z or FREE. This is mainly for optimising an isometric engine. Z means the object moves only in the Z (i.e. up/down) and FREE means any direction. Obviously it doesn't have to move in these directions, e.g. most static blocks are classed as Z. Refer to the main site for further details. extra contains hints on the objects purpose

Most elements can have a hint section. This should be read.

 

So, if your purpose is to use the XML for generating your own game you should:

  1. read in the template section to populate your data values and convert any background items into main blocks if required (cauldron/wizard)
  2. create your blocks using the room details, remembering that some locations are in cells and some are in pixels
  3. create the special items according to the algorithms described.
  4. link the blocks to your actual sprites/animation
  5. create the player

Follow the tutorial for an example of how a game is started using the data produced by the viewer.