[Discussion] Interest in a Java Pokemon API?

[iTeruri]

Function Codes can (and probably will) still clash with the way engines are made. But that's the problem with writing an engine first and then use some third party Data Structures. It makes much more sense to start off with Data Structures (in this case third party ones, this project) and then build upon it; the engine. This limits users of this project in two ways:

- Those who start with the engine first will have to adapt their code to go along with the Data Structures. No matter how the Data Structures are build, this will always be a problem.

- Those who start with this project and build the engine upon it are still limited by the Data Structures. The Data Structures you use will affect your code.

When working on a project like this, those issues must be considered. I'd say don't wory about the first group. Thise who have an engine are better of writing their own Data Structures to work with the engine. They'll probably not use this project anyway.

The second group is much more important. And that's where to problem lies. Defining Items, Attacks and Abilities is the number one thing people will use this project for. You act like that kind of 'content' is not to be provided, but with classes for Items/Abilities alone, you can't make a game. People will define effects for those things, so it's something to consider while working on the project.

Function Codes may work fine for Essentials, but this isn't Essentials. It's good to consider different options. It will 100% define the way people will use this project, so it's not something to gloss over. The way your data is defined will influence the way the data is used, obiously. You may not care how the data is used, but you must think about how it'll be used to define it.

Alright, that gives me another idea:
What if items, attacks and abilities have a reference to an empty 'Effect' object? I wonder how that'll influence how people will use this project. My solution works perfectly fine with this Effect object and I'm inclided to say the 'Essentials solutions' works too: instead of the function code, they could have specific instances of the Effect class to determine the effect. It may be the way to go; it doesn't influence the way people use the Effect object.

Any opinions on this?

 

[Maruno]

I get the feeling that your idea of what this project is for is different to mine.

69,THUNDERBOLT,Thunderbolt,[COLOR=Red]007[/COLOR],95,ELECTRIC,Special,100,15,10,00,0,be,Cool,"A strong electric blast is loosed at the target. It may also leave the target with paralysis."

That's how a move is defined in Essentials. 007 is the function code. The wiki explains what each of these data are. My understanding is that this project will only define a move by defining the above details.

So given that, why is the "item/ability effects are per item/ability and move effects are per function code" approach so bad? Part of the definition of one of these things is defining what kind of effect it has, and the simplest way is to hardcode the effect and use a single number in the thing's definition (e.g. function code) to link that thing with that effect. Since practically every item/ability does something different, it is inefficient to use function codes for them, so you might as well just have their effects depend on which item/ability is it.

I can't think of any other option that works as well as the way Essentials already does it. Please give us an example of some other way you can think of (like I did with Thunderbolt), so we actually have something to look at. I'm failing to understand what you're thinking - I don't know if it's because of a lack of your knowledge of Essentials (which I'm basically a proponent of). I don't think you've actually explained how you specifically want it to work, so an example would help.

Once you've got a number (function code or ID number) that is used to identify which effect that thing will have, the engine can do whatever it wants to implement the effect (hardcoded or abstracted or whatever else). It's no concern of ours. All we're bothered about is having a way to indicate that one object's effect is different from another one's, and that's what the function code (moves) or ID number (ability/item) does. That's it.

If you want to include extra information in, say, a move's definition (e.g. the two bits of information: "it inflicts a status problem" and "paralysis" for Thunderbolt), then that is both making it harder to define a new move and restricting how the engine's developer makes their engine. Sure, you might save a dozen small classes (out of hundreds) by generalising the "inflicts a status problem" moves, but that's really not worth the effort. Perhaps you think reducing the number of classes is preferable to making it easier to both define new moves and create new effects, but I don't.

Your preoccupation with creating effects suggests that you want to make an engine using this project. There's no other reason to worry about it as much as you are.

 

[Atheriel]

- Those who start with the engine first will have to adapt their code to go along with the Data Structures. No matter how the Data Structures are build, this will always be a problem.

- Those who start with this project and build the engine upon it are still limited by the Data Structures. The Data Structures you use will affect your code.

