The PokéCommunity Forums  

Go Back   The PokéCommunity Forums > Creative Discussions > Game Development
Sign Up Rules/FAQ Live Battle Blogs Mark Forums Read

Notices

Game Development Your number one stop for anything related to creating games (except ROM hacks). You can even make your own!


Advertise here

Reply
Click here to go to the first staff post in this thread.  
Thread Tools
  #1    
Old February 24th, 2013, 11:03 AM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013

Advertise here
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.
Reply With Quote
  #2    
Old February 25th, 2013, 01:11 AM
Koran
Unhatched Egg
 
Join Date: Feb 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 by Koran; February 25th, 2013 at 03:25 AM.
Reply With Quote
  #3    
Old February 28th, 2013, 02:48 AM
audinowho's Avatar
audinowho
我是谁?
 
Join Date: Jul 2012
Gender: Male
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.
__________________


Reply With Quote
  #4    
Old February 28th, 2013, 11:22 AM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
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.
__________________
Reply With Quote
  #5    
Old February 28th, 2013, 01:29 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 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.
Reply With Quote
  #6    
Old March 1st, 2013, 05:08 AM
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
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.
Reply With Quote
  #7    
Old March 1st, 2013, 07:55 AM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
Quote:
Originally Posted by Atheriel View Post
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.
__________________
Reply With Quote
  #8    
Old March 1st, 2013, 07:59 AM
KingCharizard's Avatar
KingCharizard
C++ Developer Extraordinaire
 
Join Date: Dec 2009
Location: Pennsylvania
Age: 26
Gender: Male
Nature: Bold
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..
__________________
My personal website. UPDATED 8/29/2013
Reply With Quote
  #9    
Old March 1st, 2013, 09:47 AM
kudoms
Unhatched Egg
 
Join Date: Jun 2012
This a great idea, but it would bring to life many generic pokemon games. As RPG maker has.
Reply With Quote
  #10    
Old March 1st, 2013, 11:32 AM
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
Quote:
Originally Posted by Maruno View Post
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.
Reply With Quote
  #11    
Old March 1st, 2013, 02:53 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Quote:
Originally Posted by KingCharizard View Post
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.


Quote:
Originally Posted by Maruno View Post
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.

Quote:
Originally Posted by iTeruri View Post
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.
Reply With Quote
  #12    
Old March 1st, 2013, 03:25 PM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
Quote:
Originally Posted by Atheriel View Post
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.
__________________
Reply With Quote
  #13    
Old March 1st, 2013, 03:53 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 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.
Reply With Quote
  #14    
Old March 1st, 2013, 04:03 PM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
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.
__________________
Reply With Quote
  #15    
Old March 1st, 2013, 04:18 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 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.
Reply With Quote
  #16    
Old March 1st, 2013, 04:47 PM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
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).


Quote:
Originally Posted by Atheriel View Post
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.
__________________
Reply With Quote
  #17    
Old March 1st, 2013, 05:52 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 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.

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"
Reply With Quote
  #18    
Old March 2nd, 2013, 01:31 AM
audinowho's Avatar
audinowho
我是谁?
 
Join Date: Jul 2012
Gender: Male
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.


Quote:
Originally Posted by kudoms View Post
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.
Reply With Quote
  #19    
Old March 2nd, 2013, 05:22 AM
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
Quote:
Originally Posted by Atheriel View Post
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.)?
Reply With Quote
  #20    
Old March 2nd, 2013, 05:54 AM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
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.
__________________
Reply With Quote
  #21    
Old March 2nd, 2013, 07:34 AM
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
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?
Reply With Quote
  #22    
Old March 2nd, 2013, 08:57 AM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
I get the feeling that your idea of what this project is for is different to mine.

Code:
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 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.
__________________
Reply With Quote
  #23    
Old March 2nd, 2013, 09:02 AM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Quote:
Originally Posted by iTeruri View Post
- 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!

Quote:
Originally Posted by Maruno View Post
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.

Last edited by Atheriel; March 2nd, 2013 at 09:11 AM. Reason: Your double post has been automatically merged.
Reply With Quote
  #24    
Old March 2nd, 2013, 09:32 AM
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
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.
Reply With Quote
  #25    
Old March 2nd, 2013, 09:45 AM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Quote:
Originally Posted by iTeruri View Post
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:

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

Code:
if (pokemon.getAbility().getEffect().getName() == "Adaptability") {
	// Change STAB to 2x from 1.5x
}
Optimal use of the new way:

Code:
// During damage calculation
if (pokemon.getAbility().getEffect() instanceof AffectsDamageCalculationEffect) {
	...
	else if (pokemon.getAbility().getEffect().getName() == "Adaptability") {
		// Change STAB to 2x from 1.5x
	}
	...
}
Really, how much would this change things? Or am I missing a way of using this field?

Quote:
Originally Posted by iTeruri View Post
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

Last edited by Atheriel; March 2nd, 2013 at 09:46 AM. Reason: Your double post has been automatically merged.
Reply With Quote
Reply
Quick Reply

Sponsored Links


Advertise here
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Minimum Characters Per Post: 25



All times are UTC -8. The time now is 07:14 PM.


Style by Nymphadora, artwork by Sa-Dui.
Like our Facebook Page Follow us on Twitter © 2002 - 2014 The PokéCommunity™, pokecommunity.com.
Pokémon characters and images belong to The Pokémon Company International and Nintendo. This website is in no way affiliated with or endorsed by Nintendo, Creatures, GAMEFREAK, The Pokémon Company or The Pokémon Company International. We just love Pokémon.
All forum styles, their images (unless noted otherwise) and site designs are © 2002 - 2014 The PokéCommunity / PokéCommunity.com.
PokéCommunity™ is a trademark of The PokéCommunity. All rights reserved. Sponsor advertisements do not imply our endorsement of that product or service. User generated content remains the property of its creator.