|
|
|
|
All use of my digital work is covered by this
Creative Commons Deed.
Please do not use any of my work for commercial purposes, thank you. |
|
|
|
|
Example Puzzle 3 (Page 5 of 7)
|
|
|
|
|
|
|
|
 |
|
|
|
 |
|
|
Taken from the map - Edge of Forever |
|
The room consists of four chains supporting heavy weights which are
locking an iris in the floor and surrounded on all sides by buttons.
The puzzle starts when the player uses any of the four buttons
around the iris on the floor. The buttons are linked to the closest
chain and when used the chain to the left and in front are also affected. The
puzzle is complete when the iris is not blocked by any weights and chains.
|
|
|
Click on the above image for a larger version |
|
|
 |
|
 |
|
|
All entities used for the puzzle logic |
|
What the entities look like |
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
 |
|
Most games present the player with a locked door and simply expect them to find
the key. Opening a door with a key is not really a puzzle, but solving the mechanics
could be fun and a good example of a lock is the
pin tumbler
or Yale.
The mechanics is a rod (key) with several ridges that push a set of pins (inside
of the lock) upwards allowing the rod to rotate. Taking the
ridges on the key and converting them into a row of numbered switches could be
a good starting point for a lock puzzle.
|
|
|
 |
|
When the player is shown a row of switches they usually expect the combination
to be written down somewhere. No one wants to guess an exact combination, it can be
time consuming and not much fun, but getting all the switches to the same value
is relatively easy.
Show a row of binary switches to a player and their first choice will probably
be to switch everything to the same value. This human instinct for visual lines
can help negates the reason for writing down the combination somewhere.
|
|
|
 |
|
The problem with binary switches is that they are really easy to solve
and adding more switches just makes the task a chore. Most games use rotating
dials because they offer more solutions and need fewer rows of switches.
Unfortunately the Q3 engine does not support rotating objects or switches
with multiple states. A solution to this problem is to use the idea
of rotation, but apply it to multiple switches instead. So when the player
uses a button it will affect multiple switches at the same time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
At the center of the puzzle is a row of switches arranged in an
AND logic gate
to keep track of progress. The open state of the switches is
maintained by a func_timer entity which is set to a very low
wait value. Not an ideal situation, but needed so that the lock
can be checked quickly.
When the state of each switch is changed a target_delay entity is
triggered that tests if the puzzle is complete or not. The delay
is because several switches can be triggered at once and the time to
switch states is not instantaneous. |
|
|
 |
|
Each floor button has a target_shooter that triggers a
func_button and eventually the relevant func_timer entity.
The extra layer of target_relay entities are used because the
func_timers are triggered from several different sources.
The button trigger logic is setup in the same layout as the puzzle mechanics
are in the actual map. Part of the fun (for me) with 3D scripting is that the
flow of the entity logic can mirror the actual map layout and be easier to understand
when creating it.
|
|
|
 |
|
A large blocker entity is set up to control when the
button triggers are active. This was designed to stop
the puzzle when finished, but was changed later because
of button overload problems.
Some players liked to run around like headless
chickens and hit all the buttons to try and solve the puzzle.
This caused the puzzle to overload and go out of sync with
some of the chains in the wrong position. When the switches
are changed, a safety target_relay entity locks the
puzzle for a short period of time to prevent button overload.
|
|
|
|
|
|
|
|
|
|
)
