This is first in a four part series, describing the evolution of the aiming mechanic in Minecart Basketball.
This is the earliest point where I had something that could be considered “launching a ball”. There’s no audio, and nothing for the balls to DO besides collide with each other and roll off the stage.
[WP_UnityObject src=”https://beanalby.net/blog/wp-content/uploads/2013/07/aimIn3D-1.unity3d” width=”960″ height=”600″/]
The ball is regulation size with respect to the physics system, as is the basketball rims and backboards that we’ll see in later stages and the game itself. I very much wanted this motion of the basketball to feel right, instead of feeling like a ping pong ball wearing a disguise.
What It Does Right
The work that went into this was all about the trajectory prediction – based on a given angle and power, it figures out the path that a launched ball will take and uses the white Line Renderer to visualize the path. Moving the mouse adjusts the horizontal and vertical angle, and W/S adjust the shot power.
What It Does Wrong
This serves as an example of why we can’t just show a 3D world in a 2D display with no further considerations. The white projection intersecting with the ground lets us know where the ball will land, but the rest of the line is largely useless. We can’t tell where it’s pointing.
The balls do move away from the cannon as they should, but there’s no depth cues or context anywhere. It’s incredibly difficult to tell how fast the balls are moving away from the cannon (if at all). As a ball is moving, we can’t tell when how high it is, or when it will hit the ground and bounce. Once the ball settles on the ground, it’s not clear whether it’s touching the surface, or hovering over it.
There’s not much good to say about this stage, but it serves as a backdrop for the next article where we discuss the steps made to improve the setup.