…be my guest 
Although I think there would be some differences.
Not sure about the coroutine but I think the destroy method using a time limit would continue to run and destroy the particles whilst the game was paused.
Hi everyone, thanks for the replies and suggestions! As expected, you’re suggesting things that weren’t taught yet in the course.
My one original question that is still unanswered - is there any advantage or reason to actually do this? I feel like there is but I’d like to know from people who are more experienced at this than I am :).
I’ll be trying to implement this later.
2 Likes
There is, performance wise and sometimes there is a chance that if you don’t destroy an object that was not supposed to be there anymore, you could experience some strange behaviors and errors (not in this case since it is a simple game).
@Rob, just tried it:
void Start()
{
Destroy (gameObject, 3f);
}
void Pause()
{
if (isPaused == false)
{
Time.timeScale = 0;
isPaused = true;
}
else
{
Time.timeScale = 1;
isPaused = false;
}
}
void Update ()
{
// Pressing Space to start the test
if (Input.GetKeyDown(KeyCode.Space))
{
Pause();
}
}
The pause function does stop the destroy timer, seems that anything that uses times as parameter stops counting if we set Time.timescale = 0, but I don’t know, I’ve seen just a few unity methods, perhaps there are some that gets the time value from elsewhere
Clearing up after yourself is deemed as good practice and not doing so can/will have potential costs on performance.
In this case, and remembering that this is fairly early on in the course, all of these items get destroyed when the next scene loads, so perhaps not really that big a deal - only a keen eye would spot that they aren’t - well done 
You could argue that there could be a benefit in destroying them off immediately (as above), or, that adding code which is checked every frame to see if they should be killed off is more costly.
Either case could be true and as such, in this specific case, the only real way to be certain of the best approach for your game would be to start using the profiler to see whats going on behind the scenes.
Regardless of performance however I would offer that it is far better to always consider the tidying up after yourself approach, even if you add a // ToDo: comment reminding yourself to come back and see if it costs you anything by doing so. Not doing so is a little lazy and could lead to performance and other issues depending on the game/app/device/circumstance.
My experience with the housekeeping comes from system development. The number of times I have seen people create database connections and not tidy up after themselves which has had undesirable effects is countless.
As above, for this specific situation, you could start looking at profiling and seeing whats going on. Your tests with the different approaches would need to be the same/fair in order for a suitable comparison.
Update
Just went through and edited all my spelling mistakes, sorry, I was using my phone the first time round, whilst cooking my son’s dinner! 
1 Like
Hi Johnny, so that’s a good thing to know - what about if the timescale isn’t actually set to zero, and thus paused, but merely put into slow motion…
Consider a scenario where in a flashy version of Block Breaker, upon smashing a specific block, the camera zooms in an replays the destruction of the block which in turns creates a spectacular visual display of sorts - this is all done in slow-mo to add to the effect before whizzing back to normal game speed after the replay… anything peculiar happen then?
I note that there was a method previously on the ParticleSystem for destroying the object once it was finished, it has been removed in more recent versions, I wonder whether there is a scenario in which killing it off based on time was having an adverse effect, so it was removed - can’t think why else what appears to be useful functionality would be removed.
1 Like
Same behavior @Rob, I updated the Project with the testing I’ve done, it is the same project that I used to test the Efficienty on setting transform position, so you can experiment with both if you want.
There are two scripts, the DestroyCounter (which is the active) has two public variables, Destroytimer to set how many seconds before destroying the gameObject and Time Divider to set the number that will divide the timescale, when you enter in the play mode there will be a counter displaying how many seconds until the gameObject gets destroyed, and if you press space it will active the timescale modifier and will allow us to see in real time through the counter being displayed. It is working like a charm =)
code:
[code]using UnityEngine;
using System.Collections;
using UnityEngine.UI;
public class DestroyCounter : MonoBehaviour {
bool isPaused;
public float Destroytimer;
float Counter;
public float TimeDivider;
public Text NumberDisplayer;
void Start()
{
Destroy (gameObject, Destroytimer);
}
void SlowEffect()
{
if (isPaused == false)
{
Time.timeScale /= TimeDivider;
isPaused = true;
}
else
{
Time.timeScale *= TimeDivider;
isPaused = false;
}
}
void Update ()
{
// Pressing Space to start the test
if (Input.GetKeyDown(KeyCode.Space))
{
SlowEffect();
}
Counter = Destroytimer - Time.time;
NumberDisplayer.text = Counter.ToString("0.00");
}
}[/code]
If you want to test the transform position efficiency, just activate the other script and deactivate the DestroyCounter, I used space to control both (recycling code 
) on the same gameObject (named as box).
let me know your thoughts
I don’t know, but I’m sure that there are situations that tweaking the timescale and making methods that are time dependant will cause some problems, but probably will cause problems to animations and etc too, regarding the replay feature, seems to be interesting, I don’t have a clue into how to do such a feature but I’ll surely look for it in the future!
Did you attach this script to the partical effects?
This was a test that I have done, I made another project just to test how timescale(pause and slowmotion effect) effects the destroy method, there is a copy of the project in the link I have posted above
I just tried this code, but it just disabled the smoke entirely…
you can disable it by adding a script to start with:
[code]
void Start()
{
Destroy(gameObject,time) // choose the time in seconds
}[/code]
ok after much tweaking I seem to have made it work, but my code ended up looking like this:
void Start () {
DestroyObject(gameObject, 2f); // choose the time in seconds
}
1 Like
is there an easier way than using two scripts?
You dont have to use two scripts, just this last one above, the other script was a test that I was doing to check if the timescale affects the destroy timer
kk, just seen what issue I’ve been having. Hmm…this will be interesting to try out.
1 Like
It is a fun mechanic indeed
Going to finish building the main game and then have an attempt at a few other ideas to alter the game in interesting ways.
2 Likes
This, but I prefer to read the time from the duration of the particle system:
// Use this for initialization
void Start () {
Destroy(gameObject, gameObject.GetComponent<ParticleSystem>().duration);
}
3 Likes
very nice. I had no idea you could set a duration value there.