Movement mechanics

Almost the first time doing serious bipedal movement mechanics and animation. Let’s make a first step into the complex character animation (or not). Anyway, here’s the workflow. Honestly, once I’ve been involved in such an affair… And things did not go very well, but that was then. Anyways, now is the first real attempt to create an acceptable bipedal character movement animation and mechanics. First, I’ve made a complete redesign of an old version of movement mechanic, which was a special pawn and was very hard to use. Well, now it looks shiny and new, now this code goes to a new separate mechanism — LBCharacterWalkMovementMechanism, which is now based on LBCharacterMovementMechanism (empty at the moment, lol) and conains all the code, needed for performing pawn movement and blending the animation. It also has all parameters, which are used to regulate pawn’s speed and acceleration.

walk_movement_mechanism

It has the forward speed parameter and a forward speed coefficient to handle forward speed, same to the sidestep (strafe?) speed. Also it has accel rate, which is used to speed the pawn up, when it wants to run. Another important thing here is the angular speed, which is represented by angular speed parameter and an angular speed coefficient, which are used to handle pawn’s rotation. Also it has move direction, which is used to point the desired movement direction. It’s worth noting, that pawn rotation is quite an interesting task itself (later on this). Second, I’ve made several frames of animation for the character, the walker (xw_char). It wasn’t easy, because someone’s left in it’s feet only one bone. Maybe it was even me. Anyways, there are two fairly appropriate animations sequences:

  • Simple walk animation:
  • Simple run animation:

Other intermediate and supportive animations are quite crappy to be shown here. It should be noted that I used the walk and run cycle tutorials by Richard Williams as a reference (found all over the internet) for my walk and run animations. As a result, we’ve got the following animtree:

Where BlendByAngSpeed node does blending between middle, left and right turn sequences and BlendByFwdSpeed node does blending between walk and run sequences. Also, while blending between walk and run is quite a simple task, but blending between rotations seems to be more complex. Using unique animation sequences turned out be the best way to solve this problem, others, like using direct bone rotations may cause weired effects in my animtree during blending between states, for example. Finally, we’ve got the result, let’s see how does it look all together:

  • Walk and run animations in game:
  • Turn and turn in place animations in game:

However, complex tests reveal some flaws, like minor body jerking and leg rattling, also there’s still no jump and sidestep implementation. And ofcourse, the camera is terrible, but controlling with joystick (gamepad) partially solves the problem. Nevertheless, in general it looks not too bad.

 

«The Cave» level, step three

The third step of level design. Some interactable objects were added to the level. They are: inventory objects (items which can be picked up), movers, carriers and immovable interactable objects.

Many of these objects don’t have meshes at this time (placeholders are used), but for some of them I’ve developed 3D models.

Placed in the level they look quite satisfactorily (from a far distance of course).

Later I’ll be compiling the scene once again, because of totally crappy lighting and unwanted gloss. And yes, I found a way to make some parts of the scene brighter or darker.

«The Cave» level, step two

The second step of designing the level. At first, some smaller rocks were added. They don’t look nice in themselves:

But a propper texture, a nice illumination and a suitable environment made them look pretty good, at least for now. Then, some foliage was added to the level. They are some ivy branches, which I’ve made recently:

This foliage doesn’t look good too, especially the leaves, but I think it’s okay for now. Finally, these simple things made the level look live. But water is still no good – I think I’ll just use one of my old shaders to keep the haemorhoid away. On the next step, gameplay elements are going to be added.

How it looks all together:

And the perspective:

«The Cave» level, step one

Here’s the first step of development of the level «The Cave». Water, rocks and sand were added. Next, some detailes, such are small rocks, stones and foliage are going to be added to the level.

How it looks:

How it should look:

Interaction mechanics

Lets make another step into a complex interaction system. The final target is the ability to interact with most objects in the level. There are many possible kinds of interactions. As I see, they are:

  • Pick up, hold, drop down (charater->object)
  • Enter, stay, leave some area (character->world)
  • Touch, hit some object (characters<->objects)
  • Intersect the line (ray) (characters<->objects)
  • Triggered interaction (player, script->characters, objects)
  • Conditional, programmed (script<->characters, objects)
  • Combinations of listed above

First of all, LBInteractableMechanism provides a basic framework for actor interactions, this mechanism carries out all data transaction between LBActor, LBPawn and other actor classes. Two first interactions are implemented by LBInventoryPawnMechanism, LBAreaCheckingMechanism and LBLocationTriggerMechanism. Line and ray intersections are implemented by LBTargetingPawnMechanism. Triggered interactions are partially implemented by LBKismetEventActivatorLBGet***SeqLBSetP***Seq.

