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

Some test run on a new level

Just made a test run on a level I’ve made recently. Playing with ground-walking bipedal character (xw_char), which is capable of walk, run and jump. Also, there’s a good, smooth camera plugged in, which can be attached to almost everything.

Yes, now we’re able to jump. I’ve decided to make ground characters able to jump. Why not, it’s qute fair in comparison with other characters, which can fly or event teleport (but can’t walk, lol). However jump system needs some fix.

There’s also another interactive actor – the way-pointer (mg_char). Most of the time the player just follows this actor. When the player is too far away it stops moving, and when the player is close – it speeds up (such a hackneyed idea).

Well, let’s look, how it all works all together. However, it turned out to be quite hard to use keyboard instead ot the joystick (okay, gamepad).

Some test run on a new level

The Lost Head gameplay test

A gameplay test of a game prototype. The player takes control over the lost head, which is detached from the escaping body. The player should be able to solve some problems to bring things back to their places.

The level contains: player-controlled character (The Head) and the non-player-controlled character (The Body), pre-set cameras, location triggers and linked scripted events.

The Lost Head gameplay test