10.4 ผสาน Physics กับ Gameplay

เรารู้จัก Rigidbody กับ Collider มาแล้ว เห็น Unity ทำให้ object ตกลงมา เด้ง แล้วหยุดชนกับกำแพงได้เอง บทนี้พูดถึงขั้นถัดไป คือการเชื่อม physics simulation นั้นเข้ากับ gameplay จริง ๆ เช่น เก็บเหรียญ โดนความเสียหายจากลาวา โดนแรงระเบิดกระแทกกระเด็น หรือยิง raycast ไปตามทางเดิน โค้ด physics ที่ดูถูกต้องตอนดูแยกส่วน ก็ยังเป็นสาเหตุของบั๊กที่งงที่สุดในโปรเจกต์ Unity ได้อยู่ดี เช่น การเคลื่อนที่กระตุก, เก็บของไม่ติด, ความสูงของการกระโดดขึ้นกับ frame rate เกือบทั้งหมดของปัญหาพวกนี้ย้อนกลับไปที่กฎไม่กี่ข้อที่บทนี้จะพูดถึง

1. เชื่อม Physics Engine เข้ากับ Gameplay Code

Unity มี physics engine (ระบบแยกต่างหากที่จำลอง rigid body, แรงโน้มถ่วง, และการชนกัน — engine 3D ตัว default ของ Unity ชื่อ PhysX) รันอยู่ข้างใต้สคริปต์ของเราตลอดเวลา มันมีนาฬิกาและ loop ของตัวเอง แยกจาก game code ส่วนที่เหลือโดยสิ้นเชิง หน้าที่ของเราไม่ใช่คำนวณ physics เอง แต่คือการคุยกับ physics engine ให้เรียบร้อย บอกมันว่าเราต้องการอะไร (แรง, ตำแหน่งเป้าหมาย) แล้วฟังสิ่งที่มันรายงานกลับมา (การชน, การซ้อนทับ, ตำแหน่งใหม่)

มี component สองตัวที่ทำให้ GameObject อยู่ภายใต้การควบคุมของ physics engine

• Rigidbody — ทำเครื่องหมายว่า object นี้เป็นสิ่งที่ physics engine ควรจำลอง (แรงโน้มถ่วง โมเมนตัม และการชนใช้กับมันได้ทั้งหมด)
• Collider — กำหนดรูปทรงที่ physics engine ใช้เช็คการสัมผัส (กล่อง ทรงกลม แคปซูล หรือ mesh แยกต่างหากจากหน้าตาที่มองเห็นของ object)

Rigidbody มีได้สามแบบ และการสับสนระหว่างสามแบบนี้เป็นสาเหตุความงงที่พบบ่อย

• Dynamic (ค่า default) — ถูกจำลองเต็มรูปแบบ แรงโน้มถ่วงดึงลง แรงผลักได้ การชนทำให้เด้ง เราส่งผลต่อมันด้วยแรงกับความเร็ว ไม่ใช่ตั้งค่า transform.position ตรง ๆ
• Kinematic (isKinematic = true) — ไม่สนใจแรงและแรงโน้มถ่วงเลย เราขยับมันเองผ่าน Rigidbody.MovePosition/MoveRotation ส่วนใหญ่ และ physics engine ก็ยังรายงานการชนกับ trigger ให้กับมันอยู่ เหมาะกับแพลตฟอร์มที่เคลื่อนที่หรือประตูที่ควบคุมด้วยสคริปต์
• Static (ไม่มี Rigidbody เลย มีแค่ Collider) — ไม่ขยับเลย เป็นตัวเลือกที่ถูกที่สุดสำหรับกำแพง พื้น และภูมิประเทศ

วิธีคิดที่สะอาดที่สุดเกี่ยวกับความสัมพันธ์นี้คือ gameplay code ส่ง ความตั้งใจ ไปให้ physics engine (แรง, impulse, ตำแหน่งเป้าหมาย) แล้ว physics engine ส่ง ข้อเท็จจริง กลับมา (สิ่งต่าง ๆ ไปจบที่ไหน อะไรสัมผัสกับอะไร) การฝืนกฎนี้ — เขียนทับ transform.position ของ dynamic Rigidbody ตรง ๆ ทุกเฟรม — จะทำให้ simulation พังลง เพราะตอนนี้มีสองระบบที่คิดว่าตัวเองเป็นเจ้าของค่าเดียวกัน

นี่คือความผิดพลาดในรูปแบบโค้ด พร้อมวิธีแก้

public class BadMover : MonoBehaviour
{
    public float speed = 5f;

    // BAD: this object also has a non-kinematic Rigidbody attached.
    // Overwriting transform.position every frame ignores the physics
    // engine completely -- the object can clip straight through walls,
    // and any collision that does happen looks jittery, because the
    // physics engine and this script are fighting over the same value.
    void Update()
    {
        transform.position += Vector3.forward * speed * Time.deltaTime;
    }
}

public class GoodMover : MonoBehaviour
{
    public float speed = 5f;
    private Rigidbody rb;

    void Awake()
    {
        rb = GetComponent<Rigidbody>();
    }

    // GOOD: MovePosition hands the move to the physics engine. It sweeps
    // the body through space between steps, so collisions along the way
    // are still detected correctly, and it belongs in FixedUpdate --
    // more on that split in Section 4.
    void FixedUpdate()
    {
        Vector3 target = rb.position + Vector3.forward * speed * Time.fixedDeltaTime;
        rb.MovePosition(target);
    }
}

ผลลัพธ์ที่คาดหวัง: GoodMover เคลื่อนที่ไปข้างหน้าด้วยความเร็วคงที่ และยังหยุดถูกต้องเมื่อชน collider ของกำแพง เพราะ physics engine เป็นคนทำการเคลื่อนที่เองและตรวจจับกำแพงได้ระหว่างทาง ส่วน BadMover เคลื่อนที่ด้วยความเร็วเดียวกันบนพื้นโล่ง ๆ แต่จะทะลุกำแพงบาง ๆ ไปเลยถ้ามันเคลื่อนที่เร็วพอระหว่างเฟรม เพราะมันไม่เคยขอให้ physics engine ตรวจสอบให้เลย

