question

Heya, @Steve Falzon.

I saw your post and comments/replies and wanted to make some notes that could be helpful to you.

Catalog Items can hold custom data. So they can be like templates for an item that include information you can change on PlayFab whenever you like.

Catalog Item instances can be added to a Player's inventory, and those instances can also include custom data for that specific instance on top of the data template from the Catalog Item data itself.

In that way, you could probably just make a single Catalog Item for many things with many small changes to data, and simply add data differences to each of those at the Catalog level, or at the Inventory Item Instance level, depending on your needs.

For example, you could have a "Competition" Catalog Item, and have data on it that could be used for options available for a Competition. Like, you could include a key-value pair of Key "SomeStuff" and Value "75,10,20,400,15,600" on the "Competition" catalog item. Then you can update these on PlayFab to make tweaks, and have the client check on what "SomeStuff" are available.

Taking it a step further, you could give the player an inventory item instance of "Competition" that has it's own data on it. Set a key-value pair on that inventory item instance's custom data to "CurrentSomeStuff" with a value of "0". And you could check the value of "CurrentSomeStuff" on the inventory item instance's custom data, against the Catalog Item's custom data "SomeStuff" values, to get the "75" value associated with that current selection.

An even further step, you can give them more than one "Competition" inventory item instance. Each of them could have a different "CurrentSomeStuff" value set to them.

So from your example, you may be able to just have a single Catalog Item for "Competitions", "Teams", and "Players". (Only three catalog items.) And customize the data for each in numerous ways to get a lot of the unique settings for the items you're talking about without having a massive catalog of items that has one unique Catalog Item for a lot of tiny data changes.

On one of my projects, we have a catalog of over 500 Catalog Items. Many of them are very specific, with a set of data unique to those items. Others are generic as I noted in this example, like a core object which has inventory instance item custom data set to show unique settings for the player that owns it. Each player can get several instances of those items, all with unique information stored on them in their inventory to differentiate between them.

I also manage the inventory item instances based on the limits associated with that, as well, only allowing a player to get so many items in order to stay within our limits. Often I've found items can be converted to be one single object, with some good data on it, and this improves a lot of different aspects of our data management.

Hopefully that helps you a bit on figuring out how to organize your Catalog Items a bit better, though.

@madmojoman, thank you ever so much for such a detailed answer. Really appreciate it, thank you! :)

I'm doing some things in a similar way to what you've suggested. I have competition, team and player items.

Team items are character creation items so they have their own inventory and stats. They contain players. Neither is stackable, I want them to take inventory slots. A player will have only a small number of each.

Player items are "tradeable" in that they may be sold but they're not tradeable with another player.

Custom data for each is really just Ids of the entities that live in Table storage mostly. This is because of the amount of data stored for each entity. Each competition, team and player has up to 10 years of real football match data and statistics and, reading other posts and docs, an external storage solution is probably the best fit which is cool because I'd built that before moving some things to playfab. For me it's about performance and table storage is quick.

I haven't decided yet whether a football club, which can have several teams - reserves, under 23s, women's team, etc, and can be in several competitions, should be the root. Or if a Competition, which has many teams should be. I'm getting there but have a few things to think about. In SQL Server, where the data is first imported to, a competition is the root of all things.

Thanks again for your suggestions @madmojoman and for taking the time to write such a comprehensive answer for me. I'll read over it a few more times, I wanted to say thanks before I go to work.