Reflecting on the What Thou Art project from the beginning of the trimester, the project introduced some interesting scripting problems specific to the Mario formula. Everybody knows how Mario operates, but its subtleties make it a challenge to migrate into Unity.
One of the first and foremost problems I encountered creating the controls was how to create a jumping system that feels as fluid and predictable as Nintendo does. Unity’s physics system allows me the ability to apply forced onto “Mario’s” RigidBody component. Further, I can implement drag to stop it from gliding throughout the levels.
However – with that Unity provides in its physics engine, developing a natural feeling jump system was impossible. By applying drag onto an object, it just moves slower while in the air. Increasing the gravity or mass of the object means it can’t jump as high, and increasing the jump force doesn’t prevent it from being able to glide as much as the RigidBody allows. It occurred to me that Unity’s physics are not a good fit for this style of project
I locked the jumping system so that the player can only jump after hitting the ground (like in Mario). Using Unity’s physics system to apply forced onto the AI wasn’t the ideal implementation, and contributed to the project’s poor controls.
Additionally, in Mario the only direction you can move to reach the end is right. Naturally, this means that the camera can only move right as well. I locked the camera movement so it only moved one way.
Here, I compare the camera movement so that the camera knows it if is moving forward or backward. If it’s going forward, the camera will move forward too.
Despite the project not getting finished, this project was an interesting problem to solve. How we take mechanics from one engine to another is always a challenge and finding the right mix is key.