4.3 ระบบใน Unity: Input, Physics, Animation, Audio, UI

สองบทที่แล้วเราเรียนไปว่าโปรเจกต์ Unity ถูกสร้างจาก GameObject และ Component ยังไง (4.1) และเขียนพฤติกรรมด้วยสคริปต์ MonoBehaviour ยังไง — Awake, Start, Update, FixedUpdate, coroutine, event, ScriptableObject (4.2) นั่นคือโครงกระดูก บทนี้จะพูดถึง ระบบสำเร็จรูป ที่ทำให้เกม Unity มีความรู้สึกเป็นเกมจริง ๆ: การอ่าน input ของผู้เล่น, การจำลอง physics, การเล่น animation, การทำ เสียง, และการวาด UI (เมนู, health bar, ปุ่ม) เกม Unity ทุกเกม ตั้งแต่ prototype ทำเล่นวันหยุดจนถึงเกมระดับ HoYoverse ล้วนพึ่งพาระบบทั้ง 5 นี้เหมือนกันหมด

แต่ละหัวข้อจะมีรูปแบบเดิม: สคริปต์เล็ก ๆ, สิ่งที่เกิดขึ้นตอนรัน (Console output หรือ trace ทีละขั้นตอนที่ชัดเจน) แล้วอธิบายด้วยภาษาง่าย ๆ บางส่วนของระบบเหล่านี้ — กราฟ Animator, การผูก Input, เลย์เอาต์ UI — ปกติจะสร้างด้วยมือใน Unity Editor ไม่ใช่พิมพ์เป็นโค้ด สำหรับส่วนพวกนี้ ไดอะแกรมและ trace จะโชว์ให้เห็นว่า Editor ทำอะไรอยู่เบื้องหลัง

1. ภาพรวม: ระบบทั้ง 5

ระบบเหล่านี้แต่ละอันคือ Component ที่เราติดเข้ากับ GameObject — เหมือน Component ที่เจอมาแล้วใน 4.1 เป๊ะ ๆ แค่มันเป็นของที่ Unity สร้างมาให้ ไม่ใช่ที่เราเขียนเอง

หนึ่งเฟรมทั่ว ๆ ไปจะแตะทั้ง 5 ระบบ: Input อ่านว่าผู้เล่นกำลังทำอะไรอยู่ตอนนี้, Physics ขยับและชน Rigidbody, Animation เลือกว่าจะเล่นคลิปไหนตามการเคลื่อนไหวนั้น, Audio เล่นเสียงที่เข้าคู่กัน และ UI โชว์ผลลัพธ์ (เลือด, คะแนน) บนจอ ที่เหลือของบทนี้จะไล่ทีละระบบ

2. อ่าน Input: การเคลื่อนที่และปุ่ม

Unity มีสองวิธีอ่าน input: คลาส Input แบบคลาสสิก (ใช้ได้ทันที ไม่ต้องตั้งค่าอะไร) กับแพ็กเกจ Input System รุ่นใหม่ (ตั้งค่าเยอะกว่า แต่ทำอะไรได้เยอะกว่า) เรียนแบบคลาสสิกก่อน — เกมที่วางขายจริงหลายเกมก็ยังใช้อยู่ และแนวคิดจะพาไปต่อยอดกับตัวใหม่ได้ตรง ๆ

using UnityEngine;

public class InputDemo : MonoBehaviour
{
    void Update()
    {
        // GetAxis returns a smoothed value from -1 to 1.
        // "Horizontal" = A/D or Left/Right arrows (or a gamepad stick)
        // "Vertical"   = W/S or Up/Down arrows
        float h = Input.GetAxis("Horizontal");
        float v = Input.GetAxis("Vertical");

        if (h != 0f || v != 0f)
            Debug.Log($"move: ({h:F1}, {v:F1})");

        if (Input.GetButtonDown("Jump"))   // default binding: Space bar
            Debug.Log("Jump pressed!");

        if (Input.GetKeyDown(KeyCode.E))   // a specific key, no Input Manager entry needed
            Debug.Log("E pressed - interact!");
    }
}

Console output หลังจากกดค้างปุ่ม D สักพัก แล้วแตะ Space แล้วแตะ E:

move: (1.0, 0.0)
move: (1.0, 0.0)
move: (1.0, 0.0)
Jump pressed!
E pressed - interact!

"Horizontal" กับ "Vertical" ไม่ใช่ string มายากล — มันคือ axis ที่ตั้งชื่อไว้ใน Edit > Project Settings > Input Manager และ Unity มาพร้อมสองตัวนี้บวก "Jump" ตั้งไว้ให้เรียบร้อยแล้ว GetAxis จะ smooth ค่าให้ลื่นข้ามหลายเฟรม (มันจะไล่จาก 0 ไปหา 1 ทีละนิด ซึ่งรู้สึกเป็นธรรมชาติสำหรับการเคลื่อนที่); GetAxisRaw จะให้ค่า -1/0/1 ทันทีไม่ smooth ซึ่งบางเกมชอบเพราะควบคุมได้แม่นและไวกว่า

มีสามวิธีเช็คปุ่ม และความต่างของมันสำคัญ:

