[Programming] Data Matching

[Draco18s]

Lets say I have a collection of foo, we'll call it Foo[].  And a collection of bar, Bar[].

I now have an item that has a subset of Foo[] as properties, chosen at random, and that I wish to assign a single bar to the item that "matches" the collection of foo already there, would it make more sense to start with the entire collection, Bar[], and remove non-matching items as each foo is added, or the reverse?

Here's what I mean:
I'm generating random items with random effects attached to them.
The foo:
Emits fireballs when used
Heals player when dealing damage
Provides air to the player when under water
etc.

The bar:
sword, staff, wand, ring, amulet, trinket, etc. textures

Also a name ("[Verb] [Noun] of [Adjective]") might qualify as 'bar' in this context, but I think that might be easier: [random foo].verb + [texture].noun + [random adjective].

I've done something like this at work, in both directions (the first was "which drug matches this wound" which was removal based* the second was essentially an image tagging system: select one or more tags, see all images with at least one tag).


*In hindsight, due to the changes made, this was a poor solution.  Hence the question.

[Mick]

My understanding is that every Foo is only valid for particular Bars, every Foo has a set of valid Bars that go with it, and from a random selection of chosen Foos, you want to create the intersection of all the associated Bar sets. Is this correct?

Do your Foo objects each define the subset of Bars that they consider themselves valid to match with?

[Draco18s]

My understanding is that every Foo is only valid for particular Bars, every Foo has a set of valid Bars that go with it, and from a random selection of chosen Foos, you want to create the intersection of all the associated Bar sets. Is this correct?

Pretty close.  Right now I'm using a fixed texture icon and have been applying random effects to it with no restrictions.  What you've typed is more "Bar implies ?Foo[]" while I'm looking for something closer to "?Foo implies ?Bar[]."  I can do it the other way, of course, (i.e. "I have generated a sword icon, what effects are valid for swords?") but I think it would be more interesting (from a player standpoint of finding the object) to generate a list of effects and pick an object that makes sense in context.  As this would allow for some "breakage" of the typical schema, due to multiple effects (as there may not be a single item type that could have them all).

Note:
? - Subset
? - For each

Do your Foo objects each define the subset of Bars that they consider themselves valid to match with?

Not yet.  I haven't even created all of my Foo Objects, as I've been building the framework to start plugging components in to.  But part of that is generating names and icons (the icon is largely meaningless, all told, which is why I would like to generate in the direction I've indicated, but it makes for good immersion).

[x4000]

Okay, let me see if I understand this properly:

1. You want a way to match an item of type Foo to a random item of type Bar, but only if Bar meets certain criteria.
2. You want no duplicates of the Foo to Bar matches, or do you care?

These are not something that are calculated per-frame, right?  So the simplest-to-humanly-understand approach is probably best, rather than the most-CPU-efficient approach.  Opinions on what constitutes the former will of course vary, since that's subjective.

But for us, what we tend to do in the Arcen code is:

- Put either bool flags or bit flags on the Bars.
- When creating a Foo, populate a list with the valid Bars based on the conditionals of our choice.
- Then randomly choose an item from that list, assign it to the Foo, and clear the list.

Obviously that would be a hideous approach if you have thousands of Bars that might be valid, but with dozens or even low hundreds it's not enough to blink at.  Specifically given how low frequency the matching would likely be.  And it's wonderfully easy to understand for anyone looking at the code, thus easy to maintain and avoid bugs in.

[Draco18s]

Okay, let me see if I understand this properly:

1. You want a way to match an item of type Foo to a random item of type Bar, but only if Bar meets certain criteria.
2. You want no duplicates of the Foo to Bar matches, or do you care?

I'm ok with matches not being unique, that's kind of the point.
In the case of multiple matches, one will be chosen at random.

It's a matter of figuring out what the pool to choose out of contains.

These are not something that are calculated per-frame, right?

No, it's a once-off.  The result will be stored and then retrieved during rendering.

So the simplest-to-humanly-understand approach is probably best, rather than the most-CPU-efficient approach.  Opinions on what constitutes the former will of course vary, since that's subjective.

But for us, what we tend to do in the Arcen code is:

- Put either bool flags or bit flags on the Bars.
- When creating a Foo, populate a list with the valid Bars based on the conditionals of our choice.
- Then randomly choose an item from that list, assign it to the Foo, and clear the list.

OK, so additive.  I can work with that.

Obviously that would be a hideous approach if you have thousands of Bars that might be valid, but with dozens or even low hundreds it's not enough to blink at.  Specifically given how low frequency the matching would likely be.  And it's wonderfully easy to understand for anyone looking at the code, thus easy to maintain and avoid bugs in.

Haha, I won't have thousands. XD
Right now I've got 26 (which includes multiple of the same base type, i.e. sword1, sword2, sword3).  So across only types I've got...6 or 7.

[x4000]

Cool stuff.

Honestly you can do your flags additive or not, it's up to you.  You can say "can't be on this Foo unless it has this flag" just as well as "can't be on this Foo if it has this Flag."  Bit flag matching is probably the easiest thing here, to put your Bars into categories that don't have to be mutually exclusive and which can be checked orthogonally.

[Draco18s]

Cool stuff.

Indeed.
I pretty much don't program outside of work unless I'm doing something neat.

[Draco18s]

Zaa!



There's actually a base class edit in effect, because SOMEONE over at Forge forgot to UNFINALIZE a function necessary to draw inventory sprites (so it can be overridden by a mod class file).