This is the third and last part of adding analytical insights to Daniel Cook’s blog post on “Building tight game systems of cause and effect”. If you missed the two first parts, you can access them through this link Part 1 and this other one Part 2 respectively.
11. Processing Complexity
“Tighter: System requires simulating few steps to predict an outcome. In a vertically scrolling shooter, you see the bullet coming towards you. It doesn’t take a lot of thought to figure out that if you stay in that location you are going to be hit.”
“Looser: System requires simulating multiple steps to predict an outcome. On the other hand, in Triple Town, good players need to think dozens of moves ahead. Thinking through all the various machinations necessary to get the result you want adds a serious cognitive load to the player. A single mistake in the player’s calculations yields unexpected results.”
Corresponding Metric: Mechanics and actions per goal
In mobile games the general trend is to limit both game and processing complexity. This is in order to accommodate the casual nature and short play times that characterize the mobile platform. There are some strategy games that exhibit complexity in long-term player interaction, but most mobile game developers design for quick understanding and quick play, thus ignoring action consequences completely. With that in mind, if you need a game metric to measure the complexity of a mobile game, the game is probably already too complex for the average mobile consumer. In that case, the designer should consider whether the game should be fundamentally changed or at least directed at another market. Of course, you might also get away with making something new and revolutionary that breaks all conformities, but that is easier said than done, right?
One possibility is to track how many different game mechanics there are in the game and how often the player uses each one. This can be done on a general scale or on a goal by goal basis, depending on whether the game is level-based, goal-based or has a loose structure. Even if the game does not use levels, the designer should somehow separate the measurements. Games like Clash of Clans and Simpsons Tapped Out have a more loose structure: the player can place buildings where they like within a difined area, but they still have to go through levels. In those cases, the goal of the game could be achieving levels. Other games with a loose structure gradually expand the area of the player’s base/castle/city. In those cases the goal could be the act of expanding. If the game has both level and expansion mechanics that delimit the goals, you can compare the complexity of the different types of goals to each other.
The metric could then check for what actions and mechanics the player uses to get from one goal to the next and how long it took to execute those actions. The resulting data would show how many player actions and how many times the different game mechanics were used to achieve each goal. This information can be use to determine the complexity of the different stages of the game. Based on this, the designer can choose to increase or decrease the complexity of the different stages to reach the desired rate of progression and difficulty.
12. Option Complexity
“Tighter: Fewer options are available to consider. In a recent upgrade system I was building I give players 3 choices for their upgrades. I could have given them a menu of 60 upgrades, but that would be rather overwhelming. By focusing the user on a few important choices, I give them the mental space to think about each and pick the one with the biggest impact.”
“Looser: A large number of options must be considered. In a game of Go there are often dozens of potential moves and hundreds of secondary moves. This options complexity is a large part of why the game has been played for thousands of years.”
Corresponding Metric: Mechanics and actions pr. goal and options
Option Complexity seems to cover both gameplay options and appearance customization options. These are two very different things, but both add to the amount of game content. The main difference between the two is that appearance customization does not have to influence gameplay in any way, while gameplay options should influence the game in some way. In this article the focus will be on the game option complexity and not the appearance customization.
There are two different approaches to game upgrade/options mechanics. One is an open and unguided approach, where the player has many different options to choose from and aspects to explore or upgrade. This approach is non-restrictive and leaves everything up to the player. This is often used in RPG games like Skyrim,to a lesser extend in MMORPGs like World of Warcraft and Minecraft.
The other approach is narrow and strict guidance. The player has a very limited range of options/upgrade possibilities and game progression is linear. The game is designed so that the player must do things in a specific order so as to advance. The designer can choose to do this in an obvious way or he can give the player the illusion of choice. This is used in games like Call of Duty, God of War, Simpsons Tapped Out and Megapolis, and basically all tap based economy games.
The two approaches are not to be thought at as “one or the other” as very few games go to the extreme in either direction. It is more a case of leaning towards one approve with more or less intensity.
The same metrics as described in the Processing Complexity section can be used to examine Option Complexity. Simply take the same data and look for upgrade game mechanics and for sections where the player can use different actions to achieve the same effect. Then you will get a sense of the Options Complexity metric. Again, the designer can use the data to tweak option complexity in order to lengthen or shorten game progression.
13. Social Complexity
“Tighter: Another human broadly signals intent, capabilities and internal mental state. In an MMO, a player dresses as a high level healer and stands in a spot where adhoc groups meet up. There’s a good chance you know what they’ll do if you ask them to go adventuring together. Or in a managed trade window, you know exactly what you are getting when he puts up a potion for your sword. There is little ambiguity.”
“Looser: Another human disguises, distorts or mutes intent, capabilities and their mental state.”
Corresponding data mining: Chat and mail mining
Cook seems to focus only on the social aspects that directly influence gameplay, ignoring a key element of social interaction – namely the chat. As mobile and social games are designed to be simple, there is no need for complex player cooperation, and most examples of PVP are really just player vs. static data saved on a server. There are, of course, indirect collaborative player interactions like watering each others’ plants in Farmville and the like. One player posts something and someone else waters the plants, so this is not direct player on player social interaction, but actually player on server state interaction.
In any game where players can interact an ingame chat or mail system is usually implemented, and it is always very interesting for the game developer to keep an eye on what the players are talking about. The player on player communication is a treasure trove of information of what the players think of the game and how they play it. That makes the chat and/or mail system an obvious target for data mining. It is however difficult to properly extract information from the chat, because a lot of manual (human) interpretation is needed.
The simplest way is to set up a metric that searches for words or phrases that the developer is interested on. This could be done for general concerns (for example, if the player likes the game) by searching for words and phrases like “game, good, awesome” or “game, bad, sucks”. But it is better to be more specific, especially if the results have to read by humans. If the search query comes up with 200.000 lines of chat, it is not possible for a human to get something meaningful out of it. It is possible to use the mined data without human interpretation, but that makes the results very ambiguous. Generally, the more specific the search the more useful the results, and the more easily humans can engage the information in a meaningful way.
This approach can be used to gather many different types of information. Possibilities are only limited by imagination and the resources necessary for metric computation . There is an element of privacy invasion in this method, so be sure to always include a clause for monitoring and examining ingame chat and mail in the EULA.
14. Time Pressure
“Tighter: Requires simulating the model at the player’s preferred pace. This is related to processing and option complexity since players can only execute their models at a given pace. Players are more likely to make causal connections if the time pressure is greatly reduced. For example, the game NetHack has complexly interwoven systems that require real detective work to decipher. In order to increase the likelihood that players will make the connection, the game is set up as a turn-based game where players may take as much time as they want between turns. You’ll see that as the situation becomes more complex, even good players will slow down their play substantially so they can understand all the ramifications.”
“Looser: Requires simulating the model quickly. In a game of WarioWare, there isn’t really much complexity involved in each individual puzzle. However, we can dramatically ramp up the cognitive load and increase outcome uncertainty by setting a very short timer.”
Corresponding Metric: Completion time vs time limits
Time pressure here does not only refer to time limit challenges in games, but also to the speed at which the games actually play. Increasing the speed of the game is a guaranteed method of increasing difficulty, dating back to classics like Pac Man.
Cook writes that the loose way is to enforce time pressure at the rate that the player is most comfortable with. But such games usually increase in difficulty by gradually applying more time pressure, which means that they will eventually become uncomfortable anyway. The challenge of the designer then becomes to balance the difficulty rate in such a way that the player feels challenged and interested.
If the player bought the game, then there is an extra financial motivation to keep playing, so the designer can make the game very challenging and still expect the player to play along. In the “free to play” or freemium model the balance of difficulty is changed. Now there is the added aspect of trying to motivate the player to spend money, while not pushing the player away. Most freemium game use a “make the game faster” or “make the game easier” monetization strategy. That means that the challenge of balancing the difficulty is not necessarily to make the game more interesting, but to make it difficult enough to determine the player to make in-game purchases. So freemium games should push the player’s limits beyond the comfort level, while at the same time trying to not drive them away.
It is possible to make a metric that reflects the difficulty of games which use time-based levels (for example “match three” games like Candy Crush, Bejeweled and Bubble Mania). It doesn’t have to be match three games, it can be any game that has a goal-based structure with a time restriction. Setup the metric to collect how long each player takes to complete each level, and to collect when the player dies or fails, and how long each play session is. Then you can get an average time to complete each level, get a count on how many players fail each level and find out when they give up.
With this data, the designer can then find out if the game is more or less difficult than expected. If all the players failed the first level and the designer expected the average player to get to level 10 without dying, the game is too hard. It is a common design mistake to make the game too hard at first. But with the data collected through the metrics above, the designer can fine tune the difficulty.
If the game follows the freemium model, the same data can be used to tweak the game difficulty towards motivating in-game purchases. If the players are progressing too fast they might enjoy the game more, but they would also be less likely to buy extra time or powerups. In that case, the designer could use the above metrics to choose a suitable moment when the player should fail a level.
For example, the designer could aim for 10 minutes of seamless playing, only to get the player interested. Then he could introduce some mechanics which make the players fail a lot in order to introduce the advantages of a paid game experience.
Tighter is more important on mobile devices
When looking at the 14 different parameters, it becomes clear that “tight” games are easier to play, understand and therefore most suited for the mobile market. So the “tight” approach is clearly the better way when designing a mobile game for the general mobile game consumer. If a designer wants to try something new on the mobile market, then taking the “loose” approach would surely achieve that. If the designer is trying to make a game for the mainstream mobile consumer though, it would be a good idea for him to go through the 14 parameters and make sure the game is as tight as possible. If on the other hand the designer is into experimentation, looking at the 14 items and choosing where to be “loose” might inspire new ideas for gameplay mechanics.
These blog posts have given some examples of how to make use of game metrics in game development. Game metrics have to be very specific in order to be effective, so it they do not apply to your particular game maybe they can at least inspire you to come up with your own relevant metrics.
In any case, if you are designing a game, no matter the platform, do yourself the favor of reading Daniel Cooks blog post.