Some help with item usage.

Game Mechanics
#1

Hi,

I’ve got Item() Class wich stores item id name and description and i have ConsumableItem() with extends Item().

This second item is supoused to be items wich after an use may be deleted from invetory (because the player ran out of them) and obviously they can be used.

So when i want to use a Potion, i add this:

effect = 1; // Where 1 = id of the add hp effect.
quantity = 50;  // Recuperable amount of the effect.
time = 0;        // In case of being a buff potion, how much time would it last. 0 is the default value and the program ignores it

The case is, that I’d like to add potions wich has more than 1 effect.

Example: Elixir wich adds 100hp and 100mp

How could i do this? Adding a new effect value would fix it but i dont think thats the best because it would be redundance in the database.

THank you :slight_smile:

#2

This might be overkill, but you could add an Effect class which contains the variables you listed (effect ID, quantity and time) and let each ConsumableItem hold a list of Effects.

#3

Already thought about that, but is to add too much memory for nothing. I’d prefer to do it in only one basic structure.

#4

Is 16 bytes per effect too much memory? -_-

#5

For an inventory with more than 300 items, tell me :slight_smile:

#6

so I assume because you store an effect id(you should use enums btw) you apply the effect later based on this id.
why not let the effect know how to affect something.
Now when you want to add a new effect you can just create one with new functionality. you can also create a MultipleEffectsWrapperEffectContainerHolder :slight_smile: for example which can hold what you requested, one effect to boost hp and one for your mana

ps: start worrying about memory when you store some million items.

#7

How could i do this? I’m still new to have an idea of how to structure. Thank you

#8

instead of having something like


class Player
{
void affect(Effect e)
{
  switch(e.type)
  {  
    case HP: this.hp += e.amount;break;
    case MP: this.mp += e.amount;break;
  }
}
}

have something like :


interface Effect
{
  void affectPlayer(Player player);
}
class HPEffect implements Effect
{
  void affectPlayer(Player player)
  {
    player.incHP(this.amount);
  }
}
class MPEffect implements Effect
{
  void affectPlayer(Player player)
  {
    player.incMP(this.amount);
  }
}
class Player
{
  void useItem(Item item)
  {
    item.getEffect().affectPlayer(this);
  }
}
#9

… 300 x 16 = 4.6kb.

That’s not even going to break a console. -_-’

#10

I understood everything but this line:


    item.getEffect().affectPlayer(this);

whats getEffect() exactly?

Thanks for the code, it was very useful :slight_smile:

#11

an Item would hold one Effect which the getter extracts(getEffect())

One can of course either hold a List with effects in a Item as theagent suggested or do it recursively with wrapper effects, one pseudo effect class holding other effects.

There are many ways to do this, you could also have a affectPlayer method in the Item class as well hyding the effect.

#12

OK thank you very much i got it :slight_smile:

This thread may be closed

#13

This is “food for thought” commentary…not suggesting anyone should change anything…cause whatever works (and is maintainable) is all good.

Someday I should get motivated a write up a description of how I handle game entities. My brain mostly targets very heavy data-driven models, so the first thing I ask myself is “How do these two things differs?” and if the ask can be “the data’s different”, then I don’t add a new abstraction (like extend a class). So from your write-up I’d never have a ConsumableItem() which extends Item() because they only differ by data (where code is data). Also I’m not very keen any the suggested solutions. Why can’t a NPC/monster drink the potion? Also I strongly dislike what I consider over-usage of interfaces in Java culture.

#14

I guarantee when you work with any non-trivial codebase that you’ll find under-use of interfaces to be a worse problem than overuse. Interfaces represent types, classes are implementations of the type. The alternative is subclassing abstract classes, and if you already had another superclass, you’re out of luck.

#15

This is exactly the design philosophy that I strongly disagree with. Classes are types. Interfaces are types which specify cross-cuts in a otherwise independent type hierarchy. In my experience troubled projects fall into two rough categories. Those that do little to no advanced design and just start banging out code willy-nilly and those that blindly follow some SW engineer design model as if it were holy writ.

Dealing with cross-cuts is exact reason why interfaces exist. To flip the coin a set of concrete classes with no-explicit parent class which implement a single interface is pointless. A wash (work wise for the programmer) and more work for the runtime. Take that set and add more interfaces which they all implement, then both the programmer and runtime are losers. To be anal, one isn’t always “out of luck” in such situations. There’s always the option of composition…not that I’m advocating avoiding using interfaces…that’s just as silly as over-usage.

#16

Obviously a class also represents its own interface. The language I used might have implied otherwise, and that wasn’t intentional. The point is that people shouldn’t think of interfaces as “stripped down classes and you can have more than one”, they should think of them as the primary types themselves, with the implementation details kept elsewhere.

Any design philosophy can be taken too far, but I’d rather people erred on the side of being too flexible by using the narrowest interfaces possible, rather than forcing me to subclass and hack around the parts that don’t fit.

#17

Guys please, i already told this thread could be already closed.

If you want to discuss that open another thread any other place :slight_smile: thanks

PS: Each person has each own thougths about it’s own style of porgramming. Respect that.