• GetButtonDown("Jump") — true แค่ เฟรมเดียว คือเฟรมที่กดปุ่มลงไป ใช้กับ "กระโดดครั้งเดียว"
• GetButton("Jump") — true ทุกเฟรม ที่ยังกดปุ่มค้างอยู่ ใช้กับ "วิ่งต่อไปเรื่อย ๆ ตราบใดที่ยังกดค้าง"
• GetButtonUp("Jump") — true แค่เฟรมเดียว คือเฟรมที่ปล่อยปุ่ม

แพ็กเกจ Input System: action แทน string

โปรเจกต์ Unity รุ่นใหม่ ๆ ใช้แพ็กเกจ Input System (com.unity.inputsystem ติดตั้งแยกผ่าน Package Manager) แทนที่จะ hardcode string เราจะนิยาม Input Action (เช่น "Move" หรือ "Jump") ไว้ใน asset แล้วผูกแต่ละ action เข้ากับ control จริงหนึ่งอย่างหรือมากกว่า — ปุ่มคีย์บอร์ด, จอยสติ๊กเกมแพด, การปัดหน้าจอสัมผัส สคริปต์เราแค่ถามค่าปัจจุบันของ action นั้น มันไม่สนว่าอุปกรณ์ตัวไหนเป็นคนสร้างค่านั้นขึ้นมา

using UnityEngine;
using UnityEngine.InputSystem;

public class InputSystemDemo : MonoBehaviour
{
    public InputAction moveAction;   // bound to WASD + left stick in the Inspector

    void OnEnable()  { moveAction.Enable(); }
    void OnDisable() { moveAction.Disable(); }

    void Update()
    {
        Vector2 move = moveAction.ReadValue<Vector2>();
        if (move != Vector2.zero)
            Debug.Log($"move: {move}");
    }
}

ข้อดีคือ: action เดียวชื่อ "Move" ผูกกับคีย์บอร์ด และ เกมแพด และ touch พร้อมกันได้เลย แล้วผู้เล่นยัง rebind ปุ่มเองได้โดยที่เราไม่ต้องแตะโค้ด นี่สำคัญมากสำหรับเกมที่วางขายจริง (รองรับ controller, accessibility) แต่ก็ต้องตั้งค่าจริงจังกว่า — ติดตั้งแพ็กเกจ, สร้าง Input Actions asset, ผูก binding ผ่าน editor แบบกราฟิก สำหรับที่เหลือของบทนี้ คลาส Input แบบคลาสสิกก็เพียงพอแล้วเพื่อให้ตัวอย่างสั้นกระชับ

3. ส่วนประกอบพื้นฐานของ Physics: Rigidbody กับ Collider

physics engine ของ Unity จะสนใจ GameObject ก็ต่อเมื่อมัน component ที่ถูกต้อง สองตัวที่สำคัญตรงนี้คือ:

• Collider (BoxCollider, SphereCollider, CapsuleCollider, MeshCollider...) กำหนด รูปทรง ที่ใช้สำหรับการสัมผัสทางฟิสิกส์ มันไม่จำเป็นต้องตรงกับ mesh ที่มองเห็นเป๊ะ ๆ — กล่องหรือแคปซูลง่าย ๆ ครอบโมเดลตัวละครที่ละเอียดเป็นเรื่องปกติ และคำนวณถูกกว่าเยอะ
• Rigidbody ส่งมอบ GameObject ให้ physics engine ดูแล: มันจะได้ mass, gravity, velocity และตอบสนองต่อแรงและการชนอัตโนมัติ ถ้าไม่มี Rigidbody, Collider ก็แค่นั่งอยู่เฉย ๆ เป็นสิ่งกีดขวางที่แข็งและขยับไม่ได้ — เหมาะกับพื้นหรือกำแพง

พอมี Rigidbody แล้ว gravity ของ Unity จะดึงมันลงทุก physics step โดยอัตโนมัติ — เราไม่ต้องเขียนสคริปต์ "ตก" เอง เราอ่านและเปลี่ยนการเคลื่อนที่ของมันผ่าน property ของ Rigidbody เอง แทนที่จะขยับ Transform ตรง ๆ:

using UnityEngine;

public class RigidbodyPeek : MonoBehaviour
{
    Rigidbody rb;

    void Awake()
    {
        rb = GetComponent<Rigidbody>();
        rb.mass = 2f;                                   // heavier -> needs more force to push
        rb.linearVelocity = new Vector3(0f, 5f, 0f);     // an initial upward "pop"
    }

    void Start()
    {
        Debug.Log($"mass={rb.mass}, velocity={rb.linearVelocity}");
    }
}

Output:

mass=2, velocity=(0.00, 5.00, 0.00)

(Unity รุ่นเก่ากว่าเรียก property ตัวนี้ว่า rb.velocity แทน rb.linearVelocity — แนวคิดเดียวกัน แค่เปลี่ยนชื่อในรุ่นใหม่ ๆ) การตั้งค่า linearVelocity ตรง ๆ คือการ override แบบเด็ดขาด เหมาะกับการยิงพุ่งครั้งเดียว สำหรับการเคลื่อนที่ต่อเนื่องแบบสมจริงตามฟิสิกส์ — เครื่องยนต์รถ, เครื่องพ่นจรวด — เราจะเรียก rb.AddForce(...) ทุก physics step แทน ซึ่งจะดัน velocity แทนที่จะแทนที่มันตรง ๆ รายละเอียดว่าจะเรียกตรงไหนอยู่ในหัวข้อ 5

