While this brings up the question of collisions, I’ll assume you’re reasoning that out already and skip that part.
I must also resist the natural tendency of this to become a chapter in a book, and cover general notions here.
These parameters deal with linear motion, but take no account of orientation or position in 2D or 3D. It should already seem clear that if you have a displacement, which is a distance, is one of your key calculations. For each slice of time you’re calculating how far something moves, and before it is moved how acceleration is changing the rate at which it is moving.
“t” comes from Unity’s time.deltaTime. Although most physics calculations are put in FixedUpdate, this actually doesn’t apply to you because you’re not using Unity’s physics engine. FixedUpdate is associated with the fixed time step of PhysX, the physics engine under the hood. Your use of time, on the other hand, doesn’t suffer limitations on the time step (it isn’t precisely fixed), and does not require synchronization with PhysX timing cycle, so you can calculate this in Update, saving some calculation power (though, since Time.deltaTime is set by Unity to work the same way in both Update and FixedUpdate, you wouldn’t necessarily see any difference in the results outside of minor accumulated rounding (or truncation) errors, natural to floating point representation of these calculations.
In Unity, velocity is expressed as a Vector3 or Vector2, which expresses, as a result, both the distance moved at a fixed unit rate of time, and the direction of that motion. Although you define u as initial velocity and v as final velocity, it isn’t clear if you’re thinking scalar or vector parameters here. That’s somewhat key, but only in that if your u and v are scalars, they must be applied to a vector representing orientation. If they are vectors, they already have orientation incorporated.
If that puzzles you with regard to, say, u + at (where a and t are scalar floats but u is a vector), the solution is to express at in terms of a vector in the same orientation of u (which assumes the acceleration is always applied in the direction of the object). Where “at” is a scalar, lets say that a * t works out to be something like 0.25. In order to add to a vector u, you need a unit vector of the same orientation as u, then multiply that unit vector by 0.25. What you get is a vector with length of 0.25, while x, y and z values may be whatever is required for that orientation at that length. THAT is a vector that can be added to a vector
There’s less of a puzzle with ut where u is a vector, because vectors can be multiplied by scalars (it merely changes the length of the vector, while the resulting vector is in the same orientation).
For ut + ½at^2, where u is a vector, multiplcation by t produces a vector. However, 1/2at^2 is a scalar. A scalar can’t be added to a vector, so 1/2at^2 must be converted to a vector as described above (multiplied by a vector of the same orientation as u, which is the same orientation after u is multiplied by the scalar t).
This leaves the question, how to create a unit vector in the same orientation as u (or any other vector)? This is called normalization (a math term, not from Unity). A normalized vector (or normal vector) is defined as a vector with a length of 1. Naturally, 1 times anything is…anything (1*a is a), even if it is a vector. In the case of multiplying a unit vector by a scalar, the result is naturally a transformation of that scalar into a vector of the length of the scalar - but the key point for that to be true is that the vector starts out as a unit vector, a length of 1. Two means of doing this are in Vector3 and Vector2.
First, there’s a “normalized” property in Vector3. It ‘creates’ a Vector3 that is a normalized version of the source vector. So,
Vector3 nv = u.normalized;
There is another method, but be careful using it, it modifies the vector you call it on. If I write,
u.Normalize();
I’m telling Vector3 to normalize u, and u is changed as a result (it is no longer the u from your equation, it’s length is changed by this function to 1.0).
None of this deals with an acceleration that is not in the direction the object is already moving in. I’ll leave that up to you for now.