Bernard Hwang

Level Designer

Systems Design

Dev Blog - MechDog - The Shop

Solo Project, DevBlogBernard HwangComment

The shop system was iterated so that a few of the game systems were better aligned with the game's main aesthetic. 

Everything you see in this post is work in progress.

Previous Shop Implementation

Recap

The previous shop system created this loop:

In the previous version of MechDog, upgrades were only available on the main menu and not in game. All upgrades purchased were applied permanently to the player's character for all future runs.

Analysis

The upgrade system provided a set of long term goals; it gives players something to strive towards in-between runs. A con of the permanent upgrade system was that it made the leaderboard an unreliable tracker of player skill. Player scores were being augmented by the amount of upgrades in the player's possession. The player's focus was split during a run between, collecting currency for the next upgrade and getting a good score for the current run; two goals that are orthogonally opposed.

Reconstructing the Pattern

This shop pattern is created from the combination of these components:

  • Permanent Currency System
  • Permanent Upgrade System
  • Player abilities
  • Score System

The score system is the "end-game component", the component that is being supported by the rest of the components in this system. In the context of the shop pattern, the currency system supports the upgrade system, and the upgrade system which improves player abilities supports the score system.

Knowing the problem that we want to solve and how the related components work with each other helps us better aim our iterations.

Iterating on the Shop

  1. The initial iteration was to move the upgrade system into the game run. The shop menu would only appear after the player completed a dungeon, and any purchased upgrades would only affect the player during the current run. The currency used in the shop was still persistent between game runs, so the problem of mixed player goals still existed.
  2. The next iteration changed the currency system so that it would only persist in one game run as well. This removed the long-term goals in the game, but doesn't create conflicting goals between score and currency.

Result

The new shop loop is all self-contained in a single game run. On any run, players start out on an even playing field, giving no one a score advantage from the start. The end run score the player receives is achieved purely through player skill rather than a player's playtime. The new shop loop aligns the goals of getting a better score and getting upgrades since they both only take place in the same instance.

Design

Why prioritize score over upgrades?

I wanted the social aspect of MechDog to be more profound. That's why the game includes Google Play leaderboards. The initial playtest group I had for MechDog made the game into a competitive experience, and I didn't want to subtract from that experience with systems that undermined the score aspect of the game.

What does having a shop add to the game?

The shop adds an intermediate goal in the game. Completing a moment-to-moment segment tests the player's platforming skill. Going through multiple moment-to-moment segments tests the player's ability to collect coins for the upcoming shop screen.

Dev Blog - MechDog - Dungeon Meter

DevBlog, Solo ProjectBernard HwangComment

A new system was designed to add interactivity during level generation.

Everything you see in this post is work in progress.

Previous Level Generation

Recap

I go into detail about the previous level generation method in this previous dev blog. But here is the quick recap: 

The previous generator created level sequences based on designer input. The input determined the order in which level segment types would appear. Segments of challenge and reward were interspersed to try and create a good flowing experience.

Analysis

The components that made up the generator were these:

  • Procedural generator (system rules)
  • Level types (content for the system)
  • Sequence code (designer input)

The component that the generator didn't utilize was "player action". The generator created levels independent of how the player was doing. Two players of different skills received similar experiences from the level generator.

The Dungeon Meter

The question was then raised: How can the level generator create different experiences for players of different skill levels?

The player's actions needed to be factor into level generation. The two actions that helped indicate player skill were collecting coins and destroying enemies. The latter was chosen as it was the more challenging action of the two.

Now I needed a way to affect the level generator. Fortunately, the level generator already sorted level segments by difficulty. I created a meter that charted enemy kills and that needed to be filled before producing more challenging level segments (dungeons). 

Result

With the game's minimalist approach to controls, player actions needed to have high feelings of agency. The meter served the purpose of providing intermediate feedback for the player's actions. The feedback was longer term than an immediate points reward, but more frequent than the end-game score screen.

Design

Why make the level generator responsive to the player?

When a person plays a game, a relationship is formed. The player inputs actions -> the game outputs feedback -> the player interprets those actions and inputs more actions. When more game components are able to respond to the player's inputs, the game feels like a better experience. I realized that the procedural level generator was a perfect target for injecting a little more life into.

Was this an easy change to implement?

The level generator was already broken up into exposed components which allowed me to quickly iterate and find solutions. The system was initially designed like this to test specific level segments without having to play to that point. Because these components were already exposed, it was relatively easy so create another system that utilized the exposed components.

Designer Interview: Liz England

InterviewBernard HwangComment

Liz England is a Game Designer at Insomniac Games. She currently specializes in Systems Design: analyzing, figuring out, and designing game-wide systems. She has worked on big franchise titles such as Saints Row 2, Scribblenauts and Resistance 3. In her free-time she works on Indie games and is responsible for some popular Ludum Dare games. Her current design efforts are being used to create Insomniac's first next-gen title, Sunset Overdrive.

In this interview, Liz shares how she got to where she is now, her thoughts on Game Design, and helpful tips for Game Design students.

What type of education/career preparation did you have? 

I started out with a degree in English literature, and followed it with SMU’s Master’s program in Interactive Technology, a fairly hands-on game development program not all that different from Digipen. Before SMU, my only experiences were various modding tools (Neverwinter Nights, strategy games like Starcraft and Heroes of Might and Magic), with a couple college-level programming and art courses.

What elements of your education were most useful when you started your career?

The list is unending for this, really. Education gave me a pretty good – although relatively shallow/simple – grasp of the elements of game design, proper level design, a variety of technical skills needed as a designer, and lots of practice in implementation. The industry is where I actually learned what good design was, and how to think critically about spaces, systems, and the player’s experience.

