Wow, nice solutions lennaert. Thanks.
My great problem right now is how store this object states to return then later.
To static objects (like buildings) it is easy. But to NPCs, that will be running through the map, it will be more difficult. In that cases, i can left the objects running and only destroy the sprites and effects. But I dont have experience in C2 to judge if this will worth the effort.
I'm trying to avoid that annoying thing - normal in 8/16bit games - when you run back for something that you just pass by and it no more exists.
But thanks for sharing your exp.
:)
I overcome the problem with instance variable from objects which get created and destroyed ... smart implementation of game mechanics.
If my object is dependanton a certain value, and it woulld be just 1 object, then I could either stuff the data in a var, or even an array ... but if you have to do this for all enemies .... it becomes a pain ...
So ... what I did, is make sure each enemy doesnt have references that need to carry over some create -> destroy -> create
Image something like an enemy picked something up ... and needs to have it after a new created ... I simply did not implement such a method, as its too much hassle.
Like with enemy health, if an enemy gets destroyed and recreated, it gets its health back after a new create ... i just envision that as being logical, you shouldnt have run away lol
for objects that need to be there when I return later, I simply do not remove them. If they have some dynamic behaviour tied to variables .. then simply only disable the behaviour to save CPU and enable with some method when needed.
A lot of good mechanics comes down to applying a minimilistic KISS appraoch.
If you have something thats really important to have it remember state, and destroy and comeback, you can always store something in a variable or array and get that data when you need it. I would see this as a workaround, and not apply too many of them.