SimonOC - Articles, Puzzle Logic Page 1


			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.

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

IF condition

			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

THEN action!

			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

Switching Sides

			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.

Puzzle-Gate

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.