State of Failure
Of the many concepts that make up a whole videogame, few are as ‘obvious’ and natural-feeling as the mechanics of player failure handling. Even the very very first videogames included a definite ‘game over’ state that was achieved when player(s) could not fulfil their given objectives well enough. One might say that it is almost a videogame tradition, to present a final dead-end status as a punishment… But is this tradition truly necessary? A forced game-over outcome does not really present anything of value to player, it hampers the natural flow of gaming experience, and given the technologies and gameplay frameworks at hand, there are vast possibilities of acknowledging and handling player failure without needing to halt the game itself. Thus, let’s take a glance at how a few rather popular games have circumvented the anachronism of “Game Over”, shall we?
The most radical approach, in terms of gameplay design and circumventing conventions, would be to turn failure into an impossibility. Whilst the idea that you can specifically not succeed is a gaming trope, it is something that’s not really present in genuine kid’s games. The process of playing is far, far more focused on enjoying the events and actions as they happen, and not trying to achieve a hidden bullet-point list of accomplishments. The fun of, say, playground activities is, after all, an active status enforced by each successive moment of activity, not a state you briefly achieve at the very end of the day after hard labour. And this can easily apply to videogames as well, if the gameplay is structured to prioritise a constant flow of events and spectacles, presenting challenges and tasks to the player in bite-sized pieces of content that naturally and seamlessly both flow into one another and fluidly reset to just seconds ago on unprecedented outcomes.
A specific example of a relatively recent high-profile videogame that incorporates this idea is the Prince of Persia: No Subtitle, released in 2008. It featured an npc companion that would serve as a reset mechanic, catching the main character whenever the player does not manage to perform a tricky jump or other manoeuvre, placing them at the very closest last stable location. This helped to maintain a stable, fast-paced gameplay flow, allowing the player to retry anything pretty much instantly all the while not being too scared or cautious, as there was no threat of having to redo minutes and minutes of already passed content (as would happen with a game that forces player to load a previous save upon “death”). That, in itself, is a rather important accomplishment – the elimination of forcing an iterated repeat of levels and steps the player would normally have to pass through. The lack of such enforced large-scale repetition helps to maintain player’s interest and excitement at seeing constantly new things, and avoids the natural state of annoyance and boredom that accompanies over-familiarity (I will admit that unfortunately the level design itself in this game forced players to retrace their steps several times; a shameful content padding that vastly undermined the benefits of the no-fail design). Arguably it could be said that such concession to failure have made the game “too easy”. Well, no, not really – the actual challenge of performing a sequence of jumps, or of defeating an enemy, is still right there and unchanged, the no-death mechanic does not auto-complete or auto-pass anything. What has been dealt away with is the repetition of already passed content up to that particular point of mistake. It is no lesser or greater in challenge levels, it is just less of a punishment.
A different way of handling player failure is to at least allow the game to acknowledge the fact of failure and yet continue the game itself. The mere fact that the player has failed to achieve an objective should not be a reason for actual cessation of action. Sure, the objective itself is failed, and it will need to be re-tried, but with proper design all that can be handled on the go, without forcing a reversion to an older game state via savegame loading. Such a way of handling things is especially important in free-roaming open-world games, where the illusion that the game world itself is progressing and advancing reigns supreme. It also ensures a more authentic feeling to the player, bringing the game’s internal rules closer to real life, which also is not reloaded & restarted every time something fails, but simply continues progressing onwards. And there’s nothing to stop the player, or person, to just try again – maybe in a different way.
The more obvious examples of such mechanical structure are the Grand Theft Auto 3 & 4, and Burnout Paradise games. In both cases the player is placed in a semi-realistic open world, where death or objective fulfilment failure simply flows onwards into further game processes. In the GTA games, if the players die, they are resurrected and transported to a “hospital” location, and can immediately continue playing. If a mission is failed, then it simply reappears at its designated start location and the player is free to retry it at his own will – maybe after stocking up on resources (health, armour, ammunition, armament) or doing something else for a while. Burnout, as a car-based racing game, obviously has physics for car damage modelling. Obviously, the players can wreck the cars they are driving, but that does not lead to a reload of a savegame. In case of regular crashes, the game just shows a cinematic view of the crash – fully acknowledging the spectacle and awesomeness of it – and merely replaces the car on the road it was on. The fact that the velocity is now at 0m/s and a few seconds were spent during the crash is enough to provide a negative overall balance and allow the opposition to catch up / overtake / gain more advantage over the player, forcing them to at least try and avoid crashing overmuch. Repeated crashes over the same event (race, derby, and so on) can actually lead to the event itself being ‘lost’, but, as with the aforementioned GTA games, the event is simply re-enabled at its designated start location and the player can choose to drive back there and start/try again, or just do something else – at no point is the actual in-game driving paused, or a savegame being forced to load. It all progresses smoothly from one mission/player state into another without breaking the surrounding world.
And, of course, there is the more involved and demanding (on developers) way of handling player failure – not only acknowledge its existence, but also acknowledge and handle its consequences in a fluid state. This is the ultimate embrace of a realistic, logically solid cause-and-effect in-game universe, where all player actions have consequences that all still lead to the game progressing and further gameplay potential revealing itself. To truly manage this, the structural framework of the game must have a way of handling player ‘death’ as well as choices that are exhibited both directly and implicitly via actions performed. This is a challenge both in terms of gameplay design and of lore concept – how to handle resurrection, how to handle fluid continuation of the game, and how to enforce and allow for consequences without allowing them to pile up over a maximum viability limit (beyond which the sum of all consequences could potentially make the game practically unplayable – especially easy if the consequences are similar to, say, stacking debuffs).
Few modern games actually handle this well. One might claim that Bioshock had something along these lines with its Vita-Chambers that did not reset anything in-world, so enemies already defeated would remain defeated. Perhaps the escape-pod mechanic in EVE-Online is a viable implementation of consequences and choices – after all, player property is lost due to their lack of ability or poor judgement, which means that certain further gameplay will be needed to recover or replace lost assets, and until then the player is more susceptible to further hostilities / damages. Also, a game I’ve described a few posts back – A.I.M.2 – also has this nigh-perpetual gameplay flow. If the player’s vehicle is destroyed, a personality core is dropped, which is scooped up by automated rescue hovercraft and quickly delivered at a nearby vehicle-selling station, where a new replacement can be bought (or the most basic one is given for free if there is not enough money in player in-game account). This both prevents a reset of game state, as all events will have taken place and all actions will remain valid, and it provides a direct feedback – consequences – to player actions that led to the destruction of their craft without actually stopping anything.
Whichever method is chosen – and I suspect that these three are hardly the only alternatives to the basic, outdated “game over” screen -, the core argument is, I trust, pretty clear – with modern technological possibilities, there is no excuse for cheaply and completely stopping the entire game if the player somehow fails, and there is no reason for forcing them to retrace/replay the last 10, 20, 30 minutes of content they have perfectly done/passed and experienced at least once already. Neither frequent autosaves nor checkpoints are a true solution – they are merely more accessible reset points, but they are reset points nonetheless. The true solution is to predict and provide for player failure, and – whether by making it impossible, or by acknowledging and implementing mechanics for its handling – allow, nay, force the game itself to continue without pause in order to provide a truly fluid, fresh experience.
~X2-Eliah does not find redoing a whole level 10 times because of one single tricky jump ‘fun’ or ‘rewarding’ in any way.