|
Posted on 06.14.07 by Mike K @ 11:22 pm
Raigan and I have had an extremely brief dialog on in game ropes. It makes sense, for a while we were both doing rope driven games. Well, due to my failings as a communicator, I sort of just never got back to him. Yet, I absolutely love the topic, and certainly spent much time puzzled by it. Apparently I’ve also made the conscious effort to push my way in to obscurity. My apologies, everybody who’s mailed me. We virtually “ran in to each other” again a few weeks back, in a discussion on 2D game water physics, and so the need to share my thought looms over me again. Now that he’s in blog town, I knew I had no choice, and went ahead with zee said “scooping of theories” out of zee brain, and defaced his blog with it. I hope you don’t mind. The question. How the heck do you pull of physics like that on the SNES!?! As I saw, the discussion is less of a question of how to do a rope, but how do you make a rope work so beautifully on such *nothing* gaming hardware? The following is the slightly edited “shotgun blast to the face” I dumped in his comments. Learn more about the game here. - - - Here we go. My thoughts on how they pulled that off on the SNES, AKA 2-3 MHZ tiled beast. To put things in more perspective, a CPU with 8bit registers, and no internal multiplication or division. However, I think I read somewhere that there was either a hardware multiplier or divider, essentially some hardware address you plug some numbers in to, and several cycles later you can read back a result. This compared to the GBA with it’s 32bit registers, and it’s “so very nice” multiplication opcode. No big deal, it’s only 1 rope. First off, I think the biggest thing they had to their advantage was the tile graphics hardware. All Nintendo hardware except the N64, GameCube, and Wii have tile map 2D graphics hardware. Memory for 8×8 tile graphics, and memory for a map to build from those tiles. So really, you’re either making a tiled game, or your not making a game on those systems. So that means, as far as testing against collision, you’re only testing against easy aligned tiles (surfaces with normals (1,0), (0,1), and the negatives). Our rope, technically only needs to be concerned with things in units of tiles. A 64 pixel tall wall is merely 8 tiles, and only 8 “unit tests” as we interpolate across the line. Also, a locked framerate. So long as we don’t travel more than 8 pixels in 1 frame, we should be able to stay completely stable. Lets also say each tile only finds nearest edges on it’s exposed sides (i.e. no tile adjacent to me, then it’s an exposed side). And an optimization for rope segments, every 2 bends we can put the previous part to sleep. We just need enough memory set aside to support a dozen or so bends. The final big thing is something I ran in to durring my adventures deeper in to physics and maths. Something in math nerd speak called the Manhattan Length or Distance (I forget it’s proper name, I just call it the Manhattan). The Manhattan is a length formula for a line, in much the same way as magnitude (or magnitude squared, how I love thee). The formula is the sum of all the absolute value parts of a vector. I.e. Manhattan = abs(x) + abs(y). No doubt you’ve played with this yourself, and scoffed it off because it’s not an accurate length. That is, except in one key case… When it’s axis aligned! No square root required! (1,0) or (0,1) respectfully, the Manhattan or length is 1, and so would the magnitude. Why is this important? Tile hardware is axis aligned! So as long as we wrap around axis aligned things, our rope segments are accurate. Even if not, so what? Worst case, our rope shrinks a bit going over a slope. You’ve probably noticed how extra bouncy/elastic the rope in Umihara is. My best guess, is it’s because they live with the horrible innacuracies of the Manhattan Length. And truth be told, asuming that’s what it is, it still looks great. Eventually you’ll pendulum your self to a stop whilst hanging vertically. So there you go, Mike’s “how they did Umihara Kawase“. - - - Disclaimer: This is all theory. I’m too lazy to disassemble the ROM. It’s enough for me so that I can sleep at night. Filed under: Stuffing and Technobabble and Opinion and The Spider Comments:
|
your Umihara theory overlooks some of the key mind-blowing features of that game:
-non-axis-aligned/arbitrary sloped surfaces, including acute corners! (which is something mario never had)
-conveyor belts: we’re still trying to figure out how to simulate these well — any of the arbitrarily-sloped edges of the world can be a “conveyor belt” which will move the grapple along itself, around corners, etc..
-both ends of the rope are simulated; when you’re attached to an enemy or a moving platform (in later levels there are platforms which you can pull up/down!) both ends of the rope “swing”
The rope is really short, so no matter how much work they need to do, there will be at most maybe 8 “bends” in the rope. Still, it is _amazing_ that they got that working so well — we haven’t found any collision/sim glitches yet. Whoever programmed that is a genius!
p.s - you used the past tense.. you’re not making the rope game anymore?! why not?!?!?! damn it!
p.p.s - some technical info on umihara.. not really useful though: http://tasvideos.org/UmiharaKawasePhysics.html
Comment by raigan — June 15, 2007 @ 6:15 pm
> non-axis-aligned/arbitrary sloped surfaces
This is something, after thinking about it, I suspect isn’t a big deal. The so called “Manhattan Length” still works for horizontal/vertical, diagonal and in between lines, but it will report a longer distance than magnitude, so normalization ends up making the length just a little bit less than 1. If that turns out very rigid looking, give the rope some “give” to it, like using a .25 or less instead of .5 on each end to solve a spring. Eventually, you’ll make it to equilibrium, and everybody will think you’re a mastermind.
Hehe, I’m soooo very tempted right now to throw together a little prototype of this.
. I have a strange suspicion the entire rope, Umi-style, can be done with no roots and only 1 division. I doubt it’s something we don’t already know of, just aspects are handled by clever tricks you use on crap old hardware. Reciprocal tables instead of division, shifts for cheap doubling/halfing, fixed point instead of floating point.
> conveyor belts
Ah yes. I forgot about those. Well, that just goes to show that either A. They don’t sleep the rope, or B. you sleep it in the middle. If you’re right about the 8 bends (another nicety of the tile map), then the need to sleep part of the rope is irrelevant. Perhaps it’s not so much sleeping, as it is just creating a list of bend points, and you only deal the bends on the outskirts (first and last). As a bend no longer bends, the next one (or previous respectfully) becomes the bend of note.
I’m also making the assumption that the rope is solved as a whole rope, at least given my less than satisfactory results with a segmented multi spring rope where each segment has an individually solved length. Individual segments are fine for a “rope ragdoll”, but not so good for a bent around edges rope.
> your blog post uses the past tense.. you’re not making the rope game anymore?!
Well, like you guys with N and N+, I have my little game PuffBOMB, while nowhere nearly as successful as N, it has proven itself. With my rope game, while I have control scheme I like, I lack a well developed universe/mythology or such. PuffBOMB as a concept has been stewing in the noggin’ and sketchbook for 4 years, since I made the original prototype game in 2003.
I started the rope game because I thought it suited a game pad better than PuffBOMB (a previously mouse driven game). It did, but I decided I could probably make PuffBOMB work. Why waste 3 years (at the time) of notes and ideas by not doing the remake. So I did that, and added a variant that works better on a pad. It wasn’t really a radical shift either. We simply started making PuffBOMB appropriate content using the tools.
And besides, there’s nothing stopping me from using ropes or ropey things in PuffBOMB. I love the idea of tethering things or the character to a bungee cable. Paddle ball with explosives.
And you bring up a good point, I don’t think I ever actually announced I was “back” on PuffBOMB via my blog. I just sort of invented new topics to confuse my 2-3 readers.
Anyways, the specifics we can take to e-mail (or try to), so long as I’ve not completely lost your interest as of the switch.
> Umi-link!
Cool! Thanks for the link.
Comment by Mike K — June 15, 2007 @ 6:33 pm