Jump to content
  • Advertisement

Loadout System Design?

Recommended Posts


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

  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.

Share this post

Link to post
Share on other sites

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?

Share this post

Link to post
Share on other sites

@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.

Share this post

Link to post
Share on other sites

@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.

Share this post

Link to post
Share on other sites

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.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!