2. Solid Collider กับ Trigger Collider

Collider ทุกตัวมี checkbox ใน Inspector ชื่อ Is Trigger มันเปลี่ยน collider ของเราให้เป็นคนละแบบกัน

• Solid collider (isTrigger = false ค่า default) — บล็อก collider อื่นทางกายภาพ collider แข็งสองตัวที่สัมผัสกันจะผลักกันออก (หรือหยุดการเคลื่อนที่) และ physics engine เรียก OnCollisionEnter/OnCollisionStay/OnCollisionExit
• Trigger collider (isTrigger = true) — ตรวจจับการซ้อนทับแต่ไม่บล็อกอะไรทางกายภาพเลย object เดินทะลุผ่านมันไปได้เลย และ physics engine เรียก OnTriggerEnter/OnTriggerStay/OnTriggerExit แทน

นี่คือเครื่องมือสำหรับกรณีที่เราคาดเดาได้เลย เช่น เหรียญ ยาเพิ่มเลือด zone ที่ทำความเสียหาย volume ที่มองไม่เห็นแบบ "ผู้เล่นเข้ามาในห้องนี้แล้ว" — ทุกอย่างที่ควร รู้ ว่ามีอะไรสัมผัสมัน โดยไม่ต้องหยุดมันทางกายภาพ

เพื่อให้ collider สองตัวเกิด event อะไรก็ตาม (collision หรือ trigger) อย่างน้อยหนึ่งใน object ทั้งสองต้องมี Rigidbody trigger volume ที่มีแค่ Collider ไม่มี Rigidbody เลย ก็ยังตรวจจับ player ที่มี Rigidbody เดินเข้ามาได้ ในทางกลับกันก็ทำงานเช่นกัน collider เปล่า ๆ สองตัวที่ไม่มี Rigidbody เลยจะไม่ส่ง event หากันเลย เพราะ physics engine ไม่เสียเวลาเช็คคู่ static-กับ-static สำหรับ event เนื่องจากทั้งคู่ขยับไม่ได้อยู่แล้ว

ตอนไหนควรใช้ solid collider: กำแพง พื้น ตัวละคร ลัง — อะไรก็ตามที่ควรหยุดหรือผลัก object อื่นทางกายภาพ ตอนไหนควรใช้ trigger: pickup, damage zone, checkpoint, volume เปลี่ยนด่าน, sensor แบบ "player อยู่ใกล้สิ่งนี้ไหม" — อะไรก็ตามที่ควรแค่ รู้ ไม่ใช่บล็อก

3. ตรวจจับการซ้อนทับ: OnTriggerEnter กับ OnTriggerExit

Unity เรียก method สามตัวบน MonoBehaviour ที่แนบอยู่กับ trigger collider (หรือ collider อีกฝั่งที่เกี่ยวข้อง) ให้เองอัตโนมัติ ทุกครั้งที่การซ้อนทับเริ่ม ดำเนินต่อ หรือจบลง

• OnTriggerEnter(Collider other) — ทำงานครั้งเดียว ในเฟรมที่ collider ทั้งสองเริ่มซ้อนทับ
• OnTriggerStay(Collider other) — ทำงานทุก physics step ขณะที่ยังซ้อนทับกันอยู่
• OnTriggerExit(Collider other) — ทำงานครั้งเดียว ในเฟรมที่พวกมันหยุดซ้อนทับกัน

pickup ต้องการแค่ OnTriggerEnter

using UnityEngine;

public class CoinPickup : MonoBehaviour
{
    public int value = 10;

    void OnTriggerEnter(Collider other)
    {
        if (other.TryGetComponent(out PlayerScore score))
        {
            score.Add(value);
            Debug.Log("Coin collected, +" + value);
            Destroy(gameObject);
        }
    }
}

ผลลัพธ์ที่คาดหวัง: ทันทีที่ collider ของ player สัมผัส trigger collider ของเหรียญ console จะพิมพ์ Coin collected, +10 แล้วเหรียญก็หายไป ถ้ามีอะไรที่ไม่มี component PlayerScore มาโดน trigger แทน (เช่น enemy หลงเข้ามา) จะไม่มีอะไรเกิดขึ้น เพราะเช็ค TryGetComponent จะข้ามไปเฉย ๆ

damage zone ต้องการการตรวจจับต่อเนื่อง เลยใช้ OnTriggerStay แทน

using UnityEngine;

public class LavaPit : MonoBehaviour
{
    public float damagePerSecond = 10f;

    void OnTriggerStay(Collider other)
    {
        if (other.TryGetComponent(out Health health))
        {
            // OnTriggerStay fires once per physics step, so scale the
            // damage by the fixed step's length to get a steady
            // per-second rate no matter how often the step runs.
            float damageThisStep = damagePerSecond * Time.fixedDeltaTime;
            health.TakeDamage(damageThisStep);
        }
    }

    void OnTriggerExit(Collider other)
    {
        if (other.TryGetComponent(out Health health))
        {
            Debug.Log(other.name + " left the lava");
        }
    }
}

ผลลัพธ์ที่คาดหวัง: ขณะที่ player ยืนอยู่ในลาวา Health.TakeDamage จะถูกเรียกทุก physics step ด้วยจำนวนเล็กน้อย รวมกันแล้วเท่ากับ damagePerSecond hit point ที่เสียไปต่อวินาทีจริง พอ player ก้าวออกมา OnTriggerExit จะพิมพ์ Player left the lava ครั้งเดียว แล้วความเสียหายต่อเนื่องก็หยุด

4. การแบ่ง FixedUpdate / Update

game loop ของ Unity เรียก method แบบ "ทำงานหนึ่งครั้งต่อ X" สองแบบที่ต่างกันมาก และการสับสนระหว่างสองแบบนี้เป็นบั๊ก physics ที่มือใหม่เขียนกันบ่อยที่สุดอย่างหนึ่ง

