Development Log 2

For my first transition room, I’m planning on using the trans experiences from my Trans Experience Survey to create harrowing messages that the player has to listen to while traversing a black corridor. The player's only navigation through the corridor will be words from phrases of harassment. When the player reaches the word, a memory of that harassment will play audibly. The player will be literally wading through messages in the darkness to find the light at the end of the tunnel. I decided I wanted to depict those messages audibly and physically.

For the physical portion of this room, I decided that I’d like to model key words from the experienced lines. The lines I had chosen were: “Godless heathens like you are an abomination to our Lord.”, “Ew, look at that man in a dress!”, and “Do you think it is a man or a woman?” I chose “abomination”, “it”, and “man” as the key words that’d be depicted physically. I thought they would share a common theme of the player being referred to as something they’re not (As the player character is assuming the role of a trans woman). Each line is a mixture of an answer from a survey and my own experience.

For modelling the words, I considered using Maya’s Word Art feature, however, the feature required a new download of either a 2016 Extension or a newer version of Maya. My student license allowed me access to these versions, but I was running into many frustrations in installing the new versions. Not only that, but the word art I was seeing looked generic and not quite what I wanted to go for. I could model the words by hand in Maya, but this seemed like it would be a timely process.

I eventually decided on using Google’s Tilt Brush 3D for the HTC Vive. This was commercial software that I already owned and it allowed me to create the hand-written and scratchy aesthetic to the words I was looking for. The models created with Tilt Brush 3D had a feeling of wrapping around the player due to being made in a virtual reality environment. Using this software gave me a bit of a creative spark after spending so much time with Maya and Unreal.

Unfortunately, while I could export general FBX files that worked with Unreal, more specialized tools that allowed the transfer of particle effects only exist for Unity. While there are some third-party applications in existence for using these particle effects in Unreal, they seemed spotty and cost money that I’d rather not spend on such a small part of the project (Especially not on software that might not work properly). The particle effects weren’t essential to my project, so I moved on without them.

Other recent work included another attempt at fixing my VR collision issues. I looked into a few potential methods, mostly by scouring forum posts, as again, proper documentation and tutorials are hard to come by. One thing that caught my eye was a VR Expansion Plugin for Unreal. This plugin would seemingly allow me to work in VR with development techniques that I’m more accustomed to. I attempted to install it, but ran into various issues with Microsoft Visual Studio. For whatever reason, it wasn’t generating a code version of the plugin properly. After a few hours of troubleshooting different solutions, I decided to just contact the creator of the plugin.

The creator of the Plugin helped me get it installed on my copy of Unreal. It took a lot of troubleshooting, but I got there. I was able to bypass the Visual Studio problem through a different method of installing. I’m now experimenting with the new VRCharacter options this plugin gives me. As opposed to using the default VRPawn, I should be able to now use a proper character Blueprint along with a Capsule Collider. Being stuck with the default VRPawn meant I didn’t have access to proper colliders. Now I do. However, I now have to replicate the sophisticated movement of the default VRPawn in this VRCharacter.

I continue to deal with the harsh realities of developing with VR for a one-person project. I'm especially glad I decided on a simpler art style for my work due to how time consuming creating every asset is. Coming to terms with the lack of MoCap animation for my project has been harder than I thought. I feel a lot of the reasons I chose this project are no longer valid. I still want to make a game that illustrates my experiences as a trans woman, but I also think working with VR is compromising it more than providing an enhanced experience. Also, losing the MoCap aspect is a huge blow since that's one of the few unique skills I feel I've picked up in my university experience.

Development Log 1

I've decided to start doing a development log going over specific events and issues during the development of this project. I think this will work better to illustrate my work than the more generalized blog posts I've made in the past. The brunt of my development work for the last week has been trying to figure out why things aren’t working the way I’m used to. VR development differs from non-VR development in a lot of ways that I wasn’t prepared for. I’ll outline a few of those ways and what’s gone wrong and what’s worked in this development log.

I spent a lot more time than I expected rescaling models and rearranging things to better fit the VR interface. This is something I had hoped to do weeks ago, but was delayed due to the lack of equipment. At the time being, I’ve only been able to finish this for the opening room and not the other planned rooms. Now that I better understand the proportions I need, this should go by much faster in the future.

