Go to the first, previous, next, last section, table of contents.

Buildings and Rubble Piles

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.


Go to the first, previous, next, last section, table of contents.