#2 - 11/09/2024
Had a week break whilst on holiday but had some time here and there for some equipping development. happy to say the chunkiest majority of the system is now working and stable, with replication! Animation has also received some attention with a Layered system in-place using decoupled animgraph layers to integrate with the item equipping and actions logic. Armour/Wearables equipping has complete functions, with head, body, feet, and hands mesh swapping.
Goals of the update
I’m inspired by Bethesda's Creation Kit’s designer-friendly framework to create a similar framework for my game. I admit it pains me a bit to see the impressive RPG framework get bashed so often - it's a great framework with a level of interactivity and persistence I don't find too often in other games still today. Skyrim/Fallout has reliable, predictably consistent methods of agency across all areas of the game, items have physical weight, all npc can be damaged/interacted with, a big (somewhat) reliable sandbox/simulation design can allow emergent narratives to occur in engaging, surprising and immersive ways. I want my game to follow a similar approach, where a solid core framework is in place that allows for some basic simulation, and streamlined methods of creating characters, items, and gameplay. Once this is inplace, I can take a design-lead stance to development for rapid expansion and easy re-skinning in cases of future projects. In this update I implement some core logic for equipping items and wearables, and animation logic - with the resultant systems being ready to accomodate an easily expandable lists of items.
Items are very important in my game as they are the way through which most if not all abilities and gameplay are made available to the player, and are a core loop component for gameplay. I want to make a system that is simple to use, intuitive, trying to land somewhere between the minimalist systems of minecraft, with some extra rpg flavour from the likes of skyrim or the witcher. The aim here is to have 100s of items that are easy to manage, edit and add to.
Weapon equipping/sheathing
Items of certain types can be equipped in the game. To do this players can ‘click’ items inside their inventory, and the corresponding item gets ‘equipped’ to a slot set by that item’s specific descriptors. When equipping an item, a sub-class of ItemBP (ItemBP_weapon) can be read from the equipped item’s descriptors as a soft reference. Once the item is ‘equipped’ from the players inventory, the BP class is asynchronously loaded along with it’s data and then spawned in the game world. Note that the term ‘weapon’ here can denote any ‘holdable’ item including tools and other special items. The item class, it’s abilities and dependencies is loaded now rather than when the weapon is actually unsheathed and in-use. This means that all of the data needed for gameplay associated with all current equipped items is ready to go, so that panicked (or strategic) rapid inputs to switch weapons during combat does not trigger any loading of new data and is as smooth as possible. If a player attempts spamming their inventory and equips and unequips many weapons at once, this will not overload or get lost across the network - because ‘equipping’ occurs on the server and updates a repnotify (a 0.15 second delay gets reset if another update is requested) ‘equipment data list’ variable that is then sent back to the clients UI, it is not possible for clients to get ‘ahead’ of the server, their UI is always true to the server; stability at the cost of some minor UI latency. This is a system I want to optimise and improve, but it works well now and that’s enough.
The ‘ItemBP_weapon’ Class contains asset variables including Abilities to grant to the player (their logic, montages, input binding etc.), Animation Data and so on. By having these assets defined within the weapon class ( + using soft reference pointers until actual point of spawning the weapon) data for these specific weapons can be loaded and unloaded in a somewhat efficient and controlled way.
 |
