C-Dawg
12-07-2002, 05:37 PM
I posted this in the Beta forums awhile back, but it didnt get any comments there. I want people to see this because, once 179 is released, I'd love someone like fatcatfan to program a scripting engine that can apply the formula I've devised automatically. I'd also like to work with that person in improving the formula to be more realistic... the method I describe below is very rudimentary. But it does work.
With new combo animation, we can do alot of neat effects, including moving platforms. One easy way to accomplish this would be to make platforms that appear and dissapear while remaining stationary- that one is pretty much a no-brainer of switching between a pit and walkable combo. I've been exploring something a little more difficult- making a platform that floats along a pre-determined path on the screen between two points. Ive found organizing the animation and combos is not something you can just sit down and do- it requires preperation. With that in mind, I'd like to describe the method I've found useful for setting it up.
First, some terminology. A tile is one 16x16 graphic on the tilesheet. A combo is a entity on your combo sheet, including type, walkability, C-set, and a series of tiles that make up it's animation sequence. (These you already know.) A cell is an entity consisting of a series of combos linked together by combo animation. That is, if I was to make a spike that jutted out of the wall, the cell would consist of two combos- one as damage, one not- and each combo would consist of the animation tiles assigned to it. An Animation Unit, or AU, is a number equal to the amount of time a given cell displays a given combo. For each cell considered here, assume the AU takes on only ONE value- that is, each cell spends exactly the same amount of time in each combo it animates across. This being true, the animation frames and speed of each combo in the cell must be set up so that Frames*Speed = x, where x is the same for all combos. (So, notice, you can vary the number of animation frames, and conserve tiles, by upping the speed.)
Now, let's make a platform that floats back and forth vertically over three spaces. When at least half of the platform is animated over a cell, that cell is a walkable combo. When less than half of the platform is animated over a cell, it is unwalkable. That part is pretty easy. The hard part comes in when you want to set up the combos, especially since we (cough) can't see combo animation in Zquest (cough). You need a way of deciding exactly what combos to set up, and how to link them together.
Consider the following graph. The vertical axis depicts animation over time, with each unit on the axis being equal to one AU. (So every combo in every cell in this whole thing needs to have exactly the same AU.) Each letter on the vertical axis corresponds to a cell in the platform's movement sequence. Here A is the farthest north, and the cells are placed south of eachother in decending order.
http://phantom5.netfirms.com/cellanimation.jpg
(Thanks to Plith for the image hosting)
The intersection of each letter and number correspond to a single combo. The little pictures show you what the first and last tiles of the animation for that combo need to be- you can sorta see how the platform is meant to move. At time 1, it goes from between B and C down to fully on C and then back up to between B and C. Then it moves north until it gets to A, where it does the same thing and comes back. At each time, only ONE of the cell's combos is walkable- the others are STAIRS. (The reason for this will become apparent momentarily) The walkable tiles are set up thusly
TIME----------WALKABLE CELL
1----------C
2----------B
3----------A
4----------B
And this should make some sense. Once you have made all twelve necessary combos, link them together by cell letter. That is, A1 combo-animates to A2, then A3, A4, and back to A1 again. When you place the cells on the screen, you will have to do it by combo; that is, you can't place all of cell a in Zquest. You have to choose a combo from cell A to place. It doesnt matter at which time you choose your combos, but make sure ALL COMBOS PLACED ARE FROM THE SAME AU TIME INDEX. That is, make sure you place A1, B1, C1 or A3, B3, C3... do NOT place A1, B1, C2. It won't look right.
This won't look right at ALL in Zquest, but assuming the combos animate correctly, this should work out fine in ZC.
ANTICIPATED FAQ :
Q: My platform stops and starts; movement is jerky. Seems to pause once per combo.
A: This is unavoidable if you want to use this simple system. The problem is this. Each combo in a cell's sequence needs to have the same number of tiles in order to most simply satisfy the equal AU requirement. Since the combos animate after each other in sequence, if the FIRST tile animated for a given combo is the same as the LAST tile in the animation of the combo immediatly before it in the cell, you'll get a 'pause'. Because that tile will be shown twice. You could avoid this by starting the second combo one tile animation farther on, but this quickly creates a problem because it means you now have to move ALL the combo animations down one tile. This gets complicated as you go farther along in time, and ruins the symmetry of the table. (You'd need, roughly, #of old AU indexes % #of tiles in the animation sequence new AU indexes, I think. But I havnt calculated it.)
Moral of the story- to keep it simple, deal with the little pause.
Q: Why can't I use a PIT combo instead of a STAIR combo?
A: Again, to preserve your sanity. The applicable difference between stair and pit combos is that Link warps when he touches any part of a pit combo, but only when he is totally on a stair combo. Since the cells are only walkable one at a time, if pit combos were used, Link would never get across- he would trigger the pit warp whether he scooted ahead or held back behind. Using stair combos alows link to creep along in half-combo increments- as long as half of him is on a walkable combo, no worries.
You could use pit combos, but then you'd need to redesign the system with another four AU indexes during which TWO cells would be walkable, and adjust the animation accordingly. But I dont see that as worthwhile. If the platform is moving across only three combos, as here, you can easily set the blue square to put him almost exactly where he'd fall through a pit anyway. If the platform was going father, then the amount of extra work would go up even faster... and no one would do that.
Q: Link can just stand still while the platform moves out from under him, and he wont fall!
A: Yea, sadly, this is something that would happen with pits too. The way DN has it coded now, the game only checks for Link being on a pit or stair as part of the collision test, which only takes place when Link moves or is bumped. So if Link stands still, the game doesnt care where he is. HOPEFULLY we can get a quest rule to fix this- assuming there is some way to add a check for Link's current position without slowing down the code too much.
Q: Can't I use a convayer combo instead of a walkable combo, so Link will be pulled along with the platform?
A: Yes... and go for it. Thats a little more complicated, though. Look at the way the platform animates above, and you'll see it currently changes direction in the middle of a combo. In order to make the convayer pull link in the right direction, you'd need exactly twice as many combos- each endpoint in the platform's path needs to be split in two, and every other combo needs to split so the combos all still have the same AU.
ALSO- and someone can check me on this- you need to be sure the platform is moving at the same SPEED the convayer moves at. Otherwise it'll look odd; and Link might get pushed off the edge. I dont know if the speed of tile animation and convayer movement is preserved from machine to machine, either- maybe one slows down more on slower machines. That might cause problems.
Hope this helps working with animated combos, and gets you thinking about other ways to use them, too.
-C
With new combo animation, we can do alot of neat effects, including moving platforms. One easy way to accomplish this would be to make platforms that appear and dissapear while remaining stationary- that one is pretty much a no-brainer of switching between a pit and walkable combo. I've been exploring something a little more difficult- making a platform that floats along a pre-determined path on the screen between two points. Ive found organizing the animation and combos is not something you can just sit down and do- it requires preperation. With that in mind, I'd like to describe the method I've found useful for setting it up.
First, some terminology. A tile is one 16x16 graphic on the tilesheet. A combo is a entity on your combo sheet, including type, walkability, C-set, and a series of tiles that make up it's animation sequence. (These you already know.) A cell is an entity consisting of a series of combos linked together by combo animation. That is, if I was to make a spike that jutted out of the wall, the cell would consist of two combos- one as damage, one not- and each combo would consist of the animation tiles assigned to it. An Animation Unit, or AU, is a number equal to the amount of time a given cell displays a given combo. For each cell considered here, assume the AU takes on only ONE value- that is, each cell spends exactly the same amount of time in each combo it animates across. This being true, the animation frames and speed of each combo in the cell must be set up so that Frames*Speed = x, where x is the same for all combos. (So, notice, you can vary the number of animation frames, and conserve tiles, by upping the speed.)
Now, let's make a platform that floats back and forth vertically over three spaces. When at least half of the platform is animated over a cell, that cell is a walkable combo. When less than half of the platform is animated over a cell, it is unwalkable. That part is pretty easy. The hard part comes in when you want to set up the combos, especially since we (cough) can't see combo animation in Zquest (cough). You need a way of deciding exactly what combos to set up, and how to link them together.
Consider the following graph. The vertical axis depicts animation over time, with each unit on the axis being equal to one AU. (So every combo in every cell in this whole thing needs to have exactly the same AU.) Each letter on the vertical axis corresponds to a cell in the platform's movement sequence. Here A is the farthest north, and the cells are placed south of eachother in decending order.
http://phantom5.netfirms.com/cellanimation.jpg
(Thanks to Plith for the image hosting)
The intersection of each letter and number correspond to a single combo. The little pictures show you what the first and last tiles of the animation for that combo need to be- you can sorta see how the platform is meant to move. At time 1, it goes from between B and C down to fully on C and then back up to between B and C. Then it moves north until it gets to A, where it does the same thing and comes back. At each time, only ONE of the cell's combos is walkable- the others are STAIRS. (The reason for this will become apparent momentarily) The walkable tiles are set up thusly
TIME----------WALKABLE CELL
1----------C
2----------B
3----------A
4----------B
And this should make some sense. Once you have made all twelve necessary combos, link them together by cell letter. That is, A1 combo-animates to A2, then A3, A4, and back to A1 again. When you place the cells on the screen, you will have to do it by combo; that is, you can't place all of cell a in Zquest. You have to choose a combo from cell A to place. It doesnt matter at which time you choose your combos, but make sure ALL COMBOS PLACED ARE FROM THE SAME AU TIME INDEX. That is, make sure you place A1, B1, C1 or A3, B3, C3... do NOT place A1, B1, C2. It won't look right.
This won't look right at ALL in Zquest, but assuming the combos animate correctly, this should work out fine in ZC.
ANTICIPATED FAQ :
Q: My platform stops and starts; movement is jerky. Seems to pause once per combo.
A: This is unavoidable if you want to use this simple system. The problem is this. Each combo in a cell's sequence needs to have the same number of tiles in order to most simply satisfy the equal AU requirement. Since the combos animate after each other in sequence, if the FIRST tile animated for a given combo is the same as the LAST tile in the animation of the combo immediatly before it in the cell, you'll get a 'pause'. Because that tile will be shown twice. You could avoid this by starting the second combo one tile animation farther on, but this quickly creates a problem because it means you now have to move ALL the combo animations down one tile. This gets complicated as you go farther along in time, and ruins the symmetry of the table. (You'd need, roughly, #of old AU indexes % #of tiles in the animation sequence new AU indexes, I think. But I havnt calculated it.)
Moral of the story- to keep it simple, deal with the little pause.
Q: Why can't I use a PIT combo instead of a STAIR combo?
A: Again, to preserve your sanity. The applicable difference between stair and pit combos is that Link warps when he touches any part of a pit combo, but only when he is totally on a stair combo. Since the cells are only walkable one at a time, if pit combos were used, Link would never get across- he would trigger the pit warp whether he scooted ahead or held back behind. Using stair combos alows link to creep along in half-combo increments- as long as half of him is on a walkable combo, no worries.
You could use pit combos, but then you'd need to redesign the system with another four AU indexes during which TWO cells would be walkable, and adjust the animation accordingly. But I dont see that as worthwhile. If the platform is moving across only three combos, as here, you can easily set the blue square to put him almost exactly where he'd fall through a pit anyway. If the platform was going father, then the amount of extra work would go up even faster... and no one would do that.
Q: Link can just stand still while the platform moves out from under him, and he wont fall!
A: Yea, sadly, this is something that would happen with pits too. The way DN has it coded now, the game only checks for Link being on a pit or stair as part of the collision test, which only takes place when Link moves or is bumped. So if Link stands still, the game doesnt care where he is. HOPEFULLY we can get a quest rule to fix this- assuming there is some way to add a check for Link's current position without slowing down the code too much.
Q: Can't I use a convayer combo instead of a walkable combo, so Link will be pulled along with the platform?
A: Yes... and go for it. Thats a little more complicated, though. Look at the way the platform animates above, and you'll see it currently changes direction in the middle of a combo. In order to make the convayer pull link in the right direction, you'd need exactly twice as many combos- each endpoint in the platform's path needs to be split in two, and every other combo needs to split so the combos all still have the same AU.
ALSO- and someone can check me on this- you need to be sure the platform is moving at the same SPEED the convayer moves at. Otherwise it'll look odd; and Link might get pushed off the edge. I dont know if the speed of tile animation and convayer movement is preserved from machine to machine, either- maybe one slows down more on slower machines. That might cause problems.
Hope this helps working with animated combos, and gets you thinking about other ways to use them, too.
-C