4. Collider กับ Trigger ต่างกันยังไง

Collider ทุกตัวมีช่องติ๊ก Is Trigger ใน Inspector แค่ช่องติ๊กเดียวนี้แบ่งพฤติกรรมมันออกเป็นสองโหมดที่ต่างกันโดยสิ้นเชิง:

• Solid collider (Is Trigger ปิด) — บล็อกทางกายภาพจริง ๆ Collider แบบ solid สองตัวอยู่ที่เดียวกันไม่ได้ physics engine จะดันมันแยกออกจากกัน นี่คือสิ่งที่ทำให้กำแพงเป็นกำแพง
• Trigger (Is Trigger เปิด) — ไม่บล็อกอะไรเลย วัตถุเดินทะลุผ่านมันได้ตรง ๆ แต่ Unity ก็ยังบอกสคริปต์เราว่า "มีอะไรเข้ามา" กับ "มีอะไรออกไป" นี่คือสิ่งที่ทำให้เส้นชัยล่องหน, โซนเก็บไอเทม หรือประตูออกจากด่านเป็นไปได้

สคริปต์เราจะรู้เรื่องทั้งสองแบบผ่านคู่ callback method ที่ Unity เรียกให้อัตโนมัติ — เราไม่เคยเรียกพวกนี้เอง Unity จะเรียกให้ตอนมีการสัมผัสเกิดขึ้น:

using UnityEngine;

public class ContactDemo : MonoBehaviour
{
    // Fires when THIS object's solid collider physically hits another.
    void OnCollisionEnter(Collision collision)
    {
        Debug.Log($"bumped into {collision.gameObject.name}");
    }

    // Fires when THIS object's TRIGGER collider overlaps another collider.
    void OnTriggerEnter(Collider other)
    {
        Debug.Log($"entered trigger zone of {other.gameObject.name}");
    }
}

ลอง trace ดู: สมมติสคริปต์นี้อยู่บนลูกบอลที่มี SphereCollider แบบปกติ (ไม่ใช่ trigger) กับ Rigidbody ลูกบอลกลิ้งไปชนกำแพง (solid collider) — OnCollisionEnter ทำงาน พิมพ์ bumped into Wall และลูกบอลหยุดจริง ๆ ทางฟิสิกส์ อีกไม่กี่วินาทีต่อมาลูกบอลกลิ้งเข้าไปใน GameObject "Coin" ที่ collider ของมันติ๊ก Is Trigger ไว้ — ลูกบอลไม่หยุด มันกลิ้งทะลุเหรียญไปเลย แต่ OnTriggerEnter ทำงาน พิมพ์ entered trigger zone of Coin ลูกบอลตัวเดียวกัน สคริปต์เดียวกัน แค่ตั้งค่า collider ต่างกัน ผลลัพธ์ก็ต่างกันคนละเรื่อง

มีข้อกำหนดหนึ่งที่คนมักพลาด: อย่างน้อยหนึ่ง ในสองวัตถุที่สัมผัสกัน (ไม่ว่า collision หรือ trigger) ต้องมี Rigidbody ไม่งั้น Unity จะตรวจจับการสัมผัสไม่ได้เลย กำแพง static (มีแค่ Collider ไม่มี Rigidbody) ก็ยังใช้งานได้เพราะ อีกฝั่ง — ตัวผู้เล่นของเรา — มี Rigidbody อยู่แล้ว

5. ขยับด้วย Physics: ทำไมต้อง FixedUpdate

เราเจอ Update กับ FixedUpdate มาแล้วใน 4.2 ตรงนี้คือเหตุผลว่าทำไมความต่างของมันสำคัญมากโดยเฉพาะกับ physics Update รันครั้งเดียวต่อ เฟรมที่เรนเดอร์ และเฟรมพวกนี้ไม่ได้ห่างกันเท่า ๆ กัน — วินาทีนึงอาจได้ 60 เฟรม อีกวินาทีอาจได้ 144 เฟรม ขึ้นอยู่กับว่าเครื่องแรงแค่ไหน FixedUpdate รันตาม ตัวจับเวลาคงที่ (ค่า default 0.02 วินาที คือ 50 ครั้งต่อวินาที) ไม่ว่าการเรนเดอร์จะเร็วหรือช้าแค่ไหนก็ตาม physics engine ของ Unity จะ step ตามตัวจับเวลาคงที่นี้เสมอ ดังนั้นโค้ดที่แตะการเคลื่อนที่ของ Rigidbody ต้องอยู่ใน FixedUpdate ไม่ใช่ Update

