Our profession develops, we form conventions and a toolbox of useful solutions. These tools make us faster, and more efficient. Conventions are not only developer driven but player driven as we define the language of games. The real question is when to break convention?

Before you know the answer, you must know the Question

Define the problem clearly with all parties, locate the true source problem and eliminate symptoms. Do you want a sticky goo gun which sticks to walls; or do you want an indirect weapon?

The most common mistake with a convention is to blindly apply it, without knowing the problems its designed to solve. You need to delve past the symptoms into the root causes and motivations. For example what may seem like an issue with your jumping dynamics may actually be a visual feedback issue.

Study not only the present state but the history of a Convention

Every day more people more intelligent than you are pouring collective hours into solving the problem you have just started thinking about. The convention you so readily reach for, or dismiss, did not pop into existence fully formed but instead grew through the years of gaming history from title to title.

Seeing the path of development allows you to better understand the components that build the convention, and the parts which were thrown away. Often choices were made, limitations imposed or situation demanded and the path of development was altered. Sometimes a convention might not be the best fit for your game, or even a good starting point but an earlier version of the convention could be ideal building block or tool to use.

Invention is Expensive

The key benefit of a convention is its a known element, with known quantities. In many cases with known relationships to other conventions. The development time is predictable and many of the edge cases are known.

Implementing a convention in an environment will introduce some new edge cases and relationships but they will be tiny in scope when compared to a new invention.

A new invention or variation must be explored for all edge cases, establish relationships with all other elements of your project, and be iterated upon to reach a stable state.

If you do not have the budget to invent a new convention, don’t start. Find an existing convention that roughly fits and use that instead. A loose fitting convention will be ten times better than a half baked idea.

A little invention goes a long way, but too much will Alienate

While some conventions are entirely developer facing, such as coding conventions, many design conventions are outwards facing to the customer. If a player buys your game which has been marketed as a first person action shooter, there are certain conventions they expect.

Altering convention or surprising your player will often pleasantly and enhance their experience, but only if your solution is clearly superior. Though too many surprises will frustrate or alienate your player, even if your conventions are better than those previously established.

When to break Convention?

Every artistic endeavour must seek to achieve something new, or improve upon the old. The question of when to break convention is simple.

You should always break at least one established convention, though the less you break the more likely you are to succeed. Break too many and failure is assured, break none and success will never be yours.