Mechropolis: Grab & throw
|
Another week has passed and a lot of work have been done. This week I’ve been working on correctly throwing the player (and to some extent, the robots). “Throwing” the player involves applying a high amount of force in a certain direction once when the player touches a thrower-fusion robot. This was easier said than done though as a few complications occurred. First, as a minor detail, the scale in which force is added to the player controller is as of now undetermined. As a Unity CharacterController isn’t really based on a RigidBody , then the values becomes blurred. UFPS (A plugin for FPS functionality) manages this by abstracting the value we put in its AddForce down to a CharacterController.Move call, whose units doesn’t exactly represent the same as a RigidBody.AddForce call.
Nevertheless, a sweet-spot value can be reached by tweaking the value, and once it’s reached then (assuming final) it doesn’t matter what it represents. The bigger problem was that the player behaved seemingly random when being thrown; sometimes being thrown straight up, sometimes as expected and other times achieving far less in distance than wanted. At first I know it had to do with collision, so I disabled collision on the character controller, which is also unconventional as there is no collider attached to it. Instead supposedly CharacterController.detectCollisions is to be set to false in order to disable collision checks, but in my case it seemed to still cause jitter as if it wanted to push itself out of a wall. After much troubleshooting it became apparent that UFPS utilized its own physics calculations for certain aspects, such as controlling if the player is standing on solid ground and compensate for various encroaches. A simple fix was made and the player finally fully disabled collision and now behaved as expected when thrown! The results are actually quite good for a first draft. The distance and height has to be tweaked but it works solid. Throwing a robot is still in the works, but a pretty good variant exists as of now. The problem is that it is too random whether it collides with the thrower-robot. The reason it is okay to disable collision on the player is that the player doesn’t normally notice this (being a first-person game), but the robot would clearly be noticed clipping through, even more so as the player often is directly in front of the action, throwing the small robot herself. As of now it looks like this: Another small improvement I’ve made this week is redoing the grab-throw functionality of the player. A core mechanic of the game is being able to pick up robots and throw them, therefore it is vital that this functionality works more or less flawlessly; it didn’t. I recycled and used the UFPS grabbing mechanic, but I found it far too inflexible. It worked by directly attaching the object to the player and then performing a set of checks on whether or not it should be dropped (e.g. colliding with a wall), but it didn’t work quite as well as one would hope. Physical collision became distorted and object could fall through floors or get stuck in walls. Picking things up also became an annoyance as once it got stuck in the floor a series of quick movement had to be made to get it back up. I solved this by replacing this manual approach with a simple SpringJoint . Some new problems exist, such as the object not being centered when grabbed, but in its entirety it works much better! Fixes are in the works so that mechanic becomes much more stable. |


