Pong rebound algorithm advice

1

Hi all,

I’m sure this topic has been done to death, but I’m hoping to approach it in a slightly different way. Admin, please feel free to move this if it’s in the wrong place (go easy on me, I’m new to the community).

Quick introduction; I’ve been a commercial PHP developer for many years now, but always wanted to try my hand at game development. A friend pointed me towards Monogame and the rest is obvious.

Anyway, to the topic at hand. I have (as I’m sure everyone new to game development does) created a basic PONG clone. I’ve got a core gameplay working (2 paddles, simple AI, rebounds using Vectro2.Reflect(), etc.) but I’m not at that awkward stage of trying to make it more playable by tweaking the rebound algorithm so that it’s not just a standard rebound.

I’ve tried several methods including “faking” the shape of the paddle (to be more round), manually “forcing” the rebound vector depending on the collision site on the paddle and manipulating the reflection vector depending on the direction the paddle was travelling. The code I’ve written for these methods may not be pretty, but it “works” and I understand it.

My problem now is that I can’t seem to find method (or combination of methods) that makes for a good game. They all still feel a bit rubbish in terms of actually making a playable game. I was hoping that other ex-newbies might be able to offer me some advice as to what worked for them. I’m not really looking for code samples… more ideas and concepts. I’d really like to be “happy” with this game before I move on to more complex things.

Please help; All advice welcomed. Or just say “Hi”. Would be nice to get to know people :slightly_smiling:

2

Hi, welcome to MonoGame community.

No not everyone has created a basic Pong close :innocent:

You first and (most important) issue is the tittle which is miles away from your concern.
Then, what you’re looking for is called I guess “game design” itself with a little taste of programming.

I mean, games are a set of basic/technical things, mixed with a great deal of talent to make the basic fun and hopefully addictive.

Look at match3 games, compare some with Gummy Drop! and you’ll get part of what you’re looking for.

Regarding the programming thing, compare Cannon Fodder (Sensible Software) with Theatre of Death (Psygnosis).
The later is a poor attempt to catch up with the former, with very poor coding and some art too, both are action game, Cannon Fodder was quite fun with a lot’s of humour stuff. If you could, try both on an Amiga emulator (WinUAE), and you’ll really feel what I mean.
It’s about making game without noticeable, or none at all, technical issues, with a smooth gameplay, very well done input management, display, sounds, etc all well in sync. Hard to really explain by words.

So so so, to give you quite an answer, you’ll have to think, play some similar game, imagine what could be fun or not, experiment, share your prototype maybe, etc
Currently, a great paradigm is role playing style: you get experience and money, you can buy stuff, unlock stuff (more bonus, more firepower, etc), progress through a story which make a campaign, but it’s not always needed, fortunately, as games like Fairway Solitaire or Avalon Solitaire shows.
What you can do is adding bonus/malus like Arkanoid and its clones (faster/slower ball, wider/smaller pad, obstacles, “blackholes” which catch ball and put it somewhere else).

3

Hi @InfiniteProductions, thanks for the welcome.

Sorry, I wrote the post in a bit of a rush before I left work. I guess I could have been a bit more specific :wink:

Thanks for the advice. I did try to play some other pong clones, but wasn’t really able to nail down what they were doing differently. But I will certianly look at the ones you suggested. I’ll also look at getting an emulator and try loading up some old (well known) pong clones.

At this stage, I’m less concerned with making a polished Pong product (although I am liking your idea for adding thing’s like power-ups and such). I guess I really just want to be able to say “I am happy with the basic design and structure of this clone” before I move on to something else. The rebounding is just the last thing I’m not fully happy with, and was hoping that someone else might have faced similar niggles when they started out and might be able to share their experiences. It doesn’t have to be super-fun (it’s just a basic pong game, after all), but slightly more interesting than 45 degree rebounds all the time :wink:

I’ll share my prototype once I leave how to actually build it properly (but that’s a topic for another day) :slightly_smiling:

4

What you can do is define a point behind te paddle (in a fixed position relative to the paddle and when the ball collides with the paddle, find the intersection point and mirror the balls velocity around the vector from the point to the intersection point. Hope that makes sense like that. If not I’ll make a drawing when I get on my laptop :slight_smile: If you do it like this the player will have more control over the path of the ball!

5

Hi @Jjagg,

Yeah, I think see what you’re getting at. So if the point was in the middle of the paddle (behind it), I’d image a straight line from that fixed point to the intersection point on the paddle and send the ball back along that vector? (tried to draw in ASCII and failed miserably)

6

Kind of, but instead of taking that vector directly if you mirror the velocity vector of the ball over that vector it makes more sense. I think there’s a reflect function in Vector2 that could help you figure it out. Let me know if you need some pointers :smiley:

7

You can tweak the distance of the point to the paddle till it feels just right.

This drawing should clarify. You can reflect the green vector over the brown one to get the resulting vector. I think if you use Vector2.Reflect you should make sure the brown one is normalized.

8

Yeah, I used the Vector2.Reflect() initially when I was learning about vectors and such. To get the “standard” bound, I was creating a normalised vector perpendicular to the paddle (1, 0) and reflecting over that (which gave the same outcome as just inverting the vX).

It makes more sense now you’ve drawn it. The only thing I worry about is when it hits the bottom (or top) of the paddle., the “brown” vector would be much steeper and you could run the risk of the reflection being way too steep (almost 180 degree), resulting in a ball that just bounces up and down. Or am I overthinking it?

I dealt with it in my last iteration by having a min and max rebound “angle” (had all manner of crazy functions for converting vectors to angles and back) and I would manually prevent the reflection vector’s “angle” from going outside the min/max bounds.

9

I think if you don’t put the point too close to the paddle it’ll be alright, but you can definitely try clamping the reflection vector angle too. Also the steeper the angle, the harder it gets, so it’ll probably solve itself.

10

Thanks @Jjagg, I’ll give it a try and let you know how I get on :smiley:

1 Like
11

Hello!

I did a brick breaker, (solo pong?)

I simply did this:

When the ball hits the paddle, distance from center of paddle = angle variance in bounce…

That way, you can specify direction of ball by where on the paddle you strike it…

You could use RANGES, rather than specific values, so its easier to control…

12

You could also add a Scale variable.

for example you first calculate the return angle that you have based on the paddle and ball postions
next you could do this
retunAngle = MathHelper.Clamp(returnAngle * scale, -MathHelper.TwoPi * .8f, MathHelper.TwoPi * .8f);

The clamp function with give you from a 144 degree variation on your return angle (ie -72 to 72) meaning you cant have angles that would break the game.

The scale variable could be anything you want. Realistically from like .7f to 1.4f.
It would allow you to modify the return angle quickly and easy to something that you want.

13

Like the above poster - when I worked on a ‘breakout’ style game I found the most playable results were to ignore the incoming angle altogether and send the ball back at an angle based on the distance from the centre of the bat when hit.

It’s not ‘realistic’ but it makes sense in the game context and avoids the player getting stuck in situations where the ball is always bouncing at a really steep angle.