Images on this post have been lost.
Designing a game spawns an endless set of ideas – ideas that need to be sorted. In order to do this, you need a method of evaluating them. The following discusses five different gameplay models – ways of thinking about game design – that can be helpful in choosing between ideas, and how they affect the final game.
I’ve previously talked about how games are, when it comes to narrative evolution, “too much fun for their own good“. I’ve also given a specific example of this by comparing Resident Evil 4 and 7 and shown how development focus can make a huge difference to the final game. But one place where I think I’ve been a bit vague is that I’ve been talking about a position taken during development. “Games are too much fun for their own good” is not a value judgement about games in general. It’s all about the effect this has when creating a game. This is an incredibly important distinction to make. While you can debate forever over fuzzy subjects like “is this a game?” and “what is the purpose of games?” it’s a fact that your intentions during design will have a huge impact on the final result.
When designing a game, or doing anything creative for that matter, you are basically navigating a space of ideas. At any point there are a bunch of decisions that you could be making and you need to base these decisions on some sort of plan. How you come up with this plan will be highly dependent on your values, processes, restrictions and so forth. What all this boils down to is a need to constantly evaluate the project’s current state and adjust its trajectory.
For a long time, the general advice in game development has been to “follow the fun”. But this is far from the only way to evaluate a project. In this post I’ll present a few different ways to go about it. Take note that it is very uncommon for any project to rely purely on a single method. Different aspects of a project usually require a slightly different mindset. It is however very common to base the majority of design decisions on one type of evaluation.
Classical Gameplay
Let’s start with the most common way of working in game design: to follow the fun. When working in this way you normally try to find a good “core loop” that provides the basic engagement factor for the game. The rest of the development is then spent enhancing this core loop in order to make it as engaging as possible. This could mean that new mechanics are added on top (e.g. crafting or levelling) or that the core design is tweaked until it generates the most fun possible.
When creating a game like this, you can usually start by figuring out what works and what doesn’t early on. It’s also possible to hand it over to playtesters early, and to have continuous testing throughout development. The art and story are often also heavily based on how the gameplay works.
Metric-Based
This is the sort of design that you see a lot of in free-to-play games and it’s incredibly common in mobile games. Here the goal is not to make the game as engaging as possible, but to set particular goal metrics, and then tweak the game to adjust player behaviour so that the metrics measured reach those desired goals. Sure, you are often looking for a certain amount of fun in the game, but when it comes down to it, no matter how much fun a certain decision creates, if it doesn’t produce the right change in metrics, it is a bad choice.
When making a game like this, testing on users is paramount. You often want to release the game as early as possible and then start tracking things like retention rate, daily active users, and churn rate. The better numbers you get, the better the game matches your goals.
Deep Mechanics
While both of the above methods put some focus on constantly asking the question: “Is my user having fun?”, this type of design takes a different route. It’s quite unusual for this to be a major evaluation method, but games like The Witness (2016) and the upcoming Miegakure do just that. In their talk “Designing to Reveal the Nature of the Universe Jonathan Blow and Marc Ten Bosch (creators of the two previously mentioned games) lay out this way of thinking about the design. Quickly summarized it’s all about taking your game’s mechanics as far as possible. This makes it different in that it is no longer about creating maximum engagement. Instead, it’s all about maximizing the depth of the gameplay. When following this design you really want the game to squeeze every possibility out of your core mechanics.
Just like with classical gameplay, you want to start with the core loop, and you also want people to test early and regularly. When it comes to art and story, they are only there in order to enhance the gameplay. The main goal is not to aesthetically please your viewer, but to have the art and the story that are best at conveying the mechanics to your user.
Classical Plot
Another way to go about designing a game is to just view it as a standard story. Your utmost concern is to make sure that the end experience works in terms of classical ways of structuring film, books and other traditional storytelling media. When creating a game like this, you generally start out with a script and then develop the gameplay in order to support what that document says.
The interactive movie genre is something that very strongly uses this model. It is also very common in RPG games, which can be said to interlace this with sections of more classical gameplay. There are also many adventure games that mainly adhere to this approach when evaluating progress.
Narrative Driven
This is the approach that we at Frictional Games are following to the greatest extent right now. It is also the approach that this blog mostly refer to as a way of crafting better narrative in games. In this type of design the goal is to make the activity of playing the game produce a certain type of experience. The goal is to maximize the efficiency in which the intended experience is delivered. For example, in a horror game, the goal might be to make the player as scared as possible.
In this case you normally start with some sort of emotional or intellectual experience that you want to convey. After that you add features, both gameplay, story and art-wise, in order to make this experience come across as clearly as possible. What stands out when compared to other approaches is that there is no core feature, such as gameplay or plot, to fall back on. Instead you have a fuzzy goal that you are trying to reach, and many different parts of the game are needed before you can evaluate whether it works or not. Because this often requires a lot of high quality content, playtesting is made relatively infrequent compared to other approaches.
It is this approach that I believe is the future of interactive storytelling. We can only get so far by focusing on classical gameplay or storytelling techniques.
It’s worth noting that these types of games by no means need to be story-heavy. A great example of this is the game Duskers (2016), as explained in the creator’s GDC talk. While the game started with a classical gameplay approach, it later put a ton of focus on delivering a couple of core pillars such as feelings of isolation and realism. Because of this I think it is a good example of using a narrative-driven approach for development. The game is by no means a pure example of this approach, but it is an excellent example of how different it can make a game.
—
That sums up the approaches I wanted to cover today. I am sure there are other approaches, but these were the ones that felt most interesting to discuss.
As I said earlier, it’s very rare that a project will rely solely on one of these methods of evaluating progress. For instance, no matter how much fun it would be for Super Mario to have a shotgun to blast goompas with, it would never feel fitting to add it. But if you put aside stuff like that, a game like Super Mario bases pretty much all of its decisions on the Classical Gameplay approach. It therefore feels fair to say that it is a game developed using that approach.
I also want to make it clear that there is no best way to develop a game. All of these approaches have their pros and cons, and what it all really comes down to is what sort of game you want to create.
Hopefully these examples should make it more understandable what I mean by “narrative-wise, games are too much fun for their own good” and development being a navigation of an idea space. Consider how different the paths taken during development will be depending on the approach chosen. Some paths will be filled with constant confirmation that you are going in the right direction. These are often the ones you are most tempted to use. Other paths require long treks through uncharted territory and are filled with uncertainty. These are often less tempting, but can also lead to very interesting and unique results.
Now for some examples on how the evaluation process can have a huge effect on how a game turns out.
The first example is the sanity meter in Amnesia. At first the sanity meter was thought of as an important gameplay detail and it was evaluated through a Classical Gameplay lens. However, it started to become clear that the approach was clashing with our wish to have an immersive and very scary game. The lowering of sanity would often become annoying and it was very hard to balance it in way that meshed with our other goals.
Up until then we had focused on making the sanity as much “fun” as possible, and we could have continued down that route. However, due to our discussions, we chose to take a different approach: we asked ourselves what would benefit the intended experience best. This made us consider the whole sanity as an “atmospheric device” instead and we dropped a bunch of related features. The game took on a very different shape because of this and we continued to use the same narrative-driven approach for other things, like monster encounters.
The second example is from SOMA, where we from the beginning were very focused on the narrative-driven approach. This took a lot of different shapes throughout development, but one of the most prominent ones was that, once the prologue was over, the game must be a continuous first person experience without any camera pull-outs or cuts. The reason for this was that we wanted a narrative experience where the player could get a sense of what it was like to “switch” consciousness. This caused all sorts of issues during development, most likely making a few passages, gameplay-wise, less fun. But it was vital to get the right experience across and without this, and many other similar decisions, the game wouldn’t have been the same.
This should hopefully have given a sense of the many ways you can search between in the space of game design ideas. I also hope it’s given some more depth to my two previous entries on connected topics. (Check them out here and here).
It should also have given an idea on just how uncertain the narrative-driven approach is when compared to other ways of evaluating. Because of this, I think the need to understand how our medium works is much greater than it has been before. Next week I’ll try and help with this by talking about presence, one of the key aspects when crafting a narrative-driven game.
Notes:
I am not 100% sold on the name “Narrative-Driven”, but I’m unsure what works better. I thought about “Experience-Driven”, but that felt too broad. For me narrative is (as explained here) all about the emotional journey the player takes when playing through the game. It is a very holistic concept and not reliant on plot details or how much “fun” gameplay is. This feels like it fits well with the point I want to get across. However, the name could be very misleading to people and I suspect I’ll get at least one comment where someone is upset with the article because of it. That said, I don’t expect to use the term a lot and the categorization here is really just to better get the idea of “games are too much fun for their own good” across, so it should be fine.
