I'm thinking about creating a level format which would be text-only - no binary data.
Here's my early concept, Eversmile:
Code:
[legend]
. NEUTRAL EARTH
- NEUTRAL PATH
$ NEUTRAL GOLD
~ NEUTRAL WATER
= PLAYER0 CLAIMED
* PLAYER0 WALL
H PLAYER0 HEART
P NEUTRAL ENTRANCE
[level]
.......................................
...--..................................
..----.................................
.-------.........PPP...................
..----...........PPP...................
...--............PPP...................
.......................................
.......................................
.......................................
.......................................
...............*******.................
...........*****=====*......~~~~~~.....
...........*===*=HHH=*$$$.~~~~~~~~~~~..
...........*=====HHH==$$$-~~~~~~~~~~~~.
...........*===*=HHH=*$$$.~~~~~~~~~~~..
...........*****=====*......~~~~~~.....
...............*******.................
.......................................
[things]
object x y z model value
creature x y model exp gold
trap x y model ncharges
action_point x y range
light x y z range color
[script]
(standard DK1 script)
Let me know what you think.
Why am I doing this:
I want KeeperFX levels to be stored in easy format, which would take full advantage of version control systems. Binary data is hard to compare, so if someone is changing a level - it's hard to say what was really changed.
Also, it would be quite easy to write a level editor which creates levels in such form - it soesn't need any decrypting of DK level file format, this one is plain and self-explanatory.
Text-based level file format - specification
1. Basic structure
Level files are divided into INI-like sections. Section starts with its name in square brackets, and ends with a start of another section, or end of file.
Each section start must be in a separate line, with no non-white characters before or after square brackets.
Standard sections are [legend], [level], [things] and [script]. These store level parameters with universal form.
Additionally, there may be variants of each section used only for a specific game. The game is identified by a shortcut after a dot in section name, ie. [legend.DK1], [things.WFTO], [script.DK2]. If such game-specific section exists, level converter for that game will only use specific section and ignore the common variant of the section.
Also, there may be new sections introduced by specific games - they should also keep the game name shortcut after dot, ie. [columns.DK1].
Note that using varianted [level] section is a bad practice and should be avoided.
Every line which do not contain non-white characters is ignored.
The semicolon (;) is a comment indicator - all text between the semicolon and end of line is ignored, and the semicolon position is treated as end of line.
The file should be coded in UTF-8, and have no BOM indicator at start. Line endings may be either Windows-style or Unix-style.
2. Concept behind standard sections
The [legend] section should assign owned rooms and terrain types to specific character. Then, in [level] seciton, the previously defined characters may be used to place those rooms on map area.
Map size is determined by the amount of lines and amount of characters in each line of [level] section. The [level] section may only contain characters which purpose is defined in [legend] section.
All additional items placed on the level are stored in [things] section. This section doesn't store items which are automatically placed in rooms (ie. no gravestones on the gaveyard), it only stores additional things - like creatures, additional light sources, traps, gold piles, effects. It also stores action points and static lights.
The [script] section stores level script in a universal form. The LUA language will be used to create the universal form, but for now there's no specification of an universal script format. This is why, for now, only game-specific script blocks are used, ie. [script.DK1] or [script.DK2].
3. Details of [legend] section
Each line in this section stores 3 words separated by whitespaces.
The first word must actually always be a single character, and defines the char to be used in [level] section. The character must be non-control and non-whitespace char (of code >32). Also, some characters are forbidden: [ ] ; and the char of code 255.
The second word defines which player is the owner of the tile. Universal owner names are discussed later.
The third word defines terrain or room type to be put on the tile. Universal terrain type names and room types are discussed later.
All owner-specific [legend] sections will use the same basic scheme of 3 words, only specific words to be used will differ.
4. Details of [level] section
This section defines size of the level and its basic content - terrain types and their owners.
Map width is determined by the amount of characters in each line; every line must have the same length. Map height is determined by amount of lines; lines which do not contain non-whitespace char are not counted. If a specific game has restrictions on map size, the map may be enlarged by a converter, and terrain around filled with unpenetrable rock.
Every character used inside this section should be defined by a line in [legend] section.
5. Details of [things] section
The Universal things section contains a list of items placed on specific positions of the map. Each line of this section will add a new thing to the map. The amount of arguments in each line depends on what is being placed.
What can be placed:
- object
- creature
- trap
- action_point
- light
WIP
6. Details of [script] section
Universal script format will be based on LUA scripting language. It will only contain basic commands, which are common to the supported games.
More advanced scripting require game-specific sections. Those will contain commands in game-specific form.
6.1. Section [script.DK1], specific to Dungeon Keeper
This section should contain raw content of .txt script for Dungeon Keeper Level.
6.2. Section [script.DK2], specific to Dungeon Keeper II
This section should contain Dungeon Keeper II script written in a text form.
The details are still to be decided - the game originally uses binary form of storing scripts.
The text-based form should be made in a way which allows simple 1:1 translation between text and binary forms.
6.3. Section [script.KFX], specific to KeeperFX
This section should contain raw content of .txt script for KeeperFX.
While KeeperFX may use [script.DK1] section, it also introduces some new commands, which doesn't exist in original Dungeon Keeper. In case such commands are used, the KeeperFX specific script section should be used.
7. Owner names
WIP
7.1. Owner names specific to Dungeon Keeper
Any sections specific to that game will use the following owner names:
PLAYER0
PLAYER1
PLAYER2
PLAYER3
PLAYER_GOOD
PLAYER_NEUTRAL
8. Terrain/room types
8.1. Terrain/room names specific to Dungeon Keeper
Any sections specific to that game will use the following terrain names:
HARD
GOLD
DIRT
TORCH_DIRT
DRAPE_WALL
TORCH_WALL
TWINS_WALL
WOMAN_WALL
PAIR_WALL
PATH
PRETTY_PATH
LAVA
WATER
GEMS
And available room names are as below:
ENTRANCE
TREASURE
RESEARCH
PRISON
TORTURE
TRAINING
DUNGEON_HEART
WORKSHOP
SCAVENGER
TEMPLE
GRAVEYARD
GARDEN
LAIR
BARRACKS
BRIDGE
GUARD_POST
DOOR_WOODEN
DOOR_BRACE
DOOR_STEEL
DOOR_MAGIC