Thread: [Discussion] Interest in a Java Pokemon API?
View Single Post
  #32    
Old March 2nd, 2013 (03:07 PM).
iTeruri's Avatar
iTeruri iTeruri is offline
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
Posts: 276
I'm pretty sure all abilities will work, and quite good too. (=P) Yeah, it might be more work to create all the classes, but hard coding all the effects isn't too great either (believe me, I've been there). But both options are possible with the Data Structure, and that's the important thing. I still think neither option is perfect, but that's just because with these kinds of things you'll always have to sacrifce on one aspect.

I'll describe my implementation in the spoiler. It isn't about the Data Structures, so that's why I put it in the spoiler. "
Spoiler:

It'll probably work with Events, or something like that. The main BattleEngine will listen to these events. One of it's functions is to determine if the effect of an ability should happen or not (if it knows this) or just tell the ability to do something (passing the type of event that caused it to call the method, so the ability knows if it should do something). Something like this:
Code:
playerPokemon.getAbility().getEffect().doEffect(BattleEvent, battleField)
opponentPokemon.getAbility().getEffect().doEffect(BattleEvent, battleField)
Most abilities are pretty basic, only being activated by one particular effect. That's why I think a simple if statement in the doEffect is the best solution:
Code:
public class ExampleAbilityEffect implements AbilityEffect
{
    public void doEffect(BattleEvent trigger, BattleField battleField)
    {
         if(event instanceof EventIWant)
        {
               //Do something based on the event
               //Also, is that the way to check if an Event is of a special Event type? Can't remember.
         }
    }
}
Most abilities either:
A) Affect the Pokémon that has that ability (stat boosts, held item, forme changes, etc.)
B) Affect the opponent (show the name of the held item, stat lowering, etc.)
C) Affect the 'battle field' (cause weather, etc.)

That's where the reference to the BattleField object comes in. I'm not sure how exactly to take care of type A or B, but type C can use this object to affect the battle field. For type A and B a general reference to a Pokemon is needed, I imagine. Those could be passed as arguments when calling the doEffect() method or be fields in the BattleField class (but how would the ability know which of those two objects it should affect?). Anyway, when it has a reference to the object it can affect it, so that's something. It can't return anything, because there are three possible things to affect.

When one ability has more than one in-battle effect, it gets slightly more confusing by adding several if-statements. Similar abilities (like Torrent, Blaze and Overgrowth) are handled by Inheritance.

There are several abilities (and moves) that don't affect the fields within the Pokemon object directly. One example could be moves Block, Leech Seed, etc. Ofcourse, you could have a Boolean for those kind of things, but that's overkill. Instead I was thinking of having a List of 'tokens'. A token being present in the List affects how the BattleEngine processes several things. When trying to switch a Pokémon with the BlockToken, the game knows you can't. This, however, basicly boils down to 'hard coded check wheter or not a BlockToken is present', and thus I'm not quite happy with this idea.

Another isue might be effects outside of battle, but those I don't find that important. It's all about the battles for me. That's the important stuff, overworld stuff can be figured out later.


It's quite different than hardcoding everything, but I think that's the beauty of the solution we came up with.

Through this discussion, I've found out that I like thinking about these kinds of things (I'd call them architecture, but I don't know if that's the correct English term). Yeah, I've done these kinds of things during my school and my internship at a game company, but not quite on this level. Maruno may think I'm overthinking, but I'm just enjoying myself thinking about this. And I hope my contributions helped the project, because that's why I came here in the first place.
Reply With Quote