Community

The PokéCommunity

We are still working on a better slogan!

Visit Index



Advertise here

Go Back   The PokéCommunity Forums > Creative Discussions > Game Development
Notices

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

Post Reply
Click here to go to the first staff post in this thread.  
Thread Tools
  #26    
Old March 2nd, 2013, 10:31 AM
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
Tournaments Joined: 0
Tournaments Won: 0

Advertise here
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:

Code:
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.
  #27    
Old March 2nd, 2013, 11:25 AM
audinowho's Avatar
audinowho
我是谁?
 
Join Date: Jul 2012
Gender: Male
Tournaments Joined: 0
Tournaments Won: 0
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.



Last edited by audinowho; March 2nd, 2013 at 11:31 AM.
  #28    
Old March 2nd, 2013, 11:56 AM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
Tournaments Joined: 0
Tournaments Won: 0
Quote:
Originally Posted by iTeruri View Post
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.


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


Quote:
Originally Posted by Atheriel View Post
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
    }
    ...
}
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.
  #29    
Old March 2nd, 2013, 12:07 PM
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
Tournaments Joined: 0
Tournaments Won: 0
Quote:
Originally Posted by audinowho View Post
@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:
Code:
interface Effect {
}
Two examples of Effect classes, both would work with the project.
Code:
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
}
Code:
class secondExampleEffect impelents Effect {
    public void doEffect()
    {
         //Code to make the item that uses this effect work.
     }
}
An Item could look like this:
Code:
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.

Last edited by iTeruri; March 2nd, 2013 at 12:26 PM.
  #30    
Old March 2nd, 2013, 02:02 PM
Maruno's Avatar
Maruno
Lead Dev of Pokémon Essentials
 
Join Date: Jan 2008
Location: England
Tournaments Joined: 0
Tournaments Won: 0
Quote:
Originally Posted by iTeruri View Post
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.


Quote:
Originally Posted by iTeruri View Post
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.
  #31    
Old March 2nd, 2013, 02:07 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Tournaments Joined: 0
Tournaments Won: 0
Quote:
Originally Posted by Maruno View Post
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.

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

Last edited by Atheriel; March 2nd, 2013 at 02:15 PM. Reason: Your double post has been automatically merged.
  #32    
Old March 2nd, 2013, 03:07 PM
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
Tournaments Joined: 0
Tournaments Won: 0
I'm pretty sure all abilities will work, and quite good too. (=P) Yeah, it might be more work to create all the classes, but hard coding all the effects isn't too great either (believe me, I've been there). But both options are possible with the Data Structure, and that's the important thing. I still think neither option is perfect, but that's just because with these kinds of things you'll always have to sacrifce on one aspect.

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

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

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

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

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

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


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

Through this discussion, I've found out that I like thinking about these kinds of things (I'd call them architecture, but I don't know if that's the correct English term). Yeah, I've done these kinds of things during my school and my internship at a game company, but not quite on this level. Maruno may think I'm overthinking, but I'm just enjoying myself thinking about this. And I hope my contributions helped the project, because that's why I came here in the first place.
  #33    
Old March 2nd, 2013, 03:11 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Tournaments Joined: 0
Tournaments Won: 0
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.
  #34    
Old March 2nd, 2013, 09:43 PM
audinowho's Avatar
audinowho
我是谁?
 
Join Date: Jul 2012
Gender: Male
Tournaments Joined: 0
Tournaments Won: 0
Quote:
Originally Posted by iTeruri View Post
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:
Code:
interface Effect {
}
Two examples of Effect classes, both would work with the project.
Code:
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
}
Code:
class secondExampleEffect impelents Effect {
    public void doEffect()
    {
         //Code to make the item that uses this effect work.
     }
}
An Item could look like this:
Code:
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:

Code:
class JPokemonAbility {
    String name;
    int code;
}
Here's an equivalent that does not require an Effect class inside the library:

Code:
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.
  #35    
Old March 2nd, 2013, 10:00 PM
zingzags's Avatar
zingzags
Creator or Pokemon Serenity
 
Join Date: Jan 2009
Location: Boston
Age: 20
Nature: Adamant
Tournaments Joined: 0
Tournaments Won: 0
Quote:
Originally Posted by Maruno View Post
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.
Pokemon Serenity is my fangame name.
name decided 12/15/09
Currently helping:
Pokemon ebony
and
Xenotime:

Last edited by zingzags; March 2nd, 2013 at 10:07 PM.
  #36    
Old March 2nd, 2013, 10:45 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Tournaments Joined: 0
Tournaments Won: 0
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.
  #37    
Old March 2nd, 2013, 11:24 PM
Koran
Unhatched Egg
 
Join Date: Feb 2013
Tournaments Joined: 0
Tournaments Won: 0
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.
  #38    
Old March 3rd, 2013, 04:18 AM
FL's Avatar
FL
Pokémon Island Creator
 
Join Date: Sep 2010
Gender: Male
Tournaments Joined: 0
Tournaments Won: 0
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.
  #39    
Old March 3rd, 2013, 09:11 AM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Tournaments Joined: 0
Tournaments Won: 0
Quote:
Originally Posted by FL . View Post
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.

Quote:
Originally Posted by FL . View Post
A side note: I have experience with Ruby/Java/Essentials.
I get the impression from your knowledge of reflection...

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!
  #40    
Old March 3rd, 2013, 10:42 AM
audinowho's Avatar
audinowho
我是谁?
 
Join Date: Jul 2012
Gender: Male
Tournaments Joined: 0
Tournaments Won: 0
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.


  #41    
Old March 3rd, 2013, 10:55 AM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Tournaments Joined: 0
Tournaments Won: 0
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.
  #42    
Old March 28th, 2013, 07:30 PM
UnderMybrella's Avatar
UnderMybrella
Some Game Developer
 
Join Date: Jan 2011
Location: Atlantis
Gender: Male
Nature: Calm
Tournaments Joined: 0
Tournaments Won: 0
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:
Spoiler:

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
The Monoball Challenge - Have you got what it takes to catch 'em all, but with only one type of Pokéball? http://www.pokecommunity.com/showthread.php?p=7889482
  #43    
Old April 8th, 2013, 12:15 PM
Atheriel's Avatar
Atheriel
Unhatched Egg
 
Join Date: Feb 2013
Tournaments Joined: 0
Tournaments Won: 0
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.
  #44    
Old May 1st, 2013, 11:53 AM
oxysoft's Avatar
oxysoft
 
Join Date: Sep 2009
Tournaments Joined: 0
Tournaments Won: 0
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.
PokeSharp Engine
Post 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 06:50 PM.

About Us
© 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.

Copyright
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. Header artwork by Jordanice of deviantART.

Social Media
If you would like to stay up-to-date with us on the go, when we're down, or other such things, follow us on social media sites--most notibly Twitter, Facebook, and Google Plus--by clicking on the links provided.

Design presented by Peitharchia. Special thanks to Hiroshi Sotomura and Ausaudriel.