Search Unity

  1. Unity 2020.1 has been released.
    Dismiss Notice
  2. We are looking for feedback on the experimental Unity Safe Mode which is aiming to help you resolve compilation errors faster during project startup.
    Dismiss Notice
  3. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Design thoughts? Separate classes, generic, if/else/switch?

Discussion in 'Scripting' started by UnbridledGames, Jul 3, 2020.

  1. UnbridledGames


    May 12, 2020
    Sorry for the poorly descriptive title. I'm not sure how to describe my question.

    I'm designing a complex item system for a game, and trying to make it as modular/expandable as possible. The current idea I'm kicking around is to have items be a pretty generic class... Name, weight, primary physical material, general classification (weapon, armor, consumable, etc). And to have items have an "attribute" field... an array or list... probably a dictionary... not sure... of attributes, which define what items can do and what properties they have.

    So instead of having a Weapon class of items that inherits from the base Item class, a sword Item would have the "weapon" attribute. And inside that attribute class would be some bitwise flags like TYPE_SLASHING and WIELD_ONE_HANDED. In some int fields there'd be the min and max damage.

    It would have an attribute called "equippable", with bitwise flags like HAND_LEFT and HAND_RIGHT.

    When you try to equip the sword, the code checks it's attributes. If it's not equippable - you cannot put it in your hand. You could equip a wand to your hand... but if you try and make a melee attack, it doesn't have the "weapon" attribute so you'd just punch. Or something like that.

    I'm in the brainstoming and planning stage and I'm wondering if, code wise, it's any better or worse (and what the pros and cons may be) of making Attributes just a generic class, looking something like:

    public class ItemAttributes {
    public int idkey;
    public string name;
    public long bits;
    public int value1;
    public int value2;
    public float fordecimals;

    In that case, the attributes would need to be looped through looking for a matching one, and a block of if/else or switch code would need to pull the right numbers out of the generic named fields.

    Pros: Everything in one place, simple to populate
    Cons: Could get confusing

    Another idea was to have each attribute be a class, maybe with interfaces (not sure, pretty new to C# so I'm still learning all the details). Then each could have it's own named and specific variables, specific functions, etc. In that way it seems way easier to code, but possibly harder to have them in a list of attributes, of which there could be many different types.

    Is that making sense? I feel like I'm not explaining it well.

    Any thoughts on what I've written so far? I don't want to go too far down the rabbit hole just yet, in case I'm going at this all wrong.

    Oh, and the final thing to note, a reason why I'm trying to make this really modular: Items available in the game will be very customizable and new and varied items may be introduced at any time through an API repository. Very few, if any of the items will be hardcoded into the game distro iteself. So these items need to be created on the fly from json responses. So the ability to be flexible is paramount.

    And again, apologies if this is rambling and doesn't make much sense. I'm having a hard time putting to words the concepts I'm playing around with.
  2. Kurt-Dekker


    Mar 16, 2013
    My thought: make it work first, at least as a minimum viable set of functionality. You do not possess enough knowledge of your problem space to reason about organizational issues until you do the work. If you don't like how it ends up, change it. It's software. That means it's soft. It can change.
  3. R1PFake


    Aug 7, 2015
    It depends on how complex your system should be in the end, but I would just use a item base class and sub classes for specific item "types" which need more properties or additional logic instead of this item attribute class.

    For example a class Weapon with Item as base class, but don't create a new class for every weapon,
    don't make a Sword, Dagger, Katana etc just make one Weapon class and add the properties there, for example min/max damage, damage type.

    But if you really want to use the item attribute then you might want to use different names, because "bits" "value1" and "value2" is way too generic

    You can store the attributes in a dictionary with the id as key, then you don't have to loop over all of them if you just want to check a specific attribute.

    If you want to create multiple item attribute classes then you can still store them in the same list/dictionary if they all have a common base class (or interface)

    For your long flags you could use a enum instead, you can use them as flags too.
    Last edited: Jul 3, 2020