Decommissioned Windows, VR game

Lots of good stuff happened over the past two weeks. Let’s dive in!

Movement system

Last update, I was working on building compartment door interaction into the movement system. And now it works! Sort of…

There’s a few issues still left to handle. One of the main issues I’ve been grappling (ha) with is momentum. If you grab an object while you’re moving in microgravity, you’ll generally keep moving, and likewise, if you’re stationary and grab a moving object, you’ll generally start moving in the direction the object was headed. Of course, this is true for both free-floating objects and those attached to walls by a hinge, like a compartment door. Applying these facts to doors creates a bunch of edge cases that need to be handled.

Here’s what works:

• Grabbing a moving compartment door – In this case, the door is already rotating when you grab it. As you would expect, when the player grabs rotating doors, they move with it. Hooray!
• If the player is grabbing the door handle in one hand, and the other is grabbing and pushing on a wall handle or is pushing on a nearby wall, the door opens.

What sort of works:

• Applying player velocity to the door – There’s really two different cases here, but the issues and underlying causes are the same so I’m combining them. And there’s nothing you can do about it. Anyways, the first is a player in motion grabbing the door handle, and the second is a player grabbing a door and imparting velocity by pushing off of walls or handles with their other hand. This ended up being a tricky piece of math.

Both of these systems work, for the most part. The issue is best explained in a hypothetical, but first an explanation of the hand system is necessary. In the game, there’s a visual model of the player’s hand and a invisible target representing the actual tracked location of the player’s hand. This allows me to do some fudging of the system, for example, when reaching out and grabbing a handle. When the player reaches out to grab a handle, they don’t have to be precise. When the hand determines it is “close enough” to the handle it plays a reach out and grab animation. This way the player's hand is always visually on the handle, even if they're slightly off in reality.

The consequence of this is that the actual position of the player’s hand and the position of their in-game hands are slightly different, at least until the player lets go. In practice, this difference isn’t very noticeable to the player, and it helps playability. Also note here that I’m not doing any rectification of this difference. This would involve shifting the player so that the in-game hand and real hand match positions, which I’m hesitant to do since there’s an increased risk of motion sickness that comes with non-player driven motion.

With all of that said, here’s the issue. If the player grabs a door handle in a way that gives it rotational velocity, either by pushing off of a wall or the player having velocity prior to grabbing the door handle, error builds up in the difference between the player’s hand position and actual position. Rotating in a full 180 degree arc creates a huge difference in position, and it’s really, really obvious and jarring.

So in this case, I think I need to be doing some rectification. I don’t think that it will cause motion sickness issues in this case, since the player is already moving. I’ll gie it a shot and see how it goes

Studio improvements

I’ve had a Windows 10 machine running a file server in the studio (AKA my house) for a while now. This worked, but my needs are starting to grow and I wanted to make some improvements. Here was my to-do list:

• Switch to Linux for faster performance and better server software compatibility
• Increase RAM. I’ve been running the server on 4 gigs of RAM…
• Set up a VPN so I can access my files remotely
• Automated build and deploy architecture. I’ve been a big fan of Jenkins for a while, and wanted to integrate it into my build process for some of the Unity plugins
• Set up Vagrant so I can run my tests in a sandboxed environment

I’m now running a headless Ubuntu distro, and upped the RAM to 8 gigabytes. Still not great in the RAM department but it's a lot better, and I had the RAM laying around from my last PC upgrade so it was essentially free.

I used Docker to set up and run VPN and Jenkins. I like Docker because it makes it really easy to setup and manage different servers on the same machine, without worrying about conflicts between the servers. I’m pretty new to Docker, but I like it so far and am looking for other ways I can use it in my studio.

I still need to install Vagrant, but that’s pretty easy. The only complication may lie in managing Vagrant instances from Jenkins; even though they are technically on the same machine, they are walled off from each other.

Marketing stuff

I plan on showing Decommissioned at RIT’s GDC Prototype/Playtest Night! Come say hi if you’re there! I wanted to pull together some handouts for the event. My plan is to make a small information card and a playtest questionnaire. I went last year, and most of the groups were taking feedback, so I’m stealing the idea.

I think it might be fun to design the handouts like in-universe, NASA-styled postcards commemorating the International Space Station Expedition that takes place in the game. I figure that would be sort-of unique, and I could make multiple variations based on the idea. I’m maybe halfway done with the first one. A draft of the front is the featured image for this dev log, expect a full draft next update! In the mean time, here’s the mission patch I made as part of the post card:

Until next time!

-Mark