#102314 - DiscoStew - Tue Sep 12, 2006 10:03 pm
This is one thing that I would like to figure out how to program, because I'd like to make a demo involving objects moving in a scripted manner that is smooth and not clunky or robotic, but I have no knowledge about them, other than perhaps that they need a position (vector), a direction (vector), and a magnitude.
What I mean by Vector Paths (if you even call them that) is very much like in Adobe products that have Pen Tools, that allow you to make curved lines out of points, such as the image shown below.
http://img67.imageshack.us/my.php?image=vectorpathzs9.png
The only other option for something like this is to split up this scripted path into many many points, each with their own set of information to get from one point to another, but in my mind, that seems like a lot of space to use for just one, when I hope to make a path for a lot (at least hundreds) of individual objects.
If anyone has any information about how to do this, it would be very much appreciated.
_________________
DS - It's all about DiscoStew
#102315 - tepples - Tue Sep 12, 2006 10:06 pm
First see [[B?zier curve]].
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#102340 - sajiimori - Wed Sep 13, 2006 1:54 am
#102349 - poslundc - Wed Sep 13, 2006 3:50 am
#102352 - sajiimori - Wed Sep 13, 2006 4:39 am
Huh, I like those even better. Just a bit smoother around the control points.
#102953 - DiscoStew - Mon Sep 18, 2006 4:47 am
Thanks for the suggestions everyone. I'll take a look at them.
_________________
DS - It's all about DiscoStew
#102960 - shen3 - Mon Sep 18, 2006 7:07 am
you could also try an array of points for the flight path.
If you give each array a name, or have an array of these flight path arrays, each monster could be assigned a path, maybe with an x + y offset.
In any case, I would be very interested to hear what you come up with, and any free tools you develop to help you create + manage paths for your game.
I would love to add some predefined movements to my shoot em up, but am too busy to do the coding required to implement any of the ideas I have had.
Shen
#102962 - DiscoStew - Mon Sep 18, 2006 7:31 am
The whole array-of-points idea was what I was going to do in the first place, until I realized that in order for the path to look smooth, I'd have to have a large array for a single path, and because of the hundreds of paths I plan to make, I could see that getting mighty hefty.
_________________
DS - It's all about DiscoStew
#103002 - poslundc - Mon Sep 18, 2006 4:30 pm
The biggest problem with splines on the GBA tend to be in the initialization of them, in the determination of coefficients. You are at your best if your splines are either totally static within a scene/level/map (in which case you can write a tool to pre-calculate them for you), or if you can determine them when your scene/level/map is initializing, and calculate the coefficients during a blackout.
I sometimes calculate simple splines on the fly, but they are usually only three or four data points large. I wouldn't ever want to try to do more than a couple in a single frame.
Dan.
#103090 - sgeos - Tue Sep 19, 2006 4:54 am
| poslundc wrote: |
| You are at your best if your splines are either totally static within a scene/level/map (in which case you can write a tool to pre-calculate them for you) |
Precalculation is very useful.
> shen3
If you want to do an array of points, I'd use a PC side tool to precalculate a pretty path.
-Brendan
#103114 - keldon - Tue Sep 19, 2006 9:59 am
Although your paths may be smooth it doesn't mean that the movement will. You could end up with a lovely path and it still appears robotic because of the changes in speed between each curve, so just be aware of that when you are making them.
#103242 - shen3 - Wed Sep 20, 2006 6:19 am
Steos said:
Precalculation is very useful.
> shen3
If you want to do an array of points, I'd use a PC side tool to precalculate a pretty path.
I reply;
Yeah, I agree. Then you still end up with some arrays of points. I guess if you could do some compression, instead giving a dx,dy and the number of times to apply the movement or something.
Then a movement across the whole screen might be (-1,0,260) meaning move 1 to the left, and do it 260 times. Or, if you do as I do and use fixed point math for positioning, and treat each pixel as having 256 segments (-256,0,260). Moving at half a pixel per turn would be (-128,0,520).
Doing this requires either writing some pc application to draw + record flight paths from mouse movements, or even worse, to draw and record flight paths from vector drawing commands + spline + beizer curves + whatever else.
Another option I thought about would be to have a starting point for each enemy, and then a bunch of functions for different movement patterns. This might take up less ram space, but is still a pain to write, and making a unique path is a lot of work for little gain.
However, that is the method I used for my game "S World 3". The aliens have about 5 or 6 different possible movement patterns (straight line, curvey, move + hover) plus a few special movement patterns for the boss monsters.
The monsters within a level just get generated randomly, based on some parameters for total monsters per level, start generation rate (monsters / minute) and monster generation accelleration (monsters / minute / minute)
It would be nice to have some rtype style levels where every monster is placed + given a flight path, but that would require another application on top of the flight path designer, to create levels + place enemies + assign flight path per enemy.
If someone writes or finds such a thing that can be setup for the gba or ds screen size and is $0, I'm interested in hearing about it.
link to S World 3 http://shen.mansell.tripod.com/games/gba/sworld3/sworld3.html
Shen
#103277 - sgeos - Wed Sep 20, 2006 3:59 pm
sgeos (lower case, with a 'g'); not very important
| shen3 wrote: |
Yeah, I agree. Then you still end up with some arrays of points. I guess if you could do some compression, instead giving a dx,dy and the number of times to apply the movement or something.
Then a movement across the whole screen might be (-1,0,260) meaning move 1 to the left, and do it 260 times. |
That strikes me as a strange way of doing things. Although I suppose they are really versions of the same thing if you use fixed point values. I'd personally do something like this if I wanted to move to absolute points:
| Code: |
const Point myAbsolutePath[] =
{
{7, 7},
{14, 11},
{21, 13},
{28, 14},
{-1, -1} // DONE; this really wants to be a macro (use out of bounds value)
}; |
If you want relative movement:
| Code: |
const Point myRelativePath[] =
{
{7, 7},
{7, 4},
{7, 2},
{7, 1},
{0, 0} // DONE; this really wants to be a macro (use meaningless value)
}; |
Whether you use absolute or relative movement really depends on what you want to do. If you really want to use 3 values, I'd use x, y and frames. If frames == 17, then we reach the control point 17 frames from now.
| Code: |
const TimedPoint myTimedRelativePath[] =
{
{7, 7, 60},
{7, 4, 50},
{7, 2, 40},
{7, 1, 30},
{0, 0, 0} // DONE; this really wants to be a macro (use meaningless value)
}; |
Arrays of control points are easy to implement and understand. That is why I am advocating them. If your engine handles them, you can write fancy spline tools without having to change your data format, although you might want to. If you want really smooth paths, your LUTs are going to be large. (For some definitions of large =)
-Brendan
#106697 - Yare - Sun Oct 22, 2006 7:45 pm
| Quote: |
| because I'd like to make a demo involving objects moving in a scripted manner that is smooth and not clunky or robotic |
Flocking.
http://www.red3d.com/cwr/boids/
Steering.
http://www.red3d.com/cwr/steer/
What you want could be accomplished with a combination of steering behaviors.