13.3 ดนตรี Adaptive และ Interactive

ตลอดคอร์สที่ผ่านมา เพลงในเกมของเรามีความหมายแค่อย่างเดียว คือกด play ให้ AudioClip ตั้ง loop เป็น true แล้วปล่อยให้มันเล่นคลออยู่ใต้เกมไปเรื่อยๆ วิธีนี้โอเคสำหรับหน้า title screen แต่พังทันทีที่ตัวเกมเองไม่สามารถคาดเดาได้ — การต่อสู้ที่อาจใช้เวลาแค่ห้าวินาทีหรือยาวถึงห้านาที บอสที่อาจโผล่มาทันทีที่ผู้เล่นเดินผ่านประตู หรือผู้เล่นที่วิ่งหนีจากการต่อสู้แล้วเดินกลับไปกลับมาสามรอบก่อนจะสู้จริง ไม่มีคอมโพเซอร์คนไหนเขียนเพลงให้ตรงกับเหตุการณ์ที่ยังไม่เกิดขึ้นได้

บทนี้พูดถึง adaptive music (เรียกอีกชื่อว่า interactive music) คือเพลงที่ถูกออกแบบมาตั้งแต่ต้นให้เปลี่ยนแปลงตามสิ่งที่เกิดขึ้นในเกม แทนที่จะเล่นตาม arrangement (การเรียบเรียง) เดียวที่ตายตัว มีสองเทคนิคหลักที่ทำงานส่วนใหญ่จริงๆ คือ horizontal re-sequencing (การจัดลำดับใหม่แนวนอน) กับ vertical layering (การซ้อนชั้นแนวตั้ง) บวกกับอีกสองแนวคิดเสริมคือ stinger (เสียงแทรกสั้นๆ) และ quantized transition (การเปลี่ยนที่ล็อกจังหวะ) ซึ่งทำให้ทั้งสองเทคนิคฟังดูตั้งใจ ไม่ใช่ฟังดูพัง พอจบบทนี้คุณจะได้สร้าง beat-quantized segment switcher กับ layered-intensity mixer ด้วย C# และจะเข้าใจว่า audio middleware อย่าง Wwise หรือ FMOD ทำอะไรให้คุณบ้าง เวลาสตูดิโอมีงบให้ใช้เครื่องมือพวกนี้

1. ทำไมเพลงตายตัวถึงพังในเกม

คอมโพเซอร์หนังรู้เป๊ะว่าฮีโร่จะชักดาบตอนเฟรมไหน เขาเขียนเพลงหกสิบวินาทีให้ตรงกับจังหวะนั้นเป๊ะๆ ได้ แต่คอมโพเซอร์เกมไม่มีความหรูหราแบบนั้น — ผู้เล่นเป็นคนตัดสินใจว่าจะชักดาบตอนไหน อาจจะชักตอนกำลังฟัง dialogue อยู่ ตอนกระโดดกลางอากาศ หรือไม่ชักเลยอีกสิบนาที ระบบไหนก็ตามที่แค่เล่นเพลงตายตัวแล้วสลับไปอีกเพลงตายตัวทันทีที่มีอะไรเกิดขึ้น เกือบทุกครั้งจะสลับกลางประโยคเพลงพอดี

using UnityEngine;

public class NaiveMusicSwitcher : MonoBehaviour
{
    public AudioSource musicSource;
    public AudioClip exploreClip;
    public AudioClip combatClip;

    public void EnterCombat()
    {
        musicSource.clip = combatClip;
        musicSource.Play();   // starts immediately, wherever exploreClip happened to be
    }
}

ในโค้ดนี้ musicSource คือ AudioSource หนึ่งตัวที่ loop exploreClip อยู่ พอ EnterCombat() ถูกเรียก ไม่ว่า exploreClip กำลังเล่นอะไรอยู่ก็จะถูกตัดทิ้งทันที — กลางโน้ต กลางดรัมฟิล ตรงไหนก็ได้ที่จังหวะของผู้เล่นดันไปตกพอดี — แล้ว combatClip ก็เริ่มใหม่จาก beat หนึ่งของตัวเอง ด้วยจังหวะที่ต่างไปคนละเรื่องเลยระหว่างที่หูกำลังปรับตัวตาม

นี่คือปัญหาทั้งหมดที่บทนี้จะแก้ให้ ทุกอย่างต่อจากนี้จริงๆ แล้วคือคำถามเดียวที่ถูกถามในหลายรูปแบบ: จะเปลี่ยนสิ่งที่ผู้เล่นได้ยินยังไงให้มันไม่ฟังดูเหมือนความผิดพลาด

2. สองคำตอบ: horizontal re-sequencing กับ vertical layering

สองเทคนิคนี้ ถูกใช้แทบทุกเกมที่มี combat แบบ dynamic (รวมถึงเกม HoYoverse อย่าง Genshin Impact กับ Honkai: Star Rail) แก้ปัญหาด้วยวิธีต่างกัน:

• Horizontal re-sequencing — เพลงถูกเขียนแยกเป็น segment (ท่อนเพลง) ต่างๆ (segment สำรวจ, segment ต่อสู้, segment บอส) แล้วเกมก็เล่นทีละท่อน โดยเลือกว่าท่อนไหนจะเล่นต่อ และเมื่อไหร่ที่อนุญาตให้สลับได้ เรียกว่า "horizontal" (แนวนอน) เพราะคุณกำลังเลื่อนไปตาม timeline เลือกว่าเพลงชิ้นไหนจะเล่นต่อไป
• Vertical layering (เรียกอีกชื่อว่า stems) — เพลงเป็นชิ้นเดียวที่เล่นต่อเนื่อง แต่ถูกแยกเป็น track ของแต่ละเครื่องดนตรี (กลอง เบส สาย เมโลดี้) ที่เล่นพร้อมกันตลอดเวลา แล้วเกมก็ผสมระดับเสียงของแต่ละ track ตามความเข้มข้นของสถานการณ์ตอนนั้น เรียกว่า "vertical" (แนวตั้ง) เพราะในทุกๆ ขณะคุณกำลังซ้อน layer ทับกันอยู่