• Update() — ทำงานครั้งเดียวต่อ เฟรมที่ render ความถี่ขึ้นอยู่กับ frame rate ซึ่งเปลี่ยนแปลงตลอดเวลา (ฉากที่งานหนักอาจตกลงมาที่ 30 fps ฉากว่าง ๆ อาจขึ้นไปถึง 300 fps)
• FixedUpdate() — ทำงานที่ อัตราคงที่ กำหนดโดย Time.fixedDeltaTime (0.02 วินาที หรือ 50 ครั้งต่อวินาที เป็นค่า default — เปลี่ยนได้ใน Project Settings > Time) อัตรานี้ไม่เปลี่ยนตาม frame rate เลย physics engine เดินหน้าเป็น step ขนาดคงที่แบบนี้เท่านั้น

กฎที่ตามมาจากตรงนี้คือ อ่าน input ใน Update (frame rate ที่เร็วไม่ควรทำให้เรากดปุ่มไม่ทันเลย Input.GetKeyDown ถูกออกแบบให้เช็คครั้งเดียวต่อเฟรมที่ render) และ ใส่แรง, impulse, หรือเปลี่ยนความเร็วใน FixedUpdate (เพื่อให้ physics engine ได้รับค่าที่เราตั้งใจเป๊ะ ๆ ครั้งเดียวต่อ physics step เสมอ ไม่ว่า frame rate จะเท่าไหร่)

นี่คือบั๊กในรูปแบบที่พบบ่อยที่สุด — thruster ที่ดันยานไปข้างหน้าขณะกดปุ่มค้าง

public class BuggyThruster : MonoBehaviour
{
    public Rigidbody rb;
    public float thrust = 20f;

    // BUG: AddForce is called once per Update -- once per RENDERED
    // frame. At 240 fps, Update runs about 5 times for every single
    // FixedUpdate (at the default 50 Hz). That means roughly 5 times
    // as much force gets queued up per physics step as at 48 fps,
    // where Update barely keeps up with FixedUpdate. Thrust ends up
    // depending on the player's frame rate, not on the thrust value.
    void Update()
    {
        if (Input.GetKey(KeyCode.W))
        {
            rb.AddForce(transform.forward * thrust, ForceMode.Force);
        }
    }
}

public class FixedThruster : MonoBehaviour
{
    public Rigidbody rb;
    public float thrust = 20f;
    private bool thrusting;

    // Only READ input here. Polling once per rendered frame is exactly
    // right for input -- it is cheap, and GetKey/GetKeyDown are built
    // to be checked this often.
    void Update()
    {
        thrusting = Input.GetKey(KeyCode.W);
    }

    // Only APPLY physics here. This runs at a fixed rate, so the force
    // added per physics step is now the same no matter how fast the
    // game is rendering.
    void FixedUpdate()
    {
        if (thrusting)
        {
            rb.AddForce(transform.forward * thrust, ForceMode.Force);
        }
    }
}

ผลลัพธ์ที่คาดหวัง: FixedThruster ไปถึงความเร็วสูงสุดเท่ากันหลังจากเวลาจริงจำนวนวินาทีเท่ากัน ไม่ว่าเกมจะรันที่ 30 fps หรือ 300 fps ส่วน BuggyThruster เร่งความเร็วเร็วกว่าเห็นชัด ๆ บนเครื่องแรงเทียบกับเครื่องช้า ทั้งที่รันสคริปต์เดียวกันเป๊ะ

5. Layer-Based Collision Matrix

GameObject ทุกตัวมี layer (หมวดหมู่ที่มีหมายเลข สูงสุด 32 อัน ตั้งชื่อได้ใน Project Settings > Tags and Layers — เช่น Player, Enemy, EnemyBullet, Scenery) layer เฉย ๆ ไม่ทำอะไรด้วยตัวมันเอง แต่มีสองระบบที่อ่านมัน คือ rendering (กล้องไหนเห็น layer ไหน) กับ physics

Project Settings > Physics > Layer Collision Matrix คือตาราง checkbox ขนาดใหญ่ หนึ่งแถวหนึ่งคอลัมน์ต่อ layer ช่องที่ติ๊กไว้แปลว่า collider บนสอง layer นั้นได้รับอนุญาตให้เกิด collision หรือ trigger event กันได้ ช่องที่ไม่ติ๊กแปลว่า physics engine ข้ามการเช็คคู่นั้นไปเลย ไม่ใช่แค่เพิกเฉยผลลัพธ์ แต่ไม่ทำงานเช็คตั้งแต่แรก

การตั้งค่านี้ครั้งเดียวใน Project Settings มักเป็นทางเลือกที่ถูกต้อง เพราะมันเป็นกฎระดับทั้งโปรเจกต์ที่ตั้งครั้งเดียวจบ มีเครื่องมือเพิ่มอีกสองตัวช่วยจากในโค้ด

using UnityEngine;

public class SetupLayers : MonoBehaviour
{
    void Awake()
    {
        // Same effect as unchecking a box in the matrix, done at runtime.
        int enemyLayer = LayerMask.NameToLayer("Enemy");
        int enemyBulletLayer = LayerMask.NameToLayer("EnemyBullet");
        Physics.IgnoreLayerCollision(enemyLayer, enemyBulletLayer, true);

        // Assigning a layer to a spawned object, in code.
        gameObject.layer = LayerMask.NameToLayer("EnemyBullet");
    }
}

ตอนไหนควรใช้: เมื่อไหร่ก็ตามที่ object สองประเภทไม่ควรมีปฏิสัมพันธ์ทางกายภาพกัน หรือไม่ควรถูกเช็ค event เลยด้วยซ้ำ — ปิด friendly fire, ให้กระสุนไม่โดนคนยิงเอง, ผีเดินทะลุกำแพงได้, layer แบบ "ใช้ตรวจจับอย่างเดียว" ที่ใช้กับ raycast ล้วน ๆ สิ่งนี้ยังลดภาระงานของ physics engine โดยตรงด้วย (Section 12 จะย้อนกลับมาพูดเรื่องนี้) เพราะคู่ที่ถูกเพิกเฉยจะไม่ถูกเช็คเลยด้วยซ้ำ

6. ใส่แรง: AddForce กับ Force Mode

