Kai Zheng (@devilpie) header
Kai Zheng (@devilpie) profile picture

Game dev with 18+ yrs experience at PlayStation, Xbox, EA and more. Perfect Dark, God of War, Dead Space, Battlefield, Dante's Inferno.

California, USA
Joined September 2007
#gamedesign Lessons Learned #18 Invisible walls suck Players don’t hate a world with boundaries. They hate the broken promises. If the game teaches the player a set of rules (jump height, climbable surfaces) then silently break them with occasional invisible walls, we lose their trust. Here are some tips for avoiding such failures, especially in games where the player can jump: 1. Lock your level-design metrics and visual language early. If a 2-meter fence is climbable in the tutorial, every unclimbable fence should be at least 4m or have barbed wire on top. 2. Use naturally occurring terrain whenever possible. Sheer cliffs, canyons, deep water, and floating islands communicate the boundary through geometry itself. The Legend of Zelda: Breath of the Wild and Elden Ring lean on this constantly. 3. When natural barriers aren’t feasible, prefer a justified kill zone over a silent collision wall. Helldivers 2 is a clean example. Step outside the mission area and Super Earth brands you a traitor, then rains orbital strikes until you die. 4. Never place invisible walls inside non-linear spaces. Calibrate the philosophy instead: reward curiosity with optional content instead of funneling everyone onto the same critical path with hard stops. #GameDev #LevelDesign
🤖 Made with AI
2
150
#gamedesign Lessons Learned #17 Clarity is the foundation for fun Ever read Scott McCloud’s Making Comics? He famously broke down how creators achieve visual clarity using 5 Choice pillars: Moment, Frame, Image, Word, and Flow. It’s a great framework for clarity in communication, which is critical for keeping the readers engaged. As game designers, we face a similar challenge but in a different medium. When we get clarity wrong, players get lost, frustrated, and lose their immersion. That got me thinking. How can I translate McCloud’s clarity framework into video game level design? Here's my attempt: 1. Clarity in Agency I always start the design of a space by asking "What are the required and optional things the player can do here?". Use the answer to inform other design decisions. And make sure the player intuitively knows the answer as well. 2. Clarity in Sightline Design geometry to orient players, frame goals, and minimize visual noise. Be deliberate about what to show and hide at each step on the way in order to maintain clarity and focus. 3. Clarity in Affordance Make useful things instantly readable. Players should know exactly what is cover, what is hazard, and where they can climb, in a split second. 4. Clarity in Context Provide diegetic cues to guide, inform, teach and immerse the players. They are great tools for adding narrative and gameplay context in a seamless manner. 5. Clarity in Flow Combine intuitive 3D navigation and careful event pacing to create a flow through space and time. This is the most critical craft for level designers. It's also where games and comics can learn a lot from each other. Check out the full breakdown in the image below. #GameDev #LevelDesign
🤖 Made with AI
1
97
#gamedesign Lessons Learned #16: Break the Rules to Create Special Moments Most of the time, designers must establish and follow consistent rules of the game. However, the moments players remember years later are often the ones where a designer deliberately shatter a rule players thought they understood. Done right, it’s a powerful tool for delight, and emotional impact. The Last of Us Part II: workbenches are safe the entire game. Until one isn’t. Tears of the Kingdom: every boss health bar works the same way. Until Ganondorf’s keeps growing past the screen. That's the recipe: Establish the rule. Let players internalize it. Then break it at the exact moment it will hit hardest. What is your favorite rule-breaking moments in a game (that's actually good design)? Please share in the comments. #gamedevelopment #gamedev
109
#gamedesign Lessons Learned #15 Treat source material as the creative spark, not the wrapper. It's tempting to rely on the surface-level elements of the source material (e.g., copying the visual style, general settings, or character designs). But the adaptation only becomes its own experience when the developer dig deeper to identify themes and details that can inform the gameplay mechanics, level design, and narrative. Here's an example from my own experience working on the "Magic Chisel" level in God of War (2018). While studying Norse mythology, the team was reading the Prose Edda. One story is a giant stonemason deceived by the gods and killed by Thor. Instead of retelling the exact story, we took his fate, his scale, and his tools to create our lore: he is killed by Thor using his own chisel, driven through the skull. The airport-sized corpse becomes the playable space. Retrieving a shard of that chisel, now under the frozen lake where he fell, is the objective. While that setup was a great starting point, the level design team still had a big challenge on our hands: a typical GoW level would ask Kratos to fight giants and gods, but the stonemason was already dead and must stay dead for now. (We reanimate him for the final boss fight much later in the game). In order to avoid the "superficial adaptation" trap, we did a few things to make sure the giant corpse was not just a static non-interactive backdrop, but a fully integrated part of the experience: • Embed stonemason into gameplay and narrative: his gigantic hammer, dreadlocks, and rings were mapped onto our gameplay pillars: navigation, combat, and puzzles. During those moments, Kratos and his companions naturally deliver lore-packed conversations about the dead giant. • Milk existing mechanics for new experiences: we combined existing gameplay mechanics (shatter crystal, runic puzzles, circular crank, wall climb) and used them in various novel context to simulate a bespoke set-piece without the bespoke cost. • Fulfill the Player Fantasy: using set pieces such as Kratos scaling the giant's hammer and dropping it to shatter the entire frozen lake. we delivered the god-like spectacle players demanded while respecting the source material and budget limitations. What are some of your favorite examples of IP adaptations that have failed or succeeded? Please share in the comments! #gamedevelopment #gamedev
1
3
149
#gamedesign Lessons Learned #14: Avoid becoming a narrow specialist at all costs. Large companies often hire specialists for specific projects, but the multi-disciplinary nature of game development calls for generalists. The people I trust most are T-shaped: deep in one discipline, yet fluent in adjacent areas to be versatile and collaborative. Why this matters: • You can test the full idea before you sell it. As a designer, adjacent skills let you prototype the full player experience, not just describing the promise. That is not a solo-dev quirk. It is how your design intent survives director reviews and department handoffs. • You spot constraints earlier. A designer who has never managed memory budget may later find out that their epic set piece won't load on consoles. A designer who has never scripted NPC behavior may have to redesign a combat encounter after realizing the enemy can't handle dynamic navmesh blockers. Adjacent literacy is how the hidden constraints gets revealed before they become redesigns. • Your teammates trust you more. A designer who can speak the language of art, animation, and programming will be able to communicate their intent more clearly, and understand the constraints of those disciplines. That builds trust and respect among teammates, which is invaluable in a collaborative environment. • You become harder to replace. Narrow pipeline roles are the first to freeze when a project pivots or a studio cuts. Breadth is career insurance, not a hobby. And that's especially true in the context of industry-wide shifts and AI taking away jobs. What adjacent skill changed how you design? Please share. #gamedevelopment #gamedev
1
1
206
#gamedesign Lessons Learned #12: Game narrative is more than dialogue and cinematics. Those two sit at the tip of the iceberg. But anything can carry story if we design it with narrative intent. I often use such a "Narrative Iceberg" framework to remind myself about exploring the full narrative potential of gameplay spaces. These are the narrative devices I keep in my toolbox: • Player objectives. Give them motivation and consequences, or they become generic fetch quests. • Player actions. They should mean something in the fiction. Never jump to actions without designing the context. • NPC barks and banter. Cost-efficient and non-intrusive. Build them with your writers, not after the fact. • Interactive objects. e.g., Loot, notes, recordings, traps. They imply people who were here and events happened. • Non-interactive environment. e.g., Bloody drag marks at an air vent. Let curiosity and imagination do the work. • Ongoing events. e.g., A gathering, an ambient battle, a blackout. The world has a life of its own. To raise the impact of those devices, I also rely on these emotion amplifiers: • Lighting and VFX • Music and SFX • Architecture and landscape • Weather and time of day Which narrative device is your personal favorite? Please share! #gamedevelopment #gamedev
1
2
121
#gamedesign Lessons Learned #11: Pacing must be planned across multiple layers. This applies at both the macro scale (singleplayer campaign, multiplayer session) and the micro scale (encounter, level, mission). Planning it early is far more reliable than winging it. And the larger the team, the more that matters. Unlike movies or novels, game pacing does not live on one track. I like to focus on these 3 layers: gameplay, narrative, and environment. Gameplay pacing frameworks such as Kishōtenketsu (covered in Lesson #6) and Metroidvania gating never go out of tyle. They help us develop a plan to unlock, develop and mix the gameplay ingredients without implementing fully playable content. Narrative pacing is the evolution of character, conflict, and plot. Macro frameworks like the Three Act & Kishōtenketsu, and micro tropes like cliffhangers & plot twists are good starting points. But the interactive nature of games requires us to find our own balance between creative control and player agency. Environmental pacing is the art of crafting spaces with clear creative intent. Expansive or claustrophobic, linear or nonlinear, flat or vertical, dark or bright, calm or chaotic. Design a space that amplifies the beat and complements the gameplay and narrative. It's also important to coordinate those layers. A spike (too much landing at once) and a flatline (nothing interesting for too many seconds) are cheap to catch on a pacing sheet and expensive to fix after the content is built. Every project grows its own toolbox (walkthrough scripts, flowcharts, 2D maps, 3D flythroughs) and weights the layers differently depending on whether the game is narrative-driven or gameplay-driven. The team DNA is often reflected in how they plan. What tools or process do you use to plan pacing on your particular game? Please share in the comments! #gamedevelopment #gamedev
1
3
145
#gamedesign Lessons Learned #10: Be honest about who the game is for. Is it for Investors? Players? Yourself? There is no wrong answer. But you cannot optimize for all three. Restaurants already figured this out. A fast-food chain, a Michelin restaurant, and a home kitchen are all “food businesses.” They share almost nothing else: cost structure, staffing, target customer, what “success” even means. You cannot run all three with the same people. Games have the same problem now. The industry is no longer one business. Treating it as one is how good teams get assigned the wrong product. A few mappings I find useful: * Live service often works like a fast-food chain — high volume, seasonal menus, operations first. * A lot of mobile is snack food — cheap, quick to consume, built for everyone, but not for anyone in particular. * Premium AAA wants to be fine dining: guests with money and time, a kitchen that wants to be proud of the plate. * Many indie games are home cooking. You make it because you want to eat it. Everything else is secondary. None of those is clearly better. They just require different teams, different priorities, and different definitions of “good.” A pattern behind recent high-profile failures is a category error: first-party studios built for authored single-player games, then told to operate live-service multiplayer. That is asking a talented sushi kitchen to run a burger chain. Next time you start or join a new project, ask the unglamorous question out loud: who is this game actually for? Be honest. Because the right team for the right product is the only way to make a good game. #gamedevelopment #gamedev
1
1
148
#gamedesign Lessons Learned #9: Designing a modern open-world city without a real-world reference is rarely a good idea. Have you ever explored a video game street that felt slightly off — too wide, too clean, more theme park than a place where people live? That usually means the team never locked a real-world city reference or stopped following the reference. “Worldbuilding” is a misleading phrase for inexperienced teams. It makes a 100% original city sound like the ultimate creative flex. In practice, it is often the fastest way to drain time and budget. Most game artists and designers are not urban planners or civil engineers, which means there will be a steep learning curve and months of extra pre-production. The strongest open-world cities are often grounded in existing places. GTA V studies Los Angeles. Watch Dogs Legion studies London. Even Cyberpunk 2077 inherits Night City from Mike Pondsmith’s sourcebook. Those teams researched geography, culture, history, architecture, road design, traffic patterns and more, then reimagine the city based on their game's theme, style, gameplay, and scope. Often, that means  distilling the city down to its core elements, and using those elements to build a psychological caricature that feels truer to the human memory than a strictly accurate replica. There are, of course, exceptions to this rule. If a unique, fictional city is a key part of your narrative or gameplay, then it may be worth the time and budget to create a new city from scratch. But make sure you hire the right experts, and that you have a clear vision for the city’s geography, culture, and history before you start building. If you are interested in a deep dive into my process for translating a real-world city into a game-ready world, leave a like or comment. #gamedevelopment #gamedev
3
1
6
321
#gamedesign Lessons Learned #8: Shared context is the key to effective collaboration. Picture this: a new pod is assembled to prototype a boss fight. The animator insists on movement fluidity and realism, while the combat designer wants exaggerated, telegraphed animations for clarity. Without a shared context of the game's core pillar (e.g., "Is it a grounded, realistic game or a stylized, arcade-like game?"), the pod struggles to make a decision and ends up with a disjointed prototype. This is one of the most common challenges in game development. We often assume that everyone on the team has the same context, but that's rarely true. Each team member has their own perspective and knowledge, which can be a blessing or a curse. The most effective team members are those that actively work to surface and share context, and then use that context to help everyone make better decisions. So here's my advice: next time you encounter a disagreement, instead of asking "Who's right?", ask "What context are we missing?" and "Who has that context?". Then work together to fill in the gaps. #gamedevelopment #gamedev
4
177