ไม่มีเทคนิคไหน "ดีกว่า" — มันแก้ปัญหาคนละแบบ Horizontal re-sequencing เหมาะกับตอนที่ตัวเพลงเองต้องเปลี่ยนเป็นคนละชิ้นจริงๆ (เพลงหมู่บ้านไม่มีอะไรเหมือนเพลงดันเจี้ยนเลย) ส่วน vertical layering เหมาะกับตอนที่เพลงยังเป็นไอเดียเดียวกันอยู่ แค่เข้มข้นมากหรือน้อยกว่า (เพลงบอสตัวเดิม เบาบางตอน HP ยังเยอะ เต็มอิ่มตอน HP ตก) เกมจริงๆ ส่วนใหญ่ใช้ทั้งสองอย่างพร้อมกัน คือใช้ horizontal re-sequencing เพื่อย้ายระหว่าง state ใหญ่ๆ อย่างสำรวจ/ต่อสู้/บอส แล้วใช้ vertical layering ข้างในแต่ละ state เพื่อตอบสนองต่อการเปลี่ยนแปลงเล็กๆ อย่างเหลือศัตรูอีกกี่ตัว

3. เวลาทางดนตรี: beat, bar, และ BPM

ทั้งสองเทคนิคขึ้นอยู่กับไอเดียเดียวกัน คือการรู้ตำแหน่งที่แน่ชัดว่าเรากำลังอยู่ตรงไหนของเพลง วัดเป็นเวลาทางดนตรีแทนที่จะเป็นวินาทีเฉยๆ มีสามคำศัพท์ที่ใช้ตลอดบทนี้:

• BPM (beats per minute) — tempo (จังหวะ) คือมี beat กี่ครั้งในหนึ่งนาทีของเพลง
• Beat — จังหวะเคาะหนึ่งครั้งของเพลง สิ่งที่คุณเคาะเท้าตาม
• Bar (เรียกอีกชื่อว่า measure) — กลุ่มของ beat ที่ตายตัว ที่พบบ่อยที่สุดคือ 4 beat ต่อ bar ใน "4/4 time" (time signature ที่ไม่มีอะไรซับซ้อนไปกว่า "นับหนึ่งถึงสี่แล้ววนใหม่") bar มักเป็นชิ้นส่วนเพลงที่เล็กที่สุดที่ยังฟังดูเป็นไอเดียดนตรีที่สมบูรณ์ และ segment ต่างๆ มักถูกเขียนเป็นจำนวนเท่าของ bar เสมอ

การแปลง BPM เป็นวินาทีจริงคือเลขคณิตที่ใช้ในทุกๆ ส่วนที่เหลือของบทนี้:

using UnityEngine;

public class TempoMath : MonoBehaviour
{
    public float bpm = 120f;
    public int beatsPerBar = 4;

    void Start()
    {
        double secondsPerBeat = 60.0 / bpm;
        double secondsPerBar = secondsPerBeat * beatsPerBar;
        Debug.Log("One beat = " + secondsPerBeat + "s, one bar = " + secondsPerBar + "s");
    }
}

One beat = 0.5s, one bar = 2s

ที่ 120 BPM หนึ่ง beat จะเท่ากับครึ่งวินาทีพอดี และหนึ่ง bar (4 beat) จะเท่ากับ 2 วินาทีพอดี นี่เป็นส่วนหนึ่งที่ทำให้ 120 BPM เป็น tempo ที่คอมโพเซอร์เกมนิยมเลือกใช้ — เพราะมันทำให้เลข seconds-per-bar ออกมาเป็นตัวเลขที่ลงตัวง่ายๆ

อีกเรื่องหนึ่ง: Time.time ของ Unity ที่อิงกับเฟรมไม่แม่นยำพอสำหรับงานนี้ Time.time อัปเดตแค่ครั้งเดียวต่อเฟรมที่ถูก render และเวลาต่อเฟรมนั้นก็สั่นได้ — เฟรมหนึ่งอาจใช้เวลา 16ms อีกเฟรมอาจ 19ms ฮาร์ดแวร์เสียงมี clock ของตัวเองที่นิ่งกว่ามาก ซึ่ง Unity เปิดให้ใช้ผ่าน AudioSettings.dspTime (เป็น double ที่บอกเวลาปัจจุบันของระบบเสียงเป็นวินาที ไม่เกี่ยวกับ frame rate) ทุกการคำนวณเรื่อง scheduling ในบทนี้ใช้ dspTime ไม่ใช้ Time.time เพราะแค่การเหลื่อมเล็กน้อยของเฟรมก็ทำให้ได้ยินว่าการเปลี่ยนเพลงมันเบี้ยวไปจากจังหวะนิดหน่อยแล้ว

4. Horizontal re-sequencing: สลับ segment ตาม game state

Horizontal re-sequencing เริ่มจากการแยกเพลงออกเป็น segment — audio clip แยกกัน หนึ่งชิ้นต่อหนึ่ง game state ทุกชิ้นเขียนที่ BPM เดียวกันและความยาว bar เดียวกัน เพื่อให้ segment ไหนก็ตามสามารถเล่นต่อจากอีกอันได้ การตั้งค่าทั่วไปคือมี segment สลับหลายแบบต่อ state (เพื่อไม่ให้ผู้เล่นติดอยู่กับ Explore clip อันเดิมวนไปวนมา — รายละเอียดอยู่ใน section 11) ผูกกับ state graph เล็กๆ

