Real-time String-Theory, or how I learned to love and apreciate rope-physics in games.

milk

milk

Like Verified
Veteran
I've always found real time string/rope/ribbon physics to be fascinating, but they always seemed to be overshadowed by their show-offy brothers: Rigid-body and Fluid.
I'd like to take a time to apreciate impressive uses, and the evolution of that effect as used in shipped games.

Early examples:

Casltevania Series SNES/PS1/GBA - Whip:

Starting with Castlevania V for the SNES in 1991, the series started implementing dynamic physics to the player character's whip in most of its 2D games since.
Tomb Raider Series PS1 - Lara's Hair:
All early Tomb Raiders games starting with the 2nd implemented dynamic phisics for Lara's hair. I can't remember if other objects also made use of the code, and wouldn't be surprised if it happens to be the case.

Tekken Series PS1 - Kimono belts:
Many character had flailing kimono belts implemented through dynamic rope physicis.

Zelda N64 - Multiple:
This series curiously sprinkled with minor uses of rope physics since its first 3D games. Other notable mentions: The fishing rod and Volvagia's hair in OoT, poweder keg's fuse in MM, ribbons hanging from enemie's weapons in WindWaker as well as the vines in the forest temple.

Conker Bad Fur Day - Climbable Ropes:
This game had surprisingly detailed rope physics for the climbable ropes littered throughout the game. Conker's tail itself seems to animate as some kind of waivy, floaty physics object too.

Can you guys think of other impressive early uses?
 
early uses? nothing really comes to mind.
but TLOU2 has some crazy good rope physics
 
The N64 understandably had an FPU, but for the PS1, were the rope physics purely done on the CPU, or more adeptly the GTE? Also, would precision be an issue on the integer vector based GTE or is it effectively hidden with the low render precision mess?
 
cheapchips said:
Half Life 2 had wibbly phone lines and had power cables you could hook up.
Click to expand...

I remember I was very impressed when I first played the game and at some point you had to plug a power cable to an outlet, ant the cord reacted realistically. Back then, anything of that sort was so unexpected...

I cant't remember what part of the campaign that was, but it looked pretty much like in this test scene:

 
milk said:
I remember I was very impressed when I first played the game and at some point you had to plug a power cable to an outlet, ant the cord reacted realistically. Back then, anything of that sort was so unexpected...

I cant't remember what part of the campaign that was, but it looked pretty much like in this test scene:
Click to expand...

Even was in multiplayer maps. Still holds up today.
 
Some other Oldies:

Super Mario Bros 3 - NES (1988):
Surprisingly convincing dynamic chain-link on the Chain-Chomps. I wonder what shortcuts they took with coding that.


Earnest Evens - Mega Drive (1991):
This game was very technically ambitious, if not a bit janky in the implementation. Many characters, including the player, are built out separate rotating sprites for each limb. The hero has a physics based whip (not unlike many castlevanias) and some enemies are erratically moving worms that have unusually dynamic movement for the time.


The Incredible Machine - PC (1993):
Great physics for the interactive strings.


Worms 2 - PC (1995)
Ninja Rope - Very weird physics and laws of concervation of speed and momentum. Never could get used to it, but hey, its real time ropes that can rotate and bend around the level.


Umihara Kawase - SNES (1997):
Whole game about traversing levels with a grappling hook. The rope can bend around corners within the level geometry, and the character can swing with proper momentum. The rope is also somewhat springy.

 
Last edited:
milk said:
Some other Oldies:

Super Mario Bros 3 - NES (1988):
Surprisingly convincing dynamic chain-link on the Chain-Chomps. I wonder what shortcuts they took with coding that.

Click to expand...
Re: SMB3, thankfully this one has been disassembled; for the curious, looks like the Chain Chomp's code is here:

If you ctrl-f for the word 'link' you'll hit most of the subroutines that calculate the X/Y coordinates of the individual links in the chain.
 
T2098 said:
Re: SMB3, thankfully this one has been disassembled; for the curious, looks like the Chain Chomp's code is here:

