The Movement Controller

Initially HeavenX used an off the shelf movement controller. It was good enough to get a prototype off the ground, and carry us through multiple playtests. For many games that's good enough, but, for us, the longer we used it the more friction it caused. There was a whole laundry list of problems. The movement controller tried to be an entire framework, so it was bloated and forced developers to do things its way. Sometimes it completely forgot its config values. Worst of all it was nearly impossible to reason about; for example if you wanted to set the jump height to a specific amount you'd just have to plug in values, test the jump, and adjust based on how high the jump actually was. (For any game devs reading this, their physics code was dividing by delta time instead of multiplying. Your guess how that still worked is as good as mine.) So we were insane sensible and decided to write our own movement controller. A handful of games were thrown out as inspiration, (Half-Life, Titanfall, Doom, etc.) and they all had one thing in common: they grew out of the Quake engine and shared the same underlying movement code.

The Quake gif was too big to upload so here is a CS bhop clip. The path forward was obvious. Specifically, our new movement controller is based off of Half-Life 2. (Shoutout to Jiangwei Chong's excellent Half-Life Physics Reference and to the Half-Life 2 TAS community in general. https://www.jwchong.com/hl/) It's not one-to-one, but the physics involved are roughly the same, and yes that means that with the right loadout you can bhop. For a long time we've been planning on expanding on the HeavenX map, and the movement controller is prepared for it. Sliding now has a satisfying momentum to it. 

Pictured: How friction works. 

Over the speed cap there's exponential friction to bring you down to a reasonable speed. Below that is linear friction to help with stopping and turning. Too slow and you stop completely. We've added in wall running and jumping. There's potential for moving platforms, conveyer belts, and launch pads. All of it flows together, and can be affected by your loadout.

The Office

We've been making slow but consistent progress on bringing the office to life. Work has just wrapped up on making the in game computer actually function as a computer. A chunk of that work was wrangling Unity's UI system to put it behind a virtual screen, and the rest was all focused on lighting and shaders. There are a lot of great people out there making content about shaders, and Unity's Shader Graph is a massive help for simple things.

However, one step off the beaten path, and you're in the wilderness. I cannot understate how much of a behemoth the graphics pipeline is if you're inexperienced with it. (Shoutout to Ben Golus (bgolus). Time and again I've looked up some obscure issue and seen his name next to the solution. https://discussions.unity.com/u/bgolus/summary) We briefly touched on it in the second dev log, but CRT's, it turns out, are one of the many game dev problems that sound easy but are fairly complex. We wanted realism, so there was a lot to implement:

• Individual pixels
• Scanlines
• Several kinds of white noise
• Several kinds of distortions
• Dust and grime on the screen
• Vignetting
• Degaussing effect
• Screen Lighting

All of that configurable so players can adjust or even turn off the effects.

-Jake, Programming Lead