Thursday, August 25, 2011

Including Failure as Part of the Game.

This article is in response to a post made here:
http://www.gamasutra.com/blogs/BartStewart/20110820/8235/In_Defense_of_Surprising_Gameplay.php

In a recent blog post to Gamasutra Bart Stewart states that contemporary game designers are making games which are devoid of surprise in the form of of anticipating every possible event. He also states that some players like this and are being catered to while gamers who would appreciate surprises are being ignored. He postulates that the possible reason for this scenario is that unpredictable events may lead to unfair situations for the player. He fears this will make things boring and points to developer blogs who work in procedural content generation as a possible solution.

I agree with Mr. Stewart on most points. But one point in particular has grabbed my attention. It is the possible scenario that players may fail because of the conditions put in front of them through a randomly generated sequence. I made me stop and think how games are designed today and what they reinforce.

Simply put most games today state that ‘you will always be able to succeed’ and ‘failure at a task means you just have to retry’.

It concerns me to think that this is what games are all about because life is rarely so simple. There are some tasks and scenarios where the best option is to not attempt them or not confront them (at least not directly) if you don't have the power to change them.

I think some players would be disturbed by being confronted with the existential night-mare of a game that gives them no choice to let them succeed. However they are just rejecting a reality and playing a dream, another nightmare, to where they can always succeed. Cutting the “philosophical bull-shit” for a moment; allowing the player to always win is same as always having them lose. It is boring!

It is also misleading and possibly dangerous to have players only win. Here it’s not about what games are doing but what they could be doing; teaching players to overcome failure. Now when I say failure I mean specifically ‘Player Failure’ the player needs to screw up, NOT the character the player is playing. If a player doesn’t make a choice that leads to failure then they have not failed. players need to be in a scenario where success is difficult but not impossible. Just because you want players to fail doesn’t mean you can force them either. Forced failure isn’t failure. To have failure you must have the possibility of success and the player must choose to get into this scenario. If you don't do this it wont be a real failure to the player; it will be ‘what was supposed to happen’.

So what happens AFTER the player fails at a task that they could have (improbably) succeeded at? The game needs to apologize. someone needs to say “we never should have let you go in there”, or “you didn’t have nearly enough training to operate that machine correctly”, or even “you have failed several times while performing stealth operation; you need additional training before Attempting another.” It sounds harsh and kinda rough. But it will be the truth and the next step is that the game will need to help the player overcome what they are bad at.

Games with plausible failure need to also offer redemption. Players who fail at a driving sequence need to be retrained and re-offered challenges that allow them to prove to themselves that they are competent at driving. This would build an arc telling the story of the player failing, working hard and then overcoming the challenge before them. The game delivers a message that scenarios are not win/lose but that failure is part of learning and attempting new things.

I think that by treating the player as the main character it will help elicit emotions in the player and create a stronger response to the game. I will admit that developing games for these scenarios of failure can be difficult and require additional content. However I think the payoffs of including failure as part of the game design will be worth the additional content requirements.