The core premise of the game was that the player controls a dipole magnet, rotating it around a central pivot to manipulate their velocity and traverse the level. Because a significant portion of the movement is entirely driven by magnetic interaction, perfecting the system became an important part of the character controls.My first implementation was intentionally simple. It applied force along the direction between two magnets’ normal vectors, with the magnitude attenuated by distance. This was enough to validate the core concept, but the system lacked both simulation depth and gameplay intent.

Basic First Implementation

Once the first implementation proved viable, I looked into how magnetic forces behave in the real world. I looked into the Lorentz Force Formula, which describes how electric charges interact with magnetic fields. In reality, magnetic fields emerge from enormous numbers of moving electric charges, but fully simulating that behavior would have been unnecessarily expensive and overly complex for the needs of the game. Instead, I simplified each magnet into a single representative charge while preserving the physical relationships most relevant to gameplay.The most important takeaway from this research was the relationship between force and velocity. In real electromagnetic systems, faster-moving charges experience stronger interactions due to a faster rate of transfer. This concept translated naturally into the game, since players are constantly entering magnetic fields at different speeds and angles. Basically, more relative velocity produces more force.Using these principles as a reference, I rewrote the magnetic force calculations to more closely resemble real electromagnetic behavior. It was certainly more realistic...but that was a bit of a problem. At this point, the formula was not altered in any way to accomodate gameplay. We wanted the game to have a sense of finesse where players could master the controls over time. The reality is that physics is hard to predict and not always fun to control. Players struggled to control their left and right velocities and their movements would feel sluggish when trying to change directions. Other features were added to assist with player control, but I still wanted to adjust the formula to better accomodate gameplay.The final implementation focused on preserving the physical inspiration of the system while shaping it around player readability and responsiveness. I added padding and clamping to create consistency. This was especially important for the distance attenuation. A mathematically accurate inverse-square force created dramatic acceleration near magnet surfaces, which made platforming feel difficult to get a read on during fast gameplay sections. To improve horizontal control, I also incorporated a 2D cross product between the player magnet’s velocity and the target magnet’s normal vector. This allowed the force magnitude to scale based on how perpendicular the player’s movement was relative to the magnetic surface, giving players more deliberate control over lateral movement while inside a magnetic field. Not pictured, I also do an occlusion check between the two magnet surfaces. This occlusion check is between 0 and 1 and is multiplied with the final result.By the end of development, the system had evolved from a simple force simulation into a movement system that was better designed for predictability, responsiveness, and player mastery. Although the final implementation still draws heavily from real-world principles, it has been tweaked to provide a better gameplay experience.

Final Magnetic Force Implementation

At the core of the game, the player traverses levels using magnetic forces. However, not every surface in the environment is magnetized, which raises an important design question: how should movement work on neutral surfaces?Movement in magnetic fields is heavily based on rotation, so I wanted neutral traversal to follow the same principle. Keeping both systems centered around the concept of rotational control helps create a more cohesive and consistent control scheme throughout the game.This led to concept of using physically based foddian mechanics for neutral surfaces.

Creating a system like this came with a slew of challenges based around physical logistics. Before any of that, I needed a baseline implementation to try out. I created a software cursor and made it so the players negative charge always pointed toward it.

Basic First Implementation

While this first implementation works well for moving the players character around, it was ultimately too naive. I realized that modifying the transform.rotation directly was a mistake, as it caused numerous physics bugs. If the player rotated too quickly while overlapping walls or floors, the physics system would calculate extremely large corrective velocities that created unruly behavior. In cases where this wasn't occurring, there was still a problem. Similar cursor motions could produce very different player velocities, making the controls feel unreliable.

Large Velocities Physics Issue

The solution I used for this problem was to replace the direct rotational changes with a physically based torque system. Instead of modifying transform.rotation to point towards the software cursor, I used custom torque forces on the rigidbody to point towards the software cursor. I also had to implement damping to the torque to prevent oscillation and overshooting.This method has an additional benefit of making the rotation feel significantly more tactile. Previously, players would rotate toward the cursor at the same lagging rate, even if colliders were in the way. With torque-driven rotation, colliders naturally resist movement when rotating. This creates a sense of weight to the player character and adds a sense of depth to the feedback of the controls.

Physically Based Rotation Implementation

Throughout gameplay, the player is constantly changing between states that affect their controls. On neutral surfaces the player should be able to push themselves off of surfaces by rotating; however, on magnetic surfaces this behavior is not desired. The project has numerous collision queries to provide information for state changes and provide limitations that simplify the controls.In order to detect neutral surfaces, I first use a capsule collider to query for any overlapping surfaces flagged as neutral. Then, I do a raycast between the closest point along the neutral surface and the closest point along the player's collision. This is done to prevent conflicts when moving over the area where neutral surfaces transition into magnetic ones. Whichever end of the player is closest to either surface dictates which state the player is in.

The player is a dipole, meaning both ends of the player has a different magnetic charge than the other. Early implementations ran into problems where players laying sideways or attempting to rotate in a magnetic field would see unpredicatable velocities. The reason for this, was that both magnets had a radius of effect that was unrestricted by direction. To create more predicatable movement and allow more intentional control, dead zones were put into place for each magnet's radius of effect. A dot product is checked before calculating any magnetic forces, and if it fails a certain threshold it is disregarded and skipped. Additionally, the dot product is used in affecting the force strength. This allows players to use the edges of their range of influence to get smaller boosts, as well as smoothing over the transition between net zero forces and repel magnetic forces.

The neutral player state actually requires additional queries. One of the most difficult issues to solve with the movement was a logistical one. The player moves by rotating, as that is what pushes them against the ground. However, this comes with some problems.If players rotated extremely fast into the ground or walls, the physics system would output extremely large velocities. Slowing down the torque prevents this but also makes the player unable to move much at all. It also prevents the player from being able to react with quick rotations within magnetic fields. The solution involves dynamically changing the player's torque based on results from queries.My solution is simple, but has proved to be fairly effective. Raycasts are performed on the lateral vectors of a magnets direction. If both of these raycasts detect a surface, the players torque is slowed down. When only one or none of these raycasts return a hit, the torque interpolates back to its regular speed.

I wanted to add more platforming elements to the game. I also wanted to add ways for the player to have more corrective control for their movements. I prototyped 5 main concepts for additional movement for the player character.

- Welding
- Launching
- Burst Projectile
- Bumpers
- Grappling