Hi there,

i've been wanting to code an engine for a point-and-click adventure for over 10 years (and have been trying it a lot of times), but i'm not quite sure how to handle the riddles. i've been coding a lot, but i didnt really learn it, so it's mostly self-taught and i dont see if i'm doing something horribly wrong in my concept.

this is where i need help, opinions and hints: can it work? do i oversee anything that might 'break my neck' after 50 pages of code, like 'duh, i should have thought of that from the start... now i can do it all over.'

------

this is my usual approach (i've done it in visual basic 6 most of the time):

objects have a parameter called "action" (or such), which means if the user clicks on them, the action is done. there are (for example) "GoToScreen #xxx" or "show LookAtObject-text" or "take Object" (if its takeable). the objects have "triggers" (i'd rather called them Events, but i didnt think of that at the time), which can change properties of objects (see below) or simply show texts or so.

a example would be: opening "Door #xxx" wont work (object-action "GoToScreen #xxx" is disabled), but picking up a key calls the Event "set Door #1 GoToScreen True".

------

i have a real problem thinking of anything that wont work if i code it in this fashion, but i also think the adventure-genre is very old and there is a perfect "recipe" doing the riddle-system. i have searched to much for something like this, but never found anything.

i would very much appreciate anything anyone has to say to my problems, thanks in advance!

There is nothing mysterious about it, and differences between text adventures, point-&-click adventures, and 3D RPGs are not existent at that level. You are in fact right with your assumption about the versatileness of the chose approach. However, there are some details of interest.

The world state is the overall value of all variables that define each and every dynamic aspect of the world; e.g. whether a door is locked, whether a gate is open, whether a NPC is dead, whether a quest is solved, but also non-boolean aspects like how many gold coins are at a given place, the room number where the PC currently is, and so on. The word state can exist distributed, but saving and restoring a game is much easier if it is concentrated instead. If the gameplay is hardcoded, then the world state may be an object with a variable for each aspect. If it is data driven, then it may be a map (i.e. string key to value object).

The values of the world state have a type like boolean or integer, a name (either the hardcoded variable name or the string key), but they have no explicit semantic. Instead, the semantic is given by the use. If the action "open the door" has a condition that checks a boolean state variable and denies opening the door if the variable state is false, then the variable has the meaning of "the door being locked/unlocked". If the guarding condition of the action resolves to true, then the action can taken place. In this case, the action alters the state of a boolean variable with the meaning of "the door is open". Notice that actions have a pre-condition (of arbitrary complexity) and an outcome. The pre-conditions checks a part of the world state by comparison to a needed state, and the outcome alters a part of the world state.

You may use a kind of planning. For example, the action "go through door" has a pre-condition that requires the door to be open. Let's say the door is closed at the moment. The game may reject the action with the comment "the door is required to be open". So the player issues an "open the door" action. Well, that action is guarded by a pre-condition that requires the door to be unlocked. Let's say it is locked. So the game rejects the action with the comment "the door need to be unlocked first". This can be continued by the need of having a key in the hand and the need of the key matching the keyhole. However, the game may also have some automatisms that beware the player from such micro-management. This is where planning comes into play.

Let's say that there is a pool of pre-defined automatic actions. The player issues the aforementioned "go through door" action. The game determines that it is not possible. So it first looks into its pool of automatic actions and looks for an action with an outcome that would alter the game state so that the issued action is possible. It finds the automatic "open door" action that would do. However, the pre-condition of that automatic actions requires an unlocking, so the game again searches the automatic actions for one, this time one with an outcome that would generate the "door is unlocked" world state. Only if the game could not find a sequence of actions that in its entirety would do, it rejects the originally issued action and give a comment (usually based on how far the search for automatic actions was successful).

Now something else: For a one man team, a one game goal, and the demand of getting the game done, it is mainly okay to do things like the above hard-coded. A more flexible way would be to implement a data driven approach. This has the following advantages: It separates programming and designing the game a bit, so it is easier some people to work on the engine and others to work on the game content. It allows further to use the game engine (with some modifications) also for the next game of the same kind. But is is definitely a harder job for the programmer to get things right, because it is another level of abstraction. But I wanted to mention it here.

thanks for those answers!!

but i fear i haven't explained enough =)

first of all, it's rather the engine i want to code. the game itself... phhhh, i dont even have enough ideas - it's the engine i want to code. even if i dont ever use it =)

the other stuff - i know most of the mechanics, but as i wrote i have problems with putting the riddles in. i have an engine where you can walk around, take objects (plus working inventory) and use objects. but i'm not good enough in coding for example to tell wether i should let the obbjects call the functions to change parameters ("take key" -> the key calls "door is open") or wether the "conditions" should be checked on the user-actions ("open door" -> check if key is in inventory).

is there a "recipe" to do this, or is it just "both works, but one will result in more code" (pc-performance may have been an issue 20 years ago, but as for now, i think memory and such aren't an issue)

… wether i should let the obbjects call the functions to change parameters ("take key" -> the key calls "door is open") or wether the "conditions" should be checked on the user-actions ("open door" -> check if key is in inventory).

Why should "take key" open (or unlock) the door? The action does not imply such an outcome. Doing it nonetheless will confuse the player. The usual way of doing such a thing is like "open door with key" to denote the usage of a tool. This is what the planning approach I've posted above abbreviates. Demanding "open door" is a clear statement of the player what s/he wants to be done, and the planner just figures out if it is possible in the given situation.

An item (useable objects in adventures are often called items) by itself does nothing. Using an item, or more generally performing an action, has an outcome. Whether the action can be performed is situation dependent and hence needs to be checked. Even if you don't use a planner, the basic structure of an action is just this.

ok, i seem to get it: the items (my "objects") dont have any influence. there is another "thing" (a class, a module, anything that works on methods, events and so on), which will enable/disable such things as "open door".

picking up a key is not the way to turn a door from "closed" (aka "you cant move here) to "open" (aka "get the key first, buddy..."), but there is another thing running along the game routine, checking on every user-action, if the conditions are fit?

thas he thing i was asking about - should the items/objects change the conditions, or should there be a "higher instance", which "monitors" that and changes it to get the game going. it seems to be the later one =)

i always thought there is a standart recipe for that, but it just seems to be common sense of coding (as i said, i never was teached how to...=) )

edit:

the "outcome" you say, it is an "event" (?). this has to be handled. i told my objects something like: "if you are picked up, tell the main-engine to show the text 'i better take this!' " or something like that. -- is that too much? i just put parameters and the ability, to change parameters on other objects to my existing items or scenes. thath is what i want to know, should i command the game "from above" (aka every parameter in a module) or should i let the classes work together (aka "the key says, door is open".).