24 Nov 2014
November 2014 - Delta g Arena
unityfpsgravityjam7dfpsdigital
Skip to the Game

Well the 7DFPS has come again, and that means it's time for me to make another shooter that isn't about shooting people, like the dirty mostly-non-violent game maker I am. I'd been thinking about revisiting one of my first 1GAM projects, delta g, and seeing how I'd implement it now after nearly two years of progress. When 7DFPS came around again, I decided that would be a good time to try to put together something using the same basic concept of changing gravity on the fly to traverse obstacles, but now in a 3D first-person environment.

This turned out to be a non-trivial proposition, but I ended up with something simple but entirely playable before the jam clock ran out, which I called Delta g Arena.

Down is Overrated

The basic idea is similar to the original delta g &emdash; you're a technician attempting to get approved for work in zero gravity environments, which requires proficiency with a gravity suit, which can be recalibrated to an external frame of reference and will generate a false gravity force in that direction, essentially making the calibrated surface into the new "down." The first game was a set of puzzles that had to be solved to demonstrate proficiency in a controlled environment. In Delta g Arena, you have a more straightforward task which is much more dangerous; you must demonstrate your ability to navigate between detached surfaces in different orientations quickly and efficiency, without accidentally flinging yourself into the void. Some of the platforms will periodically active and glow, and if you manage to ground yourself on an active platform, your timer in the arena is extended. Your objective is to last as long as possible in the arena without your timer running out, and without leaving the bounds of the arena.

In addition, where the first game also gave the player the ability to create arbitrary force areas, which propel the player in a chosen direction when entered, and time zones that speed up and slow down time, this time the player's only other ability is a gravity tether, which can be used to create an ad hoc force of attraction toward an arbitrary surface when fired. The player can use this to propel themselves around the arena, or to rescue themselves from a mistake, but it has a limited amount of power which regenerates over time, so it can't be relied on as the primary means of navigation.

As usual, the soundtrack is courtesy of Ben Freund. It's a simple enough game in terms of the activity and objective, since the only goal is to keep playing as long as possible, and I would've liked to add more but the gravity system ended up taking up a lot more time than I would have liked.

Flipping and Spinning

In the end, the rotations and movements involved required a somewhat elaborate control rig, but once I got it sorted out conceptually, it worked almost exactly as I'd hoped. The system has four structural levels:

Avatar
The primary logical object of the player entity. The collision and physics code happen at this level, and the player uses a spherical collider to prevent any oddities caused by rotating an irregular collider while touching other colliders. This makes collision detection a little slippery at platform edges, and given more than a week I would likely have worked on making sure a better collider would work.
Body
The physical representation of the player body, which rotates to orient the player's feet toward the current "down" vector. The visual representation of the player would be here, and was during development, but wasn't needed in the game.
Head
The player's head, which rotates with the player's mouse X input. This separation allows a clean distinction between the body's rotation, which is smoothed to prevent the gravity switches from being jarring and to make the game feel more real, and the player's mouselook input which needs to continue independent of the body rotation. All calculations that involve the player's sight line use the head's position and rotation as their basis.
Eye
The player's eye, which is the point the camera attaches to and which rotates with the player's mouse Y input. This allows normal mouselook input on the Y axis without interfering with either the body or the head's orientation. The player's idea of what is up, down, forward, etc. is most easily understood when mouselooking up and down has no effect on those considerations.

On the off chance anyone is ever trying to solve the problem of how to rotate a player when changing their gravity, which means you've discovered the issue of having the player's look rotation and their body rotation causing unexpected quarter- and half-turns in the air, the magic formula is to first snap the body's rotation to the player's look rotation while zeroing out the look rotation, so there's no visible change but the player's body actually matches their sight line, then set your body's target rotation so that (1) your new look vector is your old up vector and (2) your new down vector is your old forward vector. In hopefully more easily-digestable terms, if you're standing on the floor of the room you're in and want to walk up the wall, your new look direction is your old up, i.e. you're looking at the ceiling now, and your new down is your old forward, because you're now standing on the thing you were looking at before. That probably sounds like gibberish unless it's something you're working on, but it was some hard won knowledge so I thought I'd include it just in case.

The Verdict

As is usually the case with a jam game, I had a lot more planned if time permitted, but it did not. That said, I'm still pretty happy. The gravity system was really the big challenge, and it ended up working pretty smoothly, and the game was playable and got some good feedback. Considering I was also trying to finish NaNoWriMo while having a job and a family and all that business, I think it shaped up nicely.