8 replies to this topic

[PacManPlus]

Hi:

As some of you may know, I'm almost complete with my Asteroids Deluxe hack. I am stuck on pretty much the last aspect of this game, and that is the movement of the wedges.

In the arcade game, once a 'Killer Satellite' is hit, it breaks up into three smaller ships ('wedges') that persue the player. I'm trying to recreate that here. The issue is, these three ships don't 'snap' to face the player, they kind of slowly turn as they are moving (like a car would) to go after the player.

If I have these known values at the point in time that I have to calculate this, does anyone know how I would go about doing it:
Wedge:
XPOSITION
YPOSITION
XVELOCITY (IN PIXELS)
YVELOCITY (IN PIXELS)

Player:
XPOSITION
YPOSITION

We also have the X and Y Velocity for the player, but I don't think that is needed here as the wedges track the ship's position, not direction.
The wedges also have a speed cap. They cannot go any faster than a velocity of 8 in any direction (for example). I am assuming we have to take into consideration the frame count (which there is a variable for) to make sure the wedge doesn't turn too fast or too slow...

Also, the bottom left corner if the screen is the home position (0, 0)

Thank you so much for this in advance, as I have been racking my brain on this for a few weeks now.
Bob

Edited by PacManPlus, Sat Jun 30, 2007 10:54 AM.

[PacManPlus]

Nobody has a clue?


How about this slight variation:
If I can get a number (preferably 0-16, with 0 being directly above) from the difference in the x,y coordinates using the wedge as the 'center' and the player's ship in relation to the wedge, that would work for me

For example, if the player's ship is directly above the wedge (doesn't matter how far, it just matters that the 'y' delta between the two objects is zero), thatwould return a '0'. IF the player's ship is slightly to the right, but still above the wedge, that would return a '1', and so on - kind of like a clock, with the wedge in the middle and the player being at each of the numbers...

I don't know if I'm explaining this correctly, maybe not, becuase nobody can answer the question

Bob

[Bruce Tomlin]

I suppose you could always try to disassemble the arcade version and hope it didn't use a mathbox for the computation.

Basically, you've got to:

1) Determine which quadrant you are in relative to the ship. In other words, if the player is on the far left side of the screen, and the wedgie is on the far right side of the screen, it should be going across the edge of the screen.

2) Determine the angle from the wedge to the ship. This will probably require a sine/cosine thingy, but you might be able to get away with following an approximation using Bresenham's line algorithm. This would instead require a table of slope to angle conversions, which may be easier to compute.

3) Turn the wedge more in the direction of the player's ship. If it's more than a 90 degree turn, it might want to slow down too.

And hey, if you feel the need to have one monster table 8K to 16K for faster computation, you could always put that table in a bank by itself.

Edited by Bruce Tomlin, Tue Jul 3, 2007 8:49 PM.

[Rybags]

Agreed - it would probably be best to employ some smarts to judge the shortest distance to the player, based on the possibility of wraparound.

You might also want to have some sort of predictive aiming - e.g. based upon the ships direction/velocity. Of course, the direction the ship is pointing doesn't necessarily mean it is moving that way.

So far as movement goes, you'd be way better off having fractional movement. Consider the ship's screen X or Y position as a 2 byte number.

Use the low byte as a fraction, e.g. imagine two adjacent screen pixels as having co-ordinates ranging from 0-511. That way, you can have finely graduated velocity and not a lot of extra coding or time is needed.

For the actual velocity values, you could either add/subtract gradually from the velocity value, or you could just have a set number of possible velocities, e.g. 10 or so in each direction.

From there, just have a table lookup which gives the actual velocity value. The velocity index would gradually increment/decrement.

For each direction that a ship or wedge points, you obviously have a pre-determined maximum velocity in the H/V direction that it can achieve. Your code could gradually change the velocity index towards that max value which should give the object a curved motion path, rather than suddenly snapping to a certain path of motion.

Edited by Rybags, Tue Jul 3, 2007 8:07 PM.

[PacManPlus]

Thanks guys...

I believe I did something similar (I posted the new version in the Hacks thread)

I used table lookups for everything, but the downside is there are only 8 directions for the wedges. Maybe I can increase that to 16 after I play this a few times and nobody has any complaints...

I also explaned (quickly) what I did in that thread.

Thanks again
Bob

[Rybags]

If you have an assortment of velocities, the number of animation frames indicating direction mightn't seem so important.

It's perfectly OK for an object to point straight up, but be moving at a 15 degree angle, for example.

[PacManPlus]

Thanks Rybags

I've been thinking about that, and you're right. I'm going to work on it.

[EricBall]

Did you see this thread: Algorithm for tracking a target

[PacManPlus]

Thanks Eric!

I actually wish I had seen this - that was exactly what I was looking for. (I finally was able to do it with tables)

Thanks again for the head's up - I'll have to keep that thread in a 'favorites', so to speak.
Bob