Primary Roles:
Co-Designer
Lead Gameplay Programmer
Sound Designer
K.U.N. is a 2D adventure game set in a distant future when the entire earth is flooded with water. Waking up in the middle of this apocalyptic world, the player has to find out what happened by exploring the surroundings, and to figure out what to do next under such a critical condition.
Platform: Unity
Collaborated with:
Tina Zong — Co-Designer, Level Designer, Writer
Sunny Pu — Lead Artist
Sam Xu — Artist
Peter Huang — Gameplay Programmer
Wendy Wang — Gameplay Programmer
Making of K.U.N.
Recreating Kun, the Mystic Creature
As described in Chinese Taoist literature Liezi (列子) and Zhuangzi (庄子), Kun is a big fish living in the North Ocean whose body is thousands miles long. It travels to the South Ocean while transforming into a giant bird, Peng (鹏).
Aiming to make our game different from orthodox interpretations of Chinese culture, we decided to bring in cyberpunk elements and recreated Kun as a cyborg creature serving as an ark that transmits survivors on earth to the outer space. Around this setting, we designed the background story of the main character who is a pilot that woke up in a malfunctioning Kun. The bird transformation of Kun described in the mythology is also reinterpreted as a mechanical transformation of the aircraft.
Designing Events & Puzzles that Weave a Story
Trying to come up with a sequence of events and puzzles for the player to solve is challenging, because not only do they have to be logically coherent and able to bring the player to the final destination but also do they have to contain certain information and reveal the story piece by piece.
Inspired by the game Another World and the idea of a cinematic platformer, we tried to minimize the use of texts on storytelling to guarantee the continuity, and utilized puzzles and events as our tool instead. For example, in one of the puzzles the player is supposed to shake a tree with a body hanging on it. Then they will be able to pick up a mountaineering pick falling from the body and use it to climb on a high wall. The appearance of that dead body reveals the dying nature of this world to the player. Another example is that we designed a scene where the player couldn’t do anything besides walking on a broken bridge and seeing the endless flowing water. That scene doesn’t have any function in helping player reaching the goal but serves as an indicator of the flood–an important part of the background of this game.
Lesson Learned: A Game System Complicates Itself Fast
Due to the linear nature of the events in our game, we programmed all events and interactive objects into separate scripts and put the objects at places where they are expected to happen. Each object has a collider as trigger on it. The reason that we did so was to make allocating problems easier when debugging since every interaction that player does with objects is strictly segregated.
Unexpectedly, when we were trying to implement new events and details into the already established system it became very problematic. Since one single object in this game can be involved in multiple events, it’s very easy to have some scripts doing contradictory things to the same object at the same time, and such problem usually arose when we added in new events. For example, the script for an event towards the end of the game is trying to constantly unlocking player control whereas another script at the beginning part is trying to lock player control for a set amount of time. The entire system complicates itself fast as the number of intersections among script functions grow.