-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathNotes
67 lines (56 loc) · 2.82 KB
/
Notes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
COMTROLS:
- HELP: shows standard help, not contextual
- EXIT: exits game after confirmation with "yes or "y". Resumes play with "no" or "n".
After 3 prompts with indefinit answer continues
- HINT: shows hitn according to the current progress
ACTIONS:
1(0) Argument
- LOOK: short description of object. If it's scene lists all contents Objects.
- EXAMINE: long description of object.
- PICK_UP: Only items can be picked up, item is than in the inventory
" You pick up {item}"
- GO: change of location if it's a scene, otherwise not relevant
"You are at {location/item}"
- OPEN: Only items can be closed, causes a status change of object
"You open {item}"
- CLOSE: Only items can be closed, causes a status change of object
"You close {item}"
- PUSH: Only items can be pushed, causes a status change of object
"You pushed {item}"
- PULL: Only items can be pulled, causes a status change oj object
"You pulled {item}"
- TALK_TO: Only persons/animals/telephone can be talked to
- USE: There is another version with 2 arguments
2(1) Argument
- COMBINE: combines to items. Items has to be in reachable limit
" You combine {item1} and {item2} into {newitem}"
- GIVE: gives an item to a person/animal
" You give {item} to {person/animal}"
- USE: uses item on another item like :use key on door, use key with door
" You used {item} on {item}"
- PUT
INTERFACE:
The interfaces define if a certain action can be generally performed by this object.
This is handeled by the instanceof checks in Enum Action.
Otherwise the executable list specifies if this action can be performed in the current state of this object.
This is handled by the object themself.
PROCESS:
Questions:
Objects contain their description and their executable actions. Should actions contain the object which can be performed on?
build.Game creation is more intuitiv by object, whereas game play is more intuitiv by action.
Where should status be saved? Ideally in the build.Game Class as it saves the play in independently.
How should the structure look like? Are 2 lists discovered and reachable enough to represent all states?
It's easiest if 1 Argument actions are performed by their object.
Possible clash occurs if 0 Arguments are given. This can happen to LOOK and EXAMINE.
Which object is referred to? Last item or last scene? -> needs to be clarified
2 Argument ACTIONS are better performed by action. COMBINE should have combination table or lists.
How should CONTROLS be performed?
- Missing:
- put action, like putting something somewhere
- handle unclear command where object posses the same name
- synonymes and spell checker(levenstein)
PROBLEMS:
- Use exists as a TwoPredicate and OnePredicate. Use key/ use key on door
- similar to open: open door/ open door with key
- how do i handle two words? like pick up, walk to, look at
- move means push or pull, move to means go, how to determine?