public enum MusicState { Explore, Combat, Boss }

[System.Serializable]
public class MusicStateSegments
{
    public MusicState state;
    public AudioClip[] variants;   // several clips per state, same tempo and bar length
}

มีสองเรื่องที่สำคัญเกี่ยวกับ graph นี้ อย่างแรก state มักจะแยกกันเด็ดขาด — เกมอยู่ใน state ใด state หนึ่งจาก Explore, Combat, หรือ Boss ครั้งละหนึ่งเดียวเสมอ ไม่มีการผสมสอง state (นั่นเป็นหน้าที่ของ vertical layering ที่อยู่ข้างใน state เดียว) อย่างที่สอง และนี่คือประเด็นหลักของ section ที่เหลือ: ทุกลูกศรถูก quantize ทั้งหมด คำขอให้ย้ายจาก Explore ไป Combat จะไม่ตัดทันทีที่ถูกขอ — มันจะถูกเข้าคิวไว้ แล้วสลับจริงๆ ก็ต่อเมื่อถึง bar line ถัดไปเท่านั้น กฎข้อเดียวนี้แหละที่ทำให้ horizontal re-sequencing ไม่ฟังดูเหมือน naive switcher ใน section 1

5. Quantized transition: รอ bar line

Quantization ในความหมายทางดนตรี คือการดันเหตุการณ์หนึ่งให้ไปตกที่จุดที่ใกล้ที่สุดบน grid ทางดนตรี — ปกติคือ beat หรือ bar ที่ใกล้ที่สุด — แทนที่จะปล่อยให้มันเกิดขึ้นตรงเวลาที่ถูกขอพอดีซึ่งเป็นเวลาสุ่มๆ Quantized transition คือการสลับ segment ที่ถูกดันไปให้ตรงกับ bar line แบบนี้

เหตุผลชัดเจนขึ้นทันทีที่เห็น diagram: ทุก segment ที่ใช้ BPM เดียวกันและความยาว bar เดียวกัน หมายความว่า beat หนึ่งของ bar ใดๆ ใน Combat จะตรงจังหวะกับ beat หนึ่งของ bar ใดๆ ใน Explore ถ้าการสลับเกิดขึ้นตรง bar line เสมอ การเปลี่ยนก็จะฟังดูเหมือนคอมโพเซอร์ตั้งใจเขียนไว้แบบนั้น — เพราะจริงๆ แล้วเขาก็ตั้งใจ: เขาเขียนทุก segment ให้เล่นต่อจาก segment ไหนก็ได้อย่างสมูท ตราบใดที่การสลับเคารพ beat grid

มันมีต้นทุนจริงอยู่: การ quantize เพิ่ม latency (ความหน่วง) ที่ 120 BPM กับ bar 4 beat คำขอที่มาถึงตอนที่ bar line เพิ่งเริ่มไปหมาดๆ ต้องรอเกือบเต็ม 2 วินาทีกว่าจะถึง bar line ถัดไป สำหรับเพลง ความหน่วงเล็กๆ นี้คุ้มค่า — การเปลี่ยนที่ช้าไป 2 วินาทีแต่สะอาด ฟังดูดีกว่าการเปลี่ยนทันทีแต่กระโดดชัดเจนมาก Section 9 จะกลับมาพูดถึง trade-off นี้อีกครั้งสำหรับ stinger ซึ่งการเลือกตรงข้ามกันมักจะถูกต้องกว่า

6. สร้างจริง: beat-quantized transition scheduler

การเปลี่ยน diagram ของ section 5 ให้เป็นโค้ดต้องใช้ Unity feature สองอย่าง: AudioSource.PlayScheduled(double dspTime) เริ่มเล่น clip ที่จุดเวลาที่แน่นอนในอนาคตบน audio clock แทนที่จะเป็น "เร็วที่สุดเท่าที่จะทำได้" และ AudioSource.SetScheduledEndTime(double dspTime) หยุด clip ที่กำลังเล่นอยู่ที่จุดเวลาที่แน่นอนในอนาคต ทั้งสองใช้หน่วย dspTime เดียวกับ AudioSettings.dspTime ซึ่งนี่แหละที่ทำให้มันตรงกันเป๊ะ

using UnityEngine;

// Horizontal re-sequencer: only one segment plays at a time, but a
// requested switch always waits for the next bar line before it happens.
public class HorizontalMusicPlayer : MonoBehaviour
{
    public AudioSource activeSource;    // currently playing segment
    public AudioSource standbySource;   // holds the next segment, cued up in advance

    public float bpm = 120f;
    public int beatsPerBar = 4;

    private double segmentStartDsp;     // dspTime the active segment's beat 1 landed on
    private AudioClip queuedClip;
    private bool hasQueuedClip = false;

    public void PlayFirstSegment(AudioClip clip)
    {
        segmentStartDsp = AudioSettings.dspTime + 0.1;   // small safety offset
        activeSource.clip = clip;
        activeSource.PlayScheduled(segmentStartDsp);
    }

    // called by gameplay code: "switch to this segment, whenever the beat allows it"
    public void RequestSegment(AudioClip clip)
    {
        queuedClip = clip;
        hasQueuedClip = true;
    }

