Hello,

I'm interested to hear peoples thoughts on what would make a good structure for a load-out system.

Requirements:
  Designers will specify some default load-outs.
  Designers will have to specify loadout item pre-reqs.
  In game players can create custom loadouts.
  Items selected for the loadout will have costs, and pre-requisites (eg an attachment for an axe)
  There are different types of items. (Weapons, Perks, Aura's, Recipes, Etc)


Some things I've thought is that loadout specification is a separate problem from verifying weather a loadout is legal.
This leads me to think of a loadout as just a set of symbols. But then that would require lookups of some sort.
And then I start wondering about adding structure to the loadout specification which would make the definitions do some of the loadout checking (eg. # of allowable weapons)

But overall, I'd like to hear your thoughts on what would make a good loadout system.
  

I feel your question is a little too general and the requirements are quite broad. A proper design requires a proper definition of what encompasses a load out. Does it include clothing items as well as weapons, items such as potions, etc? You need to define what can go where.

Are you thinking of things more like "classes" in Call of Duty or more like a set of gear as in Diablo 3?

Additionally, what help specifically are you looking for? Designing the system or implementing/developing the system?

@Jamison Thank you for helping me clarify.

I'm looking to answer the question of how I would structure my data?
I'm looking for help with drawing the line between loadout specification, and loadout verification.
The questions I want to answer are

• How will the loadout be stored in memory(structs)?
• UI will need to highlight the items the player can select so there will have to be a way to know what set of items is a valid option when using that UI, and I'm not sure where that information will live. It could live in the structure of the data. It could live procedurally. It could live in the data. 

The system will be very similar to the "classes" of Call of Duty.
 

• There will be a primary, secondary, and special weapon.
• Each weapon has special attachments that impact the weapons stats, or give the ammo special attributes like vampirism, or possibly impact character stats.
• Weapons have:
  • a limited and maybe variable number of attachment slots
• Attachments have pre-requisites such as:
  • The type of weapon it can be attached too
• There can only be so many attachments to one weapon.
• Attachments can have several tiers
• The player does not have to use all available loadout slots.
• There are slots for several Cards.
• Cards allow the player to buff themselves in different ways.
• Cards impact abilities, player stats.
• Cards can have several tiers.
• Most, if not all items have a cost associated with them.
• The player only has X points they can spend.
• Some Items have pre-requisites.
• A loadout is not the players starting inventory. It is a specification of what to grant the player in addition to base inventory.
• Granting a loadout item doesn't always increase the player's inventory.

I suppose I should put together some pseudocode/code before posting.

@Plotnus I think it's important that you take a step back from thinking about the structure of your data and the layout of your user interface. Break it up into logical pieces that you can then design and build independently of each other. You're trying to design a lot here and putting it all under what you are calling the "loadout system."

Realistically, this could be designed and built as multiple systems. The weapons, the attachments, the projectiles (ammo, as you say), cards, and loadout can all be different systems. A weapon can have multiple slots where attachments can be placed. A weapon holds an attachment. A weapon fires a projectile. The weapon itself does not have damage but the projectile it fires does (but of course, the same projectile could be fired by different weapons which could affect speed which could affect the damage). Do you see where I'm going here?

The idea here is to break it down into manageable chunks and design for a single chunk at a time. Of course, one design will affect another but it's important to get a core established for what each system is supposed to handle and accomplish. Only then can you start to think about how your data structure should be.

Once your core systems are designed, you can then think about to represent this visually with your user interface.

@Jamison
Thank you very much for the help. After reading and thinking about your post and thinking about the systems, I feel I got to a good spot. You helped me realize that I been too focused on the data and hadn't focused enough on the actual problem and how to split up responsibilities. So, thanks again. It helped a lot.