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

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.