Single Player Games

Triggers Library

This library provides a new object type called a trigger, which can be used to cause reactions in other objects in the world through the use of tags. For example, a lever is a trigger object, and when pulled, the lever opens the gate object with the appropriate tag. There are a variety of different trigger setups you can create to influence objects in your game.

Triggers work through activation and deactivation, or toggling. You can activate a trigger directly, such as when a player steps on a trigger object, using the Activate(object) proc, where the object argument is the object the activated it. You can also deactivate it directly using the Deactivate(object) proc. Or, if you're not sure whether you want to activate or deactivate it, such as in the case of using a lever, you can use the Toggle(object) proc, which will activate or deactivate it depending on its settings.

When a trigger is activated, it will add to a targeted object's triggers_set variable, and the amount added is dependent on the trigger's trigger_weight value. When the triggered object's triggers_set value equals its triggers_req (triggers required) value, then the object is activated, such as a gate's opening. When the object's triggers_set value no longer matches its triggers_req value, it will deactivate, such as a gate closing.

You specify which objects a trigger will affect through the trigger's trigger_target var. This variable is a params list of the tags for the trigger to locate. So in order to affect an object, you need to set the object's tag value, and set the trigger's target value to include the object's tag value.

In case you've missed the forum announcements, I've created several new libraries. Suggestions for improvements are always welcome!


Autojoining Library

Makes it easy to autojoin tiles using 13, 16 and 47-state autojoining. Most everything is already setup for you when you include the library, all you really need to do is decide which turf types are going to be joined and in what way.


Hub Datum Library

Makes it easy to extract information from a BYOND game's hub page and use that information inside the game. An example of how this could be used would be to generate a list of available game servers for the player to connect to from within the game. That means you may never have to visit the BYOND hub in order to connect to an online game, because you can do it from within the game itself!


Panels Library

Allows you to easily change the contents of the game's primary window using a child control, window panes and customizable panel datums.


Map Storage Library

The purpose of this library is to save and load maps for use in such things as level-based puzzle games. Currently it will save and load the entire map, and has no support for chunks, although that may change in the future. The library is setup so that if maps are tampered with, the game can detect this and optionally reject the tampered map file. Maps can also be password protected so that only the author of the map (or the creator of the game) can work with them in an editor.

Here's a concept for a slightly different way of playing Tomb Explorer. Suppose you actually have a "character" on the map. But you don't move that character around yourself. Rather, whenever you click on an interactive object, such as a door or a level, your character will attempt to, via pathfinding, walk his way over to the interactive object and use it. If the object can't be reached for some reason, he or she will let you know why.

The reason for this is that it gives a reference point to determine where the player is at any given time. Then, if a gate is closed (which currently isn't possible since there's no way to determine which side of the gate the player wants to be on), the player can be restricted to the side of the gate that their character is on.

It wouldn't change gameplay all that much since, end the end, you're still using the mouse for everything. But being able to close off areas after the player has accessed them would open up more puzzle possibilities.

Mind you, the "character" isn't necessarily something you'd have to wait around for while they casually meander over to the object you want to use. This is a single player game - the character can reach its destination in 0.2 seconds. Its mostly just a matter of using this character to let the game know where "you" are supposed to be.

Any thoughts?

I found a bug in the way the Fade library was handling MapSet() which was creating some weird behavior. Since that has been fixed, you can download the latest version here:

http://www.byond.com/developer/Foomer/Fade

I haven't posted much lately since I've been involved with other projects outside of BYOND, but I've had a question in my mind for a while and I thought I'd look for some audience feedback.

Aside from Solar Conquest, which I've been neglecting for quite a while, I have two other projects: Tomb Explorer and The Gauntlet. I've been wondering though, who would prefer that Tomb Explorer be played like The Gauntlet? They both have the same puzzle structures at heart, so its really just a matter of two things:

1) Use player-created levels or a single game world.
2) Use a character that moves around or click on things with the mouse.

The benefit to The Gauntlet's setup is that I already have a wide range of graphics drawn up for that style of game, while Tomb Explorer uses small, relatively abstract graphics. Also, the way Tomb Explorer is setup requires that the entire map be within the player's view, while The Gauntlet has no such restrictions.

It would be fairly easy to take The Gauntlet and combine it with level loading, level saving and scoring systems similar to what Tomb Explorer uses. Then it would be just like playing The Gauntlet, only with custom levels. The downside is that combining them into a single game like this would make it much too similar to one of the original inspirations for both games, Chip's Challenge.