When working on a project like this, those issues must be considered. I'd say don't wory about the first group. Thise who have an engine are better of writing their own Data Structures to work with the engine. They'll probably not use this project anyway.

Hopefully, developers shouldn't really need to adapt their code to my data structures. Why? Because they don't really DO anything. They don't have functional abilities that people are likely to debate. Suppose you're writing a game, and you don't want to make use of a commonly used field -- take dex colour, for example -- then you just don't need to call it. That's it.

On the other hand, if you want all of your species to have a new quality -- say, a boolean "nocturnal" value -- then simply extend the class, and use that. The only real thing that people will have to work around are the names of the methods, but in my opinion those are about as straightforward and canonical as I can imagine them.

As nice as it would be to just consider people who started their engine on top of this project, that's not really fair, and we can probably do better. I'd like to appeal to all the half-finished projects out there as well!

My understanding is that this project will only define a move by defining the above details.

This is what I had imagined as well. You can always fork the project and approach it another way if you'd like, maybe making it more amicable to certain kinds of engines. I'd even encourage that :)

I do, however, think that there are other approaches than the one Essentials takes, and it would be nice to facilitate them. I've tried to take a different approach to items, for example, by making use of an Attribute interface so that it's easy to add things like berry flavour to an item without extending it.

A discussion can be constructive, and frankly I'm much happier that people are debating and thinking about things than having no response at all.

 

[iTeruri]

Alright, so I'll try to explain myself a little better, this time. ^^