ถ้าเขียนโค้ด physics ใน Update ปริมาณ "แรงดัน" ที่ใส่แต่ละครั้งจะขึ้นอยู่กับว่า Update เกิดขึ้นบ่อยแค่ไหนในวินาทีนั้น ๆ — สคริปต์เดียวกันเลยขยับวัตถุด้วยความเร็วจริงต่างกันในแต่ละเครื่อง แล้วอาจดูกระตุก ๆ ด้วย เขียนไว้ใน FixedUpdate จะทำให้ physics คงที่เหมือนกันทุกที่

รูปแบบที่ใช้กันบ่อย ๆ: อ่าน input ใน Update (จะได้ไม่พลาดการกดปุ่มเร็ว ๆ) แล้วใส่ให้ Rigidbody ใน FixedUpdate (physics จะได้ลื่นและไม่ขึ้นกับ frame rate):

using UnityEngine;

[RequireComponent(typeof(Rigidbody))]
public class PhysicsMover : MonoBehaviour
{
    public float speed = 6f;

    Rigidbody rb;
    Vector3 inputDir;     // cached between Update calls

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

    void Update()
    {
        // Read input every rendered frame so a quick tap is never missed.
        float h = Input.GetAxis("Horizontal");
        float v = Input.GetAxis("Vertical");
        inputDir = new Vector3(h, 0f, v);
    }

    void FixedUpdate()
    {
        // Apply it to the physics body on the fixed timer.
        Vector3 targetPos = rb.position + inputDir * speed * Time.fixedDeltaTime;
        rb.MovePosition(targetPos);
    }
}

Time.fixedDeltaTime คือขนาด step คงที่นั้น (0.02 โดย default) — คูณด้วยมันคือการแปลง "หน่วยต่อวินาที" ให้เป็น "หน่วยสำหรับ physics step นี้หนึ่งครั้ง" เหมือนที่ Time.deltaTime ทำกับ Update ใน 4.2 เป๊ะ rb.MovePosition ขยับ Rigidbody แบบถูกต้องตามหลักฟิสิกส์: มันยังชนกำแพงกับวัตถุอื่นระหว่างทางอยู่ ต่างจากการตั้งค่า transform.position ตรง ๆ ที่จะเทเลพอร์ตทะลุทุกอย่างไปเลย

AddForce คืออีกเครื่องมือหนึ่ง เหมาะกับของที่ควรรู้สึกมีน้ำหนักและ momentum (รถ, ลูกบอล, ragdoll) แทนที่จะควบคุมตรง ๆ แบบแม่นยำ:

void FixedUpdate()
{
    rb.AddForce(inputDir * accelForce);   // a push; velocity builds up over time
}

MovePosition กำหนดว่าวัตถุควรอยู่ตรงไหนตอนนี้เลย (ยังคำนึงถึงการชนอยู่) — เหมาะกับตัวละครแพลตฟอร์มที่ต้องควบคุมแม่นยำ AddForce ดันวัตถุแล้วปล่อยให้ momentum กับ mass จัดการที่เหลือ — เหมาะกับของที่ควรรู้สึกหนักหรือลื่นไถล บทที่ 10 (Physics for Games) จะพูดถึง character controller, ragdoll และการผสาน gameplay ลึกกว่านี้เยอะ หัวข้อนี้คือ 80% ที่ใช้บ่อยที่สุดในชีวิตประจำวันที่ต้องรู้ตอนนี้

6. Animation: state machine ของ Animator

Component Animator เล่น animation clip บน GameObject ว่ามันจะเล่นอะไร และสลับคลิปตอนไหน ถูกควบคุมโดย asset ที่ชื่อ Animator Controller — ระบบ animation ของ Unity มักถูกเรียกว่า Mecanim ตามชื่อภายในของระบบนี้ เราสร้าง Animator Controller ด้วยภาพ ผ่านหน้าต่าง Animator เป็น state machine: กราฟของ state (แต่ละอันมักถือ animation clip หนึ่งตัว เช่น "Idle" หรือ "Run") เชื่อมกันด้วย transition (ลูกศรที่บอกว่า "สลับไป state นี้เมื่อ...")

อ่านไดอะแกรมนี้เหมือน flowchart: ตัวละครเริ่มที่ Idle แต่ละ transition มี condition ที่เขียนโดยอิง Parameter — ค่าที่มีชื่ออยู่บน Animator คล้าย ๆ ตัวแปร เมื่อ Speed ขึ้นเกิน 0.1 transition Idle -> Walk จะทำงาน แล้วคลิป Walk ก็เริ่มเล่น กล่อง Any State พิเศษตรงที่ transition ของมันทำงานได้ไม่ว่าตอนนี้เราอยู่ state ไหน นี่คือเหตุผลที่ "Jump" มาขัดจังหวะ Idle, Walk หรือ Run ได้เหมือนกันหมด

parameter สี่ชนิดครอบคลุมเกือบทุกอย่าง:

• Float — ตัวเลข เช่น Speed ใช้กับเงื่อนไข threshold แบบ "Speed > 5"
• Bool — true/false เช่น IsGrounded ค่าจะคงอยู่จนกว่าเราจะเปลี่ยนมันเอง
• Int — เลขจำนวนเต็ม เช่น ตัวนับ AttackCombo
• Trigger — flag แบบใช้ครั้งเดียว เช่น Jump มันยิง transition ครั้งเดียวแล้ว รีเซ็ตตัวเองกลับเป็น false อัตโนมัติ — เหมาะมากกับ event แบบ "เกิดขึ้นครั้งนี้ครั้งเดียว" ต่างจาก Bool ที่เราต้องรีเซ็ตเองมือ

