Frog Story!

Genre: Interactive fiction with minigames
Engine: Unity/ink
Solo Project
Development time: 2 weeks

Created for Narrative Driven Jam 7, April/May 2022.
Theme: Frog
Optional sub-themes: Outside ur Comfort Zone, Self-Conscious Narrator, Lost in da Woods
Ranking: 4th overall out of 13 submissions; voted 1st in the Concept category

Play on itch.io

Screenshot of Frog Story! gameplay showing the ability to click on objects within the scene.
In some scenes, the player must click on objects within the game world.
Screenshot of Frog Story! gameplay showing dialogue choices made via UI buttons.
The player can often select how Fern will respond during dialogue sequences.
Screenshot of Frog Story! gameplay showing a minigame in which the player must guide Fern around rocks in a river.
There are two dodging minigames; in this one, Fern must dodge rocks as she’s swept downriver.

Design

Narratively, I decided from the beginning to spoof the prince-turned-frog fairy tale. Fleeing an arranged marriage, Prince Oran purposefully transforms himself into a frog and plans to escape by flushing himself down the toilet. His best friend Fern, the player character, also becomes a frog and follows Oran, hoping to change his mind.

The silliness of the story concept informed not only the writing, but the aesthetic design as well. Embracing the jam’s optional sub-theme of “Outside ur Comfort Zone,” I decided to do all the artwork and music myself. (In case it wasn’t obvious, I am neither a trained visual artist nor practiced musician.)

Inspired by old Winnie the Pooh cartoons, I decided to set the game within a storybook. I wasn’t confident I could properly convey the idea with my artwork, and thus chose to record a video of myself turning the pages of a notebook. This had the added bonus of taking the “homemade” aesthetic a step further.

Likewise, I whistled and hummed the game’s music instead of using instruments or a DAW. The “It’s a Frog Story!” theme song blossomed naturally from this process.

In terms of mechanics, I decided to keep things simple. Most of the gameplay consists of choosing one of two dialogue options presented as buttons. In some sequences, the player can interact with objects in the scene by pointing and clicking. My desire to add some motion to the otherwise static graphics led to the inclusion of two minigames in which the player must dodge objects by moving left and right.

I chose Unity and ink as the technology for the project, as I had experience working with those tools and didn’t want to add unnecessary risk.

Implementation

The most challenging part of the game to implement technically was the video background. I hadn’t worked with Unity’s Video Player component before, but fortunately setting it up was relatively simple. I trimmed the video of turning the pages in my notebook so there was very little “dead space” of lingering on a single page, noting the times at which the video should pause. I then wrote a C# script to control the Video Player, playing the next page turn when a public method was called and setting a property to indicate the transition was complete.

The ink script could call the page turn method as an external function. Similarly, the ink contained external functions for changing the displayed characters and choosing the music.

Using a variable, the ink script can set the “choice mode” to one of three values: dialogue, map, or minigame. When in dialogue mode, the C# code in Unity knows to present the choices as buttons. In map mode, each choice is associated with an object in the scene the player can click. Minigame mode presents no options to the player, but instead allows the Unity code to notify the ink script of the win/lose result. This last one was particularly helpful for testing the story script in Inky.

Because the minigames use the same mechanics, a single controller script could be used for both. The script allowed configuration of the game area, number of obstacles, speed, and difficulty progression.

Lessons Learned

The minigames weren’t intended to be particularly difficult, but they were a bit too easy and went on for too long, boring some players.

Due to the tight deadline imposed by the game jam, I used an inflexible “overlay” system to position objects in each scene. This led to a lot of hand tuning as well as repeated, inefficient code.