The Lazy Designer: The Next Game
Chapter 5 (Part 3)
Gameplay versus Cinematics
Any discussion of flow needs to consider a balance between gameplay and cinematics. Again, as in all things, this will be heavily influenced by the type of game being made. Certain styles of game nowadays rely more on cinematics than others. This does not mean that these games need the cinematics but if they do not have them to the same degrees as their competition they need to offer something else.
Cinematics and high quality voice acting are seen as hallmarks of a professional game title. But even in highly cinematic games it is important that the player, in my opinion, controls as much as possible, the game's flow and timing. This requires cinematics to behave in certain ways, probably the most important rule for them to follow is to be consistent.
If the game is driven by the player's actions in-game... that is, if the player's actions have consistent consequence, then care must be taken when presenting the player in cinematics... the player should not be made to do something inconsistent with their previous actions, even for story purposes. This is a hard idea for some designers to grasp but it has made me stop playing certain games. On the other hand in a game where it has been clearly established that the player is only enjoying a limited use of their in-game avatar (who has its own personality and drive) it is perfectly acceptable for cinematics to take over the character's actions.
It is an issue of expectation driven by past consistency.
And if your game has numerous cinematics (and any modern, voice-worked dialog with animation is a cutscene) those cinematics needs to be skippable. If you have to take the player's control away to move the story forward the player still needs to be able to move past your scene if they choose (though it is best to ensure that skipping cannot happen by accident).
On the other hand if your game design calls for limited cinematics (whether due to budget or as a key component of the game's vision) there are ways to still create powerful and emotional story moments. Stumbling across a ruined house and scouring the remnants for clues to the family that once lived there builds a story as does accidentally riding your horse off a cliff, to its death, or participating in a drag race down the streets of a virtual city. Story can be built via action without text, recorded dialog, or cinematics.
In many ways by withholding information suspense is created and a player might be even more motivated on a quest to answer the mysteries that have been presented. Clearly the player needs sufficient motivation to begin the search but I think many designers would be surprised at how little hand-holding and explanation is required to motivate a player.
So do not despair if you lack the budget to do a fully voice recorded game. Just be clever, or if you feel you are lacking in cleverness get your hands on older adventure and role-playing games to see how story was told by an earlier generation of designers. Some of the techniques might be crude compared to today's games but I suspect you will learn a design trick or two from them.
Designing by Data
Though I would never encourage designing a game entirely by data (after all the heart we all put into our projects is what really makes them shine) all designers should use data to some extent to help flesh out their creations. A later Lazy Designer book will explore this topic in greater detail, with solid examples from my experiences at BioWare but I'd like to plant the seed of this idea now to encourage you to design with data tracking in mind.
This might be data tracking embedded during the development phase, using the tester's playthru to guide the finished project. Are there areas that are too empty and should be filled or removed? Are players expressing a great deal of satisfaction somewhere... what's working well in that encounter? These hooks should be integrated early in the process and assessed regularly.
These kinds of data tracking are also useful when running focus tests. Even though these are technically external tests, they are still being done in the context of the development process. Which means that the game can still be changed to accommodate what the data is telling us.
On the other hand external hooks are data tracking that is in the shipped game. Basically this is real data, the stuff your actual players are doing. This can be immensely useful when developing a sequel to a title. With data from the first title in a series you then decide which things were popular and which were not and plan the sequel accordingly.
Some things to consider when leaving data hooks in after ship.
- Privacy Players should consent to having their data tracked. The actual specifics and requirements of this consent vary but err on the side of caution. Only track really basic stuff (how far into the game completed, hardware specifics, et cetera). Keep in mind that even the choice of the gender of the character the player chooses might be considered private by some and not something they want to share.
- Be Social One way to encourage players to consent to the release of their data is to add a social gaming layer to it. I think there is a lot of potential here. It might involve designing intriguing interactions between players, or even between players and developers. Maybe players are allowed to compare maps of their playthrus... how they actually navigated a particular area. Maybe they record videos of their playthrus and share them or annotate photo albums of their progress, basically writing visual and narrative stories of their game experience. And then share them. The key is to allow conversation at all levels. A simple brag board or high score list is okay but a place where players can comment on what has actually happened is going to build and retain your audience more effectively.
As a bit of a digression, but still very important to the concept of game flow, I want to touch on a feature I do not think is considered often enough. The loading screen.
Certain games requires loading screens to cover the transition between one area to another or when a save game is loaded. Generally the more complex a game (such as a role playing game) the longer the load screen takes to complete.
Generally loading screens are seen by many as a bad thing because if they are long they take the player out of the game. This is true. But when they are inevitable, they should be leveraged in such a way that they become an advantage.
Making the Most of Load Screens
Sins of a Solar Empire, a space strategy game, has very long load times when reloading a savegame (other than this I find it to be a responsive and fun space warfare game).
To minimize the annoyance of the long load the screen displays text describing how to improve gameplay... I like these load tips and think they are effective at taking advantage of the load screen. But there are a couple flaws to this (and most load screen systems).
The first flaw is that the information presented on the load screen should be available elsewhere. It should not be assumed that the player is reading and memorizing these details — they might be talking to a friend during the load, for example or otherwise distracted.
The second flaw is that in this particular game the load screen, once completed, sends the player directly into the game. But unfortunately the incredible length of time it takes to load the game manifests another kind of player action I do not think the designers predicted. An action dictated very much by human behavior. A long load time is the equivalent of a commercial break. Which means it is time to pee.
Because the game does not pause at the end of the load the player might find that their solar empire has been overrun by pirates while they were taking care of business. Which means they have to load their game again!
A long load is an invitation for the player to wander away. If the long load exists, the designer needs to understand that and should ensure that the player is in a safe state when the game finishes the load. That means that a cinematic should not play nor should the player be thrown into battle. If possible, pause the game after a load screen. Especially a long one... because your players might not be there anymore.
And think about where other minor annoyances happen throughout your game. Can you deliver something interesting, informative or pleasurable during what is traditionally seen as an annoyance? If so you have improved your game.
In the next newsletter, we will look at designing the right kind of user frustration into your experience. Thanks for reading, please let me know if you have any feedback!