Is it just me or did my really lengthy post on bouncing that I posted a while back just disappear? D:
Also, just asking: By circular trajectory did you actually mean this (parabolic trajectory)? Implementing a parabolic trajectory is simpler and faster since sin/cos functions are relatively slow functions.
Just so we're on the same page, I'm assuming you know how to use vectors, because they simplify calculations *A LOT*. However, if your engine doesn't support vector maths, you can technically split them into x and y components, although things like calculating magnitudes would be unnecessarily messy.
I've noticed you got some trouble combining forces, and this is probably due to the way "sticky" physics in older 2d games were done. In older platform games, they often calculate just the velocity and apply it to the position. If you want a more realistic representation, there is acceleration / force to consider as well.
Newton's first law states that an object is stationary or at constant velocity unless there is a net force is applying on it. Newton's second law states that an object accelerates proportionally to the net force per mass.
Each object should store its own velocity, position and mass.
set total_force as (0, 0)
do calculations for each force and add it to total_force
add (total_force / mass * time) to velocity
add (velocity * time) to position
Let's start with the easiest of all the forces, gravity. Gravity on the surface of the Earth is 9.81 x mass. The 9.81 I've given is in SI units, so you'll need to convert it to whatever scale you're using. Over time, as we learn the other forces, we'll add it to the code above.
For now, you could try out simple trajectory physics by setting the velocity vector and seeing how it goes.
EDIT: I realised my earlier explaination might end up troublesome if we ever decide to move on to rotations.
Ah, didn't notice you've posted while I was trying to ninja-edit my stuff. :P
Yeah, you might want to go over my changes.
To be honest, all that stuff about shaving CPU time off is no longer applicable because that was back in the days when 300MHz was amazing. I went over it so that you would know why those older games were done that way.
Also, calculating individual forces and adding them up would really help in the long run, because there is so many things you can add to it, like lift, drag, magnetic pull, collisions, etc. and the system would still work.
The second thing I want to get into before bouncing is the concept of normals. The name itself is a bit confusing, but essentially, it's a vector that represents the direction the face of a surface is pointing at.
EDIT: Meh, got some work dumped on me. Will finish this later. Don't worry, I'll get there eventually.
Well, the easiest thing to do is to simply plug in Box2D. There have been various ports to different languages like Flash and JavaScript and used extensively by numerous games, so it's no slouch. I wouldn't be supprised if Angry Birds used them as well.
However, if you insist on making things yourself, I am a first year mechanical engineering student so I could try helping out. Just ask any topic and I'll answer as much as I can.
Running the sample through a spectrum analysis, the highest peak is at 999Hz, i.e. 999 combustions per second.
Looking up the car on Wikipedia reveals that the car uses a 4 cylinder engine. Being a 4 stroke engine, a cylinder combusts every 2 revolutions. In other words, there are 4 / 2 = 2 combustions every revolution.
So the calculated speed is (999 / 2) = 249 rev/s = 7470rpm
Well, there is no download link on your website for the game so I can't test it out first-hand. Also, I've noticed your other projects are Windows-only .exe files, so I don't think I can run those either.
Judging from your video, the text isn't exactly laid out nicely. For instance, the score is supposedly centre aligned yet it seems a bit too far to the left. In addition, the plain font does clash with the busy looking borders. You'll either have to tone down the borders or add something like a border or shadow effect to the fonts.
Moving on to the game board itself, the graphics is fine, but the lack of animation doesn't give much feedback to the user. This isn't the 90s. Heck, even Windows 7 updated the classic Minesweeper to have animations.
I'm still not clear on the gameplay itself, mostly because I can't try it out myself first-hand so I'll leave that alone. However, I don't approve of the idea of saving and then loading to get around things. The load/save system is supposed to recreate the exact same state the game was the moment the save button was pressed.
The buttons on the right side of the game board causes some inconsistency with the main menu buttons, so that should be fixed as well.
Overall, your game is pretty rough around the edges and needs quite a bit of work.
As a final note, if you're going to ask for critique on OGA, don't make such wild statements about us. We do have production quality artwork, they're being used in FLARE and other projects already. In an exaggerated sense you're basically calling a someone ugly and then asking that person: "Do I look pretty?"
What Quake does is use brushes, which are essentially convex blocks with each face represented by a plane equation. You can then test the point with each plane.
Python-ish pseudo code:
collision = true
for plane in brush.faces:
if plane.distance(point) > radius:
collision = false
I haven't really worked with ellipses before, but I read something about scaling along an axis. That's probably a good place to start.
EDIT: Fixed some typos
EDIT 2: Oh, I think I misread the OP. :/ But this is still some useful information to have around.
What you could do for parabolic path is have your projectile set up like this:
pos_x = 0
pos_y = 0
vel_x = - sin(deg2rad(aim_angle)) * speed * player_direction
vel_y = - cos(deg2rad(aim_angle)) * speed
And then while the game is running you have it run like this:
vel_y = vel_y + gravity * delta_time
pos_x = pos_x + vel_x * delta_time
pos_y = pos_y + vel_y * delta_time
if pos_y < ground_level then
pos_y = 0
vel_y = - vel_y * elasticity
Where the elasticity of an object is how bouncy it is, between 0 and 1. For instance, a tennis ball should be around 0.7.
Is it just me or did my really lengthy post on bouncing that I posted a while back just disappear? D:
Also, just asking: By circular trajectory did you actually mean this (parabolic trajectory)? Implementing a parabolic trajectory is simpler and faster since sin/cos functions are relatively slow functions.
Just so we're on the same page, I'm assuming you know how to use vectors, because they simplify calculations *A LOT*. However, if your engine doesn't support vector maths, you can technically split them into x and y components, although things like calculating magnitudes would be unnecessarily messy.
I've noticed you got some trouble combining forces, and this is probably due to the way "sticky" physics in older 2d games were done. In older platform games, they often calculate just the velocity and apply it to the position. If you want a more realistic representation, there is acceleration / force to consider as well.
Newton's first law states that an object is stationary or at constant velocity unless there is a net force is applying on it. Newton's second law states that an object accelerates proportionally to the net force per mass.
Let's start with the easiest of all the forces, gravity. Gravity on the surface of the Earth is 9.81 x mass. The 9.81 I've given is in SI units, so you'll need to convert it to whatever scale you're using. Over time, as we learn the other forces, we'll add it to the code above.
For now, you could try out simple trajectory physics by setting the velocity vector and seeing how it goes.
EDIT: I realised my earlier explaination might end up troublesome if we ever decide to move on to rotations.
Ah, didn't notice you've posted while I was trying to ninja-edit my stuff. :P
Yeah, you might want to go over my changes.
To be honest, all that stuff about shaving CPU time off is no longer applicable because that was back in the days when 300MHz was amazing. I went over it so that you would know why those older games were done that way.
Also, calculating individual forces and adding them up would really help in the long run, because there is so many things you can add to it, like lift, drag, magnetic pull, collisions, etc. and the system would still work.
The second thing I want to get into before bouncing is the concept of normals. The name itself is a bit confusing, but essentially, it's a vector that represents the direction the face of a surface is pointing at.
EDIT: Meh, got some work dumped on me. Will finish this later. Don't worry, I'll get there eventually.
Well, the easiest thing to do is to simply plug in Box2D. There have been various ports to different languages like Flash and JavaScript and used extensively by numerous games, so it's no slouch. I wouldn't be supprised if Angry Birds used them as well.
However, if you insist on making things yourself, I am a first year mechanical engineering student so I could try helping out. Just ask any topic and I'll answer as much as I can.
I nearly forgot I did that one. Back then I had absolutely no idea about anatomy, mind you I still don't. :P
But yeah, great work improving on it.
Running the sample through a spectrum analysis, the highest peak is at 999Hz, i.e. 999 combustions per second.
Looking up the car on Wikipedia reveals that the car uses a 4 cylinder engine. Being a 4 stroke engine, a cylinder combusts every 2 revolutions. In other words, there are 4 / 2 = 2 combustions every revolution.
So the calculated speed is (999 / 2) = 249 rev/s = 7470rpm
Science, it's amazing.
Well, there is no download link on your website for the game so I can't test it out first-hand. Also, I've noticed your other projects are Windows-only .exe files, so I don't think I can run those either.
Judging from your video, the text isn't exactly laid out nicely. For instance, the score is supposedly centre aligned yet it seems a bit too far to the left. In addition, the plain font does clash with the busy looking borders. You'll either have to tone down the borders or add something like a border or shadow effect to the fonts.
Moving on to the game board itself, the graphics is fine, but the lack of animation doesn't give much feedback to the user. This isn't the 90s. Heck, even Windows 7 updated the classic Minesweeper to have animations.
I'm still not clear on the gameplay itself, mostly because I can't try it out myself first-hand so I'll leave that alone. However, I don't approve of the idea of saving and then loading to get around things. The load/save system is supposed to recreate the exact same state the game was the moment the save button was pressed.
The buttons on the right side of the game board causes some inconsistency with the main menu buttons, so that should be fixed as well.
Overall, your game is pretty rough around the edges and needs quite a bit of work.
As a final note, if you're going to ask for critique on OGA, don't make such wild statements about us. We do have production quality artwork, they're being used in FLARE and other projects already. In an exaggerated sense you're basically calling a someone ugly and then asking that person: "Do I look pretty?"
What Quake does is use brushes, which are essentially convex blocks with each face represented by a plane equation. You can then test the point with each plane.
Python-ish pseudo code:
collision = true
for plane in brush.faces:
if plane.distance(point) > radius:
collision = false
I haven't really worked with ellipses before, but I read something about scaling along an axis. That's probably a good place to start.
EDIT: Fixed some typos
EDIT 2: Oh, I think I misread the OP. :/ But this is still some useful information to have around.
Pages