My last suggestion was exactly what you described, Maruno, but a bit more flexible. We have an object that represents the attacks. It has several properties, one of which is of the type Effect. Other properties include accuracy, type, physical/special, etc. (This data make come from several sources, like a database, a xml-file, etc. Objects hold the data for easy access. It's something Atheriel mentioned before. I think loading the data from a source when needed (at the start of the game for items, attacks, etc.?/when loading a map for specific maps?) is the way to go.) For now we are only interrested in the effect-field.

Like I said, the effect-field is of the type Effect. Effect itself is an Interface, but it doesn't actually contain anything. Developers therefor can use it anyway they want. I'll give two examples:

Maruno creates a class 'FunctionCode' that implements the Effect interface. When initiating the object, he can pass a reference to a FunctionCode object to the effect-field. This FunctionCode object could hold the actual function code, as well as optional parameters, or whatever Maruno wishes. Somewhere else in the code the FunctionCode object is used to make the effects work. This is how Essentials works, but instead it uses an object instead of a hexadecimal number.

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.

I think that this accomplishes several things:
- It's highly flexible. What I described couldn't be done with a Function Code alone. Everyone could use it in a different way.
- The objects itself don't care about the Effect in anyway. This is what you said: for this project, it doesn't matter how the effects are defined. (It is, however, still important to consider how developers will use this.)

You are both right that my first suggestion (in my first post) will push things too far into the direction of an engine. I however think that my corrunt solution or something like it is a far better solution than my original one. I hope that I explained myself I bit better this time. ^^

 

[Atheriel]

What if items, attacks and abilities have a reference to an empty 'Effect' object? I wonder how that'll influence how people will use this project. My solution works perfectly fine with this Effect object and I'm inclided to say the 'Essentials solutions' works too: instead of the function code, they could have specific instances of the Effect class to determine the effect. It may be the way to go; it doesn't influence the way people use the Effect object.

Any opinions on this?

Keep in mind that this is exactly what I suggested yesterday for Moves and Items. It also gives two options for developers: handling effects in their respective classes, and handling them in the engine and having the classes only contain a name or id field to identify them.

But leaving Items and Moves aside for a moment, I did consider adding an "Effect" field to Abilities. But then you'd probably have to use them like so:

Old way:

// During damage calculation, for example
if (pokemon.getAbility().getName() == "Adaptability") {
	// Change STAB to 2x from 1.5x
}

New way:

if (pokemon.getAbility().getEffect().getName() == "Adaptability") {
	// Change STAB to 2x from 1.5x
}

Optimal use of the new way:

// During damage calculation
if (pokemon.getAbility().getEffect() instanceof AffectsDamageCalculationEffect) {
	...
	else if (pokemon.getAbility().getEffect().getName() == "Adaptability") {
		// Change STAB to 2x from 1.5x
	}
	...
}

Really, how much would this change things? Or am I missing a way of using this field?

Alright, so I'll try to explain myself a little better, this time.

Edit: It looks like we're all thinking the same thing now :P

 

[iTeruri]

The true beauty comes in when people start using the field in different ways, I think. With these kind of projects it's important to make things as abstract as possible. While it makes more sense for the effect-field to just be some kind of identifier when the effects are hard coded, it might not make any sense with other ways of using the field. I do like the instanceof solution, didn't think of that one before. ^^

So you might code Adaptability like that, but using the same effect-field and Interface, but with a different implementation, I might code Adaptability like this:

public whatever damageCalculation()
{
    attacker.getAbility().getEffect().doEffect('attackingOpponent');
    //the ability should do it's effect that triggers when attacking the opponent.
    
    //calculate damge.
    //for this specific anility, the Pokemon class could have a STAB field, or something like that. Or a List of 'attack bonusses' that now has a HigherSTAB bonus or something, it depens on the engine.
}

We are still using the exact same Pokemon class, with the exact same Ability class and the same reference to a field of the type Effect. While I might have to change a few things around, for the most part the Data Structures are unchanged.

 

[audinowho]

Abilities are incredibly diverse. Even if we were to try and group them together in some heirarchy the way to group them would still be subjective and ought to be left to the dev using the library. Engines may differ, especially when people (like me!) are interested in thinking up more spinoff-oriented fangames that still want to take advantage of the huge amount of pokedex data the game offers them. Pokemon Tower Defense has no end-of-turn.

@iTeruri Would you be fine with just extending the Ability class with a function working the same way that your proposed Effect class would do? The meaning of "effect" in your example would be to serve some active purpose "in engine" rather than just containing data to be read. It seems to me that having it as part of the library would go against modularity it's aiming for. From what I gather the OP wants to do is create something that leaves both the ends (what it's used for) and the means (how it's used for that) up to the dev.

 

[Maruno]

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.

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.

Optimal use of the new way:

// During damage calculation
if (pokemon.getAbility().getEffect() instanceof [COLOR=Red]AffectsDamageCalculationEffect[/COLOR]) {
    ...
    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.

 

[iTeruri]

@iTeruri Would you be fine with just extending the Ability class with a function working the same way that your proposed Effect class would do? The meaning of "effect" in your example would be to serve some active purpose "in engine" rather than just containing data to be read. It seems to me that having it as part of the library would go against modularity it's aiming for. From what I gather the OP wants to do is create something that leaves both the ends (what it's used for) and the means (how it's used for that) up to the dev.

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:

interface Effect {
}

Two examples of Effect classes, both would work with the project.

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
}

class secondExampleEffect impelents Effect {
    public void doEffect()
    {
         //Code to make the item that uses this effect work.
     }
}

An Item could look like this:

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).

// Edit:

Maruno, I do not know much of how Essentials works, but you don't seem to know much about how Java works, either. Because this project is made in Java, it is much more important to know how Java works, isn't it. My examples are just examples, ignore the part where I mention how it works like Essentials if it isn't the case.

Basicly Java works by having Object and Classes. Classes are like blueprints for Objects. They define what properties Objects have (fields; variables that are defined outside methods) and what they can do (methods, other languages call them functions. Same thing). Because some Objects are similar to it's other, you can extend one object to another, which we call inheritance. Example: the Cat class extends the Animal class. The Cat class now has all the fields and method as the Animal class, and more importantly when the program expects an Animal object (an object is just a reference to a class, basicly), you can pass a Cat object.
An interface is the same, only an interface can never be an object. If Animal is an interface, you can't make an Animal object.
My proposal uses this, but instead of animals and cats, is uses a generic Effect placeholder and whatever implementation the developer wants for effects. That's much less limiting than using, say, an integer variable for function code, because an integer can only ever be a whole number.

