My solution is giving startColor to the smoke before the editor create it.
Here’s my code:
if (timesHit >= maxHits){
breakableCount--;
levelManager.BrickDestroyed();
smoke.GetComponent<ParticleSystem>().startColor = this.GetComponent<SpriteRenderer>().color;
Instantiate(smoke, transform.position, Quaternion.identity);
Destroy(this.gameObject);
}
It works great.
Is there any problem if I code this way? Thank you in advance.
Hello Tuan,
Something you may want to consider is destroying the actual smoke game objects also.
If you run your game you will notice that as the smoke game objects are created for each destroyed brick, they remain in the hierarchy long after the particle effects have finished.
The Destroy() method can take a parameter for the period of time before the game object is destroyed. By default, this is set to 0f, as such, game objects are destroyed straight away.
What you could do is call the Destroy() method, passing in the smoke game object, and using the particle effect’s duration as the period of time before the smoke game object is destroyed.
As you will have several lines of code which are all related to the smoke game object, if it were me I would probably also refactor this so that it was either in its own distinctive method, or perhaps better still, have it’s own class which you then access/call from within your code above.
I hope this is of use 
See also;
That’s right, Rob. I will have to destroy smoke game objects remaining in the hierarchy. However, I think Ben forgot to destroy it too. ( I tested the project downloaded from lesson 98).
But what I mean here is compare 2 method (I don’t know should I call it method or function):
mind:
Void createSmoke () {
smoke.GetComponent().startColor = this.GetComponent().color;
Instantiate(smoke, transform.position, Quaternion.identity);
}
and
void PuffSmoke () {
GameObject smokePuff = Instantiate (smoke, transform.position, Quaternion.identity) as GameObject;
smokePuff.GetComponent().startColor = gameObject.GetComponent().color;
}
the second one is seem more complicated for me. Because the computer needs to spend more memory every time GameObject smokePuff is created.
Hi Tuan,
In both case the Instantiate() method is going to return a new copy of the original object. I believe in the case of the PuffSmoke() method, the smokePuff variable will become a pointer on the stack to the same newly created object on the heap.
So I don’t believe there is really any difference internally.
One approach which may make a difference, albeit somewhat small depending on the number of bricks and the device in question, to the use of memory here would be to not keep instantiating and destroying the game objects actually. Instead, create a pool of instantiated smoke objects and then re-use them.
Depending on your game you would need to give some consideration to the size of the pool, for example, the number of required smoke objects may depend on the speed of the ball, the number of hits required per brick and whether or not you have added any form of power-ups which allow for the bricks to be destroyed more easily.
A slow moving ball, even with a more rapid ricochet perhaps near the top/side of the screen may only require a small pool. Once each smoke object has completed its particle effect run, it could be set as inactive and then reset the next time it is required.
A fast moving ball, destroying bricks rapidly would potentially need a greater sized pool as you would have more smoke objects in play at the same time.
If you have 200 bricks on the level, with either of the above approaches, 200 smoke objects will be instantiated and destroyed. I would imagine, unless you have a “nuke” type power-up, you would never have more than half of these bricks being destroyed in the scene at any one time, probably not even a quarter. So the size of the pool could be set to 25% of the number of bricks for example. 75% saving on over head of instantiating/destroying - allocating/de-allocating memory.
Just something to consider