Design

What if we don't succeed?

This is the second article in the Back to the Future theme week series.

One of the most useful advice that has proved its worth to me again and again, both in creative work and in business life, is "fail early, fail often." It might sound counterintuitive, but it simply means "have a lot of ideas, discard the bad ones before you've spent too much time on them." The word "failure" is used here in the most positive connotation it can have.

Not all ideas are equal. In the best case scenario you get an idea, realize immediately that it's not viable, and discard it. Even though the idea was a failure it was useful because you can now focus on better ideas. If you have 100 ideas it's best to shift through them quickly instead of finding the hard way which of them is the gold nugget.

Even if a project is based on a good idea, the details will need constant revisiting.

Doc Brown pointing at a sign in a miniature model that says "Point of no return"

Don't let a bad idea get past the point of no return.

The creators of Back to the Future had always envisioned Michael J. Fox to play the protagonist, Marty McFly. When the filming started Fox was unavailable because he was starring in a popular sitcom Family Ties. Eric Stoltz, an up-and-coming young actor, was cast instead.

A billboard crediting Stoltz as the star of Back to the Future

In an alternate timeline, Stoltz was the star of the film. (Screen capture from Fringe.)

In late 1984, after a few weeks of filming, it became clear that Stoltz wasn't right for the part. He was by all accounts a good actor but he just didn't have the personality or the comedic sense that the part required.

At this point they had basically three choices. Keep filming with Stoltz, risking an inferior end result; change the lead to someone else; or try again to get Michael J. Fox on board. Thankfully they went with the third option and managed to strike a deal with Fox and the producers of Family Ties. Fox joined the cast, Stoltz had to go, and the movie was better for it.

Changing the lead actor was a dramatic decision and it was made right before the point of no return. Recognizing the failure earlier would have saved them a lot of money and wasted effort.

Two pictures from the same scene where Marty McFly looks at his young father in the past, the first one with Eric Stolz and the second with Michael J. Fox as Marty McFly

Above: Eric Stoltz as the original Marty McFly.
Below: Michael J. Fox in the final film.

Other famous but less dramatic "failures" were the first drafts of the script where the time machine was built from a refrigerator instead of the iconic DeLorean, and the original ending in later scripts which involved getting the 1.21 gigawatts of energy to power the time machine by driving it into a nuclear explosion test.

A storyboard frame showing a nuclear test tower

A frame from an early version of the Back to the Future storyboard

The moral of the story is that it's best to fail as early as possible. It opens up a possibility for choosing something better.

The important thing to acknowledge is that you can't plan for success when you're doing experimental or creative work. Failure is always an option. The only time you can plan for success is when you're doing something that's already done and tested before, like assembling Ikea furniture or designing a game by cloning an existing one. When you're creating something new, no-one can tell if it's really going to work or not before you can see it in action.

It's also important to not take the principle too far. Some ideas need time to grow to their full potential, so discarding them would be a mistake. Balancing between being bold enough to discard probably bad ideas and holding on to potentially good ideas is the hard part.

Identifying failure points

Coming back to game design, failing early means identifying potential failure points, testing them, and making correcting moves or even discarding the project if needed.

Pretty much every aspect of game design is a potential failure point. To name just a few:

  • Game mechanics
  • Plot and story structure
  • Characters and character relations
  • Setting
  • Geography
  • User interface

The key is to think what will be this game's innovation. Tried and tested details probably won't be a problem, it's the things that are going for something new that are most likely to require repeated iterations.

Once a potential failure point is identified, the best way to find actual problems is prototyping. Make a small example that shows the thing in action; implement the game's core mechanism, at least partly; start writing from the climax of the story instead of from the beginning; write the key interaction between main characters first. Once you have something concrete, no matter how small, you can more easily get a sense of whether it will work or not.

Being brutally honest

I was writing a comment to The Many Authors of IFComp over at Sibyl Moon Games, but it became so long and slightly tangential that it's better to post a proper article instead.

Historically there have been several parser IF writing communities with partially overlapping members. The "main" community, originating from rec.arts.int-fiction newsgroups before largely migrating to the intfiction.org web forum, makes up for the bulk of the high-profile activity and covers the most diverse collection of authoring tools. Smaller communities are usually focused around individual authoring systems (ADRIFT, Quest).

The approach these communities take to providing feedback to authors varies greatly. The main community used to be on the far end of the scale: "brutally honest" would probably describe it best. The community expects and rewards quality, and things that don't work are meticulously brought out in reviews.

On the other side of the scale there are communities that reward effort. No matter how bad the game is, you get cheers and pats on the back just for releasing it. Feedback, if any, is overwhelmingly positive. The community doesn't necessarily even expect that published games would be open for criticism.

The games produced by these two extremes are also very different. Communities that only reward effort produce a lot of games that are almost without exception, to be brutally honest, utter crap. This is because of two main reasons: Firstly, there is no incentive to spend time designing, polishing and testing your game because you'll still get the same reward in positive responses no matter what the quality of the result is. Secondly there is no peer pressure: when no-one expects high-quality games, there's no outside push to aim there.

The brutally honest camp produces less games but they're generally of better quality. There's a sieve that the authors are pushed through: all work undergoes close scrutiny. Authors who can't handle the criticism will drop out, but those who stay are less likely to repeat their mistakes and more likely learn from the feedback and keep improving. The peer expectation of game quality is generally high and the authors aim higher in the first place.

