🚀 Spring Sale is live! 🚀 Don't miss your chance to get all my products at 30% OFF!  

Get it!

Interaction Sysytem

Overview of the Generic Interaction System(WIP)

With GGS's Generic Interaction System, you can have a player interaction system based on SmartObjects and GameplayAbilities today, without waiting for official production. (It's not released yet, but it's coming soon.)

通用交互系统.001

Features:

  1. Built on SmartObjects and GameplayAbilities, providing enough flexibility to handle interactions ranging from simple to complex.
  2. Based on SmartObjects, allowing for multiple interaction object selections and multiple interaction entrances for a single object.
  3. Utilizing GameplayAbilities, it modularizes player interactions, encapsulating single-type interaction logic in the form of Abilities, supporting network synchronization and client prediction.
  4. Simple and easy to use: one component, one ability. You only need to configure the SmartObject definitions and focus on developing the interaction logic (Ability) itself.

Use Cases:

It can do many interesting things; here are just a few examples:

  1. A bench with two interaction points where two players can sit simultaneously. If it's full, other players cannot interact.
  2. A horse with four interaction points: players can mount from the sides and rear, and feed it from the front.
  3. A siege engine from a game like "Mount & Blade" with four interaction points. If three AIs occupy one point and a player occupies another, the siege engine will advance.
  4. An enemy on the verge of death kneeling on the ground, at which point options for rescue, execution, and persuasion become available.
  5. Of course, it can also just be a momentary interaction like "pick up" an item.

Motivation for Development / Why Use My Interaction System

Interaction systems are a fundamental feature used in every game project. While they may seem simple to talk about, implementing them effectively is quite challenging. You might find yourself writing interaction code throughout the entire game development lifecycle.

The forms of interaction initiated by players with other objects in the game world are generally similar: as long as there are interactive objects nearby, some available interaction options will pop up on the UI, and players can start interacting by pressing a key.

However, the information about the object being interacted with is often not known in advance.

The way interaction systems are implemented can vary drastically depending on the developer's experience, and each approach has its flaws.

Journey of Development:

Initially, I used a basic approach:

If the player is interacting with a pickup, follow the pickup process; if interacting with a door, follow the door interaction logic; if interacting with a chair/stairs, follow the corresponding interaction process.

Result: The player's interaction code became highly coupled, requiring the initiating object (the player) to know and handle too much information, making the code difficult to maintain.

After some time learning, I adopted a more intermediate approach:

I decoupled the interaction logic using interfaces, delegating part of the interaction logic to the object being interacted with, while the player only initiates the interaction. For example, when a player interacts with a door, the door coordinates and handles the interaction with the player.

Result: Many interaction codes were shifted from the initiator to the object being interacted with, making the code somewhat easier to maintain. However, when it comes to multiplayer games or when an object has multiple interaction forms, everything becomes more complex. How do you ensure that an interactive object can only be used by one player at a time? How do you implement coordinated interactions among multiple objects?

When UE5 Released SmartObject:

SmartObject is an excellent design that allows all interaction behaviors to be defined entirely by the interactive object itself. The Pawn in the game only needs to find an interactive SmartObject and initiate different interaction behaviors based on various interaction entrances (Slots), while the internal logic of the interaction is determined by the object being interacted with. It supports multiple interaction entrances; for example, a chair can be sat on, broken, or searched. It allows multiple pawns to interact with it simultaneously, such as two pawns using a long bench. It supports a reservation system to know which interactions are occupied and which can be used.

SmartObject seems to be a game-changer for creating game interactions. The official team has also developed the GameplayInteraction and GameplayBehavior plugins based on it, allowing users to create complex in-game interactions flexibly.

However, the existing examples of SmartObject usage focus primarily on AI/NPC interactions, with very few tutorials or cases related to player interactions, and they do not support network synchronization. Additionally, in the Lyra "Beginner" project, there is a semi-finished player interaction system based on GameplayAbilities. I have studied it in-depth, and while it handles network interaction prediction well in multiplayer games, it does not utilize SmartObject and lacks support for multiple interaction entrances.

Conclusion:

Therefore, I believe that by combining SmartObject and GameplayAbilities, a powerful and sufficiently generic interaction system can be developed. This is my motivation for developing the Generic Interaction System.

Interaction System Components

TODO...