    void Update()
    {
        if (!hasQueuedClip) return;

        double secondsPerBeat = 60.0 / bpm;
        double secondsPerBar = secondsPerBeat * beatsPerBar;

        double now = AudioSettings.dspTime;
        double elapsed = now - segmentStartDsp;
        double barsSoFar = System.Math.Ceiling(elapsed / secondsPerBar);
        double nextBarDsp = segmentStartDsp + barsSoFar * secondsPerBar;

        standbySource.clip = queuedClip;
        standbySource.PlayScheduled(nextBarDsp);
        activeSource.SetScheduledEndTime(nextBarDsp);

        Debug.Log("Queued switch to " + queuedClip.name + " at dsp time " + nextBarDsp
                   + " (in " + (nextBarDsp - now).ToString("F2") + "s)");

        AudioSource temp = activeSource;   // swap roles for the next request
        activeSource = standbySource;
        standbySource = temp;
        segmentStartDsp = nextBarDsp;

        hasQueuedClip = false;
    }
}

activeSource กับ standbySource เป็น AudioSource สองตัวแยกกันที่ผลัดกันสวมบทบาทเดียวกัน — ไม่มีวันเล่นพร้อมกันสองตัว แต่พร้อมส่งไม้ต่อได้เสมอ ต้องใช้สองตัว ไม่ใช่ตัวเดียว เพราะคุณเปลี่ยน clip ของ source ที่กำลังเล่นอยู่กลางคันโดยไม่หยุดมันก่อนไม่ได้อย่างปลอดภัย segment ที่กำลังจะมาต้องถูกเตรียมไว้ล่วงหน้าบน source ตัวที่สอง กำหนดให้เริ่มตรงจุดที่ source ตัวเดิมถูกกำหนดให้จบพอดี

RequestSegment แค่บันทึกว่า clip ไหนถูกขอ แล้วตั้ง flag ไว้ — มันไม่คำนวณอะไรเองเลย เพราะคำขอสามารถมาถึงตอนไหนก็ได้แบบสุ่มๆ และไม่ควรบล็อกอะไรทั้งนั้น งานจริงเกิดขึ้นตอน Update() รันครั้งถัดไป: elapsed คือระยะเวลาที่ segment ที่กำลังเล่นอยู่เล่นไปแล้วกี่วินาที การหารด้วย secondsPerBar แล้วปัดขึ้นด้วย Math.Ceiling จะหาว่าต้องผ่านไปกี่ bar เต็มๆ ก่อนจะถึง bar line ที่ตรงกับหรือหลังจากตอนนี้ การคูณกลับด้วย secondsPerBar แล้วบวกกับ segmentStartDsp จะได้ dspTime ที่แน่นอนของ bar line นั้น

ลอง trace ด้วย bpm = 120, beatsPerBar = 4 (ดังนั้น secondsPerBar = 2.0) segment ที่เริ่มที่ segmentStartDsp = 10.0 และ RequestSegment ถูกเรียกตอนที่ Update() รันพอดีที่ dspTime = 11.3:

Queued switch to CombatA at dsp time 12 (in 0.70s)

elapsed ออกมาเป็น 1.3 วินาที เข้าไปใน bar ยาว 2 วินาที (bar หนึ่งอยู่ระหว่าง dsp 10.0 ถึง 12.0) Math.Ceiling(1.3 / 2.0) ปัด 0.65 ขึ้นเป็น 1 หมายความว่า "รอ bar boundary อีกอันหนึ่ง" ซึ่งตกที่ 10.0 + 1 * 2.0 = 12.0 — bar line ถัดไปพอดี 0.7 วินาทีหลังจากคำขอมาถึง ถ้าคำขอมาถึงตอน dsp 11.9 แทน ซึ่งห่างจาก bar line เดียวกันแค่ 0.1 วินาที การรอก็จะเหลือแค่ 0.1 วินาทีแทนที่จะเกือบเต็ม bar — ความยาวของการรอขึ้นอยู่กับว่าคำขอมาถึงใกล้ bar line ถัดไปแค่ไหนล้วนๆ ไม่มีทางนานเกินหนึ่ง bar เต็ม

7. Vertical layering (stems): loop เดิม แต่มิกซ์ต่างกัน

Vertical layering เริ่มจากแนวคิดที่ต่างออกไป: แทนที่จะมีเพลงหลายชิ้นแยกกัน มันมีเพลงชิ้นเดียวที่เล่นต่อเนื่อง ถูก export ออกมาจาก session ของคอมโพเซอร์เป็น stem หลายชิ้น (ไฟล์เสียงแยกสำหรับแต่ละกลุ่มเครื่องดนตรี — กลอง เบส สาย/pad เมโลดี้ — ทุกไฟล์มีความยาวเท่ากันเป๊ะ tempo เดียวกันเป๊ะ ตั้งใจให้เล่นพร้อมกันทั้งหมด) ในทุกๆ ขณะ ทุก stem กำลังเล่นอยู่ สิ่งที่เปลี่ยนคือแต่ละอันดังแค่ไหน

กฎที่สำคัญที่สุดข้อเดียวของ vertical layering คือ: ห้ามหยุดหรือเริ่ม layer ใหม่เด็ดขาดหลังจากเพลงเริ่มไปแล้ว AudioSource ทั้งสี่ตัวเริ่มพร้อมกัน ในจังหวะเดียวกัน แล้วก็เล่นต่อเนื่องตลอดเวลาที่ผู้เล่นอยู่ใน state นั้น — บางทีนานเป็นนาทีๆ มีแค่ volume เท่านั้นที่เปลี่ยน สิ่งนี้รับประกันว่าทั้งสี่ layer จะไม่มีวันเคลื่อนออกจากกันทางจังหวะ เพราะในมุมมองของ audio engine มันไม่ใช่เพลงสี่ชิ้นแยกกันที่ถูกประสานเข้าด้วยกัน — มันคือเพลงชิ้นเดียวสี่สำเนา ที่อยู่ตำแหน่งการเล่นเดียวกันเป๊ะเสมอ แค่ถูกมิกซ์ด้วยความดังต่างกัน