Rigidbody.AddForce(Vector3 force, ForceMode mode) คือเครื่องมือหลักสำหรับผลัก dynamic Rigidbody argument ตัวที่สอง ForceMode เปลี่ยนความหมายของตัวเลขที่เราใส่ การสับสนระหว่างโหมดเหล่านี้เป็นสาเหตุของความงงแบบ "ทำไมแรงของฉันอ่อนไปหรือแรงเกินไป" ที่พบบ่อย

"ใช้ mass" แปลว่า Rigidbody ที่หนักกว่า (rb.mass สูงกว่า) ต้องการแรงมากกว่าเพื่อขยับในระยะเท่ากัน ตรงกับสามัญสำนึกในโลกจริง (ผลักเบา ๆ แทบไม่ทำให้รถบรรทุกขยับ แต่ทำให้รถเข็นซูเปอร์มาร์เก็ตปลิวไปเลย) "ไม่สนใจ mass" แปลว่าทุก object ได้ความเร่งหรือการเปลี่ยนความเร็วเท่ากันเป๊ะ มีประโยชน์เมื่อเราต้องการ game feel ที่คาดเดาได้และปรับแต่งง่าย มากกว่าความสมจริงทางฟิสิกส์

thruster แบบต่อเนื่องใช้ ForceMode.Force ใส่ทุก FixedUpdate ขณะที่กำลังทำงาน (pattern เดียวกับใน Section 4)

void FixedUpdate()
{
    if (thrusting)
    {
        rb.AddForce(transform.forward * thrust, ForceMode.Force);
    }
}

ผลลัพธ์ที่คาดหวัง: ยานเร่งความเร็วขึ้นอย่างนุ่มนวล ความเร็วเพิ่มขึ้นตามระยะเวลาที่ thrusting เป็นจริง และยานที่หนักกว่า (rb.mass สูงขึ้น) จะเร่งความเร็วช้ากว่าภายใต้ค่า thrust เดียวกันเป๊ะ เพราะ ForceMode.Force สนใจ mass — เหมือนเครื่องยนต์จรวดจริง ๆ บนจรวดที่หนักกว่า

7. Raycast กับ Overlap Query: การยิงและการตรวจจับ

ไม่ใช่ทุกคำถามด้าน physics ที่ต้องการ Rigidbody เคลื่อนที่ผ่านโลกเกม บางครั้งเราแค่อยากถาม physics engine เดี๋ยวนี้เลยว่า "มีอะไรอยู่ตรงหน้าปืนกระบอกนี้" หรือ "มีอะไรอยู่ใกล้การระเบิดนี้บ้าง" คำถามแบบครั้งเดียวจบพวกนี้เรียกว่า query และมันอ่านสถานะปัจจุบันของ collider ทุกตัวในฉากโดยไม่จำลองอะไรเลย

raycast (ยิงเส้นตรงบาง ๆ ที่มองไม่เห็นผ่านฉาก แล้วถามว่ามันโดนอะไรก่อน) เป็นวิธีมาตรฐานสำหรับทำ hitscan shooting — ปืนที่ยิงโดนทันที ไม่มีเวลาเดินทางของกระสุนให้เห็น

using UnityEngine;

public class Gun : MonoBehaviour
{
    public float range = 100f;
    public int damage = 25;
    public LayerMask hittableLayers; // set in the Inspector: Enemy + Scenery

    public void Fire()
    {
        Ray ray = new Ray(transform.position, transform.forward);

        // Physics.Raycast returns true the instant it finds something,
        // and fills "hit" with details -- what it hit, where, how far.
        if (Physics.Raycast(ray, out RaycastHit hit, range, hittableLayers))
        {
            Debug.Log("Hit " + hit.collider.name + " at distance " + hit.distance);

            if (hit.collider.TryGetComponent(out Health targetHealth))
            {
                targetHealth.TakeDamage(damage);
            }
        }
        else
        {
            Debug.Log("Shot missed everything");
        }
    }
}

ผลลัพธ์ที่คาดหวัง: เล็งไปที่ enemy ที่อยู่ห่างออกไป 12 หน่วยแล้วเรียก Fire() จะพิมพ์ Hit Enemy at distance 12 และลดเลือดของ enemy ตัวนั้นลง 25 เล็งไปที่ท้องฟ้าโล่ง ๆ จะพิมพ์ Shot missed everything การส่ง hittableLayers (ที่ไม่รวม layer Player) แปลว่า raycast ไม่มีทางรายงานว่ายิงโดนผู้เล่นที่ยิงมันเองได้เลย ไม่ว่า ray จะเริ่มจากตรงไหน

overlap query ถามคำถามต่างออกไป คือ "มี collider อะไรอยู่ข้างในรูปทรงนี้ตอนนี้บ้าง" — มีประโยชน์สำหรับการตรวจจับพื้นที่ เช่น สัญญาณเตือนที่รู้ว่า player อยู่ใกล้ ๆ

using UnityEngine;

public class ProximityAlarm : MonoBehaviour
{
    public float radius = 5f;
    public LayerMask playerLayer;

    void FixedUpdate()
    {
        // Physics.OverlapSphere returns every collider touching the
        // sphere -- this object does not even need a Collider itself.
        Collider[] nearby = Physics.OverlapSphere(transform.position, radius, playerLayer);

        if (nearby.Length > 0)
        {
            Debug.Log("Player detected, colliders in range: " + nearby.Length);
        }
    }
}

ผลลัพธ์ที่คาดหวัง: console จะพิมพ์ Player detected, colliders in range: 1 ทุก physics step ที่ player ยังอยู่ในระยะ 5 หน่วย แล้วหยุดพิมพ์ทันทีที่เดินออกไป

8. Impulse, Knockback, และการระเบิด

แรงผลักทันทีครั้งเดียว — การตีระยะประชิด แรงกระแทกจากกระสุน แผ่นเด้ง — ใช้ ForceMode.Impulse แทน ForceMode.Force แบบต่อเนื่องจาก Section 6 โดยใส่ครั้งเดียวเป๊ะ

