Pong

Hey everyone,
I've been bouncing this idea around in my head, so I've finally decided to ask: how would I go about making a pong game? For instance, how do I make the actual ball bounce off the walls and detect if the paddle is there to hit it? If someone could give me a head start or some ideas on how to create this, that'd be great.

-Smithy

You could make it work with physics, but it would be mostly unreliable and easily abused. Other than that, the only real way to do it without physics is to constantly move the ball and check to see if it's past a certain point, as well as keep track of its angle, etc.

Edit: It may be possible to have the ball as a tiny dot on a texture and animate the texture back and forth when you calculate it's past the correct point, but I don't know how reliable that would be in comparison. I might end up trying that for a different game I'm working on.

I tried to make a breakout game and used physics on the ball which didn't really work. Even with setting buoyancy to 1.0 (which should make the ball «float»), the ball behaved odd.

Constantly updating the position doesn't really look good, either. The idea with the texture is nice, but then you lose the hit-detector and you would have to calculate the borders (which isn't _that_ handy. Using the hit-detector would be much easier). Plus, changing the texture (llSetTexture, llSetPrimitiveParams) delays the script by 0.2 seconds, which makes the movement uneven, I think.

What you could try is, to lay your game flat on the ground. That way, the ball can't fall down and all you have to do is control the x and y axles. Downside is, that people would have to move the camera above the game to play it, which isn't _that_ fancy... If you try this, set the ball's and surface's material to «glass» which has the least friction and thus the movement should look pretty constant...

Thanks for all the replies, as I am considering having the game flat on the ground. But can someone give me a start on how to calculate the angels of which the ball will follow?

A pong game has been done in sl.
2 people sit in 2 vehicles and a ball is added.

First, you'd set the local rotation to false with:

llSetStatus(STATUS_ROTATE_X | STATUS_ROTATE_Y | STATUS_ROTATE_Z, FALSE);

If you don't do this, your ball will tumble while moving, mixing up the local axles.

Then you apply a force:

float mass = llGetMass(); // mass of this object

x = 10; // to overcome gravity, you have to apply at least 9.8
y = 10;

// this will make the ball go straight - use different numbers for x and y to make it move diagonally

Then you apply a force (rather than making it move to a specific vector, as llMoveToTarget() would do):

llSetForce(mass * <x,y,0>, TRUE); // move it along local x/y axles

When the ball hits a wall, you simply reverse x and y;

x *= -1;
y *= -1;

... uhm - at least I guess it works that way

If I understand correctly, this would cause the ball to "bounce" back in exactly the same direction it struck the wall from. What you really want it to do it bounce at a "mirrored" angle. Hence, if it hits a "vertical" wall (i.e. a paddle, in the classic Pong layout), you'd invert the x value. If it hits a "horizontal" wall, invert the y value.

However, this will just keep the ball bouncing off the walls and paddles at exactly the same angles all the time, which makes the game too predictable. You'd need to alter the vectors based on the velocity of the paddle at the time of "impact" (effectively, but not literally, imparting some "spin" on the ball).

Sorry - totally forgot that part... sure, you're right Deanna...

What might be nice as well is, that the ball gets a different speed depending on where it hits the paddle. As we can't determine the hit-point on a prim, this could be made with a paddle that's made out of smaller prims...

Could be inferred, in this limited instance, by measuring the distance between ball and paddle at the moment of collision.

You could see how far out it was from the center of the object at the time of the collision.

Is there an echo in here?

Even better: Take the dot product of the normalized ball-paddle vector and the straight-up unit vector. This tells you not only how far from center the impact point was, but also on which end of the paddle. i.e. a zero result would be dead-center, positive would be high, negative would be low.

uhm... you guys are into math, aren't you?

I'd simply make a paddle out of like 5 prims and set the speed according to which part of the paddle was hit... that way it's pretty simple to determine a) the speed and b) the direction the ball has to go back (because when the ball comes from the bottom and hits the lower end of the paddle, it should go back down)...

Not as elegant as your solution, but it would do the job and what's even better, my head wouldn't explode

Chapeau, Deanna, I'd never come up with a solution like that (no sarcasm/irony here!)