เทียบกับ horizontal re-sequencing ตรงๆ: horizontal เปลี่ยน เมโลดี้ไหน ที่ผู้เล่นได้ยิน (Explore กับ Combat เป็นไอเดียดนตรีคนละอันกัน) ส่วน vertical เปลี่ยน เท่าไหร่ ของไอเดียดนตรีชิ้นเดียวที่ผู้เล่นได้ยิน (เพลงบอสตัวเดิม บางเบาตอนแรก เต็มดังตอนที่การต่อสู้ทวีความรุนแรง) ค่า float เดียว — ค่า intensity ตั้งแต่ 0 ถึง 1 — ก็มักจะพอสำหรับขับเคลื่อนมันแล้ว

8. สร้างจริง: layered-intensity mixer

using UnityEngine;

// All four layers share ONE clip length and ONE start time. This code
// never starts or stops a layer -- it only changes volume, so the
// layers can never drift out of sync with each other.
public class VerticalMusicMixer : MonoBehaviour
{
    public AudioSource drums;
    public AudioSource bass;
    public AudioSource strings;
    public AudioSource melody;

    [Range(0f, 1f)] public float intensity = 0f;
    public float fadeSpeed = 1.5f;   // volume units per second

    void Start()
    {
        double startDsp = AudioSettings.dspTime + 0.1;

        drums.volume = 0f;
        bass.volume = 0f;
        strings.volume = 0.3f;
        melody.volume = 1f;

        drums.PlayScheduled(startDsp);
        bass.PlayScheduled(startDsp);
        strings.PlayScheduled(startDsp);
        melody.PlayScheduled(startDsp);
    }

    void Update()
    {
        float drumsTarget   = intensity >= 0.6f  ? 1f : 0f;
        float bassTarget    = intensity >= 0.35f ? 1f : 0f;
        float stringsTarget = Mathf.Lerp(0.3f, 0.7f, intensity);
        float melodyTarget  = 1f;   // melody is always present, at full volume

        drums.volume   = Mathf.MoveTowards(drums.volume, drumsTarget, fadeSpeed * Time.deltaTime);
        bass.volume    = Mathf.MoveTowards(bass.volume, bassTarget, fadeSpeed * Time.deltaTime);
        strings.volume = Mathf.MoveTowards(strings.volume, stringsTarget, fadeSpeed * Time.deltaTime);
        melody.volume  = Mathf.MoveTowards(melody.volume, melodyTarget, fadeSpeed * Time.deltaTime);
    }

    // called from gameplay: enemy distance, combat state, boss phase, etc.
    public void SetIntensity(float value)
    {
        intensity = Mathf.Clamp01(value);
    }
}

Start() กำหนดให้ layer ทั้งสี่เริ่มด้วย PlayScheduled ที่ startDsp เดียวกันเป๊ะ บวก offset เผื่อไว้ 0.1 วินาที (พอให้ Unity เตรียม clip เสร็จก่อนถึง deadline จริง) การกำหนดให้ทั้งสี่เริ่มจากค่า dspTime เดียวกัน ในเฟรมเดียวกัน คือสิ่งที่รับประกันว่ามันจะเริ่มที่ sample เดียวกันเป๊ะ — ถ้าเรียก Play() แยกกันสี่ครั้งข้ามสามสี่เฟรม แต่ละอันอาจตกต่างกันไม่กี่มิลลิวินาที ซึ่งไม่ใช่ช่องว่างใหญ่อะไร แต่นั่นแหละคือความไม่ประสานกันเล็กๆ (บางทีเรียกว่า phasing) ที่หูที่ฝึกมาแล้วจับได้หลังฟังไปสักไม่กี่นาที

Update() คือจุดเดียวที่การตัดสินใจมิกซ์เสียงจริงๆ เกิดขึ้น และมันไม่แตะฟีลด์ intensity โดยตรงเลย — โค้ดฝั่ง gameplay จะเรียกแค่ SetIntensity(value) แล้ว Update() ก็อ่านค่ามันทุกเฟรม แต่ละ layer จะได้ target volume ที่คำนวณจาก intensity: กลองกับเบสเป็น threshold on/off ง่ายๆ (กลองจะเปิดเฉพาะตอนเกิน 0.6, เบสเฉพาะตอนเกิน 0.35) สายไล่ระดับสมูทตลอดช่วงด้วย Mathf.Lerp ส่วนเมโลดี้อยู่ที่ full volume ตลอด เพราะเมโลดี้ที่หายไปตอน intensity ต่ำจะทำให้เพลงฟังดูไม่ครบมากกว่าฟังดูสงบ Mathf.MoveTowards ค่อยๆ ดัน volume จริงของแต่ละ layer เข้าหา target ด้วยความเร็วคงที่ (fadeSpeed หน่วยเป็น volume unit ต่อวินาที) แทนที่จะสแนปทันที เพื่อให้การเปลี่ยน intensity แบบฉับพลันค่อยๆ เฟดเข้ามาแทนที่จะกระโดด

ลอง trace สถานการณ์ด้วย fadeSpeed = 1.5: intensity เริ่มที่ 0 (นิ่งแล้ว) จากนั้น SetIntensity(0.5) ถูกเรียกที่ t = 2.0s และ SetIntensity(0.8) ถูกเรียกที่ t = 5.0s:

สังเกตว่าเบสไม่ต้องขยับเลยครั้งที่สอง (มันอยู่ที่ target 1 อยู่แล้ว) และกลองเพิ่งขยับตอน t = 5.0s เพราะ 0.5 ไม่เคยข้าม threshold 0.6 ของมัน แต่ 0.8 ข้ามได้ ไม่มีอะไรสแนปเลย — ทุกการเปลี่ยนแปลงเป็นการไล่ระดับสมูทด้วยความเร็วคงที่เดียวกัน นี่คือเหตุผลที่การกระโดดจาก intensity 0 ไป 0.8 ทันทียังฟังดูเป็นการเฟด ไม่ใช่การตัด

9. Stinger: เสียงแทรกสั้นๆ ตามเหตุการณ์

Stinger คือวลีดนตรีสั้นๆ ที่เล่นครั้งเดียว — เสียงแตรกระแทก คอรัสกระแทก เสียงไรเซอร์ — ที่ซ้อนทับอยู่บนเพลงที่กำลังเล่นอยู่ เพื่อเน้นเหตุการณ์เดียวๆ: บอสปรากฏตัว ผู้เล่น level up ไอเทมหายากดรอป ต่างจาก section 4-8 ตรงที่ stinger ไม่ได้แทน state ที่ดำเนินต่อเนื่อง มันเล่นครั้งเดียวแล้วจบ

using System.Collections;
using UnityEngine;

public class MusicStingerPlayer : MonoBehaviour
{
    public AudioSource stingerSource;    // separate channel, layered on top of the music
    public AudioSource[] musicLayers;    // duck these briefly while the stinger plays

    public float duckAmount = 0.4f;      // fraction to lower music volume by
    public float duckTime = 0.15f;
    public float minCooldown = 1.0f;     // ignore repeats faster than this

    private float lastPlayTime = -999f;

    public void PlayStinger(AudioClip stingerClip)
    {
        if (Time.time - lastPlayTime < minCooldown)
        {
            Debug.Log("Stinger " + stingerClip.name + " suppressed (too soon)");
            return;
        }
        lastPlayTime = Time.time;

        stingerSource.PlayOneShot(stingerClip);
        StartCoroutine(DuckMusic());
        Debug.Log("Stinger: " + stingerClip.name);
    }

    private IEnumerator DuckMusic()
    {
        float[] original = new float[musicLayers.Length];
        for (int i = 0; i < musicLayers.Length; i++)
            original[i] = musicLayers[i].volume;

        for (int i = 0; i < musicLayers.Length; i++)
            musicLayers[i].volume *= (1f - duckAmount);

        yield return new WaitForSeconds(duckTime);

        for (int i = 0; i < musicLayers.Length; i++)
            musicLayers[i].volume = original[i];
    }
}

PlayOneShot เล่น stinger clip โดยไม่รบกวนอะไรที่ stingerSource อาจจะเล่นทีหลัง ซ้อนทับอยู่บนเพลงที่กำลังเล่นอยู่ DuckMusic จะ duck (ลดระดับเสียงของเสียงหนึ่งชั่วคราว เพื่อให้อีกเสียงหนึ่งได้ยินชัดเจนขึ้นบนนั้น) volume ของทุก layer ลง duckAmount เป็นเวลา duckTime วินาที แล้วคืน volume เดิมของแต่ละ layer กลับมาเป๊ะๆ เพื่อให้ stinger ตัวใหญ่ๆ ไม่ต้องแย่งความสนใจของผู้ฟังกับมิกซ์เต็มๆ

ลอง trace การเรียก PlayStinger สองครั้งด้วย clip เดียวกัน ห่างกัน 0.3 วินาที โดย minCooldown = 1.0:

Stinger: BossReveal
Stinger BossReveal suppressed (too soon)

Cooldown มีไว้เพราะเหตุการณ์ในเกมไม่ได้เว้นระยะห่างให้กันอย่างสุภาพ — ศัตรูสามตัวอาจตายภายในครึ่งวินาทีเดียวกัน แต่ละตัวก็อยากยิง stinger "ศัตรูถูกกำจัด" เดียวกัน ถ้าไม่มี cooldown สามชุดของวลีสั้นๆ อันเดียวกันที่ซ้อนกันจะกลายเป็นเสียงรบกวนแทนที่จะเป็น sting hit ที่ชัดเจนสามครั้ง

ต่างจากการเปลี่ยน segment ใน section 5 PlayStinger เล่นทันที ไม่ต้องรอ bar line เลย นี่คือการตัดสินใจโดยเจตนา: stinger มักแทนเหตุการณ์ที่เกิดขึ้นแบบฉับพลันน่าประหลาดใจ และ feedback ที่ทันทีสำคัญกว่าการเรียงจังหวะดนตรีตรงนี้ — ผู้เล่นควรได้ยินตอนที่บอสเปิดตัวทันทีที่มันเกิด ไม่ใช่รอไปได้ถึงสองวินาที บางเกมก็ quantize stinger บางตัวให้ตรงกับ beat ที่ใกล้ที่สุด เพื่อให้ได้ hit ที่หนักแน่นและ "ดนตรี" มากขึ้น จะเลือกทางไหนเป็นการตัดสินใจที่คอมโพเซอร์กับ gameplay designer ร่วมกันตัดสินเป็นรายเหตุการณ์

10. Middleware (Wwise/FMOD) ทำเรื่องพวกนี้ยังไง

