Improving my combat method

[Dark Magician]

 

What am I reading o_O

this whole thing is literally the same as

if(npc == p.getInteracting()) {
    return true;
}

 

Doesn't really matter. Gets the job done, no complaints here.

[FrostBug]

@OP

You don't have to make a seperate class for the filter as I suggested; that's just my own personal preference, as I find it cleaner and better for code-reuse. The only actual difference is that you don't get the context snapshot, which wasn't needed in my example.

[Botre]

Doesn't really matter. Gets the job done, no complaints here.

 

It's redundant code though.

It might matter some day ^^

[Dark Magician]

It's redundant code though.

It might matter some day ^^

 

I see. I guess when the world explodes it may matter. 

Edited September 3, 2015 by Dark Magician

[Bobrocket]

@OP

You don't have to make a seperate class for the filter as I suggested; that's just my own personal preference, as I find it cleaner and better for code-reuse. The only actual difference is that you don't get the context snapshot, which wasn't needed in my example.

 

Just a thought, wouldn't it be better to have the separate class so that way you don't recreate the filter everytime its needed?

[FrostBug]

Just a thought, wouldn't it be better to have the separate class so that way you don't recreate the filter everytime its needed?

 

Well, you don't need to re-create it if you simply construct the filter and assign it to a global member; as such public Filter<> filterInstance = new Filter<>(){ .. };

But it certainly helps if you're using the filter across multiple classes and such. As soon as you need to construct an instance of this custom filter in more than 1 location, I would definitely not recommend doing it anonymously twice.

 

[Botre]

Well, you don't need to re-create it if you simply construct the filter and assign it to a global member; as such public Filter<> filterInstance = new Filter<>(){ .. };

But it certainly helps if you're using the filter across multiple classes and such. As soon as you need to construct an instance of this custom filter in more than 1 location, I would definitely not recommend doing it anonymously twice.

 

 

 

There is a misconception that creating many small short lived objects causes the JVM to pause for long periods of time, this is now false as well Current GC algorithms are actually optimized for creating many many small objects that are short lived, that is basically the 99% heuristic for Java objects in every program. Object Pooling will actually make the JVM preform worse in most cases. The only Objects that need pooling today are Objects that refer to finite resources that are external to the JVM; Sockets, Files, Database Connections, etc. The modern GC algorithms don't have this problem because they don't deallocate on a schedule, they deallocate when free memory is needed in a certain generation. If the heap is big enough, then no deallocations happen long enough to cause any pauses.

 

http://programmers.stackexchange.com/questions/149563/should-we-avoid-object-creation-in-java

 

(Just another side of the story I guess, not disagreeing with you but I saw an opportunity to confuse everyone a little bit more and so I figured: why not?)

[FrostBug]

http://programmers.stackexchange.com/questions/149563/should-we-avoid-object-creation-in-java

 

(Just another side of the story I guess, not disagreeing with you but I saw an opportunity to confuse everyone a little bit more and so I figured: why not?)

 

Well, okay.

But I meant mainly in terms of being easier to maintain. If you're creating 3 custom filters with the same checks in 3 different places, you'll have to update all 3 of them if something changes

ITT: Overanalyzing :p

 

Edited September 3, 2015 by FrostBug

[senpai jinkusu]

NPC target = npcs.closest(new Filter<NPC>() {
        @Override
        public boolean match(NPC npc) {
            return npc != null && npc.getName().equals("Yak") && !npc.isUnderAttack() && npc.getHealth() > 0 && map.canReach(npc);
        }
        });

noob question, i thought you couldn't instantiate interfaces, so why is this allowed?

 

edit: nvm it's an anon class so im guessing java understands it's a class and not a filter, i did not know this functionality was possible as my understanding of anon class is somehwat limited

Edited September 4, 2015 by senpai jinkusu

[fixthissite]

I see. I guess when the world explodes it may matter.

The thread is titled "improving", so don't take criticism so poorly. Use it as a ledge to pull yourself up.

Although it works, there's a bunch of excess processing. Some may be ommited by the JIT, but thats implementation specific (someone using a different type of VM may not get the same benefits); it's best to avoid excess processing within code.

Not only is it excess processing, there's a cognition issue. You are increasing the focus requirement needed to understand your code. This hurts when it comes to refactoring and scaling in the long run.

Just because something works does not mean it works well. Constructive criticism is what opens your eyes to things you may have not realized before. Take all the criticism you can get, it builds character.

[Dark Magician]

The thread is titled "improving", so don't take criticism so poorly. Use it as a ledge to pull yourself up.

Although it works, there's a bunch of excess processing. Some may be ommited by the JIT, but thats implementation specific (someone using a different type of VM may not get the same benefits); it's best to avoid excess processing within code.

Not only is it excess processing, there's a cognition issue. You are increasing the focus requirement needed to understand your code. This hurts when it comes to refactoring and scaling in the long run.

Just because something works does not mean it works well. Constructive criticism is what opens your eyes to things you may have not realized before. Take all the criticism you can get, it builds character.

 

Sorry I may have overreacted. I need to learn how to take constructive criticism.

 

Anyways been working on a new paint.

 

[fixthissite]

Sorry I may have overreacted. I need to learn how to take constructive criticism.

Anyways been working on a new paint.

That's the spirit, take all the advice you can get, research to filter out the bad advice.

Good luck on the paint, feel free to pm me for advice

Just another quick tip, for functional interfaces like Filter (interfaces with 1 method), you should use a lambda expression:

npcs.closest(npc -> ...);

Since anonymous classes are still classes, class files are generated for each one you declare. Since lambdas use method handles, they are not a victim of this. Shrinks the amount of space your project consumes and is less verbose. I also suggest checking out this thread about using MethodProvider's fields rather than getter methods

 

 

http://programmers.stackexchange.com/questions/149563/should-we-avoid-object-creation-in-java

 

(Just another side of the story I guess, not disagreeing with you but I saw an opportunity to confuse everyone a little bit more and so I figured: why not?)

It may confuse people into thinking VMs can handle many short-lived objects without worry.

 

For anyone whos wondering, the article is stating that GC algorithms have been adjusted to sweep dead objects when memory is needed (more specifically, for the young generation of heap).

 

If objects aren't continuously being created within a short time frame, then its most likely not a problem.

 

A better way to handle this situation is to profile your code, don't optimize based on assumptions

Edited September 4, 2015 by fixthissite

[Dark Magician]

That's the spirit, take all the advice you can get, research to filter out the bad advice.

Good luck on the paint, feel free to pm me for advice

Just another quick tip, for functional interfaces like Filter (interfaces with 1 method), you should use a lambda expression:

npcs.closest(npc -> ...);

Since anonymous classes are still classes, class files are generated for each one you declare. Since lambdas use method handles, they are not a victim of this. Shrinks the amount of space your project consumes and is less verbose. I also suggest checking out this thread about using MethodProvider's fields rather than getter methods

 

 

It may confuse people into thinking VMs can handle many short-lived objects without worry.

 

For anyone whos wondering, the article is stating that GC algorithms have been adjusted to sweep dead objects when memory is needed (more specifically, for the young generation of heap).

 

If objects aren't continuously being created within a short time frame, then its most likely not a problem.

 

A better way to handle this situation is to profile your code, don't optimize based on assumptions

 

Thank you very much! I've actually never used lambda exporession before, so will try it out, seems much better!

 

Again will defiantly look into all the things you posted.