i think we need your code to see what's wrong ...

F

So when you build your stored list of enemies at the beginning you are giving them all different initial conditions, right? And you want those initial conditions to be preserved for the next time you need a new enemy like that.

One thing you might want to consider is creating a different class for each set of initial conditions you want to use. So you'd have enemie, but the you'd extend enemie with enemieRed or enemieAgro or whatever you want to call your extra classes. Then you'd store the parameters for the initial conditions in each of those classes. Instead of storing a list and cloning one of the enemies in the list when you want a new one, you'd just construct a new enemie based on the type being asked for. But then you'd hand it back as an enemie so that the level asking for an enemie didn't have to keep a separate list for each enemie. It wouldn't even have to know how many enemie types there are, so long as they all had the same methods for updating and drawing and so forth.

Alternatively, you could put all of your initial condition code into the enemie class itself, keeping only one enemie class, but being guaranteed that every time you construct a new one it has slightly different initial conditions.

Probably you don't want to do either of those things because they would require a significant rewrite of your existing code, but I think they are the better way to go, rather than putting all the initialization code in one place and using all those switch statements that you use. It can become a real nightmare to maintain.

The other option is to implement some kind of cloning function for your enemie class so that you can get an independant copy of a particular instance of an enemie. You wouldn't have to follow the Java clone() spec, you'd just have to ensure that when you construct a new enemie you are able to intialize it with the values of the enemie being cloned.

As a simple example:

Code:

class A
{
  private int a, b, c;
  
  A(int _a, int _b, int _c)
  {
    a = _a;
    b = _b;
    c = _c;
  }

  A makeCopy()
  {
    A copy = new A(a, b, c);
    return copy;
  }
}

A anA = new A(1, 1, 1);
A anACopy = anA.makeCopy();
 

Because your enemie class has some of your own classes as data members, you'd just have to make sure that all of those classes support copying as well.
 

looks good so far ..

your problem is that you copy the pointers, when you say:

enemies[i] = eStored[A]

enemies[i]
and
eStored[A]

reference the same object, so if you alter enemies[i] then eStored[A] will get changed too.

what you need is a copy function so that objects in eStored stay unaltered:

Code:

// inside enemie class
  enemie copy ()
  {
      enemie tmp = new enemie();
      tmp.pX = width/2;
      tmp.pY = 10;
      tmp.colField = colField;
      tmp.LIFE = LIFE;
      tmp.hCheck = hCheck;
      tmp.hitCheck = hitCheck;
      tmp.sDraw = sDraw; // same problem
      tmp.motion = motion; // here you are running into the same problem again ... you probably want to have a fresh motion object here.
      tmp.motion.pX = width/2;
      tmp.motion.pY = 10;
      tmp.shootPlan = shootPlan; // same problem
      return tmp;
  }
 

i set motion.pX / pY to just have the object reappear on screen.

now, with the new copy function inside enemie class, you can do:

Code:

  void newEnemie(int A, float B)
  {
    for (int i = 0; i < enemies.length; i++)
    {
      if (enemies[i] == null)
      {
        enemies[i] = eStored[A].copy();  // YAY!
        enemies[i].motion.pX = B;
        break;
      }
    }
  }
 

i think you get the idea. can't really tell which parts of enemie need to be copied and which you want to start fresh with ...

game looks nice. i like that your graphics consist of simple shapes to build complex bodies.

F

see .. little bit of code, lot's of replies. what a nice place our discourse is ..

F

yeah great indeed. but i see i dont have an easy way to go thru this problem.

to what st33d said, i can only say no. i dont have a good way to see what are the conditions of each created enemie, because i dont create them from a list. at least not on the conventional way.

i use the "shots" verry much.
http://www.deci.blindado.net/loliness/
see on DOCS the... kind of documentation i made about the shots. its basicly a particle system, that have the uses that i want. the shot_mng class just inputs values on the shot class, so the class behaves in determined ways. the good about the shoot_mng class is that already stores the values of the shot we want to make. so if we say "newShot(...... whatever we want it to do and so on" we can have the same shooting everytime we say "shoot".

that way i can easly have the same movement for many enemies of same kind, i would only have to say "getShot"...
well actualy that can be a good way to do it.

however a problem maintains. the whole enemie drawing, the enemie shooting plan, and the enemie creation itself is RANDOM. compleatly from its core.

i create a new enemie (that make enemie) and the reason why i make new motion and whatever objects, is because they create themselfs in a random way.

for example, the drawing. you probably cant see it right because of the grey colors i've used on the enemies, but when you start a new enemie_draw object, the object itself creates a random drawing. if you start the applet a few times, you'll notice the enemies are never the same, and hardly similar. you can start the applet as many times as you want, you will always have diferent enemie drawing.

now even worst is the enemie shooting plan. it is again also diferent every time. every time you enitialize a new shooting plan, you just have to say it where the shooting points are positioned. you can see that the class constructor gets an array with the position of the shots, and an array of simple 0s and 1s. that is determined on the enemie's drawing class, when that one is made, it determines the postion of the shooting points, and how many diferent kinds of shooting plans we want for the groups of shooting points that i have. that ia made on the enemie drawing class, because that is where the points of the drawing are, and it determines the shooting points positions depending on the points of the drawing. the 0s and the 1s are only to say when "make a new plan" and "aplly the plan you alrady have". what that plan making class does is call the "newShot(..... whatever you want the shots to do" into each shooting point, depending on 0 it will only call on the plan existed, on 1 makes a new plan and applys. finaly the update calls the "shoot(NOW)" whenever the plan decides to.

this is all generated with randoms, wich are the carnI, carnF, carnB on the first file.

so, each object is verry VERRY unique :\
they all make diferent things to the enemie. i could easly make a new random enemie everytime i wanted a new enemie. thats what i had before. if you erase what's inside the newEnemie() function of the enemie_mng class, and copy this there:

for (int i = 0; i < enemies.length; i++)
   {
     if (enemies[i] == null)
     {
       getMove();
       tempDraw = new enemie_draw(carnI(255), carnI(255));
       tempPlan = new enemie_shots(tempDraw.getShootPs(), tempDraw.getPlan());
   
       enemies[i] = new enemie(tempDraw, tempMove, tempPlan, tempDraw.maximus);
       break;
     }
   }

you will get a compleatly new random enemie ever 10 or 20 frames. i dont want so much random. i want 9 random enemies, and i want to call them every time i want :\, thank you for the hel but thats not exactly what i have here.

as for the rest of the comments, i have the same problem, i would have to do a copy class for each object :\
i guess that's the only way. but still i cant stubornly think that there should be a better way to do it. those java  pages i found explain exactly my problem and they probably tell how i could solve it. if i knew how to implement their code, and if i understood what they say on the page.

i'll try to wait a bit more for diferent opinions and guesses, but otherwize, i'll just make the copy function inside every class, wich will b a major pain XD but its cool

thanks everyone for the wonderfull help, its good to see that people are actualy interested in help and discuss the problems.