It's Twine Week on Electron Dance. This is the last of five posts.
I never had any experience of using Twine until I wrote Truth is Ghost, which was released as part of the Fear of Twine exhibition in February. I had heard all sorts of things. It’s really easy. It’s better than parser IF. It can make your voice heard. It’s the remedy for capitalism. It can make English Breakfast tea.
Now, with a little experience of Twine tucked under my Batman utility belt, I have a few thoughts to share.
It's Twine Week on Electron Dance. This is the first of five posts.
So I wrote about how I had problems with the Twine format. But this year I participated in the Fear of Twine exhibition and, as a result, forced myself to read the other 15 works in the exhibition so I could write about them.
Do I still have problems with Twine?
In his epic Dark Souls Diaries series, Matt “Steerpike” Sakey wrote about a key moment when he felt guilty for killing an NPC he had intended to save. Sakey didn’t have long to mourn. Rather than leave him to wallow in his misery, one commenter told him there was actually nothing he could do. Don’t feel bad about it.
Player guilt is so easily destroyed, it seems, if we learn everything is a foregone conclusion. We are fascinated by what lies behind the curtain and the fear that the game might be making a fool of us, exploiting us through an illusion of agency. No one wants to be Stanley of The Stanley Parable (Galactic Café, 2013), the developer’s puppet.
We crave the weight of consequence yet revel in its destruction. How do we make sense of this contradiction?
In 2012, Jenn Frank wrote about how she rediscovered some floppy disks carrying some of her Norn creations from the artificial life simulation Creatures (Millennium Interactive, 1996). She saw them as coffins. She sent her Norns into stasis on floppy disks but they never woke up; she had murdered her brood.
Save games. A thorny subject for sure. In 1981, we might have asked whether a man was not entitled to the control of his own leisure time. ‘No!’ said the developer from his office cubicle. But we are not in 1981 any more. In 2014, I should be able to do anything I want, whenever I want, with whomever I want, multiple times. Not only can I do whatever I want but I can also shout at people on the internet for doing whatever they want. This is liberty.
The save game is one of the most important innovations in game design. It’s also a promise to the developer that we’re coming back.
But why do we sometimes break that promise?
When British mountaineer George Mallory was asked why he wanted to climb Mount Everest, it was reported his answer was, “Because it’s there.” The desire to climb does not have to make any sense, have any rhyme or reason. The mountain was a challenge that called to Mallory. It’s very existence was enough to seduce him to its slopes in 1924 – and the mountain claimed his life. Mallory’s body was recovered in 1999.
There is a similar pattern in our desires to take on challenging videogames. Playing Super Meat Boy (Team Meat, 2010) isn’t making us smarter and doesn’t teach us anything about the human condition. We might argue that it improves reflexes but this is the kind of comforting babble we tell people who don’t play games. Players need no such justification.
Oh, wait! Except when we do!
Some reviews of Kickstarted puzzle game Full Bore: The First Dig (Whole Hog Games, 2013) find its rewards not shiny enough. “Gems […] have no apparent value other than raising your completion percentage,” writes Britton Peele for Gamespot. “Why should you spend time collecting them, other than because they're there?”
In other words, why should we spend time solving puzzles in a puzzle game?
This is the concluding part of No Alternative, the first part was posted yesterday.
What if someone wanted to market a hypothetical “non-game”? Channels for marketing and distribution have matured for games but are there any channels for publicising or selling “non-games”? Are developers being coerced into calling their works games for commercial reasons?
A couple of years ago in an essay called A Theoretical War, I touched on the Holy War over the meaning of the word ‘game’. The war has not gone away. Each time some ‘alternative’ release reaches across the divide – such as when Proteus (Key & Kanaga, 2013) or Depression Quest (Zoe Quinn, 2013) hits Steam – there’s an outbreak of unpleasantness. This battle to control ‘game’ even has a parody Twitter account, TheGamePolice.
Outside of the mainstream, there’s a strong belief that no one needs to define or control what gets to be called a game. Everything can be a game. But let’s put aside a technical discussion on definitions. The word ‘game’, in popular culture, has connotations. It is a complicated word that means different things to different people.
Last year, Darius Kazemi published a slideshow called Fuck Videogames in which he suggested not everyone needs to make ‘games’. He admitted he had dropped the term himself, pitching his own work under the banner of ‘weird internet stuff’.
Here’s a question for you. Are there problems with calling everything a game? Here’s another. Are there developers who would rather not call their software a game? I consulted Kazemi, Ed Key (Proteus), Auriea Harvey and Michaël Samyn (Tale of Tales) and Dan Pinchbeck (The Chinese Room) on whether we need an alternative.
Puzzle games have a delicious quality. They are honest. The design never lies because everything you need to know is on the screen. There are no special switches and no powerups are required. The answer is in front of you, it’s right there, if only you could see it. Look again. Look harder. This is possible, you know it is.
Actually, now I think about it, the game is taunting you, mocking you. Are you still stuck on this level? Still? Don’t worry, I can wait, sweetie. You just take your time. I’ll have a cup of earl grey over here while you think your brains out.
That honesty? Passive-aggressive is what it is.
This is the final part of the Learning Curve trilogy. In the first part, Learning to Walk, I learnt to program and make games on the Atari 8-bit home computer. In the second part, Learning to Run, I wrote a game in machine-language which was sold commercially.
I think it was 1995.
It was the difficult second year of my PhD at Reading University, where far too many of my water wave simulations exploded into colourful infinity and I wanted to shoot my research in the head five times. We had a series of presentations from industry types looking to charm the latest batch of Dr. Mathematicians being squeezed out of the academic womb. I was impressed by one guy from a company called Geoquest that made oil field mapping software, and followed up on email. I asked Geoquest Dude how I might make myself more valuable after my research was complete. I told him about my grand game-making plans, hoping this would sell me as an unstoppable code hero who could work machine language like Jimi Hendrix worked the guitar.
His response? He told me to stop.
This is the second part of the Learning Curve trilogy. The first part, Learning to Walk, explored how I became a game programmer in the 1980s.
It is 1992.
Beyond small projects, I couldn't finish a damn thing. I had folders crammed full of design sketches for games and numerous disks littered with crude prototypes. I was apt to spend my time on title screens and structure, leaving the actual game bit to be "filled in later", always chasing the high of creation without actually creating something. I believed I was a genius of unearthly codemagick power yet had nothing to show for it except for the work I did with my father: Blitz, Runaround, Escape and also Runaround II (published in New Atari User #53, Dec/Jan 1991). I needed to prove that I had the discipline to see one of my own ideas through.
But that wasn't all I needed to prove. If you wanted to get decent performance out of an 8-bit computer you had to do the business in assembly language. I’d written plenty of machine language snippets and done my share of hacking commercial games to make them easier so I believed I could write one of those grandiose machine language games if I wanted to. But development in assembly language is like having to marshal individual grains of sand into a sandcastle. The scale of the task was enough to subdue any hubris. I needed to prove I could write a game in machine language.
I threw one more goal onto this project of projects. This game I was going to make? I was going to sell it like a proper developer. If I pulled this off, I would never doubt my Atari skills again.