Bernard Hwang

Level Designer

Game Design

Dev Blog - AquaBlock - Puzzle Signifiers

DevBlog, Solo ProjectBernard HwangComment

This post is a continuation of the last dev blog and covers how signifiers are essential in puzzle games.

Everything you see in this post is work in progress.

What are Puzzle Signifiers?

Here are two terms that I'll be using in this article...

Signifiers: Perceivalbe indicators that communicate appropriate behaviors to the user. When signifers are correctly used, they create "feedforward".

Feedforward: Information that helps answer that question of "what do I want to accomplish".

The presence of both signifers and feedforward always guides the player into desired bevhaior.

Artboard 3-01.png

In a puzzle game, a series of puzzles ideally has a gradual learning curve. Each sequential puzzle ramps up in difficulty and add layers of knowledge. A single puzzle can be designed similarly to follow the same structure. Signifiers can be used to provide direction and validation in the middle of a puzzle to provide stepping stones for the player.

Puzzle Signifiers in AquaBlock

AquaBlock uses signifiers in multiple ways that range in scope.

Corner Pieces

In the first puzzle world of AquaBlock, special colored blocks are used to indicate that they belong in one of the eight corners of the cube. This puzzle constraint creates guidelines for the player in the beginning world to get the player used to how game’s puzzles are solved.

World Block

When the player is selecting which puzzle world to select, they get to see the type of block that world is themed around. The block itself is an indication of what its effect is, and the player can expect to see its use in the puzzles contained in that specific world.

Puzzle Names

There is a name that appears before the start of any puzzle in AquaBlock. The text is meant to stick a certain idea/thought in the player's mind that can serve as a puzzle hint. This signifier proved to be a bit more ambiguous and can have varied effectiveness.

PuzzleName.png

Design

Don’t indicators lessen challenge in puzzle games?

Even with a small scope and a forced control scheme, a mobile puzzle game like AquaBlock has the potential to cause the player to be overloaded with information. This is where things like constraints, mappings, and signifiers come in handy. Signifier do reduce the mental challenge placed on the player, but it also serves as a way of keeping a puzzle attempt-able.

How do hint systems differ from signifiers?

Hints in puzzle games are essentially player-obtainable signifiers. Both are meant to be perceivable indicators of where the action should take place, but hint systems are able to monetize this design concept. One downside of hints systems is that their effect is obvious to the player; players will have their feeling of accomplishment lessened because they realize they relied on a hint. This is why signifers need to be avoid being labeled by the player. 

Dev Blog - AquaBlock - Puzzle Difficulty (and designer rules)

DevBlog, Solo ProjectBernard HwangComment

This post covers how difficulty can be approached in puzzle design and why it is harder to create an easily solvable puzzle than a difficult-to-solve puzzle.

Everything you see in this post is work in progress.

Defining Puzzle Difficulty

Here are factors that I found helped define a puzzle’s difficulty.

  1. Number of Puzzle Pieces
    The quantity of pieces in a puzzle controls the time required in solving a puzzle. Each additional piece increases the number of possible outcomes the player has to consider. The ideal for this factor is try and get the piece count as low as possible while letting the puzzle serve it’s purpose. Every piece costs the player time, so don’t waste it.

  2. Number of Puzzle Mechanics
    The amount of unique puzzle mechanics the player has to consider sets a skill/knowledge gate. This number should be reasonably low to avoid having the player be overloaded with the amount of knowledge they have to recall.

  3. Preceding Information
    As a broader factor, any relevant puzzle information that surrounds the puzzle helps to smooth out the difficulty curve. Information that is not specifically a part of the puzzle can still be valuable to the player, like puzzle titles, themes, or even music.

Establishing Rules

Designer Rules

With the list of difficulty factors in mind, I established a few rules for myself for designing the puzzles in AquaBlock.

  1. Piece Selection Limit
    The self-enforced limit for pieces in a puzzle is currently six. There’s no hard formula that was used to calculate this, it was decided through testing. Six appears to be the magical number where the piece count just starts reaching the point of being overwhelming.

  2. Piece Size Range
    Each piece in AquaBlock can potentially be made up of nine blocks. A larger piece means there are less potential places to drop it, making it easier to drop.

  3. Block Type Limit
    The limit for different block types allowed in a single puzzle is three. This limit also does not have a hard formula attached to it; it mostly comes from the small scopes of the puzzles and the limited puzzle types currently.

Player Rules

Along with the behind-the-scenes rules that apply to me for designing, there are also some forward-facing rules that the player perceives.

  1. 3x3 Cube
    The player can only encounter a 3x3 cube puzzle; there are no other dimensions that the player has to consider. This hard limit keeps the scope of the manageable and conditions the player to approach each puzzle in similar ways.

  2. All Pieces Required
    The player always has to use all the pieces provided; there are no extra pieces and the pieces are never out of order. This simple rule gets the player to analyze all puzzle pieces at the start of a puzzle.

Design

Why establish rules for myself?

The "Player rules" are an attempt to playpen specific player behaviors and hopefully make the game easier to understand; the purpose of the designer rules is similar. The "Designer rules" help translate Game Design abstractions into rigid guidelines. So instead of constantly trying to figure out why I'm implementing things in a certain way, I can trust the rules I set in place at the start of production to guide my design.

What are some mistakes made?

While trying to have a larger puzzle piece count on some puzzles, I realized that I was creating “No-Choice blocks”, or puzzle pieces that didn’t offer any options in terms of possible placements. These blocks were acting as “puzzle filling", so I tried to avoid creating too many of these.

Dev Blog - AquaBlock - Controls

DevBlog, Solo ProjectBernard HwangComment

This post covers the iteration on AquaBlock's controls and the reasoning behind the changes.

Everything you see in this post is work in progress.

Previous Controls

Recap

The previous control scheme broke up the screen into quadrants and recognized quick swipes.

  • Swiping left/right on the bottom half of the screen rotated the puzzle block on the Z-axis by 90 degrees.
  • Swiping up/down on the left and right side of the block rotated the block on the X-axis and Y-axis respectively.
  • Swiping down on the top half of the screen drops the puzzle piece into place.

Mapping the touch areas to the puzzle cube itself was a good start for creating an accessible control scheme, but there were still a few layers of abstraction that could be stripped away. A more direct control scheme was designed to improve UX and accessibility.

Free Controls

Free Rotate

The new control scheme allows the puzzle block to be freely rotated in all degrees.

  1. Tap and drag on the puzzle block to rotate the puzzle block.
  2. Release tap on the puzzle block and the puzzle block rounds to the nearest 90° rotation. 

Drag Drop

Also added in the new control scheme is the ability to drag and drop the top puzzle piece.

  1. Tap and drag on the puzzle piece to move it around.
  2. Drag it close enough to the puzzle block when a drop is viable to lock the puzzle piece into place.

Design

Why add a new control scheme?

Iterations were made to the control scheme to improve UX. The singular swipes used in the previous controls didn't provide any tangibility in the interactions. The new controls allow for 1:1 interaction which makes the game feel more responsive as a result.

Why aim for better control mapping?

Having natural control mapping reduces the amount of information the player has to callback when playing. Keeping this mental load low helps a game maintain an easier learning curve and more intuitive mechanics.

By removing control abstractions...

  • Swipe zones
  • Locked 90 degree turns

... and replacing them with more intuitive controls, the game has less information to initialize onto the player. The game can rely less on tutorials and the player has less to recall when playing.

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.