Byne

A 3D puzzle/adventure game with a symbolic narrative about gender and the complexities of life. It critiques societal binaries through both gameplay and story, inviting players to explore themes of conformity and self-discovery.

Project Summary

Byne was originally a school project I worked on with 2 classmates. I set out to make an abstract narrative game about gender and asked them to work on it together. During this school project, we defined the core world-building and worked on some early prototypes. We struggled finding a balance between narrative and gameplay and ultimately couldn't get the concept off the ground.

After school, I continued working on the concept without my classmates. I applied for a subsidy through Stimuleringsfonds to make a demo for the game and was granted the money to work on it for the following 6 months. In this article I will mainly be talking about the demo I've made during that time period, but will also showcase some of the earlier prototypes and research that went into shaping the project.

The entirety of the demo that you see was made solely by myself (with use of 3rd party assets).
After finishing the demo, I made the decision to shelve the project for now, as the full scope of the game is too big to further develop on my own without additional team members and funding for the production.

The story of Byne

Byne is set in a binary world with "Flame Shapers" and "Water Weavers" that possess either fire or water powers.
Gender doesn't exist in this world, so instead the 2 different types of people represent male and female.
The game has you follow a non-binary character on a journey of self-discovery that is slowly trying to find their place in society.
Perhaps even reshaping society itself.

The protagonist is born with fire powers. Using these powers make them feel uncomfortable and gradually starts hurting them the more they use them.

The demo takes place at the start of their journey where they are being taught to avoid water at all costs and to instead embrace their fire powers. The water does not physically hurt them, so the only reason they need to avoid this is to conform to the rules of society.

This represents being raised to behave according to gender roles, just because society expects you to. The demo focusses on suppressing your identity as a result of this societal pressure.

Since the protagonist is assigned to be a Flame Shaper, they are not allowed to be associated with anything water related. The way this is reflected in the gameplay, is by having the player physically suppress water coming out of geysers by plugging them with corks. The water will then shoot out of another nearby geyser and is used to manipulate platforms that the player uses to navigate through the level.

This is the main mechanic for all of the puzzles in the demo and is later visually exaggerated during the ending sequence (more about that later).

Additionally, the player is constantly greeted with a choice to either take the short path that has them wade through water, or a long path that has them avoid the water.

Choosing to go through the water is the most obvious route, as the water itself doesn't have any negative effect on the player, but will result in the player facing judgement from nearby people for not conforming to the societal norms that everyone lives by. Further strengthening the theme of the demo.

The demo is introduced with a big canyon that our protagonist needs to cross in order to start their journey. The Water Weavers go around this canyon by going through some shallow water. The Flame Shapers however, need to cross it using a gondola.

When the player tries to call the gondola, a giant cork flies through the air, followed by a powerful jet of water. The gondola stops working before you can get on it and a nearby relative explains to you that the geyser that was powering the gondola has just bursted open.

The easy solution would be to go around the canyon using the Water Weaver route, but your relative does not allow this. They order you to follow them down into the canyon to help them fix the gondola.

Once down in the canyon, you are tasked with finding 4 gears that are required to repair the machine that can re-plug the geyser. Once you have collected them all, you can return to the machine and activate it.

When you do, a giant mechanical fist firmly slams a new cork into the geyser and violently hammers it deep inside. Trapping the water in the machine and powering up the gondola, which is where the demo ends.

This final climactic suppression of the water, symbolizes that our protagonist has permanently shut off their connection to a big part of their identity. Solidifying their mental change and starting their journey down the wrong path.

Design Choices

Geysers

In it's earliest version, the geyser mechanic worked a bit differently. Multiple geysers were connected to each other and once you plugged the active geyser, the water would go to the nearest connected geyser without a cork in it.

The challenge here was getting the water to a geyser that is hooked up to a machine, by plugging the geysers in the right order. Once there, the water gets trapped inside the machine and powers it. This in turn opens a door or gateway to allow the player to progress further into the level.

Having a few people playtest this concept with paper prototypes worked pretty alright. The rules were clear, but it could still be made complicated enough for it to be challenging.

Testing it in-game however, proved to be very confusing to players. Seeing the entire area from a top-down view on paper, made it very clear what path the water would take, but playing this in third-person perspective made it a lot harder to see and resulted in most players brute forcing their way through the puzzles.

While on paper it was fun for people to freely experiment and put corks in random geysers, in-game it became tedious for people to keep walking from one geyser to the other, without certainly knowing what the outcome would be.

To combat this, I limited the water to only be able to go to one other geyser instead of the closest one. This however meant that finding the right path was no longer the challenge, so instead I added different types of platforms that the player can manipulate using the geysers. Making the combination of the geysers and platforms form the puzzles, instead of solely having to find the right path for the geysers.

Vertical Platform

Rotating & Flipping Platform

I have a lot more interesting examples to talk about here, but if you're reading this, it means I'm still busy typing them out or finding some fitting footage to go along with it ;)

Check back later for some an inside on: design choices, defining the core gameplay loop, level design, puzzle design, older prototypes and the initial research that kickstarted the project.

Technical Challenges

Physics vs Navmesh

One technical problem I ran into in the beginning, was finding a good way to restrict the player's movement to a certain area. It was easy to restrict the player to walled in areas by adding a physical barrier, but having them not fall off a ledge proved to be a bit more difficult.

I started out by using invisible barriers, but this soon turned out to be a grueling inefficient task. I tried Raycasting to the ground below the player to prevent them from falling from certain heights, but I ran into a lot of edge cases that made this method not a reliable option.

Eventually I got inspired by the game "The Last Campfire" to use a navigational mesh for the character movement. I had used Unity's Navmesh system multiple times before, but never thought of using it for player character movement.

Instead of using physics to drive the player character forward, I instead made it pathfind to its target destination using the Navmesh. I then simply used the direction of the movement input to set the target direction right in front of the player, and voilà, all of a sudden, all my problems were solved! (In the GIF, the yellow sphere represents the movement input and the blue sphere represents the final target destination on the Navmesh.)

This worked wonderfully, giving me full control over the intended play area and leaving no room for edge cases to pop up where the player might fall down from somewhere or get stuck due to some physics-bases issue.

I have a lot more interesting examples to talk about here, but if you're reading this, it means I'm still busy typing them out or finding some fitting footage to go along with it ;)

Check back later for some an inside on: creating Spline-based movement, implementing Finite State Machines and more, alongside some code examples!

‌

Mobirise