Approaching the task of creating a narrative for ‘Take On’, we knew that everything had to be driven forward by gameplay. Narrative and simulation games don’t traditionally go hand in hand; at best, they’re uncomfortable cousins. Try to marry ‘em up,and people will have eyebrows raised at all sorts of ambivalent angles.
So, why seek to merge the concepts? Primarily: engagement. Constructing a simple narrative framework within which gameplay instances can take place, controlled by a progressive flow of complexity (i.e., the skill required by the player), affords us an opportunity to add a richness to - and provoke an engagement with - the overall experience.
Below, we track the design of Take On's narrative element from its inception through to the beginnings of implementation.
Approaching the design of a game-based narrative, we’re met up front with a number of challenges. The idea alone is something of a contradiction: player-agency competes with the guiding hand of the author/designer at every turn. Indeed, the process itself competes against its development context, an environment where dependencies are high and competing gameplay elements and engine features may be added (and dropped) at (or between) a number of development milestones. Furthermore, we work alongside at least two identifiable constraints: the eclectic (and changeable) abilities of our player, and the genre of the game itself. By recognising and examining each of these challenges up front, we're in a much stronger position to address our narrative design.
Picking it apart, we've already identified at least three complexities here - player-agency, our development environment and the narrative’s design contexts - and our list isn’t anywhere near exhaustive. Arbitrary? Perhaps. A place to begin? Almost certainly. We’re empowered to design a robust narrative framework and appropriate plot structure. These function to mitigate our risks, and sketch out the boundaries of a malleable creative space. It is here that we will then begin to create context, shape characters and build our story with added confidence. It is here that we can begin to nail down our creative content with greater authority. But first, we might consider our initial complexities with a little more care.
Narrative in Contradiction
A game – at least, in the purest sense – may act as its own ‘story’, player-agency driving drama towards some sense of ‘ludological’ conclusion. The experience is not necessarily subject to the will of an author; at best, it’s guided: liable to augmentation (or constraint) by a player's skill with - or state of immersion within - any particular game. Sitting atop our ivory tower, we might debate the discord between the story-narrative the ludo-narrative; yet, at the ‘coal-face’ of development, the bottom line remains clear: grafting a big white elephant of narrative and dropping it squarely on top of a game will lead to disaster. Fundamentally, the narrative must be in sync with the gameplay; it cannot be a monolithic entity operating upon some separate plain of our design's existence.
Balancing exposition with gameplay mechanics requires both analytical objectivity and subjective thought. Narrative that is arduous and overbearing to one, may, to another, be evocative and real. Trying to predict the ‘sweet spot’ of exposition and gameplay across an eclectic player-base is a challenge. Risky narrative choices can damage a game as a whole; yet, shifting methodologies towards a design-by-committee approach risks overlooking unique or innovative opportunities. Understanding the risks while maintaining creative freedom is essential. Our solution is to create a multi-layered narrative, wherein – to an extent - players are empowered to involve themselves with the story as much or as little as they prefer. Core gameplay must be readily available to those who want it, while a depth of narrative is accessible to those seeking a ‘richer’ experience.
Narrative in Development
In terms of the development environment, narrative is often required to pay a high price. Iterative development methodologies mitigate the risks of getting behind schedule or going over budget - particularly where new engine tech is involved - but how does a monolithic narrative adapt to this environment? Let’s say we plan to feature a fire. Writing a novel, for example, it's up to the author alone to describe it - it is fundamentally integrated into the exposition of the plot; whereas, in development, one might write a story that involves a fire, only for a programmer to reply - two months later - that, no, actually, you can’t do that, we can't get it past prototype, sorry old chap. Essentially, development is more modular, with a number of components (hopefully) coming together to form the whole. This is, comparatively, more problematic, where each identifiable dependency introduces another risk.
Such a comparison is arbitrary; however, it identifies a fairly common problem: dropping features amid the process of implementation. Moreover, it conveys that, although two forms of media may seek to evoke narrativist experiences, they each require their own distinct approach. For ‘Take On’, a flexible, risk-aware framework was adopted. Building a narrative upon a more formal analysis may appear stifling; indeed, taking risks can drive creativity. Certainly, no one looks to actively drop gameplay; yet, we must accept that - if a planned feature doesn’t make it to alpha - a once carefully-crafted narrative arc may be left in ruin.
Narrative in Context
With helicopters, we’re dealing with a highly specific context. We started by looking at everything you can - or might want to do - in a chopper, and sought to identify atomic pieces of gameplay. Now, after trimming away gameplay that is too dependent upon other, risky design decisions – say, fully modelling, animating and voicing an enormous mutant reptile - we need to evaluate what the player will actually be able to handle or may learn to handle. And therein lies another problem: our second context. Just FYI: a Godzilla dream-sequence (copyrights aside) could have been a real winner, though.
Approaching other forms of media, we (broadly) know how to access them. Picking up a novel, it’s likely that you can already read. Watching a film, you’ll generally have the bladder-capacity to sit and view it. Although we'll find exceptions to such simplistic observations, the point remains that even when it’s not completely 'understandable', it’s likely to be 'consumable'. We might think about Take On itself as a 'text', wherein helicopter flight is something approaching it's own 'language'. How, then, do we begin to translate that to the reader-player, yet maintain the integrity and natural 'beauty' of the original text? We must consider both those players who have hours of (often real life) flight-time and, also, that guy who once piloted a transport chopper in PvP multiplayer - only to smash into a tree seconds after take-off - never to fly again (you know who you are). In essence, we have a range of proficiencies.
Narrative in Requirements
Creating a game's narrative is a tricky business , however, it's not the conflicting mass of problems and needs that it may appear; at least, it needn’t be. We can attempt to boil things down to a set of identifiable, atomic problems, translate those into core requirements, and highlight any constraints under which we’ll operate. Now, that doesn't feel very creative. In fact, that sounds an awful lot like Requirements Engineering. Well, that's almost exactly what it is. Narrative design is stripped down and rebuilt within the modular, milestone-driven structure and requirements of developmental implementation.
So far, we've managed to highlight some fairly high-level issues, or constraints, under which our design must operate. In slightly more formal terms, we've identified the following:
- Narrative is subject to and augmented by player-agency
- Narrative is subject to changes in the development schedule
- Narrative is subject to a limited range of helicopter gameplay
The list isn't exactly exhaustive but our constraints give us a point of reference, which we might redeploy in our domain analysis - a procedure that looks at a problem in its context. Here, we might evaluate other games or stories - both specific to our helicopter genre and in broader terms - and try to identify how these constraints have impacted upon their design, or analyse the impact of failing to respond to their needs.
Building upon our problem and domain analyses, we can begin to identify some specific requirements, which will drive the narrative design:
- Narrative must drive gameplay progression
- Narrative must construct a broad context, which encompasses various types of flight, experiences and environments
- Narrative must cater for a range of player-proficiencies
We'll be able to use these atomic pieces of necessary functionality to build an abstract framework: something within which the narrative can freely operate. Note, these requirements don't set out to prescribe any particular content, per se. Rather, we try to make them as objective as possible, to minimise the risk of carrying through any preconceptions that may unduly affect the later stages of our design.
Narrative in Design
After evaluating a ‘long-list’ of gameplay instances, we need to accommodate them into a navigable plot structure. Rather than use a linear approach, which we’ve successfully deployed across several projects, a ‘threaded’ and ‘phased’ structure was designed. A 'thread' is a self-contained set of missions, bound up by one particular sub-narrative. Multiple threads are contained within ‘phases’, which progressively introduce more gameplay complexity to the player. Individually testable and repeatable, this approach enables a degree of modularity. Threads can be changed and adapted independently as development and testing require, and phases can be balanced to pace the introduction of complexity.
Perhaps most significantly, the lynchpin of the structure is the ‘gameplay hub’: the player’s heliport. Here, threads and tertiary gameplay elements - such as a simple economic system of helicopter upgrade-management - are accessible. The parallel nature of this structure provides a degree of flexibility. The ‘core thread’ introduces gameplay via a narrative flow. Other threads may be optional, which, in turn, enables us to introduce more advanced challenges for more experienced players at an earlier stage. Less advanced players – those still learning the ropes - can return to these missions later, concentrating instead on the ‘core’ and ‘tutorial’ threads.
Narrative in Conclusion
Our early design goals are built upon a technical analysis. Such formality risks stifling creativity; yet, in our judgement, the complexity of the problems has demanded a robust approach. Since the sterile nature of the structure is identifiable, we’re in a good position to actively mitigate its problems and passively seek to avoid its effect. This work, however - the creative exercise - forms part of another, inter-related task. Fundamentally, we believe that game-stories require an adapted set of rules and a distinct approach, as opposed to the design of stories found in ‘comparable’ media, such as film or theatre.
There’s no getting past the fact that helicopters are complex machines, which require skill to fly and patience to master; yet, along the way, the player is empowered to create his own drama. Our prescriptive framework simply delineates the boundaries of the creative content, and imposes a flexible structure to facilitate interactions and mitigate potential risks. In this sense, deploying the narrative as a staged, gameplay-driven showcase of features aims to both provide a rich experience and ensure that any given player can approach our game and find a way into the complex, yet rewarding, gameplay challenges offered by helicopters.