Map progress is saved in global variables called parm1-16 which are used for storing the inventory (ammo/weapons) and the top 6 (parm11-16) are not used for anything. AD turns the top 'parm' variables into 132 binary (0/1) switches that can be used in any map for internal logic or variables which can be passed between multiple maps. Level designers can access any of the map variables with new entities that can query, toggle or change values.
This is probably the most underwhelming system in AD because I imagine most people don't see what it is useful for. If someone has never fought with map hacking variable systems then its hard to see what the fuss is all about having simple access to map variables.
At the heart of map variable hacks is the fire/damage trigger setup. A map event triggers a "target_shooter" (pink) which then fires in a certain direction (can use angle field as well) using a "info_notnull" (green) that hits a "func_door" entity to create a yes/no answer. The front "func_door" is moved to create a certain state value or variable result (storing a value).
The AD map variable system gets rid of the shooter/bmodel setup and just uses a single entity instead. Map values can be saved or checked and even carried over between maps with a good example being the AD hub maps keeping track of player progress.
With so many map variables to play with (6 banks of 22 values = 132 variables), what can be done with them!?! Well probably the first use that comes to mind is puzzles, but creating engaging and intuitive puzzles is more tricky than it sounds. After a year of prototyping I created
The Edge of Forever which got discussed at
Func_Msgboard and it did not go (excuse my defensive replies) as planned. I found out that puzzle design requires consistent visuals and lots of testing to get right.
To get the ball rolling on puzzle design and AD map variable examples the first map in this pack is "test_mapvar_prism" which was an idea developed for
Imhotep's Legacy by Heresy. I originally thought of the Lara Croft style rotating mirrors and light puzzle setup, but in this example its laser beams being reflected between points to unlock an objective. As the blue blocks (variables) are moved up/down the red beam is extended or blocked based on the state of variables. Probably should be introduced as a single blue block and red beam so that players can understand what is going on and reduce the random button mashing!
The second puzzle example is using func_rotating objects for a 3 barrel lock. The player has to rotate (shoot at them) the cubes with colour surfaces and match the colours to the one's over the door. Once the symbols are correct, the floor opens and the player gets the key to the door. Each rotating block is stored as a variable and when all 3 are the correct value, then the key is unlocked. This should probably be presented as a single rotator first so that the player understands the mechanic of shoot/rotate and matching colours to door frames.
Quake maps are typically heavily combat focused or into exploration and rarely do players have many encounters with puzzles, but with the AD map variable system players' progress can be stored and more interactive puzzles can be developed.
