-
Notifications
You must be signed in to change notification settings - Fork 13
Compatibility
Tip
You hopefully shouldn't need to know any of this unless you're a huge nerd for this game (or would like to become one). The defaults should be fine.
Chip's Challenge¹ has had several releases, and while the general gameplay remains the same, each version of the game has subtle different behavior (or bugs) that can make or break particular levels — especially custom ones.
The behavior of each release is called a "ruleset", and is generally referred to by the name of the platform it was released on. Lexy's Labyrinth supports three rulesets to varying degrees.
The rules from Chip's Challenge 2, thusfar only available on Steam. The ruleset is sometimes also called CC2, but that's a little misleading since there's also a Chip's Challenge 1 release on Steam that uses the same engine, so the rules are perfectly suitable for both games.
This ruleset has the best support by far. Lexy's Labyrinth has three compatibility modes based on the Steam rules:
Lexy is the default mode, reflected by having all compatibility flags turned off. It's modeled after the Steam rules (which the developer considers to be canonical-ish), but with some bugs fixed and some small tweaks to fix aesthetic issues or confusing edge cases in the game's behavior. (You can see exactly what's changed by just skimming the compatibility flags that are turned on for the Steam modes.) This mode also detects and automatically fixes a few design patterns in CCL/DAT-format levels (designed for Lynx or MS) that would otherwise break under Steam rules.
If a level can be solved in the original Steam engine, it can almost certainly be solved under Lexy rules.
Steam is a middle-ground compatibility mode for Steam. It plays the game more faithfully, but preserves fixes for bugs that should make the experience strictly better (and have very low risk of making levels unsolvable or more difficult). It also preserves the automatic fixes to CCL levels.
Steam (strict) adheres to Steam rules as closely as I know how, bugs and all. This mode is intended to faithfully play back recorded solutions, but is not really recommended for general play.
The very first iteration of the game was Chip's Challenge for the Atari Lynx, an ill-fated handheld system from the 80s. The Steam rules are still broadly similar to the original Lynx rules, but with some changes to accommodate new puzzle elements added in CC2.
Complicating the situation somewhat is that many players' experience with "Lynx" rules are actually with the Lynx mode from Tile World, a Chip's Challenge emulator written many years later and which is not perfectly bug-for-bug compatible. Where the two diverge, Lexy's Labyrinth's Lynx mode prefers to target the original Lynx behavior, even at the cost of compatibility with recorded solutions.
The best-known release of Chip's Challenge was the Windows port released in Microsoft Entertainment Pack 4 and later the Best of Windows Entertainment Pack (or BOWEP). Unfortunately, this port was dramatically different from the source material — objects move discretely rather than smoothly animating (or animating at all), the rules for where monsters can step are different, and there are a number of significant bugs around movement.
Lexy's Labyrinth does have an MS mode, but it's relatively superficial. It should reasonably replicate the experience of playing the Microsoft port, but there are several fundamental design differences that cannot be covered by compatibility flags in any practical way. MS compatibility is considered a low priority.
The vast majority of levels should work under Lexy mode. If you suspect a level is unbeatable with the default behavior (or it's listed in Known Broken Levels), try using the rules for the game it was designed for.
Please note that no mode is guaranteed to be 100% compatible with any ruleset (though Steam should get pretty close), and in particular, Lexy's Labyrinth is not guaranteed to be suitable for speedrun purposes. That said, bug reports are always welcome; compatibility issues will only be rejected if fixing them would require disproportionate amounts of effort to replicate very obscure behavior.
You're also welcome to mix and match individual compatibility flags and see what happens, especially if you like the Lexy experience and want a particular level to work with minimal changes.
The Steam releases of Chip's Challenge 1 and 2 come with "replays" (recordings of player input) embedded in all the levels, and the community has a public archive of best known solutions to Chip's Challenge 1 for both Lynx and MS rules. So a reasonable way to measure compatibility is by simply playing back these recordings under the appropriate mode and seeing if the level is solved by the end. If the game doesn't behave the same way as it did when the recording was originally made, the player will generally end up in the wrong position, and they'll either bumble around until the recording runs out or just run directly into something fatal.
Current status, as of sometime in April 2024:
Steam (strict) — Successfully plays back all 149 levels of Chip's Challenge 1, all 200 levels of Chip's Challenge 2, and 199/200 levels of Chip's Challenge 2 Level Pack 1. The sole outlier is Bringin' Down the House, a level based around using the hook on force floors.
There is also a very large and raucous pack called CC2LP1-Voting, a collection of all 1400 levels that were submitted for possible inclusion in CC2LP1. Many of these even rely on obscure CC2 bugs. LL still manages to successfully play back 1328/1400, or 94.9%.
Lexy — Replay compatibility is explicitly a non-goal here, but it still successfully plays back 123/149 of Chip's Challenge 1, 177/200 of Chip's Challenge 2, and 156/200 of Chip's Challenge 2 Level Pack 1, for an 83.1% pass rate. So it's not too different.
Lynx — Successfully plays back all but 36~40 of the solutions for Chip's Challenge 1, CCLP1, CCLXP2, CCLP3, and CCLP4, a total of ~706/745 levels, or around 95%.
MS — Absolute garbage. Barely plays back anything but the simplest levels.
For the sake of brevity, flags are listed as "Steam" if they apply in both "Steam" and "Steam (strict)" modes.
no_auto_convert_ccl_popwalls — Steam (strict only), Lynx, MS
In Lynx, recessed walls changed into normal walls when they were stepped onto, but the Steam release changed this to when they're stepped off of. (Likely to match the behavior of turtles; if they vanished when stepped on, you'd be left standing on open water, which would look weird.)
This rarely affects gameplay, except when a level begins with an actor already placed on a recessed wall. Under Lynx rules, the actor can leave without affecting the recessed wall, so it could be stepped on again; Steam rules immediately leave behind a wall, which often makes such a level unsolvable.
By default, when this construct appears in a CCL level, it's fixed by replacing the recessed wall with a custom "doubly recessed wall" tile, which reverts to a standard recessed wall when stepped off of, thus recreating the original behavior with Steam-like mechanics. This flag disables that fix.
no_auto_convert_ccl_blue_walls — Steam (strict only), Lynx, MS
In Lynx, it was possible to push a block off of a blue wall (the kind that turns into a normal wall when you bump into it). Arguably, this was a bug, since it wasn't possible to push a block off a regular wall, and Steam fixed it. Unfortunately, a number of old levels rely on this behavior.
By default, when this construct appears in a CCL level, it's fixed by replacing the blue wall with a recessed wall, which recreates the intended behavior under Steam-like rules. This flag disables that fix.
emulate_60fps — Steam
Update at 60 frames per second like Steam, rather than the 20 tics per second of Lynx.
The difference is subtle. Speeds within the game itself were also tripled, so for example, a normal move gets a cooldown of 12 frames instead of 4 tics, and finishes in the same amount of time. Actors also only get a chance to move every third frame, so it seems like everything happens at the same speed. (I suspect that the Steam release made this change for rendering reasons, since it's easiest to have the game and the rendering run at the same speed.)
Unfortunately, this scheme has some cracks. For example, if the player starts the level on a force floor loop, she'll start moving on frame 1. The problem is that she's only allowed to try a move on frames 3, 6, 9, etc. She'll take 6 frames to move and be aligned with a tile again on frame 7, but then the next force floor will move her again, and by the time the game allows her to give input on frame 9, she'll already be in motion and ineligible to start moving in a different direction. This will continue indefinitely.
Since this causes obscure bugs and doesn't really gain anything, the default is Lynx speed, which is what Steam is trying to emulate anyway.
Note that the display will update at your monitor's refresh rate (possibly faster than Steam!) regardless of this flag.
no_separate_idle_phase — Steam
The original Lynx game (or, at least, Tile World) updates in two passes. First, every actor moves. Then, separately, every actor teleports, if it's standing on a teleporter.
In the Steam release, these were collapsed into a single pass: every actor moves and teleports before the next actor is processed.
Surprisingly, this creates a problem with the very common situation of pushing blocks through teleporters. When the player pushes a block into a teleporter, the block automatically moves out of the "out" teleporter in the same direction. A few tics later, the player and the block will both (usually) finish their next move at the same time — the player reaching the "in" teleporter, the block reaching the next cell beyond the "out" teleporter.
But under the Steam model, if the player moves first, she will finish her move, fully arrive in the teleporter, attempt to teleport, and be unable to — because the block will still be considered to be in motion, and the player can't immediately push a moving block, so the "out" teleporter is considered blocked! She'll go somewhere else, or maybe not teleport at all.
This situation is impossible under Lynx rules, where both the player and block finish moving before the player attempts to teleport. That seems better, so it's the default behavior.
In practice in the actual Steam release, this situation is avoided by the following flag — a pushed block is always a tic ahead of the player, so it'll finish moving in time for the player to teleport.
allow_double_cooldowns — Steam, Lynx
When an actor starts to move, it's given a "cooldown", a number of tics before it'll be able to move again. Most commonly this is 4, meaning it takes ⅕ of a second to take a single step. Every actor's cooldown is decreased by 1 at the end of each tic, and when it reaches 0, the actor may try to move again. This is also used to animate actor movement — when something has a speed of 4 and a cooldown of 2, you know it's halfway between two cells.
Under some circumstances (usually when the actor is moved by some external force), Lynx and Steam will decrease an actor's cooldown in the middle of a tic. Its cooldown will then decrease again at the end of the tic, along with every other actor. The effect is that an object will jump ahead of where it should be, and arrive in its new tile one tic earlier. This is why pushing blocks in CC2 looks off; the block skips ahead by a step when it's first pushed, so it's slightly ahead of the player, and then it waits for a moment for the player to catch up to it before pushing it again, leading to slightly jerky motion every time it lands exactly in a cell.
This all seems to be an oversight, so by default Lexy's Labyrinth will never let an actor cool down more than once per tic. This flag restores the original behavior.
player_moves_last — Lynx
Lynx always had the player move last. Lexy's Labyrinth defaults to the CC2 behavior, where players are placed within the update order the same way as every other actor. The difference is extremely minor and mostly affects replay compatibility.
reuse_actor_slots — Lynx
In Lynx, if an actor is destroyed and then a new actor is spawned, the new actor will take the place of the destroyed one in the update order. In Lexy's Labyrinth and all other versions, new actors are always added to the end of that list.
Again, this is very minor and mostly affects replays.
player_protected_by_items — Lynx
Most monsters (including all CC1 monsters) are blocked by items, so logically, a player can't be killed by monsters if she's standing on an item. In Lynx you always pick up an item you step onto, so this only matters in mid-step, or if you start a level already standing on something.
Unfortunately, this would create some degenerate behavior in CC2: you could simply drop an item to become immortal. Since this comes up very rarely in Lynx anyway, Lexy's Labyrinth defaults to the CC2 behavior, where monsters will kill you before even noticing you're standing on a pair of boots. Use this flag if you'd like to be able to inscribe Elbereth.
force_lynx_animation_lengths — Lynx
Here, "animation" refers to things like water splashes or explosions, which play out an animation and then automatically disappear. These were significantly slower in Lynx, forcing the player to wait briefly every time they pushed a block into water before they could step on it.
player_safe_at_decision_time — Lynx, MS
This is the other half of the earlier "trampling" flag. In CC2, monsters can't wait until they actually move to kill the player, or the player could be protected by an item. So instead, if a monster even checks whether it can move into a cell and it sees the player (before an item), the player dies instantly.
This is a little weird, of course, and it's not the case in earlier versions of the game. But for the sake of CC2 gameplay, it's also the default in Lexy's Labyrinth.
This flag has no effect unless no_early_push ("Pushing blocks happens at move time") is also enabled.
bonking_isnt_instant — Lynx, MS
Under CC2 rules, an actor that slides on ice headfirst into a wall will turn around immediately and start moving backwards. Under CC1 rules, the actor doesn't start sliding back until the next tic.
actors_move_instantly — MS
The most obvious difference between MS and every other iteration of the game is that movement is supposed to be animated, but in MS, everything just snaps immediately to a new position and then dawdles for a moment before doing it again. This flag will recreate that experience, rendering and all.
tanks_always_obey_button — Steam (strict only)
In Steam, blue tanks respond to blue buttons even if they're on clone machines. Monsters on clone machines are generally not supposed to move, and this tends to make the clone machines not work so good any more, which smells very much like a bug.
sliding_ignore_button_while_moving — Lynx
In Lynx, pressing a blue button while a blue tank is in mid-motion will cause it to completely ignore the press and continue on in that direction. In Steam, the tank will turn around at its next opportunity. Blue tanks are frequently intended to stay synchronized, so this is often very bad; it just doesn't come up much in the original levels, where blue tanks generally didn't cover much distance.
blobs_use_tw_prng — Lynx
The random number generator changed between Lynx and Steam, which breaks demo playback. This has no real gameplay effect, but there's no "Lynx (strict)" category, so.
teeth_target_internal_position — Lynx
In CC2, both varieties of teeth respond to where a player appears to be — that is, if a player has only just started to move, a teeth will move towards/away from the cell she's departing.
The original Lynx behavior was to use the player's internal notion of position, which is always the cell being moved into, even if the move has only just begun.
This mostly affects demo playback, but the default behavior feels slightly more sensible.
rff_blocks_monsters — MS
For reasons no one can fathom, the Microsoft port forbids monsters from stepping onto random force floors. All other force floors are fine.
fire_allows_most_monsters — MS
Monsters are supposed to avoid fire, but for some reason the Microsoft folks decided to let them walk right into it and die instantly. But not bugs and walkers, for some reason.
use_legacy_hooking — Steam
Steam prevents you from moving if you have the hook and you try to move away from a block that you can't pull (most commonly, because it's already in motion). Steam also prevents you from moving if you try to move away from a monster that's in motion.
This is incredibly unintuitive (in practice you just seem to freeze for no reason), and it makes the hook even more unpleasant to use than it already is, so I came up with a completely different implementation for Lexy mode.
no_directly_pushing_sliding_blocks — Steam
The impact here is about blocks on force floors facing a wall. Under Steam rules, pushing such a block will simply tell it to move in the pushed direction the next time it's able to — but a block can't override a force floor, so that will never happen. Things being stuck forever doesn't seem great, so the default behavior lets you move such a block out of the way, as long as it's not in mid-move already.
emulate_spring_mining — Steam (strict only)
Steam has a bug termed "spring mining" where the player can push a block off of a recessed wall and follow along behind it, even though the block's movement causes the recessed wall to pop up, resulting in the player walking directly onto a solid wall.
This is obviously not intended, and it even causes softlocks in the level it's named for, so it's fixed even in normal Steam mode.
no_early_push — Lynx, MS
"Block slapping" is the ability to push a block sideways as you walk past it, without ever moving into its space, by holding two directions at once. It doesn't exist in the MS release, but it's frequently useful.
use_pgchip_ice_blocks — MS
"pgchip" is a binary patch to MSCC that adds ice blocks to the game. This version of ice blocks lacks many of the extra abilities that CC2's ice blocks have, though they do have the unique ability to be pushed by teeth and blue tanks.
This flag attempts to emulate the pgchip behavior, and should only be used for levels intended to be played in pgchip.
allow_pushing_blocks_off_faux_walls — Lynx
This one is fairly self-explanatory.
block_splashes_dont_block — MS
Technically, in MS, a block pushed into water doesn't splash at all; it just becomes dirt immediately. This flag is a compromise that's functionally identical: there's still a splash, but you can walk into it like it's not there.
green_teleports_can_fail — Steam (strict only)
CC2 has green teleporters, which pick a random other green teleporter in the level to exit from in a random direction. There are two bugs in the Steam implementation:
-
If a green teleporter has no usable exit, CC2 will move on to the next one (in reverse reading order, i.e., blue teleporter order) and try that instead. But it will give up completely as soon as it reaches the entry teleporter. That means if the list of green teleporters is A B C D E F, an actor enters teleporter E, and the one chosen at random is C, then the game will check C, check D, and then reach E and give up! It won't try the others at all. On average, it won't check half the teleporters in the level.
(This only matters if green teleporters tend to become blocked on all sides, but that's not an unreasonable way to use them in a level — green teleporters surrounded by a couple recessed floors can force the player to visit several areas in random order, each only once.)
-
CC2 seems to count up all green teleporters except the one you entered, then roll a random number in order to select one of them. But then when it goes to pick the teleporter with that number, it skips over any teleporters that currently have an actor in them. This can cause teleporters closer to the top of the level to be more likely than ones near the bottom.
The default behavior is to fix both bugs. Since the teleporter selection is random anyway, this misbehavior is only useful for replay compatibility, and the flag is only on in strict mode.
no_backwards_override — Lynx
The player is allowed to step off of a force floor in any (other) direction, but in Lynx, this ability was specifically restricted to stepping off sideways. It's not clear why (perhaps just an abundance of caution), and Lexy's Labyrinth defaults to the CC2 behavior.
traps_like_lynx — Lynx
You might expect open traps to behave like plain floor, and in most versions of the game, they do.
But Lynx's implementation is a little buggy. See, when something is stuck in a trap and then the trap is opened, it gets pushed out, similar to how actors in teleporters get pushed out automatically. But in Lynx, traps constantly push whatever's in them, the whole time that they're open. The effect of this is that actors walk into open traps at double speed (because an actor moving into a cell is considered to be in that cell, and the open trap does an extra cooldown every tic), and actors aren't allowed to turn on an open trap (because the open trap functions like ice).
These are obviously bugs, so they are not enabled by default.
blue_floors_vanish_on_arrive — Lynx
In Lynx, a fake blue wall doesn't disappear until the player finishes stepping on it. This is visually weird, since the player appears to be moving into something that looks very much like a wall, so it's not the case in any other version, or in Lexy's Labyrinth.
Note that this flag does have some minor gameplay impact, since it causes blue walls to last longer and thus block monsters for longer.
popwalls_pop_on_arrive — Lynx, MS
The counterpart to "Recessed walls under actors are not auto-converted in CCL levels". If you turn that on, you might want to turn this on.
rff_actually_random — MS
In Lynx and Steam, the behavior of random force floors is not actually very random — random force floors use the same sequence of four directions in a loop. A level in Chip's Challenge 2 even specifically relies on this and requires the player to learn and exploit the order.
The Microsoft port takes "random" to heart and consults an RNG.
The MS behavior seems more expected, but since it makes a canonical level effectively unplayable, Lexy's Labyrinth defaults to the predictable sequence.
cloned_bowling_balls_can_be_lost — Steam (strict only)
The way a clone machine works is to attempt to eject the "template" that's already on the clone machine. If that's successful, a duplicate is made, and that becomes the new "template". If the object can't move, nothing happens, no harm done.
CC2 introduces an oversight: if something (e.g. a block) is in front of a bowling ball cloner, then attempting to eject the ball will cause it to destroy the obstruction, and itself! Worse, the ball will report that it failed to move (since it was blocked), so no duplicate will be made — meanwhile, the original ball turns into an explosion, animates, and disappears. The result is an empty clone machine!
This obviously violates a number of player expectations, and probably designer expectations too, so it is banished to strict mode.
detonate_bombs_under_players — Steam (strict only)
In Steam, when an actor starts the level already on top of a mine/bomb, both immediately explode. If that actor is a player, you lose instantly, before being able to move.
The latter behavior has no level design utility whatsoever, and some CC1 levels (that are otherwise playable under the default rules) do start the player on top of a mine, so it's off by default.
bombs_detonate_on_arrive — Lynx, MS
Counterpart to the previous flag: in both iterations of Chip's Challenge 1, mines only explode when stepped onto.
This can't be the default behavior because it breaks a level in CC2LP1.
monsters_ignore_keys — MS
In Lynx, blue keys could be "eaten" by monsters, red keys could be passed over by monsters, and green and yellow keys blocked monsters. This behavior was retained (and made even more convoluted) in CC2.
The bobbins down at Microsoft didn't get this memo, probably because it virtually never comes up in the game, and so monsters can walk over every color of key with no effect.
Lexy's Labyrinth defaults to the CC2 behavior, since it comes up a bit more in CC2 levels.
¹ Chip's Challenge is a registered trademark of Bridgestone Media Group LLC, and is used here for purposes of identification only. Not affiliated with, sponsored, or endorsed by Bridgestone Media Group LLC.