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

The Scenario

As it now stands, your game design requires Xconq to generate all kinds of stuff randomly, such as the initial set of units, terrain, and so forth. However, we are doing a monster movie, so random combinations of monsters and people and terrain don't usually make sense. Instead of trying to define a "reasonable" random setup, we should define a scenario, either by starting a random game, modifying, and saving it, or by text editing. Since online scenario creation is hard to describe in the manual, let's do it with GDL instead.

To define a scenario, we generally need three things: sides, units, and terrain. Now the basic monster movie idea puts one monster up against a bunch of people acting together, so that suggests two sides:

(side 1)

(side 2 (name "Tokyo") (adjective "Japanese"))

The 1 and 2 identify the two sides uniquely, since we'll have to match units up with them in a moment. The side that plays the monster is really a convenience; players should just be aware of the one monster unit, so we don't need any sort of names. The other side has many units, which should be qualified as "Japanese", and the side as a whole really represents the city of Tokyo, so use that for the side's name.

Now for the units:

(unit monster (s 1) (n "Godzilla"))

(unit firetruck (s 2))
(unit firetruck (s 2))

(building 9 10 2)

(define b building)  ; abbreviate for compactness' sake

(b 10 10 2)
(b 11 10 2 (n "K-Mart"))
(b 12 12 2 (n "Tokyo Hilton"))
(b 13 12 2 (n "Hideyoshi's Rice Farm"))
(b 14 12 2 (n "Apple Japan"))
;; ... need lots of buildings ...

This example shows two syntaxes for defining units: the first is introduced by the symbol unit and requires only a unit type (or an id, see the definition in xxx), while the second is introduced by the unit type name itself and requires a position and side. The second form is more compact and thus suitable for setting up large numbers of units, while the first form is more flexible, and can be used to modify an already-created unit. In both cases, the required data may be followed by optional properties in the usual way.

Also, since the word "building" is a little longwinded, I defined the symbol "b" to evaluate to "building". GDL has very few predefined variables, so you can use almost anything, including weird stuff like "&" and "=". Property names like s and n are NOT predefined variables, so you can use those too if you like.

At this point, you should have a basic game scenario, with one player being Godzilla, and the other trying to keep it from running amuck and flattening all of Tokyo. Have fun!

You can enhance this scenario in all kinds of ways, depending on how ambitious you want to get. Given the basic silliness of the premise, though, it would be more worthwhile to enhance the silliness and speed up the pace, rather than to add features and details. For instance, name the buildings after all the laughingstock places you know of in your own town.

To see where you could go with this, look at the library's monster game and its tokyo scenario, which include fires, different kinds of terrain, and other goodies.


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