What are the criteria that make something a good “Clockwork Game”?
The Clockwork Game Design model is something I have been working on for the last five years or so. It is specifically an effort to figure out how to make the most elegant and effective strategy games possible. There are certainly practical reasons why you might not want a specific game to be a Clockwork game. But to the extent that you want your strategy game to be elegant, you should adopt as many of these principles as possible.
Below is a list of criteria that strategy games should strive for. I am sorting them by how controversial they are. In other words, I am putting the stuff people pretty much agree upon towards the bottom.
These are not ordered by priority. I am making no statements about which of these is more or less important; just that they are all something to strive for.
Criteria
- Error-proof input. With a strategy game, we are trying to measure a player’s understanding of a system. Therefore, we should do our best to get an accurate reading. That means that there should be basically zero times that a player “mis-clicks” or performs any action that they do not intend to perform. To clarify: when a player looks at the list of inputs they made into the system, that list should 100% match the player’s intentded inputs. This means that high execution, or really any execution, is off the table, and means that probably most Clockwork games will be turn based. More here.
- Balanced information horizon. Games need hidden information. They shouldn’t be about “are you willing to do lots and lots of tedious calculation“. Instead, they should be a test of your understanding of the system. Then again, the input of a player needs to be tied to the final outcome as much as possible, so the answer can’t just be slap dice rolls between every player action and the result. The answer is to have a carefully chosen information horizon: enough hidden information to prevent calculation, but enough deterministic, public game state information to associate the end-state with the player’s input.
- A clear, binary, enforceable goal. If there is not a clear “player-has-achieved-the-goal” state, there is no way for the player to get the crucial end-of-match feedback that gives strategic meaning to the player’s input. It’s highly unfortunate that this has to go so high on this list, but the pattern of using “high score” as a model for goals has been plaguing systems that otherwise could be coming close to the Clockwork design model. Games like Civilization, X-Com and Rogue-likes come to mind as games which, but for their lack of a clear and enforceable goal, could have a lot of potential as at least frameworks for Clockwork strategy games.
- Balanced difficulty. The best way to get the most meaningful feedback possible out of your win/loss end condition is by setting things up so that the player has a 50% chance to win. In multiplayer situations, you can (and we already do) do this by implementing a matchmaking system. In a single player situation, you’ll have to do something like Auro’s single-player Elo system.
- Relies on systemic complexity, not content complexity. Content is stuff like characters, maps, items and so on. Systemic complexity is the amount of emergent potential from the game’s rules. Most current videogames rely almost entirely on content complexity. (There is sometimes grey area here, but the above examples are usually pretty obvious.)
- Has a timer. All games require a timer. Sort of the other side of the “error proof input” coin; on the one hand, you want players to be able to make inputs correctly with zero error. On the other hand, you want games to reach their conclusion in a timely fashion because of how important the win/loss feedback is to allowing players to explore a game’s depth.
Ramifications
The following are not criteria, but steps that you will probably have to take in order to achieve the criteria. It is my opinion that designers will have to do most or all of the following in order to create a solid Clockwork game.
Single Player. What we are trying to do with a strategy game is measure a person’s understanding of that system. The involvement of a second player (or more) causes there to be player-generated deformities in the randomness that they provide to the other player; the parameters of this randomness is, despite any attempts to guide players, slightly taken away from designers. Read more here.
Further, the system now has the bizarre requirement of “forcing test-answers to function as questions for another test-taker”. So we need to provide Player 1 with a system that gives them decisions and meaningful feedback while at the same time taking their inputs and having it set up interesting decisions for the other player. In practice, this obviously can and does work, but it is not an ideal setup.
Turn Based. As I said before, probably you’ll need to make your system turn-based in order to avoid input errors. But if you can achieve zero input errors in a real-time environment, that would be fine.
No “Metagame” (Asymmetry, customizability, etc). Since you need your game to be deep, accessible, and have a single core mechanism, any attempts to wrap a game in a larger metagame (such as choosing characters or customizing a character) will be, at best, a waste of time, and at worst, damaging to your system. Also, this tends to conflict with the “one core mechanism” concept, and the supporting structure that goes with that. Read more here.
A core mechanism. A clear, singular core mechanism is a basic action around which all interactivity revolves in a Clockwork game. This, like the other things on this list, is more of a “thing you’ll need to do to achieve the criteria” rather than a criterion itself.
Spend more than a year developing it. I think a reasonable time range where you can expect to end up with a solid, polished Clockwork game is probably between two and ten years. That doesn’t mean you can’t release the game after six months; you can release it at whatever point you like. But there needs to be serious post-release patching, probably for a few years, to get things close enough. The old idea of pumping out a new game every 3-6 months and then just moving on will not result in the achievement of the above criteria.
Depth & Accessibility
A couple of side notes: is accessibility a necessary property of a Clockwork game? I had it on an earlier draft of this list, but actually, I don’t think it is necessary. I do think if you follow all of these criteria, you’re likely to end up with something more accessible than if you hadn’t, but you could theoretically have something extremely inaccessible that’s still a Clockwork game.
And how about depth, actually? I had depth on here, too, earlier. But I actually think you can have a non-deep Clockwork game. It won’t necessarily be good, but I think you can follow this model perfectly and not have a deep game. But then again, depth is relative. I think that if you have an extremely simple Clockwork game, it will be deeper than a similarly-simple non-Clockwork game.
Depth and accessibility are really what we should all be striving for in game design, but I think they are outcomes, or byproducts of using the Clockwork Game Design model, and not “criteria” for it exactly, any more than “the game being good” is a criterion. Perhaps it’s somewhat like saying criteria for engine design is that it produces a lot of power efficiently.
You must be logged in to post a comment.