8 hours ago, Alberth said:

Note that in this way the game always has a monster object, so if the player can kill it, you need some sort of inactive or 'dead' state for the monster for the time between the kill and the respawn.

In my monster class I have a boolean 'alive'. Basically the only time 'fighting' is activated is when a character moves to a new room and the room contains a monster. A new monster is rolled and alive is set to true. The fighting continues until alive=false. Then fighting is set to false. Then normal room actions continue. I also have things like monster.'level', a boolean for 'magic' type, and other stats. I reference these in my main method. So if I replace the old monster object with a new one, that means the monster.alive (etc.) will stop pointing at the old object entirely so it can be destroyed by GC, correct? 

45 minutes ago, blesseddisciple said:

So if I replace the old monster object with a new one, that means the monster.alive (etc.) will stop pointing at the old object entirely so it can be destroyed by GC, correct? 

Primitive fields like your 'alive' boolean don't point at anything, but I'm guessing what you're asking about is the relationship (if any) between different instances of a class. If that is in fact the question, then yes, generally speaking each instance is separate and discrete from and unrelated to all other instances (aside from static fields).

Again, what keeps objects alive is (strong) references to them. A boolean field (to use your example) isn't a reference, so it plays no role in object lifetime.

Does that answer your question? Or is it something else that you're asking about?

I would have an array of computer objects named "computer1" to "computer32" and reuse them for whatever monsters are necessary by changing their properties. If hitpts are over 0, the object is alive. Ones that are not needed currently have visible set to false. The array is re-created for every different level (with needed length), but stays consistent during a particular level. I find that not re-creating or deleting objects during game play helps with debugging and helps avoid memory leaks in C++. In Java, maybe there would also be a small benefit of GC not being invoked unnecessarily (less jitter).

23 minutes ago, VoxycDev said:

I would have an array of computer objects named "computer1" to "computer32" and reuse them for whatever monsters are necessary by changing their properties. If hitpts are over 0, the object is alive. Ones that are not needed currently have visible set to false. The array is re-created for every different level (with needed length), but stays consistent during a particular level. I find that not re-creating or deleting objects during game play helps with debugging and helps avoid memory leaks in C++. In Java, maybe there would also be a small benefit of GC not being invoked unnecessarily (less jitter).

Some of these issues have already been discussed in the thread, but I think some reiteration might be appropriate here.

The impression I have is that the OP is working on a non-realtime game, in which case jitter (which is, I would say, generally a realtime phenomenon) shouldn't be an issue. Even in a realtime context I think it'd be worth considering whether pooling would actually be beneficial (see earlier in the thread for some relevant discussion).

Since the OP isn't using C++, I'll leave that part aside. I think it's worth considering though that pooling can introduce code quality issues that wouldn't exist otherwise, e.g. with respect to mutability, lifetime management, and so on. Pooling may be preferable and even necessary in some cases, but I'm not sure it should be preferred by default, or that it would be particularly appropriate for what the OP appears to be doing.

10 hours ago, Zakwayda said:

Primitive fields like your 'alive' boolean don't point at anything, but I'm guessing what you're asking about is the relationship (if any) between different instances of a class. If that is in fact the question, then yes, generally speaking each instance is separate and discrete from and unrelated to all other instances (aside from static fields).

Again, what keeps objects alive is (strong) references to them. A boolean field (to use your example) isn't a reference, so it plays no role in object lifetime.

Does that answer your question? Or is it something else that you're asking about?

What I meant was that my monster class has an instance variable like so, monster.alive..  So, if I reference monster.alive in my code it will be looking at whatever object is currently set to monster variable. Then, once the new object is assigned to monster, monster.alive looks at the new object and the old reference is gone correct. Just verifying I understand correctly. 

Yes it is. You can easily test such things yourself by doing a small experiment, for example:

public class Monster {
    public final int number;
    public boolean alive;

    public Monster(int number, boolean alive) {
      this.number = number;
      this.alive = alive;
    }

    public static void main(String[] args) {
      Monster m = new Monster(1, true);
      Monster p = m;
      System.out.printf("m: Monster %d, alive=%s\n", m.number, m.alive);
      System.out.printf("p: Monster %d, alive=%s\n", p.number, p.alive);

      System.out.printf("\nKill monster m\n");
      m.alive = false;
      System.out.printf("m: Monster %d, alive=%s\n", m.number, m.alive);
      System.out.printf("p: Monster %d, alive=%s\n", p.number, p.alive);

      System.out.printf("\nNew monster m\n");
      m = new Monster(2, true);
      System.out.printf("m: Monster %d, alive=%s\n", m.number, m.alive);
      System.out.printf("p: Monster %d, alive=%s\n", p.number, p.alive);
    }
}

Output:

m: Monster 1, alive=true
p: Monster 1, alive=true

Kill monster m
m: Monster 1, alive=false
p: Monster 1, alive=false

New monster m
m: Monster 2, alive=true
p: Monster 1, alive=false

With experiments like these it's simple to try anything you want to know. There is no substitute for experiencing it yourself!!

Note that my "System.out.printf" calls are a bit weird perhaps. I grew up with C, so I am used to this function. You may want to find another print function that suits you better.