GDC Day Four and Five

April 7th, 2018

Wrapping up my GDC notes with the final two days. It was an incredibly fun and intense week with my brain overflowing with knowledge and inspiration.

Over the last two days I managed to go along to a wide range of talks covering areas such as design, to audio, to VR. I also had the chance to have a proper walk around the expo floor, though I didn't have the guts to ride the mechanical llama.

Ben started the talk out with a definition of error, which is “things going wrong that you don’t want to go wrong”. In game design, we want some errors to be removed, but sometimes we want failure to happen.

He then introduced the ‘Skill, Rule, Knowledge’ model. We usually function at the Skill level where our responses are fast and automatic, however if something goes against this automatic processing we then move on to apply rules. If the rules don’t work we then apply logic, reasoning and rational thought. As we move from Skill down to Knowledge, it requires more time and effort to process. Errors can occur at each of these levels for different reasons.

Skill level relies on muscle memory where the player doesn’t need to think, but errors occur through inattention (where not enough attention is paid), or overattention (trying to apply effort). Rule level errors occur when a good rule is misapplied to a situation, or doesn’t cover the current situation, or a bad rule is applied. Knowledge level rules are a result of workspace limitations. Ben covered various types of errors and provided tips for how to avoid and use them.

To finish the talk, Ben discussed the ‘System (or Holistic) View’ of errors. Rather than looking at individuals to blame, look at the system instead. When approaching usability issues, phrase them as positive or negative systems which resulted in certain outcomes, and not “the player was confused.”

This was an awesome talk that I walked out of feeling way smarter. I’d recommend checking out the free slides to fill in the gaps which includes descriptions of types of errors and how they can be avoided and used in design.

‘Night in the Woods’ is a story about a time and a place, and in Em’s talk she discussed how audio can help make the player feel like part of the world.

Everything is alive in NITW and this is conveyed through audio. Sound originates from both known and unknown sources. The environment also responds to the player, something Em achieved by adding probability chances that certain sounds would play. This creates a feeling of randomness as well as intimacy. Characters too react to the sound as we hear it. The idea of this ambient sound telling the story all help build the feeling that you are Mae inhabiting the story.

Sound and music work together too. Em matched the ambient sounds in certain scenes to the BPM of the music. When Mae visits Gregg at Snack Falcon, diegetic music is used to give a different vibe. Similarly, the absence of music in certain scenes helps heighten the emotion and make it more dramatic.

Em also touched on the absence of voice over in the game. The decision was made as it would have gotten in the way of people being able to really inhabit the characters. Where there were scenes with multiple characters such as the party, sounds were used for background characters to make the scenes feel alive.

Lots of the sounds in the game were designed for the subconscious. Sounds were reused for certain characters to give a consistent feeling. For the “ghost,” this sound gets louder as you approach it. Other sounds fade to create tension. All of this was done to provoke people into listening by making them feel things.

To end the talk, Em encouraged the audience to be weird. Sharkle is an example of a silly thing added to the game and someone recorded a 10-hour video of him. If you find something funny, others might too.

When approaching ‘Rick and Morty’, Owlchemy Labs already had a VR framework they had built for ‘Job Simulator’. However, new features and requirements meant a major refactor was needed.

One new feature was locomotion. The developers are not fans of artificial locomotion as it is not comfortable for players. Instead they created a ‘teleportation tech’ to get from one area to another. However, they found people would stop moving which can cause fatigue, and would also attempt to teleport anywhere. To solve this, they came up with zone based teleportation. Players look at the zone they want to teleport to and hit a button. This was easy to do for players, encouraged movement, and fits the fiction of ‘Rick and Morty’.

Another feature was Portals, something iconic from the TV show that would also be awesome in VR. The Rick and Morty IP guidelines state that portals have to be shot onto flat surfaces. To avoid players doing this at the edge of the place and walking into something, the player has to deploy a mechanical wall into the space and then create the portal. When entering and exiting the portal the game discretely repositions itself which prevents collision.

You die a lot in ‘Rick and Morty’ but death in VR is challenging. If not done correctly it feels punishing and creates a loss of control. To get around this, the team created an instant cut into a brand new ‘Death Space’ world when the player died. This meant the experience was not jarring, and the player had immediate feedback as to what happened. The player could also choose when to return to the game, providing control over the pace.

Another new addition to the game were fully rigged characters. To increase immersion, the head and eyes of Rick and Morty track the player in the scene, and the game makes use of dynamic point. During playtests the team found that 50% of players slapped Rick or Morty. Initially, nothing happened which was disappointing, so the team added dynamic colliders so the player would get a reaction.

There was a load more interesting and hilarious tidbits from the session that I didn’t capture, but at the end Alex and Devin shared some of the weird and wonderful bugs they encountered which alone should encourage you to watch the talk.

