Now you've got an "interactive experience" but no game; there's no challenge or goal. You could maybe make a two-or-more-player game where the players race to see who can flatten the mostest the fastest, but that's still not too interesting to anyone past the age of 5. Instead, we need to make some units for the people bravely (or not so bravely) resisting the monster's depredations:
(unit-type mob (name "panic-stricken mob") (image-name "mob")) (unit-type |fire truck| (image-name "firetruck")) (unit-type |national guard| (image-name "soldiers"))
Note that a type's name may have an embedded space, but then you have to put vertical bars around the whole symbol (a la Common Lisp). Things are starting to get complicated, so let's define some shorter synonyms:
(define f |fire truck|) (define g |national guard|) (define humans (mob f g))
You can use the newly defined symbols f
and g
anywhere in place of the original type names.
The symbol humans
is a list of types, and will be useful
in filling several propertys at once.
As with monsters, all these new units should be able to move:
(add humans acp-per-turn (1 6 2))
The speeds here are adjusted so that monsters can chase and run down (and presumably trample to smithereens) mobs and guards, but fire trucks will be able to race away.
Also note the use of a three-element list that matches up with the
three elements in the humans
list. This is a very useful
features of GDL, and used heavily. It can also be a problem,
since if you add or remove elements from the list humans
,
every list that it is supposed to match up with also has to change.
Fortunately, Xconq will tell you if any lists do not match up
because they are of different lengths.
We still need to define some interaction, since monsters and humans can make faces at each other, and get in each other's way, but otherwise cannot interact.
(add table hit-chance (monster humans 50) (humans monster (0 10 70)) )
This time we have to say "add table" because we've already defined
the hit-chance
table and now just want to augment it.
As with the addition of properties, we can use a list in place of a single type.
Last but not least, we need a scorekeeper to say how winning and losing will happen. This is a simple(-minded?) game, so a standard type will be sufficient:
(scorekeeper (do last-side-wins))
The do
property of a scorekeeper may include some rather elaborate
tests, but all we want to is to say that the last side left standing
should be the winner, and the symbol last-side-wins
does just that.
There might be a bit of a problem with this in practice, since in order to win, the monster has to stomp on all the humans, including fire trucks. But fire trucks can always outrun the monster, and cannot attack it directly either, which leads to a stalemate. You can fix this by zeroing the point value of fire trucks:
(add f point-value 0)
Now, when all the mobs and guards have been stomped, the monster wins automatically, no matter how many fire trucks are left.