void ApplyKnockback(Rigidbody target, Vector3 direction, float strength)
{
    // Impulse: an instant velocity change that still respects mass,
    // so a heavy enemy flies back less than a light one for the
    // same strength value -- feels right without extra tuning.
    target.AddForce(direction.normalized * strength, ForceMode.Impulse);
}

การระเบิดต้องผลัก Rigidbody ทุกตัวที่อยู่ใกล้ ๆ พร้อมกันหมด ด้วยแรงที่ค่อย ๆ จางลงตามระยะทาง Rigidbody.AddExplosionForce จัดการเรื่อง falloff นี้ให้เราเลย ผสมกับ query Physics.OverlapSphere จาก Section 7 เพื่อหาทุกอย่างที่อยู่ในระยะ

using UnityEngine;

public class Grenade : MonoBehaviour
{
    public float explosionForce = 700f;
    public float explosionRadius = 5f;
    public float upwardsModifier = 0.5f;
    public LayerMask affectedLayers;

    public void Explode()
    {
        Collider[] hits = Physics.OverlapSphere(transform.position, explosionRadius, affectedLayers);

        foreach (Collider hit in hits)
        {
            if (hit.attachedRigidbody != null)
            {
                hit.attachedRigidbody.AddExplosionForce(
                    explosionForce,
                    transform.position,
                    explosionRadius,
                    upwardsModifier,
                    ForceMode.Impulse);
            }
        }

        Destroy(gameObject);
    }
}

parameter ตามลำดับ: explosionForce (ความแรงตรงจุดศูนย์กลางของแรงระเบิด), explosionPosition (จุดที่เกิดระเบิด — object ที่อยู่ไกลจากจุดนี้จะได้แรงน้อยลง จนเหลือศูนย์ที่ explosionRadius), explosionRadius (ระยะที่แรงระเบิดไปถึง), และ upwardsModifier (แรงดันขึ้นเพิ่มเติมแบบเทียม ๆ ที่ทำให้เศษซากกับ ragdoll ปลิวขึ้นและออกด้านนอก แทนที่จะไถลไปตามพื้นแบนราบ — การระเบิดจริงก็ทำแบบนี้เหมือนกัน แต่ parameter นี้ทำให้เราขยายผลให้ดูดีขึ้นได้)

ผลลัพธ์ที่คาดหวัง: การเรียก Explode() ใกล้ลังสามใบ จะเจอทั้งสามใบด้วย OverlapSphere และแต่ละใบจะปลิวออกด้านนอกและขึ้นด้านบนเล็กน้อย โดยลังที่อยู่ติดกับระเบิดจะปลิวไปไกลกว่าลังที่อยู่ใกล้ขอบของ explosionRadius มาก — falloff เกิดขึ้นอัตโนมัติข้างใน AddExplosionForce เราไม่ต้องคำนวณระยะทางเองเลย

9. Velocity กับ Force: กรณีศึกษาการกระโดด

ตอนนี้เรามีเครื่องมือสองแบบที่ทำให้อะไรบางอย่างเคลื่อนที่ได้ คือใส่แรงหรือ impulse หรือตั้งค่า rb.linearVelocity ตรง ๆ (เขียนทับความเร็วปัจจุบันของ object ไปเลย — property นี้ชื่อ velocity ใน Unity เวอร์ชันเก่า) การกระโดดเป็นตัวอย่างที่ชัดที่สุดว่าแต่ละแบบเหมาะกับตอนไหน เพราะทั้งคู่ดู "ถูกต้อง" ในการทดสอบเร็ว ๆ และจะเผยความต่างออกมาก็ตอนเจอ edge case เท่านั้น

public class JumpWithForce : MonoBehaviour
{
    public Rigidbody rb;
    public float jumpForce = 8f;

    public void Jump()
    {
        // Adds ON TOP of whatever vertical velocity already exists.
        rb.AddForce(Vector3.up * jumpForce, ForceMode.Impulse);
    }
}

public class JumpWithVelocity : MonoBehaviour
{
    public Rigidbody rb;
    public float jumpSpeed = 8f;

    public void Jump()
    {
        // OVERWRITES vertical velocity outright.
        Vector3 v = rb.linearVelocity;
        v.y = jumpSpeed;
        rb.linearVelocity = v;
    }
}

ลองทั้งสองแบบตอนที่ตัวละครกำลังตกจากขอบอยู่แล้ว (กำลังเคลื่อนที่ลง rb.linearVelocity.y เป็นค่าลบ) JumpWithForce เอา jump impulse ไปบวกกับค่าลบนั้น ทำให้ความสูงของการกระโดดขึ้นอยู่กับว่าตัวละครกำลังตกเร็วแค่ไหนอยู่แล้ว — บางทีแทบไม่ลอยขึ้นจากพื้นเลย บางทีก็พุ่งขึ้นสูงเกินคาด JumpWithVelocity ไม่สนใจว่าตัวละครกำลังทำอะไรอยู่ และตั้งค่า y เป็น jumpSpeed เป๊ะ ๆ เสมอ — การกระโดดขึ้นถึงความสูงเท่าเดิมทุกครั้งไม่มีเว้น

ตอนไหนควรใส่แรงหรือ impulse: อะไรก็ตามที่ควรดูและรู้สึกสมจริงทางฟิสิกส์ ที่การเปลี่ยนแปลงตาม mass และการเคลื่อนที่เดิมคือจุดประสงค์เลย — การระเบิด, knockback, ragdoll, แรงผลักจากสิ่งแวดล้อม, ก้อนหินกลิ้งลงเนินแล้วเร็วขึ้นเรื่อย ๆ

ตอนไหนควรตั้งค่า velocity ตรง ๆ: action ที่ผู้เล่นควบคุมและต้องการความแม่นยำสูง ที่ความคงเส้นคงวาสำคัญกว่าความสมจริง — การกระโดดในเกม platformer ที่ต้องสูงเท่าเดิมทุกครั้ง ท่า dash ที่มีความเร็วคงที่แน่นอน การ clamp Rigidbody ไม่ให้เกินความเร็วสูงสุด character controller สไตล์ arcade ที่ตอบสนองไว "กระชับ" ส่วนใหญ่พึ่งพาการตั้งค่า velocity ตรง ๆ มากกว่าการสะสมแรงเรื่อย ๆ

