Tag Archives: Game

Managing Interactive Game Props

An interactive prop in a game would be any animatable object in the game world that a character interacts with. As an example, to implement a player turning a valve, the player must be positioned at the right place with respect to the valve. Both interaction animations (prop – ‘valve turning’ the player – ‘turning valve’) must be played in sync with each other. What programming needs to implement this:

  •  Some sort of locator node in the prop rig to determine the position of the player with respect to the valve. On pressing the ‘interact’ key somewhere close to the prop, the player will be interpolated to the correct position.
  • The player animation and valve animation, both should be exactly the same in length. These can be played when the player is at the correct position.

The last time we used interactive props, the animators were setting this up manually. The process would involve importing the prop rig (exposing potential naming conflicts) and manually placing the tag in the prop rig at the correct position. Once the prop and character have been animated, they would need to saved out into separate files. This is a very time consuming and error prone process. The ‘Interactive Prop Manager’ tool was created to automate all this for animators. On the surface, the tool allows the animators to import a a prop into an animation file and work on the character and prop in the same scene in Max. In our example, the valve rig can be imported into the player rig scene and the animator can animate the interaction.

propMgr

Step 1: Import prop – opens a file browser window to select a file. On import, the prop is placed in the scene using the character reference tag present in the prop file. This step also renames all the nodes in the prop file with a prefix to separate it from the character rig nodes for easy identification.

Step 2: Animate – Animator animates the character and rig.

Step 3: Export Prop – saves out the prop file as its own separate animation. The thing to consider here is that in the prop file, the prop is at the center of the scene, while in the character file, the prop would be offset due to the interaction. This offset is calculated using a non keyable prop root control curve. The prop root control curve will always stay in the center of the prop rig and can be used by the animator to place the prop within the the character rig file. The offset between the player reference tag and the prop root control curve will be the amount the prop scene would need to be moved in the prop rig after export. This offset will also move the player reference tag to the correct position.

prop_rig

the prop rig file

player_rig

the player rig file, with the prop imported and offset based on ‘player reference tag’

Input.GetAxis vs Input.GetAxisRaw

I recently started getting into some Unity programming with C# and was working on a character controller script to make a simple box move on a 2D plane. I was using the Input.GetAxis method to read the input from the keyboard. After a little bit of playing around, I wasn’t satisfied at all with the way the character was moving, it seemed like there was a little bit of delay when the key was pressed and also when I let go of a direction key, the character still moved a little bit as if it had some momentum. None of the physics settings seemed to fix this issue. After a bit of digging around, I found out that it was not the physics that was causing the sluggishness and over shooting, it was the input method. The Input.GetAxis method contains an inbuilt smoothing filter which automatically smooths out the key press. This means that the function won’t give an immediate full response to the key press, the return value will gradually increase from 0 to 1 as the key is pressed and decrease from 1 to 0 as the key is let go. I personally find this smoothing quite annoying and it feels sluggish for the kind of movement I want. The alternative is to use the Input.GetAxisRaw which gives a 1 when the key is pressed and a 0 when it is not. Simple and straight up.