To give the monster something to do besides walk around, add buildings as a new unit type:
(unit-type building (image-name "city20")) (table independent-density (building street 500))
The building
type uses an icon that is normally used for a
20th-century city, but it has the right look.
The independent-density
table says how many buildings will
be scattered across in the world.
The table
form consists of the name of the table followed by
one or several three-part lists;
the two indexes into the table, and a value. In this case, one index
is a unit type building
, the other is a terrain type street
,
and the value is 500
, which means that we will get about 500
buildings placed on a 100x100 world (look up the definition of this table
in the index).
You need some for testing purposes, otherwise you won't see any when you
start up the game.
We're going to let buildings default to not being able to do anything, since that seems like a reasonable behavior for buildings (although Baba Yaga's hut might be fun...).
By default, buildings act strictly as obstacles; monsters cannot touch them, push them out of the way, or walk over them. In real(?) life of course, monsters hit buildings, so we have to define a sort of combat.
(table hit-chance (monster building 90) (building monster 10) ) (table damage (monster building 1) (building monster 3) ) (add (monster building) hp-max (100 3))
The hit-chance
and damage
tables are the two basic
tables defining combat. The hit chance is simply the percent chance
that an attack will succeed, while the damage is the number of hit points
that will be lost in a successful attack. The unit property hp-max
is the maximum number of hit points that a unit can have, and by default,
that is also what units normally start with.
Note that the add
form allows lists in addition to single
types and values, in which case it just matches up the two lists.
The add
tries to be smart about this sort of thing; see its
official definition for all the possibilities.
The net effect of these three forms is to say that a monster has a 90% chance of hitting a building and causing 1 hp of damage; three such hits destroy the building. A monster's knuckle might occasionally be skinned doing this; a 10% chance of 3/100 hp damage is not usually dangerous, and feels a little more realistic without complicating things for the player.
Now you can start up a game, and have your monster go over and bash on buildings. Simulated wanton destruction!
By default, a destroyed building vanishes, leaving only empty terrain behind. If you want to leave an obstacle, define a new unit type and let the destroyed building turn into it:
(unit-type rubble-pile (image-name "???")) (add building wrecked-type rubble-pile)
In practice, you have to be careful to define the behavior of rubble piles. What happens when a monster hits a rubble pile? Can the rubble pile be cleared away? Does it affect movement? Try these things in a game now and see what happens; sometimes the behavior will be sensible, and sometimes not.
For instance, you will observe that the default behavior is for the rubble pile to be an impenetrable obstacle! The monster can't hit it, and can't stand on it, and in fact can't do anything at all. OK, let's fix it. Monsters are agile enough to climb over all sorts of things, so the right thing is to let the monster co-occupy the cell that the rubble pile is in. The default is to only allow one unit in a cell, but this can be changed:
(table unit-size-in-terrain (rubble-pile t* 0))
This says that while all other units have a size of 1, rubble piles only have a size of 0. By default, each terrain type has a capacity of 1, so this allows one unit and any number of rubble piles to stack together in a cell.
If you try this out, you'll find that the monster can now cross over rubble piles, but still has to bash buildings in order to get them out of the way.
Incidentally, it can cause problems to set a unit size to zero, because it allows infinite stacking. Since buildings and rubble piles don't move, there will never be more than one in a cell, but Xconq will happily let hundreds of units share the same cell, which works, but causes no end of headaches for players confronted with overloaded displays.