Flyer Movement Framework

[Grayzzur]

And the lightbulb for what SetTargetOffsetX/Y does just went off. I always wondered what the heck those were for.
Great! Now I have to go rewrite everything...

;D

I can imagine how they came to be.
I did the Harvesterscustom spores when I made FarborCW1 SAMs, then slapped my forehead when I saw the snipersmissiles shoot at the ground under the harvestersspores. Lacking the ability to add features directly to the game, I came up with my plan. I do get a warm and fuzzy hearing Virgil call it ingenious, so thank you for that.

[eduran]

Lacking the ability to add features directly to the game, I came up with my plan.

Lacking the ability to add features directly to the game, I came to the forum to cry about it :) Which turned out to be almost as good.

[eduran]

Another update:
I am currently using my movement script as part of a map. Doing that allowed me to identify a couple of flaws in the design, but most of them were easily fixable. On the upside, not having to worry about movement makes implementing new enemies a lot easier. I am even using it to drive a ship.
Once the map is released I will give the code another once-over and after that it should be ready for release.


Some details on how I tackled the 'approach a cell at a certain angle' problem. Feel free to ignore this part, it's mostly meant as a way to sort out my thoughts on the subject.

1) Fixed turn radius. All of the calculations hinge on that one. Variable speed and acceleration are not a problem and neither is changing turn radius in between moves. But during a move, the turn radius is fixed. That also means the flyer is either turning as hard as possible or not at all (i.e. flying in a straight line).

2) Two turns are enough to reach any destination from any origin. To get the shortest possible path, the first turn has to happen immediately, followed by going straight. The second turn ends at the destination, at just the right angle.

Here's a screenshot of a flyer plotting a path. The CRPL cores, lines, circles are all generated by the script (I gave up on debugging with just the trace log pretty quickly).

Spoiler

[close]

The destination is the black arrow at the top left, the origin is the flyer itself. The steps I outlined above (turn, straight line, turn) allow for four different pathes: turning either left or right at both the start and the end. That's why there are four colored lines.
I was unable to come up with a way to figure out which path is the shortest, so the script resorts to brute force: it calculates the length of all of them and selects the shortest one.

3) Once that is done, a number of parameters are fed into a function that converts distance traveled along the selected path into a set of coordinates and a direction. At that point, the actual movement is as simple as

Code Select Expand

<-coveredDistance add(<-currentSpeed) ->coveredDistance
@Distance2Position(<-coveredDistance) ->myDir ->myY ->myX
@RotateImages(<-myDir)
SetUnitAttribute(Self CONST_PIXELCOORDX <-myX)
SetUnitAttribute(Self CONST_PIXELCOORDY <-myY)


Things that work very well using this method:

• arriving at the target at exactly the intended angle
• using the shortest path to do so (unless someone proves me wrong and comes up with a shorter path)
• the movement looks very smooth, even at high speed

   
The downside is that a lot of calculations are necessary. So far I didn't notice any performance issues with up to 10 moving units, but using a lot of them or changing targets often (e.g. when you are tracking a moving target) could be a problem.

[knucracker]

That's very, very clever.  Back before CW1 I worked on two game prototypes that I never went anywhere with.  One of them was a stop motion space combat sim (similar to the way Space Rangers works).  The motion of the spacecraft in that prototype was very similar to the way this works out.

I have a feeling this will get used by a lot of people in a lot of maps... shoot, I might even use it if I can find the time to make the map I've been wanting to make.

[Clean0nion]

That's very, very clever.  Back before CW1 I worked on two game prototypes that I never went anywhere with.  One of them was a stop motion space combat sim (similar to the way Space Rangers works).  The motion of the spacecraft in that prototype was very similar to the way this works out.

I have a feeling this will get used by a lot of people in a lot of maps... shoot, I might even use it if I can find the time to make the map I've been wanting to make.

You know what? I'm deleting Sall 5 right now. Eduran, get prepared for some credit coming your way.

[Cavemaniac]

That's very, very clever.  Back before CW1 I worked on two game prototypes that I never went anywhere with.  One of them was a stop motion space combat sim (similar to the way Space Rangers works).  The motion of the spacecraft in that prototype was very similar to the way this works out.

I have a feeling this will get used by a lot of people in a lot of maps... shoot, I might even use it if I can find the time to make the map I've been wanting to make.

I've said it before, I'll say it again, the most amazing stop motion/'turn based' space homing missile game I've ever seen is Critical mass.

http://www.windowsgames.co.uk/critical.html

Looks a bit crappy, gameplay is amazing.

The turning radius is a massively important part of the game.

After the CW series, this game has soaked up more of my life than any other...

Visit and be inspired - free demo, but it's a bit limited.

[thepenguin]

Another update:
I am currently using my movement script as part of a map. Doing that allowed me to identify a couple of flaws in the design, but most of them were easily fixable. On the upside, not having to worry about movement makes implementing new enemies a lot easier. I am even using it to drive a ship.
Once the map is released I will give the code another once-over and after that it should be ready for release.


Some details on how I tackled the 'approach a cell at a certain angle' problem. Feel free to ignore this part, it's mostly meant as a way to sort out my thoughts on the subject.

1) Fixed turn radius. All of the calculations hinge on that one. Variable speed and acceleration are not a problem and neither is changing turn radius in between moves. But during a move, the turn radius is fixed. That also means the flyer is either turning as hard as possible or not at all (i.e. flying in a straight line).

2) Two turns are enough to reach any destination from any origin. To get the shortest possible path, the first turn has to happen immediately, followed by going straight. The second turn ends at the destination, at just the right angle.

Here's a screenshot of a flyer plotting a path. The CRPL cores, lines, circles are all generated by the script (I gave up on debugging with just the trace log pretty quickly).

Spoiler

[close]

The destination is the black arrow at the top left, the origin is the flyer itself. The steps I outlined above (turn, straight line, turn) allow for four different pathes: turning either left or right at both the start and the end. That's why there are four colored lines.
I was unable to come up with a way to figure out which path is the shortest, so the script resorts to brute force: it calculates the length of all of them and selects the shortest one.

3) Once that is done, a number of parameters are fed into a function that converts distance traveled along the selected path into a set of coordinates and a direction. At that point, the actual movement is as simple as

Code Select Expand

<-coveredDistance add(<-currentSpeed) ->coveredDistance
@Distance2Position(<-coveredDistance) ->myDir ->myY ->myX
@RotateImages(<-myDir)
SetUnitAttribute(Self CONST_PIXELCOORDX <-myX)
SetUnitAttribute(Self CONST_PIXELCOORDY <-myY)


Things that work very well using this method:

• arriving at the target at exactly the intended angle
• using the shortest path to do so (unless someone proves me wrong and comes up with a shorter path)
• the movement looks very smooth, even at high speed

   
The downside is that a lot of calculations are necessary. So far I didn't notice any performance issues with up to 10 moving units, but using a lot of them or changing targets often (e.g. when you are tracking a moving target) could be a problem.

This is roughly the space shuttle landing system... wow.  Awesome job!