Post-Mortem: AquaBlock

AquaBlock is a turn-based puzzle game designed for mobile devices. In the game you piece together blocks to create a finished puzzle cube. The player can spin and rotate the puzzle cube to find the correct orientation that the blocks need to be placed. As the player progresses through the puzzles, they discover different block types and unique ways in which they can be used.

3 THINGS THAT WENT RIGHT

1. Utilizing Last Project's Assets
   AquaBlock is my second mobile release, a follow-up to MechDog. Fortunately through good scripting on MechDog, I was able to carry over many scripts and managers to expedite certain parts of development. The benefit of making scripts that are universal and transferable between projects should not be underestimated.

2. Performance Testing from Day One
   A lesson that I learned from my last project was that performance testing needed to be practiced during all points in mobile development. Although it was a time-consuming practice, the constant testing helped create straight-forward decisions on which post-processing effects were viable and what quantity of in-game effects were acceptable.

3. Task Managing for a Solo Project
   It was very important to use a task manager to stay on track during production. Even with a team size of one, the task manager was used in keeping tasks organized, prioritized, and minimized in scope. By visualizing tasks in the manger, I was able view which tasks were causing bottlenecks and put them on the back burner.

3 THINGS THAT WENT WRONG

1. Puzzle Playtesting is Different
   In skill-based games like shooters and platformers, you can have the same playtester replay a section multiple times and still collect useful data every time. This isn't the case with knowledge-based games like puzzles because they are solvable. Once a playtester completes a puzzle, they can simply rely on their memory to complete it again. Unless iterations on the puzzle completely change it, a old playtester's feedback isn't as valuable as a new playtester's feedback.

2. Not Setting Clear Goals for Polish Phase
   While there was a healthy amount of concepting in the early stages of development, additional concepting would have still been useful for polish. There was no set vision for how the game would finally look. Towards the end, it felt like a grab-bag of UX and FX ideas were being thrown at the game to see what would stick. Reinforcing the game's vision would have resulted in a more efficient polish phase.

3. No Competitive Research
   Because the puzzle genre was an unpracticed genre for me, I should have at least tried to benefit by having complete knowledge of the subject. Many of the design/UX problems faced during production could have been more fluidly solved by analyzing other puzzle games for possible solutions.

OUTCOME

Working on AquaBlock has taught me a few things.

1. Apply different types of playtesting for different game genres

2. Schedule more concepting breaks to refine and polish the game's vision

3. Look towards games of the same genre when suffering "Designer's Block"

4. Keep static scripts well-documented so they can be plugged into future projects

AquaBlock Launch

AquaBlock is available to play on the Google Play Store!

Dev Blog - AquaBlock - Puzzle Signifiers

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.

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.

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)

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

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.