When creating ‘Horizon Zero Dawn’, Guerilla had some lofty goals. They wanted to create a majestic wilderness filled with awe-inspiring machines and exotic tribes, all the while building an open-world – something they had never done before. With one year left before launch they had their first big playtest and, as Eric puts it, the feedback was brutal.

To understand what happened, Eric talked through development of the game. The project started with a concepting phase lasting 2.5 years with a small multidisciplinary team of 8-16 people. The goal was to answer high level concepts around areas such as combat against machines, what open world meant, and the abilities the player would have. It was great because they had a playable build quickly, but it was very costly.

The prototypes built were interesting but didn’t feel cohesive. To resolve this, a narrative team was formed to provide context to the game. Eric states that context helps everything you do, but cautions against worrying about this too early as it can prevent cool ideas.

Eric talked about some of the challenges they faced during production. One of the first things they worked on was the tutorial, but over time gameplay weight shifted and the tutorials they created didn’t cover the right information anymore. Toward the end of production, they also found that meta-issues began to show as the team hadn’t been able to play the game as a whole. The economy was a big example of this as the system had grown to be too complex – something that made it into the final game due to time constraints.

In the end, the team were able to resolve some, but not all, of the issues they discovered, but the game released to a great reception. Eric concluded by highlighting their key learnings: always review your goals, be honest with what works and what doesn’t, and adapt if necessary.

Ubisoft know how to launch a game. Prior to releasing ‘For Honor’ there had been several public tests, with the last open beta before launch being played by 6.5 million players. Before shipping, the team had worked hard to build a community through events such as E3 as well as open tests. The team always wanted a playable build that could be shared and tested with each period validating various objectives. There were minor issues, but these all seemed manageable.

At launch the game received decent reviews, but there were problems with balancing and stability. In less than a month sales had declined, there was a lot of bad press, and the community was threatening a blackout. Players who had fun testing the game before launch were now paying customers with different and higher expectations.

One of the biggest challenges was fight balancing. The game offers both 1v1 and 4v4 modes, so to balance characters across all modes requires lots of data, both from telemetry and community feedback. But even when the team had changes they wanted to make, it could take up to 3 months to patch a fix. As a result, the team developed tools to make patching quicker, reducing the turnaround time to a week.

After launch, the team quickly realized that live production velocity was not the same. There were constant interruptions to work due to emergencies, frequent milestones, branching, and a high QA dependency. This meant that deadlines would often become unrealistic. A decision was made to stop announcing public deadlines to protect and preserve the team.

Communication and transparency became key. For players, you’re only doing what you say you’re doing. They needed to show progress early and often. The team started a weekly live stream to acknowledge problems, explain strategy and share priorities. Public tests were used to show early progress.

Part of being Games as a Service means the game has to be sustainable. Revenue was generated through people purchasing the game and DLC, as well as in-game purchases. Everything that was built delivered value because the team had a philosophy of building on cool things that added value to the player. New maps and events are all free for players. The monetized Season Pass provides early access but all content can be unlocked through play. This ensured there were no paywalls and no split in the player base.

To close their talk, Damien and Roman spoke about how they have built a routine into live. Their job has shifted from building a platform to entertaining the community. They achieve this through daily, weekly and seasonal events, as well as surprises such as a Halloween event that was both fun for the players and the team who worked on it.

The final talk I attended was given by Studio Gobo’s own Peter Buchardt. Peter wanted to discuss design tests, a topic he felt no one is really shining light on. Within modern recruitment for big companies, design tests function as a filter and creates a foundation to compare candidates one-to-one. It’s a cheap and easy way to make a decision, but the process often forgets the people applying.

Over his 10-year career, Peter has taken a number of design tests for big name studios across a range of roles within design including level design, mission design and RPG design. The tests have ranged in both the work expected, and how explicit the instructions are. During the session he shared some of these real-world examples as a way to demonstrate what could be expected.

In terms of responding to these tests, this will often come down to the challenge posed. In general, for game design expect to include diagrams, text and images. For more technical roles such as system design, code examples may be expected. Level design may include paper designs or 3D blockouts. In all cases, you should communicate your solution and how you got there. At the same time however, you also want to make sure you’re not going too low level that you bore the reader.

One thing Peter highlighted is that each company will have a specific format in mind. In his experience, some tests made it clear what deliverables were expected and how much work he should put in. Others were ambiguous or vague. When it came to receiving feedback, this too differed from company to company. Sometimes he would receive feedback straight away, other times he would have to chase people to find out why the company didn’t move ahead with his application.

Peter concluded by saying that design tests come in many shapes and formats, some with explicit instructions while others may be more freeform. As a designer, you need to be agile and adjust to the requirements. Make sure you read and understand the task fully before starting, and don’t forget to get a second opinion from friends or peers. Finally, express yourself in the response as it’s a good way to show what kind of designer you are.