with Start it sets a local, private, startTime variable with the current time. It then uses this against real time to figure out its algorithmic movements.
This causes, for example, a line of enemies using Sin/Cos to, instead of moving all together, move in what would appear to be a snake-like movement (due to each starting from 0 due to this time change, instead of starting at whatever the Time currently is).
This also means enemy movements when entering the screen are consistent, regardless of when they enter the screen.
I implemented a hack to the Enemy script for the "on screen enable" stuff to test this, though that is not part of this PR.
61
Note: This is done in Start instead of OnEnable as mentioned in #61. Apparently component.enabled = true causes both OnEnable AND Start to be called. Due to this there is no reason not to just put that in Start (I previously expected Start to be called only on instantiation, with OnEnable reacting to component.enabled = true).
with Start it sets a local, private, startTime variable with the current time. It then uses this against real time to figure out its algorithmic movements.
This causes, for example, a line of enemies using Sin/Cos to, instead of moving all together, move in what would appear to be a snake-like movement (due to each starting from 0 due to this time change, instead of starting at whatever the Time currently is).
This also means enemy movements when entering the screen are consistent, regardless of when they enter the screen.
I implemented a hack to the Enemy script for the "on screen enable" stuff to test this, though that is not part of this PR.
61
Note: This is done in Start instead of OnEnable as mentioned in #61. Apparently component.enabled = true causes both OnEnable AND Start to be called. Due to this there is no reason not to just put that in Start (I previously expected Start to be called only on instantiation, with OnEnable reacting to component.enabled = true).