Preparation Work
This article is only applicable to users who have purchased multiple products from me, such as GCS, GMS, or GIS.
Due to the complexity of the combat system itself, which involves more game mechanics, the recommended process is to integrate GIS or GMS into GCS.
Prerequisite Knowledge
Before integration, you should at least understand the basic usage of each system, as well as the BC_DemoCombatEntity implementation.
Background
First, GCS, GMS, and GIS all belong to GGF (General Game Framework Plugin, my All-In-One solution, but it has not been released yet).
I hope my products can maintain independence and modularity among each other. Therefore, GCS, GMS, and GIS all have their corresponding supporting projects, which are subsets separated from my current All-In-One.
For more information, please see here.
Merge Projects
You can manually merge the latest supporting projects of the corresponding versions of each plugin, or migrate the project content to your own project at the same time.
Note
The supporting projects are all split from my own projects, so you can freely merge them back together by copying and pasting. The supporting projects will share some content, so you can directly overwrite duplicate files during the merging process.
At the same time, be aware that the contents of DefaultGame.ini and DefaultEngine.ini in the supporting projects (if they exist) should also be merged.
Required Plugins for Installation
All supporting projects share General Game System(GGS), the plugins do not need to be merged, you just need to install the corresponding version of the plugin from Fab.
Integrating GMS into GCS
The Demo part of the supporting project in GCS contains a simple movement system that demonstrates how to introduce a movement system into GCS, and includes:
- BC_Demo_MovementManager : Located at /GenericDemo/GCS/Blueprints/MovementManager, it is a simple movement management component.
- Several Animation Blueprints : Located under /GenericDemo/GCS/Animations/, these are several lightweight animation blueprints, which can be considered an extremely simplified version of GMS.
You can replace it with other implementations, such as using ALS/GASP or my GMS to replace the movement system in GCS.
This section will explain how to integrate GMS into GCS.
Complete the basic setup of the movement system
Replace the movement system
Before integrating GMS into GCS, you should at least be familiar with and understand the usage of GMS itself. You can refer to the movement system's configuration, and complete the basic component setup of the movement system in GCS.
Key points are as follows:
- Replace BC_Demo_MovementManager in the GCS character with the GMS movement system component, which provides an API/event similar to BC_Demo_MovementManager.
- Replace the animation blueprint of the SkeletalMesh component in the GCS character from ABP_CombatCharacter to the ABPT_GMS_Main provided by GMS.
- Refer to the usage of ABP_Mannequin_Ext in GMS, and in the Beginplay of the GCS character, link it to the main animation instance of the SkeletalMesh component. ABP_Mannequin_Ext is the animation layer that sets up the character's Montage layout, providing the same functionality as ABP_CombatCharacter_Ext provided by the GCS Demo.
For Step 3:
Loading Blueprint
Initializing BlueprintUE renderer...
Replace Movement API
In the combat entity interface of GCS, there are several movement-related APIs that are compatible with GMS APIs, so you can inherit from BC_GCS_CombatEntity or modify BC_GCS_DemoCombatEntity, and replace the API calls as instructed.
Example code in DemoCombatEntity.
SetMovementSet/SetMovementState/SetRotationMode implemented by GMS.
GetRotationMode/GetMovementState/GetMovementSet implemented by GMS.
Integration of Weapons and Movement Definitions
In GCS_Demo, DemoWeapon is configured with different animation layers through WeaponAnimLayerSelections and calls RefreshWeaponAnimLayer and UnlinkWeaponAnimLayer to implement state changes for the character, switching different animation layers (different animation poses) based on the current weapon.
If using GMS, you no longer need to manually call the refresh of the animation layers on the weapon, but instead, add movement definition variables in your weapon class, and when the weapon is activated/deactivated, change the current movement definitions for the GMS movement system component.
When the movement API is called, the GMS movement system component will automatically refresh the corresponding control/animation layer logic.
Depending on your game design, you may need more complex logic to determine what kind of movement definitions to set for each weapon when activated (for example, using different movement definitions based on the character's gender).
Summary
Ideally, when you switch weapons in GCS, the movement definitions on the GMS component will switch. When you call movement-related APIs through the CombatEntityInterface, the specific movement control/animation replacement will be executed through the GMS component.
Integrating GIS into GCS
The supporting project in GCS includes a simple weapon management component that demonstrates how to introduce an equipment management system into GCS.
You can use other inventory/equipment systems to replace the weapon management functionality in GCS.
This section will explain how to use GIS to manage weapons in GCS.
TODO...