Let’s test this interaction system on a pre-set character in a test level. The desired result is an ability to put objects in certain places, where their presence causes certain events. In this example only three interaction types are involved: the first, the second and the fifth. The procedure should be like this:

  • The player initiates the drop-down action by the character
  • The carried object is released from the inventory
  • If this object is put in a specified location:
    • The object is forced to move to specific point
    • The special effect is shown

Projected to a Kismet-Mechanism model, this procedure takes the following form.

First, the key is pressed by a player, which tells the LBSetParamIntSeq to set ActivateInteraction parameter of the Pawn_Interactable_Controller to 6. Then the put down sequence is executed by the pawn and it’s mechanisms.

activate_interaction_seq

After the object is on the floor, it interacts with LBLocationTriggerMechanism, which checks its area every n-th second (tick) of game time (yes, it’s quite expensive). If the objects passes center-to-center distance test, a special Kismet event is activated, which is connected to a group of LBSetParamBoolSeq. The first LBSetParamBoolSeq node sets the parameter bEnabled of LBTargetedMovementMechanism in our object to true, so it could move to the center point. The second node sets the parameter bVisible of LBVisibilityModifier in special effect object to true, so we could see the glowing.

event_handle_seq.PNG

That’s it. Now the objects have an ability to several consequences. In our case, the capsule, carried by a character to certain stand, moves to it center and triggers a glow effect.

interaction

Of course, it’s not enough, because there are three more interactions (at least), that need to be implemented. Some of them have their preliminary handlers, and some of them don’t. The further research and development is carried out.

Inventory mechanics

Well, it’s up. Time to test some inventory mechanics. Start with an LBPawn (xc_char), which has been already set up. The character itself doesn’t seem to have any hands, so it uses its mouth to pick up objects. It’s quite a complex task to make a correct body and neck bend animation (it’s still not correct). Well, handling hand animations is even hareder. But in future I’ll think about it. Maybe.

To handle all interactions the pawn interactable controller is used (LBPawnInteractableController), which is a part of mechanism system. All actions are set in the editor by setting names of corresponding animations.

pawn_action_list

All animation names are linked to animtree nodes, and the slider node (blendbyaction) is controlled from the code.

animtree_example

For example, the slider for drop down action is set to child number five on activation of interaction number six (full code).

else if (value == 6)
 {
  //activate interaction: Drop down
  if (curaction != 0)
   return; 
  if (!CheckInteractioConditions(3))
  {
   LogError("proc: ActivateInteraction() return: [CheckInteractioConditions(3)] returned false!"); 
   return; 
  }
  blendbyaction.SetActiveChild(6, 0.5);
  actionseqs[5].SetPosition(0.0, false);
  actionseqs[5].PlayAnim(false, 0.8, 0.0); 
 }

Yes, slider control is hard-coded in the mechanism, it’s a shame, I know. Then, the animation is played. It fires animation notifies, which are set in the begining, the middle, where the action is performed and in the very end. Each one of them calls its own part of code (full code).

else if (notifynode.NodeName == 'Interaction_DropDown')
 {
  if (notifytype == AnimNotifyTypes_ActionStart)
  {
  curaction=6;
  }
  else if (notifytype == AnimNotifyTypes_PerformAction)
  {
   PerformInteraction(3);
  }
  else if (notifytype == AnimNotifyTypes_ActionEnd)
  {
   blendbyaction.SetActiveChild(0, 0.5);
   curaction=0;
  }
 }

The PerformInteraction function performes the real work: sets all properties of invoked objects. In this case it just tells the held object’s mechanism that it’s free to go.

All inventory objects are equipped with LBAttachMechanism.( I don’t use the default attach system, because it’s a total hemorrhoid). And the pawn has its counterpart – the LBInventoryPawnMechanism, which does all the work.

inv_mech.png

It has a modifiable parameter – a socket, where all inventory is attached (in our case – a mouth). When needed, the parameter of this mechanism (InventoryMechanism) is set to certain actor. After several checks it adds this actor to inventory or doesn’t add this actor because it’s impossible. It could be implemented with one interaction from pawn controller mechanism.

SetTargetParam(parent, InventoryMechanism, 'AddObject', otheractor);

The other actor is selected from all actors in specified area in LBAreaCheckingMechanism based on the distance from the center of this area. It’s still not the best solution, because each time it uses an iterator, wich iterates through many objects in the level. I’m not using the default collision-overlapping system, because it’s a total hemorrhoid and moreover it’s a slow solution too.

Well, this was a first step towards a complex interaction system. It’s interesting, because many modern games do have quite a simple interaction systems. Even RPG games are tend to have more and more plain character-static world interaction system, but I think you can prove me wrong. Well, the result is shown below – the character is now able to pick up and put down any objects in the level.