Weapons and Data Tables


It's been a while since a blog post on here, and a lot has been done with my project. In this post I'll be going over how weapon implementation works in my project. Covering topics including Data tables, memory management, networking logic and a practical examples of asset creation and implementation - the system in action. 

Overview of the system

A weapons system that allows for players to access 100s of weapons and weapon-specific abilities/actions, with an easy and fast implementation workflow.

Unique challenges and requirements

The system isn't overly complex (forgoing dual-wielding for example), but needs to meet some critical criteria:

  • Use minimal RAM memory
  • Support network replication
  • Have minimal set up/dev time for new items
  • Allow for easy management of 100s of items
  • Items should have rich content (Item icon images, descriptors, granted abilities, animations, meshes and materials)

Approach/Method

Data Tables

Data Tables are a core component to creating and managing items, it has some key benefits:
  • Allows management of all items in one centralised place
  • Can be exported to a CSV file, and can be edited in standard CSV applications (excel etc.)
  • Can be held in memory at all times, reducing load operations during gameplay (better than having each item be a unique object - both on performance, memory, and development)
  • Standardises Item Data Structures
I go over further details of the data table set up and replication in a previous post but, in short, the table structures for items include all base information that takes up small amounts of data, and anything with a large memory footprint uses a Soft Reference. A soft reference is just a pointer to a location on disk, rather than the actual asset. This is why the game can have the full data table loaded, without having the hundreds of meshes and animation referenced inside it loaded. The game will load this heavier data using a separate thread, when needed at runtime, to minimise hitching/dropped frames. 

Inside the item structures there is also variable slot for a separate Data Asset. This Data Asset slot is where extra, bespoke data can be stored/accessed for items requiring more info to standard items, like weapons.

Data Example:


Hard Reference/Variables ---
Item Name (Text)
Item Icon (64x64 Texture)
Item Tag (Gameplay Tag)
Item Description (Text)

Soft Reference/Variables ---
Animation Overlay Asset (AnimLayerInstance)
Weapon Vanity Class (uObject Actor Blueprint)
Granted Abilities Array (uObject GameplayAbility)

Player Equipment Component


The equipment component (responsible for equipping logic and networking) has been covered in previous posts, however, the flow for weapons is now slightly different. Previously, when players equipped a weapon, a BP weapon actor was spawned in the world, and this actor object was responsible for weapon logic (traces, hit detection etc was being calculated inside the weapon object), this meant that core logic for the game was running on the weapon actors and thus these actors had to replicate over the network - introducing unneeded network latency into core weapon functionality. 
   
Now, the weapon actors still spawn and attach the player, but no logic runs on them - they are simply for visuals only (vanity). Weapon trace and hit logic now occurs within the player character which is already replicating by default. This saves some bandwidth as weapons do not need to replicate over networks (only exists on local client machines), centralises networking logic and also removes gameplay dependency on these actors. 

Removing this dependency also negates any any chance of players being unable to perform weapon abilities should the Vanity Object class take too long to load from disk (e.g. client 1 equips sword and attacks, but doesn't need to wait for the object to be spawned on the server, then replicated back to them before doing so, which would create a period of time where they 1) cant see the weapon and 2) hasn't been granted the weapon's abilities) - players can access their abilities instantly after equipping, and the vanity visual class can safely take a few milliseconds to load on all client machines without affecting gameplay.

Forging a blade: Practical example of adding weapons to the game


This is how weapons are added to the game, utilising this Data Table workflow.

Asset Creation


Engine Implementation


Video Demo




Comments

Post a Comment

Popular posts from this blog

LOG #3

Image
  Had a long-form explanation of the game design ideas and my thought process but I’m keen to keep these blogs more concise so just gonna jump into it. Concept Art Took a break from unreal and created some key art. Some kind of tower point of interest in a dense area. Wanted to get some material shaders going in engine to having at least some kind of visual inspiration for designing a few textures was helpful. See a full timelapse video below the image, used blender and krita. Substance Designer Materials Created some materials for ground terrain, and tree bark. Vegetation assets were made using Tree it. Have displayed in varying roughness/wetness. The Mega Uber Super Material Shader An efficient workflow for authoring and managing materials is quite crucial for me as I’m only one person and as the asset count increases, so too does the workload associated with managing and editing my materials. For this reason, and to reduce GPU draw calls, I am using a mega material shader that w...
Read more

#2 - 11/09/2024

Image
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) reliabl...
Read more