Little Big Planet 2 is a video game for the Sony Playstation 3 console. One of its most interesting features is a robust set of tools for users to build and share new levels. This article contains a detailed discussion of the tag and sensor components available within the LBP2 level creator. It will be of interest chiefly to readers who have some experience creating LBP2 levels, and who have at the very least completed the in-game level creation tutorials.
Tag and Sensor Basics
Tags and sensors are superficially very simple. A tag is a logic component which can be attached to an object. A tag sensor is a logic component with an output that turns on if and only if a corresponding tag is within range. This basic functionality has been around since the “magnetic keys” of the original LBP. It’s often used to implement the familiar “drag key object to door, then door opens” gameplay mechanic, for example.
In LBP2, tags are substantially more powerful. There are some subtle and extremely useful new features, most of which hinge on added flexibility in defining which tags trigger which sensors and when.
Colors and Labels
Tag colors are reasonably easy to understand: each individual tag has exactly one color (chosen from a palette of eight). Likewise each tag sensor. A given sensor only detects tags of the same color. Color must be chosen in the editor at the time the tag is created, and cannot dynamically change during play. By default, tags and sensors are green.
A tag or sensor may optionally be given a label. The label is a text string. Sensors only detect tags with a matching label. (Labels are considered matching only if they are absolutely identical. Unlabeled sensors detect only unlabeled tags.) Like color, the label (or lack thereof) must be chosen when the tag or sensor is created, and cannot change during play.
Note that both label and color must match for detection to occur.
One reason to use labels is that it allows you to have more than eight types of tags in the same level, without having to worry about overlapping ranges and people finding a way to get a tagged object into a place they shouldn’t.
Another reason to use labels is that it lets you build library objects and be reasonably certain that they’ll only interact with the stuff you intend — even if you share them as community objects. Another creator might well have a green tag on his level, but it’s really unlikely he’ll have one called “joeuser_star_key”. (This obviously works better if you choose reasonably descriptive labels rather than, say, single-digit numbers.)
Range, Layer and Angle
Sensors have a configurable detection zone based on the location of the tag relative to the sensor. Each sensor has a minimum and maximum range.
A sensor can never detect tags on the same microchip, even if minimum range is set to zero! If you nest multiple microchips, then any chips which ultimately have the same parent are the same for the purposes of this discussion. Complex components which include a circuit board, such as the controlinator, act as microchips with respect to tags and sensors.
Sensors and tags act as points in space with no area. The distance from tag to sensor measured from the actual location of the components, not the edges of the objects they’re attached to. The tag and sensor object can be touching and you can still be out of range! (Remember that as always components on microchips are located where the chip is physically attached, not where the circuitry is displayed.)
Sensors can be configured to detect only tags in the same layer, or to detect tags in any layer. The “any layer” option does just what it says on the tin. “Same layer” is more complex.
There are seven layers normally accessible in create mode: three “thick” layers, and four “thin” layers, like this: (back) |O|O|O| (front) where a | is a thin layer and an O is a thick one. A solid object may occupy either any one thin layer, or one thick one, or two adjacent thick layers, or all three thick layers. That’s ten possibilities total. (An object which occupies more than one thick layer is also considered to occupy the intervening thin ones.)
Sensors and tags have to be attached to solid objects (or be in a microchip or board thus attached). A tag or sensor is “in” all the layers occupied by the object it’s attached to. A tag is in the “same layer” as a sensor if the objects holding them share at least one layer. Note that this means single individual objects, not including rigid connections. (In other words, having the tag object glued to another object in the sensor layer doesn’t count.)
A good way to visualize it is to imagine trying to drag the tag object past the sensor object. If they’d bump, they’re in the same layer. If they’d slide past, they’re not.
Finally, sensors can be configured to detect only tags within a certain angular arc (relative to the orientation of the sensor).
Ranges, layer and angle can only be set at create time. However, if a sensor is configured to detect only tags in the same layer, remember both sensor and tags can potentially change layer during play. Also, since angular arc is relative to the orientation of the sensor, the actual sensing area can change if the sensor rotates.
Tags have a logical input which determines if the tag can be sensed. Left unconnected, it defaults to true. You can connect it to the output of another logic component to dynamically control if a given tag is active. (You can also connect an analog signal to the input, and use the sensor to detect “signal strength”.)
This is an extremely powerful and useful feature. Consider: A tag with a connected input and a sensor with a very long range, both with the same unique label, are (to a first approximation) a long logic wire, without some of the wire’s limitations.
Example: Imagine you have an object in your level that needs to interact (in terms of digital or analog signals) with an item spawned (during play) by an emitter. You can’t just connect them with a wire, because the emitted object doesn’t exist while you are designing the level. Using a logic-controlled tag and sensor, you can do it easily. (This method even gives you reasonable ways of dealing with things like the object being destroyed and respawned, or having multiple instances spawned concurrently.)
A particular case that deserves special mention: At the time of this writing, the randomizer object is bugged, such that it is only re-seeded upon creation or when the settings are changed. A workaround is to have it created by a one-shot emitter (so it is freshly created thus re-seeded each time the level is played.) If the randomizer has to connect to other things in the level, you may do this with tags and sensors, and you’ll still be able to implement the workaround easily. (This avoids the need to have large chunks of your level created at play time by an emitter.)
Tags and sensors aren’t always a good substitute for wires. Obviously, you wouldn’t want to use a tag/sensor pair where a simple wire would serve — to do so would add pointless complexity (and needlessly increase the thermometer of your level). Tags and sensors exhibit different timing and race condition characteristics than wires.
Sensors can be configured to activate only when a certain number of matching tags are simultaneously sensed. This can be quite useful for implementing things like “select three matching objects” or “get at least three lights lit at the same time” or “finish at least three of the sidequests to open the door”.
Granted, there are other ways to do all of these. However, tags and sensors can sometimes do it more simply and with a lower component count, especially in cases where the number of matches can increase or decrease. (The counter logic component is useful, but it counts pulses on a single input rather than how many inputs in a collection are currently active.)
A single sensor just has a minimum count of tags required. To implement a range or an exact count, use two sensors (one each for upper and lower bound), invert the output of the upper-bound sensor, and connect the output of both to an AND gate.
Timing and Race Conditions
Consider a pair of objects, each of which has a sensor and a matching tag. The tag only turns on when the object is grabbed. The sensor is connected to a destroyer. (Tag and sensor are not on the same microchip.) Grab either object, and both are destroyed.
On a mostly empty level, this will likely work reliably and as intended.
Now consider the case where you have a dozen such objects, on a fairly busy level. In testing, you grab an object, and some but not all of the other objects are destroyed. What’s happening?
When you grab an object and the tag turns on, the connected sensor triggers the destroyer, destroying the object and with it, the tag. The period of time between when the tag turns on and when it is destroyed may be so brief that other sensors on the level don’t notice the activation.
A similar problem can arise when you’re just deactivating the tag instead of destroying it.
One solution is to have a central control circuit: a single place which is responsible for detecting the relevant condition (via tags or wires), then informing all objects in the set to take action (again, via either tags or wires).
If that isn’t practical, another workaround is to use the timer logic component to implement a delay between detecting the condition and acting on it. (I’ve found that even 0.1s is sufficient in the cases where I’ve tested it.)
A sensor will detect a tag if and only if all of the following conditions are met:
- the sensor and tag are the same color
- the sensor and tag have identical labels (or are both unlabeled)
- the sensor and tag are on objects which occupy at least one common layer, OR the sensor is set to detect tags on any layer
- the sensor and tag are not on the same microchip (or in a series of nested chips with the same parent)
- the tag input is activated (or unconnected)
- the tag is inside the maximum range of the sensor
- the tag is outside the minimum range of the sensor
- the tag is within the detection arc of the sensor (relative to the sensor’s orientation)
- neither tag nor sensor is on a microchip with an “activate” input which is off
The logic output of a sensor is active if and only if the number of detected tags is equal to or greater than the required count.
The analog output of a sensor only emits a non-zero signal only if the logic output would activate per the above rules. If “signal strength” is selected, the output is the value of the strongest detected signal. If “range” is selected, the output is the distance to the most distant detected tag.
http://wiki.lbpcentral.com/Tag_Sensor — LBPWiki article about tag sensors
I have no relationship to Sony or Media Molecule except as a customer, and I do not speak on their behalf. All trademarks are acknowledged as the property of their respective owners, and nothing here is intended as a challenge to that status.