<aside> ⚠️ THIS PAGE IS IN PROGRESS - MAYBE IT SHOULD HAVE BEEN DONE BEFORE SENDING THIS PORTFOLIO OUT BUT GOOD IS BETTER THAN PERFECT, RIGHT?
</aside>
Role: Solo Dev - Programmer, Designer, Artist
Project Length: 1 month (ongoing)
Sexy Labyrinth is an asymmetric online multiplayer arcade game built in Unity. I designed the concept art, produced and animated the game sprites, designed the lobby UI/UX, programmed the multiplayer networking and game mechanics. This was done originally as a part of the Sex Games Jam (2022), over two weeks. After launching on Itch.io, this game is integrating player feedback with subsequent releases.
Its design goals was to create a space that would enable a couple to experience the online, digital equivalent of kinky, dom-sub sex. That meant the primary designs focuses were:
Having these design goals explicitly laid out at the beginning of the game jam was important because I only had two weeks and could only afford to pursue the highest priority tasks.
For example, these design goals meant that I prioritized writing a comprehensive content warning and the option to enable/disable sex instead of giving myself more time for more traditional game mechanics like Dashes or Attacks. Instead of adding collectables or health or timers, I wanted to encourage a more open, tag-like mode of playing. I invested more time animating a variety of sex positions because that too, is a form of player expression and I wanted there to be a variety of ways to have sex, as there is variety in real life.
An important design decision was the way the Minotaur overwhelms the Hero. In a typical multiplayer game, if Player A beats Player B, there is a predefined set of consequences. Player A wins, gets points for beating Player B, B’s game ends. In some cases, Player A gets to loot Player B’s inventory for items, gets a public record of that win.
In Sexy Labyrinth, I explicitly decided to go against this convention for the purposes of player safety. In a digital space, we embody our avatars. When our avatars are violated that is reflected back on our real selves. For something as intense as sex (and in our case, specifically “consensual non-consent sex”) I opted to design a system such that even if “the Minotaur overwhelms the Hero” in the scene, consent from both parties is still explicitly requested before the game transitions into its sex phase. To further this point - in Sexy Labyrinth even the “aggressor”, the Minotaur, receives the same consent prompt before sex is initiated.
Building a configurable multiplayer game in a game jam is not easy and it would have been easy to say, sorry, I didn’t have time to build a multiplayer configuration menu but to meet my design goals I had to give players the option to disable sex if that was their preference for this kind of play.
This design goal was also built into Sexy Labyrinth’s UX. See, scene negotiation is an important part of kink, discussion what is fun, what isn’t, what individuals’ boundaries are. It’s necessary to make sure kink is safe. In Sexy labyrinth, the game can’t start until both players enter the scene configuration menu together. And in the configuration menu, defaults are not provided. The game tries to avoid setting expectations using defaults and encourages players to come to their own decisions about the kind of scene they want.
An important factor of my participation in the Sex Games Jam was the opportunity to expose a project to a wide audience and practice collecting data, making data driven decisions.
To that end, one of the most important tasks I prioritised for the v0.1 release of this project was integrating game analytics. I integrated Game Analytic’s packages, set up some basic metrics and funnel analysis.
Through this, I was able to better gauge Sexy Labyrinth’s reception. While Itch.io reported 2500 browser plays in the first week, I was able track that only 309 play sessions in the first week actually resulted in a complete game.
Analysis into to player behaviour also revealed that users were ending and restarting the game immediately after a play session. Through this I was able to prioritize the development of a “replay” button so that the game could be replayed without refreshing/recreating the game lobby. This was critical because I had a laundry list of features I wanted to add post-launch and looking into the player data actually helped me prioritize a feature I likely would have ignored for several weeks.