The biggest hurdle this week was with the NavMeshBoundsVolume. This is a game object that dictates where you can and can’t move in a space. While this object isn’t exclusive to VR development, I had never needed to manipulate one in my previous games, so I was generally unfamiliar with it. I was having an issue where if the player moved on top of the bed, they wouldn’t stay the amount of space they had moved vertically. They were essentially locked to a specific set of Z coordinates that was higher than the floor, even when trying to move to a different part of the floor.

Manipulating the NavMeshBoundsVolume fixed that, but it created a new problem. In changing the range of the NavMeshBoundsVolume, the Volume now wanted to interact with objects that I didn’t want it to. This led to the events of the following GIF:

Trying to restore the Volume back to how it had been created a new movement problem. Movement wasn’t working at all. I spent the majority of a day trying to fix it until I decided the best course of action was to just rebuild the game, which I then did and was able to avoid all of the above problems, but it was extremely time-consuming.

Another roadblock I’ve ran into with VR development in Unreal is that the VR controller pawn doesn’t work like a character pawn in other Unreal templates nor like any pawns that I’ve created myself from scratch. Essentially, the VR controller pawn doesn’t create solid objects with proper collisions like a normal character pawn does. Most of the development work I’ve done in Unreal (As well as Unity) in the past has been entirely collision based. This has required me to rethink and relearn a lot of development.

Right now, I’m mainly trying to complete my game’s interactions by using these Blueprints.

These Blueprints operate the grab mechanic. I’ve been playing around with it to allow me to “activate” objects in addition to grabbing them. For example, I can grab this purse to add it to my “inventory” and I can grab this door to enter the next level. This allows me to operate most basic game logic despite the lack of proper collisions with the VR Controller pawn. I'm now trying to add variables to this operation. This rough video showcases some of these mechanics: https://youtu.be/7TruacKWJ-E

There have been multiple other issues this week, but they aren't exclusive to the VR side of things. One of those issues was an attempt at cloth physics that did not go as planed. I'm going to revisit that later in following the MOSCOW system by labelling it as a "Could Have". While I definitely want cloth physics working, especially in the clothing store portion of the game, I can't guarantee they'll work at this moment.

Three other issues holding me back this week include work on my group project (I created a procedurally generated game board for that in Unity completely from scratch, but that's not what this blog is about), personal illness (I had the flu all week), and lack of documentation for developing in Unreal. The illness made it hard to work and more uncomfortable than usual to work on a computer all day, especially since I had to attach a screen to my head and move my body around with it, but I got through it.

The more annoying thing about the illness is that I couldn't record any in-game dialogue. While I'm not going to do all of the dialogue myself, the actor situation never panned out since my contact would not reply to my emails. I do have some friends that might help me out, including one who is a professional radio DJ in New York. I can't guarantee their assistance though. Motion Capture acting will have to be entirely done with my girlfriend and a friend of mine, assuming the license I need is renewed.

The documentation issue has made me decide on Unity for the Group Project. Documentation is much, much easier to find for Unity than Unreal. However, I have less experience in Unity. I went with Unreal because I had developed similar first person experience games with the software and I figured that experience would transfer well to VR development. However, as you can see, it's required a lot of relearning. Which wouldn't be so bad, but the documentation for development in Unreal simply isn't as widespread as I'd like.

For this coming week, I'm going to record dialogue, record MoCap data (Hopefully), and build the rest of the levels now that I have level transitioning working fine. Once I have the MoCap data, I should be able to animate characters for the remaining levels. I continue to hope to have the project finished at the end of this month, however, I might edge closer to the Gold Product Deadline than I'd like. This is mostly due to the initial issues with getting software installed pushing my work back weeks.

I'm trying not to stress about this and just get on with my work, but every time something breaks, I lose hours, if not days, of time. That can be very unnerving and discouraging. I worry a lot of the creative side of this project is going to falter because of the technical issues. I'll continue to log development in an effort to properly measure the development process and the time it consumes.