| BP_Item_weapon Variables |
When weapons are unsheathed, gameplay abilities are granted to the player, along with any input bindings, and thus removed when the item is no longer in the players hands. Gameplay abilities are a core component of the gameplay ability system. Granting these abilities allows the player to perform specific in-game actions such as a sword attack, or a ranged aim and shoot.
Setting up the item equipping framework in this way makes in very easy to add in new items and their respective new abilities incredibly quickly, without introducing large data dependencies within the Item DataTable that gets accessed during runtime.
Item Armour Equipping
Armour, or Wearables, have some very basic functions that I will go over.
To start I had to decide on a method for my Armor system, there’s a lot of ways to go about it. On previous builds of this game framework, I had armor being spawned as a BP actor and then attaching that actor to the player and matching animations, similar to the way weapons are handled. I went with this decision previously because I wanted players to be able to see their original characters skin underneath ( a character base mesh that I intend to be somewhat customisable, hence a separation of the clothes from the base mesh seemed the obvious path). This was okay, but lead to some large issues that would only get worse as time went on. Firstly, creation of armour pieces for this method was tricky, not only did the armour/clothes pieces need to be outside the skin surface, but rigging proved to be slow. Making a simple set of pants would take 30 mins to model and texture, but then hours of tweaking weights to remove all cases of clipping during gameplay animations. Secondly, the base player mesh was always present. Not only is it providing an obvious render cost for the hidden skin faces, but also removes any possibility of having any armour or wearable item that ‘replaces’ a body mesh piece (e.g. robotic legs or skin-tight items).
My new approach is to have 4 (or more to come) skeletal meshes within the player character, along with default mesh variables. all skeletal meshes follow the leader mesh (the head in this case) and are assigned a tag that defines the slot associated with that mesh (e.g. itemslot.head). When a wearable item within the inventory is equipped (checking if the pawn character has any SKM component with the matching slot tag), the player character contains some basic functions that 1) async load the desired SKM asset from the items descriptors and 2) apply the SKM to the correct component with the correct tag. Armors and wearables also can apply abilities, effects and other modifiers much like weapons. Simple as that. The base mesh skin is included with these pieces, so that any edits can be made to it for optimisation or design purposes,. To enable the customisation in-game of this base mesh and retain any custom parameters I will be using a separate material for it, along with some post-process bone modifiers within my animation graphs to adjust height, weight, skin colour etc. all negating the need to create multiple armours for different body types.
 |
| Skeletal Mesh Setup |
 |
| example of item struct variables, showing slot tag configuration (equipslot.weapon1) |
Animation Updates
Not so much of an update but more of a start. Animation in games is something I appreciate, a lot. One of my first ever ‘completed’ unreal demos was started with a keen interest in procedural animation logic and how to get a lot of results from a minimum of source animation assets. For my animation system on this project, I wanted to achieve something that felt controllable, have some fluidity and weight to it and was relatively lightweight performance wise and made efficient use of a small set of animation data.
A brief overview of the animation graph's current capabilities:
- 360 degree strafing
- Toggle-able Forward-facing/Strafing Movement Support
- Foot and Hips IK
- Procedural Landing and Aiming processes
- Walking, Crouching and Jumping/InAir
- Weapon overlays with per-weapon linked animation logic
- Montage Support
- Lightweight + Uses Thread-safe variable logic
The animation graph for players is structured into stages of linked animation graphs. For example the player anim graph consists of some minimalistic state machine stages, with heavy emphasis on procedural effects over complex states with many animation clips.
 |
| Overview of full Animgraph and Base Locmotion's thread-safe functions |
Base Locomotion
This linked graph is responsible for full body locomotion, with walking, crouching and jumping states. Walking and crouching locomotion uses blends of 4 cardinal directions, combined with orientation warping, giving a full 360 degrees of hip rotation.
 | ||
Base Locomotion Graph
|
This layer can be linked to an anim graph that handles logic for item-specific overlays such as holding a sword, aiming a gun. Any graph can be linked here at runtime, meaning each item can have it’s own bespoke blending and gameplay-reactive logic. E.g.Pistol idle only applies to right arm, whilst a rifle may apply to both.
Montage Slots
A series of montage slots allows injection of animations from player-activated abilities, reloading, attacking, hit reactions etc.
Control Rigs and Warping
These are great, much of the fluidity of the animation graph comes from this stage. These stages apply procedural effects to bones in very simple ways that add a huge amount to the end result. Firstly, acceleration warping takes our players speed delta (acceleration) and direction (float rotation) and applies a small amount bending to the spine chain. This simulates characters leaning into their accelerations, and decelerations. Second is landing; a float variable ‘time since landed’ drives simple logic with curves to pull the pelvis down, bend the spine and slightly pull out the arms. I really love this effect, it’s so simple yet the results are great. No landing animation is needed, and better if we don't use one! - the character’s base locomotion with the procedural overlays provides a huge range variation to our landings and easily adds more believable weight to our characters. Lastly, a simple foot IK ends the graph (disabled whilst character has State.inAir tag).
 |
| Control Rig Landing, driven by curves |
Comments
Post a Comment