Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (108)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Some help with item usage.  (Read 2460 times)
0 Members and 1 Guest are viewing this topic.
Offline zengoku

Senior Newbie




Trying hard to program well >.<


« Posted 2012-02-01 15:27:17 »

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:

1  
2  
3  
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 Smiley
Offline theagentd
« Reply #1 - Posted 2012-02-01 15:32:41 »

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.

Myomyomyo.
Offline zengoku

Senior Newbie




Trying hard to program well >.<


« Reply #2 - Posted 2012-02-01 15:33:44 »

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.

Already thought about that, but is to add too much memory for nothing. I'd prefer to do it in only one basic structure.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3 - Posted 2012-02-01 15:38:20 »

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

Myomyomyo.
Offline zengoku

Senior Newbie




Trying hard to program well >.<


« Reply #4 - Posted 2012-02-01 15:40:18 »

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

For an inventory with more than 300 items, tell me Smiley
Offline Danny02
« Reply #5 - Posted 2012-02-01 15:43:07 »

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 Smiley 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.
Offline zengoku

Senior Newbie




Trying hard to program well >.<


« Reply #6 - Posted 2012-02-01 15:45:20 »

why not let the effect know how to affect something.

How could i do this? I'm still new to have an idea of how to structure. Thank you
Offline Danny02
« Reply #7 - Posted 2012-02-01 16:03:25 »

instead of having something like

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
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 :
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
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);
  }
}
Offline theagentd
« Reply #8 - Posted 2012-02-01 16:06:05 »

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

For an inventory with more than 300 items, tell me Smiley
... 300 x 16 = 4.6kb.

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

Myomyomyo.
Offline zengoku

Senior Newbie




Trying hard to program well >.<


« Reply #9 - Posted 2012-02-01 16:07:39 »

I understood everything but this line:

1  
    item.getEffect().affectPlayer(this);


whats getEffect() exactly?

Thanks for the code, it was very useful Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Danny02
« Reply #10 - Posted 2012-02-01 16:11:23 »

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.
Offline zengoku

Senior Newbie




Trying hard to program well >.<


« Reply #11 - Posted 2012-02-01 16:13:28 »

OK thank you very much i got it Smiley

This thread may be closed
Offline Roquen
« Reply #12 - Posted 2012-02-01 17:14:56 »

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.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #13 - Posted 2012-02-01 17:59:18 »

Also I strongly dislike what I consider over-usage of interfaces in Java culture.

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. 

Offline Roquen
« Reply #14 - Posted 2012-02-02 09:36:55 »

Quote
Interfaces represent types, classes are implementations of the type.
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.

Quote
The alternative is subclassing abstract classes, and if you already had another superclass, you're out of luck. 
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.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #15 - Posted 2012-02-02 17:04:28 »

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.
Offline zengoku

Senior Newbie




Trying hard to program well >.<


« Reply #16 - Posted 2012-02-04 03:42:24 »

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

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

PS: Each person has each own thougths about it's own style of porgramming. Respect that.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (17 views)
2014-07-30 21:08:39

Riven (23 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!