7. สั่ง animation จากโค้ด

เราสร้างกราฟใน Editor แต่สคริปต์ของเราตั้งค่า parameter ทุกเฟรม แล้ว state machine จะตอบสนองเอง นี่คือวิธีปกติในการเชื่อม gameplay เข้ากับ animation — เราแทบไม่เคยบอก Animator ว่า "เล่นคลิปนี้" ตรง ๆ เราบอกมันแค่ข้อเท็จจริงเกี่ยวกับโลก ("ความเร็วตอนนี้คือ 4.2") แล้วให้ transition เป็นคนตัดสินใจ

using UnityEngine;

[RequireComponent(typeof(Animator))]
public class AnimationDriver : MonoBehaviour
{
    Animator animator;

    void Awake() { animator = GetComponent<Animator>(); }

    void Update()
    {
        float h = Input.GetAxis("Horizontal");
        float v = Input.GetAxis("Vertical");
        float speed = new Vector2(h, v).magnitude;   // 0 when still, up to ~1 when moving

        animator.SetFloat("Speed", speed);            // feeds the Idle/Walk/Run thresholds
        animator.SetBool("IsGrounded", CheckGrounded());

        if (Input.GetButtonDown("Jump"))
            animator.SetTrigger("Jump");              // fires once, resets itself
    }

    bool CheckGrounded() { return true; }   // stand-in; a real project raycasts downward
}

ลอง trace ตาม state machine จากหัวข้อ 6: ผู้เล่นยืนนิ่ง Speed = 0 Animator อยู่ที่ Idle ผู้เล่นกด D — แต่ละ Update ตอนนี้คำนวณ speed ที่มากขึ้นเรื่อย ๆ สมมติมันขึ้นถึง 0.6 เพราะ 0.6 > 0.1 เงื่อนไข transition Idle -> Walk เป็นจริง แล้ว Animator ก็สลับไป Walk คลิปเดินก็เริ่มเล่น — เราไม่เคยเรียก "เล่นคลิป walk" ที่ไหนเลย เราแค่ตั้งค่า Speed เท่านั้น จากนั้นผู้เล่นกด Space: SetTrigger("Jump") ยิง transition Any State -> Jump ทันที ขัดจังหวะ Walk แล้ว trigger ก็เคลียร์ตัวเองเพื่อไม่ให้ยิงซ้ำในเฟรมถัดไป

ยังมีทางลัดตรง ๆ อีกทาง คือ animator.Play("StateName") ซึ่งกระโดดตรงไป state นั้นเลยโดยข้าม transition condition ทั้งหมด มันมีประโยชน์ตอนต้องการบังคับรีเซ็ต (เช่น สแนปกลับไป Idle ตอน cutscene จบ) แต่ถ้าใช้บ่อยเกินไปก็เสียจุดประสงค์ของการมี state machine ไป ส่วนใหญ่แล้วการตั้งค่า parameter แล้วปล่อยให้ transition ตัดสินใจคือสิ่งที่เราต้องการ

8. Audio: AudioSource กับ AudioClip

สองชิ้นส่วน และการแบ่งนี้ก็คล้ายกับที่รู้จากฝั่งกราฟิกแล้ว: AudioClip คือข้อมูลเสียงจริง ๆ (ไฟล์ที่เรา import เข้ามา เหมือน Texture ที่เป็นข้อมูลภาพที่ import เข้ามา) และ AudioSource คือ Component ที่เล่นคลิปออกไปในฉาก (เหมือน Renderer ที่แสดง Texture) ไม่มี AudioSource ก็ไม่มีเสียง — ต่อให้ตั้งค่าคลิปไว้แล้วก็ตาม

using UnityEngine;

public class AudioDemo : MonoBehaviour
{
    public AudioSource source;     // assigned in the Inspector
    public AudioClip jumpClip;
    public AudioClip musicClip;

    void Start()
    {
        // Background music: assign + loop + play, keeps playing across frames.
        source.clip = musicClip;
        source.loop = true;
        source.Play();
    }

    public void PlayJumpSound()
    {
        // A short one-off sound effect. PlayOneShot does NOT interrupt
        // whatever the AudioSource is already playing (the music keeps going).
        source.PlayOneShot(jumpClip);
    }
}

เรียก PlayJumpSound() จากที่เดียวกับที่เรียก animator.SetTrigger("Jump") ในหัวข้อ 7 แล้วเสียง effect กระโดดจะเล่นซ้อนทับเพลงโดยไม่ตัดเพลงทิ้งเลย นี่คือความต่างระหว่าง Play() (เข้าครอบครองคลิปหลักของ AudioSource แทนที่สิ่งที่กำลังเล่นอยู่) กับ PlayOneShot(clip) (เล่นเสียงเพิ่มซ้อนกับคลิปหลัก ยิงแล้วปล่อยผ่าน — เหมาะกับเสียงฝีเท้า, เสียงโดนตี และเสียงเก็บไอเทมที่ซ้อนทับกันได้)

