The GIVE game world
- 1 The GIVE game world
- 1.1 World state
- 1.2 Actions
This document describes in detail how a GIVE game world is encoded in a World object.
The general approach is that the world state is encoded as a set of ground atoms such as in-room(b1,room1). Depending on the parameter types, the arguments of a predicate may be either logical constants (such as b1), 3D positions such as (1,0,-1.5), or 3D orientations such as [1,0,-1.5]. We generally write constants in this font, positions with round brackets, and orientations with square brackets. Each world has a universe of logical constants that it knows about; each constant has a type (such as "button" or "wall"), and these types are arranged in a type hierarchy. World has methods for asking about the universe, the types of objects, and the type hierarchy.
We will first describe the possible atoms, and then we will discuss the actions that can be executed to change the world state. As a running example, the map of the GIVE development world looks as follows:
World state
Below, we document the atoms we use in GIVE-2. We write a, a1, etc. to range over individuals, p to range over positions, o to range over orientations, and x to range over other things (such as color names).
| atom | description |
|---|---|
| button(a), wall(a), etc. | P(a) means that a is an object of type P. The object types that are used in the development world are: "alarm" (an alarm tile on the ground), "button", "chair", "couch", "door", "flower", "lamp", "picture", "room", "safe", "stateless-button" (a button that only triggers an effect when pressed, but doesn't change its state), "trophy", and "wall". |
| position(a,p) | The individual a is at position p. The position can be retrieved with getPosition(a). |
| player-position(p) | The player is at position p. This position can be retrieved with getPlayerPosition(). |
| orientation(a,o) | The individual a faces towards orientation o. The orientation can be retrieved with getOrientation(a). |
| player-orientation(o) | The player faces towards orientation o. This orientation can be retrieved with getPlayerOrientation(). |
| state(a,x) | The state of individual a is x. The states that an individual can have depend on the type of the individual: doors and pictures can be open and closed, buttons can be on or off, alarm tiles can be "alarmed" or "nonalarmed", and the safe in the current development world can have the states safe-state-1, safe-state-2, etc. up to safe-state-5, and safe-state-open. In the evaluation world, a safe may have different states on top of these. The current state of an object can be retrieved using the getState method. |
| color(a,x) | The value of the "color" attribute for individual a is x. Currently, GIVE knows about the colors "red", "green", "blue", and "yellow". Right now, color is the only attribute that we use in GIVE, but we may add more attributes for the evaluation worlds. In this case, we will continue to follow the pattern of writing "P(a,x)" to encode that the value of a's P-attribute is x. You can retrieve attribute values with the getValue method: getValue(a,P) will return x. |
| in-room(a,b) | Object a is inside room b. |
| controls(a,b) | Pressing the button a will change the state of the object b (e.g. a door). |
| positive-room(a,b), negative-room(a,b) | If a is a wall-like object, i.e. a wall, safe, or door, it has two sides. The positive side is that side which faces in the direction of a's orientation vector; the other side is the negative side. positive-room(a,b) records that the room on the positive side of a is b; the negative case is analogous. Note that this means that walls with orientations [-1,0,0] and [1,0,0] have reversed positive and negative sides, even though they look identical in the client. |
| lost | The player has lost the game by stepping on an active alarm tile or pressing an alarmed button. |
| holding(a) | The player is holding object a. |
| accessible-if-state(a,b,s) | Object a can only be touched if object b is in state s. This is used, e.g., to specify that the trophy (a) can only be accessed if the safe (b) is open (s). |
| start-tile(p) | Specifies the position at which the player starts the game. |
The following atoms are part of the world state, but they specify the effects of certain actions rather than representing the actual, dynamically changing, world state.
| atom | description |
|---|---|
| manipulate-effect-state-change(a,b,s1,s2) | Pressing a (typically a stateless button) changes the state of b from s1 to s2. |
| state-change-effect-state-change(a,s1,b,s2) | If the object a (typically a stateful button) changes its state to s1, then the object b (perhaps a door or a picture) changes its state to s2. |
| state-change-effect-move(a,s,b,p) | Manipulating a (typically a stateful button) such that its state changes to s will move the object b to position p. |
| state-change-effect-turn(a,s,b,o) | Manipulating a (typically a stateful button) such that its state changes to s will move the object b to orientation o. |
| state-change-effect-alarmed(a,s1,b,s2) | If object a changes its state to s1, then b (and its region) will change its alarm state to s2. |
| state-change-effect-blocking(a,s1,b,s2) | If object a changes its state to s1, then b (and its region) will change its blocking state to s2. |
| manipulate-effect(a,p) | Manipulating a (typically a stateless button) adds the atom p() to the current state. The typical pattern for using this is "manipulate-effect(b1,lost)", where b1 is some button; pressing this button will then trigger the alarm and make the player lose. |
| next-state(s1,s2) | If an object is in state s1, and its state gets changed, then it will go into state s2. For instance, there is an atom "next-state(open,closed)". |
There are also some special facts, which can be queried using the isTrue method but aren't reported by getTrueAtoms. However, when the current world state is discretized into a planning problem, all (discretized) instances of these atoms are generated for the planner to see.
| atom | description |
|---|---|
| adjacent(r1,r2,s) | Regions r1 and r2 (which are specified via their names) are adjacent, and the connection is in blocking state s. That is, if s is the constant "blocked-state", then it is not possible to walk from r1 to r2, e.g. because there is a closed door between them. Otherwise, s is the constant "non-blocked-state". |
| near-object(a,r) | Object a is "near" the region r. This means that a player standing in region r is close enough to a to interact with it (by clicking on it with the mouse). |
| alarm-state(r,s) | The alarm state of the region r is s. If s is "alarmed-state", this means that r is completely contained in an active alarm tile; entering the region will trigger the alarm. Otherwise, s is "non-alarmed-state". |
| connects(o, r1, r2) | Object o connects the regions r1 and r2. This is usually the case when o is the door that connects these two regions. |
Actions
When the Matchmaker loads an virtual environment from a file, it automatically computes a number of actions that encode what the player can do in this world. Each action that the user takes in the 3D client is translated into one of these actions; these same actions are also used by the getPlan method to compute a plan towards the goal. The only difference is that the action instances computed by the client (and passed on e.g. to handleAction) use 3D positions and orientations, whereas the action instances that the planner computes use discretized names for these positions and orientations.
GIVE-2 uses the following actions:
| action | description |
|---|---|
| move(p1,p2) | Move the player from the region p1 to the region p2. This is only possible if p1 and p2 are adjacent, and the path between them is not blocked. This action is only used in the planner; movements in the 3D client are not represented as explicit actions, only through the regular status updates. |
| manipulate(a,s1,s2,p) | Click on the object a, changing its state from s1 to s2, while standing at position p. This is only possible if a is currently in the state s1; in particular, the action can never be applied if a has no state. p is the player position; this position must be close enough to the object to touch it. |
| manipulate-stateless(a,b,s1,s2,p) | Click on the stateless object a which controls the object b while standing at position p, changing the state of b from s1 to s2. Notice that a must be stateless, but b must be in state s1 when the action is executed. |
| manipulate-stateless-a(p) | Click on the stateless object a. This is a special case of the "manipulate-stateless" action in which a doesn't control another object. Notice that "a" is part of the action name in this case, and not a parameter. |
| take-a(p) | Click on the trophy a, picking it up, while standing at position p. The trophy must be accessible, and the player's position must be close enough to it to interact with it. |
