Best practices with Data tables?

So I have been playing around with data tables a bit more and I have to say they are quite awesome. On my current project, that is not currently using data tables, what I do is define an actor class and add a struct to it. I would then be able to make children of that actor and define the variables that make each child different from the base class.

However, it seems that with data tables I am dealing with a much different beast somewhat invalidating the above work flow.

So lets say I have a project with 30 different weapons and 30 different armor types. With the old method I would just make one kind of item as my base class then make children for weapons armor ect. I could then define what weapons are shotguns or sniper rifles by defining those child classes in that way. Same with armor, I can make helmets, boots, legs, body gloves ect.

But with data tables it almost seems like I don’t actually need to do things in this way. With data tables it almost feels like all I need is one object and I can then just specify the name of the data table row and be done with it.

Here is the thing though, While data tables are really great, I am not sure if they will be super great when working with hundreds of objects. For example if I lump all armor types into the table Then I end up with a giant list and it will end up being a pain to organize it at all. If helmets are at the top of the list then every time I add a new helmet I end up leaving it at the bottem of the list or being forced to slowly move it up to the top of the list potentially causing other problems.

So what is the best way to do this?

Always depends on what you need or want.

You could for example just start every Row of Amor data with “Armor” and search for it, so you only see Armor data.
Or maybe i dont understand/see your problem :confused:

Look into scene components or blueprint components.
Make interface in weapon that is for eg. “set stats”
make component that from its parent expects actor with interface “set stats”.

Now create parent component that just knows how to call interface and pass over those stats.
Then create inherited components with different stats.
Expose all stats as editable variables, so you can see them from weapon blueprint.
Or totally opposite, lock them tightly inside those component blueprints so you are sure they are changed only from within component blueprint.
Or make those components read some data tables.
That is beauty of components, they are like inherited variants of blueprints but without all those “cant do because inherited” stuff. You can drop same component on different parent classes, all you need to do is implement one interface function in parent.

When you have all that ready make your weapons as you wish, then drop components with stats on them

For eg i did all that component stuff for fire and autofire mechanics for all my weapons.
All firing logic is inside one component, it has fire_enum type and autofire delay.
Then it tells parent weapon when to fire.
It also can handle disconnects and lagg in multiplayer.
Same component for machine gun sniper, flamethrower rocket launcher etc.

When working with the spreadsheet every new line is placed at the very bottom of the list. You cant inset rows as far as I know. But imagine a giant list of armor types all mixed together.

really unorganized.

It depends on you.

You could make multiple tables OR organize them with their names / data, at the top is a filter system that helps you a lot.

Edit: Ok i see what you mean, you could use “make Literal Name” but thats not great aswell… I dont think that there is a way to make it easier. Multiple Tables might be the best option.

Nesting other data tables within a data table is possible but, is that really a best practice is the question?

Dont think so.
What do you need? How do you plan to use them?

If you want to avoid the problem of having too much options to select, its better to create multiple tables (as long as you know where the data is that you need) because you make it manually anyway and its easier.
If you want your game to detect what row/data you need, it is better to use one table.

Edit: Or you use a name variable as input, using multiple tables does not feel like the “right” solution.

What I need is to create an inventory system that is both organized while also encompasses a wide verity of different types of items.

I also want to have a character framework that allows me to create a lot of enemies and player types in an organized way.

Data tables can help you to create Items, so that they have the same data every time.
Inventory system itself is just an array of your DataStruct, i dont see how data tables help you here.

Edit: But im not that much into data tables yet.

An inventory system is a lot more than just an array. You need functions to recognize what the items are and make them act accordingly. You need functions for them to be moved around and stored in other arrays. You need ways to interact with the items as well.

So with all of those things in mind, I seek the most optimal way to work with data tables to create the most elegant work flow possible. A system that can allow me to easily work with thousands of unique objects with as little headach as possible while having them all work within the framework of an inventory system.

I have an inventory system right now that works but it is based on parent child relations and heavy use of structs. From what I am experiencing this system works great on paper but the engine itself has a lot of problems with it.

Do you know of any boiled down working examples of this I can take a look at? Its definitely interesting but kind of hard to visualize.

I talk about a possible workflow with data tables that will probably encourage me to start the entire project over from scratch. Though, before I do that I would like to see if others can agree that this method will work without too much issue.

Is this a good way to use data tables for this kind of project or is there a better way to do it?

This is something I would like more direction on, personally. I’ve done programming for a while, but I’m new at unreal and a little uncertain how to proceed. I would like to avoid going TOO far down a rabbit hole and finding out the way I’ve done it is bad. And as far as I can tell, refactoring in Blueprints is pretty painful.

I started out defining my item type data in a datatable. Sword type has these stats. Pickaxe has these stats. etc etc. When I create item X, I look up its class info, and starting stats from the datatable. Spawn actor from the class defined in the datatable.

Then, I was looking at Ark’s dev kit, and I noticed the creatures, items etc…all had a CRAPLOAD of variables, structs, etc defined in each actor. Not in datatables.

That got me to thinking…what is the benefit of putting something in a datatable, in this situation?
What is that giving me over just defining a base class for my actors with all of the variables there, and just adjusting them as needed on child blueprint? If I create an instance of it, it will automatically use the values I assign.

So in that case, I don’t think datatables give me any value at all. Also, I find datatables a bit clunky to deal with, especially when modifying them. They seem to have ripple effects in your other blueprints, and can break things. I find modifying the variables defined in the actor blueprints MUCH better. If there was a Create Component From Class blueprint that worked like Actors, I’d be very happy.

Here’s where datatables are of value for me, I think.

  1. If it’s information I don’t want or need to store in actors. Maybe quest information, that sort of thing.
  2. Maybe it’s actor extra information I don’t want sitting on each actor, that is shared among actors of the same type. Again extra actor data that is “bulky”
  3. Maybe other resources need to access that data. But in that case, I can just use the Get Class Defaults blueprint node, which can access the values.

This is mostly about storing actor specific data, do I put it in the blueprint, or the table. I’m leaning towards the blueprint/actor, but I’d love to hear from more experienced people!

Game designers and writers usually work on MS Office and they aren’t necessarily programmers.
Datatable (csv) is a way for them to directly input systems that are data-driven and test their ideas.

It’s not designed to replace a database or UProperties.