ทุกอย่างใน section 5 ถึง 8 เป็นโค้ดจริงที่ใช้งานได้ — และก็เป็นโค้ดแบบเดียวกับที่มีเครื่องมือเฉพาะทางสร้างมาให้ทำแทนคุณพอดี Audio middleware (เครื่องมือภายนอกที่ใช้คู่กับ Unity หรือ Unreal ที่พบบ่อยที่สุดคือ Audiokinetic Wwise กับ FMOD Studio) ให้คอมโพเซอร์หรือ sound designer สร้างระบบ adaptive music ทั้งระบบแบบ visual โดยไม่ต้องเขียน C# แล้วส่ง API เล็กๆ ให้โปรแกรมเมอร์เกมเรียกใช้

สามไอเดียที่ตรงกับสิ่งที่คุณสร้างไปแล้วโดยตรง:

• State — ค่าเดี่ยว global ที่มีชื่อ (enum MusicState ของเรา, Explore/Combat/Boss) ที่เกมตั้งค่าด้วยการเรียกครั้งเดียว เครื่องมือ authoring ของ middleware รู้อยู่แล้วว่า segment ไหนอยู่ใน state ไหน และมันเรียงต่อกันได้ยังไง — นี่คือ horizontal re-sequencing ที่ authored แบบ visual แทนที่จะเป็น switch statement ใน C#
• RTPC (real-time parameter control) — ค่าต่อเนื่อง เหมือนกับ float intensity ของเรา ที่เกมอัปเดตทุกเฟรม คอมโพเซอร์วาด curve ต่อ layer แมป parameter นั้นไปเป็น volume ของ layer นั้นภายในเครื่องมือ authoring — นี่คือ vertical layering ที่แทนที่คณิตศาสตร์ fadeSpeed/Mathf.Lerp จาก section 8 ด้วย curve ที่คอมโพเซอร์เห็นและปรับได้เองโดยไม่ต้องขอให้โปรแกรมเมอร์แก้โค้ด
• Sync point — marker (Bar, Beat, Entry Cue, Exit Cue) ที่คอมโพเซอร์วางลงบน timeline ของไฟล์เสียงโดยตรงในเครื่องมือ authoring เมื่อเกมขอเปลี่ยน state middleware จะ quantize ให้อัตโนมัติไปยัง marker ถัดไปตามชนิดที่คอมโพเซอร์เลือก — นี่คือการคำนวณ bar-line ด้วย Math.Ceiling จาก section 6 ที่ถูกทำให้คุณแล้ว

// Hand-rolled (sections 5-8 of this chapter): the game computes the
// next bar line itself and schedules the switch/fade by hand.
horizontalPlayer.RequestSegment(combatClip);
verticalMixer.SetIntensity(0.8f);

// Wwise-style: the game only announces WHAT changed. The sound designer
// already placed Bar/Beat/Exit Cue markers and wrote the transition
// rules inside the Wwise authoring tool -- no C# math needed for it.
AkSoundEngine.SetState("MusicState", "Combat");

// FMOD-style: a continuous parameter (an RTPC) drives the vertical
// layers, mixed by the composer in FMOD Studio instead of by our
// fadeSpeed/Mathf.Lerp code.
musicInstance.setParameterByName("Intensity", 0.8f);

สังเกตว่าฝั่ง C# เล็กลงแค่ไหน: SetState กับ setParameterByName เหลือแค่บรรทัดเดียว การ scheduling การ duck และคณิตศาสตร์ curve ทั้งหมดจากบทนี้ยังเกิดขึ้นอยู่ — แค่มันเกิดขึ้นข้างในเอนจินของ middleware เอง ขับเคลื่อนด้วยข้อมูลที่คอมโพเซอร์ authored ไว้ในเครื่องมือ visual แทนที่จะอยู่ข้างใน MonoBehaviour ของคุณ

11. หลีกเลี่ยง repetition fatigue

Repetition fatigue คือสิ่งที่เกิดขึ้นเมื่อผู้เล่นสังเกตเห็น และเบื่อกับการได้ยิน loop, transition, หรือ stinger เดิมๆ ซ้ำไปซ้ำมา มันแทบจะเลี่ยงไม่ได้เลยในทางทฤษฎี — ผู้เล่นอาจใช้เวลายี่สิบนาทีในพื้นที่เดียวที่คอมโพเซอร์เขียนเพลงไว้แค่สามนาที — แต่มีนิสัยไม่กี่อย่างที่ช่วยไม่ให้มันเห็นได้ชัดเกินไป:

• Segment สลับหลายแบบต่อ state (E1, E2, E3 สำหรับ Explore แทนที่จะมี clip เดียว) เลือกให้อันเดิมแทบไม่ได้เล่นซ้ำติดกันสองครั้ง
• Stinger cooldown (section 9) เพื่อไม่ให้เหตุการณ์ที่เกิดบ่อยยิงวลีสั้นๆ อันเดียวกันซ้ำรัวๆ
• ช่วงเงียบหรือช่วงบางที่ตั้งใจเขียนไว้ใน arrangement เอง เพื่อให้หูได้พักแทนที่จะแน่นตลอดเวลา
• ความแปรผันเล็กๆ ที่ authored ไว้ข้างใน loop — ฟิลเพิ่ม เมโลดี้ที่ต่างไปนิดหน่อยในรอบที่สอง — เพื่อให้ loop ที่เล่นติดกันไม่เหมือนกันเป๊ะจนได้ยินออก แม้จะความยาวและ tempo เท่ากัน

using UnityEngine;

public class SegmentPicker
{
    private AudioClip[] variants;
    private int lastIndex = -1;

    public SegmentPicker(AudioClip[] variants)
    {
        this.variants = variants;
    }