If you ctrl-f for the word 'link' you'll hit most of the subroutines that calculate the X/Y coordinates of the individual links in the chain.
Click to expand...

I tried following that, but understanding NES assembly is way above my pay-grade, even if thoroughly commented...

I wish Alex "IsoFrieze" Losego could do a detailed read through of that code as he often does in his "Retro Game Mechanics Explained" youtube series.

Such as this one:

As for chain chomps, I found this video that documents every apearance of them in Mario Games. The Home-Console New Super Mario Bros. versions of the enemy have very good looking chains (5:26/9:18). I couldn't tell if they are drawn as many individual rotating sprites, or just as a textured "ribon" polygon-strip... Mario Sunshine also had a very detailed 3D physics-based chain (1:19 )... Late N64 to early GC period felt like the time in which Nintendo was the most technically ambitious.

 
milk said:
As for chain chomps, I found this video that documents every apearance of them in Mario Games. The Home-Console New Super Mario Bros. versions of the enemy have very good looking chains (5:26/9:18). I couldn't tell if they are drawn as many individual rotating sprites, or just as a textured "ribon" polygon-strip... Mario Sunshine also had a very detailed 3D physics-based chain (1:19 )... Late N64 to early GC period felt like the time in which Nintendo was the most technically ambitious.
Click to expand...

Funilly, as I thought I had completely exausted the Chain Chomp topic, I replayed the GBC version of Zelda Link's Awakening last month, and was surprised to be reminded that that game also featured a Chain Chomp, that not only is present in an early area of the game, but that at one point can be carried along with the player through many portions of the map. It has a pretty varried behaviour and the chain links manage to behave somewhat convincingly, on a measly Game Boy (game first released on the original B&W portable)

Here is such section of the game:


And for completion's sake (hopefully)

 
For something more modern, the most obvious rope based game:


If I'm not mistakeng, this game was light enough to run on the very first iPhone, and was among the first wave of "killer-app" games for smartphones, along with angry birds and fruit ninja. So much so that Google would eventually license the game so all android users could get it for free on an Android device.

And here is another lesser known early smartphone game that still makes prominant use of rope physics: Tongue Tied

 
When Death Stranding was in development, Hideo Kojima had this to say about his then future release:

"The stick is the first tool that mankind created to put distance between himself and bad things - to protect himself," Kojima said.

"The second tool mankind created is a rope. A rope is a tool used to secure things that are important to you.”

"Most of your tools in action games are sticks. You punch or you shoot or you kick. The communication is always through these sticks," Kojima continued.

"I want people to be connected not through sticks, but through what would be the equivalent of ropes."
Click to expand...

Here is how it came to fruition in the more literal sense:


It's a competent if imperfect implementation of rope physics for the purposes of the game. It works decently well as long as you don't try to fiddle around too much and exploit its weaknesses...




DS serves as a interesting exemple for comparison with TLoU2, both being PS4 targeted games. In DS, the rope-env. interactions seem to be way less fine-grained than in TLoU under the hood, while (as long as it is not glitching out) looking very comparable visually.

