Improved interaction mechanics

Earlier I’ve managed to make a fair action system and an inventory-based interaction mechanics, so currently developed interaction is a physical proximity-based interaction, as postulated earlier: a touch or a hit between objects (characters<->objects). So, basically, the player can touch anything in the level, but not everything in the level is able to react — the interaction is only performed in a mutual manner. At least, I’ve made such a conclusion. The concept is the following: there are some interactions, which are performed by the player’s character, the character can perform an interaction on an arbitrary object, influencing its state. The idea is quite simple: an actor makes the other actor’s mechanism to perform handling of a certain event, each event is described and handled in the event handling mechanism. The active counterpart of the interaction couple is LBSimpleInteractionMechanism (LBBasicInteractionMechanism), while the passive counterpart is LBEventHandleMechanism, however I’ve made some loopholes for the interaction mechanism to be able to handle events by the React() function. The following four procedures do form the interaction mechanism’s core, so when an additional functionality is needed, they are modified or overridden.

function Interact()
{ }
function React()
{ }
function bool CanInteract()
{ }
function bool CanReact()
{ }

But typically there’s no need to modify any code at all, so all needed data is set in the editor. To describe a new interaction, the designer should set its name and some values, which are used by this interaction.

char_interact_params_3

Thus, the passive counterpart-actor’s mechanism, the LBEventHandleMechanism, performs the real event handling (what a surprise!). It is interacted by sending this mechanism SetParamInt() with param name ‘RaiseEvent‘ and a param value, containing this event’s id. After activation of a certain event, its params are set. For example, we can enable or disable movement, set movement speed of the current actor or do many other interesting things by this params.

object_interact_params_1

For more convenience, interaction mechanism in a player’s character is wrapped in a character controller mechanism, which also wraps the inventory mechanism and many others. So, the player first activates a certain action, for example, a touch action of the player’s character. Also it’s quite a convenient way to perform some checks, but in the code, of course.

char_interact_params_1

Now, all together. I’ve made a draft touch animation and a corresponding touch action, which is performed by our character. Well, the character doesn’t seem to have any hands, so it has to touch everything with its face, lol, so the current animation looks quite strange. Finally, we’re able to perform the touch action by pressing a key on a keyboard, as described earlier, so the pipeline can proceed. Next, this action plays a touch animation, which triggers the anim notify, which send the interaction mechanism a message via Interact(), and then, the interaction mechanism perform a coresponding interaction. It should be noted, that the action cannot be pefrormed (the animation won’t play), if we receive a negative answer from an interaction mechanism via CanInteract(). This is the fair way, I suppose, when you don’t touch things, that are not ment to be touched.

So, in this example, when animation time reaches a certain position in the touch animation, the animation notify is sent to the character’s interaction mechanism, which handles all the stuff by the HandleAnimNotify(). In this example, the actioncode is set to 401 and notifytype is set to ActionNotifyTypes_ActionPerform. Next, the check is performed, and, if this check is passed, the interaction is performed — the PerformInteraction() is called, which also says the interaction mechanism to perform a certain interaction immediately.

function HandleAnimNotify(int actioncode, int actiondata, 
ActionNotifyTypes notifytype)
{
 ...
 if (actioncode == 401)
 {
  if (CheckInteract(TouchInteractionID))
  {
   PerformInteraction(TouchInteractionID); 
  } 
 }
 ...
}

When the cube (okay, the golem) is touched and all above stuff is performed, the event handling mechanism sets several values, which turn on movement, rotation and other logics. Also, I’ve made a camera effect, so when the golem is touched, the view toggles to a cinematic camera via the following kismet sequence.

Kismet_nodes_3

Well, that’s the core of the interaction system, the concept looks quite acceptable, however it may contain some hidden problems, like simultaneous interaction with multiple objects. But for now, that’s how the interaction system is organized. Now we can see the in-game interaction example, where the object is being activated by character’s touch.

