Bernard Hwang

Level Designer

Dev blog - MechDog - Systems

Solo Project, DevBlogBernard HwangComment

MechDog has three systems associated with the core game.

Everything you see in this post is work in progress.

Systems

Currency

In the game the player can earn currency. These are the ways the player can receive currency:

  1. Points-Earning Actions
    The player can complete actions to give them points. A percentage of these points are converted into currency at the end of a run. The player can also find pick-ups during a run that increase the conversion rate to receive more currency.
  2. Currency Pick-Ups
    The player can find currency pick-ups that directly add to the player's currency at the end of the game. These pick-ups are not effected by conversion.

Upgrades

The player can use currency to purchase upgrades that enhance MechDog's abilities. The upgrades system categorizes upgrades by functionality (Jump, Slam, Token). The categories are tiered and require the player to invest into a category to unlock better upgrades.

Draining Health

On every run, the player has a gauge that counts down to the player's death. When the player hits an obstacle, a portion of the gauge will deplete immediately. The player can extend this life gauge by clearing obstacles and taking out enemies.

Design

Why have a Currency System?

A core design principle with this project was to pursue exciting moment-to-moment gameplay above all else. The currency system allows me to highlight specific actions with extrinsic motivation. The system gives me the tools to draw the player to certain actions.

Why have an Upgrades System?

The upgrade system was added after the addition of the currency system. They work in tandem to create a gameplay loop.

The player earns currency -> Spends the currency on Upgrades -> the upgrades help the player earn more currency.

Why have a Draining Health System?

Many endless runners share a one-hit death mechanic and a level generation system that ramps difficulty. The combination of these two work together to cause the player to increase their skill gradually. As the difficulty ramps up, the player faces new dangers that are likely to kill them. The one-hit death mechanic resets a player's progress, leading them to replay so that they can incrementally learn how to get better at the game. This method works if the goal is to stretch the amount of content and keep the player invested for a long period of time.

My goal with this project isn't to have a long running game service, so I decided to try a health system that allows for longer play. With draining health, the emphasis of the game becomes about being taking action rather than about trying to survive.

Dev Blog - MechDog - One

Solo Project, DevBlogBernard Hwang1 Comment

Overview

What is Mechdog?

MechDog is an Endless Runner project that is planned as my first Android release. You take control of MechDog, a dog in mechanical battle suit that races across the desert to escape his pursuers who you have stolen the mech suit from. 

Everything you see in this post is work in progress.

Abilities

MechDog's suit has three abilities:

  1. Jump
    The suit has the ability to launch itself into the air allowing the wearer to leap over hazards without losing speed. The suit can also land on enemies after a jump to destroy them.

  2. Thrust
    When in the air, the suit can use its ion thrusters built into the arms to keep the suit from losing altitude.

  3. Slam
    Also when in the air, the suit can reverse its arm thrusters to thrust itself down to avoid above-ground hazards and damage enemies directly below.

Prototyping Abilities

Design

Why for Mobile?

I wanted to develop an Android release to follow up my internship at Gameloft, a mobile games studio. I had created two experimental mobile games in my senior year at school in which I found tackling touch controls to be an interesting design challenge. Making a mobile game allows me to continue exploring this challenge.

Why an Endless runner?

The Endless Runner genre is a matches well with the constraints of touch controls. With forward movement being automated, the player can focus on executing other actions and abilities. This in theory allows me to design for more exciting moment-to-moment gameplay without worrying about overburdening the player with information.

How did I decide on the abilities?

This project got its start after I read a design article about how add more nuance to jump mechanics. Feeling inspired, I launched unity and messed around with a jump mechanic that had more force the longer your pressed the jump button. This is where the 'Thrust' mechanic evolved from; having more air control tested better within my small test group. Thrusting seemed like a good way to compensate for the lack of lateral control.

The 'Slam' mechanic was initially meant to just be a band-aid solution. After implementing a jump and some test enemies, there were instances where the player missed landing on enemies to take them out. I added a slam instead of tweaking player physics as a quick solution. Again this option appears to work because it gives more control to the player. In addition I assigned the slam to a swipe down gesture to exploit natural mappings with touch controls.

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.

Dev Blog - Mashball

DevBlogBernard HwangComment

Mashball is a multiplayer arena combat game that pits up to four contestants in to a deadly game of hot potato. From it's initial prototype, the game has had a list of feature implemented so far.

While the tech team gets the engine into a workable state, I've been responsible for creating a working version of the game in Unity.

Using Unity to build a precursor version of the game has allowed me to hit the ground running. I've been able to playtest, create levels, and iterate on mechanics far before the team's engine is ready.

As the tech team gets closer to reaching a point where the engine is in a state that allows for geo building and gameplay scripting, I expect to be tackling the difficulties of transferring mechanics from one engine to another.

Here is some footage from our latest playtest session.

Muffin Express Project 5 - Prototype 4

DevelopmentBernard HwangComment

This is a prototype created to help decide the direction for my Junior Team's next project. The only design prompt given by the team was to create a multiplayer arena game.

Mashball is an Arena Combat game. The contestants in th arena must hold onto the bomb as long as they can without having it blow up on them.

Coming out of Engine-proof milestone, this prototype was chosen to be the Team's next project. Over the coming months I will be posting dev blogs charting the iterative changes and progression of the game.