Announcement

Collapse
No announcement yet.

Max number of variables in a Struct?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Max number of variables in a Struct?

    Hi, Does anyone know the max number of variables a struct can have?

    #2
    Don't worry about that and if the struct have far too many, then you should rethink your design.
    "I have harnessed the shadows that stride from world to world to sow death and madness."

    Comment


      #3
      Originally posted by EvilCleric View Post
      Don't worry about that and if the struct have far too many, then you should rethink your design.
      In your opinion what is to many? I have around 50+ variables in my struct right now.

      Comment


        #4
        Consider a SQL database. How many columns are too many? More than 4000? One can write an entire book about that. The same goes for structs.


        Anyway, here is my personal preference in terms of structs.

        Take the "Sequence" node for example, put it in a BP, and see how many pins you can add, until you can't zoom out without compromising the correct lecture of pins' id. That number would be the max of the max for me and I would only use that in some extraordinary case.
        Hell, take the "Hit Result". It has around 14 variables. That's one large struct. Bigger than that, I tend to avoid.


        Structs can have structs inside them. Either people forget that or are just too lazy to think about their design.
        Composition and containers are your friends.

        I once saw something similar to this:

        Code:
        struct Character {
            char name[20];
            int age;
            char sex;
            ...
            FWeapon primaryWeapon;
            FWeapon secondaryWeapon;
            FWeapon sidearmWeapon;
            FWeapon backpackWeapon;
            ...
            int healthStats;
            int healthMax;
            int healthMin;
            int xpStats;
            int xpMax;
            int xpmin;
            int dexterityStats;
            int dexterityMax;
            int dexterityMin;
            int enduranceStats;
            int enduranceMax;
            int enduranceMin;
            ...
        }
        And this is just one tiny part.
        "I have harnessed the shadows that stride from world to world to sow death and madness."

        Comment


          #5
          What information is your struct holding?

          What kind of variable (+ their name, just so I can better understand what you're doing with it) you have?
          [Released] Multiplayer Combat Editor
          A-RPG Sacred Swords
          Auto-Chess Live Development
          Youtube Tutorials

          Comment


            #6
            Originally posted by Yun-Kun View Post
            What information is your struct holding?

            What kind of variable (+ their name, just so I can better understand what you're doing with it) you have?
            Inventory items like weapons, bullets, food etc. I know I need to trim this down and think it out better before I move on. Open image in new tab to zoom in, but you probably know that already

            Click image for larger version  Name:	struct.jpg Views:	1 Size:	483.2 KB ID:	1453659

            I'm making data tables right now to store the variables that won't change, that should trim this down, plus I am making categories to help split all this stuff up more neatly. Just looking for the best practices on this.
            Last edited by Cipher5; 04-01-2018, 08:11 AM.

            Comment


              #7
              Ok I better understand why you're asking how to improve. It's a pain to fill the metrics, read and maintain the usability of the nodes within the blueprint editor.

              It's about object oriented programming.

              Right now I suppose you have one class for item that "does-it-all" (it can be a consumable / a weapon or whatnot). Am I correct?

              If I am correct, you need to apply object-oriented principles to your tech design.

              This means;
              - having 1 parent class for all items, which contains the values / functionalities all items share
              - having 1 child class of item type you want which contain the values / functionalities of this item type
              - I'm sure you are spending a lot of time specifying the same values over and over in your data table for your different item categories (for each weapon you check the box 'IsWeapon'? for instance)
              - the idea would be to create subclasses depending on what values they have in common / which one are identical. all identical values can be contained in the class rather than the data table. The data table should only contain values that are going to be different for two items of the same type.

              This could lead to something like:

              BP_Item
              BP_StackableItem (child of BP_Item)
              BP_Consumable (child of BP_StackableItem)
              BP_Equipment (child of BP_Item)
              BP_Weapon (child of BP_Equipment)

              And then you create sub-structures for each type of items. You end up with more structures containing less variables, you spend less time specifying the same values over and over and you can better understand your structure at first glance.

              I also see things such as "IsItemInUse", it sounds weird to me to have "state" values stored inside a struct that looks like a list of static properties. I'm guessing you are never specifying this value within your data table (are you?) so why add it to the structure? Just let it be in the BP_Item itself no?

              I would also wrap up the different attribute bonuses as such:
              - EStat (an Enum of your list of Stats such as Health, Stamina etc.)
              - SAttributeBonus (a Structure composed of a EStat and a float).
              - SItemBonuses (a variable in your ItemStructure composed of an Array of SAttributeBonus)

              Instead of having StaminaRegen, HungerRegen etc. you have one single array named "ItemBonuses". Not only does it reduce the amount of rows, it also make items able to have 0 to X bonuses.

              And maybe not all items needs to have this value in their structure (which means the structure might not be read by the Item Data Table, maybe only Equipment does this and in this case this list of bonus should be contained within your EquipmentStructure).

              In addition to all of this, any item can still modify the values that are supposed to be generic and identical to all items of its type.
              Last edited by Yun-Kun; 04-01-2018, 08:49 AM.
              [Released] Multiplayer Combat Editor
              A-RPG Sacred Swords
              Auto-Chess Live Development
              Youtube Tutorials

              Comment


                #8
                Originally posted by Yun-Kun View Post
                Ok I better understand why you're asking how to improve. It's a pain to fill the metrics, read and maintain the usability of the nodes within the blueprint editor.

                It's about object oriented programming.

                Right now I suppose you have one class for item that "does-it-all" (it can be a consumable / a weapon or whatnot). Am I correct?

                If I am correct, you need to apply object-oriented principles to your tech design.

                This means;
                - having 1 parent class for all items, which contains the values / functionalities all items share
                - having 1 child class of item type you want which contain the values / functionalities of this item type
                - I'm sure you are spending a lot of time specifying the same values over and over in your data table for your different item categories (for each weapon you check the box 'IsWeapon'? for instance)
                - the idea would be to create subclasses depending on what values they have in common / which one are identical. all identical values can be contained in the class rather than the data table. The data table should only contain values that are going to be different for two items of the same type.

                This could lead to something like:

                BP_Item
                BP_StackableItem (child of BP_Item)
                BP_Consumable (child of BP_StackableItem)
                BP_Equipment (child of BP_Item)
                BP_Weapon (child of BP_Equipment)

                And then you create sub-structures for each type of items. You end up with more structures containing less variables, you spend less time specifying the same values over and over and you can better understand your structure at first glance.

                I also see things such as "IsItemInUse", it sounds weird to me to have "state" values stored inside a struct that looks like a list of static properties. I'm guessing you are never specifying this value within your data table (are you?) so why add it to the structure? Just let it be in the BP_Item itself no?

                I would also wrap up the different attribute bonuses as such:
                - EStat (an Enum of your list of Stats such as Health, Stamina etc.)
                - SAttributeBonus (a Structure composed of a EStat and a float).
                - SItemBonuses (a variable in your ItemStructure composed of an Array of SAttributeBonus)

                Instead of having StaminaRegen, HungerRegen etc. you have one single array named "ItemBonuses". Not only does it reduce the amount of rows, it also make items able to have 0 to X bonuses.

                And maybe not all items needs to have this value in their structure (which means the structure might not be read by the Item Data Table, maybe only Equipment does this and in this case this list of bonus should be contained within your EquipmentStructure).

                In addition to all of this, any item can still modify the values that are supposed to be generic and identical to all items of its type.
                Thank you for your input this will help me out a lot.

                Comment


                  #9
                  You can have up to 500 pins or so in an array, after that the blueprint starts running into visual display issues on the screen (does on my system) and you are going to run out of blueprint graph to display it all in as the blueprints have got limited space in the graph... But I needed all those pins for the image character selector

                  Comment


                    #10
                    Split that weapon struct, into assets part, weapon stats, bullet type. Make bullet type enum, and give it own (bullet) struct.
                    You want be able to swap visuals separately from weapon stats (rate of fire, or if it is automatic\single shoot, bullet spread) and from type of projectiles it spawns.
                    That will save time when adding new weapon types. Also create base weapon with all code, then inherit it into separate weapons.
                    First rethink how you code all those weapons.

                    Comment


                      #11
                      Can a Game Instance be able to Save and load (read and write) information to Data Tables? If so, how do we set this up? Because I'm doing a game with dialog, and in dialog, there are alot of storyline events that I need to keep track of going on between party members in different stages of the game....
                      Last edited by tozan; 04-04-2018, 11:10 PM.

                      Comment


                        #12
                        Originally posted by tozan View Post
                        Can a Game Instance be able to Save and load (read and write) information to Data Tables? If so, how do we set this up? Because I'm doing a game with dialog, and in dialog, there are alot of storyline events that I need to keep track of going on between party members in different stages of the game....
                        No, you cannot save a data table in runtime, but you can make a struct with all the variables you need, and save that.

                        Comment


                          #13
                          What good are data tables if we cannot read and also write to them to tracked when playing across the worlds that the player explores? The data needs to be remembered by the game those variables need to be saved and also tracked across the levels... How do dialog games save all their dialog event storylines and keep them up to date? Structs can't hold heaps of info After about 200 or so entries the screen all starts to slow all down in the editor and it take ages to input in the new variables.... Likewise the same with Blueprint Arrays, they are limited to the amount of space that the blueprint graph has which gives you about 500-600 pins before you run out of space and it does slow the whole system down the more pins you have... I think it will crash the engine if you try to put in all the game variables into the struct.

                          So do you mean that I have to set aside a data struct for each individual world to hold all the variables and all the storyline events going on of that world?? That might be more managable, but still come to about 200-300 or so variables for a world including all the different dialog storyline events I would have to also put in.

                          Can someone show me a load save system of how to to read and write these structs to disk so the game can beable to track all of the data.
                          Last edited by tozan; 04-06-2018, 09:54 AM.

                          Comment


                            #14
                            Originally posted by Yun-Kun View Post
                            Ok I better understand why you're asking how to improve. It's a pain to fill the metrics, read and maintain the usability of the nodes within the blueprint editor.

                            It's about object oriented programming.

                            Right now I suppose you have one class for item that "does-it-all" (it can be a consumable / a weapon or whatnot). Am I correct?

                            If I am correct, you need to apply object-oriented principles to your tech design.

                            This means;
                            - having 1 parent class for all items, which contains the values / functionalities all items share
                            - having 1 child class of item type you want which contain the values / functionalities of this item type
                            - I'm sure you are spending a lot of time specifying the same values over and over in your data table for your different item categories (for each weapon you check the box 'IsWeapon'? for instance)
                            - the idea would be to create subclasses depending on what values they have in common / which one are identical. all identical values can be contained in the class rather than the data table. The data table should only contain values that are going to be different for two items of the same type.

                            This could lead to something like:

                            BP_Item
                            BP_StackableItem (child of BP_Item)
                            BP_Consumable (child of BP_StackableItem)
                            BP_Equipment (child of BP_Item)
                            BP_Weapon (child of BP_Equipment)

                            And then you create sub-structures for each type of items. You end up with more structures containing less variables, you spend less time specifying the same values over and over and you can better understand your structure at first glance.

                            I also see things such as "IsItemInUse", it sounds weird to me to have "state" values stored inside a struct that looks like a list of static properties. I'm guessing you are never specifying this value within your data table (are you?) so why add it to the structure? Just let it be in the BP_Item itself no?

                            I would also wrap up the different attribute bonuses as such:
                            - EStat (an Enum of your list of Stats such as Health, Stamina etc.)
                            - SAttributeBonus (a Structure composed of a EStat and a float).
                            - SItemBonuses (a variable in your ItemStructure composed of an Array of SAttributeBonus)

                            Instead of having StaminaRegen, HungerRegen etc. you have one single array named "ItemBonuses". Not only does it reduce the amount of rows, it also make items able to have 0 to X bonuses.

                            And maybe not all items needs to have this value in their structure (which means the structure might not be read by the Item Data Table, maybe only Equipment does this and in this case this list of bonus should be contained within your EquipmentStructure).

                            In addition to all of this, any item can still modify the values that are supposed to be generic and identical to all items of its type.
                            I have another question.

                            "BP_Item
                            BP_StackableItem (child of BP_Item)
                            BP_Consumable (child of BP_StackableItem)
                            BP_Equipment (child of BP_Item)
                            BP_Weapon (child of BP_Equipment)"

                            So when I add an item to my inventory do I have to have separate arrays for each child class that was based off of BP_Item? Because right now I have just one array that stores all the items on my character. I'm guessing I would have a different struct for each child class? And need to have multiple arrays one for each child class then loop through each and add the items to my inventory display using UMG. Does this sound right or is there a better way. Wouldn't it be easier using just one array for the inventory? Thanks


                            Comment

                            Working...
                            X