    // picks a random variant, but never repeats the same one twice in a row
    public AudioClip PickNext()
    {
        int index;
        do
        {
            index = Random.Range(0, variants.Length);
        }
        while (variants.Length > 1 && index == lastIndex);

        lastIndex = index;
        return variants[index];
    }
}

ลอง trace การเรียก PickNext() ห้าครั้ง ด้วยสามแบบ [E1, E2, E3] ผลลัพธ์ที่เป็นไปได้แบบหนึ่ง (ลำดับจริงๆ เป็นแบบสุ่ม แต่กฎไม่ใช่):

รอบของคุณเองมีโอกาสสูงมากที่จะได้ลำดับต่างออกไป เพราะ Random.Range สุ่มจริงๆ — สิ่งเดียวที่ loop do/while รับประกันคือ index จะไม่มีวันเท่ากับ lastIndex ตอนที่ loop จบ ดังนั้น segment เดียวกันสองอันจะไม่มีวันเล่นติดกันสองครั้ง

12. คำศัพท์

• Adaptive music / interactive music — เพลงที่ถูกสร้างมาให้เปลี่ยนตาม gameplay แทนที่จะเล่นตาม arrangement ตายตัว
• Linear (fixed) music — เพลงชิ้นเดียวที่เล่นตรงหรือ loop โดยไม่ตอบสนองต่อ game state เลย
• Horizontal re-sequencing — การแยกเพลงเป็น segment แล้วเลือกว่าอันไหนจะเล่นต่อตาม game state
• Segment — clip เพลงชิ้นหนึ่งที่จบในตัวเอง ใช้โดย horizontal re-sequencing (clip Explore, clip Combat)
• Quantization (musical) — การดันเหตุการณ์ให้ไปตกที่ beat หรือ bar ที่ใกล้ที่สุด แทนที่จะปล่อยให้เกิดขึ้นตรงเวลาสุ่มๆ
• BPM — beats per minute; tempo ของเพลงชิ้นหนึ่ง
• Beat / Bar (measure) — จังหวะเคาะหนึ่งครั้งของเพลง และกลุ่มของ beat ที่ตายตัว (ปกติสี่ครั้ง) ที่รวมเป็นหน่วยดนตรีหนึ่งหน่วย
• AudioSettings.dspTime — clock ของฮาร์ดแวร์เสียงของ Unity ที่นิ่งกว่า หน่วยเป็นวินาที ใช้สำหรับ scheduling ที่แม่นยำ แทนที่จะเป็น Time.time ที่อิงเฟรม
• PlayScheduled / SetScheduledEndTime — method ของ AudioSource ใน Unity ที่เริ่มหรือหยุด clip ที่ dspTime อนาคตที่แน่นอน
• Vertical layering / stems — เพลงชิ้นเดียวที่เล่นต่อเนื่องแยกเป็น track ของแต่ละเครื่องดนตรี มิกซ์สดด้วย volume แทนที่จะสลับ
• Intensity parameter — ค่าเดี่ยว (มักเป็น 0 ถึง 1) ที่ขับเคลื่อนว่าแต่ละ vertical layer ดังแค่ไหน
• RTPC (real-time parameter control) — คำศัพท์ของ middleware สำหรับค่าต่อเนื่อง อย่าง intensity ที่เกมอัปเดตทุกเฟรมเพื่อขับเคลื่อนมิกซ์
• Stinger — วลีดนตรีสั้นๆ ที่เล่นครั้งเดียว ซ้อนทับบนเพลงเพื่อเน้นเหตุการณ์เดียว
• Ducking — การลดระดับเสียงของเสียงหนึ่งชั่วคราว เพื่อให้อีกเสียงหนึ่งได้ยินชัดเจนขึ้นบนนั้น
• Middleware — เครื่องมือเสียงเฉพาะทาง (Wwise, FMOD) ที่ใช้คู่กับเกมเอนจิน ให้คอมโพเซอร์สร้าง adaptive music ได้โดยไม่ต้องเขียนโค้ดเอนจิน
• State (middleware) — ค่าเดี่ยว global ที่มีชื่อ ที่เกมตั้งค่าเพื่อเลือกว่าชุด horizontal segment ไหนกำลังทำงาน
• Sync point (Entry Cue / Exit Cue) — marker ที่วางบน timeline ของไฟล์เสียง ที่ middleware ใช้ snap การเปลี่ยนเข้าไป
• Repetition fatigue — ผู้เล่นสังเกตเห็นและเบื่อกับการได้ยินเพลงเดิมซ้ำไปซ้ำมา

13. แบบฝึกหัด

นี่คือ adaptive music แบบครบวงจร: loop ตายตัวพังเพราะเกมไม่รู้จังหวะเวลาของตัวเองล่วงหน้า horizontal re-sequencing แก้ปัญหาด้วยการสลับระหว่าง segment ที่ authored ไว้บน bar line ที่ quantize แล้ว vertical layering แก้ปัญหาอีกแบบด้วยการมิกซ์ stem ที่เล่นต่อเนื่องตลอดด้วยค่า intensity เดียว stinger เน้นเหตุการณ์เดียวๆ ซ้อนทับบนทั้งสองอย่าง และ middleware อย่าง Wwise หรือ FMOD ให้คอมโพเซอร์ authored state, RTPC, และ sync point แบบ visual จนฝั่ง C# เหลือแค่ไม่กี่บรรทัด ไอเดียเดียวที่ร้อยทุกอย่างเข้าด้วยกันคือเวลาทางดนตรี — BPM, beat, และ bar วัดด้วย dspTime แทนที่จะเป็นเวลาเฟรม — เพราะทุกเทคนิคในบทนี้จริงๆ แล้วก็แค่วิธีต่างๆ ในการเคารพมันนั่นเอง