It seems to be one of the most complex parts of the game logic, but very perspective at the same time. Also I’m looking forward to making use of it in some even more complex cases. But for now, just a simple case: the player’s character activates some cubes. The video below shows, how it looks all together.

 

Improved interaction mechanics

Improved action mechanics

So, I’ve made some improvements in the action-interaction system. It has been a long-needed update. In different games player is able to perform different actions, not only just run, jump and shoot. Well, honestly, a major part the gameplay nowadays is built around actions and interactions, so inadequate and ineffective solutions are unacceptable. This leads us to a completely new domain of problems: we need a separate mechanism for performing character’s actions. The concept is simple: there are some actions, each can be performed by the character. An action has certain properties, like it’s relationship with animation — an action may or may not have an animation, and it’s relationship with character state and other actions — an action may or may not have effects on the game pawn (except the animations effect). Thus, we come to a fairly easy solution — the LBBasicCharacaterController, which is capable of performing actions, which means the ability to play animations and change pawn’s states (virtually, of course). Basically, we’ll be working only with current character’s logic, leaving all underlying activity to the basic character controller. So, we’re interested in only in these methods:

function HandleActionStart(int startedaction)
{ }
function HandleActionStop(int stoppedaction)
{ }
function HandleAnimNotify(int actioncode, int actiondata, 
ActionNotifyTypes notifytype)
{ }

Which do handle action start, action end and animation notifies, which may or may not trigger during the action animation. If we don’t need any character-specific logic or we just want a Garry’s Mod-styled animation player, we can just use the editor. For the designer it’s really simple — all what’s required is to fill out the Character Action List in the editor, which contains all the necessary data.

char_interact_params_1_1.PNG

For example, here I’ve made four basic actions: touch, pick up, put down, carry, three last interactions I’ve been describing earlier, the touch action and the appropriate interaction I’ll describe later. Also I’ve made some auxiliary actions, which really don’t have any effect in the game, except they do play animation. All options of this actions are shown below, for example, them options of the touch action mean that this action is controlled by the certain animation: the action starts with the animation and ends with this animation, also it may have activation restrictions and switch links. What is activation restriction? It’s simple — the action cannot be performed from any actions (state-actions), except these. And the switch link is a type of  a bridge between the actions — upon its finish, the action can be automatically switched to another one. Well, I’ve made some comments (been trying my best) in sources on GitHub.

char_interact_params_1_2

Next thing, what is required — the proper animation, set up and linked to the LBBlendByAction animnode, which blends all animations. There’s also a default node, which is used to blend out, when the default action is active.

animtree_nodes_1_1.PNG

Thus, all, what’s required now is to call a needed action by the SetParamInt() function with param name ‘BeginAction‘ and param value containing the action code. Also, this can be performed from any sub-system, but I’ve chosen Kismet and its keyboard events.

kismet_nodes_4

Well, let’s test this functionality. I’ve made some random (though interdependent) animation sequences (though craggy) for the character, then plugged them into the new action system. There’s a state-action, which defines character’s state — the ‘Sit_Tie_Idle‘ action. There are also two gateway-actions — the ‘Sit_Tie_In‘ as an entrance into this state and the ‘Sit_Tie_Out‘ as an exit. And there are two actions, performed exclusively from the ‘Sit_Tie_Idle‘ state — the ‘Sit_Tie_Gym_1‘ and the ‘Sit_Tie_Gym_2‘.

Now we can make our character do different things. For example, we can watch our strange character doing its strange exercises (some kind of gym, maybe?). However, everything happens in the right order, for example, it can’t just start walking or jumping from a stretched pose, it has to stand up first.

Improved action mechanics

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:

xenowalker_walk_gifxenowalker_walk_gif_side

Simple run animation:

xenowalker_run_gifxenowalker_run_gif_side

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.

Movement mechanics

«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 three

«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 two

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.

Interaction mechanics