The Limits of Simulation

My friend Tracy believes that a certain amount of sunlight and exercise are necessary for the health of the human spirit. Therefore, he routinely drags me into the wilderness to see green growing things, for which I am appropriately grateful.

On Sunday, we went to the Sudbury River, where we paddled four miles through the Great Meadows National Wildlife Refuge in an inflatable, flat-bottomed kayak. And because I am me, I gazed at wild buckwheat and herons and sunlit water and thought about which aspects could and couldn’t (or shouldn’t) be simulated in video games.

Great_Meadows_National_Wildlife_Refuge_2011-10-24_(edited) smaller

Great Meadows National Wildlife Refuge. Photo courtesy of Wikipedia, because I didn’t bring a camera. Whoops.

The visuals are not hard. The summer-blue sky would be easy, and we’ve had the basic tech for rippling, sparkling water for decades. The herons and turtles could have simple AI to describe when they spook and where they go when they do. (Maybe we could skip the invasive water chestnut, though it was a legitimate part of the experience.)

Audio is equally easy. Record in surround sound and play it back: done. There are probably complexities of acoustics and space that I’m not properly appreciating, but I’m lumping these in with “we don’t have perfect resolution yet” on the visuals as a problem that we can safely ignore.

Sunlight and water (stray droplets from the oars) are hard to simulate at home, but in a 4D film, we could mimic these with an overhead heater and a water spray system. Adding the wind is also possible, but it requires a tradeoff. In a VR environment, you can provide 360 vision, but you don’t get wind on your face. In a 4D film environment, fans can provide the wind, but then you’re in a theater-style environment and you no longer have the close, intense visuals.

At this point, our hypothetical audience is surrounded by summer-blue sky and pickerel weed, listening to chirring insects and goldfinches and water against the boat, heated by the sun and occasionally cooled (or startled) by water.

What we perhaps can simulate perfectly, but should not simulate perfectly: the handling of an inflatable, flat-bottomed kayak. Because a flat-bottomed kayak handles terribly.

We did have a keel, but it was at the back of the boat. We were moving upstream, and so was the wind, so the water was composed of many small waves conspiring to push the kayak sideways. And spin the kayak. And, in general, make the kayak go places we did not actually intend to go. It reminded me of nothing so much as the driving controls on Brütal Legend.

In a video game, the player needs some form of input. Mouse clicks, keystrokes, parser commands, control sticks, button mashes – they’re all ways of telling the game What The Player Is Trying To Do. And in an ideal world, that input is a perfect reflection of What The Player Is Actually Trying To Do.

What’s the most frustrating thing in gaming? Intending to do the correct thing, attempting to do the correct thing, and having the game fail to recognize your input, or respond as if you were trying to do something else. To put it another way, flat-bottomed kayaks have bad UI built into their reality. Replicating that bad UI in a game would be a bad idea. Wonky control mechanisms have slain a painful number of games.

Consider a parser IF game where the PC needs to drive to the grocery store. Five possible walkthroughs:

1)
> DRIVE TO STORE

2)
> ENTER CAR
> NORTH
> EAST
> EXIT

3)
> UNLOCK CAR DOOR WITH KEY
> OPEN CAR DOOR
> ENTER CAR DOOR
> TURN ON CAR
> NORTH
> EAST
> TURN OFF CAR
> OPEN CAR DOOR
> EXIT

4)
> UNLOCK CAR DOOR WITH KEY
> OPEN CAR DOOR
> ENTER CAR DOOR
> CLOSE CAR DOOR
> PUT KEY IN IGNITION
> TURN KEY
> PUSH GAS PEDAL
> PUSH TURN SIGNAL UP
> TURN STEERING WHEEL RIGHT
> PUSH BRAKE PEDAL
> TURN KEY
> GET KEY
> OPEN CAR DOOR
> EXIT

5)
Like #4, but then you have to parallel park.

Which of these levels is most appropriate for an game? It depends greatly upon the game itself, and that depends upon what’s been communicated to players.

Most IF games will fall somewhere between walkthrough #2 and #3 – standard IF commands used in a standard fashion.

Walkthrough #1 is higher level than most IF games. If nothing important or interesting happens while the PC is driving, then this is excellent – except that players will be trapped in guess-the-verb misery, if the game doesn’t deliver clear instructions.

In general, I’d expect to see something between walkthrough #2 and walkthrough #3, since those are a “standard” level of simulation in IF, and use no unusual commands.

Walkthrough #4 is more detailed than most games. It could be cool, under the right circumstances, but the author would have to have a very good reason for this. If it’s just simulation for simulation’s sake, it will dissolve rapidly into frustration and tedium.

Walkthrough #5 is a disaster. I haven’t written out the play-by-play walkthrough because I’m not even sure what it would look like. Parser IF is a particularly bad medium for communicating spatial relations, and parallel parking is about nothing else. Confronted with this problem as a player, I’d be utterly doomed, unless the game relented and accepted “>PARALLEL PARK” – which would be completely unbalanced against the rest of the walkthrough, and trap the player again in guess-the-verb hell.

There are times when it’s appropriate to build the most accurate simulation possible. When my fiancee was learning to fly planes, she trained on a flight stick and a copy of X-Plane in addition to her regular flight hours. But X-Plane is marketed specifically at people who want the most authentic flight experience possible. Their target audience prizes simulation quality above everything else.

Far more frequently, a better goal is to build the best input mechanism possible, and thereby to streamline connection between player input and game response. This won’t make a better simulation, but it will make a better game.


Thank you to everyone supporting Sibyl Moon through Patreon!
If this post was entertaining or helpful, please consider becoming a patron.

Bookmark the permalink.

3 Comments

  1. …unless the game relented and accepted “>PARALLEL PARK” – which would be completely unbalanced against the rest of the walkthrough…

    Yes! Consistency is important.

    This reminds me of one of the things that bothered me about Adam Cadre’s I-0. There’s a scene in which the PC accepts an offer of a lift, and a few paragraphs of uninterrupted narration take you from the moment she gets into the car to about an hour later. As I discovered later, though, the game does not assume that the PC has buckled her seat belt unless you explicitly tell her to (after she’s already been in the car for an hour). For me, putting on the seat belt is such an automatic part of getting into a car that it never occurred to me that that action wouldn’t have been included, in the same way that closing the door is. So it felt to me as if the game was being unfair when it turned out to be important later whether her seat belt was fastened—but perhaps it just reflects a difference between my background and expectations about normative car-riding behaviour and those of the PC and/or the author, rather than a flaw in the interactive design.

    • Based on a sample size of two (you and me), your expectations about normative car-riding behavior are not unreasonable. I was trying to be obnoxiously exhaustive about walkthrough #4, and yet I didn’t think to mention the seatbelt – while still entirely expecting (in the back of my head) that the PC would wear a seatbelt!

    • I actually thought that worked particularly well, because it subverted my expectations; it was frustrating, but also clever, and it let me feel ‘smart’ when I went back & re-did it. (which is weird, I admit that!)

Leave a Reply to Q. Pheevr Cancel reply

Your email address will not be published. Required fields are marked *