top of page

Developed in Unity Engine 3D                                                 May 2020 – August 2020

Role: Systems Designer                                                                             Team Size: 9

A Singleplayer, Third-Person, Casual Puzzle Game
5e55f69edd54424f9fde4f01e5b783ac.png

Responsibilities:  Documentation, Systems Design, Puzzle Design, Balancing

Maneki and the Firefly Spell

Overview

Maneki and The Firefly Spell is a third-person puzzle adventure game where the player takes on the role of Maneki. A witch in training whose girlfriend has been magically transformed into a firefly. Brew potions and solve puzzles to help Maneki reverse the firefly spell.

Development of this game took place remotely during the summer of 2020 as part of the Rad Magpie Studio Summer Incubation Program. The game’s concept was developed by one of our programmers who wanted to make a wholesome narrative-puzzle game about a cat who crafts potions. My responsibilities were mostly with designing the crafting system and how the potions interact with the world. 

Features

  • A complex potion crafting system that allows for a multitude of ingredients to be combined

  • Throw potions to change the physical traits of objects in the environment

  • Large playground like level to explore and experiment with the game’s mechanics

  • Character dialogue including dialogue choices

giphy-downsized-large.gif

My Responsibilities: 
I was responsible for designing and balancing the game’s potion system. I primarily worked on the crafting process as well as their in-game interactions. The potion system was designed to be simple enough to interact with but interesting enough to keep the player interested in the puzzles and narrative. I worked with another designer to bring our product owner's vision of a wholesome puzzle game with a unique crafting system to life.

Design Problem: The Potion Problem

Maneki presented a few different challenges. One challenge that was quickly evident is something I call the “potion problem”. Our potion crafting was based on creating effects based on the ingredients that are used. Each ingredient is given a keyword that is used to explain its effect. Combining the keywords of the ingredients will describe the effect of the resulting potion. Allowing players to essentially “write” a potion into existence when crafting. This felt incredibly charming and was very popular during QA.

 

 

We quickly discovered that each new ingredient we designed caused our technical scope to increase exponentially. We wanted to give players a large amount of control over their environment to experiment and play with, while still keeping the player’s abilities within the scope of our development time. It all boiled down to striking that balance between infinite possibility and technical capability.

giphy.gif
MA_CraftingDemo_Transparent.png

Solution #1 - Limit Ingredients 

Once it came to our attention that the game’s scope was starting to exceed the amount of time and resources we had available, we decided to limit the number of ingredients available to the player. At first, I had wanted there to be many different permutations of potion effects ranging from physics, elemental, or visual. This quickly got out of scope so we decided to limit the crafting system to potions consisting of 2 ingredients, one that determines the physical property the potion will affect, and one that determines how that physical property will be affected.

giphy.gif

Solution #2 - Intentional Interaction Design
Another way we limited the scope of our game while maintaining the joy of discovery was by being extremely intentional in designing the potions interaction. Theoretically, any object that is not the ground or trees can be affected by our potions, so we made sure to create environments and situations that allow for interesting interactions with the potions without increasing the technical scope. All of our set pieces were designed specifically to allow the player the ability to experiment with the systems available to them without increasing the technical scope of our game. 

Documentation

bottom of page