• entries
5
9
• views
6219

Gravity Works

910 views

It's all coming together.

In the past week or 2 I was able to add a black hole to the game. At first, the only consequence of touching the black hole is that you would bounce off of it using the inelastic collision algorithm I finally got working. You would also lose 20 points.

But then I asked some friends to play it and every one of them said the same thing: "Does the black hole suck you in?"

Ok, I need to add gravity.

Thinking back to my physics class in college I remembered that the force of gravity is G times ((m1*m2) / R^2). I already had mass defined for my entities because I needed it to calculate the inelastic collisions (billiard ball bouncing). So I plugged in the gravity calculation and would you believe it, the planets started flowing towards the black hole. WIth a bit of tweaking to the G gravitational constant I was able to make the planets be drawn to the black hole at a force which caused some change to the game mechanics without being too difficult for the user.

So what should happen when the planet touches the black hole now? I added an animation to show your planet being shurnk down to nothing. Your planet then reappears at a new place on the board and it grows back to full size (and you still lose 20 points). But when I was testing it odd things happened. The planet would bounce wildly all over the screen. When I caught a collision with the black hole I had to do the following:

Turn collision handling off for that planet (Check)
Disable player control (Check)
Set the X and Y speed to zero (Check)
Animate the shrinking (Check)
Find a new spot on the screen which is away from the other player and the black hole (Check)
Animate the growing planet (Check)
Enable collision detection (Check)
Enable player control (Check)

So where the hell was the bouncing coming from? It turns out that gravity works. When you touched the black hole the R component (distance between the entities) was very small which made the force of gravity very large. Gravity was literally tossing the planet back and forth across the sky. This was quickly fixed by temporaily turning gravity off for the captured planet while I did the animations and repositioning.

Meanwhile, as I was adding the animation code to both the player entity and the planet entity I found myself copying the same code into two different objects. Any time you see yourself repeating code it's a good sign that you should push that code down into a base class. I see more refactoring in my future. This is another great example of why I'm building a proof of concept project before my main project. You only learn this kind of thing by writing the code and trying things out.

Finally, I made some changes to my OpenAL sound engine so I now share the same sound engine across all my scenes. One of the many benefits of this is that I can have one piece of music play across multiple levels. The sound doesn't restart every time you replay a level.

I think my proof of concept game is nearly done. This entire project was created so I could learn about game loops, double buffering, the update-render-paint loop, image manipulation and other basic game progamming concepts. I've certainly achieved that goal. What I got out of it was a huge learning experience and a fairly fun mini game. I think the next step will be to make the engine handle scrollable tiled backgrounds. Then it's time to move on to building [secret awesome game idea] which spawned this process in the first place.

There are no comments to display.

Create an account

Register a new account