You either need to create multiple images for each animation, or use another tool to create this specific type of animation for you.
If you create the images yourself, each image of the animation is called a frame, and you'll need to create as many frames as there are changes in the graphics. You then need to, in code, drive that animation (by telling the object which image it should be using, based on e.g. elapsed time, or something else).
(Note that the different frames can be either 1 image per frame, or 1 big image containing all the frames in the animation.)
There are also certain changes you can do directly in Unity with a single graphic -- scaling and rotating spring to mind.
If you choose to use a different tool to create the animations, check out Spine. I'm not entirely familiar with the details of it, but it can be used in Unity and seems to fit the animation style you mentioned.
Maybe I should have gpogled my question
Yes, you should. If you want to make a game, you can't be too lazy to do a bit of research on your own. Especially given how just putting your subject into Google brings up quite a lot of relevant hits.
Would anyone be interested in helping to build the game?
Recruiting goes in the Classifieds section of the forums, not here.
If it were as simple as you say, then games wouldn't take as long (and require as many people) as they do. It doesn't matter how smart you are (or think you are), games are a lot more work than you give them credit for. Multiplayer games even more so. MMOs even more so, much much more than you believe.
Can you give any reasonably explanation as to why similar games have development times measured in years, with production teams measured in tens of people, if it were as easy as you think it is?
Unity will not be enough. Once you have all the assets you need, you can use Unity to put them together and make them do as you want, but in order to create and potentially process/adjust all the assets (images, sounds, etc etc), you will need other software (e.g. Gimp, as was mentioned).
you only need a solid 15 fps to be sufficiently responsive to be playable. once you hit 30 or so, your animation is smooth and your responsiveness is quite snappy. anything more is just smoother animation eye candy. turns out that lower framerates (within reason) aren't bad, variable frames rates are bad.
This reads like an absolute truth, but it isn't; it depends wildly on the game. While the games you make might be fully playable at lower framerates (and might also thus be what you're accustomed to), it does not mean that translates to every other game/genre.
For fighting and racing games in particular, higher framerates are easily noticable, far above 30 frames per second.
For a chess game without fancy movements/animations, 2 frames per second would probably still be playable (although possibly somewhat annoying with selection latency).
I can't think of a single instance where a higher frame rate would lead to a worse product, but I can definitely think of the inverse.
For VR games/applications, what is considered to be usable is also much much higher, although not for the same reasons.
That said, I definitely agree with constant frame rates being very important. Companies are also starting to catch on to this, e.g. by offering optional frame rate limiters if the frame rate varies, and even in some cases options for whether graphics quality or frame rate is to be prioritized (both of which, for console games, are a fairly huge change to the status quo).
There are some mistakes in your conversion (notably: "t" without a number is not currentDeltaTime, it is the time at which the collision occurs). Your current code would always have k = 1*.
The magic f is just a variable that exists solely to ensure that a line segment is output instead of an infinite line.
However, I still have a feeling this is a lot more complicated than it probably needs to be.
*or divide by zero if currentDeltaTime and prevDeltaTime were equal.
While there might be edge cases where the following is not true, I would imagine this would work in most simple cases involving linear motion, and it should be fairly quick to implement/test:
Keep track of the ball's previous position (i.e. last frame's position) and the paddle's previous position, and whether a collision occurred in the previous frame.
If an intersection occurs, and there was no intersection in the previous frame, compare the positions of the paddle and the ball in the previous frame.
If the ball was to the left of the paddle in the previous frame, collision occurred on the left side of the paddle. Conversely, if the ball was to the right of the paddle before the collision occured, collision occured on the right side of the paddle.
While I don't immediately see the error, you could try doing the Debug.Draw in different colors based on i to see if it's always the same ray that's messing up, and then Debug print values for that specific ray and see if anything becomes apparent.
In the VerticalCollisions I was slightly surprised to see velocity.x used, but I guess it makes sense for movement collision? (Although HorizontalCollisions doesn't do the equivalent.)