• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Forum moderator applications are now open! Click here for details.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

[Discussion] Interest in a Java Pokemon API?

16
Posts
11
Years
  • Seen Apr 9, 2013
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.
 
6
Posts
11
Years
  • Seen Mar 3, 2013
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)
 
Last edited:

audinowho

Unovan Indeedee
84
Posts
11
Years
  • Age 34
  • Seen Mar 1, 2024
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

Lead Dev of Pokémon Essentials
5,285
Posts
16
Years
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.
 
16
Posts
11
Years
  • Seen Apr 9, 2013
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

iAm
277
Posts
17
Years
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 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

Lead Dev of Pokémon Essentials
5,285
Posts
16
Years
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 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

C++ Developer Extraordinaire
1,229
Posts
14
Years
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..
 
9
Posts
11
Years
  • Seen Mar 1, 2013
This a great idea, but it would bring to life many generic pokemon games. As RPG maker has.
 

iTeruri

iAm
277
Posts
17
Years
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 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.
 
16
Posts
11
Years
  • Seen Apr 9, 2013
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

Lead Dev of Pokémon Essentials
5,285
Posts
16
Years
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.
 
16
Posts
11
Years
  • Seen Apr 9, 2013
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

Lead Dev of Pokémon Essentials
5,285
Posts
16
Years
All moves with an identical effect (ignoring priority, chance of effect and a couple of effects which behave differently) share the same function code. 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.
 
16
Posts
11
Years
  • Seen Apr 9, 2013
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

Lead Dev of Pokémon Essentials
5,285
Posts
16
Years
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.
 
16
Posts
11
Years
  • Seen Apr 9, 2013
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

Unovan Indeedee
84
Posts
11
Years
  • Age 34
  • Seen Mar 1, 2024
It might be a good idea to check out the Pokedex Data structure 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

iAm
277
Posts
17
Years
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:

Code:
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:
Code:
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

Lead Dev of Pokémon Essentials
5,285
Posts
16
Years
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.
 
Back
Top