// Edit 2: (Still for Maruno)
Basicly the thing is: Effect is anything you want it to be. If you need it to be a FunctionCode then it can be a FunctionCode. If it needs to be something entirely else, it's something entirly else. You don't want people to force using it in one way or another, because as you mentioned, how the effects are programmed is up to the developer. Using FunctionCodes only forces you to use FunctionCodes, and that leaves out a lot of ways to program the effects.
You are also wrong about the last part of your last post. With the reference to the Effect object, we aren't forcing anything. To the contrary. If you want to hardcode everything, that's still a posibility, but instead of getting the FunctionCode, you get an Effect object. If you want to solve it using my original idea, you can do too. But my original idea can't be done using a FunctionCode.

 

[Maruno]

Maruno, I do not know much of how Essentials works, but you don't seem to know much about how Java works, either. Because this project is made in Java, it is much more important to know how Java works, isn't it. My examples are just examples, ignore the part where I mention how it works like Essentials if it isn't the case.

Basicly Java works by having Object and Classes. Classes are like blueprints for Objects. They define what properties Objects have (fields; variables that are defined outside methods) and what they can do (methods, other languages call them functions. Same thing). Because some Objects are similar to it's other, you can extend one object to another, which we call inheritance. Example: the Cat class extends the Animal class. The Cat class now has all the fields and method as the Animal class, and more importantly when the program expects an Animal object (an object is just a reference to a class, basicly), you can pass a Cat object.
An interface is the same, only an interface can never be an object. If Animal is an interface, you can't make an Animal object.

Ruby works the same way. I know all this.

My proposal uses this, but instead of animals and cats, is uses a generic Effect placeholder and whatever implementation the developer wants for effects. That's much less limiting than using, say, an integer variable for function code, because an integer can only ever be a whole number.

// Edit 2: (Still for Maruno)
Basicly the thing is: Effect is anything you want it to be. If you need it to be a FunctionCode then it can be a FunctionCode. If it needs to be something entirely else, it's something entirly else. You don't want people to force using it in one way or another, because as you mentioned, how the effects are programmed is up to the developer. Using FunctionCodes only forces you to use FunctionCodes, and that leaves out a lot of ways to program the effects.
You are also wrong about the last part of your last post. With the reference to the Effect object, we aren't forcing anything. To the contrary. If you want to hardcode everything, that's still a posibility, but instead of getting the FunctionCode, you get an Effect object. If you want to solve it using my original idea, you can do too. But my original idea can't be done using a FunctionCode.

I fail to see the point of interface Effect, since you could just make all the classes that would implement it stand-alone classes instead. That's just me not knowing whether interfaces do anything useful.

I do get what you're saying now. I still say it's beyond the scope of this project, though. Anything involving the implementation or use of effects is beyond the scope. We don't need to say what effects do; we just need to say that one effect is different to another one (which, incidentally, can be done by designating each effect with an integer, or by implicitly assuming that every thing has a different effect in the case of items/abilities, which isn't unreasonable).

You do what you like, though. I've become bored of telling you that you're overthinking things.

 

[Atheriel]

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.

I had actually posted that as a criticism of that approach... in any case, I think I've decided that it doesn't hurt to pander to both methods. There's almost no cost to adding an optional field. I've updated the class to handle an Effect field if so desired, but it's null by default and won't do anything unless you implement it yourself. The code is now at

"github.com/atheriel/jPokemon/blob/master/src/main/java/org/jpokemon/pmapi/pokemon/ability/PokemonAbility.java"

if you're interested. Again, I can't post proper links yet.

I will be pretty surprised if you can get it Abilities working effectively the way you want to, @iTeruri, but I'd love to see it what you can come up with :)

I do think it is a bad idea to amalgamate the effects into one class (why? because what do all effects have in common?), so there is no generic Effect interface.

I fail to see the point of interface Effect, since you could just make all the classes that would implement it stand-alone classes instead. That's just me not knowing whether interfaces do anything useful.

