So, for the past couple of days I've been slacking on getting Pong-Karuga done. Being sick (sore throat, headache, runny nose, coughing) didn't really help my case either. So now that I'm back on the job I've got a bit more to share.
Unfortunately there are still no sprites or any cool effects put into the game yet, but I'd rather make the game work and have the all of the systems down before I try and get all fancy with the other stuff.
A few days ago one of my Classmates and I worked together on getting a really basic physics engine into the game. It's not using gravity or anything like that, but the velocity of the ball is based around time rather than how fast your processor is. Here's a little explanation to help understand what I'm talking about...
My Pong has 3 main functions (which end up calling a bunch of other smaller functions), GetInput, Simulate, and Render. The GetInput function checks to see if a key is held down. The simulate function handles the moving of the Ball and the calculations for the AI. And the Render function paints the whole thing to the screen. The way movement was originally handled was based on two things, an increment and a sleep.
The Sleep function basically tells the program to stop doing anything for the specified amount of time. The problem with this is that the Sleep function isn't always accurate. Depending on your processor and Sleep of 1 millisecond can take 10 milliseconds to wake back up. This means that the slower your computer it, the slower the ball will move because it won't make it to that Simulate function as often as a faster computer would. This also means that when you resize the window to something bigger (or maximize it), it will take longer to render the components and thus delay the time it takes to get back to that Simulate function and change the ball's position.
Here you can see the y-Velocity of the ball is 825, quite a bit higher than the 500 to start with. Too bad I suck and lost a life in the process of taking this screenshot...
So what we ended up doing is basing our movement off of a time step. Basically we call a function to get a time (the number of milliseconds since your computer started) and when the next call to simulate comes around it grabs the new time and compares it to the old one. That time difference becomes the "time step" which we use to tell us how many pixels to move. So this means that no matter how fast or slow your computer is, the ball will always move at (what I've got it set to) 500 pixels per second. This also means that with a real velocity, you can use the paddles to "spin" the ball by moving as you hit it.
Once that was done and implemented I started to work on the actual Pong-Karuga mechanics. I figured I'd start with something a little easier: the Charge shot system. Currently, whenever your opponent misses the ball and it hits the wall behind him, you gain some charge. Once you've hit the wall 5 times You've gained a "charge shot". Once you've filled your meter, the next time you hit the ball it will stick to your paddle. Pressing Space bar allows you to launch the ball again. This makes the ball grow to 2.5 times its original size and move 3.5 times faster across the board, firing at a random angle from the paddle. If the ball hits your opponent's wall he will lose a life, but if he manages to hit it, you volley the super shot back and forth until it hits someone's wall.
Charged shot ball! Hooray!
Eventually once polarity has been introduced if the opponent hits it with the wrong polarity he's lose a life too. But I haven't implemented that yet. I'm still trying to think of a way to have the AI choose polarity without it being unfair due to his being able to immediately know which polarity it is.
Anyway, I'm off to work on this some more. I'll be back in another couple of days with an update, hopefully one that starts with a "D" and ends with an "ownloadable Alpha".