Thread: [Discussion] Interest in a Java Pokemon API?
View Single Post
  #34    
Old March 2nd, 2013 (09:43 PM).
audinowho's Avatar
audinowho audinowho is offline
我是谁?
 
Join Date: Jul 2012
Gender: Male
Posts: 68
Quote originally posted by iTeruri:
I'm not sure I understand you, sorry.

My proposal is to have a Effect class that the developer can use in any way (s)he wishes to use it. It's just a reference to an object of the Effect type, that doesn't do anything. It's just a generic type to hold a reference. It doesn't serve an active purpose.

Note: I haven't programmed in Java for quite some time, so the specific may be off. I'm sorry.

Effect could just be something like this:
Code:
interface Effect {
}
Two examples of Effect classes, both would work with the project.
Code:
class FirstExampleEffect implements Effect {
    int EffectNo; //Some other part of the code knows what to do with this (example: heal). This is the FunctionCode as it's used in Essentials.
    //other fields that serve as optional parameters
}
Code:
class secondExampleEffect impelents Effect {
    public void doEffect()
    {
         //Code to make the item that uses this effect work.
     }
}
An Item could look like this:
Code:
class Item {
     //fields
     Effect effect;
}
Note that ability, attack, item, etc. could all use this generic Effect type.

The classes themself (the Item class that has the effect field and the Effect Interface) do not care what the developer does with them. Basicly it's like having a field to contain objects of the Object type, but slightly more specific (in naming, at least).
Let's say the library implemented abilities with only a name and a function code:

Code:
class JPokemonAbility {
    String name;
    int code;
}
Here's an equivalent that does not require an Effect class inside the library:

Code:
class SomeAbility extends JPokemonAbility {
    //...
    public Effect effectIUse;
}
It takes everything you write out and plan, and places it in the territory specific to the "what if" implementation that you're trying to take into account. "What if" scenarios in which someone else wanted each ability to, say- have a special effect in that one-time pokethlon-like minigame they plan to implement in their game- would be something built on top of the base class given by the library, not the library itself.

yeah... I still have my doubts on whether this kind of thing is necessary in-library; it still seems like an engine-side complication for a specific way of using the library that should distinctly be handled by the engine that chooses to do things that way. I'm pretty much opposite to Maruno in cases where this stands- no Essentials experience, yes Java experience; but all the same I'm in agreement with him on maintaining a neutral simplicity.
Reply With Quote