Instead of achieving smooth rope shapes by bruteforcing the problem with as many physics particles for the the rope colisions/physics (DS seems to segment the rope in the scale of feet, while TLoU seems to do it in the scale of inches (so to speak) DS is smoothing out the curvature between these joints with some aproximation. The obvious guess would be bezier curves, and they might very well use them between non-corner segments, but the look at parts of the rope that "corner-around" env. geometry look like something else. Like they created a specific system for smoothing the curvature around constriction points (which often can look a little "inflated")

As much as this creates pleasant visuals when everything works well, the rougher aproximation shows its face the worst when interacting with intricate geometry. The physics often can't keep up with too many intersescting shapes and will often clip through geo and get stuck in weird places. A possible improvement to it while still trying to keep processing requirements low might perhaps be to dynamically LOD up/down the amount of collision/physics particles and length of segmentation in areas where complicated interactions are detected vs. straighter or non-coliding stretches of rope...

All of this is entirely speculative though, based on eye-balled observation.

On a positive note: it has pretty detailed interactions with the game's dynamic snow:

 
Last edited:
Fury of the Furries, Amiga et al, 1993. Extensible rope platforming with object wraparound and fudgy physics where you could extend it upside down against gravity, but very smooth and great fun to play. This example is weak...

 
Last edited:
Ropes in Contraption Maker
https://www.gamedeveloper.com/design/ropes-in-contraption-maker

This post is a general overview of how I went about implementing ropes in Contraption Maker which is an updated version of a game called The Incredible Machine that I designed and coded way back in 1992. I included the code that I used to implement verlet integration for the ropes along with some of the problems I faced in getting it to work smoothly.
Click to expand...

Reddit thread:
https://www.reddit.com/r/gamedev/comments/4adnlt

From the reddit thread:

I wrote all the code for TIM. Jeff isn't really a programmer - at all. :)

For TIM i just completely faked the ropes when they had slack because the CPUs back then weren't that powerful I was worried that doing anything CPU intensive would really hurt the frame rate. If there was slack in the rope then I just drew a curved line between the two endpoints of the rope.

Here the code from TIM that drew the ropes.

http://pastebin.com/Nn22aWAq

Ugh, looks very ugly. My code style has changed a lot since then. vm_line(..) was part of our Dynamix lib that drew lines. len_dif was how much slack was in the rope.

For ropes that didn't have slack I'd calculate the forces on each of the rope and then add which end pulled which end into a "force transfer array" that I'd process at a later point. Nothing like what can be done now - very simplistic - but got the job done without bringing the computer to a crawl.
Click to expand...

The code he linked, which is aledgedly the one used in the original TIM:

[LIST=1] [*]void do_conic(color,n,x1,x2,x3,y1,y2,y3) [*]short color,n; [*]long x1,x2,x3,y1,y2,y3; [*]{ [*] short cur_x, cur_y; [*] short old_x, old_y; [*] long px, py, rx, ry, nx, ny; [*] long t, c; [*] long temp; [*] [*] vm_lcolor = color; [*] [*]// y2 = y2 << 1; [*] [*] px = x3 + x1 - (x2<<1); [*] py = y3 + y1 - (y2<<1); [*] [*] rx = (x2 - x1) << (n + 1); [*] ry = (y2 - y1) << (n + 1); [*] [*] temp = n << 1; [*] [*] nx = x1 << temp; [*] ny = y1 << temp; [*] [*] c = 1 << n; [*] [*] old_x = (short) (nx>>temp); [*] old_y = (short) (ny>>temp); [*] [*] for ( t = 0; t <= c; t++) [*] { [*] cur_x = (short) (nx>>temp); [*] cur_y = (short) (ny>>temp); [*] if (old_x != cur_x || old_y != cur_y) [*] { [*] vm_line (old_x, old_y, cur_x, cur_y); [*] old_x = cur_x; [*] old_y = cur_y; [*] } [*] nx += (rx+(t*2+1)*px); [*] ny += (ry+(t*2+1)*py); [*] } [*]} [*] [*] [*]void draw_curved_line(x1,y1,x2,y2,len_diff) [*]short x1,y1,x2,y2,len_diff; [*]{ [*] short x_cp,y_cp; [*] [*] if (len_diff > 4) [*] { [*] x_cp = (x1+x2)>>1; [*] y_cp = ((y1+y2)>>1) + len_diff; [*] do_conic(vm_lcolor,4,(long)x1,(long)x_cp,(long)x2,(long)y1,(long)y_cp,(long)y2); [*] } [*] else [*] vm_line(x1,y1,x2,y2); [*]} [/LIST]
 
Last edited:
You must log in or register to reply here.

Similar threads

G
Itagaki talks to 1up about DOAX2 and real-time physics
Replies
4
Views
2K
blakjedi
B
Back
Top