Interest in a Java Pokemon API?
View Single Post
March 2nd, 2013 (2:07 PM). Edited March 2nd, 2013 by Atheriel.
Join Date: Feb 2013
Originally Posted by
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
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.
Originally Posted by
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.
View Public Profile
Send a private message to Atheriel
Find all posts by Atheriel
Find threads started by Atheriel