Monday, 17 October 2011

Game Design: Circles, Ellipses, and Epicycles

Game design is curiously like theory building in science: you have some observations (or preconceived notion) of what the outcome is supposed to look like, which you try to generate using a set of rules (a game or hypothesis). If the hypothesis disagrees with the evidence before you, or the game turns up weird situations you don't like, then it's either back to the drawing board (or complain that the players are idiots that don't play like gentlemen).

A case in point: The Ptolemaic cosmology of an Earth-centered planetary system (a "Terra System" rather than a Solar System). If you observe the night sky without benefit of telescope, then you will eventually notice that it has this beautiful property of appearing both eternal, and circular like the life-giving sun. You will also notice that some stars move across the background stars, and these are the planets (no, not planets like the one you're on, but special stars that stand out from the background...). If you want to explain their movement, particularly since the background stars appear to have a beautiful circular cycle of movement, then it stands to reason (for a certain value of reason) that the planets likewise follow a beautiful circular cycle of movement.

Except that now that you've noticed the stars, you'll notice that your observation will frequently disagree with your notion of where the stars would be if they were actuated by a benevolent creator with a hard-on for perfect circles. So, as so often happens in science, you don't throw the baby (the circles) out with the bathwater (inaccurate predictions). Instead, you realize that your predictions can be 'corrected' if only you use enough circles, building little beautiful circular epicycles into your beautiful circular system.

Eventually the theoretical baggage of so many embedded cycles starts to take its toll on the beauty and elegance of the system while making no special improvement to the accuracy of its predictions. Once the Ptolemaic system was beaten to death, it could be surplanted by the Copernican system. The Copernican system likewise didn't get rid of the beautiful circles, but it did do some ego-bruising reconfiguration of the centre of the cosmos, re-orienting it around the Sun rather than the Earth. Unfortunately for Galileo, the ego that was bruised was that of his sponsor, the Pope. Let that be a lesson in biting the hand that feeds you, rather than any special antipathy for science that religion (and particularly the Roman Catholic church) may hold.

And eventually, astonomy being what it was, refinements in observation and the mathematical tools available for describing and predicting these observations, the circles had to be let go and the orbits of the planets (as well as quite a few other things besides) were replaced by a more general concept of elliptical orbits. The eternal timeless heaven of beautiful epicycles gave way to a more larger space-time of far more beautiful tensors. But this transition required far more than the mere interaction of evidence and hypothesis.

After all, the Ptolemaic system survived primarily because its predications were good enough, given the technology and science of the day, and appealed to the intellectual milieu of its times. We see something similar today as scientists desperately try to amend or tinker with the standard model of cosmology in an effort to avoid both starting from scratch, and to maintain the reputation of their sciences as creditable in a world that may not understand physics, but does understand the bottom line.

Similarly in game design you face the issue of having decided on the game you want to play, producing rules to guide people in playing that game, and then facing the decision of either repairing the rules, or changing the game. Changing the game has tremendous costs, so often game designers go in and tinker with the rules, and with the values within the rules, in an effort to make good on the effort so far.

There's an element of necessity to this tinkering: since games are frequently cobbled rather than designed, allowing the flaws in a game to persist for long periods of time means that the game's audience will either drift away, or sideline itself into a strange parody of the game by exploiting thos flaws. Similarly games frequently lack a valid design philosophy or even a solid design brief which successive generations of writers may refer to when amending the work of their earliers and betters. It's rare for a writer to be able to understand where the designer was going, and it's an expensive proposition (at least in the short term) to spend time creating a long-term plan for growth that may turn out horribly wrong.

That's where the various scientific activities can come into play and inform efficient game design and product maintenance. Besides gathering data and testing hypotheses, science also involves unifying theories. Having ten theories to describe ten separate phenomena is not user-friendly, smacking of lore rather than data. Having one theory to describe the causal mechanisms of ten separate phenomena, on the other hand, is much more useful.

Unifying the rules that govern the behaviour of elements in the game is very important, because the fewer rules that players need to know, the more time they can devote to 'un-packing' or playing the game, and exploring its strategic depths. It's no coincidence that games like Go are both extremely simple, extremely deep, and wildly popular.

Elegance is an important game-design value, just as it is an important value in science. Fewer rules means more accessibility, and hence greater sales, as well as fewer small niggling bugs, and easier bug-checking.

So besides:
1. A philosophy: The designer's motivations, intentions, specifications, etc.
2. Rules: Describing the behavior of game elements.
3. Elements: The stuff you can actually sell, like dice, boards, pieces, etc.
4. Testers: The people who make sure that the combination of rules and elements adds up to the design brief. It really helps if these people know math.
5. Technical writer: The poor bastard who gets to connect 1-4 by structuring, editing, and producing the documentation (rulebook, etc).

Game design requires:

6. A project manager, the person that organizes the project, tracking the resources that it's allowed, and making sure that it goes out the door rather than continually being bounced around development as the group works on what the individuals think the game should be rather than what the specifications laid out.

Because that's the curious thing that the history of science usually leaves out, the commercial or economic aspect that not only created a demand for the products that could be technologized from scientific knowledge, but also gave resources to the scientists so that they could pursue their work, and get that work out to other scientists (and the public) so that it could be science rather than esoteric lore or mere trivia.

Science, and indeed many of the best games like Chess, Go, and so on, have benefitted from a anarchic development that can best be described by evolutionary game theory. They have not been designed so much as they have evolved. While some people may take this to mean that game design should be open-sourced, I disagree. The thing about evolution is that it's a process by which elements speciate and get selected, or more loosely: mutate or die. Some companies make their living on the margins by producing the small, cheap-ass games that are sufficiently disposable for the company to survive the selection process. Other companies, particularly those involved in the big, expensive games require a design process to get their games to market. Indeed, I think that the whole point of design is to avoid the process of natural selection, and the economic harrowing that inevitably follows.

Without an eye towards economics, as well as towards the game, game design is a random and capricious process, and one to be indulged at your peril.

No comments:

Post a Comment

Looking forward to hearing from you!