PuzzleScript is not a game. It is, indeed, an engine for creating games, but here I am, treating it as IF it were a game, and porting it into my Game Mechanic of the Week.
(There’s a huge discussion to be made with respect to “What is a game?” and frankly, it’s a kettle of fish I don’t want to get into, but you know. Maybe it is a game. Whatever.)
If you’re not familiar with PuzzleScript, it is an open-source scripting language for creating Sokoban-style puzzle games; that is to say, it’s turn-based, tile-based, and naturally structures itself around requiring players to move crates onto targets without getting them boxed into corners. You can create different kinds of crates, different kind of targets, and different kinds of walls, but the game, as an engine, is really made for that simple sort of interaction.
But just because it’s simple doesn’t mean it’s simplistic. I don’t just mean with respect to the complexity of the puzzles… Sokoban can be tricky when it wants to be. I mean… well, here’s what I mean. Today’s mechanic is a rule that loads up as soon as you open the editor to the fresh template:
[ > Player | Crate ] -> [ > Player | > Crate]
The language is a series of cells and arrows. The cells represent tiles, if they’re bracketed together, they’re adjacent. The “>” indicates intended motion, so ” > Player” means “The player character is attempting to move in this direction.” The “-> ” is an order for the game engine; it says “Whenever you see the situation on the left side of this arrow, turn it into the one on the right of the arrow.”
Taken together, it’s like this: “Whenever the player character is next to a crate, and attempts to move into the crate, try to move the crate in the direction they’re pushing.”
What do I love about this? I love how simple it is. I love how intuitive it is. I love, love, love how intensely VISUAL it is.
Look at it! Of course that’s what it means! How could it mean anything else? There’s a player next to a crate, you can tell because he’s NEXT to it. He moves toward it, so he gets a little arrow moving TOWARD it. If you want a player to pull crates as well, it looks exactly as you might expect:
[ < Player | Crate ] -> [ < Player | < Crate]
If you want players to crush crates against walls, then you just need to define a few extra things:
[ > Player | Crate | Wall ] -> [ | Player | Wall ]
Three tiles in a row, with an empty cell that means, well, “empty that cell, PuzzleScript.” But honestly, did I need to tell you that? If I say
[ > Player | Crate] -> [ Crate | Player ]
isn’t it clear right off the bat what that means? You can come up with any number of ways to interact with crates.
PuzzleScript, to me (that is to say, someone who does not code things for a living or for funsies) exists in a perfect point between “easy enough to be approachable” and “complex enough to get things done.” Certainly, I’m limited to a handful of 5-by-5 pixel objects, and rules regarding where they exist on a square grid, and exactly one action button, but within those limitations not only can I decide what happens, I can lay things out in a perfectly clear and comprehensible sort of way. If I don’t understand why the player and the crate keep switching places, I just have to look at the cells when I mention them, and realize that, oh hey. That’s what’s going on there.
Of course, it can be used to create complex interactions, with hundreds of little rules, and all sorts of crazy additional twists, but even at its most convoluted, the game boils down to looking at groups of tiles, and changing them to other groups. Even at its worst, you can go through the rules and SEE what’s going on.
Anyway, a week ago I sat down to try and make a game about a princess escaping from a tower, and then I figured out how to let her toss fireballs, and then things sort of fell apart and the long and the short of it is that I more-or-less accidentally recreated Portal as a sokoban-style puzzle game.
Here, check it out, why don’t you?