Designer Intent vs Emergence: Nissan Edition

Nissan Datsun 510: Fastest Car on the Planet

Forza Motorsport 3 is, as described by one of the designers, “car porn.” And, well, that beauty above? That delicious, glistening, throbbing piece of machinery? That’s a Nissan Datsun 510 from 1970. You’re free to take a moment right now, if you need one… imagining yourself astride the seat, hand gripped on the gear shift, thrusting forwards through the forest…

At least, that’s what Forza 3 would have you think.

Once you’re back from your “moment,” please continue over the jump to see exactly what I’m talking about.

The video linked above is aptly titled “Forza Motorsport 3 Drag Race WTF.” It shows a very fast race car being soundly beaten by one of those beautiful Datsuns. This driver was not the first person to notice. The problem is that the Nissan is able to be upgraded with the engine from a Skyline, amongst other upgrades, which boosts the car’s horsepower output to a phenomenal degree.

What’s happened here? Who’s to blame? Is anyone at fault? Here be the dragon of emergence.

Dominant strategies are one of the first aspects of a game to be communicated around the Internet. As soon as they are discovered, the viral potential is enormous. Some members of the community will revel in them, some will be disgusted, and many will be ambivalent until they’re upset by them directly.

In order to talk about the problem effectively, we need to enforce the boundaries of the problem (not doing this can lead you to arguing with a psychologist until you’re blue in the face about the possibility of solving of the Turing Test¹ )

1. This is not a bug in the implementation (unlike Modern Warfare 2’s javelin glitch), but a bug in the game design itself.
2. The bug is a direct result of the emergence from having a very large number of combinations of cars and upgrades.

Doing some very rough mathematics, let’s assume there are 400 cars, each with a possible 25 upgrades that could be applied. This would give us:

This is, undoubtedly, a big number. It’s very, very rough: 25 upgrades is something I’ve pulled out of the air, and you can’t apply all upgrades at the same time (ie. you can’t apply two different types of exhausts). A more realistic number might be more along the order of:

The number gets very big due to the number of different upgrade combinations, which causes the tree of the possibilities to blow-up very quickly. Scientists dramatically call this an “explosion.”

That said, it is something we can enumerate, and 13 billion isn’t that many possibilities for a computer. However, for a human game designer, we’ve escaped the realms of human processing possibility, and there’s no way one person could ever understand such a state space.

The 'S' is for Software!

This is one of those problems where my ego imagines myself donning some sort of cape, adorned with fine circuit boards and transistors, and allowing myself to exclaim “software engineering to the rescue!” We could have detected the Nissan Datsun problem before the release of the game by encoding a set of designer expectations that we can test for. These expectations we’ll more formally call “assertions.”

A sample expectation, in this case, would be “An E-class car can’t win drag races in less than 25 seconds” or “An E-class car can’t beat upgraded B-class cars in a drag race.” We add them to a software program, benchmark all the possible cars, and come back and see which of our assertions failed. Perfect!

Such a program wouldn’t take long to create, so obviously there are hidden problems here. Here’s a few:

1. Encoding assertions, while not hard, exercises a part of the brain we don’t often use. What’s important to assert, and what isn’t? Programmers wrestle with this problem every day: which part of my software do I need to test the most? It’s not an easy mindset to be in, but it is possible.
2. Forza 3 takes about 3 seconds to benchmark the top speed of a car. If we ran that test across our low-ball estimate 13 million cars, it would take 1.2 CPU years. Against our conservative estimate of 13 billion cars, it would take 1276 CPU years. Oh dear. But! This just means that a brute force approach to testing isn’t possible. If we just look at the characteristics of the problem, maybe we can do better. Winning a 1 mile drag race is all about horsepower… what if we just calculate the statistics for each car and compare the HP? With a completely made up number of 0.1 seconds to calculate, we bring the numbers down to 15 days and 42 years, respectively. Some intelligence of searching (like testing the most expensive parts first) should improve the time it takes to get useful results.

As you can see, the struggle with designing correct emergent systems is a fight that designers are doomed to lose.

On the one hand, emergence is the key to making great games, experimentation and choice are a linchpin of the form. We can’t get rid of it, nor try to artificially constrain it. On the other hand, emergence creates systems that encourages abuse, being poked and prodded by millions every day. All it takes is one to communicate their results, and it’s all over. Gamers don’t want to lose in races to Datsuns. Testing against the emergent properties is going to become very important. I’m currently exploring this problem, and I hope to have something to show you all soon.

Until then, I’ll spend some time making the back of my Datsun look pretty. It’s all you’re ever going to see.

1. The Turing Test is well within our grasp if you understand the boundaries of the test: convincing someone else you’re human with just textual responses does not require sentience! [↩]