Howdy. I’m attempting to create a gravity-free FPS where the character is free-floating and rotation is applied entirely to the physical player object (as opposed to only applying tilt to the camera as in the original FPS prefab object). If you’re having trouble understanding, I’m basically making a descent (or forsaken if you prefer) clone.
I’ve managed to screw around with the mouselook and FPSwalker scripts enough to accomplish this (sort of).
My problem is that in a game of this type being able to move in six directions relative to the player’s rotation is extremely important.
Right now I’m just trying to get the upwards motion to work correctly. My modified script is still using the old prefab’s jump code because I haven’t figured out how to properly modify it. This is a problem because hitting the jump button causes the ship to move up relative to the game world instead of relative to the player. So if the player is looking up and hits the jump button, it does pretty much the same thing as if the player were to hit the forward button. If teh player is looking down, it does the same as the backwards button. You get the idea.
I’m used to using blender for game editing. In blender, fixing this problem would simply be a matter of setting movement to be local instead of global. Unity does not provide such an easy fix, however, and I’m trying to figure out which of unity’s mathematical functions to use and, more importantly, HOW to use them to solve this problem.
I think a key is the movedirection vector in the FPSwalker script. It uses input.getAxis to retrieve the character’s rotation about the global y axis by setting the x component of moveDirection to input.getAxis(“Horizontal”) and the z component to input.getAxis(“Vertical”). If there were a way to use getAxis for the y component this wouldn’t be a problem. However the documentation makes no mention of such a possibility, so I’m clueless as to how to achieve this.
Another problem I’ll eventually need to solve is to allow the character to rotate around the local z axis - this will make it so that the character isn’t always artificially aligned with the global x-axis in such a way that its local x-axis and the global x-axis are always parallel. This is a problem I’ll save for later, though. It ought to pretty much solve itself if I can get my original problem figured out anyway.
Thanks in advance to anyone who can help!
Welp, I’m a fool.
I figured out the jump problem. Its simply a matter of moving the code that applies the jump to the movement so that it’s before the transform.transformDirection() line, which I now gather is where the code makes the movement relative to local axes rather than global axes.
I was also wrong about figuring this out solving the rotation problem.
I took a look at the mouselook script. I can’t for the life of me understand why the rotation that makes teh character look up or down is local while the rotation to make it look side-to-side is done globally (thus creating the problem I have where turning is always done relative to the global y-axis instead of the character’s local y-axis.) I’ve looked at the code pretty closely and the code for both the horizontal and vertical rotation appears to be identical.
I must be missing something.
There’s also another minor issue. Because my “jump” movement is not using a getAxis statement, Unity isn’t applying any smoothing to the upwards motion. When the character moves forward or backward or strafes left or right, unity smooths the motion, giving the appearance that the character has inertia. When I jump however, the movement starts and stops abruptly.
For the sake of uniformity I could use getAxisRaw to make ALL movement abrupt like this - but I would much prefer to have all movement be smooth instead. Will I have to program my own smoothing code for the y axis movement using delta time or some such thing?
The script implements typical FPS-style motion using (essentially) a pair of Euler angles. Each update, the orientation is re-created from scratch. Ignoring the ‘original rotation’ part (which doesn’t really change anything), a rotation about the world ‘side’ axis is applied, then a rotation about the world ‘up’ axis. This has the perceived effect of pitch being local and yaw being global (which is usually what you want for FPS-style motion).
For true 6DOF motion (which is what I gather you’re trying to do), a different approach has to be taken. Instead of creating the orientation from scratch each update, you instead modify the current orientation using local-axis rotations.
I imagine this has been covered previously on the forums, but I didn’t find anything with my quick search. If you check out this thread though, you can find some code I posted that shows how to handle the rotation part (note that the code was just typed into the post, and is untested).
For linear motion, you’ll probably want to move along the ‘side’, ‘up’, and ‘forward’ vectors associated with the transform. I’m not quite sure what type of movement scheme you’re trying to implement (it’s not quite clear to me how the concept of ‘jumping’ would fit into the Descent movement scheme), but if you get stuck on that aspect of things, I’m sure someone will be able to help out.
Thanks for trying to help Jesse.
I actually solved most of my problems with some more tinkering and experimentation. Using transform.rotate() and providing a rotation vector (as opposed to using transform.rotation =) made the turning work correctly.
I still have the jump problem though. What I meant by jump, by the way, was simply moving upwards along the local y-axis - whatever you’d call that motion in descent or similar games that roughly corresponds to jumping in a standard FPS.
The problem is that there is no smoothing. the input.getAxis() command automatically applies smoothing to movement along the local x and z axes. However there is no way to input.getAxis() for the y axis. So when my character moves forwards, backwards, left, or right, the character accelerates for a short period of time when the movement key is pressed, and quickly decelerates when it is no longer pressed. For upwards motion, however, movement instantaneously jumps from zero to full-speed, and when the button is no longer pressed the ship instantly stops moving, giving the sense that the ship’s upwards movement is not bound by the laws of physics
I just now figured out how to edit the input settings and axes. I modified the “jump” axis a smidge, used it in my code for up/down motion,and SPLAZZ! works like a charm.