The second book about game dev I’ve read this year is Practical Game Design by Adam Kramarzewski and Ennio De Nucci. This book touches numerous important topics from ideation to LiveOps. This time, I’ll try not to write a whole six posts about the book. The book has fifteen chapters and I’m going to condense them into 7 bullet points. This post contains the second three points.

---

Book Summary: Practical Game Design

1. Intro to Game Production Process, Creating Concept, and Gameplay
2. Story, Interaction with the User, and the Last 90% of Game Design: Play-testing, Balancing and Polishing
3. Creating a Live Game or Game as a Service

---

4. Story: Narrative and Characters Design

Some games have been popular because they are not employing a traditional in-game story. Some others go all in and offer a cinematic experience. In chapter 8, Games and Stories, the writer incites a discussion by asking if all games have a narrative. Referring to the Story Machine concept in The Art of Game Design by Jesse Schell; good games generate stories regardless of if it is in-game or not. Good stories create an emotional attachment within the players. So we have to ensure the story within the game is good. The direct way to ensure the game has a good story is to design it. The writer introduces the traditional narrative models to help aspiring narrative designers to start:

• the three-act story, and
• the monomyths of the hero’s journey.

After reviewing the existing narrative models, the writer describes the game narrative structures that are often encountered. The narrative structures are crucial because the games with in-game story usually structured around the narration. The in-game narrative structure should be established as early as the game scoping phase that has been laid out in chapter 3.

In chapter 10, Characters, the writer invites the game designer to populate the game world with characters. First, the writer briefly describes:

• the playable character,
• non-playable characters, and
• enemies.

The common functions of the characters are also referred, such as:

• the friend, the lover, the mentor, the boss, the main antagonist, the allies, the hostages, the vendor, the quest giver, and the competitors.

Then, the writer describes the steps to design a character:

• Step one is to have a deep understanding of the game. The designer then uses this knowledge to work out the design pillars. The designer can also find the pillars in the design documentation. The design output should adhere to these pillars.
• The next step is to create a general concept similar to the game concept in chapter 2.
• Then, the designer adds stats to the character. These stats are to be balanced with the existing game system. The writer elaborates more about balancing in chapter 13.
• After that, the character is ready to be prototyped and tested. This prototyping-testing step is iterated to achieve the required level of quality. Although even after all that, the final version might need minor tweaking in special cases after release.

5. Interaction with the User: User Interface, Tutorials, and Localisation

While most teams have a member who specializes in UI/UX, the game designer still needs to know how the player input and the game’s feedback affect the overall experience:

• Input can make or break a game; that’s why mainstream con-soles have strict guidelines on how their controllers should work. In chapter 11, User Interface and User Experience, the writer explains the importance of following a standard and getting input right. Then, the writer lists control types such as digital input, analogue input, and touch screen controls.
• Camera types and viewing perspectives are also described to inform the reader as to how the camera movement can influence the experience.
• The game should give feedbacks every time something happened. Feedbacks can come from UI, physics, VFX, character/object animations, full-screen effects, tactile feedback, audio, and text.

After laying out the things that can have an effect on the experience, the writer proceeds to provide a step by step guide to designing UI. The writer also gives out UI tips and tricks in this chapter.

6. The Last 90%: Play-testing, Balancing, and Polishing

Play-testing is also explained in chapter 12, Accessibility, after the sub-chapter about localisation. The writer guides the designer by asking the following questions:

• What to play-test
• Who the testers are
• How the play-test is carried out and how the feedback is garnered

To help the designer get started, the writer refers to an example of what to test and who the testers are in relation to a sample production phase. Some of the examples are:

• Controls and game mechanics are tested in pre-production by internal testers.
• Art direction and brand test are done with a small ad campaign to the target audience in the first production milestone.
• The first 30-mins gameplay test is done to check the initial appeal of the brand and the game by an external tester on the target audience in the next production milestone.
• Multiplayer and singleplayer content are tested internally in the last production milestone.
• In the closed alpha phase, a version of the game is tested by the press and influential players.
• In the open beta phase, the game is tested publicly for promotion and to stress test the networking system.
• After release, a special test server is clearly marked and opened to the public to test new and updated content before being released to all server.

In the next sub-chapters, the writer gives details about play-testing session types, the pros and cons of different ways to get testers, and how to run the test sessions itself. There are also important tips on questionnaire design such as length, getting a player profile, and tracking fill-rate.

In non-puzzle games, designing multiple strategies for the player to discover is essential. In chapter 13, Balancing, the writer proposes some balancing approaches such as MBT (main battle tank) balancing and grouping stats into separate layers and dealing with them by layer.

One way to accommodate different skill levels of the players is by providing difficulty settings. The most straightforward way to make the difficulty settings is adding a stats multiplier. But this strategy may result in odd behaviours that are caused by the multiplier messing up with the already balanced system. Another way to implement difficulty levels is to modify the game mechanics itself. In this chapter, the writer mentions some practices such as making player assisting features toggleable, modifying enemy AI, and changing failure results.

Game pacing design is also explained in this chapter. The game designer should keep the player off the boredom zone and the frustration zone as the game progresses. Maintaining pace can be done with content or mechanics that are revealed within a narrative-like structure. In the sub-chapters about pacing, the writer uses many examples in the existing games to illustrate the tips and tricks of keeping the player in the flow zone.

In chapter 14 titled The Final 10%, the writer emphasizes that oftentimes the testing, balancing, and polishing parts of the game production are vastly underestimated in both time and budget plan. That’s why I like to refer to them as the final 90%. Although organizing the production timeline and resources is the project manager’s job, the game designer should know that there are some tasks to do in the final 10% of production. Suddenly adding large features is not one of them. The game designers, directors, and QA should experience the whole game to know which part of the game that needs to be polished. Usually, they are stability and performance, audio and visual and mechanics balancing. Stability and performance are mostly the responsibility of the engineers, but the game designer should consider the limitation of the hardware where the game will run. The game designer should maintain a good relationship with QA team as they are some of the people who have played the game intensively so they might have some valuable insight to share.

At the end of the chapter, the writer gives excellent tips to close a project quickly. For instance, aligning everything with the game concept, sticking to the plan, iterating and testing early, accepting failure and some imperfection, and releasing as soon as possible.

---

The next post will be about the way some companies keep a steady income from an IP, that is creating a game as a live service.