Game Developer (2018)
About Journey Through Memories
Journey Through Memories (JTM) is a 2D puzzle platformer that utilizes speech recognition in a mesmerizing, hand-painted aesthetic to showcase Vivi the witch and her magical world. Set in the aftermath of a devastating war, players are invited to help Vivi discover new spells, cast powerful magic and unveil the untold past of the war’s fallen victims. JTM launched on Steam in late 2018 by a small team of game developers, 2D artists, music composers and producers. This fantasy experience was crafted using Unity, C# and Microsoft’s Cortana.
Magic Spells
One of the main appeals of the game was the ability to perform magic spells. When combined with speech recognition, the game granted players the unique experience of vocally casting a powerful spell in a similar manner to witches and wizards in films and television.
Due to the limitless nature of speech as a controller, it naturally bolstered a player’s curiosity to see what kind of spells they could and couldn’t cast. This curiosity also served as a motivational drive since it encouraged players to explore our levels to experiment with different spells in different situations. On the other hand, this also meant the game wasn’t intuitive which is why the team and I decided to utilize elemental-based magic. Elemental magic is a familiar staple in many fantasy games with very intuitive applications. To add some variety, we also added some non-elemental spells with similar intuitiveness (ex. growing and shrinking spells). Additionally, we also incorporated a spell book menu to act as a visual reminder of the player’s discovered spells (as shown in the picture).
As the team’s main programmer, I was tasked with programming the animations, spell effects and spell book UI. To prevent our content library from growing exponentially, I designed the casting animations to be reusable and easily customizable with particle effects. Each spell’s animation and effect were also organized into their own smaller scripts to ensure future changes would be quick and less error prone.
Spirits
Spirits are prominent in this world and each one has their own story to tell. In addition to providing the game’s lore, they also served the purpose of setting up certain puzzles.
We knew early on that spirits would be a vital part of the world building in the game. However, the main concern was whether or not we could generate enough spirits to tell the whole story without overwhelming ourselves. To address this issue, I designed a boilerplate script to foster quick and simple spirit creations. The script also allowed other developers to customize various traits of an individual spirit such as their name, speech, body color and puzzle-based behaviors to easily accommodate the developer’s specific needs.
Some spirits were also designed to trigger story panels to more powerfully convey their story in pictures instead of just words. I programmed this panel feature in a manner that granted easy accessibility to our artists so they could independently draw and fine tune their visual stories.
Puzzles
Solving puzzles was the other main component that drove the overall game loop. Puzzles came in the form of objects, obstacles and environments that could sometimes be solved in more than one way.
When it came to level and puzzle design, the key goal was to provide a mixture of straight forward and open ended challenges. The decision was made to populate the early portion of the game with straight forward puzzles to introduce the various spells as early as possible. For example, the first level was designed almost exclusively to introduce movement mechanics and the most basic of spells (as shown in the video). Meanwhile, the later portion would contain more open ended puzzles to test the player’s creativity and problem-solving skills. For example, the diagram and screenshot show a puzzle that can be solved using a combination of fire, water, and movement commands. To our pleasant surprise however, some players discovered alternative solutions using earth and growth spells instead.
While I did get to design some puzzles and level layouts, I spent most of my time programming them. To start, I first had to construct the game’s physics and collision engines. The next step afterwards was to implement and stitch together all the interactable objects and platforms respectively. Then I started programming spell interactions with the objects and platforms. To accommodate the goals of certain puzzles, I often found myself tuning the spells to prevent them from breaking simpler puzzles or causing buggy interactions. Finally, playtesting sessions were held to finalize these puzzles and level layouts.
Additional Content
Juan Rosales 