Which is better for huge numbers of variables

Question

So, after I read a lot in JS over the past few days (I'm just starting with this), I came across three viable options for my project, which is a game by the way. In my game there will be about 200 items, for a total of about 30 characteristics / properties. But since the program should know that the Sword does not give damage from spells, I must give each item all these 30 properties, even if 90% is 0. So, here’s what I came up with, any advice is welcome:

var prop, obj = { Item1: "Boots", Item2: "Gloves", Item3: "Sword", Item4: "Cape" }; 

// Pretty sure I have to redo this somehow to put properties in it, it may not be so useful

 function Item(hp, mp, dmg, spd, luk) { this.hp = hp; this.mp = mp; this.dmg = dmg; this.spd = spd; this.luk = luk; } var BigSword = new Item(0, 0, 50, 20, 10) 

// I think this might be my best option, so there are as few variables as possible? or does it not matter? I decided with this option whenever I update totalHp and totalMp and totalDmg etc. In the update function, can I create a local variable called theItem = BigSword, and then just do theItem.hp, theItem.mp, and so it doesn’t have to look much for the variable and should it work relatively faster? Sorry for the newbie question, but does JS even have local variables in functions? As with if I do var theItem = any, then theItem will be invalid outside the function?

 itemNames = [ "Boots", "Gloves", "Sword", "Cape" ]; itemHp = [ 0, 0, 0, 50 ]; itemMp = [ 0, 30, 0, 0 ]; itemDmg = [ 0, 0, 50, 0 ]; itemSpd = [ 50, 0, 0, 0]; 

// This is the other option that I came across is a little ugly, but if it is faster or better than just using arrays, I am not against it.

But please keep in mind that, as I said, 200 pieces in total, each item will have about 30 properties. What do you think?

Thanks so much for reading and for the information provided, this is very much appreciated! thanks in advance

Answer 1

It is best to have a constructor, as in the first example. However, I would change a few things. First of all, for the constructor, you just pass a lot of numbers. This is bad because it is very easy to forget the order in which your numbers go. It would be best to pass the object to your constructor so that you can mark each property:

 function Item(props) { this.hp = props.hp; this.mp = props.mp; this.dmg = props.dmg; this.spd = props.spd; this.luk = props.luk; } var BigSword = new Item({ hp: 0, mp: 0, 5 dmg: 0, spd: 20, luk: 10 }); 

This is nice, but it’s still a pain, because you have all kinds of different objects, and, as you said, you will need to define 30 properties for each element that becomes dirty and time-consuming. At this stage, you find yourself in the area of ​​more complex objects-oriented objects. From here you have basically two options: inheritance and construction.

Inheritance

Using object inheritance to correctly define objects is probably the more common of the two, and quite simple. Essentially, you have a “class” of the object, and then subclasses of each class. Thus, you can have magic items and non-magic items like two classes. If you had a magic belt, perhaps you would need to inherit the properties of the Magical Item class. On the other hand, if you had a basic non-spellable sword, you would like to inherit it from the class of non-magic items.

But say you have magic scrolls and magic potions. These are both magic items, right? Therefore, you want to create a class called "Potions" and a class of "Scrolls", which both inherit from the class "Magic Item". Then you may have certain types of potions. Healing potions, possibly the “Magic Potion of Healing Allies” and the “Magic Potion of Healing”. Thus, you need different classes - and so on and so forth.

Javascript inheritance can be done in several different ways, and you can get a very detailed description, so I will not discuss it in my post. Here are some useful links to get you started with inheritance, though if you want to go this route:

• David Crockford on inheritance
• MDN on Inheritance and MDN Inheritance Revisted
• Alex Sexton on Inheritance

Structure

Composition is a concept that is heavily dependent on other freely typed languages ​​such as Python, which uses it quite widely. The main idea of ​​composition is that you have a base class of objects, and whenever you need a specific type of object, you add behavior or members to this base class. This is not as well known as inheritance, but it is definitely the one that I prefer.

In Javascript, it works with the base constructor, element, and then with other constructors that add the necessary behavior to your element. Let me take a look at the example I used for composition - the creation of a magic potion of healing allies. Here you have several excellent properties: magic item, potion, healing. With inheritance, you will do something like Item -> Magical -> Potion -> Healing Potions -> Allies . However, with the composition, you can add several types of behavior to the base class Item without having to install a huge chain of prototypes: Affect Allies , Potion , Healing .

Since composition is a bit simpler than inheritance (and I admit I'm biased), I will create a quick example in psuedo code:

 // base item class function Item(props) { this.someProperty = props.someProperty; this.someOtherProperty = props.someOtherProperty; } // potion behavior function Potion(props) { this.amount = props.amount; // IDK what amount means, just some random potion property this.color = "green"; } // healing behavior function Healing(props) { this.amountToHeal = props.amountToHeal; this.cooldown = props.cooldown; } // behavior to affect allies function AffectAllies(props) { this.allies = props.allies; for(ally in this.allies) { this.allies[ally].affect(props.affact); } } // at this point we have the various behaviors set up and we can create the Magical Potion of Heal Allies constructor: function MassHealingPotion(props) { var self = this; this.amount = props.amount; this.potion = new Potion(props); this.effect = new Healing(props); this.AffectAllies = new AffectAllies({ affect: function(ally) { self.potion.affect; }, allies: player.allies; }); } // you can now create a mass healing potion: var potion = new MassHealingPotion({ weight: 50, someProp: "someValue", someOtherProp: "someOtherValue" // and so on and so forth with whatever properties you want the potion to have }); 

Well, it turned out a little longer than I expected, and probably contains proportionally more errors than I would like, but I hope this conveys the main idea of ​​the composition.

Now easier to create objects is not even the best part of composition, but it is that you can reuse different types of behavior. You have a magic sword that whenever you launch an attack, it heals your allies. All you have to do is give him a member of healing and a member of AffectAllies and boom - the magic sword of healing buddies. With inheritance, you will need to create a Swords class in the Magical Items class (and then you will have two different Swords classes - one for non-magic swords, and the other for magic swords! Ew!), And then extend this using Healing Swords, etc. d. Etc.

You can go in any direction, inheritance or composition of the object. Both are equally effective for what you want to achieve.

But what about performance?

200 items with 30 piece properties? No problem. Glue them all in one gigantic array / object, boil them, mash, insert into the stew. The browser doesn't care. Your best bet is probably an object, but:

 var itemList = { bigSword: new BigSword(...); smallSword: new SmallSword(...); } 

Answer 2

I would prefer objects. I would start with a simple, general “Item”, and then build specific elements by “inheriting” from the general with prototyping .

This can probably reduce code redundancy and significantly increase maintainability.

Speedwise I have no clue, but I think that iterating through the values ​​of an array of 200 * 30 is also not so fast.

Answer 3

First you need to make a serious design effort. If you are just starting coding (as many developers do), you will only get so far and understand that your design has a fundamental flaw, and the application needs to be rewritten. It doesn't matter in the early stages, but once you have written a few hundred lines of code, it becomes quite tedious.

By all means write code for the prototype of things, but all you should expect from it is design tips, the code should be thrown away.

Your product list (or catalog) should be an object with methods for adding, deleting and updating items. Each player (character, avatar, whatever) just needs a list of his items and their condition. There must be global damage or renewal damage, or some function that receives items of a certain type and applies them to players of a certain type (for example, weapons that damage enemies, power revives the player and friends, etc.).

Only after you know all the players and objects and their attributes and actions, you can start creating interfaces and methods, and finally write the code.

Watch for the goal, which should be to develop an attractive game, and not just write a few thousand lines of code.