Isotope SoftWorks Community

...how hard would it be to implement a system where you could create unique keys?
I'm thinking of something along the lines of how keys worked in Quake 2. You never got a generic key, you got a specific item that worked like a key. I like that idea, it can really help you expand the game's flavor and easily implement stylized objectives while still utilizing the same underlying mechanics. I don't have to pick up just another red key, I could get the key to main gates, or I could pick up a specific character's keycard. It could still work the same as picking up a red keycard, but adds flavor to the level by making customized.

For it work, we'd need an ability to write in scripts for a virtually unlimited number of keys. We can already add a new key object easily into the ddf files, and with not too much effort create a custom message. And since you can create custom line defs with ddf (Holy crap I never realized that until just now) all we really need is an ability to write custom key names to add to the script.

This is relatively easy to do. 3DGE already supports extra key types (Green, Gold, Silver, Brass, Copper, Steel, Wooden, Fire, and Water, 16 keytypes in total currently), but you can customize whatever key type you want into THINGS.DDF. Then, you just write the corresponding linetype (if you go here, you can see the existing Linetype specials).

So, you can just rename whatever key you want to change (say, change BLUE_KEY to, I dunno, Wind_Rune), and edit it as such:


THINGS.DDF:

[WIND_RUNE:5]
RADIUS=20;
HEIGHT=16;
DLIGHT.TYPE=QUADRATIC;
DLIGHT.INTENSITY=100;
DLIGHT.COLOUR=#4040FF;
PICKUP_BENEFIT=BLUE_CARD; // <--- This only gets changed if the change has been made in both DDFLINE and COAL_API (and wherever else you have it defined)!
PICKUP_SOUND=ITEMUP;
PICKUP_MESSAGE=GotWindRune; // <--- Must correspond to the new (or replaced) entry in DDFLANG, see below!
SPECIAL=SPECIAL,NODEATHMATCH,NOSHADOW;
RESPAWN_EFFECT=ITEM_RESPAWN;

STATES(IDLE)=BKEY:A:10:NORMAL:Dlight_set(50),
BKEY:B:10:BRIGHT:Dlight_set(100);

Then, the pickup message would be defined via DDFLANG, so you can write in whatever you want there:

LANGUAGE.LDF:

GotWindRune="You now possess the Wind Rune!";

Then, you would trot on over to LINES.DDF (or SECTORS), which you've already figured out:

LINES/SECTORS.DDF

// BLUE DOOR SR (NOW WIND RUNE DOOR)
[26]
TYPE=MANUAL;
ACTIVATORS=PLAYER;
KEYS=WIND_RUNE;
CEILING.TYPE=MOVEWAITRETURN;
CEILING.SPEED_UP=2;
CEILING.SPEED_DOWN=2;
CEILING.DEST_REF=LOSURROUNDINGCEILING;
CEILING.DEST_OFFSET=-4;
CEILING.PAUSE_TIME=150T;
CEILING.SFX_UP=DOROPN;
CEILING.SFX_DOWN=DORCLS;
FAILED_MESSAGE=NeedWindRuneForDoor;
FAILED_SFX=LOCKED?;
SINGLESIDED=TRUE;

Those commands there tell the Linetype which Key to match it up to (in this case, WIND_RUNE, and also don't forget the FAILED_MESSAGE in DDFLANG).


For RTS scripting, you can use GIVE_BENEFIT(), which can also be a key or something. For example:

RSCRIPT.RTS

RADIUS_TRIGGER 0 0 -1
TAGGED_USE

TIP "You got a chaingun, ammo and a blue key!"
GIVE_BENEFIT CHAINGUN
GIVE_BENEFIT WINDRUNE //<--- Entry in THINGS.DDF to GIVE_BENEFIT
GIVE_BENEFIT BULLETS(50)

END_RADIUS_TRIGGER

And that thing in RTS is only an example -- you can do some truly crazy shit with this system, and check for all kinds of requirements before
the script runs, or define a custom on-screen action or even add your own pickup message (and leave the one in DDFLANG blank), using
TIP_SET_POS. You would use the RTS property, TAG, to have the script identify with a number (integer), which can trigger other
external sources (another script, a linedef, DDF stuff using RTS_ENABLE_TAG() in DDF, or even in the COAL API).

Hope that kinda gives you a good overview of how the system works in general.

If you are wondering explicitly about COAL and adding completely new types, the key names are hard-coded into the COAL_API (you can see them if you open coal_api.ec in
a text editor, such as Notepad++). HOWEVER, you can completely change the name, so you can change the 'constant BLUE_CARD' to 'constant WIND_RUNE' -- the catch
is that this change needs to also be registered in Lines.ddf.

// keys
constant BLUE_CARD = 1
constant YELLOW_CARD = 2
constant RED_CARD = 3
constant GREEN_CARD = 4
constant BLUE_SKULL = 5
constant YELLOW_SKULL = 6
constant RED_SKULL = 7
constant GREEN_SKULL = 8

constant GOLD_KEY = 9
constant SILVER_KEY = 10
constant BRASS_KEY = 11
constant COPPER_KEY = 12
constant STEEL_KEY = 13
constant WOODEN_KEY = 14
constant FIRE_KEY = 15
constant WATER_KEY = 16

These are constant key types in the player module, which are STATIC -- meaning they cannot be renamed. I can always add more keys in the
source code, but eventually we want to get COAL to the point where you can define your own modules (much like QuakeC allows you to do). So,
the thing here is to remember which key type you are replacing if you want to do any HUD work with it (in this case, the WIND_RUNE replaced
the BLUE_CARD entry).

For instance, this is how it is used, taken from the COAL Wiki Manual:

Defined in the PLAYER module:

player.has_key(key)
Returns true if the player currently has the specified key, which is a number from 1 to 16.

For more readable code, the following names can be used:

KEYS.blue_card KEYS.gold_key
KEYS.red_card KEYS.brass_key
KEYS.yellow_card KEYS.steel_key
KEYS.green_card KEYS.fire_key
KEYS.blue_skull KEYS.silver_key
KEYS.red_skull KEYS.copper_key
KEYS.yellow_skull KEYS.wooden_key
KEYS.green_skull KEYS.water_key

Okay, so I think you get the idea now I know you probably knew all of this, but hopefully I was able to enlighten you on the ways the
system can be expanded in its current state to do all sorts of unique stuff

Hmm, okay, this works.

So the system is (currently) limited to 16 keys. More importantly, now I know what they are all called, so I can easily use any/all of them in my designs.

I can go through and re-name them, but honestly that seems a bit pointless. As long as I rewrite the text displayed to the player and the associated graphics, it works exactly the same as far as the player knows. Although I guess it isn't much effort to rename the keys in the system anyway, so... whatever.

16 keys does sound a bit limited, but I guess not really. I was planning on having all/most of my game use the hub maps to make one large world, and that can eat up 16 keys pretty fast.
That being said, if I can just use any arbitrary TAG with RTS, I can use that system to simulate more keys. And honestly, I was kind of thinking I would prefer to use keys in a manner more similar to Duke and SW, where the key interacts with an object in the world instead of the door directly. This would really just limit me to 16 keys where I need the key to enable the player to directly access a line, which I can probably work with.

Although as I think about it, while I do prefer to work the key with an object, I don't think RTS has the capacity to "lock" functionality of targeted lines, does it? Or I guess what I would really want it to have RTS change the functionality of a line, so that I might have the line (for example) either function like a normal door, or just trigger a message to the player ("You need x key!") ...Does RTS allow me to change out what a line does? Boy you could do a lot of crazy stuff if that's an option.