Los descubrimientos de hulleras de un novato y un científico

The developer had never worked with telemetrics before. Since several members of the team found them intriguing and wished to gain additional information by collecting more than just the publisher requested data, some room was made in the schedule to allow for a day of designing and implementing extra metrics collection. With previous projects, we had made patches to the game to fix some problems and the same was expected to happen with this one, so any extra information on usability problems, their true nature and possible fixes would be useful. If there had been no possible use for the extra metrics, no time would have been spent on them, but in this case the team agreed that they could prove useful and there were people interested in developing them.

Our way of using this day was to first have each interested person write notes about what they thought would be valuable and what sort of limitations were involved. We then sat down to discuss, with the intention of coming up with clearly defined metrics that are within the scope of the time given, so they can be implemented. What this meant was that as many of the metrics collected as possible should be things the game system already collected. The game already had built and planned systems that collected data, for example information overlays for the player to use that list things about the game (traffic information overlay shows how many vehicles are currently on the city streets and what are their types), a general city happiness icon (a smiley face that is derived from the average happiness value of all citizens in the city), or a statistics screen shown as a reward when the player has unlocked everything (graphs describing city development).

For the meeting, guidelines were formulated to guide metrics design based on how Drachen et al. (2013) describe starting out with metrics collection. The guidelines were descriptions of what information was hoped to be gained with the extra metrics. These were the guidelines brought to the meeting:

2. How to find out if a specific feature works 3. Confirming design choices

4. Helpfulness of the ingame guide (does the player use it?)

Guideline one, “How to find out player strategy”, is trying to focus the metrics so that by analysing them it would be in some way possible to find out what sort of playing strategies players use. These would include, for example, leaving the game to run overnight, playing intentionally slow to gain lots of money, rushing through the unlocking phase or just being plain lost. If we could identify player strategies and see which ones are used most, it would be easier to balance the game to work for those strategies, or if some strategy seems too easy it could be made harder.

The second, “How to find out if a specific feature works”, guideline is about isolating features and trying to find metrics that would tell about specific features and how they are played with. This guideline was mainly written with the system of Unique Buildings leading to Monuments in mind, but can work for other features too. Unique Buildings are sort of in-game achievements that the user can choose to strive towards. A requirement for gaining a Unique Building could be to have 500 000 citizens or to have average ground pollution in the city on a certain level. They are goals offered to the player to support sandbox play, there is no need to gain any Unique Buildings, but they are things the player can choose to go for if they feel the need for a goal. Building a set of Unique Buildings allows the user to build a Monument, which is a great, visually stunning structure that fills one of the needs the city has. For example the Fusion Power Plant produces so much electricity that it basically removes the need to produce electricity for the city in other ways. This is meant to be a point where the rules for the game change to encourage the user to keep playing with the Monument in the city. “Confirming design choices” is the third guideline and focuses on metrics design that would help confirm design solutions for things that are less tried and tested in the game. These would include the Unique Buildings and Monuments mechanic, drip-feeding by unlocking and the integrated tutorial.

Guideline four, “Helpfulness of the ingame guide (does the player use it?)”, is focusing on the integrated tutorial. Usually, city-builder games have a separate tutorial, but since we decided to work on an integrated one instead, seeing if it works as intended would be very interesting. Most game tutorials feel quite separated from the actual game, and

users dislike them (Glajch et al., 2006) partially due to feeling they need to wait before getting to the actual game. Tutorials can lower the enjoyment players get from playing the game even when the skills of the player and efficiency of playing the game does rise. Our version is a collection of guide messages that only pop up if the game system notices the user does not seem to grasp a part of the game. This is not something you see often, and the reason could be that integrated tutorials simply do not work. We did some research and wanted to try anyway, because nothing seemed to imply integrated tutorials were automatically bad or did not work.

After discussing the guidelines, the meeting proceeded to presenting notes and deciding what metrics could be collected without too much extra work and would provide information fitting the guidelines. We decided to write clearly on each metric the information we hoped to gain. This was according to Drachen et al. (2013, 31-35), hoping to avoid redundant metrics and metrics that would just collect clutter. We wanted to keep the metric number fairly low so analysing metrics later would not be too big of a task. At this point of the project, it was impossible to know when any actual metrics data would be available and in what phase the project – or a future project – would be at that point, so expecting there to only be little time for analysis was playing it safe.