If you read the thread (and the old one) you will find many explanations how the animations are done.
It's procedural/physical animation.
If people are interested, I could go into more detail. The very basics of it is very... basic. You only need two functions: one to determine the distance between two points and one to give the direction as a vector from one point to another. With that you can emulate "chains", i.e. points moving about freely but being stuck to other points at certain distances.
So in my game, the player consists of two such points (upper/lower body) and the lizard consists of 3. Then I attatch to that additional points for limbs and so on. For example the tails of the creatures are several such points chained together.
On top of this stuff I draw the creatures, using simple sprite mechanics such as rotation. For example, the arm of a creature is drawn at the shoulder and then rotated towards the location of the hand point.
This is the reason why the creatures are one, solid color. In fact they consist of several sprites overlapping each other in awkward ways, and if there was any kind of shading on the sprites this would be visible. If I worked in a more reasonable software I could compile the whole body of the creature to one picture and then shade it, but I'm not, so the flat colors are staying. Instead I've tried to adapt my style so that it'll look ok.
When it comes to the more specific movement of limbs and so on it's a great deal of faking going on. The lizards for example do not grab on to stuff and pull themselves forward. Instead they move about with a magical force pushing them in whatever direction they are going. When a limb is too far behind the body it goes into a "search mode", looking for possible grasps in front of the lizard. Such a thing might be a wall, a pole, a platform or whatever. When it finds one, the limb connects to it, and then passively stays there until it's left behind by the body again. The magical propulsion force of the body is dependent on how many limbs are currently connected to terrain, making the speed of movement uneven and synced to the movement of the limbs (few limbs grasping - slow movement of the body).
If there is demand, I could make a more in-depth technical tutorial.
Pixel characters are most often a square moving against other squares, with
fluid animation painted onto it. However, you can still somewhat feel that
the character is a box, mathematically. I have tried to create a character
that looks like pixel art, but moves much more fluently, and has a body that
actually is affected by the surroundings. I still want to keep the levels blocky
and grid based though, to create an interesting contrast and put emphasis on
the softness of the character. Please tell me what you think.
Technobabble
If you have to mathematical points, each with their velocity vectors, you can easily create a "stick" with different elasticity. You do this by locking the distance between the points. If the points are further away from each other than your set distance, you move their positions and velocities towards each other, if too close you separate them. By making the force they're bound to each other with weaker, you get an elastic "rubber band", and you can also let one point do 70% of the movement and the other 30%, creating different weights for them. What you need is a function to determine the distance between points, and a function to create a vector pointing from one point towards the other. This is the basis of what you see in my demo(the creatures are mathematically boxes moving like this). From there I just improvise, and fine-tune the numbers like crazy.
Technobabble #2I won't go into how to make a box collide with rectangles, beacuse I know that you can find a lot of stuff like that all over, and my solutions for this are a bit horribad. I will also assume that you know what a vector is, and that you know how to implement gravity and stuff like that. What I'm going to show you is how to create "atoms" or whatever you want to call them, that is points that are connected to each other to create a simple physics simulation.
So, assume that you have two points, Ax, Ay and Bx, By. These points also have velocity vectors, sAx, sAy and sBx, sBy. By adding the vectors to the positions you get movement, as you probably know.
You now need to create two functions, one to determine the distance between two points(I'm going to call mine diag, from diagonal) and one to create direction vector pointing towards a point. That is a vector with a total length of 1.0, only indicating direction. This can also be used for a lot of fun stuff, such as gravity wells and so on. I'm gonna call mine moveToPoint. These functions are heavy on the processor, so use them sparsely.
So this is what we have so far:
function diag(point1x, point1y, point2x, point2y)
rectHeight = ABSOLUTE(point1y - point2y)
rectWidth = ABSOLUTE(point1x - point2x)
diagonal = SQUAREROOT((rectHeight * rectHeight) + (rectWidth * rectWidth))
return diagonal
function end
function moveToPoint(point1x, point1y, point2x, point2y)
point2x = point2x - point1x
point2y = point2y - point1y
diag = diag(0,0, point2x, point2y)
if diag>0 then
dirVecX = point2x/diag
dirVecY = point2y/diag
else
dirVecX = 0
dirVecY = 1
end if
return [dirVecX, dirVecY]
function end
Alright, let's move on. This part is simple, every frame do this:
function newFrameMovePoints()
Ax = Ax + sAx
Ay = Ay + sAy
Bx = Bx + sBx
By = By + sBy
sAx = sAx*0.98
sAy = (sAy*0.98) + 1.2
sBx = sBx*0.98
sBy = (sBy*0.98) + 1.2
diag = diag(Ax, Ay, Bx, By)
rtrn = moveToPoint(Ax, Ay, Bx, By)
dirX = rtrn[1]
dirY = rtrn[2]
getToDiag = 17
Ax = Ax - (getToDiag-diag)*dirX*0.5
sAx = sAx - (getToDiag-diag)*dirX*0.5
Ay = Ay - (getToDiag-diag)*dirY*0.5
sAy = sAy - (getToDiag-diag)*dirY*0.5
Bx = Bx + (getToDiag-diag)*dirX*0.5
sBx = sBx + (getToDiag-diag)*dirX*0.5
By = By + (getToDiag-diag)*dirY*0.5
sBy = sBy + (getToDiag-diag)*dirY*0.5
function end
What you see is, separated by the empty rows: Adding the velocities to the positions, applying air friction and gravity to the velocities, retrieving the data necessary for the "binding" of the two points, and finally applying the bond. The points are now freely moving, but will always keep the same distance to each other, and forces applied to one point will realistically transfer into the other. As long as you draw the points
after this has been done, they will always be displayed with the correct distance between them.
You see the "0.5"s after each row in the last section? Those mean that if there is a difference between the desired distance and the actual distance between the points, this point will stand for 50% of the movement made to correct the distance. If you tilt those numbers, so that for example point A stands for 85% of the movement and point B for 15% it will appear that B is significally heavier than A. If you make it so that the sum is less than 100% you will get an elastic bond, like a rubber band. You might want to tone down the movement of the actual positions in this case, and focus on the velocities. Other interesting choices you can toy with is to only affect the points if they are further away from each other than the desired distance, or only if they are closer.[/size]
Once you get the basics to work you can start connecting bigger structures of dots together, playing with the parameters.
This is created with this technique only. For example you can create an array of dots, each connecting to the next one, and you have a rope! Fix the first node at your mouse position and whip away. This is also the tech behind my unfinished mega project
freethinker, which brings me to another very important piece of advice; never start a mega project!
I hope this is helpful to you, and that I hit the right level (don't really know how much 80 hours is, it depends a lot on what you're using). Please do not hesitate to ask further questions.
Community
