Swinging rope physics?

[300happy]

I'm a bit stuck on how I would go about making this, so I thought getting some input from you fellow clickers might help.

I'm trying to make a swinging rope, like those found in a lot of platformer games. The rope normally just sits there, but if the player grabs onto it anywhere, they can climb up and down it. If they tap left and right to give the rope momentum, the rope swings both ways and then they can let go to jump off(with momentum of the rope added to their custom movement, of course).

The catch? I can't use non-flash extensions. Ouch.

My current thought was to make a "chain" of active object "rope sections", but I'm having major problems with getting them to position themselves relative to other copies of the same active. (MMF2 has no way to tell it to get the alterable values and angles for the calculations from the rope sprite parent instead of itself, because both are the "rope sprite".)

To get around that, I've now got a bunch of cloned rope sections, all different active objects. It still doesn't look that convincing unless I make the sections really really tiny though, bloating the game filesize. I'm trying to make a flash game, so having 200+ different active sprites in the game's library just for a 200 pixel rope isn't a good use of space. Not to mention it's giving me quite the headache trying to work out how muliple copies of these ropes are going to work.

I have noticed a lot of earlier platformers "cheat" on these ropes by using animations, but those are rather limiting. Only grabbing the tip of the rope instead of the whole rope anywhere on it, and not letting other actions take place while on ropes, which are both things that will happen in this game. So I really need some way to make a system for dynamic ropes.

I'm quite open to any suggestions/examples/ect you all have. Quite honestly, I have a headache and a mess of notes right now, and am feeling a bit lost as to how to get MMF2 to handle the ropes properly.

Ideas quite welcome. I'm going mad here.

[Pixelthief]

just position the player from the node point via sine/cosine functions. You should use an inverse tangent to find the players angle relative to the node and the distance from it when he attaches, store these, and adjust the angle, rotational velocity and distance to emulate the 'swinging' movement. This is how things like the grappling hook in Metroid work

for the animation between the player and the point, one possibility is to use a verlet integrated chain, which is rather hard to implement, or to use a bezier curve, or more simply to just use a chain of active objects that are set to say 50% of the distance from each node ahead and behind it in the chain


In order to reference the multiple instances of the active objects like you were saying you 'couldnt do', you need to use a fast loop to iterate through each object and operate on it, or use the foreach extension to do the same thing even faster.

[300happy]

In order to reference the multiple instances of the active objects like you were saying you 'couldnt do', you need to use a fast loop to iterate through each object and operate on it, or use the foreach extension to do the same thing even faster.

I tried that in my first attempt. The problem is that to do the physics for the ropes, they need to reference their parent rope(the piece 1 unit above them). The thing is that in a fastloop or foreach, I can't do things like this:

Set X position of Chain Object relative to The Other Chain Object That Has ID of XX

MMF2 has no way to say "Do this operation to the current active in the fastloop, but grab the alterable values and position from the other copy of this active object", since both chain sections are the same active object.

I've since had a major brainstorm expanding on my system above, while also simplifying it. The following is a raw dump of my thoughts and notes, with no practice test just yet:

The problem is that the chain is made of the same active objects, so even a fastloop doesn't help. However, I can work around that by having 2 chain objects, alternating down the chain, like so:

Chain Active A - with id of 1
Chain Active B - with id of 2
Chain Active A - with id of 3
Chain Active B - with id of 4
ect.

The result is that now the loops can, in theory, operate on say, ID 3, and grab the values of the "parent" by checking for Active B(which is no longer the same as an Active A) with ID 2. Actions done to Active A will no longer be applied to Active B, and I can get the part above or below the current chain section for the purpose of the relative physics.

This also means that the chain can be made of the same two actives cloned again and again, instead of a billion different actives. I think it will work...I gotta rebuild version 3 of my chain spawning code to test it out.


The vector swinging method was what I first tried, but the problem is that the chain continues past where the player grabs it. It's not a beam shot from the player, it's a dynamic chain, so it quite often extends beyond where the player is located. The end of the rope should not be locked to the player's swinging vector, but should instead be pulled with the rest of the player swinging.


