[Feedback wanted] Multi-purpose item struct

[Ardoc]

Hi, I've put together a nested multi-purpose item struct I'd like some CC/feedback on.

I'm trying to cover all bases I could think of when I think what an "item" is in UE4. An item in my eyes is a: weapon, tool, potion, armor, etc.
Trying to cover 2D and 3D as well: a 2D item would have a sprite (I've included possible animation struct too), a 3D item would have a mesh.

I wanted to define all items in a struct (without being inside a blueprint and fiddle about), because that way I have better eye on things.

http://i.imgur.com/NYjY3Tp.png - I've tried color-code so it'll be easier to find where and what goes where.

So when I want to create a new item, I'll just need to add it into the Items struct and change the values I want to use then it's ready to go!

Does this look any good? Would you use or think of using something similar?
Why? Why not?

Feel free to ask questions.

Thanks

[vanlacke]

So I wrote a long post pointing out the things that stuck out, but I think it's best to just summarize it: Way too much. It's good to make a dynamic item, but not UNIVERSAL, if you know what I mean. As a person looking at this, it would take ages and be very complicated to make an item. If you were to do this it'd be best to nest everything correctly, and to avoid an item having variables that it will never use.

[DevilsD]

Inheritance.

Build a base class that contains the essential properties that an Item should have. Using inheritance from this base class you branch down into more specialized versions that only achieve the additional behavior pertinent to that particular subclass of Item. This way you are not wasting properties on Items that would have no need for them at all.

[Ardoc]

So I wrote a long post pointing out the things that stuck out, but I think it's best to just summarize it: Way too much. It's good to make a dynamic item, but not UNIVERSAL, if you know what I mean. As a person looking at this, it would take ages and be very complicated to make an item. If you were to do this it'd be best to nest everything correctly, and to avoid an item having variables that it will never use.

Complicated to make an item? All you have to configure is the items struct (the first struct to the left)?

Inheritance.

Build a base class that contains the essential properties that an Item should have. Using inheritance from this base class you branch down into more specialized versions that only achieve the additional behavior pertinent to that particular subclass of Item. This way you are not wasting properties on Items that would have no need for them at all.

Not a big fan of using a blueprint for holding data, using a struct seems to me the best way to quickly change properties on an item if need be. And it being separated makes it a bit more reusable.

[vanlacke]

Complicated to make an item? All you have to configure is the items struct (the first struct to the left)?



Not a big fan of using a blueprint for holding data, using a struct seems to me the best way to quickly change properties on an item if need be. And it being separated makes it a bit more reusable.

What do you mean? Wouldn't you have to go through every substruct to create the item you want, and along the way leave many empty?

And what DevilsD said is what I meant by not having such a huge amount of useless variables for any specific item

[Ardoc]

What I meant was you create the item in the first struct and setup the values in there. No need to open up the other structs to configure the item.

Useless variables for an item or not, I did create a multi-purpose struct to cover what I'd think an item would have.

[vanlacke]

What I meant was you create the item in the first struct and setup the values in there. No need to open up the other structs to configure the item.

Useless variables for an item or not, I did create a multi-purpose struct to cover what I'd think an item would have.

Yep, of course no need to open up the struct. What I'm saying is having every single variable bound to a single item that like is very messy and confusing (maybe not for you - the creator). Is the goal to have other people use this?

Here's a quick example I made to show what I mean in terms of no useless variables for an item, and much easier & cleaner way of making an item. (one is 2d, one is 3d, and one is a consumable, other is storage)

[Ardoc]

Is the goal to have other people use this?

No.

What do you mean by is consumable and storage? Is it for something like a pickup (consumable) and displaying purposes only (storage)?

Another question:
Take your 2D example. How would you deal with a 2D item that needs to have another variable that's only usable for that item (like another boolean variable) but not the rest of the 2D items.
That boolean variable would be useless for every other items. Would you create another struct just for that item?

[vanlacke]

I thought maybe you were creating something to release since you said this:

Does this look any good? Would you use or think of using something similar?
Why? Why not?

What I showed were simply examples. Yes, 2d weapon with bools "locked" would be totally useless. That's what I've been trying to say about your current system. Unless I'm mistaken, every item created will have lots of unneeded variables.

So what I would do, is simply make a different struct for a 2d weapon with its own specific variables. I would show you however I already deleted everything...

[Hyperloop]

I went down the same path, and while it does work well for me, I did run into some issues because changing structs in the editor can corrupt blueprints and disconnect nodes. These problems are much better in recent engine versions thankfully. I agree with the above poster who said it's maybe not the best idea to rely on storing data in a blueprint. I got around this by making a save game class that I can export and import my data definitions from so that it's easy to back them up and not rely on a blueprint alone to store critical game assets.


In the end, after having done this in my game, I would only do it this way again if I knew I was dealing with many many item types. If I only had a few dozen I would not define them dynamically like this but it has it's advantages when you have hundreds, as I do.

For what you are doing, based on the structure you have there I'd recommend not trying to store everything in one giant struct like that, but rather separating out like things into their own data structures. It's a pain to get and put things into structs that are nested deeply.


Another thing you could consider is that you have access to data tables, so you could develop your item data in excel or similar and import those tables and get the item data based on a key/value

[SaxonRah]

Hi, I've put together a nested multi-purpose item struct I'd like some CC/feedback on.

I'm trying to cover all bases I could think of when I think what an "item" is in UE4. An item in my eyes is a: weapon, tool, potion, armor, etc.
Trying to cover 2D and 3D as well: a 2D item would have a sprite (I've included possible animation struct too), a 3D item would have a mesh.

I wanted to define all items in a struct (without being inside a blueprint and fiddle about), because that way I have better eye on things.

http://i.imgur.com/NYjY3Tp.png - I've tried color-code so it'll be easier to find where and what goes where.

So when I want to create a new item, I'll just need to add it into the Items struct and change the values I want to use then it's ready to go!

Does this look any good? Would you use or think of using something similar?
Why? Why not?

Feel free to ask questions.

Thanks

An item is much more simple than a potion or weapon. The Item is the base underlying thing that represents an item. In your case an item is a struct with many parameters that has struct with many parameters that has a struct with many parameters, all of the structs have states (bools). allot of functionality that is unnecessarily grouped. Don't make an item that has everything, make an item that has the most basic of functionality and then inherit that item to build specialized ones from it.

for example why does items_params have weaponstats, if the item is a potion ? Object orientation is your friend.

[Ardoc]

I thought maybe you were creating something to release since you said this: [...]

I don't think it's anything worthy of releasing (all my UE4 development is available on GitHub anyway), only asking if people would use a item struct like this. I just want to find a good item structure I could use for my future games/prototypes.

What I showed were simply examples. Yes, 2d weapon with bools "locked" would be totally useless. That's what I've been trying to say about your current system. Unless I'm mistaken, every item created will have lots of unneeded variables.

So what I would do, is simply make a different struct for a 2d weapon with its own specific variables. I would show you however I already deleted everything...

No worries, I think I understand, a more specific struct for-that-type-of-item kinda thing.

I went down the same path, and while it does work well for me, I did run into some issues because changing structs in the editor can corrupt blueprints and disconnect nodes. [...]

Yes, I've had the editor crash on me many times. Structs are more stable now than before, still not "great" though (yet).

In the end, after having done this in my game, I would only do it this way again if I knew I was dealing with many many item types. If I only had a few dozen I would not define them dynamically like this but it has it's advantages when you have hundreds, as I do.

For what you are doing, based on the structure you have there I'd recommend not trying to store everything in one giant struct like that, but rather separating out like things into their own data structures. It's a pain to get and put things into structs that are nested deeply.

I am already working on a new item struct, trying to make it more "flat" (less nesting). Got lots of ideas going thanks to vanlacke's examples.

Another thing you could consider is that you have access to data tables, so you could develop your item data in excel or similar and import those tables and get the item data based on a key/value

Ah, didn't know data tables existed!

An item is much more simple than a potion or weapon. The Item is the base underlying thing that represents an item. In your case an item is a struct with many parameters that has struct with many parameters that has a struct with many parameters, all of the structs have states (bools). allot of functionality that is unnecessarily grouped. Don't make an item that has everything, make an item that has the most basic of functionality and then inherit that item to build specialized ones from it.

for example why does items_params have weaponstats, if the item is a potion ? Object orientation is your friend.

Yes, people already mentioned blueprint inheritance, etc. My way of thinking of this item struct is that it's a collection of items that are easy to setup/change.
Example how I could use the item(s):

[Distul]

From my experience it's a lot easier to manage specialized structures instead of a universal one. Universal structs get incredibly confusing as your code becomes deeper. For footprint and organizational standards alone I'd make task specific structs.