Building an inventory system using data tables, and objects…
First up should i actually load the data from the data table into the object or just store the table row information on the object?, I know both work its just which is better programming.
Next, When creating an object its asks for an outer (like a parent / owner), after the objects creation this cant be changed so should I set this to the class which will be holding a ref to the object or somthing more persistant like a gamemode.
The jist of what im asking for is how should i handle trasfering ‘items’ between actors, should i make a new object on the destination actor and copy the data and set the outer to be this actor, or Set the outer to be somthing else (like gamemode) and then just handle transfering the refs.
You’d store most information in the data table, then in the item actor tell it how to interpret the data (i.e what to do with the icon, name, stats ect)
Then if you want new items all you have to do is add another data table row and set up the item stats.
Then when ever you initialize the actor you give it a data table row (i.e steel sword) and it just runs with it.
For the actor class you want your parent class to be all the fundamentals of every item in game, for example whats one universal thing about each of your items; You can pick them up, they have a name, an icon ect. So you do all the logic in that, and then create children to do specific things, in this case a weapon class, with item class parent, so it inherets all the things a normal item can do (be picked up ect) but hold additional logic that a normal item can’t do (attack)
You can change a blueprints parent class after you’ve made it, but you rarely have to, maybe in the case of moving the parent BP to c++ from blueprint. But if all set up correctly its pretty future proof.
It really depends on what type of game you’re creating. For something like a survival/battleroyale game where there are thousands of world objects (lootable) you wouldn’t want to use data tables for obj/item info.
More info on the type of game and item interactions would help.
@Rev0verDrive
A survival game with thousands of world objects as you predicted. If not DataTables what would you suggest? I was looking into databases like SQlite ect. But i’d really need to do some studying to figure out A) what the hell they are and B) if its applicable to this scenario.
But also i’m just purely after Data from a design perspective with the Data Tables, i wouldn’t be using them to query spawned actors or anything, just so i can create actors dynamically from a DT without needing to spawn them first.
Alternatively i think i have a solution; Data Assets.
Not as pretty as a DataTable, but with Editor Blueprints and Widgets i’m sure i could make something that resembles the Data Table editor.
For example;
Create a new actor from the class Primary Data Asset, and store all the generic variables in there like name, description ect.
Then create a child of that Actor for specific item types, in this case a weapon, and add any relevant variables for a weapon (DPS, RPM ect)
Now you can create data assets based on what item you need, a generic, or weapon.
You can basically always cast to the parent BP to get all the generic data when needed or cast to the specific DA if you need more specifics
Still on the fence about it though, because A lot of individual separate assets. One pro DA have over DT is you can add categories and sub categories instead of being blasted by a wall of variables.
Think about game loading, run time spawning on the server, then replicating to all clients. Spawning items needs to be fast. They need to be replicated to clients quickly. Server resources are crucial, especially early game.
Configuring data needs to be done prior to map load. You don’t want to be doing data set lookups, setting vars and spawning on a mass scale. That’ll crush the servers tick. You need to be able to spawn a thousand items or more in 1 second. I personally prefer to do collision based spawning.
@Rev0verDrive Thanks for the reply, Just so i’m understanding you correctly you’re recommending moving away from Data Tables and Data Assets and just setting up the child item actors defaults on an item actor per item? So when they’re spawned or initialized they don’t have to read-write variables at runtime?
If so what kind of trade offs for actor centric data, reading is fine. But say it’s in my inventory and not in the world anymore, modifying variables become a bit troublesome doesn’t it?
I’m going to definitely look into this approach tho.
@geohan Sorry! I totally hijacked your thread. I thought this was one of my threads i had some similar questions. Running into issues with Data Tables, but Rev0verDrives replies work well for my issues as well.
Data Assets are fine, yet remember they are read only. Data tables are too slow for what you want to do. Same definitely applies to sql, more so actually.
Complex items such as weapons (guns) have two variants. Weapon_sm and Weapon_sk. The SM (static mesh) variant is a low poly sm, with low data. No need for recoil, camera, firing logic etc. Simply a world actor to interact with. On interaction (pickup), the server destroys the sm variant and spawns the sk (skeletal mesh) variant, attaches to pawn etc. This variant has all the data, specs … recoil, sway, deviation, projectile class, velocity, ik offsets, ammo, attachments etc.
Each item spawned in the world eats memory on the server. The sm_variants are used to reduce this overhead. Another plus is the meshes are low poly, so a render performance gain.
I’m using structs for configs instead of data assets. Modifying variables is pretty straight forward and there shouldn’t be too many that need to be. How you setup your inventory is key. Mine is a struct (see previous linked post). Most of my primary gear/items have an object reference for storage. When the SK variant is spawned I set its obj reference to a slot (struct element).
Actors + Structs is the expensive way to do it.
I would create an UObject class in c++ marked with EditInlineNew class specifier and use it as item type.
Eventually that’s the direction I’ll be taking. Prototyping, testing, making sure I have all the needed vars for what I want to do. production build will be majority cpp.
My main concern at the moment with UObjects is networking/replication.
