In Decommissioned, you play as the last astronaut to visit the International Space Station, charged with successfully ending the station's 26 year mission by deorbiting the space station into the Indian Ocean. After powering down the station's aging systems and prepping to leave, a catastrophic failure disables your only means of escape. Now - with your oxygen failing and your orbit plunging deeper into the Earth's atmosphere, you must find a way to repair and bring back online the systems that once kept you alive, and finally make it back home.

  • View media
  • View media
  • View media
  • View media
  • View media
  • View media
Post article RSS Articles

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:

Expedition 79 Mission Patch

Until next time!

-Mark

 Decommissioned dev log 1/21/2017

Decommissioned dev log 1/21/2017

News

Work on the movement/interaction system has taken up most of the week. In the game, I want the player to be able to open compartments, open hatches and...

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Follow Report Profile
Icon
Decommissioned
Platforms
Windows, VR
Developer
ABXY Games
Engine
Unity
Contact
Send Message
Release date
Game watch
Follow
Share
Style
Genre
Adventure
Theme
Survival
Players
Single Player
Project
Indie
Play With
HTC Vive
HTC Vive HTC Headset
Twitter

Latest tweets from @mark_at_abxy

RT @tha_rami: A good thread for creatives in general. T.co

May 12 2017

Who let the spam bots out today?

May 8 2017

100 emails in 4 hours. Proof that JIRA is the world's greatest spam machine

Apr 27 2017

If creative cloud could go one month without breaking, that would be nice

Apr 21 2017

It's Wednesday, and react.js is now a #VR platform. What is happening?

Apr 19 2017

AAAND we're back

Apr 17 2017

It's weird

Apr 17 2017

Embed Buttons
Link to Decommissioned by selecting a button and using the embed code provided more...
Decommissioned
Statistics
Last Update
Watchers
6 members
Articles
2
You may also like
Animallica
Animallica Adventure
VRZ : Torment
VRZ : Torment Adventure
Endeavour
Endeavour Adventure
NOME
NOME Adventure