10. Interpolation: ทำให้ภาพที่ขับเคลื่อนด้วย Physics ลื่นขึ้น

ย้อนกลับไปที่ Section 4 FixedUpdate ทำงานที่อัตราคงที่ (50 Hz เป็น default) ในขณะที่การ render อาจเร็วกว่านั้นมาก (144 Hz, 240 Hz, หรือไม่จำกัด) Transform ของ Rigidbody เปลี่ยนจริง ๆ ก็ต่อเมื่อมี physics step เท่านั้น ถ้าจอ redraw บ่อยกว่านั้น ตำแหน่งเดิมจะถูกวาดซ้ำหลายเฟรมติดกัน แล้วก็กระโดดไปตำแหน่ง physics ถัดไป — เห็นเป็นอาการกระตุกเล็กน้อย โดยเฉพาะกับ object ที่เคลื่อนที่เร็ว

วิธีแก้คือการตั้งค่า Rigidbody.interpolation จะทำใน Inspector หรือในโค้ดก็ได้

void Awake()
{
    Rigidbody rb = GetComponent<Rigidbody>();
    rb.interpolation = RigidbodyInterpolation.Interpolate;
}

• RigidbodyInterpolation.None (default) — ไม่มีการทำให้ลื่นเลย ถูกที่สุด แต่อาจดูกระตุกที่ frame rate สูงเทียบกับ fixed timestep
• RigidbodyInterpolation.Interpolate — ทำให้ลื่นโดยการ render ช้ากว่าสถานะ physics จริงเล็กน้อย ผสมระหว่างตำแหน่งที่รู้สองตำแหน่งล่าสุด ดูลื่นเสมอ เพิ่ม delay นิดเดียวที่ปกติสังเกตไม่ออก เป็นค่า default ที่ถูกต้องสำหรับ object ที่ player ควบคุมและ object ที่กล้องตาม
• RigidbodyInterpolation.Extrapolate — เดาล่วงหน้าโดยใช้ความเร็วปัจจุบัน แทนที่จะผสมย้อนหลัง ไม่มี delay เพิ่ม แต่การเดาอาจผิดให้เห็นชัด ๆ หนึ่งเฟรมตอนที่ความเร็วเปลี่ยนกะทันหัน (การเด้ง, การเลี้ยวกะทันหัน) ใช้อย่างระมัดระวัง และอย่าใช้กับอะไรที่ player ต้องการ feedback แม่นยำระดับ pixel

ผลลัพธ์ที่คาดหวัง: ลูกบอลที่กลิ้งบนพื้นโดยตั้ง Interpolate ไว้ จะดูลื่นสมบูรณ์แบบที่ 144 fps ทั้งที่ยังถูกจำลองทาง physics แค่ 50 ครั้งต่อวินาทีเท่านั้น ลูกบอลลูกเดียวกันที่ตั้ง None ไว้ จะเห็นการก้าวข้ามตำแหน่งชัด ๆ บนจอที่ refresh เร็วมาก ๆ สังเกตได้ชัดเป็นพิเศษตอน camera pan ช้า ๆ

11. Determinism: Fixed Step, Fixed Order

simulation จะ deterministic (กำหนดผลได้แน่นอน) เมื่อสถานะเริ่มต้นเดียวกันเป๊ะ และลำดับ input เดียวกันเป๊ะ ให้ผลลัพธ์เดียวกันเป๊ะทุกครั้งที่รัน มีสองฟีเจอร์ที่พึ่งพาสิ่งนี้โดยตรง

• Replay — แทนที่จะบันทึกตำแหน่งของทุก object ทุกเฟรม (ข้อมูลมหาศาล) เราบันทึกแค่ input ของ player แล้ว re-run simulation จากสถานะเริ่มต้นเดียวกัน ป้อน input เดียวกันกลับเข้าไป ถ้า simulation เป็น deterministic replay จะดูเหมือนการเล่นครั้งแรกเป๊ะ จากไฟล์เล็กนิดเดียว
• Lockstep networking (โมเดล multiplayer ที่พบบ่อยในเกม real-time strategy ที่เครื่องของผู้เล่นทุกคนรัน simulation เต็มรูปแบบในเครื่องตัวเอง แล้วส่งแค่ input ผ่านเครือข่าย) — ทุกเครื่องต้องได้ผลลัพธ์เดียวกันเป๊ะจาก input เดียวกัน ไม่งั้นโลกเกมจะค่อย ๆ เพี้ยนไปคนละทางระหว่างผู้เล่น (เรียกว่า desync)

มีสองข้อกำหนดที่ทำให้สิ่งนี้เป็นไปได้ และทั้งคู่เชื่อมกับ section ก่อนหน้าโดยตรง

• Fixed timestep — จำลอง physics ด้วย step ขนาดเท่ากันเป๊ะเสมอ (Time.fixedDeltaTime จาก Section 4) ไม่ใช่ step ที่แปรผันตามเฟรม floating-point math ให้ผลลัพธ์ต่างกันเล็กน้อยสำหรับขนาด step ต่างกัน ดังนั้น step ที่แปรผันจะทำให้ input เดียวกันเป๊ะให้ผลลัพธ์ต่างกันเล็กน้อยในการรันแต่ละครั้ง
• Fixed order — ประมวลผล object, input, และ event ในลำดับเดียวกันทุกครั้งที่รัน ลำดับการวนของ Dictionary ใน C# ไม่รับประกันว่าจะเหมือนเดิมข้ามการรันหรือข้าม platform การวน loop เพื่อรัน gameplay logic อาจเปลี่ยนผลลัพธ์แบบเงียบ ๆ ได้ ให้ใช้ collection ที่มีลำดับแน่นอน (List หรือ array ที่เรียงตาม ID ที่คงที่) สำหรับอะไรก็ตามที่มีผลต่อ simulation

[System.Serializable]
public struct InputFrame
{
    public int tick;
    public float horizontal;
    public bool jumpPressed;
}

public class ReplayRecorder : MonoBehaviour
{
    private List<InputFrame> recordedFrames = new List<InputFrame>();
    private int currentTick;

