PDA

View Full Version : [Discussion] Interest in a Java Pokemon API?


Atheriel
February 24th, 2013, 11:03 AM
There seem to be plenty of projects going on in Java, but no one seems to be recycling code. Obviously, it's fun to write everything yourself, but sometimes things can get a little monotonous, and everyone's PokemonSpecies class probably looks pretty similar. I've been poking around looking for an API to contribute to, but I couldn't find one.

So: I'm wondering if there's any interest in an open-source (MIT? BSD?) API with the relevant data structures for Pokemon games. I don't mean a fully-featured engine. No graphics. No game loops. Just classes to hold things most people are probably using, and maybe some serialization/database functionality. I've written a lot of the pieces anyway, so I could get something basic up and running in short order if there's interest.

Koran
February 25th, 2013, 1:11 AM
I would be willing to help with this project.

I've been planning on doing it anyway... Project Collaboration always works best.

What I would like to see is a system akin to the one PokeMMO uses. (Loading data directly from the ROM)

audinowho
February 28th, 2013, 2:48 AM
Basically, data structures for Pokemon, moves, movepools, etc.? I'm not interested in using something like that (because I have no ideas...) but I once occurred to me how if so many people are getting into actually coding a Pokemon game without RPG maker, there would be a benefit in having some kind of generic library for "Pokemon" data that everyone seems to have trouble stuffing into their games.

Maruno
February 28th, 2013, 11:22 AM
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.

Atheriel
February 28th, 2013, 1:29 PM
I'm glad to hear that there's interest and even possible help :)

Any preference on how/where it should be hosted? Having a github repository makes sense to me, so that it can be forked and accept pull requests easily, and there is a built-in way to post javadocs/documentation through their pages feature. I suppose I'll have to take some credit/responsibility if it's so public, though.

As for progress on an initial release: items are (mostly) done, types are done, natures are done, species are (mostly) done, and I've started moves and pokemon. No trainers/players yet. The classes are intended to be highly extensible, and I've tried to make customization possible in a variety of ways.

There are plenty of things I haven't thought of a clever solution for yet (like a good way to account for the diversity of effects moves can have), but I'm more hoping to work on those after there's an alpha version out there.

iTeruri
March 1st, 2013, 5:08 AM
I haven't programmed in Java for ages, so I can't quite remember the specifics of the language. But this might help:

The Abilities are quite confusing when you look at their description and try to implement that. Take the Harvest (http://bulbapedia.bulbagarden.net/wiki/Harvest_(Ability)) Ability, for example. The easy way might be to add some code to the 'end of turn' functionality to check if the Pokémon has this Ability and then restore it's berry, etc. When you add ALL Abilities, this becomes unmanagable.

What I was thinking was to make every Ability it's own class (implementing the same interface). A Pokémon has a reference to an instance of it's ability (so we can do PlayerPokemon.ability). For this to work, you should break the abilities down to it's very basics.
Harvest only takes effect at the end of the turn. It then has a 50% chance to restore the held berry of the Pokémon. If the weather is Sunny, it always restore the berry.

This tells us something: the effect only works at the end of the turn. In other words: if we do PlayerPokemon.ability.doAbility() at the end of the turn, it should restore it's berry or not. But we must know it was called because it's the end of the turn. We could pass this as a parameter (kind of like a state) or instead call the method 'doEndOfTurnAbility()' or something like that.
Both options could work: the first one keeps the classes smaller, the second one may make the classes more readable.

Abilities can affect three things, as far as I can remember: the Pokémon with the ability, the opponent or the battle field. Both of those could be an object that's available to the methods in the ability classes. The BattleField object could keep track of things like weather, so our Harvest ability can work. The Pokémon objects keep track of the Pokémon, so things like hold items are also known to the ability object.

And now for attacks. I have no elegant solution, but I do have a solution. There is a design pattern called the 'decorator pattern'. A modified version could work for attacks.
Each effect is again broken down. For example, take an attack that deals both damage and has a chance to cause a status effect to the opponent.
DealDamage and CauseStatus are classes that implement the 'AttackEffect' interface. They both have a field called 'nextEffect' of the type AttackEffect. The constructor for AttackEffects have several parameters, that depent on the class that implement the interface: nextEffect is always present (but nullable), chance, damageToDeal, etc.
Attacks are created like thus:
Attack exampleAttack = new DealDamage(90, 60, 80, new CausesStatus(null, 'poison'));
In order this means: it's a damage dealing attack that has 90 accuracy and deals 60 damage. It also has a 80 chance of inflicting poison to the opponent.
Each AttackEffect class has a 'doEffect' method that works like the 'doAbility' method described above. It has access to both Pokemon objects (to calculate damage, deal damage and inflect the status) and the BattleField object (to things like causing weather). When the doEffect method is called, it also calls 'nextEffect.doEffect'. In our example, this causes the doEffect of the CauseStatus object to be called. Wheter or not the doEffect method of the next effect has to be called is decided by the current attackEffect. This is for chaining Objects.

Maruno
March 1st, 2013, 7:55 AM
There are plenty of things I haven't thought of a clever solution for yet (like a good way to account for the diversity of effects moves can have), but I'm more hoping to work on those after there's an alpha version out there.
I really think this, plus everything iTeruri said, is beyond the scope of this project. All you're really doing is recreating the PBS files of Essentials, and those don't describe what moves/abilities/items actually do. They just define what they are.

In Essentials, each move has a function code which is shorthand for "a particular effect". When a move is used, this code is checked, and the appropriate effect occurs. I'm sure simply creating a helpful list of which moves have which function codes (there's one on the Essentials wiki (http://pokemonessentials.wikia.com/wiki/Function_codes) which you could use) is sufficient.

For abilities and items, it's even simpler - the only check is which ability or item it is.

Let the actual engine developers do what they want when it comes to inventing the effects.

KingCharizard
March 1st, 2013, 7:59 AM
to have an API you need a base of some sort for people to use the code in, such as a graphics engine or a full blown engine without something the API is useless, basically your trying to write a group of base classes call it an API and tagging it complete when in reality all it is is a half finished framework/foundation...

API stands for "Application Programming Interface". It is essentially the language that you use to interact with an application. A finished one, its the way to use the application built by someone else and build with it..

kudoms
March 1st, 2013, 9:47 AM
This a great idea, but it would bring to life many generic pokemon games. As RPG maker has.

iTeruri
March 1st, 2013, 11:32 AM
I really think this, plus everything iTeruri said, is beyond the scope of this project. All you're really doing is recreating the PBS files of Essentials, and those don't describe what moves/abilities/items actually do. They just define what they are.

In Essentials, each move has a function code which is shorthand for "a particular effect". When a move is used, this code is checked, and the appropriate effect occurs. I'm sure simply creating a helpful list of which moves have which function codes (there's one on the Essentials wiki (http://pokemonessentials.wikia.com/wiki/Function_codes) which you could use) is sufficient.

For abilities and items, it's even simpler - the only check is which ability or item it is.

Let the actual engine developers do what they want when it comes to inventing the effects.

What I wrote is exactly what you said, only in a Object Orientated Programming (OOP) way. From what I gather Essentials wasn't written with OOP in mind.

What this project is, is reusable code that anyone can use. It's a base, in the same way Essentials is a base. In Essentials, I imagine, one can add new moves. The way it's defined is different from my proposed way of defining attacks, but there is nothing wrong with that.

The thing about objects and classes is, is that one developer can write either an Abstract Class or an Interface and other programmers can use that to build upon it. For example: we could write an Interface for abilities and let other programmers use that to define their own abilities. The Interface is kind of like a blueprint or a guide on how to create new abilities. With attacks it's the same: create a few effects, show how to use the system and developers can do the rest.

Atheriel
March 1st, 2013, 2:53 PM
to have an API you need a base of some sort for people to use the code in, such as a graphics engine or a full blown engine without something the API is useless, basically your trying to write a group of base classes call it an API and tagging it complete when in reality all it is is a half finished framework/foundation...

API stands for "Application Programming Interface". It is essentially the language that you use to interact with an application. A finished one, its the way to use the application built by someone else and build with it..

I strongly disagree with this. As I said in my original post, I have no intention of writing an engine. That is an enormous undertaking, and I would rather produce something useful, even if it is not the only tool you would need to write an application. Not all APIs are libraries. Think of the Apache Commons, for example.


Let the actual engine developers do what they want when it comes to inventing the effects.

I'm very much in agreement with this. I have no intention of building classes for instances of anything, really (scripts are a much better way to accomplish things like Abilities, Moves, and Items anyway). That being said, the interfaces still need to be powerful enough for engines to find them worthwhile to implement, and to be capable of handling scripts/components/attributes/aspects or whatever other method a developer would actually want to have the logic or calls carried out by. Event systems seem like a good idea to me, too.

What I wrote is exactly what you said, only in a Object Orientated Programming (OOP) way.

Java really doesn't necessitate OOP! I like some of your ideas about what abilities should possess, but think about your system this way: there are dozens of abilities. Maybe, if you really needed to, you could write a class for each one. But what about the 600+ items? Or the 600+ moves? You'd be doing an incredible amount of copying for each one. There are better approaches. Koran mentioned loading resources from ROM files, which I think is a great idea (although I have absolutely no idea how to approach that), and there are other classic approaches: databases, xml files, or json. Another great example of where to stay away from OOP is with NPCs. Should every NPC in your game be its own class? Or does it make more sense to have a file somewhere that dictates their behaviour within a given NPC interface? Maybe you could even edit it during runtime (as you can do with some of these methods) to help out with testing.

Maruno
March 1st, 2013, 3:25 PM
Java really doesn't necessitate OOP! I like some of your ideas about what abilities should possess, but think about your system this way: there are dozens of abilities. Maybe, if you really needed to, you could write a class for each one. But what about the 600+ items? Or the 600+ moves? You'd be doing an incredible amount of copying for each one. There are better approaches. Koran mentioned loading resources from ROM files, which I think is a great idea (although I have absolutely no idea how to approach that), and there are other classic approaches: databases, xml files, or json. Another great example of where to stay away from OOP is with NPCs. Should every NPC in your game be its own class? Or does it make more sense to have a file somewhere that dictates their behaviour within a given NPC interface? Maybe you could even edit it during runtime (as you can do with some of these methods) to help out with testing.
I imagine the idea was to create an abstract Ability class, and then for each actual ability, give it its own class which extends the abstract one. Essentials does this with moves (see the script section PokeBattle_MoveEffects).

However, there are set orders in which many effects occur or apply, which would mean you'd need an awful lot of abstracted methods to cover them all.

In the end, since practically every ability and item effect is different, they might as well just be implemented in the main battle code individually rather than try to abstract them. This is what Essentials does, and it's simple.

Also, creating abstract classes for various effects strays dangerously close to actually making parts of a game engine (because you'd need to define when each method is triggered and what arguments to pass, etc.). That's not within the scope of this project.

I'd say you should focus on simply getting the information into an easy accessible and readable format, and creating things which make it easier to edit this information (e.g. adding a new species). You might also want to create a Pokémon class for Pokémon entities to use (analogous to PokeBattle_Pokemon), and a Trainer class for trainer entities, since they're pretty standardised features. I don't think there's much call for anything beyond that.

Atheriel
March 1st, 2013, 3:53 PM
I'm surprised to hear that Essentials has only one abstract move class. Plenty of moves do very similar things. You could probably dramatically reduce the number of move classes if you had a few different kinds of general but non-abstract ones -- a ChanceToCauseStatusAilmentMove(Ailment, Chance), a OneHitKOMove(), and so on.

Maruno
March 1st, 2013, 4:03 PM
All moves with an identical effect (ignoring priority, chance of effect and a couple of effects which behave differently) share the same function code (http://pokemonessentials.wikia.com/wiki/Function_codes). Each function code has its own class which extends the basic move class, and which describes the effect associated with that function code.

I don't see anything wrong with the way Essentials works in this regard. Be careful about trying to over-abstract things, because it's more work and will at some point become pointless.

Atheriel
March 1st, 2013, 4:18 PM
What I was trying to point out originally was that strict OOP inheritance schemes don't handle things like move effects very well. As far as I can tell from your link, function codes are a piece of data attached to a Move instance so that effects can be handled in a more general way. That's a strictly non-OOP inheritance solution, and a completely reasonable one in my opinion.

So: when writing a move class that would actually be useful, it would probably be important to allow moves to have effects. Essentials (seems) to do this by adding a function code field. I'll need to do this by adding a field, too. How an actual engine handles that field isn't my problem.

Maruno
March 1st, 2013, 4:47 PM
Yes, a function code is just a number (a hexadecimal one). It's up to the engine to make moves do different things depending on its value (i.e. different effects).

Each move (during battle) is an instance of a class. There are many classes to choose from (as many as there are function codes), but they are all classes which extend the basic Move class. The basic Move class itself describes a move with no special effect, and is also extended by the dummy move class, failed moves, and the confusion self-damaging attack. Isn't this OOP? I'm not big on the jargon (inheritance versus extension, which are apparently different things).


So: when writing a move class that would actually be useful, it would probably be important to allow moves to have effects. Essentials (seems) to do this by adding a function code field. I'll need to do this by adding a field, too. How an actual engine handles that field isn't my problem.
Quite right.

How much do you know about Essentials? Given that it has a complete engine and sets of data, it's a good thing to look at to make sure you're doing everything you need to do.

Atheriel
March 1st, 2013, 5:52 PM
This might be an issue of semantics/different programming languages... and I'm getting the feeling that it's not that important to argue about. :P

I talk about OOP in the simplified everything-is-in-the-inheritance-tree kind of way, which is a bit of a caricature, but it is where most of the criticisms come from. Contrast it to things like entity systems, and so on. What using field(s) to hold effects means is that you don't actually need to extend the Move class at all. Just construct a new move, add some effect instances to the effect field in the move, and you're set. Of course, you could do this automatically by defining a new class that extends Move and adds the effect(s) automatically, but it's not necessary. In that sense it's cheating the OOP approach, since you can get away with not having any new methods or fields for different kinds of moves -- they would be stored in the effect class instead. However, I haven't actually implemented any of this.

In other news: the Github site is up. I'm apparently not allowed to post links yet, though, so you'll have to copy + paste the http bit. I'm really not creative with names, so it's just called "jPokemon" for now.

Homepage: "atheriel.github.com/jPokemon/"
Source Code: "github.com/atheriel/jPokemon"
Javadocs: "atheriel.github.com/jPokemon/apidocs/index.html"

audinowho
March 2nd, 2013, 1:31 AM
It might be a good idea to check out the Pokedex Data structure (http://bulbapedia.bulbagarden.net/wiki/Pok%C3%A9dex_data_structure_in_Generation_III) for a view on how the data is organized. Although I haven't seen the code in the repo at this time, I'd personally vouch for having different "formes" treated in a list-like fashion such that any aspiring pokemon designer can tack on a new one if s/he pleased, without having to do the official dex way of adding formes at the end of the pokedex.


This a great idea, but it would bring to life many generic pokemon games. As RPG maker has.

In the long run, this is a good thing. It's cutting off unnecessary development time that could be spent doing something else more worthy of any fangame visionary's creativity. People who are developing amid a sea of other people using the same API to do the same things will be more tempted to tweak out something different eventually.

iTeruri
March 2nd, 2013, 5:22 AM
What I was trying to point out originally was that strict OOP inheritance schemes don't handle things like move effects very well. As far as I can tell from your link, function codes are a piece of data attached to a Move instance so that effects can be handled in a more general way. That's a strictly non-OOP inheritance solution, and a completely reasonable one in my opinion.

So: when writing a move class that would actually be useful, it would probably be important to allow moves to have effects. Essentials (seems) to do this by adding a function code field. I'll need to do this by adding a field, too. How an actual engine handles that field isn't my problem.

How would you make the attacks/abilities work? You say it's not your problem, but when making the datastructures to hold attacks/abilities you should consider things like that.

For example:
The Ability Speed Boost can be programmed like this: in the method that takes care of ending the turn, there might be a bit of code like this:


if(PlayerPokemon.ability == "SpeedBoost")
{
PlayerPokemon.speedModifier++;
}

if(OpponentPokemon.ability == "SpeedBoost")
{
OpponentPokemon.speedModifier++;
}

This is an easy solution, sure. Abilities aren't defined anywhere, Pokémon just have a field to determine their ability. The abilities are handled in the places where it makes sense (an ability that takes effect at the end of the turn is in the 'endOfTurn()' method, an ability that takes effect when hit by an attack is in the 'dealDamage()' method). But it's hard to maintain. When removing an ability you'll have to go through your entire code to remove all the (hard coded) effects of the ability.
Sure, when abilities, items, etc. are all their own class/object there are a lot of classes, but maintaining them is easy. When you want to modify an ability, to code you'll want to modify is right there in the class.

The same goes for Items. And attacks.

From what I gather, Essentials works like this:
An attack has a numerical value to determine it's effect. The player attacks and then something like this happens:

public void manageAttack(Pokemon attacker, Pokemon target)
{
//1 = generic damage dealing attack
if(attacker.selectedAttack.functionCode == 1)
{
target.damage = attacker.selectedAttack.calculateDamage(attacker, target);
}

//2 = does damage and inflicts poison status
if(attacker.selectedAttack.functionCode == 2)
{
target.damage = attacker.selectedAttack.calculateDamage(attacker, target);
target.inflictStatus("poison");
}

//3 = inflicts poison
if(attacker.selectedAttack.functionCode == 3)
{
target.inflictStatus("poison");
}
}


That's a lot of repeated code, that's hard to maintain. It's easy to add new attacks, sure, but the easy solution is not always the best.

While this project isn't about how the user will make these things work, it's something you'll have to think about. When the classes you provide are easy to use, developers can use them to create something truly epic. When the classes you provide are a hassly to use and program with, they;ll ditch them and create their own classes. And that's exactly the problem you wanted to fix in the first place.
I'm just throwing some idead out there, just like you, and that's great. With programming it's often best to think about things before hand and then start programming. My solution probably isn't the best, but neither is Essential's solution. The solution Gamefreak uses probably isn't the best solution neither, because most programming solutions sacrifce on one thing, while gaining on something else. The question is; what do you want to sacrifice (ease of use, ease of maintenance, etc.)?

Maruno
March 2nd, 2013, 5:54 AM
Perhaps you should have a look at how Essentials works before assuming how it works. ;)

Yes, the items and abilities are hardcoded, but all the item effects are put in a separate place for easy access (the script section PokemonItemEffects). The same goes for move effects - they're in their own script section. Abilities are hardcoded because every one is radically different and occasionally complex (e.g. are passive or continuous or apply in several different areas), and it would be redundant to have lots of calls to separate bits of code that define their effects instead.

Besides, removing the hardcoded code wouldn't be a problem. The name of the ability is part of its effect's definition, so just search for that. Alternatively, you can just ignore it; it's not doing any harm.

In any case, effects are still not something we care about. Seriously. Item and ability effects can be defined per item/ability, and move effects can be defined per function code. That's what we've decided on, that's how Essentials works, and it's fine. Nothing else to consider. We can't make any code here which actually implement effects, because that's the start of making an engine, and our code may well clash with how another developer wants to work (e.g. they might not want to use your PlayerPokemon.speedModifier method/value). As long as the developer knows that item/ability effects are per item/ability and move effects are per function code (which they will because we'll tell them in the documentation), that's it.

iTeruri
March 2nd, 2013, 7:34 AM
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
March 2nd, 2013, 8:57 AM
I get the feeling that your idea of what this project is for is different to mine.

69,THUNDERBOLT,Thunderbolt,007,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 (http://pokemonessentials.wikia.com/wiki/Defining_a_move) 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
March 2nd, 2013, 9:02 AM
- 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
March 2nd, 2013, 9:32 AM
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
March 2nd, 2013, 9:45 AM
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
March 2nd, 2013, 10:31 AM
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
March 2nd, 2013, 11:25 AM
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
March 2nd, 2013, 11:56 AM
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 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.

iTeruri
March 2nd, 2013, 12:07 PM
@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
March 2nd, 2013, 2:02 PM
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
March 2nd, 2013, 2:07 PM
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
March 2nd, 2013, 3:07 PM
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. ^^"

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
March 2nd, 2013, 3:11 PM
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
March 2nd, 2013, 9:43 PM
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
March 2nd, 2013, 10:00 PM
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
March 2nd, 2013, 10:45 PM
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
March 2nd, 2013, 11:24 PM
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
March 3rd, 2013, 4:18 AM
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
March 3rd, 2013, 9:11 AM
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
March 3rd, 2013, 10:42 AM
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.

Atheriel
March 3rd, 2013, 10:55 AM
It is incredibly easy to fork a project, especially on Github. Essentially:

1. Fork (i.e. get your own copy of) the project
2. Make changes
3. Submit changes to your version (commit)
4. Submit a pull request to the original (there's even a button for this)

It was easy to learn, and I've contributed to projects in the past this way without much effort.

UnderMybrella
March 28th, 2013, 7:30 PM
I'm actually creating a Mystery Dungeon kit, in a similar format. As for interfaces, I learnt the main use of them when creating another game. This is where Interfaces > Classes.

Say we have an Ability. Ability is a class. Then, we have a Pokemon, with it's updateState method.
Ability has a method. This method is called effect(), and receives a Pokemon. It then does everything it needs to.

Now. Let's say there are 10 abilities. We would like to avoid creating 600+ files for Pokemon, so we have 1 generic class that will do everything for us (Maybe some other helper classes too).

The updateState method looks something like this:

public void updateState(String state)
{
Ability a1 = this.primaryAbility;
if(ability instanceof AOvergrow)
(a1(AOvergrow)).effect();
... etc
//And then again for secondary effect
}

This is ridiculous. For every ability in the game, we add an extra 2 lines, and, with secondary abilities, that's 4 lines per ability!
However, with Ability as an interface, it's one line!
this.primaryAbility.effect()!
Sure, more classes, but you could narrow them down. You'd find a way :)

Atheriel
April 8th, 2013, 12:15 PM
Thank you for the pull request, Anglican. I will be putting up something more official for this project in the Resources section when I have time.

oxysoft
May 1st, 2013, 11:53 AM
Why hardcoding the abilities and moves? Register all the altering effects you need these skills (we'll call abilities and moves "skills") to know about then create a small program to create skills and register effects to them. Good abstraction will be needed in this scenario and this kind of system is exactly what I am planning for in PokeSharp.