Combination lock

From Doomsday Wiki
Jump to: navigation, search
Work In Progress: This tutorial is not yet complete. It is published in the hopes that it might be of use but errors and omissions should be expected --danij 23:09, 12 October 2007 (BST)

Overview

Chances are, you have felt somewhat limited by DOOM's key-locked doors when creating maps. Being continually faced with the same gameplay challenges is pretty un-interesting huh? Have you ever wanted to add a combination lock to secure an area in your map? Perhaps there is a secret laboratory in that deep space research lab with danagerous experimental weaponary hidden inside? This tutorial teaches you how to do just that.

Introduction

For this tutorial we will be utilizing XG to implement a combination lock. Be aware, that we will be chaining together multiple XG linetypes to create a re-usable lock mechanism that can be used to activate another mechanism (here, we will use a simple door but in your own maps you could build stairs, end the level etc...).

In the process, we will discuss the event-driven nature of XG and how it can be used in different ways to replicate complex mechanisms. As such, this technique may not be suitable for those new to XG.

Concept

As already mentioned, we are aiming to create a combination lock, which (when the right combination is entered) will open a door. Before we go any further, lets first embelish this somewhat basic concept and try to define exactly the behavior we are trying to create.

Requirements

  • The player should be able to manipulate the switches of the combination lock by using them.
  • Each time a switch changes state, we must check whether the current configuration activates the door.

Features

It would also be nice if we didn't have to create a tailored set of definitions for each instance of the combination lock. Lets outline some features that would improve the re-usability of our combination lock.

  • Any number of switches should be supported by an individual combination lock.
  • Any number of combination locks should be able to co-exist within the same map.
  • We should not have to create a new set of definitions for each combination lock.
  • The combination should be specified in the map-editor and NOT in the definition.

Determining events

/writeme

The switches

/writeme

Definitions

Line Type {
    Id = 1000
    Comment = "Combo Lock ON Switch"
    Class = none
    Flags = player_use
    Flags2 = when_act | when_deact | any
    Type = flip
    Count = -1
    Event Chain = 32767
    Act sound = "swtchn"
    Act tag = 1
}
Line Type { 
    Id = 1001
    Comment = "Combo Lock OFF Switch"
    Class = none
    Flags = player_use | active
    Flags2 = when_act | when_deact | any
    Type = flip
    Count = -1
    Event Chain = 32767
    Act sound = "swtchn"
    Act tag = 2
}

Explanation

/writeme

The combination validator

The final definition we need is that of the combination validator. Recall that earlier, when defining the switches we made use of the Event Chain paramater (=32767) to execute another linetype on activation/deactivation? This is that linetype.

Definition

Line Type { 
    Id = 32767
    Comment = "Combination validator"
    Act message = "Access Granted";
    Flags2 = any | when_act | line_act | line_inact
    Class = activate
    Count = -1
    Line act lref = act_tagged
    Line act lrefd = 1
    Line inact lref = act_tagged
    Line inact lrefd = 2

    Ip0 = "lpref_tagged_ceilings"
    Ip1 = 7
}

Explanation

Notice that there are no (de)activation triggers specified at all (normally, a linetype requires at least one trigger, for example player_cross). As our switch linetypes are calling the combination validator by way of their Event Chain paramater, there is no need to specify trigger(s). Furthermore this, means that this is a virtual linetype and cannot be used on a linedef in your map directly (note, that even if you do use it directly on a linedef - it will have no effect).