    void FixedUpdate()
    {
        InputFrame frame = new InputFrame
        {
            tick = currentTick,
            horizontal = Input.GetAxisRaw("Horizontal"),
            jumpPressed = Input.GetButtonDown("Jump")
        };
        recordedFrames.Add(frame);

        ApplyInput(frame);
        currentTick++;
    }

    void ApplyInput(InputFrame frame)
    {
        // The SAME method drives live play and replay playback. As long
        // as this only ever runs from FixedUpdate (fixed step, fixed
        // order), replaying the same recordedFrames list reproduces the
        // exact same run.
    }
}

ข้อจำกัดหนึ่งที่ควรรู้ไว้ตรง ๆ คือ PhysX engine ที่ติดมากับ Unity ไม่ได้รับประกันว่าจะให้ผลลัพธ์ตรงกันแบบ bit-ต่อ-bit ข้าม CPU architecture หรือ platform ที่ต่างกัน เพราะการปัดเศษของ floating-point อาจต่างกันได้ในระดับนั้น ระบบ replay บนเครื่องเดียว (กรณีด้านบน) เชื่อถือได้ เพราะเครื่องเดียวกันรันทั้งการบันทึกและการเล่นซ้ำ lockstep multiplayer ข้าม platform จริง ๆ ที่ใช้ physics 3 มิติเต็มรูปแบบนั้นยากพอตัว จนเกม RTS หรือเกมต่อสู้แข่งขันหลายเกมเลือกจำกัด lockstep ให้เหลือแค่ simulation แบบ fixed-point ที่เขียนขึ้นเอง เรียบง่ายกว่า หรือไม่ก็พึ่งพา determinism แค่ภายใน platform เดียว แทนที่จะเชื่อ physics engine อเนกประสงค์ข้ามทุกเครื่อง

12. Performance: Active Body เยอะเกินไป

ทุก physics step engine ต้องทำงานจริงกับทุก Rigidbody ที่ยังไม่หลับ คือ หา collider คู่ไหนที่อาจสัมผัสกัน (broadphase), เช็คคู่ที่เป็นไปได้เหล่านั้นอย่างละเอียด (narrowphase), แล้วแก้ปัญหาการสัมผัสจริง (solver) FixedUpdate มีเวลาจริงจำกัดให้ทำงานเสร็จก่อนถึง step ถัดไป ถ้า active body เยอะเกินไป physics step เองก็จะเริ่มใช้เวลานานกว่างบเวลาที่มีอยู่ ทำให้เกมทั้งหมดช้าลงแม้ว่าฉากจะดูไม่ซับซ้อนทางภาพเลยก็ตาม

วิธีที่ทำได้จริงในการคุมจำนวนและต้นทุนให้ต่ำ

• ปล่อยให้ Rigidbody หลับได้. Unity ให้ Rigidbody หลับอัตโนมัติเมื่อความเร็วของมันต่ำกว่า threshold เล็ก ๆ อยู่สักพัก — body ที่หลับอยู่แทบไม่มีต้นทุนอะไรเลย จนกว่าจะมีอะไรปลุกมัน (การชนใหม่, สคริปต์เรียก AddForce หรือตั้งค่า velocity) อย่าฝืนสิ่งนี้ด้วยการแตะ Rigidbody ทุกเฟรมทั้งที่ไม่มีอะไรต้องเปลี่ยนจริง ๆ เพราะนั่นจะปลุกมันโดยไม่มีเหตุผล
• เลือกใช้ collider แบบ primitive. BoxCollider, SphereCollider, หรือ CapsuleCollider เช็คได้ถูกกว่า MeshCollider มาก โดยเฉพาะแบบ non-convex ให้ห่อ mesh ที่ละเอียดด้วย primitive ง่าย ๆ (หรือกลุ่มเล็ก ๆ ของมัน) แทนที่จะชนกับ geometry ที่มองเห็นเป๊ะ ๆ
• Pool physics object แทนการ spawn กับ destroy. Object Pool pattern จากบทก่อนหน้าใช้ได้ตรงนี้เลย ปืนกลที่ spawn แล้ว destroy กระสุน Rigidbody ทุกนัดที่ยิง เพิ่มและลบ active body ตลอดเวลา การใช้ pool กระสุนซ้ำแทนจะคุมจำนวน active ให้อยู่ในกรอบได้
• ใช้ Layer Collision Matrix. matrix จาก Section 5 ก็เป็นเครื่องมือด้าน performance เหมือนกัน ทุกคู่ที่ไม่ติ๊กไว้คือคู่ที่ broadphase ไม่ต้องพิจารณาเลยด้วยซ้ำ ไม่ใช่แค่คู่ที่ผลลัพธ์ถูกทิ้งไป

using System.Collections.Generic;
using UnityEngine;

public class DebrisSpawner : MonoBehaviour
{
    public GameObject debrisPrefab;
    public int maxActiveDebris = 30;

    private readonly Queue<GameObject> activeDebris = new Queue<GameObject>();

    public void SpawnDebris(Vector3 position)
    {
        if (activeDebris.Count >= maxActiveDebris)
        {
            // Cap the number of active physics bodies instead of letting
            // every explosion add more debris forever.
            GameObject oldest = activeDebris.Dequeue();
            Destroy(oldest);
        }

        GameObject piece = Instantiate(debrisPrefab, position, Quaternion.identity);
        activeDebris.Enqueue(piece);
    }
}

ผลลัพธ์ที่คาดหวัง: การระเบิดซ้ำ ๆ ยัง spawn เศษซากไปเรื่อย ๆ แต่จำนวน active Rigidbody ไม่มีวันโตเกิน maxActiveDebris — ชิ้นที่เก่าที่สุดจะถูกลบก่อนที่ชิ้นใหม่จะถูกเพิ่ม ทำให้ workload ของ physics step มีขอบเขตจำกัด ไม่ว่า player จะระเบิดของไปนานแค่ไหนก็ตาม

13. Glossary

