Reviews of my Ludum Dare 32 game Deserializer are going well! Feedback has been very positive, but has also provided some useful critiques. I’m looking forward to the rankings being finalized and published Monday evening.
But I haven’t been sitting still. Although I’m proud of what I accomplished in three days, I know that the game is far from perfect. I believe that the core mechanic of a Frogger-style play field and movement plus pattern-matching is solid, but the specific type of pattern matching and its associated mechanics are definitely not ideal. So yesterday I spent some time away from the computer doing some paper prototyping. After a few iterations of conjuring up and tweaking new rules, I believe I’ve found a game objective that will work better. Allow me to describe a bit of the process I went through.
The first step was to simply review and summarize which parts of the gameplay felt good, and which parts didn’t, based both on my own experiences and the experiences of others. A lot of this information related to the physics and the action, for example, the way that the player movement is discrete, occurring in 64-pixel chunks over a fixed number of milliseconds, while the other objects in the play field move continuously, each at its own rate of so many pixels per frame. These are valuable areas of focus for me to keep in mind, but were largely unrelated to what I really wanted to focus on at the time. Studying and improving such elements would require a digital prototype, and I was already reasonably happy with their behavior in my Ludum Dare entry. They could be improved I’m sure, but the priority was elsewhere.
So leaving those in summary form, I moved on to thinking about the overall objective of the game, the pattern matching, and how the player mentally interacted with it. I considered the fact that a binary pattern was possibly over-simplistic, offering very little in the way of intriguing mechanics. I considered how an imperfect match did not feel very interesting, and that my attempts to make imperfect matches not egregiously harmful were simply cheap hacks that weakened the experience. I noted that progress toward fulfilling the objective was also less clear than I would have liked. I observed the unfortunate fact that players often just waited around for a long time avoiding objects in the environment until one spawned with the pattern they were looking for.
At this stage, I turned my perspective forward and asked myself what qualities I thought the ideal objective would have. This included attributes such as progress being clear and intuitive, imperfect pattern matching being simultaneously helpful and harmful, but in mechanistically different ways, forward progress almost always being achievable in some form, given sufficient skill and risk-tolerance, and imperfect pattern matching never reverses progress which has already been made. In addition, I felt that the ideal objective would be easily adaptable to a multiplayer format, both competitive and cooperative. Feedback from others has indicated that this sort of game could work well on consoles and a couch-play environment.
With those attributes in mind, I began brainstorming some alternatives. Non-binary patterns. Less emphasis on the order of elements in the pattern and more on the values, if there’s more than just two values. Alternatively, pattern matching always starting from the far left, with the concept of wrapping around being dropped. Imperfect matches complicating the play field rather than reversing progress toward the objective. Smaller target patterns as objectives which each contribute to a larger objective when fully matched.
Finally, I pulled out the physical prototyping tools. In this case, all I needed was some dice of various sizes and small colored blocks from my old Risk set. Small 1×1 LEGO bricks or any other easily distinguishable tokens would have worked also. Since there were exactly six colors in my Risk set, I decided I’d use them all, so that I could easily roll a 6-sided die to randomly select a color. I used a 4-sided die to determine how many blocks I should use to generate a pattern for the play field.
I decided I would simulate the game in a turn-based fashion. Each turn, I’d first have to simply survive all the moving objects without getting hit. To simulate the the skill and difficulty involved, I added up some various factors that would influence the degree of challenge, and then roll an appropriate collection of dice to see if I passed the skill check or not. For example, I utilized a notion of moving game objects, each of which might have a various number of non-active elements (equivalent to the white bits in Deserializer which would kill you if you collided with them), as well as generic debuffs of some non-descript form. I added the number of non-active elements, the number of moving game objects times two, and the number of debuffs times four. I then rolled a pair of 10-sided dice to get a random value from 0 to 99. If the roll was greater than the sum I calculated, then I survived the turn without getting hit by something.
The next step of each to was to choose (as the player) one pattern in the play field to try to grab, just as in my original Ludum Dare entry. I did a similar summation as before and compared it against a roll of a 20-sided die. If the roll was less than the sum, I treated that as a failure to maneuver into position, but not as an actual loss. I just failed to reach to pattern I wanted to grab that turn.
Finally, I performed one last skill check, based on the number of active elements within the moving game object. The more there are, the easier it is to get the timing right and grab the object, just as in Deserializer. To estimate this skill check, I rolled two 6-sided dice, took the absolute difference between them, and as long as this difference wasn’t greater than the number of active elements in the pattern, I successfully grabbed it. Otherwise, I treated the failure as though I collided with one of the non-active portions of the object, thus losing.
These dice rolls and skill checks could no doubt be tweaked to represent all sorts of probability distributions, but the overall idea was to abstract out all the actual physical and time-based challenges, and replace them with simple probability rules that can be experimented with quickly. I had to get a little inventive with the calculations (especially the absolute difference one), but I was overall pleased with the feel that the skill checks generated.
Here’s a sample of a game in progress:
The sequence of nine blocks at the bottom is the target pattern I’m trying to match. The six rows above that are “generations” of moving objects. Each turn, I push the object in each row up by one. Once an object reaches the sixth generation, it is removed from play. The object in each row consists of the blocks on their side that represent their matchable pattern, and the upright blocks which are non-active elements that increase the difficulty. The three scattered blocks at the top right are in a queue to be added to the next moving object to be generated. When this queue gets large, all new objects end up with a lot of non-active elements, but if the player can keep this queue small, they can manage the difficulty. Not shown, I also placed debuffs to the left of the moving game objects, and they followed a similar generational scheme. After four generations, they were removed from the game; debuffs bring with them a heavy penalty but have a shorter period of activity.
Through iterating on this overall scheme, I was able to discover that certain ways of managing imperfect matches worked poorly, while others generated interesting tensions between different intermediate objectives that the player was trying to manage. I also discovered that certain types of debuffs, in particular, specific ways to introduce them into play, worked better or worse than others.
The most important discovery was that I probably need to setup a tension between letting game objects pass by unused versus grabbing patterns that imperfect matches given my current target pattern. If the player lets an object go by unused, all of its elements, active and non-active, get added to that queue I mentioned above. Eventually, the non-active elements attached to game objects get so numerous that collisions were frequent. But the only way to reduce their number is to grab objects, which causes their elements to be removed from play rather than going to the queue. To offset this action, I made imperfect matches generate debuffs, which discourage the player from grabbing poorly matching objects unnecessarily. But eventually, the need to clear the field of non-active elements overrides the need to avoid debuffs. Over numerous turns, I really liked the competing pressures this placed on the player.
Being able to discover this dynamic in just a few hours was pretty thrilling. When I take some time to do so, I definitely intend to translate this into digital form. I’m eager to see how well the feeling of the physical prototype translates into a real-time action format. And at some point I’m sure to try my hand at trying this with other game ideas also. It’s been a valuable bit of practice, and I finally feel like I’m beginning to get the hang of it. If I can get my skill at this process to become highly efficient, that could do wonders for my game design abilities! I highly recommend the process for anyone else interested in game design also.