เสียงแบบ 2D กับ 3D

AudioSource ทุกตัวมีสไลเดอร์ Spatial Blend ตั้งแต่ 0 ถึง 1:

• 0 = 2D ความดังเท่าเดิมไม่ว่า AudioSource จะอยู่ตรงไหนเทียบกับกล้อง เหมาะกับเพลง, เสียงคลิก UI, เสียงบรรยาย — เสียงที่ไม่ควรเบาลงแค่เพราะกล้อง pan ออกไป
• 1 = 3D ความดังและการ pan ซ้ายขวาขึ้นอยู่กับระยะและทิศทางของ AudioSource เทียบกับ AudioListener (component ที่มักอยู่บน Main Camera — คือ "หู" ของฉาก) เหมาะกับเสียงฝีเท้า, เสียงปืน, NPC พูดอยู่ใกล้ ๆ — เสียงที่ควรรู้สึกว่ามาจากจุดใดจุดหนึ่งในโลก

void Awake()
{
    source.spatialBlend = 1f;     // 0 = flat/2D, 1 = full 3D positional
    source.minDistance   = 2f;    // stays at full volume within this range
    source.maxDistance   = 20f;   // fades to silent past this range
}

AudioSource ของฝีเท้าหรือเสียงปืนมักอยู่บน GameObject ที่เป็นคนสร้างเสียงนั้น (ตำแหน่งของมันจะตามไปอัตโนมัติ) ตั้งเป็น 3D เต็ม เพลงกับเสียง UI มักอยู่บน manager object ที่ตำแหน่งคงที่ ตั้งเป็น 2D จะได้ไม่เบาลงเลย (บทที่ 13 Audio จะพูดถึง spatial audio, mixing และ middleware อย่าง Wwise/FMOD ที่สตูดิโอใหญ่ ๆ ใส่ทับ AudioSource สำเร็จรูปของ Unity อีกที)

9. UI: Canvas กับ element ของ UGUI

ระบบ UI คลาสสิกของ Unity เรียกว่า UGUI ("Unity GUI") — มันสร้างเมนูกับ HUD จาก GameObject ธรรมดา ๆ โมเดล GameObject/Component เดียวกับที่เจอใน 4.1 แค่มี component เฉพาะ UI element ของ UGUI ทุกตัวต้องอยู่ใต้ Canvas ซึ่งเป็น GameObject พิเศษที่เป็นราก (root) ของต้นไม้ UI หนึ่งต้น และเป็นคนตัดสินว่าจะวาดมันยังไง

UI element ทุกตัวอยู่บน RectTransform แทนที่จะเป็น Transform ธรรมดา — แนวคิดเดียวกัน (position, rotation, scale) บวก rect (width, height) กับ anchor ซึ่งบอกว่า element ควรเกาะติดมุมหรือขอบไหนเวลาจอ resize (health bar ที่ anchor ไว้มุมบนซ้ายจะอยู่มุมบนซ้ายทั้งบนมือถือและบนจอมอนิเตอร์ แทนที่จะเลื่อนหนี)

Render Mode ของ Canvas เป็นคนตัดสินว่า UI จะอยู่ตรงไหนในพื้นที่ 3D จริง ๆ:

• Screen Space - Overlay — วาดทับทุกอย่างตรง ๆ ไม่สนกล้องเลย เป็นตัวเลือก default สำหรับ HUD หรือเมนู
• Screen Space - Camera — หน้าตาเกาะจอเหมือนเดิม แต่เรนเดอร์เหมือนเป็นระนาบแบนอยู่ห่างจากกล้องตัวใดตัวหนึ่งในระยะคงที่ มีประโยชน์เวลาต้องการให้ post-processing (blur, color grading) มีผลกับ UI ด้วย
• World Space — Canvas กลายเป็นวัตถุ ใน ฉาก 3D เหมือน health bar ลอยอยู่เหนือหัวศัตรู หรือป้ายบนกำแพง มันเป็นไปตาม perspective และถูกวัตถุอื่นบังได้

สาม element ครอบคลุม UI แรก ๆ ส่วนใหญ่: Image (สี่เหลี่ยมที่โชว์ sprite หรือสีล้วน — แถบเติมของ health bar, ไอคอน, พื้นหลัง panel), Text (วาด string — คะแนน, บทพูด, label; โปรเจกต์ส่วนใหญ่ตอนนี้ใช้เวอร์ชัน TextMeshPro ที่ดีกว่า มักเขียนว่า TMP_Text ซึ่งให้การเรนเดอร์ที่คมกว่าและจัดฟอร์แมตได้เยอะกว่า) และ Button (Image บวกการตรวจจับคลิก อธิบายต่อในหัวข้อถัดไป)

10. ผูกปุ่ม (Button) เข้ากับโค้ด

Component Button จะยิง UnityEvent ชื่อ onClick ทุกครั้งที่มันถูกกดแล้วปล่อยขณะเมาส์/นิ้วยังอยู่ในขอบเขตของมัน มีสองวิธีเชื่อม event นั้นเข้ากับโค้ดเรา และทั้งคู่จบลงที่การเรียก method เดียวกัน:

