We've been playing around this week with our aiming solution.
How to create an aiming system that effectively uses spatial relationships and 6DOF for positioning.
OUR GAMEPLAY ELEMENTS:
When we developed this game title, we decided against a strictly arcade stylistic gameplay. Instead, we really like what AR can bring to the table - spatial relationships and a more direct tie to our real world. To that end, we opted for a hyper-real style - can we make the gameplay look like something you might see out in the universe? Can we build a gameplay mechanic that the Seed civilizations might have actually implemented, if the technology in fact existed? If we had to defend a planetary system using energized meteors, how would we "realistically" impart those controls onto the rocks and best display that interaction to the system engineer? So "homing meteors" or too much on-screen UI dependencies were all mechanisms that we avoided.
We're creating a game that allows the player to fully roam their spatial environment and interact with the game elements. Unlike many ARKit projects that focus solely on a flat plane game environment, PROJECT XII uses the full volume of your space to position the gamepieces and interactions. We stitch your home planet into your living room - elevated approximately 3 feet off the floor. A colorful nebula lives on your ceiling. During the next minutes of the first chapter, enemy ships are inbound towards the planet from multiple approach vectors & angles. The primary defense mechanism the player uses is firing meteors from the nebula overhead to intersect with the enemy ships at the right place and time in space. This is not a game best played while sitting on the couch. In fact, in order to fire upon the enemy ships, you have to select them, which requires a certain physical proximity to the ship (in terms of where it is placed inside your living room). We couldn't opt for a simple point and shoot.
We've constructed a gravity well around that planet and an accompanying grid system that runs parallel to the floor plane. This grid systems serves the dual purpose of helping to visually establish the attack angle of the incoming enemy ships, but it also provides a positional backdrop against which the player can judge the inbound speeds of the attacking enemies. We're still working out the gravitational effects of the gameplay, but the gravity well in the grid was important for us to help the player get a sense of the physics at play here.
At Heavy Projects, we're unabashed science nerds and love the idea of working real physics into our experiences. We're rationalists, and if we can bring general relativity, string theory, or other advanced science explorations into a popular medium, we're going to do it, dammit. We're using Unity to render our scenes, and Unity's engine has exemplary physics engines built in. So we know (A) the IRL size of the planet in our scene (we assume it's Earth-sized in Chapter 1), (B) the size of the planet in Scene Units (0.4u), and (C) the speed of light relative to a body at rest (299,792 km/sec) - so a meteor travelling at the speed of light (an impossibility) would move approximately 23 planetary diameters per second in our scene. Pushing a meteor to 0.1c or 0.2c gets us to 2.3 or 4.6 planetary diameters per second - a good gameplay mechanic for what we're doing. Additionally, we take into account the increase in relativistic mass of the meteor (the increase in energized momentum required to push the meteor faster and faster, as explained here: https://arxiv.org/pdf/hep-ph/0602037.pdf) as an energy drain on the nebula reflective of the transformational requirements of E=mc2 (i.e. the energy drain on the nebula is not linear but is instead logarithmic towards infinity). In our game, you'll be able to see what 10% the speed of light looks like, relative to a planet in space. Fun!
OUR SOLUTION PROCESS
For those of you who have played with TiltBrush in a VR environment, we initially conceived of an aiming tool that the player could "dab" in space in front of the approaching enemy. The spatial paint dab would indicate a generalized area that the meteor might intersect with, with some margin of error randomization applied as to the final exact intersection point. This proved to be incredibly difficult to play with because the meteor would of course keep moving past and through that dab spot - it wouldn't explode like anti-aircraft ammunition (it could have, but that would have stretched credulity and would have a required a more "smart" energy technology inside the nebula - I mean, come on, let's be real here). And in all honesty, it was simply difficult to play with any solution that imparted a true 6DOF UX. Instead, we opted to fall back on the grid system than initially contemplated. We could use the grid system to eliminate one of the dimensional properties (here, it's the Y-coordinate Height) by (1) for each selected inbound enemy ship, fixing the grid to its approach angle keeping the planet as the fulcrum point, and (2) fixing our aiming crosshairs to the grid. Then the player is only required to focus on 3 dimensions - X & Z coordinates + Time - in order to match up the meteor's arrival with the enemy ship's.
We then added a 2D radar system, to help the player find the inbounds. We kept the planet as the center of the radar, since that is also the central fulcrum of the pivoting grid system. It works well enough for now - we'll improve the radar function in sub-releases. But trust us, at a certain wave of this Chapter - you're going to appreciate any help you can get!
So we now have a new aiming system that is (A) volumetric, (B) grid driven, (C) incorporates real physics, and (D) approaches what a hyper-real system might require, if this were all possible. Good luck playing!