One of the most common pitfalls of new game designers is not accounting for edge cases. Edge cases are scenarios that aren't part of the typical experience when playing a tabletop game and don't occur very often. We're talking about situations that aren't explained in the rules–situations where it's unclear what the players are supposed to do.
Software Engineers deal with edge cases on a daily basis. Every website or app you use has an intended use, but there's always a way to click on things in the wrong order or supply information unexpectedly. Anything that can happen that is unlikely and not part of the ideal use of the system is called an edge case. Here's a great software example. Let's say you make a website that sells shoes. Customers add the shoes to their cart and purchase them. During the checkout process customers are asked for their shipping address. Nearly everyone in the United States has a street address comprised of a number and a street name. But there are some incredibly rare cases that don't have a street number at all. If your website is expecting a number and a street you have failed to account for an edge case. If any developers are reading, yes, I realize this isn't a very real scenario, but it's a little easier to understand than a data integrity issue where edge cases may be more common! So why do we worry about edge cases? Well, would you want to lose a customer who just wants to buy your shoes but doesn't have a street number? No. Often times the risk outweighs the cost to just account for the edge case, so we do it.
Now, let's get back to board games. I'll give you an example of an edge case that wasn't accounted for in a game created by a local designer. No, I'm not going to reveal the game name or designer because this is an uplifting blog ;)
The purpose of the game in our case study is to complete objectives through set collection. Each player is assigned a few objectives and then takes turns collecting cards to complete those objectives. There's a very lovable theme applied to the game that makes it quite approachable, and it's a little more involved than I'm making it sound, but we're just cutting straight to the point here. There are a few objectives in the game that require one very specific item to be collected. However, there's only one of that item in the whole game. Let's say that two of us are playing the game and that each of us has one of those objectives requiring the incredibly rare item. The game can still be won because one of us can get the item and therefore complete all of our objectives. But, let's say you have two of those objectives with the rare requirement and I also have one. Let's then say that you draw the coveted item and use it to complete one of your objectives. Now the game's a little bit broken, isn't' it? You can't finish your second objective, and I can't finish mine.
This is an edge case. You're saying to yourself, "That will never happen. The chances that I draw two of those and you draw one are nearly impossible." Hopefully you're right, but a really polished game will either prevent these scenarios entirely, or will account for them with a quick line in the instructions letting you know how to proceed. Use the instructions to identify that if the unlikely scenario occurs the players should call it a tie, declare a winner, or flip the table.
The better you get at identifying edge cases, the better the games will be that you design. And when you get to writing the instructions you'll be able to account for everything and leave no player unsure about how to play.
Comments
Post a Comment