MShade
Status: Demo Complete
Role: Prototype Engineer (solo)
Studio: Unnamed Studio
Technologies: Unity (C#), Visual Studio, Twine
Platform: Mobile
Exp Gained: Twine to JSON to Unity
Mshade is a prototype for a mobile BDSM game that simulates the relationship between a dom and their sub. To read more about it, read my breakdown of the project. I was the only engineer for the prototype.
Postmortem
Overview
One fateful year at Indiecade, I had a hopeful mobile game project described to me as a “BDSM mobile game” by Chelsea Howe. The elaboration was that she wanted to take mobile game behaviours that are surprisingly BDSM flavoured and illuminate them within a less obscured context (more on that later). I managed to gracefully finagle my way into the role of Prototyping Engineer by throwing my arms in the air and failing them as soon as she dropped the line “Its a game I want to create but the engineer I normally work with isn’t interested in the project”. Surprisingly, I’ve gotten more than one gig that way.
The prototype for MShade isn’t 100% completed, but it’s reached a stage of Hiatus from
which I’m not sure when it will revive.
Alright. Back to those BDSM behaviours. I’m not the writer nor the designer, so I won’t do it the disservice of trying to explain it in its entirety, but I can at least overview. Some of you might be going to extremes in your mind palace with images of leather whips and ball gags, and though I don’t want to dissuade you from holding those images in your head, the behaviours we’re discussing here are far more subtle and a lot more cerebral. There are certain things that we do within games and behaviours that our apps have that we tend to take for granted. Games will sometimes withhold gratication by letting us gain momentum and then dropping a paywall. Some games command that we do very repetitive or menial tasks for a token reward. Occasionally a game will send you push notifications and reward you for engaging with them in a timely or regular manner. Many of these psychological games (if I can call them that) are also enjoyed by BDSM. MShade is a mobile game that plays a little like a visual novel with some added minigames. You’re establishing a relationship with “M”, the app, who acts as your dom. Through discussions, tasks (minigames), and gifts, you evolve your
relationship with M much like you would with a real dom, but with the filter of an application on your phone.
Ok, I hope I didn’t royally screw up that summary. In any case, a really interesting project.
Gameplay
As mentioned earlier, the game plays a little like a visual novel with some embedded minigames. For conversation, the user would tap to advance the conversation, swipe up or down to say ‘yes’ or ‘no’, and would add a little turn to their swipes to indicate respect, turning the yes or no into something more like a ‘yes ma’m’ or ‘no sir’. Sometimes you’d be given a list of options to choose from, in the cases where a response more elaborate than ‘yes’ or ‘no’ is required.
The one minigame we implemented for the prototype was the “farming” game. It’s framed as a “cleaning” game, where M requests that you clean up the dirty tiles. At some point in the conversation it was intended that M ask if you’d feel better if the grid was colorful and resembled a farm, trying to draw a correlation between the menial tasks we often perform for games and how all we need is a pretty interface to hide the fact that we’re often just tapping boxes. There are a few hooks in the game for behaviour – if you tap often through the forced wait countdowns, for instance, M will chide you for being impatient.
That’s most of what the demo experience covered.
Development
Now, for the development, I encountered a problem that I’ve encountered a few times before now – how do I get a branching storyline from the writer(s) into Unity? I’ve previously toyed around with creating a node editor within Unity, but in this case the writer(s) weren’t as comfortable with Unity, and preferred to remain using their editor of chioce: Twine. I’d worked a little with twine before, so I gured I’d attempt to either import from twine, or use a similar tool. I liked the look of Yarn, but after playing with it for a little bit I decided it wasn’t going to fit my specific needs. I instead ended up using a Twine > Json exporter, and then just built a system around those json files.
Using twine to get the story and decisions into the editor was easy enough, but it became a little more complicated when it came to communicating changes to the game. I needed a way for the writers to communicate things like changing variables that will persist with the user, modifying the appearance of the text, and starting/stopping minigames. The exporter I used marked json fields with {{double brackets}}, so I just built a simple markup-esque system where specific commands would do specific things within the game. Not as flexible as I’d like, but it got the job done quickly, which is usually my priority for prototypes.
Building out that parser was most of the work for this prototype. The only other problem that cropped up that surprised me was the desire for the text to type out one character at a time on centered text, but without it constantly readjusting its alignment. So, below on the left is what will usually happen if you do a standard typewriter implementation where you just add characters to the display with a wait in-between, and on the right was the desired behaviour.
I ended up solving the problem by filling a single centered box with the text, then using the cache to break it up by line, then creating a content-scaled line for each line and filling them, leaving them left-aligned, and then filling those text boxes out instead of the one large centered one. For all I know there’s a much simpler implementation – especially with Text Mesh Pro apparently becoming a part of unity – but it was the solution I used at the time.
Closing
I really enjoyed working on this project, and got to really flex some string parsing muscles that I hadn’t used in a while. I hope that it gets resumed at some point and can be taken to its completion.