For the last couple of months, I have been working part-time on a game called “Lettuce Walk,” which is stylized “lettuce walk” in keeping with the all-lowercase kōan aesthetic.
Lettuce Walk is based on the concept of the Knight’s Tour, a chess puzzle in which a player attempts to land on every space of a chess board.
A knight, if you don’t know, moves in a particular L-shape, so this is a puzzle that can be exceedingly difficult to initially visualize. The L-shapes work together in strange ways, and it takes awhile to get a hang of it.
I thought that a program which procedurally generates these puzzles might be an interesting way to create a diverse variety of puzzles which were all solvable. From a game design perspective, this solves the biggest problem with puzzles, which is, namely:
Once you solve a puzzle, it’s boring.
I figured that the ability to generate a large variety of potential Knight’s Tour puzzles would allow for a puzzle-game with a lot of replay-value, because every time you play, while the basic structure of the puzzle is the same, the actual puzzle presented is different.
More about the Knight’s Tour:
There are two versions of the Knight’s Tour puzzle, or at least of solutions to it: one where you try to end on the same place you started, called an “open” solution, and one where you end somewhere else, called a “closed” solution.
Lettuce Walk mimics a closed Knight’s Tour. The player is supposed to move their tortoise in L-shaped patterns around the board, picking up a lettuce, and returning home.
However, this can be a very difficult puzzle. It is very difficult for someone to quickly pick up the conceptual skills (or patience) needed to solve a Knight’s Tour. So I needed a way to make it easier for people to start playing the game.
Therefore, the moment the player lands on the lettuce, the tortoise may return home. This allows you to complete each level with a much easier solution. Consider this like using all your Angry Birds to pop the Bad Piggies. Sure, you get to move onto the next level, but you didn’t really beat it.
A Brief Detour: The Curse of Minimalism
Like the two previous tortoise games (Tortoise Trails and Sixty Shells), I wanted to minimize instructions.
I really hate reading instructions in games I play. Not that they are all bad or anything, and obviously you need instructions (or a tutorial) in some games. But, ideally, the game will be so self-evident that you will not need instructions.
Without instructions, how can someone play?
Well, you have to make sure that the game has three qualities: (1) controls are intuitive, (2) the game is responsive to player input, and (3) the consequences for new failure are small.
(These are just three concepts off the top of my head, and are not intended to be comprehensive — or, as they sometimes say, “necessary and sufficient.”)
1. Controls are Intuitive
This has been fairly easy, for the most part. The game begins with a single command: “pick up the tortoise.” Most people who test the game seem to understand how to do this intuitively.
They click on the tortoise, and it picks up the little guy and sets him down. They click on him and hold him, and two other squares flash green. People usually spend a couple clicks trying to figure out the next step, which is that you can set the tortoise down on any green square.
2. The Game is Responsive to Player Input
When a player picks up the tortoise, green squares flash on every place that the tortoise can move. When the player lands on a square, it plays a note and a burst of green leaves fall from where the lettuce used to be. When the player lands on the lettuce, it rings a bell. When they return home, it plays a chord.
Here is a fantastic video on juicing, which I think is a must-watch for game developers. The basic concept is that increasing game responsiveness to players (adding literal bells and whistles) creates an immersive quality in a game that transforms the experience.
3. The Consequences for Failure are Small
If a player is not explained what a bad move is, and then they make a bad move unknowingly and are punished drastically for it, they will resent the game.
Therefore, the game developer has two decisions they can make: (1) Describe the basic strategy of the entire game before play, or (2) Make the consequences for failure — or at least initial failure — very small.
In Lettuce Walk, when a player makes a bad move, they must start over. This consequence is disastrous. However, the consequences for attempting to make illegal moves is very small (it just moves the piece back to the square it was on), and this is the most likely form of “bad moves.” Once a player understands the basic movement mechanic, he or she is unlikely to make unknown bad moves: a move that they thought was good might reveal itself — later — to be bad, but that is a natural element of the gameplay, like making a bad opening in chess, or taking out the bottom blocks in Jenga.
I still don’t think that Lettuce Walk is intuitive enough. While the movement mechanic seems easy enough to grasp, I don’t think a lot of people understood the concept of getting the lettuce and returning home, and when they did, they almost never understood the premium placed on landing on every square.
The first solution I developed for this was to implement a scoring system that gave you bonuses for certain behaviors. For example, picking up the lettuce gave you a x7 score multiplier, which encouraged the player to postpone picking up the lettuce for as long as possible, landing on as many spaces as they could.
Also, landing on every single square before you returned gave you a +777 score bonus, in many cases more than doubling your total score. I thought that this would be plenty of information for people to deduce the ultimate goals of the game, but I was wrong.
Some people did not notice the numbers. Others were confused by them. In the absence of a “score” label, people did not understand what they were for, and they certainly weren’t motivated to action by the numerical adjustments.
When you complete a game of Lettuce Walk, a poem is displayed. There are 8 levels in the game, and there are 8 lines in the poem. For every level that you complete perfectly, you get a green line of poetry that tells a positive story. For every level that you complete imperfectly, you get a red line of poetry that tells a negative story. If you lose in a level, that corresponds to the final line of poetry, something like a full-stop.
The poem is about the love of the tortoises. If you complete every level perfectly, then I think it’s a really sweet love poem. If you complete every level imperfectly, I think it’s a pretty sad love poem. But if you complete — as most people will — a mix of perfect and imperfect levels, then the poem is a mix of red and green, positive and negative, happiness and sadness.
I really enjoy this element of random art generation, and I hope others do, too. Writing poetry is a dead art — many say — but I could not agree less. Hopefully, by integrating poetry into games (which no one argues are dead, but many argue aren’t art), I will be able to make poetry more relevant, and games more artful. At least in some small way.
However, since I never specifically spell out what the poem is for, or its relationship to the rest of the game, I am still struggling to devise a way for the player to understand its importance.
A Few Problems:
– Players understand the basic mechanic, but when they encounter the rock, they do not consider the possibility that they could pick it up. I am considering making this easier by putting a grey square underneath it, signifying that something is unusual about it.
– There is a confusion about the moon. Since I haven’t mentioned the moon at all in this blog post, I guess you have some confusion about the moon, as well.
– Early levels are too easy, and later levels are too hard. But that’s not the full nature of the problem. However, it leads easily into my final section:
The early levels of Lettuce Walk are almost impossible to lose. Well, that’s not true. Sometimes they generate levels which are literally impossible to lose: you walk through a linear path and end at the beginning, happily, with a green head of lettuce to show for it. Other levels let the player make one or two choices: sometimes, these end in failure, but more often, they end in imperfect completion, and therefore, a red lettuce.
By the end, however, the map is almost empty. This has two consequences: (1) It makes it almost impossible to get the green head of lettuce by landing on every space without dedicated pre-planning, and (2) It makes it way too easy to finish the level imperfectly.
This is my big balancing problem: I need to discover a way to make the levels harder to beat imperfectly, and easier to beat perfectly. It seems that there is a kind of equilibrium somewhere in the middle: there are enough choices to make the level loseable, but not enough free space to make it too easy to win.
This comes to an issue of balancing. How can I let the game land in that sweet spot between being too difficult and being too easy? I think I am going to make the first half of the game’s levels shorter, making them easier, and cap the ultimate difficulty. I do not want to create a game that requires graph paper to play (though I always love the idea of people really having to think through a game in order to play/understand it fully).
The only way to do this — as far as I can tell — is to implement changes, test them, adjust the changes, test them again, and repeat until good. Here are some things that I added to the game and then removed after testing:
– An undo move button
– An item that allows you to view the perfect solution
– The aforementioned score system (your total score served as the title of the poem, an idea I was infatuated with but which no one understood)
Additionally, the method by which the game generated levels changed. Initially, it randomly placed the trees, and then checked to see if the level could be solved. After a couple failed tests, it would regenerate the levels. This had a number of drawbacks: (1) some levels were trivially easy, (2) it was not guaranteed you could ever land on every space, and () sometimes perfectly solveable levels were rejected because the depth-first algorithm would not solve it in a reasonable length of time (for me, for a web game, a reasonable length of time for the computer to perform this check is instantaneous)
And I’m sure there are others. With Sixty Shells, the iteration became an important part of determining what exactly the game would be: initially, there was a set time limit with the goal to click as many tortoises within this timeframe as possible. Eventually, through testing, it became apparent that the levels escalated in difficulty to a point where they were no longer enjoyable, so I paced the game to reach this threshold around 60, and oriented the game around reaching it.
To solve these difficulties in level generation, I instead re-coded the game so that the game would start with an empty map, “solve” it with the number of steps that that level required, and then place the trees around the map.
This had the advantage of only generating levels that were totally solvable, and allowed me much greater control over the nature of each level, allowing me to place rocks in specific places that did not ruin the game.
But I still have a few other features I need to implement before I launch the game:
– An axe you can pick up and use to cut down one tree.
– A sunflower that spreads when you land on it.
– A special hidden temple level.
– Better effects for the moon transition.
– Better integration of the poem into the level design.
I’ll try to figure those things out for the rest of the week, and I’ll update with another post as soon as I have.