I'm attempting a to make a fighting game with multiple platforms. I've successfully made the controls, movement, (double)jumping, and gravity parts of the game.
The issue is, when a player jumps, upon reaching the ground, they seem to go a bit deeper than they should on the platform (they should land and stay on the surface of the platform). This is more visible when the player double jumps.
I know why this happens; it's because sometimes hitTestObject takes a while to react when objects come in too quickly.
So, the first thing I thought of is to make the player's foot's y axis equal to the y axis of the top of the platform he lands on.
Though, that solution resulted in a rather jerky landing.
My question is: Is there a way to make the player to land smoothly on the top surface of the platform?
Some things I've tried:
-Raising FPS, it just made the same effect happen, but more quickly.
-Decreasing the speed at which the player falls, but that makes the game less fun, so I've crossed it out.
And here's my relevant code:
stage.addEventListener(Event.ENTER_FRAME, loop);
var jumpConstant:Number = 30;
var gravityConstant:Number = 1.8;
function loop(e:Event):void //happens
{
if(player.leg1.foreleg1.foot1.hitTestObject(platforms.ground)||player.leg2.foreleg2.foot2.hitTestObject(platforms.ground)) //if either of the player's legs are colliding with the platform [ps: nested movieclips]
{
player.ySpeed = 0; //the player stops going downwards
player.y = platforms.y; //the player's y becomes the platform's y. don't worry, it puts the player in the right place, just not smoothly.
if (player.b_up) //if Up control button (W or Up Arrow) is being pressed
{
player.ySpeed = -player.jumpConstant; //make the player jump
}
else //if the player isn't colliding with the platform
{
player.ySpeed += player.gravityConstant; //the player is affected by gravity and is pulled downwards
}
Link to the game if you wanna try it out to see the jerky effect:
http://www.fastswf.com/-64Ux3I
The problem is that you are only checking for a collision at increments of ySpeed. Since y speed increases during a fall by 1.8 per step, you are quickly looking at collision checks spaced widely apart. If you want pixel precise collision checks, you need to check for collision at 1px increments. This means if y speed is 10, you need 10 collision checks during one loop update. Use a for loop within your loop function to accomplish this.
Why don't you set hitTestObject y coordinates a bit above the ground so the sinking into the ground will actually make it touch the ground now.
Related
I am trying to make a top down game where you throw a disc using Box2d. The world has no gravity so the disc can be thrown and just bounces around the stage with the inertia and linear damping that I have set it with. Now, if I try to introduce wind using ApplyForce on an enter frame it will constantly push the disc in that direction until it hits a wall. What I am looking to do - with no luck so far - is give the stage (ground) some fiction so as the ball loses momentum it will eventually rest/stick. The code for the ApplyForce is as follows:
var xA = (Math.sin(windDir*(Math.PI/180)) * windSpeed * -1);
var yA = (Math.cos(windDir*(Math.PI/180)) * windSpeed );
var wind:V2 = new V2(xA, yA);
ball1.b2body.ApplyForce(wind, new V2(ball1.x, ball1.y));
Any thoughts?
Thanks.
if it will have friction, it either wont move, or will move again until hits the wall, but slower.. its simple physics. you can slow down every object, but not with applyforce, because box2d is a simulator, and you want to do unrealistic thing.
I am new to working in ActionScript and I'm experimenting with using the Timeline to trigger certain events in my game. In particular, I'm using the timeline to trigger the fire event for a gun so that when the fire animation gets to a certain frame, a bullet is spawned. In the gun class (Enter_Frame) I check that the mouse is being held down and the time between the last shot and the current time is longer than the cool down, if everything checks out I play the animation.
if (time - lastShot > cooldown)
{
canShoot = true;
lastShot = time;
}
if (mouseHold && canShoot)
{
play();
}
This creates a problem when the frame rate is brought below the point where the full animation cannot be played before the cool down is up again. In this instance the bullets fire slower with lower frame rates.
In addition, higher frame rates make the gun more responsive to mouse input because the fire frame comes sooner than in lower frame rates.
The goal is obviously to make the game completely frame rate independent. I would like to have the ability to slow down or speed up the frame rate of the animation depending on the cool down of the gun.
What is the best way to make this animation play in a specific time period without skipping over the actions that I have put into the timeline?
It sounds like you're on the right track, but approaching this the wrong way. Check out the Timer class, it's framerate independent, and will greatly aid you.
var my_timer = new Timer(1000,0); //in milliseconds
my_timer.addEventListener(TimerEvent.TIMER, catchTimer);
my_timer.start();
function catchTimer(e:TimerEvent)
{
trace("event fired");
}
You should look into time based animation instead of frame based if you want your animations to be precise and not depend on the framerate, this way your animations will always be the same and will compensate the slower frame rates of slower computers. Here is an article that explains it very well: http://www.flashgamesclassroom.com/classroom/actionscript/frame-based-vs-time-based-animation/
Here's the thing : I have a ball bouncing using Tweens, and I want to detect collisions between the ball and platforms (only when the ball is falling down).
But, my solution is testing for collisions in an ENTER_FRAME loop, so when the ball speed is to high, at a x frame the ball is above the plateform, and at a x+1 frame the ball is below the platform, so my loop never detects collision (because the ball and the platform never really collide).
Here's the jump method of my ball :
public function jump():void
{
TweenLite.killTweensOf(this);
TweenLite.to(this, jumpSpeed, {y:250, ease:Cubic.easeOut});
TweenLite.to(this, jumpSpeed, {delay:jumpSpeed, y:stage.stageHeight-this.height, ease:Cubic.easeIn, onComplete:jump});
}
And here's what's executed in my ENTER_FRAME loop :
for each (var platform:Platform in platforms)
{
if (ball.hitTestObject(platform) && ballPreviousY < ball.y)
ball.jump();
}
ballPreviousY = ball.y;
I already started to work on a solution using the physics engine Box2D, but I would like to know if there was a simpler solution to that problem.
This is a common problem in collision detection - small, fast objects moving through thin obstacles. What your looking for is sweep testing
Instead of testing for intersection between two static shapes, we can
instead create new shapes by sweeping the original shapes along their
trajectory, and testing for overlap between these swept shapes.
From N Tutorial A - Fast Moving Objects, (I'd recommend reading all their stuff if your interested in more detail in collision algorithms).
For example, if you had a 1px by 1px square and it was travelling at 5px per frame along the x axis, you'll want to distort your square so that becomes a 6px by 1px rectangle for collision testing. Catching anything that it would hit next frame, but not anything more.
Circles are a little more difficult because when you stretch them they become ellipses (which are far harder to check collisions for). See this answer if you want to go the ellipse route.
I have created a collision class to detect collisions using pixels. In my class I've also developed some functions for determining the collsion angle. Based on this I created some examples:
http://megaswf.com/serve/25437/
http://megaswf.com/serve/25436/
(Space to change gravity, right/left to give some speed to the ball.)
As you will probably notice, there are strange things that happen:
When the ball speed is very low
When the direction of the ball is
almost tangent to the obstacle.
collision http://img514.imageshack.us/img514/4059/colisao.png
The above image shows how I calculate the collision angle.
I call the red dots the keypoints. I search for a maximum number of keypoints (normally 4). If I find more then 2 keypoints, I choose the 2 farthest ones (as shown in one of the blue objects). Thats how I then find the normal angle to where in the surface the object collided. I don't know if this is an obsolete way of doing things.
based on that angle, I rotate the speed vector to do the bouncing.
The piece of code to do the maths is here:
static public function newSpeedVector(speedX: Number, speedY: Number, normalAngle: Number): Object{
var vector_angle: Number = Math.atan2(speedY, speedX) * (180/Math.PI);
var rotating_angle: Number = (2*(normalAngle - vector_angle) + 180) % 360;
var cos_ang: Number = Math.cos(rotating_angle/DEGREES_OF_1RAD);
var sin_ang: Number = Math.sin(rotating_angle/DEGREES_OF_1RAD);
var final_speedX: Number = speedX * cos_ang - speedY * sin_ang;
var final_speedY: Number = speedX * sin_ang + speedY * cos_ang;
return {x_speed: final_speedX, y_speed: final_speedY};
}
This is how the new speed vector is calculated...
My question is, has anyone faced this kind of problem or has some idea on how to avoid this from happening?
Without seeing your code, this is the best I can provide.
Collision physics should have some velocity threshold that is considered "stopped". That is, once the velocity gets small enough you should explicitly mark an object as stopped and exempt it from your collision code. This will help stabilize slow moving objects. Trial and error is required for a good threshold.
When a collision happens, it is important to at least attempt to correct any inter-penetration. This is most likely the reason why tangent collisions are behaving strangely. Attempt to move the colliding object away from what it hit in a reasonable manner.
Your method of determining the normal should work fine. Game physics is all about cheating (cheating in a way that still looks good). I take it rotation and friction isn't a part of what you're going for?
Try this. You have the contact normal. When you detect a collision, calculate the penetration depth and move your object along the normal so that is isn't penetrating anymore. You can use the two points you have already calculated to get one point of penetration, you'll need to calculate the other though. For circles it's easy (center point + radius in direction of normal). There are more complex ways of going about this but see if the simple method works well for you.
I have read and recommend this book: Game Physics Engine Development
I did something a little like that and got a similar problem.
What I did is that when the pixels from the bouncing object (a ball in your case) overlap with the pixels from the obstacle, you need to move the ball out of the obstacle so that they are not overlapping.
Say the ball is rolling on the obstacle, before your render the ball again you need to move it back by the amount of 'overlap'. If you know at what angle the ball hit the obstable just move it out along that angle.
You also need to add some damping otherwise the ball will never stop. Take a (very) small value, if the ball velocity is bellow that value, set the velocity to 0.
You can try one more thing, which I think is very effective.
You can make functions such as getNextX() and getNextY()(Which of course give their position coordinated after the next update) in your game objects and Check collision on objects based on their next position instead of their current position.
This way, the objects will never overlap, you'll know when they are about collide and apply your after collision physics gracefully!
I'm creating a Flash game which is based on the old Pacman and I'm not sure which is the best way to control the animation.
As I understand it these type of games were originally dependent on a game loop which ran faster or slower depending on the CPU, which is why I imagine that the most similar to use would be the ENTER_FRAME event.
This however presents the problem of having to have a specific frame rate and changing it later is out of the question, not to mention being limited to very few different "speeds" (see below). An example could be that the sprite has to move 12 pixels before the next move is determined. If the speed is then 4 pixels per frame, the math is quite simple:
[...]
public var stepCount:uint = 0;
[...]
function enterFrameHandler(e:Event):void
{
if(stepCount==0) {
//Some code to evaluate next move. Let's say it evaluates to MOVE RIGHT
}
if(MOVE_RIGHT)
{
x += 4;
}
stepCount++;
if(stepCount > 2)
{
stepCount = 0; //Now ready to evaluate direction again.
}
}
This all works fine, but let's say that I want the sprite to move 5 pixels per frame. Then the number of frames before making the next evaluation would not compute. The stepSize would have to be a multiple of 12, which limits the different possible speeds (1,2,3,4 and 6 pixels per frame).
This is why I attempted to base the movement on a Timer instead, which I also managed to get to work, but the movement was somewhat erratic and it seemed like the Timer was using far more memory than the ENTER_FRAME event. Instead of an even movement the Timer made the sprite slow down and speed up and slow down again.
Another possible solution could be the Tween class, but it seems extravagant.
Does anyone have experience with what works best in other games?
Morten Twellmann
You have several separate issues here. Your first question is, should you execute your game loop in a frame event or a timer event? The answer is easy - you should do it in a frame event. The reason is that regardless of how you move your characters, the screen is updated precisely once per frame. So any time you're calling your game loop more than once per frame you're wasting CPU, and any time you call it less than once per frame, you're sacrificing visual quality. So this one is easy, don't bother with timer events at all.
The next question is whether your game's movement should be tied to frames or miliseconds, and the answer is that it depends on the game. Ask yourself this: suppose that some user is playing your game, and their spaceship (or whatever) is flying along at a given speed. Suddenly, the user's anti-virus package does something heavy, and the CPU spike causes Flash to stop updating for one second. Once the spike is over, do you want the spaceship to continue moving from where it was when the spike started? Or do you want it to jump forwards to where it would be if it had continued moving during the spike? If you want the former, you should tie your movement to frames; if you want the latter, you should tie it to miliseconds. But which one is best depends on how you want your game to work.
The final question is, how exactly should you move the characters in your game? Based on what you wrote, I'd do it as follows. For frame-based movement (i.e. the first approach described earlier):
// the ship moves 25 pixels per second
var shipSpeed:Number = 25;
// the number of seconds per frame, based on the published framerate
var frameTime:Number = 1 / stage.frameRate;
// game loop called each frame:
function gameLoop() {
// ...
playerShip.x += shipSpeed * frameTime;
// ....
}
This way, the ship's movement on screen is constant, regardless of what framerate you publish your SWF at. Using a higher framerate simply makes the movement smoother. Likewise, to tie your movement to time instead of frames, simply change "frameTime" in the code above to refer to the time elapsed since the previous frame, as described in Allan's answer.
Yes frame rates will vary depending on CPU amongst other things. Therefore you need to take this into account with your game loop. What I like to do is get the time difference between the current frame and the old frame and use that value in my calculations. So if it happens that there is a delay the larger difference value will then make up for the fact less frames ran.
var _previousTime:Number;
//gameLoop is the function called on ENTER_FRAME
public function gameLoop(e:Event):void
{
var currentTime:Number = getTimer();
var difference:Number = currentTime - _previousTime;
_previousTime = currentTime;
//use difference variable with calculations involving movement
}