This was an extremely productive week for me. I made strong progress in many areas of the game including AI, camera, the grapple mechanic, alarms and player movement. I built on the camera auto rotation mechanic I was working on in week 2. This involved using ray casts extruding from the player to anticipate occlusions of the player and swing to avoid them. I fixed this by making the direction of the rays relative to the camera’s back vector rather than the player’s. The rays should be relative to the camera because the camera is the object that needs to swing around, not the player. I also implemented a weight system to supplement this. This weight system gave a greater influence to rays that were closer to the edge of the set of rays. With this weight system, the camera could better react to sharp turns. Additionally, if the player walks between 2 pillars, the weights will act so that the camera is pushed behind the player and then will cancel out. To further improve the camera system, I implemented a free walk zone. This is a small zone in which the player can move freely and the camera will not follow. This makes the camera appear less jerky by ignoring small movements. After some trial and error, I also developed another auto rotation mechanic for the camera which aligns the camera behind the player when the player is not touching the right analogue stick. The purpose of these automatic camera movements is to make the game playable without having to manually rotate the camera, which should only be necessary to give the player more precise control. Navigating narrow corridors or grappling across chasms could become quite difficult if players are constantly having to manipulate the player character and the camera. I still need to do a lot more work in this area to make the camera smoother and more predictable. The AI were given a more effective means of searching for the player after losing sight. Previously it would be easy to avoid a pursuing guard by dashing around a corner. But now, guards will go to the player’s last known location and sweep left and right to search for the player, making them much more effective. I also worked with Zac on the more robust visual detection function which works by passing in transforms for the player character’s head, hands, feet etc. The function then determines what percentage of these is visible by the guard and uses this percentage to scale how fast the detection meter fills. Zac did most of the coding for this, but I made it integrate with the other parts of the plugin. For the security system, I thought it would be neat for the alarms in the level to match the flashing red and blue lights that Conrad’s guard will use when chasing the player. I quickly threw together an alarm light which swirls around and can be triggered from a script. For a stealth game, some might argue that it is beneficial for the player character to have the ability to sneak. Therefore, I implemented crouch functionality. But first I had the cleanup the player movement script which had become messy and bloated from poor coding standards and legacy code. I took some time to clean the script up before implementing the crouch. The crouch scales down the player’s capsule collider and currently also scales down the player to simulate crouch since we don’t have the appropriate animation yet. If a player jumps, crouch is immediately deactivated, and crouch cannot be activated while grappling.
Finally, I spent a significant amount of time working on the grappling system in the game. Too much time. Initially, we wanted the robot arm to be physics based and move towards the grapple points. This mechanically worked but unfortunately looked incredibly janky. After experimenting with joints, I attempted using inverse kinematics on the arm (very difficult on a non-humanoid rig with 20 bones on its arm) and even attempted steering to drive the arm bones towards a target. During some attempts, we managed to get the positions of the bones correct but not the rotation, resulting in the arm looking flat in some directions. Eventually, it was time to call it quits on the dynamic arm; it was simply eating too much time. We decided to opt for a traditional animation approach instead. The arm would move up towards the character’s head and a cable would shoot out from the hand to the grapple point. I created a cylinder object that could scale, rotate and position itself between 2 points. I set up texture scaling on this cylinder so that as the cable stretched out, the textures would correctly tile themselves. I shifted the anchor point of the joint between the grapple point and the player to be on the player’s hand. Scott game me animations to test for walking, idle, jumping and grappling. Grappling looked great with the new animation. However, I knew it could still be better. I ditched the cylinder in favour of a line renderer. Initially, it looked almost identical. But using a line renderer gave me more control, such as adjusting the weight curve for the line. I thought about how the line renderer could give the cable a curved look as if bending relative to the player character’s velocity. I added a third point which had a height between the start and end points, and its x and z were lerped towards the grapple point to simulate the bend. I then passed these points through a smoothing function which adds additional points to make the line curve smoother. After testing the mechanic, I further improved it by adding one more point just after the start point so that the cable must first come out of the hand straight before it can start curving away towards its target. This prevents clipping with the claw and created an effect that I am very satisfied with.
0 Comments
Leave a Reply. |
AuthorContrary Scholars ArchivesCategories
All
|