Posts by JJokelainen

    Sorry for the delayed response, I was having hard time finding time to study the Time- class.

    The fact that deltaTime returns the correct delta in FixedUpdate too was news to me, I did test it and it does infact return fixedDeltaTime in moderate load.

    I did a mistake too in my response.

    Even if you adjust fixedDeltaTime the objects speed will remain relative to the scaled 'UnityTime', that is the reason you multiply with delta in the firstplace ^^

    It actually is very important to adjust fixedDeltaTime with timeScale because unlike Update which will remain roughly at Application.targetFrameRate independent of timeScale, FixedUpdate (and apparently physics + other fixed framerate updates) takes its framerate from fixedDeltaTime thus is affected in actual calls in real time.

    This means the when you increase timeScale, FixedUpdate will be called more often resulting in increased CPU load and when timeScale is lowered you will suffer from decreased accuracy in physics.

    1. Time.fixedDeltaTime = 0.02f * Time.timeScale;

    This will keep the fixed framerate at 50fps in realtime and will also result in fixedDeltaTime = 0 when timeScale = 0

    As I was studying the Time- class I made a small chart of some of the properties, Id like to share this with you:

    RealTime UnityTime Definition
    unscaledTime time Time from start of the game to the start of current frame
    fixedUnscaledTime fixedTime Time from start of the game to the start of current physics frame
    unscaledDeltaTime deltaTime The completion time in seconds since the last frame (Read Only).
    fixedUnscaledDeltaTime fixedDeltaTime The interval in seconds at which physics and other fixed frame rate updates (like MonoBehaviour's FixedUpdate) are performed.

    I also made a test project(realy quick & dirty) to verify assumptions, I'll share the video but unfortunately I don't have time to go in to any details, youll have to figure it out or ask and I'll answer :)

    Edit: Forgot to mention/ask.

    In my testproject the Cubes are moved with transform.Translate. Called from Update the Cube moves at different speed compared to FixedUpdate.

    What is the cause of this? Rounding thing/something with floatingpoints? Is it something to do with when the actual Translate- methdod gets excecuted?

    Thank you for your response.

    I must admit I don't realy understand the suggestion to update fixedDeltaTime with timeScale.

    The example in the doc after said recomdation adjusts the fixedDeltaTime

    1. Time.fixedDeltaTime = 0.02f * Time.timeScale;

    This will in my understanding set the fixedDeltaTime to equivalent of 0.02f/sec which is the default with timeScale of 1f;

    Adjusting will revert any slowmotion attempts since I move my objects in FixedUpdate with speed*fixedDeltaTime

    Also setting timeScale to ero will stop calls to FixedUpdate too thus "pausing"

    Any insights on this?


    I have a minigameproject where I have tried to avoid the use of "managers", just components manipulating and reading shared assets(scriptable objects)

    I was wondering If checking for pauseState with

    1. private void Update()
    2. {
    3. if(Time.timeScale>0) //Not paused
    4. {
    5.         }
    6.     }

    would be viable solution?

    I did have a gamedata SO that held the pauseState but as I refined the codebase, it was the only field left.

    Any thoughts on this?


    My approach in the example is to attach an AudioSource to the gameobject and use it to play the sounds.

    What plans do you have for the AudioSource field in your Sound- class?

    I think FindObjectOfType<AudioArrayScrObj>(); will return null since scriptable objects are not an active instances in the scene, they are assets. In my example I have assigned the created scriptable object thru inspector.

    So when you have created an AudioArrayScrObj- asset and assigned it some clips you can reference your asset by setting a reference thru inspector. Accessing the containing data is like with any other class.


    I'm a bit busy so I can't go very deep in to your problem but one thing for you to note is that when ever you call MoveEnemy()( you are Adding to your Lists, the old data is never removed. Quick way to overcome would be to clear the lists before sorting at MoveEnemy. Other and IMHO a better way would be to move only the gameobject to correct list that is moved to your specified areas and remove it from the old list.

    OnCollisionEnter2D has a Collision2D type parameter and

    OnTriggerEnter2D has a Collider2D type parameter

    Collision2D does not inherit from anything and does not have GetComponent implemented, it only contains collision data.

    Collider2D inherits from Behaviour and Behaviour inherits from Component, this is where GetComponent is coming from.

    Pretty similar naming :)

    It seems like something has changed since I took the course.

    The background shader looks different and you dont seem to have the background named SpaceBG_Overlay

    The overlay contains those galaxies on the cornesrs and edges. Although the area you have problems with seems a lot like the right side of the overlay.

    This is in the Background layer.

    Can you post some screenshots of your hierarchy and inspectors for game objects?

    Happens to all of us :)

    From my experience many times 'assuming' is the culprit when dealing with a hard to solve puzzle or new concepts.

    If there are assumptions involved, you are not working on a solid ground and so problems arise.

    To overcome one must check/recheck the 'facts' and realy try to understand what is going on.

    I think that is what you are doing pretty well

    It was only an example.

    Simply think of the transform.Translate as a way to move the object to the direction you need and by the distance you need, no need to know the current position.

    1. transform.Translate(new Vector3(0,5,0) * time.deltaTime);

    This moves the object zero distance in the x-axis, 5-units on the y-axis and zero on the z-axis.

    When multiplied by time.deltaTime and used in Update the object will move 5- units on y per second

    The smoothing effect and funky behaviour comes from you using the current position of the object for the translation.

    transform.Translate moves the object to the direction of the input and the length of the input so lets say you are positioned at 1,1,1 on x,y,z

    if you use something like

    1. transform.Translate(new Vector3(transform.position.x, transform.position.y + speed, 0) * time.deltaTime);

    you are actually telling the object to move 1- unit on the x, 6 -units on y and 0 on z per second.

    This will change when the object moves

    Instead if you want the object to move 5- units per second on the y you could do something like

    1. transform.Translate(new Vector3(0, speed * time.deltaTime, 0));
    2. //or
    3. transform.Translate(Vector3.up * speed * time.deltaTime);

    This will always mean move 0 on x, speed on y and 0 on z / sec

    Oh snap, I don't know how I missed this! I do my physics stuff in FIxedUpdate ofcoarse :) Thanks for your reply, my experience with extension methods extend only to some tutorials so things like naming are still taking form for me.


    I'm creating a 2D game with kinematic rigidbodies to move around.

    Since Rigidbody2D has a MovePosition but no Translate I'm thinking of using an extension for moving my player:

    1. public static class Utility
    2. {
    3. public static void Rigidbody2dTranslate(this Rigidbody2D rigidBody, Vector2 translation)
    4. {
    5. rigidBody.MovePosition(rigidBody.position + translation);
    6. }
    7. }

    And to use:

    1. rigidbodyToMove.Rigidbody2dTranslate(Vector2.right * speed * Time.deltaTime);

    Any experiences or thoughts on this?

    Performance penalty since used in update?