using UnityEngine;
using UnityEngine.UI;

public class HealthUI : MonoBehaviour
{
    public Button healUpButton;
    public Image healthFillImage;   // Image type set to "Filled" in the Inspector

    int health = 60;
    const int maxHealth = 100;

    void Start()
    {
        healUpButton.onClick.AddListener(OnHealUpClicked);   // Way 2, wired in code
        RefreshBar();
    }

    void OnHealUpClicked()
    {
        health = Mathf.Min(health + 20, maxHealth);
        Debug.Log($"Button clicked! Health: {health}");
        RefreshBar();
    }

    void RefreshBar()
    {
        healthFillImage.fillAmount = (float)health / maxHealth;   // 0..1
    }
}

ลอง trace: health เริ่มที่ 60 ดังนั้น RefreshBar ตั้งค่า fillAmount เป็น 0.6 — แถบโชว์เต็ม 60% ผู้เล่นกดปุ่มหนึ่งครั้ง OnHealUpClicked ทำงาน health กลายเป็น 80 Console พิมพ์ Button clicked! Health: 80 และ fillAmount อัปเดตเป็น 0.8 กดอีกสองครั้งแล้ว health จะถูกจำกัดไว้ที่ maxHealth = 100 โดย Mathf.Min มันเลยหยุดโตแทนที่จะล้นแถบไป

ถ้าผูกผ่าน Inspector แทน (วิธีที่ 1) ไม่ต้องเขียนโค้ดสักบรรทัดสำหรับการเชื่อมนี้เลย — แค่ลาก GameObject ของ HealthUI ใส่ลิสต์ On Click () ของปุ่ม แล้วเลือก OnHealUpClicked จาก dropdown ทั้งสองวิธีเรียก method เดียวกันเป๊ะ ๆ เลือกวิธี Inspector สำหรับปุ่มที่มีอยู่แล้วในฉาก และเลือกวิธีโค้ดสำหรับปุ่มที่สคริปต์เราสร้างหรือหาเจอตอนรัน

11. โน้ตเรื่อง render pipeline: Built-in, URP, HDRP

ทุกอย่างข้างบน — physics, animation, audio, UI — ทำงานเหมือนเดิมไม่ว่าฉากจะถูกวาดลงจอยังไงจริง ๆ งานวาดนั้นเป็นหน้าที่ของ render pipeline: โค้ดที่แปลง GameObject, material และแสงในฉากให้กลายเป็นพิกเซลทุกเฟรม Unity มีให้เลือกสามตัว เลือกครั้งเดียวต่อโปรเจกต์:

• Built-in Render Pipeline — pipeline ดั้งเดิม รุ่นเก่า ยืดหยุ่นแต่ล้าสมัยแล้ว และ Unity กำลังค่อย ๆ ย้ายโปรเจกต์ใหม่ออกจากมัน
• URP (Universal Render Pipeline) — สร้างมาเพื่อ performance และการเข้าถึงที่กว้าง: pipeline เดียวที่ scale ได้ตั้งแต่มือถือไปจนถึงคอนโซลและ PC มี lighting feature น้อยกว่าและถูกกว่า HDRP แต่รันได้ดีบนฮาร์ดแวร์ที่ HDRP แตะไม่ได้เลย
• HDRP (High Definition Render Pipeline) — สร้างมาเพื่อ คุณภาพภาพระดับสูง: แสงสมจริง, เงาขั้นสูง, volumetrics มันเล็ง GPU ของ PC และคอนโซล และ ไม่ รันบนฮาร์ดแวร์มือถือเลย

นี่คือเหตุผลว่าทำไมเป้าหมายที่พูดถึงในบทนำของหลักสูตรนี้ — เกมสไตล์ HoYoverse (Genshin Impact, Honkai: Star Rail, Zenless Zone Zero) — ชี้ตรงไปที่ URP เกมพวกนี้ต้องรันได้ทั้งบนมือถือระดับกลางและ PC/คอนโซลจากโปรเจกต์เดียวกัน แล้ว HDRP ก็ไม่ใช่ตัวเลือกบน GPU มือถือเลย เป้าหมายการออกแบบของ URP ทั้งหมดคือการครอบคลุมแบบนั้นเป๊ะ ๆ: performance ที่พอรับได้และปรับแต่งได้ ครอบคลุมฮาร์ดแวร์หลากหลายมาก รวมมือถือด้วย ถ้าเป้าหมายเราคือเกมสไตล์ stylized ที่ต้องเข้าถึงมือถือ ให้ตั้ง default เป็น URP ไว้ก่อน ยกเว้นมีเหตุผลเฉพาะที่พิสูจน์แล้วว่าไม่ควร

การเลือก pipeline เป็นการตั้งค่าระดับโปรเจกต์ ไม่ใช่สิ่งที่เราเขียนสคริปต์ตรงนี้ — หัวข้อนี้แค่อยากให้การเลือกมันสมเหตุสมผล เรื่อง shader, lighting และลุค "toon" แบบ stylized ที่ HoYoverse ขึ้นชื่อมีบทเฉพาะทีหลัง (บทที่ 7 Graphics & Rendering โดยเฉพาะ 7.4 Stylized / Toon / NPR) ตอนนี้สิ่งเดียวที่สำคัญคือ: โปรเจกต์ใหม่ที่เล็งมือถือหรือการเข้าถึงกว้าง -> URP