• Physics engine — ระบบแยกต่างหาก (PhysX ในกรณี 3D default ของ Unity) ที่จำลอง rigid body, แรงโน้มถ่วง, และการชนกัน ด้วยนาฬิกาและ loop ของตัวเอง
• Rigidbody — component ที่ทำให้ GameObject อยู่ภายใต้การควบคุมของ physics engine อาจเป็น dynamic (จำลองเต็มรูปแบบ), kinematic (ขยับด้วยสคริปต์แต่ยังชนได้), หรือไม่มีเลย (static)
• Collider — รูปทรง (กล่อง, ทรงกลม, แคปซูล, หรือ mesh) ที่ physics engine ใช้เช็คการสัมผัส แยกจาก mesh ที่มองเห็นของ object
• Solid collider — collider ที่ isTrigger = false บล็อก collider อื่นทางกายภาพ และเรียก OnCollisionEnter/Stay/Exit
• Trigger collider — collider ที่ isTrigger = true ตรวจจับการซ้อนทับโดยไม่บล็อก และเรียก OnTriggerEnter/Stay/Exit แทน
• FixedUpdate — method ของ Unity ที่ทำงานที่อัตราคงที่ (Time.fixedDeltaTime) ไม่ขึ้นกับ frame rate เป็นที่ที่ถูกต้องสำหรับใส่แรง, impulse, และการเปลี่ยน velocity
• Fixed timestep — ขนาดเวลาคงที่ของแต่ละ physics step ตั้งไว้ใน Project Settings ไม่เปลี่ยนตาม frame rate เลย
• Layer — หมวดหมู่ที่มีหมายเลขซึ่งกำหนดให้ GameObject ใช้โดยทั้งระบบ rendering และ physics เพื่อตัดสินว่าอะไรมีปฏิสัมพันธ์กับอะไร
• Layer Collision Matrix — ตารางใน Project Settings ที่ควบคุมว่า layer คู่ไหนสามารถเกิด collision หรือ trigger event กันได้บ้าง
• LayerMask — ค่า bitmask ที่ใช้กรองว่า raycast หรือ overlap query ได้รับอนุญาตให้โดน layer ไหนบ้าง
• Raycast — การยิงเส้นตรงที่มองไม่เห็นผ่านฉาก แล้วถามว่าโดนอะไรก่อน เป็นเครื่องมือมาตรฐานสำหรับ hitscan shooting
• Overlap query — การถาม physics engine ว่ามี collider อะไรอยู่ข้างในรูปทรงที่กำหนดตอนนี้บ้าง โดยไม่จำลองอะไรเลย
• ForceMode — argument โหมดของ AddForce ที่กำหนดว่าแรงผลักเป็นแบบต่อเนื่องหรือทันที และสนใจ mass ของเป้าหมายหรือไม่
• Impulse — แรงผลักทันทีที่ใส่ครั้งเดียว ด้วย ForceMode.Impulse ซึ่งสนใจ mass
• AddExplosionForce — method ของ Rigidbody ที่ผลัก object ออกจากจุดหนึ่ง ด้วยแรงที่จางลงอัตโนมัติภายในรัศมีที่กำหนด
• linearVelocity — property ของ Rigidbody ที่เก็บความเร็วปัจจุบัน การตั้งค่ามันตรง ๆ จะเขียนทับการเคลื่อนที่ทันที โดยไม่สนใจ mass และแรงที่มีอยู่
• Interpolation (physics) — การทำให้ตำแหน่งที่ render ของ Rigidbody ลื่นขึ้นระหว่าง physics step ทำให้การเคลื่อนที่ดูไหลลื่นแม้ที่ frame rate สูงกว่า fixed timestep
• Determinism — คุณสมบัติที่สถานะเริ่มต้นและ input เดียวกันให้ผลลัพธ์ simulation เดียวกันเป๊ะเสมอ จำเป็นสำหรับ replay ที่เชื่อถือได้และ lockstep networking
• Lockstep networking — โมเดล multiplayer ที่ทุกเครื่องจำลองเกมทั้งหมดในเครื่องตัวเองจาก input ที่แชร์กัน ต้องการ simulation แบบ deterministic เพื่อไม่ให้เกิด desync
• Broadphase / narrowphase / solver — สามขั้นตอนของ physics step คือ หาคู่ collider ที่อาจชนกันแบบถูก ๆ ก่อน เช็คให้ละเอียดขึ้น แล้วแก้ปัญหาการสัมผัสจริง

14. Exercises

public class Hovercraft : MonoBehaviour
{
    public Rigidbody rb;
    public float thrust = 15f;

    void Update()
    {
        if (Input.GetKey(KeyCode.W))
        {
            rb.AddForce(transform.forward * thrust, ForceMode.Force);
        }
    }
}

public class Hovercraft : MonoBehaviour
{
    public Rigidbody rb;
    public float thrust = 15f;
    private bool thrustHeld;

    void Update()
    {
        thrustHeld = Input.GetKey(KeyCode.W);
    }

    void FixedUpdate()
    {
        if (thrustHeld)
        {
            rb.AddForce(transform.forward * thrust, ForceMode.Force);
        }
    }
}

using UnityEngine;

public class HealingPotion : MonoBehaviour
{
    public int healAmount = 20;

    void OnTriggerEnter(Collider other)
    {
        if (other.TryGetComponent(out Health health))
        {
            health.Heal(healAmount);
            Debug.Log("Healing potion used, +" + healAmount + " HP");
            Destroy(gameObject);
        }
    }
}

using UnityEngine;

public class Grenade : MonoBehaviour
{
    public float explosionForce = 500f;
    public float explosionRadius = 6f;
    public float upwardsModifier = 0.3f;
    public LayerMask enemyLayer; // set to "Enemies" only in the Inspector

    public void Explode()
    {
        Collider[] hits = Physics.OverlapSphere(transform.position, explosionRadius, enemyLayer);

        foreach (Collider hit in hits)
        {
            if (hit.attachedRigidbody != null)
            {
                hit.attachedRigidbody.AddExplosionForce(
                    explosionForce,
                    transform.position,
                    explosionRadius,
                    upwardsModifier,
                    ForceMode.Impulse);
            }
        }

        Destroy(gameObject);
    }
}