The JerryMaya Detective Agency

Genre
2D Puzzle Platformer

Live Service

Engine

Unity

Platform

Mobile Devices

The Game

Where is the missing diamond? Who is the culprit? Who can solve this mystery? Only you can help!
Based on the popular Swedish children’s books, The JerryMaya Detective Agency is a brand new adventure game following the two young detectives solving crimes in the small town of Valleby.

Play as Jerry and Maya, explore Valleby, and meet the eccentric residents who are in need of your help. Solve mysteries using your detective skills by puzzles and using teamwork to navigate tricky platforming levels. Find secrets, clues, evidence, suspects and more to figure out who is the culprit.

Contributions

I joined this project to mainly take charge of its sound design and sound implementation but I also contributed to things such as level/puzzle design. In short, my contributions were as follows:

Sound Design

Take charge and organize the audio aspect of the project.
Design the spoken language of the project.
Record, edit and implement all character voices.
Manage and implement music for the project.
Design, edit and Implement all sound effects for the project.
Script most of the project's audio triggering.

Level Design

Design, create and implement levels and puzzles for the project.

Game Design

Design assistance for gameplay features.

General game design assistance.

To Google Play

Section Navigation

Game Summary

What is "The Jerrymaya detective agency"

Before diving into the design of "The JerryMaya Detective Agency", let's first go through a quick summary of what the game is.

In short, the game is a live service 2D game, with a focus on puzzles and light platforming. The player takes on the shoes of two young detectives who help the police solve crimes around their town. This is done by exploring the various areas in town, interrogating victims and suspicious individuals, looking for clues and evidence, and ultimately solving the case by locating the stolen item, deducing who the culprit is, and apprehending them.

For a better view of the gameplay loop works, see the visualization below.

Gameplay Loop

Use the evidence to deduce and apprehend the culprit

Complete the puzzle room to locate the stolen item and evidence

Search Hideout for a key to access a Locked puzzle room

Take on a new mystery

Locate the crime scene and victim

Inspect the Crime scene for clues

Use the clue to locate the hideout of the perpetrator

Icons made by Freepik from www.flaticon.com

Game Design

Gameplay Component Iteration

My contributions to the project's gameplay design mostly revolved around assisting with iterating on the various interactable components in the game while building and playtesting various levels and puzzles.

Throughout the game, the player can interact with various different objects, such as ladders, crates, elevators, minigames, and more. While these can be found in various places around the game, their primary use case is to create intricate puzzles of varying degrees in designated puzzle rooms.

Below are a few examples of design changes for such components that I iterated on for the final release.

Elevator component

The elevator component's primary use is to allow the player to transport crates in between floors and while the elevator is in motion, the player retains complete control over their character

The Issue

Depending on the level layout, the player and any crates brought along could be moved out of the elevator at any point while in use. This made it prone to create collision bugs if a crate was partially outside the elevator and collided with a wall. It could also set the player's progress back in case they accidentally pushed crates off the elevator or in some severe cases even soft lock the player.

The Solution

Adding elevator doors (colliders) on the exits whenever the elevator is in motion, preventing the player and any crates from exiting the elevator while in use.

While this change somewhat limits some of the elevator use cases as a puzzle component, it did prevent the scenario where our issues occurred while also making the designated use cases for the elevator easier to understand for the player.

Reasoning

Keeping with the identity of the IP, our target audience (kids between 6-12 years old), and its focus on puzzles, it was decided early on that any platforming and reflex challenges would be relatively low in difficulty. With that in mind, I proposed this change to prevent situations where the issues occured while also moving away from any scenarios where potentially difficult maneuvering would be needed, such as needing to exit or push a crate off a moving elevator.

Keypad Minigame UX

The keypad is one of three various minigames the player can encounter in the game, all of which are used as an alternative way to interact with certain objects, such as doors, lasers, or safes containing evidence.

For example, instead of opening a locked door with a lever or pressure plate, it is sometimes instead done
by operating a nearby keypad terminal. Here, the goal is to figure out its passcode by using the notes scattered around the minigame UI to find out the correct numbers and their placement.

While I had no part in designing the minigame itself, I was in charge of its sound design (which I will cover in a later segment) and some UX improvements regarding its visual feedback, which is what this segment will focus on.

The Issue

When implementing the audio for the keypad minigame, it became clear that the fail and success states had a lack of visual feedback. Giving the correct code would simply play the corresponding audio cue and close the minigame UI afterward.

While the audio queues could suffice to inform the player of their success, the absence of visual feedback could pose a real issue for players with hearing disabilities or when simply playing with the sound off.

The Solution - On Failure

A quick solution was to create two small animations to alter the color values of the text render component showing the passcode.

On inputting the wrong code, the corresponding audio cue would play and the color of the text would simply turn red for a brief period before returning to its original color.

The Solution - On Success

Here, I instead opted to simply change the alpha value of the text to create a flashing effect to visualize the correct input, which is also accompanied by its own distinct audio cue.

Reasoning - On Success

I originally intended to use a green color (as red and green are typically enforced to mean incorrect/correct) however as the sprite for the"screen display" behind the text was already green, I feared that it would have caused issues with readability. For our purposes and as this was a small task I squeezed in between my other duties near our release, this solution felt sufficient and quick to implement.

Level Design

Puzzle Rooms