Specific skills I learned that helped the most (in no particular order): experience with lots of different level design tools (2D editors, Hammer/Source, Quake, Oblivion’s Creation Kit, Unreal, Maya) meant learning custom in-house tools is much faster, making levels in 3D editors for FPS games jumpstarted most of my knowledge about how to design spaces for players and what good pacing feels like, and working in student teams taught me how much work goes into what looks like a small game (and all about scope and time limits).

Generally, as a systems designer, the skills that I find invaluable are the ability to organize large amounts of information, and look at how systems affects various elements of the game from a sort of bird’s eye view. I can’t point to any part of my education for this, though.

What do you wish you had known when you started your first job in the industry?

I don’t have a good answer for this one – I certainly learned a ton while in the industry, but very little that would have changed my decisions early on.

How and why did you progress from one role to another?

My role has always been a designer, but I've moved around between level design and systems design until settling on the latter. Most designers at Insomniac have a couple levels or missions they are responsible for, plus some other area of the game (i.e. combat design, boss design, xp/leveling, intel, weapon design, tutorials). I made the move away from level design by just volunteering at work to take over systems that were orphaned until eventually my role (on Sunset Overdrive) transitioned into only systems.

What do you enjoy about doing systems design on project? What do miss about doing level design on a project?

I am one of those people who could spend all day every day organizing data in excel, so an opportunity to do that at work is very rewarding to me (though probably not that appealing to many others). One of the nice side effects of systems design is that I have a some knowledge about every bit of the game (all the pieces that cross paths with a system), rather than a ton of knowledge about a very small slice (a level).

The trade off is that there are definitely days (weeks, even) where it feels like nothing I make ends up in the game. When making a level, I could point to it in the finished product and say "This is mine!" It's a lot harder to have that sense of ownership over a concrete part of the game now.

Having worked at multiple studios, do you find yourself cross-pollinating practices you've learned from each studio?

There's always new things you pick up wherever you are - at 5TH Cell I spent a lot of time in Excel, and have brought over those skills to Insomniac, and have picked up a lot of new skills from our workflow here as well as tricks various designers have brought with them. I work with many people from many different studios between them, so it's common when confronted with a new problem to ask something like, "Well, how did Valve do that?" or "How does Blizzard do it?". I don't mean this in a technical sense (those would fall under NDAs) but rather in ways we improve our process (how are departments organized, whether certain tasks fall under the design or the art department, how to iterate quickly or improve our internal tools, what free or paid tools they use to help with their workflow, etc.).

What are some communications-related requirements and challenges you face on a daily work day?

Oh boy, this is a hard question to answer – I think communication challenges are the hardest to solve, but they exist on every game. I have to communicate with a lot of departments, including about stuff I really don’t know much about. I've learned (and keep learning) good ways to communicate a design clearly that doesn't leave others – programmers, FX artists, sound designers, artists – confused. Another big problem I run into is making sure that when a change or new decision is made, everyone it affects learns about it. When these are big scale changes it’s not too hard to make sure it’s communicated across the team. With little changes, though, it can be challenging to track down all the different details it affects (especially with systems, where small changes can make big waves).

How do you tell if a design change requires you to communicate with the rest of the team? Do you ever make private design iterations?

It's pretty easy to tell: with large games, most changes have ripple effects on other departments because as a designer you can't do everything yourself, but rather rely a lot on others to help you finish things. Anything that needs art, or audio, or FX, or UI, or programming support needs to be passed on to those departments. For example, changing a skill in a skill tree requires programming support to create the functionality, FX support to illustrate the new skill, and often UI support to communicate to the player what is going on. However, the larger the game and the larger the team, the easier it is to run into situations where you tell one department about new dependencies, but overlook another.

Small changes done just by the designer are really common, but by that time the level is rather 'set in stone' - we know what the moment-to-moment gameplay is, it just needs to be iterated on and refined to bring it up to where we want it. Changes to that gameplay, such as changing the geometry or adding some new gameplay, are often prototyped by a designer to a playable form to prove out the fun before another department starts work on it (programming, art, audio).

What are some difficulties you face working on a new IP?

The hardest thing is that there is no game you can honestly compare it to, assuming you aren't just making a clone but rather a game with its own identity. In sequels, you already have a game that sets a bar for gameplay, story, tone, art style, and what players should expect. New IPs have to figure all that out from scratch. Often we run into new questions or problems that many games have solved in many different ways, and we have to filter through WHICH solution is the RIGHT one for THIS game. If those decisions aren't made right, you can end up with something that's too much like a game that already exists, or something that takes from too many different games and doesn't feel internally consistent.

What is the best advice you can give to a design student, even if it's not necessarily the most traditional advice?

One bit of traditional advice is that when you’re a student, you can afford to fail. When you’re a professional, you can’t. So don’t be afraid to take risks.

I agree with that but… I think a more important – and less practiced – piece of advice is that if you should learn the rules before you break the rules. A lot of students try to invent something new and get overwhelmed and caught up in too many unanswered questions and untried (to them) territory. On the other hand, instead of designing your own game from scratch, I highly recommend students try to imitate professional designers as close as they can at first. That would mean making a level for a well-known game like Portal 2, with solid level design, puzzle design, attention to good gameplay and pacing, and relatively bug-free implementation. Doing this means you already have a target in terms of style and quality (the original game) and examples to look at when you run into problems or questions. This is the sort of work people learning any industry do in order to get good in their craft.

 

You can follow Liz England @lizardengland and visit her site here.