People have expressed interest in how moddable and extendable Goblin Camp will be, so I thought to show how things work right now. The specifics will change, as I’m still undecided on whether everything should be defined in XML files or using the libtcod file format. Personally I’m leaning towards the libtcod format. I think it’s slightly more readable than XML, and has built-in support for libtcod types. The differences aren’t major, though, so if a clear majority would rather have all the data as XML it won’t be a problem.
Anyway, on to the specifics, and we’ll start with Items.
Item Categories
The Items XML file is split into two parts: First come the category definitions, which right now consist only of a name for the category.
<category>
<name>Wood</name>
</category>
My plan is to add category specific attributes, such as <flammable> to category ‘Wood’.
Items belong to one or more categories. For example, a wooden door would belong both to category ‘Wood’ and category ‘Door’, while a stone door would be in ‘Stone’ and ‘Door’. With category specific tags like <flammable>, a wooden door will be flammable because it is wood, while a stone door won’t be, but both will function as doors. This means that I don’t need to individually tag each wooden item as flammable, instead I only need to make sure that wooden items are in the ‘Wood’ category.
Item Types
Specific items have a wider variety of tags right now, we’ll take the aforementioned wooden door as the first example:
<item>
<name>Wooden Door</name>
<category>Wood</category>
<category>Door</category>
<graphic>197</graphic>
<color>
<r>255</r>
<g>73</g>
<b>7</b>
</color>
<components>
<comp>Plank</comp>
<comp>Plank</comp>
</components>
</item>
The graphic is given as a number that specifies which tile to use from the font. This will probably change, depending on how tiles are implemented.
The <color> tag specifies a default color for the item, but the actual color you see ingame is actually derived from the colors of the components.
The <components> list is a list of items specified by their item category. They are what is required to actually produce this item at a workshop.
This is all probably quite clear, so let’s take a look at some of the other tags that have been implemented. For example the item ‘Wine ‘.
...
<comp>Berry</comp>
<comp containin="true">Liquid Container</comp>
</components>
<multiplier>10</multiplier>
...
The ‘Wine’ item has berries as components as expected, but the interesting part is the Liquid Container component. It has the attribute “containin” which directs the workshop to place all the created product(s) into this container. So being a component, a Liquid Container (see. barrel) is required to create Wine, but instead of being used up in the process it is used to store the created Wine (wouldn’t make sense to just pour it on the ground, now would it!).
The <multiplier> tag specifies that instead of creating one unit of Wine, we actually receive 10 units of Wine from these components.
Growable crops are defined as items as well. They have specific tags:
<growth>
<fruits>
<growth> specifies if, and what this plant (or seed) grows into. You can define as long a chain of growth as you like, for example: seed -> sprout -> young shrub -> shrub
The <fruits> tag specifies if and what fruit grows on this plant. It is also used to specify if an item leaves something behind after being used. You’ll use this to both define, for example, that berries grow on a shrub and that the berries in turn leave seeds behind.
Organic items such as berries won’t stay fresh and edible forever, and this is where the <decay> tag comes in. Here’s an example from the ‘Corpse’ item:
<decay>
<speed>4</speed>
<item>Bones</item>
<item>Filth</item>
</decay>
<speed> governs how quickly the item will decay, and the <item> tags specify what the item decays into. Filth is a special case, it isn’t actually an item but it’s own semi-liquid object.
Constructions
Here’s an example of what construction definitions look like right now. I’ve already planned to expand some tags, such as <walkable> into being a more specific tag. Right now it’ll tag the whole construction as walkable, but I want finer control so it’ll be extended to allow you to specify which parts are walkable and which aren’t. The tags should for the most part be quite self-explanatory:
<construction>
<name>Carpenter's workshop</name>
<graphic><g>3</g>
<g>35</g><g>46</g><g>177</g>
<g>35</g><g>67</g><g>46</g>
<g>178</g><g>46</g><g>177</g>
</graphic>
<products>
<prod>Wood plank</prod>
<prod>Wooden door</prod>
<prod>Wooden barrel</prod>
<prod>Crate</prod>
<prod>Wooden bed</prod>
</products>
<walkable>true</walkable>
<maxCondition>90</maxCondition>
<materials>
<mat>Log</mat>
<mat>Log</mat>
<mat>Log</mat>
</materials>
<productionSpot><x>1</x><y>1</y></productionSpot>
</construction>
The <graphic> tag is a bit cluttered right now and won’t stay like that. I’ll revamp it once the choice is made on the file format. Right now the first value is how long each row is, and after that the numbers are the same as with items. Right now it only allows constructions shaped as rectangles.
The <products> tag lists all the items the construction can produce, <materials> what is required to build the construction, and the <productionSpot> tag specifies where an orc has to actually stand in order to use the construction.
Creatures are an example of the libtcod format:
Creatures
Here’s what an orc’s definition looks like:
npc_type "orc" {
expert
needsNutrition
generateName
name="orc"
speed="1d20+40"
color="0,0,255"
graphic='o'
health=200
AI="PlayerNPC"
attackSkill="1d10+5"
attackPower="5d5+5"
defenceSkill="1d5+5"
}
The ‘generateName’ flag means that instead of giving each orc the name ‘orc’ the game should generate a name based on the rules given for ‘orc’ names. I won’t get into name generation, but it’s pretty straightforward and also completely moddable.
The stats (speed, attackSkill, etc) are given in dice format, though they can be given as normal numbers as well. The format is [amount of dice] d [faces on dice] +/- [number], so 1d20+40 will give numbers from 41 to 60, while 5d5+5 has a range of 10 to 30
The AI tag specifies the creature’s behaviour. In addition to the player’s creature AI I’ve implemented peaceful animals, hostile animals and hungry animals (hungry animals are hostile animals which try to get at your food stockpiles, if you have any). Obviously more will come.
Wild Plants
A quick note on wild plants, which are separate from crops. They are defined in their own XML file, wherein you can define what the plants give when harvested/cut, what their rarity is and if they appear in clusters (also the cluster size).
Feedback
Right now the question is, which format to go with. XML which I began with, or libtcod that I used for creatures? For example, libtcod allows for easier to write lists (not so many tags):
list= [ "value1","value2","value3" ]
Also the fact that it supports both the libtcod color and dice types is a nice addition.
Visit the forums to voice your opinion, as well as post any questions, comments or criticisms.
