Difference between revisions of "Adding Cities and Dungeons to the IVAN World Map"
| Line 8: | Line 8: | ||
== Three key resources == | == Three key resources == | ||
| − | There are three key steps to getting your | + | |
| + | There are three key steps to getting your dungeon to appear on the world map. | ||
=== Your dungeon data file === | === Your dungeon data file === | ||
| − | Your dungeon.dat file should reside in Script/dungeons where it will automatically be picked up by the | + | Your <code>dungeon.dat</code> file should reside in <code>Script/dungeons</code> where it will automatically be picked up by the |
=== define.dat === | === define.dat === | ||
| − | Anything you put in define.dat, you can refer to in your other script files. This is a general rule and is applicable to any of the data files. For example, if you want to create another config of a guard, then you just put a new #define in define.dat, and you can now refer to it in char.dat and your dungeon data file. | + | Anything you put in <code>define.dat</code>, you can refer to in your other script files. This is a general rule and is applicable to any of the data files. For example, if you want to create another config of a guard, then you just put a new <code>#define</code> in <code>define.dat</code>, and you can now refer to it in <code>char.dat</code> and your dungeon data file. |
| − | So it follows that you can #define your own dungeon name, which will be essential when we come to link the dungeon data file to the terrain data file. | + | So it follows that you can <code>#define</code> your own dungeon name, which will be essential when we come to link the dungeon data file to the terrain data file. |
| − | Stick to upper case lettering when adding a new #define, and be sure to put an underscore when separating words. | + | Stick to upper case lettering when adding a new <code>#define</code>, and be sure to put an underscore when separating words. |
| − | Dos and don'ts: be sure items that are enumerated follow a nice numerical sequence e.g. 1, 2, 3, 4, 5; or 2, 4, 8, 16, 32; rather than 1, 2, 5, 7, 8; | + | Dos and don'ts: be sure items that are enumerated follow a nice numerical sequence e.g. <code>1, 2, 3, 4, 5;</code> or <code>2, 4, 8, 16, 32;</code>, rather than <code>1, 2, 5, 7, 8;</code>. |
| − | If we wish to refer to a particular dungeon in the code itself, say in game.cpp, then the code will need to know about it, and so a #define will need to appear in ivandef.h before compiling the game. | + | If we wish to refer to a particular dungeon in the code itself, say in <code>game.cpp</code>, then the code will need to know about it, and so a <code>#define</code> will need to appear in <code>ivandef.h</code> before compiling the game. |
=== owterra.dat === | === owterra.dat === | ||
| − | The data file | + | The data file <code>owterra.dat</code> contains the "over-world terrains" of the IVAN world map. These are so named, because they become the little pictures that sit over the ground terrain on the world map. They denote the |
== A worked example == | == A worked example == | ||
| Line 35: | Line 36: | ||
== Known limitations == | == Known limitations == | ||
| − | As of 0.50.6, the number of slots is 32. | + | As of <code>0.50.6</code>, the number of slots is <code>32</code>. |
Overflow of number of dungeons. Ways in which this can happen. | Overflow of number of dungeons. Ways in which this can happen. | ||
Population distribution of terrain types collected by the sampling algorithm. | Population distribution of terrain types collected by the sampling algorithm. | ||
Revision as of 04:18, 6 June 2016
This section is about adding dungeons to the world map. If you would like to learn about the specifics of dungeon building, see Dungeon Building.
Contents
Introduction
This is a brief guide explaining how to include your customized dungeons on the IVAN world map.
Three key resources
There are three key steps to getting your dungeon to appear on the world map.
Your dungeon data file
Your dungeon.dat file should reside in Script/dungeons where it will automatically be picked up by the
define.dat
Anything you put in define.dat, you can refer to in your other script files. This is a general rule and is applicable to any of the data files. For example, if you want to create another config of a guard, then you just put a new #define in define.dat, and you can now refer to it in char.dat and your dungeon data file.
So it follows that you can #define your own dungeon name, which will be essential when we come to link the dungeon data file to the terrain data file.
Stick to upper case lettering when adding a new #define, and be sure to put an underscore when separating words.
Dos and don'ts: be sure items that are enumerated follow a nice numerical sequence e.g. 1, 2, 3, 4, 5; or 2, 4, 8, 16, 32;, rather than 1, 2, 5, 7, 8;.
If we wish to refer to a particular dungeon in the code itself, say in game.cpp, then the code will need to know about it, and so a #define will need to appear in ivandef.h before compiling the game.
owterra.dat
The data file owterra.dat contains the "over-world terrains" of the IVAN world map. These are so named, because they become the little pictures that sit over the ground terrain on the world map. They denote the
A worked example
Known limitations
As of 0.50.6, the number of slots is 32.
Overflow of number of dungeons. Ways in which this can happen.
Population distribution of terrain types collected by the sampling algorithm.
