Hey there.
What would be a good way to assign a sort of “typing” to objects?
Say when I cause two objects to collide, I would then compare then two object’s “type”, or “element”, if you will.
Then decide a victor based on the comparisons.
I was thinking of enumerators, since it has an easy to access listing, but it doesn’t look like I can use branch nodes on anything but Booleans. Using Booleans sounds like a bit of a hazzle, and messy, when I have multiple elements to compare.
But what are the criteria here? How do we know which type > other type?
Hm, let’s do a simple example then. Akin to Pomémon.
Fire>Grass>Water
Fire>Grass>Water
Ah, so it’s completely arbitrary.
You can use enumerators for this, sure. Have 2 variables in each actor - enum MyType {MyElemelonType} and a list of Types {ElemelonsImBetterThan}:
If the types are the same, it’s a draw. If they’re different, you check the enemy type against a list you’re better than - if it’s a match - you win.
Essentially, each Pokemon knows what other types it can beat. If you need a more modular approach, you could turn that into Enum | Struct(enum) Map, wrap it with a function and add it to library. So it’s globally accessible and actors do not need to track what they’re good against - instead they’d query that function.
That’s pretty much it and should work as is with minimum amount of wire spaghetti. Untested, though 
Oh, so it was possible to convert enums into booleans. I couldn’t find any convert options when I tried, but perhaps I needed a specific node.
Ah, but pardon, what is this section doing?
Or rather, I can see the array is checking it’s better than an enemy’s element, but how did it get told which was better than the other?
Oh, so it was possible to convert
enums into booleans.
Not really, they’re just comparisons. Contains checks if a searched element is present in the array and returns True / False. It has nothing to do with enums, it just works with arrays of anything.
[…]but how did it get
told which was better than the other?
Each actor has an array with the types it’s better than - you populate it yourself so it’s fully customisable. You can see it in the bottom left of the image I attached.
Ah I see. This sounds very plausible.
I will try it out at my earliest convenience, and report back.
You have my thanks.
Hey there, pardon for quite the late response. My attention was caught somewhere else.
Your suggestion seems to be working well, and I decided to expand a little.
I’ll tell you what I’m aiming for right now.
I’m doing a simple card game where two players picks a card each and compares them. It’s essentially Rock Paper Scissor, but I added two other elements as well. I called them Light and Dark.
Dark would beat the three Fire, Water and Plant.
Light beats Dark, but causes Draw against everything else.
For now, I have a Card Slot actor, and Card Objects of each Element. When a Card Object of a is Spawned on top of the Card Slot Actor, an Element is Set. For this example, I’m using a Water Card.
I have also set the opponent to generate a random Element for testing purpose.
Once set, it calls the Game Mode BP and launch an element check, where your help came in.
Then I made what you suggested, and tried to make some additions.
The EnemyElement, PlayerElement and ElementIsBetterThan uses the same Enumerator list, and I looks like it should be fine.
As I’m doing more than just checking single elements for win, loss and draw conditions, I thought I needed to add some more nodes.
I was thinking a Switch could be useful, but I’m not quite sure I’m running into a dead end, or just unnecessary work.
You think I should use a different approach?
Hey, just telling you I think I got a good solution now. Since I figured I could just use drag and drop operations to carry all the “type” information, it became much easier comparing them now.
Thanks for the help.
Yeah, you can override the drag operation and use it to carry data between widget (and world objects, too).
Also, even though it may not be applicable in this very case, consider the following:
You can compare enums directly to ints, both above statements would return true. So if you list your enums:
…and something with Power 4 comes up, it will defeat the first 3 and tie with Earth.
Oh, you can store enumerators, inside another enumerator?
I went with this earlier.
BP Pastebin
Oh, you can store enumerators, inside
another enumerator?
Not really (well, you could wrap everything in structs and then nesting is quite doable, yes).
Here’s what I meant - if you look at the enumeration list, the element position on that list is equal to its int value. So you can treat elements’ positions as ints for comparison purposes.
Think of it as of an indexed list - the further down your are on the list, the greater your value is.
The above should make more sense; even though they’re just enumerators, you intrinsically know which material is stronger because of the list progression. So placing them in a logical order gives you extra data to work with. You know Steel is better than Iron because it is further down on the list.
This is not really applicable in your very case because your enumerators carry arbitrary values, regardless of their position on the list. That’s why the original script I posted was needed. But it’s good to know if you need to compare enumerators.
And yeah, introducing just a couple of new elements (Light and Dark) will definitely complicate things more. It will all stack in complexity Good luck!
Ah, this is rather useful. Surely not for this case, but I’d probably need something like this in some other card games.
I appreciate it.