Besides the explorable town (wherein the player spends most of their time during investigations), there are also puzzle rooms that typically take place near the end of each mystery. These puzzle rooms are randomly selected for each mystery and contain three pieces of evidence and the stolen item in question. While the stolen item is the only required item to proceed into the final part of each mystery (which is figuring out who stole the item), the more evidence collected, the easier it is to deduce who the culprit actually is.

Let's take a closer look at just a few of these puzzle rooms that I designed and my thought process around them. Do keep in mind however that most of the following screen captures are from a zoomed-out editor view in order to more effectively go over their design.

Puzzle Room Number 20

This room was one of the first ones I designed and was created fairly early in our puzzle room production phase. As I joined and went through the earlier levels created by my two fellow designers to get an understanding of the game, I felt that most of them were following some fairly similar patterns. As a result, I instantly wanted to try and find other uses for our puzzle components.

Thus sprang forth an idea of using our elevator component as raisable platforms instead of just as a means of transporting the player and crates. Here, the player must find ways to access all of the elevators in order to line them up in a row, creating a bridge that can be used to move the crate on top of the lasers, thus giving them safe access to the stolen item.

The starting layout [1 - 10]

In editor, the evidence and goal is not shown correctly, so I have marked the goal instead.

The player view of the goal [2 - 10]

Heading to the right, we collect our first evidence and get a view of the stolen item.

Bonus - Softlock Prevention [10 - 10]

Incase the player goes back round again, this side path prevents them from getting stuck.

The starting layout [1 - 10]

In editor, the evidence and goal is not shown correctly, so I have marked the goal instead.

1/10

Thoughts & Reflections

While being one of my favorite playroom creations, it does have some flaws in that it does not utilize the partner swapping mechanic that much. I was also afraid that the location of the end goal would be hard to grasp if one does not locate the small sneak peek location in the lower right. However, playtesting proved this to not be much of an issue, most likely because the puzzle structure is relatively linear in its progression.

Puzzle Room Number 32

One of the later puzzle rooms that I created but the one that began with the strongest theme. In most other puzzle rooms up to this point, the player characters always remain relatively close to each other as the rooms remained relatively small. This brought about the idea of having a larger area where the two are isolated from one another and must traverse two distinct paths, one being the above-ground corridor and the other a deep basement section.

Here, the player must swap back and forth in order to help each character move further along their respective path. Along the way, the player may use the blue-marked objects as rest points while swapping, which will keep the swapped character in place until swapping back.

The Starting Layout [1 - 11]

A zoomed out view of the map in its initial state. The stolen item (Goal) is marked.

Split up and search [2 - 11]

The trapdoor opens and the duo splits up. A large drop is used to enforce the act of splitting up.

Extra - tricky evidence 2 [11 - 11]

Using the above character to call the elevator back up will open the path for the character below.

The Starting Layout [1 - 11]

A zoomed out view of the map in its initial state. The stolen item (Goal) is marked.

1/11

Thoughts & Reflections

Even being on the larger side among the various puzzle rooms, the level still feels rather easy to read and understand since each character's sections are rather limited in space.

In terms of evidence placement, I wanted two of the three evidence pieces to be relatively easy to find, with one being just off the beaten path to the left and the other being locked behind a set of lasers and a short minigame. This means that the player should on average have enough information to deduce who the culprit is, even if they were to miss the slightly tricky last evidence.

While I was worried about a soft lock situation in the elevator shaft, there should be no situation where both players can drop down as one must ride the elevator down first (buttons only call it to their respective floors).
With that said, this scenario could still allow one character to be pushed between the elevator roof and the ceiling. This would simply result in the character being pushed down into the elevator and while that poses no problem, I would have liked to add a solution to it. Perhaps by still allowing it to happen but adding a small alcove above the elevator shaft.

Puzzle Room Number 19

In this room, I wanted to see if we could create some new interactions by combining different gameplay components. I started with our "crane" component, which allows one character to operate a moving platform that can transport things like the player characters or crates. After a bit of iteration, I started wondering what would happen if I added other interactable objects to the cranes' platform prefab and ended up attaching a throwable ball component.

This component allows the player to aim and throw balls around for things such as knocking down shelves holding pieces of evidence or hitting electronic targets that activate nearby objects.
One small caveat is that this component roots the player in place as the control stick shifts to allow for aiming instead. This means that we had to place these throwable components in very deliberate places.

However, with the throwable component attached to the crane platform, we could now allow the player to move around while aiming as the player could swap between the character operating the crane and the character using the throwable component.

The starting layout [1 - 6]

Things of note: the stolen item (goal) is marked and only the cranes platform has collision.

Hitting the first target [2 - 6]

By hitting the targets, the trapdoors open and the crate can make its way down.

The stolen item in reach [6 - 6]

The last trapdoor opens and the crate falls on top of the lasers, blocking them.

The starting layout [1 - 6]

Things of note: the stolen item (goal) is marked and only the cranes platform has collision.

1/6

Thoughts & Reflections

This level in particular was appreciated by my fellow designers, as it helped us think a bit more outside the box when it comes to what could be done with interactions between our various gameplay components.
It also gave birth to many other combination ideas.

On its own, this level is fairly simple and short once the player gains an understanding of what to do but my intention was to help the player think more vertically in their puzzle solutions. Especially when it comes to finding all of the evidence pieces, as this idea made it possible to start hiding targets to hit in more elaborate places.