I've got an idea on my papers right now I am currently buckling down to test out that might fix this issue. My idea is to give the chain a concept of a "locked length". Normally, the pieces all freely fall down, attempting to straighten out. When the player grabs the rope, the rope above the player will be set to be locked into that vector movement, but the length below will instead be left in "free swing" mode.

In free swing mode each update the rope checks for if it's parent has "pulled" away from it's last position, and not only updates it's position but also changes it's momentum. In other words, the parent pieces of the rope can "tug" on the lower pieces.

This should, in theory, result in what is essentally a free swinging rope with physics below the player's position, and a stretched out "metroid rope" above them. With the right physics for orbiting the player around the root of the rope, this should work out really cool.

I'm still not sure how to get it to look right. Ideally I would have lines drawn up between the actives, of course, but that's pretty processor intensive to do in MMF2's engine. I think I'll try your idea of giving the actives some form of overlap, pixelthief. With the right length of actives it could look decent enough.

I've got something to do this evening, but between the next hour of this afternoon and tomorrow, I'll see if I can put all this theory to practice. Wish me luck!

[Pixelthief]

you are correct that it is *very* difficult to reference the values of one instance of an object in the expression editor of another instance of the object. However, there is a pretty easy way to work around that- use an array. Thats why implementing Verlet Integration can be so difficult, because it requires an external array to record the positions of objects.


So for example, your might record the positions X/Y of each object into a 1 dimensional associative array, then read from these when positioning the objects. That tends to work great, its just a bit of work to put into code.

Having 2 chain objects is definitely a novel idea, but you could always just have 10 different chain objects and make it a breeze at that



I have a very *rough* implementation I once used of verlet integration to demonstrate what a neat chain effect it can do. Its not the way I'd recommend doing it at all, just food for thought (its quite old):
http://create-games.com/download.asp?id=6889




Oh yeah, and the way I'm doing it in my current project here:
http://www.youtube.com/watch?v=vPKxf4pljUs#t=47s

-My trick is to have the nodes be long active objects (something like 4x24 pixels) which are dynamically resized at runtime to the distance between each node via scaling, then rotated in the proper direction.

[300happy]

How big is the overhead of the array object, if say...there are around 3 of these ropes each with 20 nodes on the screen at once? That would be around 5 array slots per node(X,Y,length,angle,speed), which is starting to sound scary already, even with just 1 rope.

Not saying the solution is a bad one, I probably should have realized I could store the values somewhere else then on the parent object, but the reason size and memory is an issue is that this is for a flash game. The rope actives already are eating quite a bit of the acceptable sprite limit(trying to aim for around 200 objects max) as it is.

-My trick is to have the nodes be long active objects (something like 4x24 pixels) which are dynamically resized at runtime to the distance between each node via scaling, then rotated in the proper direction.

That sounds like a good solution to the "spikey" problem I'm getting when my chain parts are too close together. Thanks! I'll give it a go after I get the prototype rope physics working tomorrow.

[Pixelthief]

err, well an integer takes up 4 bytes, so recording 3 ropes with 20 nodes with 2 positions each would be 3*20*2*4 = 480 bytes. By comparison, a single frame of a 32x32 bitmap image will take up around 3072 bytes.

[UrbanMonk]

If this is flash then you'll want to avoid using fast loops whenever you can.

They pretty much kill the framerate.

[Pixelthief]

really? whats particularly wrong with flash and looping? I mean loops are like the most fundamental part of programming languages

[UrbanMonk]

I'm not sure. I do know that flash is not as efficient as C++ which is prolly why.

The For Each object is a lot faster compared to the spread value method of looping through objects though, so use that and make sure the number of objects is kept at a minimum.

[Pixelthief]

the foreach method is always faster than the fast loop method, as the foreach object will have O(N) and the fast loop O(N^2); but I'm curious as to why loops in general would be (disproportionately) slower in flash. I know due to the overhead of the runtime pretty much everything will be slower in flash than MMF2, but I don't know why loops would offend in particular