koobas.hobune.stream
Problem is outdated
R-Type style movement
Hi there, I'm working on a 2.5D game similar to the game R-Type. In that game, you have a ship which is constantly moving forward through space, though within that space you can move around freely on the vertical and horizontal axis.
So far I've gotten this working, but I don't think this is the way to go about it.
using UnityEngine;
using System.Collections;
public class PlayerMovement : MonoBehaviour
{
[SerializeField]
float maxSpeed;
[SerializeField]
float minSpeed;
private void Start()
{
// move the player forward by default
GetComponent<Rigidbody>().velocity = (transform.forward * minSpeed);
}
void Update()
{
// get current velocity
Vector3 currentSpeed = GetComponent<Rigidbody>().velocity;
//Debug.Log("Player velocity is:" + currentSpeed.z);
// get inputs
float moveHorizontal = Input.GetAxis("Horizontal");
float moveVertical = Input.GetAxis("Vertical");
Vector3 movement = new Vector3(0.0f, moveVertical, moveHorizontal);
// use inputs to modify velocity
if (moveHorizontal != 0 && currentSpeed.z >= minSpeed && currentSpeed.z <= maxSpeed) //is the player pressing forward and moving within it's limit?
{
GetComponent<Rigidbody>().AddForce(0.0f, 0.0f , movement.z * maxSpeed);
}
if (currentSpeed.z < minSpeed) // if the current speed tries to go below minSpeed, reset it.
{
GetComponent<Rigidbody>().velocity = (transform.forward * minSpeed);
}
if (currentSpeed.z > maxSpeed) // if the current speed tries to go above maxSpeed, reset it.
{
GetComponent<Rigidbody>().velocity = (transform.forward * maxSpeed);
}
if (moveVertical != 0) // is the player moving up/down
{
GetComponent<Rigidbody>().transform.Translate(new Vector3(0.0f, movement.y, 0.0f));
}
}
}
I just feel like I'm missing something here... I just need the player to constantly move forward on the Z axis, but allow the player to move forward and backward within set limits.
Another way I was able to tackle this was via moving the world along -Z faster than the player could move backwards. Not a good option as far as I can tell.
The use of Rigidbody and physics-based movement in general here seems problematic.
Cosmetically, constantly getting the Rigidbody component for your object every Update() isn't typically required.
$$anonymous$$anually setting velocity doesn't always produce the result you'd expect (consider using .AddForce() with the appropriate Force$$anonymous$$ode ins$$anonymous$$d).
On top of manually setting velocity, you are also translating during the same call.
The reasons for #2 and #3 are because the physics calculations are done in concert with FixedUpdate(), so any physical interactions will be suspended until that cycle. With all of this being done in Update(), you may run into odd behavior.
