Educational Scenarios

Installation

You need Eclipse Europa (3.3) for RCP/Plug-in developers. You can either download it from Eclipse Europa download site or use the copy provided on this CD. Extract the zip archive into a directory of your choice (e.g. C:\Program Files\eclipse).

Another requirement is Unreal Tournament 2004. Follow the instructions on the installation DVD. After that apply the 3369 patch from ut2004-winpatch3369.exe.

After these two are installed, run the es-setup.exe, select the directories and install it. Everything is ready now.

Running the scenario

Creating your own scenario

    rule "unique rule name"
        modifiers
        when
        conditions
        then
        commands
    end
    

    when
        condition 1
        or
        condition 2
    then
    

    when
        condition 1
        (condition 2
        or
        condition 3)
        condition 4
    then
    

Unlike in the LHS, the order of commands in RHS is very important. Each command must be written in a single row and they are executed in a top-down order. The complete list of currently supported commands is here.

Modifiers alter the way how the rules are executed. For the complete list look into the Drools documentation but for you can be important these two:

• salience number: This modifier determines the order of rules in which they should be fired. The default salience is 0. If the LHSs of multiple rules are satisfied at one moment the first rule which is executed is the one with the highest salience and so forth.
• no-loop: When the RHS of rule is executed it could modify the objects that the conditions are testing. This would result in another firing of this rule. This modifier prohibits such behaviour. Nevertheless, when such modification fires second rule, its commands can modify the conditions for this (first) rule and it can fire again. The no-loop modifier does not prevent such behaviour.

If you want to write your own comments (what is strongly recommended) or remove some condition or command for debugging purposes (you want to add it again in the future), start the line with sharp character #. Everything between the sharp and the end of line is considered as comment and Drools ignore it.

And this is everything you need to know to start writing rules. Just a little advice: Do not try to write the whole scenario all at once. Start with one "Hello world" rule and after every one or two rules test if it works. You can also use debugging command log "message" to make sure the rule fires or does not.

Configuration file

The configuration file gathers general information about the scenario - mostly links to other files and general settings. It is a XML file where the top element is scenario with language attribute. Currently supported is only english. The scenario can contain these sections (tags):

• Players has two attributes: min sets the minimum number of players that must be joined to start the scenario, and max which sets the maximal number of players for the scenario to be started.
• Rules gathers all rule files and specifies their DSL in the attribute dsl.
• Package denotes one rules file with its attribute src.
• Scenes contains all acts. See below what is the act.
• Act is some part of the story. There are two reasons to write the structure of the scenario down. The first is to help you plan that out. Sketching of the scenario before the implementation eases thinking the scenario over. The second reason is to simplify referring to parts of the story. One act can contain multiple other acts - e.g. scenario “workday” should include acts “morning”, “work-shift” and “evening”, where “morning” includes “waking up”, “breakfast” etc. The workday is in one of these states in each moment. But when you are breakfasting it also means that it is morning, too. The questions whether the scenario is performing the act that is superior to the performed act are answered positively.
  Nevertheless, such straight division is frequently not enough. When you see a car rushing at you, you will jump out off the road regardless of whether it is morning or evening and then continue with previous tasks. That is why the scenario can be in multiple different acts but it has to be from different act tree (the two acts have no common superior act). The acts are identified by unique id attribute.
• Maps gather the map files.
• Map links with the src attribute to one map file.

Map files

It would be very uncomfortable to use commands as "if the player is in rectangle specified by coordinates 324, 5654, 756, 6544" and such. That is why all these coordinates are stored in a file called map file. More accurately, there can be more of such files but the information from them are merged during the loading.

The parts of space are called areas. There are two basic types of them: simple areas and complex areas. The simple areas are rectangles, circles and polygons and you usually do not assign a name (ID) to them. The complex areas do not have coordinates - they are specified by their subareas. These subareas can be also complex areas or simple ones. They form a tree-like structure: simple areas form streets, squares, parks and such, these form districts and districts form a city. This partitioning is up to you - nothing forces to have three levels, you can have two or fifty of them.

Sometimes you would like to have some point marked on the map or refer to the point in the scenario. These are called POIs - points of interest. You can also set their symbol, color and description.

Similar to marks are paths. These are broken lines displayed in the map. You can set their color and width. Unlike the POIs you cannot refer to them in rules because they have not a single position.

You do not have to edit the map manually, there is an editor provided. See the map editor documentation.

Deployment

Contact and support