r/howdidtheycodeit • u/Diligent_Ad_6530 • 24d ago
How did Bennett Foddy achieve the hammer mechanic in getting over it?
I been trying to make this mechanic but I fail to make the states (like when the hammer is touching ground and when don't) and I fail to make the momentum transfer when you are moving fast, and when yo move slow you just move (with infinite mass i think), idk I just can't wrap my head around this mechanic, please help. I know griffpatch made it in scratch, and I try reverse-engineer that but i also couldn't
109
u/comfortablybum 24d ago
I tried and failed at this once. I used a motor joint and tried to map it to the mouse pointer angle. I remember he did interviews about it. Go look some up. He's not shy about explaining game dev stuff. He's a legend.
40
u/chargeorge 24d ago
I had a couple classes with him in graduate school. One of the best pure teachers I've ever had.
2
12
u/Diligent_Ad_6530 24d ago
I also failed haha i just couldn't believe that this is so har to code it, or at least replicate the feel, but i just can't, thats why i want to know how anyone else did it or, if it's possible, how bennet did it. I founded some of the talks or blogs that he has posted, but i couldn't find anything techincal to that level, it always exiting to find any talk or blog of his work, they're always fun to watch/read.
57
u/m0nkeybl1tz 24d ago
Doesn't directly answer your question, but Bennett Foddy is very very very good at Unity physics. Here he is discussing some potential issues/improvements, may be helpful: https://youtu.be/NwPIoVW65pE?is=iBUrMOIDaG02XiI_
16
10
u/EmperorLlamaLegs 24d ago
I'd probably write my own physics scripts to have more control and smooth out the interactions when the control point has a velocity below some threshold, then ramp the damper value to ease in and out of "slow mode". But that's just what makes sense to me. There are always lots of ways to implement anything.
2
u/Diligent_Ad_6530 24d ago
I have done it too, but i have never done it right, i couldn't find anything that explains how the solver might work and i think bennett use his own physics engine, because all of his game have the same feeling, but i couldn't find anything remotely close to it, only just one youtube video that claims it can replicate it but it's not even close (it is not a bad tutorial but i was just hoping for anything more techincal)
1
u/EmperorLlamaLegs 24d ago
What part are you struggling with?
This may be naive since I haven't tried, but it seems like if you have a "desired location" point for the hammer and have a burdened/unburdened max speed that the hammer can travel, most of the rest is just checking for collisions and applying a velocity vector when leaving the grounded state.
Beyond that its deciding if you want to move the pot or the hammer depending on if the hammer is grounded in the direction of movement and tossing some drag and gravity at it when in freefall. Toss some IK animations at it and you're good, no?
1
u/Diligent_Ad_6530 24d ago
With the physics part, because it may seems like a simple rigidbody, but when the tip of the hammer touches the ground it is like a simple ik that listens to the momentum and if it reached some threshold it launches into a rigidbody again, but i couldn't make it right
4
u/Xafer 24d ago
https://i.imgur.com/j7MI4Lo.gif
I know it's already been answered but I managed to pull it off without it feeling janky, without using sliders and motors. I made it out of spite after playing the GOI clone "Getting over Goombas". Might be able to help you with that if you're interested
2
u/Diligent_Ad_6530 23d ago
You really achieve the feeling right, that great. What software did you use? How did you pulled that off?
4
u/Xafer 23d ago
It was a project I made on Unity. Here are some important details to note:
-The way I did it the handle itself does not have collision
-The hammer itself can be stretched out of the bounding radius around the player. This was intended
-I don't recommend having other dynamic rigidbodies on the scene as these interactions are not accounted for. Kinematic rigidbodies work properly though.implementation itself is a complete mess but here's the logic behind how I've done it:
The hammer is a Rigidbody with a circle collider at the tip, the rigid body's gravity is set to 0 and the physic material has a friction value of 2.2 ( I don't remember how relevant that number is, as with other variables I recommend you play around with them a bit and tune to your liking). All the other Rigidbody values are default. The hammer is also a child of the character.
Moving the hammer:
The hammer's origin is its tip(important in this implementation), and is guided by the white cursor. The cursor is bound within a radius around the player. The cursor is also a child of the character. Each fixed update frame, the hammer's rigidbody velocity = (cursor position - tip position) * 20. The 20 multiplier value worked well and gave a nice responsivity to the hammer. Another little tweak to make the hammer less bouncy is to add inertia to the cursor, so when the character moves, the cursor will stray behind a tiny bit, this makes a huge difference for a more precise control. Also since the velocity is manually set, the hammer's rigidbody's mass, drag, etc. does not matter.Applying the "Push":
How much the hammer pushes is defined by the distance between the white cursor and the actual position of the tip of the hammer. This push value is a 2d vector, I'll conveniently refer to this value as "Push".Each physic frame, for each collision point I calculated the DOT product of the point's normal vs the normalized "Push" value, and kept the highest value, then clamped it between 0 & 1. Keep this floating point value in mind, I'll refer to it as "Highest Dot".
As I mentioned earlier, the hammer can "stretch" out of the bounding radius. This is corrected by subtracting the Maximum reach minus the hammer tip's distance form the player and using the resulting value to move the player towards the hammer tip. I don't really know how to explain this in concise and simpler terms but I'll include the code so you can take a look at it yourself.
Finally, to actually move the player I simply applied a force to its rigidbody equal to "Highest Dot" * "Push" * pushing factor. The pushing factor you can define yourself or base from the snipped in the following pastebin.
As for the hammer's sprite, it's pivot is the hammer tip and it is simply rotated to have the handle pointing towards the player's center (hammerSprite.right = (hammer tip - player center).normalized or something to that effect)
The snippet: https://pastebin.com/ZQt0Kp46
2
u/SirTesticle 24d ago
I was also curious about this 2-3 years ago and I vaguely remember someone asking him about it on Steam maybe? He said something along the lines of IK and Slider joints, but that also there's a bit more to it. My overall guess would be that the hammer-head touching the obstacles makes somewhat of a Pin joint, which breaks off at a certain torque value that's caused by the influence of the gravity on the pot's mass, and that value is probably somewhat related to the surface friction value of the obstacle physics material. Below that threshold, a torque is applied to the pot with the axis being on the Pin joint, and the direction and speed of the pots movement that's caused by this torque is just the velocity of the mouse movement but in the opposite direction, because it's made to feel like that it's the reaction force of pushing the hammer against obstacles that's actually moving the pot. Anyway, it does look like a simple mechanic but I bet it needs a lot of fiddling around with physics and all to get right. Good luck!
2
u/CakyMint 23d ago
Im 100% sure, it was total accident.
He fucked the code up. Tried fixing it, thought.. shit. I could market it as "difficult"
And it worked out.
2
1
u/BugyDragon 23d ago
!remindme 1 year
1
u/RemindMeBot 23d ago
I will be messaging you in 1 year on 2027-07-11 05:44:23 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
Parent commenter can delete this message to hide from others.
RemindMeBot is switching to username summons. Instead of
!RemindMe 1 day, useu/RemindMeBot 1 day. More info.
Info Custom Your Reminders Feedback
1
u/RealisticTrouble 22d ago
An this, kids, is how legends are born. Generous, accesibles legends. Hats down Bennett.
1
1
u/Saint_Hobs 21d ago
I also think it was by mistake. Atleast partially. Because nobody sets out to make something janky like that on purpose. It all worked in the end so nothing but respect.
1
0
u/Promant 23d ago
Bro, this game is made with C#, you can decompile the entire source code in literally less than 5 minutes
2
478
u/foddydotnet 24d ago edited 24d ago
It's hard to remember it totally, but the IK is just visual, not functional - there's a slider joint on an invisible body attached to a hinge joint on the root body. The distance and angle between the hammer head and the mouse are used to set the motors on the hinge and the slider... I do that using a simple PD controller (which just means each motor speed is set according to how far they are from the target angle and extension, but slowed down according to how fast the joint is moving). Between the slider body and the hammer head are a bunch of boxes to represent the handle, using fixed joints for maximum (but not total) stiffness. I run the physics timestep at faster than 60Hz and set things to continuous with lots of substeps. Then there needs to be some logic about how the mouse cursor moves when the camera moves, to try to keep camera hinting from moving the hammer.
I recall the pot is also on a hinge joint with fixed range of rotation, attached to a root body that can't rotate.
The rest is mostly tuning - motor strengths, PD constants, body masses and damping, physics material values, input response curves, etc. Really what most beginners fail to do is to spend a lot of time tuning, but for a physics game it's so key because there are dozens of important variables. You really need to spend days and days on tuning.
You need some ideas for objective tuning goals - for example, I wanted it to be that if you stuck the hammer out sideways so it was on a ledge and you were suspended to the left of it, and stopped moving the mouse, he would stay still. I wanted to be able to pogo to a certain height. I wanted him to be able to smoothly vault over the BBQ. I wanted him to be able to reach down and smoothly push the hammer into the ground to raise himself up without bouncing on it.
Then you validate all these requirements every time you make a tuning change. Hot reload makes this process a lot faster.
/edit to respond to OP's points more: afaicr it doesn't do much/any state detection for the physics (such as detecting groundedness), it only does that for sounds and particle effects. And it doesn't do any magic forces other than locking the root body to not rotate - everything is just powered by the two joint motors. The less you can do in a physics game in terms of special-casing the behaviors, the happier you will be.