Demo 1 - Monster

The Monster Example. The GIGL source (left), the C++ interaction (top-right), and an execution I/O example (bottom-right).

View the GIGL source file in the Git repo

Instructions:

• • As a demo, the first step is to try compiling and running the given project. For instructions and tips about demos please refer to [Here].

  • When running the demo, it will ask for two integers as random seeds. The I/O process is encoded in C++ as the top-right of the figure indicates, and the example result is shown in the bottom right of the figure.

  • The same random seed might not give the exactly same result across different environments (difference in C++ library for RNG). The result shown in the figure is done on a Windows machine with Visual Studio 2015. In addition, the development of GIGL might also change some of the ordering of getting random numbers which might also affect the concrete results. Nevertheless, statistically, the results should be of the same distribution, as the semantics of the GIGL code does not change.

  • After the demo is working, you may want to try further reading the GIGL code and/or the notes below to get a better understanding of GIGL's syntax and semantics.

Comments/Notes:

• • Here the (parametrizable) item grammar encoded is

  • Monster:= weakMonster()

  • | strongMonster(Weapon),

  • Weapon:= clubWeapon()

  • | flailWeapon(),

  • where there are two nonterminal types ("Monster" and "Weapon") each with two expansion rules ("weakMonster" and "strongMonster" for "Monster", and "clubWeapon" and "flailWeapon" for "Weapon"). Expanding through "strongMonster" rule requires further expanding its child, a "Weapon" type node. This encode the semantics that a monster can be a strong monster or weak monster, and that strong monster has a weapon which can be a club or a flail while weak monster does not have a weapon. Note that, nonterminal type rule children (those on the RHS of the rule names) must be declared as pointers, such as the "weapon" on Line 15.

  • Here the only node attribute is "damage" (Line 5), which is a variable attribute, which is a little different from the functional attribute introduced in the previous HelloWorld example. Variables are used to store information while functions are used for computation. Variable attributes often have their values determined when the item is being generated, while functions are often used to query afterwards. They can be used achieve the same purpose but there are trade-offs. For a detailed discussion, please refer to [Here].

  • There are two different interfacing functions, "GenerateEasyRoomMonsters" (Line 25 - 30) and "GenerateHardRoomMonsters" (Line 32 - 37), each of which uses a different configuration. The first configuration is very biased towards generating weak monsters, and the strong monsters always has a club weapon (which has lower damage than a flail weapon). The second configuration has more weight on generating strong monster (compared to the first configuration) and they can have flail weapons. This is an example of modularity provided by GIGL framework, i.e. it separates the item type with the generator configuration, so that multiple different configuration can be used with the same item type. (You may even try to create your own configuration following this pattern.)