I recently beat Castlevania on my Game Boy Advance.
Am I writing this column entirely for the sake of making that announcement? To give space to what is probably, pathetically, the greatest achievement of my life thus far?
Not entirely. But there's a percentage.
The real reason for this column, the 87% of the reasoning that isn't my Castlevania announcement, is Castlevania II: Simon's Quest.
For the un-Castlevania-ed, the first Castlevania game is simple. Move from one side of the screen to the other, hit things with a whip until you reach the end of a stage, then hit a big thing with a whip way more times. Rinse (with holy water) and repeat. Simplicity at its best.
The second Castlevania game, Simon's Quest, threw that simplicity out of a castle window. Which I'm pretty sure is just a hole, by the way. Castle glaziers, you're not fooling anyone.
In the second game, you're the same guy, you have the same whip, but now you're wandering the countryside, which is positively infested with monsters. The gameplay, the once simple plan of killing everything, changes to the performing of bizarre rituals. You get hearts by killing things, and then you trade in the hearts for crystals. Like someone's weird aunt, you spend most of your time worrying about crystals and their potential powers.
It's this second game, Simon's Quest, that got me thinking about video game failures, and it got me thinking about lessons learned from these failures that I could apply to my own work.
Which is why I bring you these writing lessons learned from video game failures.
Castlevania II: Noob's Clues
I described the game to you a little already, so let's skip straight to the problems.
Castlevania II, like I said, was complex. Which the developers must have known because, as you travel the countryside, you come into villages where villagers provide "clues" as to just what the hell you're supposed to do next.
If you're wondering why I used quotation marks around the word "clues", I'll respond with a question of my own: What is a graveyard duck?
Here are some of the Simon's Quest clues and their meanings:
"A symbol of evil will appear when you strike the stake."
This means you're supposed to hit these weird orbs with an oak stake in order to break them and retrieve the contents. A little confusing, to say the least. Strike the stake? With what?
"Wait for a soul with a red crystal on Deborah Cliff."
What you really have to do is go to the cliff with the red crystal already in hand, kneel, and wait for a magic tornado to come and pick you up, bringing you to the next area. You know, if there are any English teachers out there, translating these clues would make for an interesting grammatical exercise. Screw Eats, Shoots & Leaves.
"Get a silk bag from the graveyard duck to live longer."
If you're thinking about some sort of ghost mallard right now, you're not the only one.
The Lesson
Simon's Quest is a good game. It's fun, there's some good action. The music is tops. The gameplay elements, the mysteries, it's like the game-makers knew what they wanted, but their intent didn't quite make it onto the cartridge.
It begs the question. Didn't they have one person read this and tell them it was insane?
When you're writing, it's great to have trusted editors. And it's great to have a very specific kind of trusted editor, someone who is good at saying, "I don't understand what's happening in this scene."
It's easy for you to see what's happening in a given scene. You made it up. And that means it's easy for you to see elements in your head that aren't on the page.
Of course the clues made sense to the creators of Simon's Quest. They made the entire damn game. They know the thing inside and out.
What they needed, and what you need, is someone to go through your drafts and make sure your narrative does the simple task of making sense. Make sure that if a character puts down a screwdriver, he's not holding it again, magically, a paragraph later. Make sure that people don't just appear and disappear from rooms. If you're having a character hold a crystal and wait for a magic tornado...don't do that. Okay? Just don't.
If you can take something away from Simon's Quest, take away the quest of finding a details editor for you. This person doesn't have to know grammar, and she doesn't have to be an expert in prose. Just someone who nitpicks the physical details and calls you out when you blow it
.E.T.: Burial At Sea... Of Garbage
The Game
Atari's E.T. is one of the more famous bad games. A recent documentary sought to prove a large number of the cartridges were, in fact, sealed away in a New Mexico dump. Which they totally were. That's right, the game was so underwhelming that Atari buried surplus cartridges in a dump!
The game, developed by a star developer with a very unrealistic deadline, was going to be huge. It had an endorsement from Stephen Spielberg himself, who either outright lied about playing the game or really understands very little about video games. Almost dangerously little. Which might explain why the Jaws game is also horrendous. ...wait a second. There were some pretty godawful Indiana Jones games too. I guess it's a good thing he managed to resist licensing The Terminal.
The Problem
Developer Howard Scott Warshaw had crunched before, cranking out finished games from scratch in six months. He figured he could bang out E.T. in five weeks.
Warshaw finished something. But what exactly he finished, it was hard to say.
E.T. is almost unplayable. You walk around, you fall in a hole. You find stuff, then you fall in another hole. There is almost, ALMOST a game hidden somewhere within the confusion. But it's not the game that should have accompanied a smash film, and although sales were brisk at the outset, Atari was ultimately left holding the bag. A bag filled with millions of copies of a game no one wanted.
The Lesson
Warshaw thought he could crunch. He finished a thing, but that's the highest compliment you can really give E.T. Although there IS enough game there to think that, given a little more time, he just maybe could have made something decent.
Take it from a New Mexico garbage dump, you might not be as good at working under pressure as you think. Yeah, you get it done, you get it in under the deadline, but think about it this way. If they'd taken a couple more months on E.T. and made a serviceable game, it wouldn't have gone down as one of the worst games in history. It would have been a blip (or a bleep or a bloop or another Atari sound) in history as opposed to being the awful fart-y noise that signaled the great video game crash of the early 80's.
Stop telling yourself you work well under pressure. Crunch isn't a work system. It's a sign of timetable failure.
Daikatana: I Don't Wanna
The Game
Oh, Daikatana.
If you've never played Daikatana, I'll explain it like this: I have no idea. I have no idea what's going on or how you're really supposed to play this game. You're a guy and you're supposed to find a sword. And you walk around and try to do that. I guess. Things kill you left and right. I don't know. It's a horrible experience.
Daikatana is from John Romero, one of the head developers who brought us Doom and Doom II. It was the next big thing from a promising group of people. Who promised a lot more than they could deliver.
You know, if by making me his bitch John meant that he was going to fool me into buying something I shouldn't, then I am, in fact, his "bitch." By that definition, I'm also the "bitch" of basically every place in a 50 mile radius that sells donuts, hamburgers, and I'm also the bitch of all of the Little Debbie corporation and its holdings. Damn you, Little Debbie and your Swiss Cake Rolls that aren't Swiss or cake and are barely rolls because they're kinda flat on one side!
The Problem
What's interesting about Daikatana is that, demanding I "suck it down" aside, Daikatana might have been a good game at one point.
Here's what happened. A development team started making Daikatana, then a new engine (think of the engine being like the core programming that makes the game go good) came out. John Romero decided to reprogram the entire game to work with this new engine, which added to the timetable for legal reasons, and then added even more time due to programming problems.
What it means in real-life terms is, this game was developed to fit in with a cohort of others, then re-tooled, and then re-tooled some more to the point that it was three generations behind where it should have been by the time of its release, and it was a shell of what it could have been, tortured through all sorts of different permutations. It ended up as just a mish-mash of craziness.
The Lesson
I had a novel that I wrote. Years ago. And when I went back to fashion it into something new, it'd been too long. My engine, if you will, had changed. A few times. Hell, it'd been ten years.
What the makers of Daikatana couldn't do is slap a little year 2000 onto a game they developed in 1997 and make it go.
What I'm encouraging you to do here, the expensive, time-consuming lesson of Daikatana, is to finish things, finish them completely, and finish them in a decent timetable. There's incentive to do it. If you don't, you might never be able to. You might not be able to go back. Don't set your novel aside for two years and expect to finish it later.
Steel Battalion: Too Awesome To Succeed?
The Game
What is Steel Battalion? It's a game where you pilot giant mechs. You know, the kind made famous by Stuart Gordon's Robot Jox. Or more recently by Guillermo Del Toro's Robot Jox 2: Electric Robo-loo (might not have the exact right title, but you know the one I mean).
Who doesn't want to pilot a giant robot and destroy things? Seriously, who? Because I have a lot of questions for you, and they are not worded kindly because I think you're a damn fool.
The Problem
With this one, the problem wasn't so much the game. It was the setup. As much as Steel Battalion was a game about robots, it was also this:
What you're seeing here is the controller set that allows a player to actually play Steel Battalion. It's two sticks and about 40 buttons. Plus some pedals. Oh, and a manual. You're gonna need that.
To start your mech, to START the thing like you start your car, you have to hit 2 buttons, then 5 switches, then successfully complete a test of your timing. Then your mech becomes operable. If you hit the 2 buttons and 5 switches and ace the test, you can BEGIN THE GAME.
Which might sound like a failure...but it's really not. Think about it. There's a certain kind of nerd that eats that stuff up. So what's the problem?
The Problem
The problem with Steel Battalion is commercial failure, which is easy to summarize. The game, with controller, was $200. And the controller was a bear to set up. It's not like you could leave this monstrosity in your living room. Insert joke about sex repellant if you must. Not to mention, this controller ONLY worked on this one game.
While Steel Battalion was a pretty cool idea, the reality of playing it in your home was messy, expensive, and insert callback to previous joke about sex repellent here.
The Lesson
Atsushi Inaba, the man behind Steel Battalion, said at a 2005 conference that Steel Battalion was created to show what can be done with video games that cannot be done in any other medium. And in that way, it may have been secretly, internally, successful. Inaba and his team did create an experience that was immersive and unlike anything else. No movie could replicate the experience of truly piloting a sophisticated machine. Neither could a book. A video game was the best analog experience.
The lesson from Steel Battalion is this:
Even though books are often praised for being "cinematic," and even though book-to-movie is the current path, there's something to be said for writing something that only works on the page. Writing a book that could only work in the medium of the written word.
Don't be afraid to write a book that only works as a book. It might not be a commercial success, but like we see with Steel Battalion, sometimes commercial success isn't the goal. Sometimes the goal is divorced from commerce, and sometimes, rarely, in a shining moment, a non-commercial goal is achieved.
Virtual Boy: Real Oy, Who Did This To My Eyes!
The Console
The Virtual Boy is Nintendo's most-famous misstep. The console, which was originally pitched as a virtual reality experience players would never forget, was a flop. I had one. I can tell you first hand, this thing was no good. No good at all.
The Problem
Red. All red. And not portable. And look at it!
Once in a while there was a pretty decent graphic or 3D effect. But overall—good god. I'm surprised my eye doctor never asks, "You haven't ever played a Virtual Boy, have you?" I'm surprised I was able to get vision coverage on my health insurance. Playing Virtual Boy should disqualify me as it's a pre-existing condition.
It turns out there were a lot of internal problems at Nintendo that really made this crap stew into a full-on shit buffet. The console kept getting more and more expensive, and the creators were tasked with making it cheaper and cheaper to manufacture. Once they discovered that red LEDs were a lot easier to get than blue and green, which would have provided the full color the Virtual Boy was originally slated for, the console's fate was sealed. In bright, piercing red.
The Lesson
Who's the man responsible for the Virtual Boy? Mostly, Gunpei Yokoi. Who is also the man behind the Game Boy, Metroid, and Kid Icarus. This is the dude credited with inventing the D-Pad, that plus-symbol thumb control that guides every character through every NES game.
Yokoi also developed a philosophy called "Lateral Thinking with Withered Technology." What it means is, sometimes cutting-edge isn't necessary to create something great. Sometimes cutting-edge tech gets in the way of making something that's just plain fun. It's a philosophy evident in lots of Nintendo's work. The Wii was underpowered compared to its contemporaries, as is the Wii U. The Game Boy wasn't as advanced as Sega's Game Gear, and yet Game Boy outperformed. Yokoi should have listened to his own philosophy a little more closely while developing the Virtual Boy.
Think about what you've written that you liked. Did you like it because it was something brand-stinking-new? Was novelty its best feature?
Or, more likely, did you like something else about it? Was there a way in which you used existing tropes and turns of phrase in novel ways? Did you build on something accessible, something people could grasp? Did you take a classic story structure and re-tool it?
The lesson here, don't always look to doing something wild and new to solve a narrative problem or create excitement in your work. Remember, you can do it just as well, sometimes better, with something that's proven.
Or, secondary lesson, don't print your book in red LED. I don't know why you would do that, and I hope it wouldn't be necessary to say as much. But just in case.
About the author
Peter Derk lives, writes, and works in Colorado. Buy him a drink and he'll talk books all day. Buy him two and he'll be happy to tell you about the horrors of being responsible for a public restroom.
