An Economy of Rules (part 2)

Part 1
I’d like to take a look at some specific rules and see where I end up.
Rules of surface
A proposed surface rule: Games should always have screenshots on the box.
At first glance, this appears to be a reasonable rule. In order to know if I want to play a game, I should be able to see what it looks like. Of course it would always be better if I could watch the game in motion, or perhaps play a demo of the game, but the screenshot is an adequate substitute. The screenshot can also serve to verify that the game is in fact the game you are looking for, “Yes, I saw a demo of this game and here it is.” The screenshot of a sequel game can help you decide that the game looks better (or worse) than the previous game.

But there are rules about the screenshot as well. Why are screenshots on game boxes so small? On a computer screen, a 1024×768 image fills a 15″ monitor. But in printed material, which has a much higher resolution, a 1024×768 image doesn’t contain enough detail to justify an equal amount of space. Printing a screenshot at 300 dpi will result in an image less than 4″x3″ in size (effectively a 5″ monitor). To make the screenshot look “better”, you have to print it at a higher resolution, which makes the image smaller. Screenshots printed at screen resolution (usually 72 dpi) look blocky.
In the process of transforming the screenshot of the game onto the game box, the surface of the game is distorted. If the distortion is too great, then the selling power of the screenshot may actually diminish the appeal of the game. If the image is too big, the graphic quality may appear to be poor. If the image is too small, the details may be too small to see clearly. The large, low resolution screenshot is the more honest image, but is less appealing.
The ultimate role of the game box screenshot is to persuade a buyer in a store. And yet some stores sell games without a box — older games that remain popular, or discounted games that emphasize price over packaging. And also, games that can be downloaded online do not come in a box.
Returning to the rule “Games should always have screenshots on the box,” we find that this is a rule that only applies to a certain market of games. This is appropriate for a surface rule, because the demands of the surface of a game are those which effect an immediate response from the viewer. Surface asks: Based on this game box, do you want to play [buy] this game?
Rules of craft
Proposed craft rule: If your game uses pathfinding, you should test the algorithm thoroughly.
Craft rules operate on the technical level of game making. There are a number of technical skills involved in making a computer game: programming, image editing, sound editing, and so on. In reviews, game graphics and game sound effects tend to be judged as specific categories, while the programming itself tends to be lumped among the more general comments.
“The pathfinding is bad,” or “There are some problems with the pathfinding,” are things that are commonly said about games with pathfinding. Often one person will praise a game’s pathfinding where another has found it lacking. One reviewer may evaluate a game compared against other games they have played, while another may base their opinions on their own technical knowledge of pathfinding. But in general, if a review has something to say about the pathfinding, it is usually bad.
The rules of craft can be frustrating, because when something is carefully crafted, the craft will get very little attention. At the same time, people have very individual tastes about what they regard as well crafted. An animator will be more critical of animated game elements, such as walk cycles, and an interface programmer will be more critical of interface responsiveness.
Pathfinding depends on a number of factors: the amount of resources available, the algorithm to be used, how fast it needs to be, the kind of data structures it has to operate on, and so on. The A* algorithm has been shown to be the “fastest” algorithm to return the shortest path, but the fastest implementations of A* work with certain kinds of data structures and use lots of resources. What should the programmer do when the game design requires a certain algorithm but they cannot alter key data structures? How does that programmer satisfy the well-testedness of the pathfinding routines when no amount of programming skill can give a satisfactory result?
A number of games have been released with flawed pathfinding routines. As a result, they are roundly criticized in game reviews. As a result of the reviews, programmers worry more and more about the pathfinding routines. That doesn’t mean that there will be a solution, only that there will be a rule.
How important the pathfinding rule is to the game design depends on how it compares to the other rules. If critics are making a lot of noise about pathfinding, it will get higher priority. But if rules start taking on priorities then the rules are going to be applied unevenly. Craft rules have a certain specificity; what happens when the rules are more abstract? What happens when craft rules come in conflict with structure rules?
(continued …)

Filed under musings · Tagged with


One Response to “An Economy of Rules (part 2)”
  1. Aubrey says:

    I’m enjoying this so far. It helps clean up and order thinking. Rather than a game’s production being a clusterfuck of different priorities, we can use an Edward DeBono-esque “Thinking Cap” method for each aspect.