An example: I make a USTRUCT called ‘Item’ in C++, because BP struts don’t support inheritance, and I make a child called ‘Weapon’. Is it impossible to have a Weapon in an array of Items? For BP or C++ usage?
I’ve been told this is the case, and I should just use UOBJECTS. But you can’t use UOBJECTS with data tables, no? So what other options do I have?
Is this really how you’re supposed to do it in UE4? Isn’t that… a really bad pattern to use? Instead of dealing with one hierarchy of objects I’m now forced with two. Instead of using one array, and using simple sorting patterns to display them according to type, I’m now forced to manage a bunch of arrays. I can’t understand how your system would be close to manageable when you have 100+ items to deal with and 10+ arrays.
In any other environment you would simply use an array of struct pointers, have the variables that wouldn’t be changed read-only, and store them in one array. That way you’re dealing with one one hierarchy, one array, a few data tables, and one actor that would represent the item in-game. And if your item would have ‘special’ qualities in-game, you could just derive from your item actor and treat them accordingly.
I thank you for your reply since it had a lot of information, but I think I’ll look for a workaround on this problem. Between your pattern, the one where one struct is used to hold every item type in your game (shown here), and the infamous “one blueprint for each item” (shown here), I feel like not giving us access to struct pointers just creates a bunch of workaround patterns that would be impossible to maintain over a large project’s lifetime. Workarounds that would be unheard of in other development environments.
sorting a huge array to rip out the relevant items based on category, would be way more expensive and slow, than having an array for each category, all ready to be converted into menu widgets.
storing an ItemName that accesses a data table is basically the same thing as a read only struct pointer (UE4 doesn’t have struct pointers, structs are a value type, and cannot be referenced).
you should look into Data Oriented Design:
Let’s be honest with ourselves - querying 1d containers is extremely fast. Especially with today’s current hardware. Searching a container with as few as 100 - 200 elements would have an insignificant effect on performance; even more so when using a spatial database. Like… I’m not sure what words to use to explain how insignificant the time it takes to query something that small.
If you really were that worried about performance you could have a master container and smaller containers that could contain each item type. That way you’d only have to worry about replicating the master array and all query/inserting/removing for the other arrays could be on the local machine. But then again, what’s the point? You should be spending your time on more important things than trying to get performance out of a 1d container with as few as 200 elements. ._.
“storing an ItemName that accesses a data table is basically the same thing as a read only struct pointer (UE4 doesn’t have struct pointers, structs are a value type, and cannot be referenced).”
Yeah, that’s the problem. And again, I really don’t know why it hasn’t been implemented yet. I’ve talked to an Epic employee about a month ago on why you couldn’t derive from structs in BPs, and although I felt his reasoning behind why was a little unfair, it was still understandable. But I really can’t see why they’d limit structures with this - especially since I’m using C++.
I mean, they have a whole webpage titled “Data Driven Gameplay Elements.” They probably should have a disclaimer that says, “Oh, by the way, structures can’t be passed by a pointer so have fun playing with 10+ arrays if you want any form of polymorphism!”
I’m sorry if this comes off as a rant - I don’t been to bad mouth Epic and their engine; I just think this is a major flaw in their design and hope they see how cumbersome the alternatives are.
“you should be spending your time on more important things than trying to get performance out of a 1d container with as few as 200 elements.”
im not sure where you are getting that 200 number from, we are talking about a list that can expand into 10s of thousands of objects. just dialogue objects alone will probably total over 200.
also, splitting these things into different arrays does not take any extra time on my part. the time i spend writing code that accesses these arrays is probably the same than the time you spend writing code that searches through the giant array, pulling out the relevant items to display. so its not extra work, its just a different approach.
why sort data at runtime to fit into menus created at compile time?
also, polymorphism is an object oriented feature that some languages have. in UE4, structs are not objects, they are not instantiated, they cannot be referenced, they are just passed around by value, and Epic doesn’t seem to have any plans to change that.
if structs could have pointers, they would need alot more overhead for garbage collection, they would be added to a global list of objects, they would waste memory on reflection code, and they would need a VTable… structs are designed to be light weight and efficient, but you want them to waste as much memory as objects.
The idea behind Data Oriented Design is to pack and group data belonging to one functionality closer together in a continuous memory block, in order to have less cache misses, getting rid of virtual functions and vtables.
its better to have a struct full of many small objects linked by pointers, than a big struct full of data that isn’t always used together.
this item management inventory system is the backbone of your game. its not premature optimization to organize the data based on the way its going to be used.
“im not sure where you are getting that 200 number from, we are talking about a list that can expand into 10s of thousands of objects. just dialogue objects alone will probably total over 200.”
We were obviously talking about an item system. Or are we pretending like we weren’t so you can try to make a point? Again, even with 10k elements, using a spatial database would mean instant query. I’m not sure why you think it’s such a big deal to query something like that. If you don’t believe me, test it yourself.
“also, splitting these things into different arrays does not take any extra time on my part. the time i spend writing code that accesses these arrays is probably the same than the time you spend writing code that searches through the giant array, pulling out the relevant items to display. so its not extra work, its just a different approach.”
…You do realize spatial databases do the query for you, right? It’s not like you have to write 20 lines of code to get a specific type. You would literally type index.Query(BOUNDS). Unless you’re implying it takes weeks to create something like a B-tree? Not sure how to respond to that…
“this item management inventory system is the backbone of your game. its not premature optimization to organize the data based on the way its going to be used.”
At this point you’re refusing to admit that tree data structures exist. I’m not sure what else to say to help you understand that you don’t have to brute force through a database; something you’re so kin on thinking. This whole arbitrary argument about performance is clearly a way for you to excuse not having this simple function.
And for the exert you linked, the author ignores B-trees. To inform for you: “B-tree is a self-balancing tree data structure that keeps data sorted and allows searches, sequential access, insertions, and deletions in logarithmic time.” It literally does what you’re arguing for you but behind the scene so you don’t have to deal with it.
well, my item system is a bit broad, i consider all things you can collect to be game items, including everything that goes into the save file. so every quest flag or dialogue flag or enemy killed or level unlocked or character introduced, would be items in my inventory.
i did not know about B-trees, so thanks for pointing that out, i am looking into it now. i have heard of octrees, and binary search trees, but i never knew about B-Trees. so i will have to do some tests and see if your idea is easier to manage. i know it won’t be more efficient at runtime, since my method doesn’t require searching at all, while yours requires O(log n) searches for each item, but it might be slightly more efficient for development time. thanks for the info.
but im pretty sure B-trees can be made without struct pointers or struct inheritance, by putting the structs in an array, and using their Index as if it was a pointer. any data that is ReadOnly, i would still store in separate spreadsheets.
“It literally does what you’re arguing for you but behind the scene so you don’t have to deal with it.”
no, it organizes the data far less efficiently, using arbitrary rules about how many items a folder can have, instead of using rules that correspond to how the data will be displayed. and it doesn’t save me any time, adding a new item category is a rare event that is easy enough with my current method, and could be made easier with methods that are far less detrimental to performance.
putting things where you want to retrieve them, in the order you want them displayed, skipping sorting all together, will always be more efficient than putting things in a bag and searching for each item in a list.
but i would love to hear more about how you would implement B trees in UE4. when i search for items, i use Names, but you can only compare Names for equality, there is no greater than or less than comparisons for text in blueprints. so would you search for items by a number ID?
Btrees sound great for an operating system file browser that the end user gets to organize. but in a video game, the organization of the file system is hard coded into the game, and cannot be changed by the user, so you can make some optimizations utilizing the fact that you know how all the files will be displayed.
Btrees are nice, but using a name switch case to choose a pocket, then iterating over its contents to create a menu specific to that pocket, is extremely efficient, and it doesn’t seem difficult to manage at all.