Thread: [Discussion] Interest in a Java Pokemon API?
View Single Post
  #28    
Old March 2nd, 2013 (11:56 AM).
Maruno's Avatar
Maruno Maruno is offline
Lead Dev of Pokémon Essentials
Moderator
 
Join Date: Jan 2008
Location: England
Posts: 4,146
Quote originally posted by iTeruri:
I hope that I explained myself I bit better this time.
I'm just glazing over. Maybe it's because I haven't used Java before and you're using terminology I'm unfamiliar with. Now you've started talking about "interfaces", whatever those are.

I'm just going to need to see the product of whatever you're on about in order to understand it. I still think you're overthinking all this.


Quote originally posted by iTeruri:
I instead could make several classes that handle the effects, all implementing the Effect Interface. When I create a new Move I pass a reference to a AttackEffect class. When I want the effect to occur, I use the reference contained in the effect-field to do that.
How much do you know about how Essentials works?

In Essentials, you create a move object, which is an instance of a certain class. Which class depends on the function code of that move. Thunderbolt is an instance of class PokeBattle_Move_007. Another move could be an instance of class PokeBattle_Move_12D. All these classes inherit the basic class PokeBattle_Move, which contains everything needed to make a standard no-effect move. Each function code class contains one or two methods which override ones in the inherited class (usually def pbEffect), which describe the effect associated with that function code (e.g. paralyse target). I don't know how you would describe such a get-up, but that's how it works.

From what I've gathered after trying to make sense of your words for half an hour, you're proposing to completely separate the basic move class from any extra effects a move may have. That sounds unnecessary to me. I mean, it's a valid way of doing things, but "valid" doesn't mean "good". In any case, again, it's for the engine developer to deal with, not us.

Regarding the text I coloured in green, the choice of which AttackEffect class is used for a given move depends on the move's function code. All we need to do is supply the function code. No further thought required. Effects are to be coded by the engine developer in whatever way they see fit.


Quote originally posted by Atheriel:
Optimal use of the new way:

Code:
// During damage calculation
if (pokemon.getAbility().getEffect() instanceof AffectsDamageCalculationEffect) {
    ...
    else if (pokemon.getAbility().getEffect().getName() == "Adaptability") {
        // Change STAB to 2x from 1.5x
    }
    ...
}
It'd be nice if you could modularise everything like this, but as I've said, my main problem with this approach here is that there are loads of places where effects could happen. You'd need loads of different <whatever you call the thing in red> to cover everywhen an ability could apply, and even then you'd need extra stuff for lingering effects and other things.

It's all just a lot more work and code for the sake of being able to put the effects of things together in one place. This isn't necessary. There's nothing wrong with hardcoding them - if anything, doing so makes the code much clearer. Doing it your way forces a developer to use the <whatever you call the thing in red> and everything it contains, which restricts how they can make their engine.

Basically, it's a nice idea, but impractical here. We're not going for awards in code design, we're going for what works. KISS.
__________________
Reply With Quote