Useful, but not odious. Interfaces are a way of keeping track of inheritance without actually extending classes. It's a Java staple, since classes can only extend one other class, but can optionally "implement" as many interfaces as necessary. Interfaces differ from normal classes in that they aren't allowed to contain fields, and their methods don't actually do anything on their own. It's sort of the way that Java enables modularizing things in any non-linear fashion.

That sounds ridiculous, I know, but they're hella useful in cases like this. It means that an engine can be aware of Abilities having an Effect without actually having any strict functionality imposed on them.

 

[iTeruri]

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:

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:

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.

 

[Atheriel]

If you wanted to write up something tutorial-style on how to implement this, it might make a good addition to the site/wiki. And I'd be grateful, of course.

 

[audinowho]

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:

interface Effect {
}

Two examples of Effect classes, both would work with the project.

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
}

class secondExampleEffect impelents Effect {
    public void doEffect()
    {
         //Code to make the item that uses this effect work.
     }
}

An Item could look like this:

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:

class JPokemonAbility {
    String name;
    int code;
}

Here's an equivalent that does not require an Effect class inside the library:

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.

 

[zingzags]

This would definitely be useful for people using Java. I'd be happy to help out - I haven't used Java before, but I learn quickly, plus I know all about the PBS files and data structures in Essentials.

Seeing as you know how to program in ruby Java should be a sinch for you. Have you ever tried programming in C++? If you have, then you are golden. But the only difference in all programming language is libraries and syntax's.

@TS, I do not mind helping out, I have interest in java game dev. I just need to brush up on my java more.

 

[Atheriel]

I don't really see adding a field as compromising the library's generality. So long as it's apparent from the documentation that you have options, the minor increase in clutter could probably be forgiven. There's no obligation to use the Effect field, any more than there's an obligation to use the dexColor field for a species.

 

[Koran]

The funny thing is, you're actually doing the hard part...
There's tons of open source tile based java games and even SLICK2D.

I do however, like how you have managed the packaging in your project.

 

[FL]

I believe that the best way is to do something like Essentials.

For moves you can extends the function code main class (PokeBattle_Move, that isn't abstract or interface) and use function codes, a good use of OOP polymorphism. This can be done using a factory method that dinamically instanciate the classes as reading the move data, this can be done with reflection API.

The items are done by procedures (that can be done in java extending an interface using anonymous class). Note that some similar itens uses the same procedule (ItemHandlers::UseOnPokemon.copy(:PARLYZHEAL,:CHERIBERRY)).

The abilities are done using condition in battle cycle, as well the hold items.

A thing that essentials lacks is some more flags in the moves. I believe that we can add an extra flag to moves that can be used to turn the function moves that takes a status effect (poison, burn, among others and even confusion) to only one function move with the status flag. Maybe you can also use this flag as an array.

Maybe is a good thing to do function codes to itens/abilities, like the item stats change (plates), but I disagree that you need to extends every class/implements every interface for every specify effect. I agree with Maruno that is more simple to only read a class attribute (like a code or the name) to do this.

A side note: I have experience with Ruby/Java/Essentials.

 

[Atheriel]

I believe that the best way is to do something like Essentials.

For moves you can extends the function code main class (PokeBattle_Move, that isn't abstract or interface) and use function codes, a good use of OOP polymorphism. This can be done using a factory method that dinamically instanciate the classes as reading the move data, this can be done with reflection API.

I'm very much in favour of including factories, I just haven't written them yet. I don't think reflection will be necessary for the basic ones, either, although I'm currently making use of it to keep track of the instantiated types.

A side note: I have experience with Ruby/Java/Essentials.

I get the impression from your knowledge of reflection... :P

If you're at all interested in contributing, feel free to look at the project source and submit an issue/request, or pm me on the forums with suggestions!

 

[audinowho]

I'm pretty sure git has some forking functions for these kinds of things. Branching off, merging, pull requests, etc... it always sounded pretty cool, but I never really got to a point where I had to do something like that personally.