The downside of unchecked criticism is that, from the point of view of an individual author, the feedback can feel unnecessarily harsh. A novice author can easily give up if the feedback is crushing, which is understandable; when you do things as a hobby, you want to have a positive experience or you go do something else.

The challenge is to combine the better parts of the two extremes. How to not punish anyone for producing creative work but at the same time encourage high quality?

The trend is already moving in this direction: some reviewers (including me) post only reviews that are net positive and events like Spring Thing have non-judged categories. This is only a partial solution. Lack of feedback shields authors from negative feedback but also leaves them without means to improve.

It would be great to have some kind of mentoring system where experienced authors could help out newcomers to design and polish their games. The downside is that it's not mass-reproducible: it would require a lot of effort from the mentors and the ratio of newcomers to experts is too high for everyone to get a mentor.

How to make a great IntroComp entry

IntroComp 2015 logo It's IntroComp season again! IntroComp is one of the oldest active IF competitions, run yearly since 2002. The idea is to make a short intro that showcases a work-in-progress that will eventually be expanded into a full game. Competition judges are asked to rate the entries based on how much they would want to play the full version.

Here are some tips for competition participants on how to make the best of their entry.

Plan further than the intro

This is perhaps the most common sin of IntroComp entries: the author has not designed the game beyond the entry itself, which makes it hard to continue building the full version.

It would be wise to have the story and gameplay thought out at least twice as far as the actual intro, preferably all the way to the end, at least conceptually. This includes visioning what happens immediately after the intro ends and what is the overall story structure: the intro is the beginning but what happens in the middle and how the full story is resolved in the end. Otherwise there's a good change that the intro ends in a creative dead end with no easy way forward.

It's not hard to tell if an author has planned the story beyond the intro. Intros with short term design are often tightly self-contained and convey no feeling of there being something else beyond what you see. When the world and the general plot is well thought out, it's almost automatically visible in the resulting work. (See also a previous article discussing the subject.)

Start with the relevant story

Sometimes the word "intro" is taken too literally and the entry ends before the actual story even gets to start.

A fictitious example: Your story is a retelling of the 12 labors of Hercules. A good intro would contain the first labor to its completion; it would give a good indication of how the gameplay works and judges could easily imagine what the rest of the story would look like in its full version.

A bad intro would be about Hercules packing his backpack and a puzzle about finding a map for the location of the Nemean lion, and it would end just after reaching the entrance to the lion's cave. It would tell very little about what the game is actually like.

So cut off everything that's inconsequential to the big picture and start right from the action.

Make a proper ending...

Even though we're talking about introductions, it's still important that the entry reaches some kind of conclusion of its own. Sometimes that's easy to do when the story can be neatly divided into independent scenes (like in the 12 labors of Hercules example), but sometimes you'll have to work harder to find a good place to end the intro.

As a rough generalization you'd have one or two short term goals that are resolved during the intro while the overall goal is both left unresolved and made clear to the player.

...but leave some loose ends untied

This comes back to the "plan ahead" advice. Even though it's good to resolve a short term goal or two, there should be some kind of hook that makes the player want to continue playing the finished work.

A cliffhanger is a traditional way to end the intro, but it shouldn't be the only hook. As said before, the intro's purpose is to build expectations for the full version. It shouldn't be self-contained: leave room for future expansion. A couple of locked doors, interesting inventory items with reuse potential, references to NPCs not yet encountered. Anything that makes the player's imagination run wild.

Remember though that it's important that you as the author know where the loose ends are going – you can't just drop a locked door somewhere without knowing where it leads. Anything that serves a purpose usually comes across as such in the writing, whereas pointless scenery is often easy to spot.

Have the entry betatested

While technical issues are not explicitly in the judging criteria, bugs and spelling mistakes will reflect poorly on the entry. After all nobody wants to play a buggy game and the intro is taken as an indication of the finished entry's quality.

You don't need a whole army of testers, one or two should be sufficient for a short intro (although more is always better.) It's easier to find testers for IntroComp entries than for many other games because potential testers know that the game should be short and therefore doesn't require a huge time commitment. Testers can be recruited from the beta testing site or from the intfiction.org forum, among other places.

Remember that choice-based entries need testing too for things such as spelling, tone, and pacing.

The IF Trainer project

As you might have heard from elsewhere, I've been asked by the author of In the Company of Grues blog to design and code a game that would be suitable to teach newcomers how to play IF. This is a pretty sweet deal because we're having the entire development process completely transparent. The development wiki is at inthecompanyofgrues.com/iftrainer where you can see how the game is coming along and leave your own comments.

We're aiming to release at the beginning of September, in time for PAX Prime and before IFcomp starts to avoid being overshadowed.

Continue reading "The IF Trainer project" →

Designing the puzzles of Escapade!

(Please note: the following article discusses the game Escapade! in some depth, so it will contain spoilers.)

I'm not much of a puzzle enthusiast myself. The problem with puzzles is that they tend to come in the way of a good story. Now, to contradict myself completely, so far I have released mainly puzzle games myself. With Escapade! the purpose was to make a puzzle game I myself would enjoy as a player.

In Escapade! your goal is to escape a jail cell. The twist is that there are many ways of escaping, but after all but one of the escapes (the final puzzle) you are caught and returned to the cell. At the end of 2008 the game was submitted to the One Room Game Competition 2008 where it took the second place.
Continue reading "Designing the puzzles of Escapade!" →