I like the idea of doing it head-on more than from the side. But in terms of ease of programming, doing it top view from the side is definitely easier. Would it be as fun? *shrug* Personally, I would program it with a power gauge & maybe a spin gauge like you would see in a typical golf or bowling video game not on the Wii. Oh, and I would have the ball follow the mouse, not the keyboard necessarily. Whatever. But you would want the height of the ball on the screen to be a factor, as well as the power of the player's throw to be a factor. The power meter is the classic method for handling the power of a throw, but alternatives in the past have been the speed of a controller (e.g. trackball rotation speed, or mouse speed). Ball spin isn't much of a factor in kerby, but it's something I'm sure some child has had to deal with in the game at some point in history. LOL
If you were doing a head-on version, you would need to factor in z depth. That means you would need to learn how to code with 3D concepts. You don't necessarily need render in 3D, although arguably it might make things easier, but even a 2d-rendered game would need 3D concepts. I mean, your proposal could be made on an Amstrad.
If you did head on perspective, you would need a variable (z would be a good name) to keep track of how far from the curb (sorry, US spelling here) the ball is. That would be a good variable to randomize slightly as well. Rather than having a 50/50 chance to hit the curb, you can simply have a bunch of a variables with slight random variations to them which would still take away a little bit of the control of the player, but not so much that they would ever feel cheated. Because let's face it, if you are running after a ball and real life, you are not going to be throwing from the exact same position time after time. If you are a human, you are not going to be throwing with the exact same power time after time. However, that does not mean your position or power are randomly decided, they are decided based on your particular actions. Anyway, you would need a variable for the power meter. And you would also need a height map for the curb, although this could just be a simple algorithm for calculating the height of the curb rather than an actual array of values.
You don't really need any trigonometry for this unless you did decide to add spin. At its most basic core, you just need the height of the ball, the z depth of the ball, the velocity of the mouse or the power meter level, and gravity. Using elementary physics: the z depth would change based on power level or mouse
vertical velocity. The vertical velocity of the ball would increase by gravity every step, causing the ball to fall faster. You can either add spin to the ball based on the horizontal velocity of the mouse, or you could utilize the horizontal velocity of the mouse to modify the vertical velocity of the ball, such as if the mouse veers left or right, you add that horizontal velocity to the vertical velocity of the ball. Then every step after the ball has been released you add the vertical velocity of the ball to its y coordinate, then take the z-depth and use that to find the height of the curb, then compare that value to the height of the ball. If the height of the ball is greater than the height of the curb, you know the ball has hit the curb, or maybe the sidewalk, or maybe the road. The z depth will let you know if at the time of hitting the curb the ball was actually still in the road, or overshot onto the sidewalk, or hit the curb exactly. Handling the bounce back is a whole other story. Again, you could use the horizontal velocity of the mouse when the ball was thrown determine which direction the ball will bounce back. For example, if the player accidentally swipes the mouse toward the right a teensy bit, the ball will bounce back to the right a little bit; if the player swipes the mouse toward the left by a lot, the ball could bounce back to the left by a lot more. Up to you.
Velocity, in case you don't know, is the change in position over time. So a vertical velocity is the change in y values over a particular time and a horizontal velocity is a change in x values over time. Thus the velocity of the mouse would be the change in mouse_x or mouse_y over time. personally, the way I would handle the time is wait for the player to click the mouse button and save the current position of the mouse to two variables (oldmouse_x and oldmouse_y). Then every step if the mouse button is down check if mouse_y is greater than oldmouse_y; if it is, set oldmouse_y to mouse_y and oldmouse_x to mouse_x; else if mouse_y is less than oldmouse_y, set an alarm to room_speed/4 (quarter second, might need to tweak this though). In the alarm event, subtract mouse_y from oldmouse_y and mouse_x from oldmouse_x to find the distances the mouse traveled within that time window, then divide those distances by room_speed/4 and you now have your vectors for the mouse movement.