Fudge Design Limitations

I make my living as a Systems Engineer for a software development firm. My role is to design the global infrastructure, and to troubleshoot high level problems that may require design changes. Often problems related to design are caught long before a system is brought into production. These are the types of problems that are the result of a design flaw and they are easy problems to resolve.

The truly difficult problems to resolve are when a system reaches a design limitation. No matter how well the system is designed there are limitations in every design. A good designer tries to foresee the reasonable rate of consumption or expected performance for the lifetime of a system, and then buffers that amount with a generous overhead to ensure stability.

No one can predict the actual use of a product though and occasionally systems that I designed to last five years are being stressed in three years. Is this due to bad design? No. It is because of unpredictable changes in components, reasonable expectations, and unforeseen user activity. Hitting the design limitations of a system after a few years of use but still earlier than expected is actually a sign of success. The system fulfills the needs for which it was designed, and addresses some new problems that creative users recognized the system’s potential to solve.

Good designers recognize that no system is ever finished, and this applies to game systems like Fudge just as it does to complex technologies. I enjoy Fudge tremendously, but it has limitations in its design such as:

• Fudge is so simple that it creates complexity when a designer chains several simple components together. The core mechanic is not complex, but it is the chain of components using the core mechanic that can get out of hand. A good example is combat using opposed rolls with offensive and defensive modifiers that can lead to combatants both winning the opposed action. Two opponents can block each other or injure each other once the modifiers are applied. This is a great concept, but it is difficult to keep track of in actual play.
• Fudge can be played with very little mechanics to be a collaborative storytelling game with some gaming groups. The problem is that those groups might not have the same experience twice if the social dynamics should change. A different game master or a new player with a different approach to the game can offset the social dynamic that made that collaborative storytelling experience work. Mechanics and rules create certain limitations, but they also help to focus the play of a game. Rules also help to manage player expectations.
• Fudge has a very limited range in what the ranks ladder can handle. I use a ranks ladder with fifteen adjectives now and that is pushing what a person can easily recall while playing the game. My ranks ladder uses the original seven adjectives and I added four negative and four positive results to the ladder so that any dice result at any rank has a unique description. The problem is that now the ranks ladder stretches what the human brain can easily handle in terms of unique pieces of information.

So should we ditch Fudge because of these limitations? Absolutely not.

Remember that sometimes reaching a system’s design is a good thing. It shows that the system has been successful up to a point and that the needs of the users have changed enough to outgrow the system’s original specifications. Often the next system put into production is not a complete rebuild of the system, but instead the original system is upgraded with features used to address those specific limitations so that we do not have to abandon the working components.

For instance:

• I am using a spreadsheet and writing a simple software application to make the calculation of opposed rolls with combat modifiers easy to resolve quickly.
• Fudge points can be defined as having certain benefits to help manage the collaborative storytelling experience with.
• The scale modifier was created to address the limitations of the core mechanic’s ranks ladder.

All three of these examples show how despite Fudge’s design limitations the creation of a new mechanic can expand the usefulness of the core mechanic. The design of the core mechanic was not altered in any way. We still have a list of adjectives and a unique set of dice that most likely will not change the expected outcome of a contest. Yet by introducing some simple mechanics to compliment the core mechanic with we can continue to use the core mechanic without any alteration.

This reason is why I love to design rules using the Fudge system. As Fred Hicks once told me in an interview regarding the adaptability of Fudge – “You can bolt all sorts of things onto it, and it’s still Fudge when you get to the other side of it.”

That is what Fudge needs: new mechanics that compliment the core mechanic. I created an initiative system that uses playing cards for Fudge, and today my friend Keith Boyle used a variation of that system for his own game that he ran. We both are using a mechanic other than the core Fudge mechanic in our Fudge games, and yet we are still playing Fudge. Only now our Fudge games are better and unique because we brought those complimentary mechanics into play.

So when you design your Fudge games do not be afraid to stray from the simple core mechanic of Fudge in order to have the type of play experience that you desire. The core Fudge mechanic is versatile not only in how it can be applied, but also in how it can be complimented.

Do you use a unique mechanic in your own Fudge game? Tell me about it in the comments section below, and share your own design types with the rest of the Fudge community!