12. Glossary

• Input axis — ค่าที่มีชื่อและถูก smooth ตั้งแต่ -1 ถึง 1 (เช่น "Horizontal") ที่นิยามไว้ใน Input Manager
• Input Action — ในแพ็กเกจ Input System รุ่นใหม่ คือ action ที่มีชื่อ ("Move", "Jump") ผูกกับ control ทางกายภาพหนึ่งอย่างหรือมากกว่า
• Rigidbody — Component ที่ส่งมอบ GameObject ให้ physics engine: mass, gravity, velocity, force
• Collider — Component ที่กำหนดรูปทรงสำหรับการสัมผัสทางฟิสิกส์ (Box/Sphere/Capsule/Mesh)
• Trigger — Collider ที่ติ๊ก "Is Trigger" ไว้: ตรวจจับการซ้อนทับได้แต่ไม่บล็อกทางกายภาพ
• OnCollisionEnter/Stay/Exit — callback ที่ยิงจากการสัมผัสแบบ solid (ไม่ใช่ trigger)
• OnTriggerEnter/Stay/Exit — callback ที่ยิงจากการสัมผัสแบบ trigger
• FixedUpdate — รันตามตัวจับเวลาคงที่ (default 50 ครั้งต่อวินาที) ที่เดียวที่ปลอดภัยสำหรับขยับ Rigidbody
• Animator — Component ที่เล่น animation clip และรัน state machine (Mecanim)
• Animator Controller — asset ที่เก็บกราฟ state machine: state, transition, parameter
• State / Transition — state มักถือคลิปหนึ่งตัว; transition คือลูกศรที่มี condition สลับ state
• Parameter (Float/Bool/Int/Trigger) — ค่าที่มีชื่อบน Animator ที่ condition ของ transition อ่านค่า
• AudioClip — ข้อมูลเสียงที่ import เข้ามา (ไฟล์)
• AudioSource — Component ที่เล่น AudioClip ออกไปในฉาก
• AudioListener — "หู" ของฉาก มักอยู่บน Main Camera
• Spatial Blend — 0 = 2D (ความดังเท่าเดิมทุกที่), 1 = 3D (ความดัง/panning ขึ้นกับระยะ)
• Canvas — GameObject รากของต้นไม้ UI แบบ UGUI; ตัดสิน Render Mode
• RectTransform — เวอร์ชัน UI ของ Transform: เพิ่ม width/height กับ anchor
• UGUI — ระบบ UI ของ Unity ที่อิง GameObject (Canvas, Image, Text, Button...)
• onClick — UnityEvent ที่ Button ยิงตอนถูกคลิก ผูกได้ผ่าน Inspector หรือด้วย AddListener
• Render pipeline — โค้ดที่แปลงฉากให้เป็นพิกเซล; Built-in, URP หรือ HDRP เลือกต่อโปรเจกต์
• URP / HDRP — Universal (scale ลงมือถือได้ เบากว่า) กับ High Definition (PC/คอนโซลเท่านั้น คุณภาพสูงสุด) render pipeline

13. แบบฝึกหัด

void OnCollisionEnter(Collision collision)
{
    Debug.Log("collected " + collision.gameObject.name);
}

void OnTriggerEnter(Collider other)
{
    Debug.Log("collected " + other.gameObject.name);
}

void Update()
{
    float h = Input.GetAxis("Horizontal");
    transform.position += new Vector3(h, 0, 0) * speed;
}

Rigidbody rb;
Vector3 inputDir;

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

void Update()
{
    float h = Input.GetAxis("Horizontal");
    inputDir = new Vector3(h, 0, 0);
}

void FixedUpdate()
{
    rb.MovePosition(rb.position + inputDir * speed * Time.fixedDeltaTime);
}

animator.SetFloat("Speed", 3f);
animator.SetFloat("Speed", 6f);
animator.SetTrigger("Jump");
animator.SetFloat("Speed", 0f);

นั่นคือระบบทั้ง 5 ที่ครอบคลุมในบทนี้ Input บอกสคริปต์เราว่าผู้เล่นต้องการอะไร; Physics (Rigidbody, Collider, FixedUpdate) แปลงมันเป็นการเคลื่อนที่และการสัมผัสที่น่าเชื่อ; Animation (state machine ของ Animator) โชว์การเคลื่อนไหวนั้นบนจอ; Audio ให้เสียงกับมัน; UI รายงานผลลัพธ์กลับไปให้ผู้เล่น โน้ตเรื่อง render pipeline คือการตัดสินใจระดับโปรเจกต์หนึ่งเดียวที่อยู่ใต้ทุกอย่างนี้: เลือก URP สำหรับอะไรก็ตามที่ต้องเข้าถึงมือถือ — ซึ่งตรงกับเป้าหมายสไตล์ HoYoverse ที่หลักสูตรนี้เล็งไว้เป๊ะ ๆ