|
3D Puzzle Scripting |
Page 1 of 7 |
|
|
|
 |
|
|
|
|
 |
|
At the core of any level designer (wannabe coder) is the ability to script and luckily
over the years the tools have gotten better. Originally scripting was more like coding with large
blocks of text, but that changed with
CryEngine
Flowgraph
and
Unreal
Kismet
visual 2D scripting systems.
I have always wondered about the possibilities of 3D scripting with the logic functions
defined in 3D space. I started experimenting with puzzles using a small set of entities
to see what stuff I could create and the initial tests were a lot of fun,
so I decided to build a bigger project.
|
|
Click on the above image for a larger version |
|
|
 |
|
Game engines are usually split into single or multi-player designs and
their internal functions often reflect this difference. Sometimes with
a bit of creative thinking some engines can be made to do things
they were not designed for and the map
Edge of Forever was that experiment.
The Quake 3 engine does not have a 'true' single player campaign and most of the game logic
is done within the code base. Adding new functions to the engine would either require
more code (engine update or MOD) or using the existing map entities in a different way.
|
|
Click on the above image for a larger version |
|
|
|
 |
|
|
 |
|
|
|
|
 |
|
The first step to creating Q3 puzzle logic is being able to test conditions with an
IF statement.
An entity with this function must be triggerable and be able to affect
other entities.
The target_shooter entity fires a missile in a certain direction
using an angle key or towards a targeted info_notnull entity. The shooter entity
comes in three different flavours as follows:
Grenades: are slow to fire and unpredictable
Rockets: are slow but can be directed
Plasma burst: are fast and easily directed
|
|
|
|
 |
|
|
 |
|
|
|
|
 |
|
Once the IF entity (target_shooter) has been triggered the next step is to
get a result. An entity with this function must be triggerable via
damage from the target_shooter missiles.
The func_door and func_button entities can be
affected by the missile fired by a target_shooter and also switch
between different (open / close) states. The problem is that they do not
maintain this state and are eventually (wait key) reset back to their
initial position.
|
|
|
The func_door and func_button entities are both created from
3D objects (brushwork or models) and have some similarities,
but behave differently depending on what keys they have defined.
|
|
| Key |
func_door |
func_button |
| Spawnflags |
Start_Open (Reverse) Crusher (Block dmg) |
n/a |
Trigger Default |
+ Player Proximity Trigger
+ Damage Trigger |
+ Player Touch Trigger
|
Health
|
– Player Proximity Trigger
+ Damage Trigger |
– Player Touch Trigger
+ Damage Trigger |
Targetname
|
– Player Proximity Trigger
– Damage Trigger*
*Health key overrides |
No change |
| Target |
Trigger target |
Trigger target |
| Lip |
8 (default) |
4 (default) |
| Speed |
300 (default) –1 = instant |
40 (default) –1 = instant |
Wait
|
2s |
1s |
|
|
|
|
 |
|
|
 |
|
|
|
|
 |
|
The final piece to the Q3 logic puzzle is the ability to store results
in variables that can be tested with the previous IF statement logic. An entity with this
function must be triggerable and be able to switch between an on and off state.
The func_timer entity can work with either the func_door or the
func_button entities and also be toggled between an on / off state
creating binary variables. Based on the value of the wait
key the func_timer, will re-trigger (when on) all of its targets
maintaining their state.
|
|
|
 |
|
The func_timer entity is not triggerable to exact states and any
associated logic will have to keep track of its current setup.
The func_timer wait key value has to be less than the targets wait
key otherwise the re-triggering will not work correctly. A time
difference of 1-2 second should be enough and the time required to
switch states will be based on the value of both wait keys. This is not a
quick state change process and should be considered when designing puzzles.
|
|
|
|
 |
|
|
 |
|
|
|
|
 |
|
With all the puzzle logic entities defined the next step is to create a simple
example:-
A locked door has to be opened by two switches which can be used in any order.
All puzzles can be broken down into a series of
logic gates
and this example can be designed with two.
The target_shooter (pink square) entity is being activated by two
target_relay entities (cyan square) to create an
OR gate.
The two func_buttons (purple/red) are both required to complete
the puzzle like a
AND gate.
|
|
|
Feedback is an important feature of puzzles design and should
not be overlooked. It can be a simple case of letting the player know how
far through the puzzle they are or if they are using the right components
of the puzzle in the correct order.
|
|
|
|
 |
|
|
| Articles |
 |
 |
|
| Links |
 |
 |
|
| Archive |
 |
 |
|
|