To learn the Godot engine, I’ve started remaking one of my old games in it, Gunlimb.
It was a game I’d made within just a couple weeks back in 2007, back when I was regularly using, and totally fluent in, the Game Maker engine. It was made for a Tigsource B-Game competition, so it was not exactly made elegantly.
The original Gunlimb, made in 2007.
The original Gunlimb didn’t use any physics library as it was using an early version of Game Maker. It projected points (or lines) for each gun and detected the ground, and would push the player vertically until no gun overlapped with the ground. If you aim quickly and overlap a gun with the ground, a larger vertical force would kick in to allow the player to ‘jump’. If the player was shooting, the added force from the recoil would propel them to a higher ‘jump’.
It was very simple. I don’t think it was exactly what I wanted, but it worked well enough for the game I was making and the time frame I had.
If I go back further and think about my inspirations at the time, one of the big ones was a game called ‘Sexy Hiking’ made by a prolific Game Maker game developer called Jazzuo.
In Sexy Hiking (which also inspired creator Bennet Foddy to later create Getting Over It), the player controls the character’s arms with the mouse to use the hammer as a lever to pivot their body, and sometimes launch it with force into the air.
The way this works is that the collision for the hammer is a disconnected circle projected apart from the player. This allows the player to reach around a limb of the tree, for example.
Either the hammer is ‘grounded’ on a solid surface, in which case mouse movement moves the character’s body, or the hammer is not grounded and the mouse movement controls the hammer’s location in space relative to the body.
‘Sexy Hiking’ gif
For Gunlimb, I didn’t do that. My implementation was MUCH simpler. However, it’s been nearly 20 years, and I can get the movement how I wanted it to move instead of, due to personal skill level and the competition’s time limit, I was unable to get it before.
The main thing I really wanted to achieve this time is to allow the player to use their guns as a ‘pivot’, like in Sexy Hiking. Here’s a mockup example of what I mean.
Unlike in Sexy Hiking, however, I want the collision to run down the length of the gun, rather than just the tip. It’s not a climbing game, after all!
So, I need to check the length of the gun for the first collision point, use that as a pivot.
I also need to check for cases where the gun is embedded in a wall, and push the player in the opposite direction of that.
I made a guide for myself to brainstorm possible collision situations and how I wanted to deal with them.
I started implementing this, and got a pretty good prototype of the movement going.
One thing that interested me about this approach is that I was able to get a sort of facsimile of the Sexy Hiking climbing mechanic working. I started getting ideas about levels where Gunlimb is out of ammunition, or has other reason he has to navigate without shooting.
I was fairly happy with the results so far. However, when you’re in the prototype phase, it’s a good idea to try more than just one approach before committing to it! So I thought, I’m not in 2007 any more, what if I used a physics engine?
There are many reasons I avoid using physics engines when physics isn’t the main conceit of the game. I find it can be frustrating to iron out edge cases when a physics engine goes wonky and it’s such a complex library to dig into. It can take a lot of iteration and sometimes there’s no good way to solve some of the unpredictable scenarios that can arise. I think of all the times I’ve seen physics implementations glitch out even in highly polished triple-A games. I especially avoid it when it comes to mission-critical game elements. It’s one thing if a dead enemy ragdoll glitches out, clips into the wall and loudly spasms and flails and makes a squelching noise for ten minutes until it flies into space - it’s another thing if a physics based crate you need to drag onto a button to get to the next level clips through the floor and disappears.
However!
If there’s a single game where physics jank could be welcomed with open arms, it’d be Gunlimb. The original game welcomed jank and glitches - there was an enemy called the ‘Glitchdog’ that teleported, flipped, stretched and scaled randomly across the level at the player.
So, knowing my progress so far was saved in the repository, I scrapped it all and started again.
I removed my line raycast colliders, changed the torso and guns to derive from RigidBody2D and pinned the guns to the torso using PinJoint2D nodes. I got them to rotate towards the mouse with physics forces rather than rotating them directly.
Okay, that wasn’t quite what I had in mind.
Maybe it’ll be fun if the torso rotates if Gunlimb gets knocked out or something, but for the most part he should remain upright.
That’s better.
To achieve this technically, I set the torso to Lock Rotation, and increased its Mass to 240kg.
The guns have a Mass of 15kg.
I also use the ‘Custom Integrator’ so that I can control rotation/translation in Godot directly through code, and set a Contact Monitor to 2 so that I can keep track of active collisions along each gun.
In the gun code, I use the _integrate_forces(state) function to directly set the state.angular_velocity to match the angle to the new aim angle.
To improve the feel of ‘jumping’, I also check the contacts in the gun and see if the angle is pushing the contacts further into the normal of the contacts, and if so, reduce the angular_velocity force to simulate that it requires a lot of force to rotate your gun into a wall as a lever, but it worked okay without this.
A lot of the time when I think back to the games I was making back in the 2000s, I think ‘how on earth did I pull that off with the limited knowledge that I had’. At the time, I was a teenager, and completely self-taught, making games in my weekends and evenings as a hobby. Now I’m sitting on 3 years of formal game development education and 15 years of industry experience, but somehow games seem to take much longer to make.
Like, when I started working on Gunlimb mechanics in Godot, it got quite complicated quite quickly, even though I’m sure I wouldn’t have been able to do back then what I can do now, let alone in such a limited timespan.
The trick was that back then, I took every shortcut I could! In Gunlimb, the collision code was literally just if a gun is overlapping a wall, raise Gunlimb’s vertical position until the gun is no longer overlapping a wall. This obviously limits the level design and doesn’t really ‘feel’ correct in a lot of cases, though I just designed around that.
Sometimes I miss being so scrappy in my 2000s technical approach to game dev. Everything was hacked together and then I’d just work around whatever I got stuck on. I definitely have a better eye for detail now, and I hold myself to much higher standards when it comes to code (an absolute necessity when working with others).
However, this time around, I want more verticality in the level design, and I want it to feel a bit more grounded and weighty. I think the physics approach is the right one, and could lead to some really fun mechanics. I don’t really miss the ‘climbing’ from the non-physics code-driven approach, I think the new approach is fun just bouncing around the level, which is a great start.
I may need to revisit the movement again once the guns start shooting and recoiling Gunlimb, but for now, this is a promising start!
Bonus: I very briefly started working on a sequel in 2008. It never got any further than this video. It looks like my approach to gun movement back then was basically the same as the original - it doesn’t have the Sexy Hiking pivot. I think I was too intimidated to even attempt it, haha.