11.3 การตัดสินใจ (Behavior Tree, FSM, GOAP, Utility)

บทนี้พูดถึงวิธีที่ game AI agent ตัดสินใจว่าจะทำอะไร บทก่อนหน้าสอนให้เรารู้วิธีขยับวัตถุให้ลื่นไหล และวิธีจัดระเบียบโค้ดเกมด้วย component, event และ State pattern แต่สิ่งเหล่านั้นยังตอบคำถามจริง ๆ ที่ดีไซเนอร์ถามเวลาเห็นศัตรูทำอะไรแปลก ๆ ไม่ได้ นั่นคือ "ทำไมมันเพิ่งทำแบบนั้น" บทนี้จะพาไปดู 4 วิธีตอบคำถามนั้น เรียงจากง่ายสุดไปยืดหยุ่นสุด ได้แก่ Finite State Machine (FSM), Behavior Tree (BT), Goal-Oriented Action Planning (GOAP) และ Utility AI เราจะเขียน C# จริงสำหรับสองอันแรก เข้าใจแนวคิดพร้อมดูตัวอย่างที่คลี่ทีละขั้นสำหรับสองอันหลัง แล้วจบด้วยการรู้ว่าควรหยิบเครื่องมือไหนมาใช้ในโปรเจกต์จริง

1. Game AI Agent ตัดสินใจอย่างไรว่าจะทำอะไร

ไม่ว่า game AI จะถูกสร้างมาแบบไหน มันวนลูป 3 ขั้นตอนเดิมทุกเฟรม คือ มองดูโลกรอบตัว (perception — การรับรู้), ตัดสินใจว่าจะทำอะไรกับสิ่งที่เห็น (decision-making — การตัดสินใจ), แล้วลงมือทำจริง (action — การกระทำ) เรารู้วิธีเขียนส่วน "action" อยู่แล้ว ไม่ว่าจะเป็นการขยับ Transform เล่นแอนิเมชัน หรือยิงกระสุน บทนี้จะพูดถึงขั้นตอนกลางเพียงอย่างเดียว คือส่วนของโค้ดที่เลือกว่าจะรัน action ไหน

"ระบบตัดสินใจ" ก็คือส่วนของโค้ดที่แปลง perception ให้กลายเป็นการเลือก action นั่นเอง ระบบทั้งสี่ในบทนี้เป็นสี่วิธีที่ต่างกันในการเขียนโค้ดส่วนนั้น มันไม่ใช่ "ยี่ห้อ" AI ที่แข่งกันทำงานเดียวกัน แต่แต่ละอันแก้ปัญหาการตัดสินใจด้วยข้อแลกเปลี่ยน (trade-off) ที่ต่างกัน และเกมจริงมักผสมหลายอันเข้าด้วยกัน:

• FSM — agent อยู่ในโหมดที่มีชื่อเรียกได้แค่โหมดเดียวเสมอ พร้อมกฎชัดเจนสำหรับการสลับโหมด เรียบง่าย แต่ขยายสเกลได้ไม่ดี
• Behavior Tree — ต้นไม้ของ node เล็ก ๆ ที่นำมาใช้ซ้ำได้ ถูกตรวจสอบตามลำดับความสำคัญทุกเฟรม เป็นตัวเลือกมาตรฐานของสตูดิโอส่วนใหญ่ในปัจจุบัน
• GOAP — agent ได้รับเป้าหมาย (goal) กับรายการ action ที่มีเงื่อนไขและผลลัพธ์ แล้วตัว planner จะค้นหาลำดับ action ที่พาไปถึงเป้าหมายนั้น
• Utility AI — action ที่เป็นไปได้ทุกตัวจะได้คะแนนเป็นตัวเลข แล้ว agent จะเลือกอันที่คะแนนสูงสุด ณ ตอนนั้น

2. Finite State Machine: State และ Transition

finite state machine (FSM) คือระบบที่อยู่ใน state (สถานะที่มีชื่อเรียก) ได้แค่หนึ่งอันเสมอ จากชุด state ที่กำหนดไว้ตายตัว พร้อมกฎชัดเจน — เรียกว่า transition (การเปลี่ยนสถานะ) — สำหรับสลับจาก state หนึ่งไปอีก state หนึ่ง เราเคยเจอรูปแบบนี้มาแล้วในชื่อ "State pattern" ตอนจัดระเบียบโค้ดเกม ที่นี่เราใช้แนวคิดเดียวกันเป๊ะ ๆ แต่เจาะจงมาเพื่อตัดสินใจพฤติกรรมศัตรู

ศัตรูแบบคลาสสิกมี 3 state คือ Patrol (เดินตามเส้นทางที่กำหนด), Chase (วิ่งเข้าหาผู้เล่น) และ Attack (โจมตีระยะประชิด) กฎการสลับระหว่างกันมีดังนี้:

มีแค่ 4 transition เชื่อม 3 state และแต่ละอันอธิบายด้วยปากได้ง่ายมาก เช่น "ถ้าเห็นผู้เล่นก็ควรไล่ล่า ถ้าเข้าใกล้พอก็ควรโจมตี" ความชัดเจนแบบนี้แหละคือจุดขายทั้งหมดของ FSM คุณชี้ไปที่บรรทัดพฤติกรรมไหนก็อธิบายได้ทันทีว่ามันทำงานตอนไหน

3. เขียน FSM ด้วย C#

การเขียน FSM แบบสะอาดคือให้แต่ละ state มีคลาสเล็ก ๆ ของตัวเอง แทนที่จะยัดทุกอย่างไว้ในเมธอดยักษ์เดียวที่เต็มไปด้วย if แต่ละ state ต้องรู้ว่าเมื่อเริ่มต้น (Enter) ต้องทำอะไร และทุกเฟรมที่ยัง active อยู่ (Tick) ต้องทำอะไร:

public interface IEnemyState
{
    void Enter(EnemyAI enemy);
    void Tick(EnemyAI enemy);
}

แต่ละ state ที่เป็นรูปธรรมจะ implement interface นี้ แล้วตัดสินใจข้างใน Tick ว่าถึงเวลาสลับไป state อื่นหรือยัง:

using UnityEngine;

public class PatrolState : IEnemyState
{
    public void Enter(EnemyAI enemy)
    {
        Debug.Log("Enter Patrol");
    }

    public void Tick(EnemyAI enemy)
    {
        enemy.MoveAlongPatrolRoute();

        if (enemy.CanSeePlayer())
        {
            enemy.ChangeState(new ChaseState());
        }
    }
}

public class ChaseState : IEnemyState
{
    public void Enter(EnemyAI enemy)
    {
        Debug.Log("Enter Chase");
    }

    public void Tick(EnemyAI enemy)
    {
        enemy.MoveTowardPlayer();

        if (enemy.DistanceToPlayer() < enemy.attackRange)
        {
            enemy.ChangeState(new AttackState());
        }
        else if (!enemy.CanSeePlayer())
        {
            enemy.ChangeState(new PatrolState());
        }
    }
}

public class AttackState : IEnemyState
{
    public void Enter(EnemyAI enemy)
    {
        Debug.Log("Enter Attack");
    }

    public void Tick(EnemyAI enemy)
    {
        enemy.AttackPlayer();

        if (enemy.DistanceToPlayer() >= enemy.attackRange)
        {
            enemy.ChangeState(new ChaseState());
        }
    }
}

คอมโพเนนต์ EnemyAI แค่เก็บ state ปัจจุบันไว้ แล้วส่งการควบคุมให้มันทุกเฟรม:

using UnityEngine;

public class EnemyAI : MonoBehaviour
{
    public float attackRange = 2f;
    private IEnemyState currentState;

    void Start()
    {
        ChangeState(new PatrolState());
    }

    void Update()
    {
        currentState.Tick(this);
    }

    public void ChangeState(IEnemyState newState)
    {
        currentState = newState;
        currentState.Enter(this);
    }

    public bool CanSeePlayer() { /* raycast toward the player */ return false; }
    public float DistanceToPlayer() { /* Vector3.Distance to the player */ return 999f; }
    public void MoveAlongPatrolRoute() { /* walk to the next waypoint */ }
    public void MoveTowardPlayer() { /* walk toward the player */ }
    public void AttackPlayer() { /* deal damage on a cooldown */ }
}

ผลลัพธ์ที่คาดไว้: ตอนศัตรูเกิด คอนโซลจะพิมพ์ Enter Patrol พอ CanSeePlayer() คืนค่า true จะพิมพ์ Enter Chase และพอ DistanceToPlayer() ต่ำกว่า attackRange จะพิมพ์ Enter Attack ทุกครั้งที่เรียก ChangeState จะมีการสร้าง state object ใหม่ ดังนั้น field ที่เก็บข้อมูลเฉพาะของ state นั้น (เช่น timer หรือตำแหน่งเป้าหมาย) จะเริ่มต้นใหม่เสมอ

4. ทำไม FSM ใหญ่ ๆ ถึงกลายเป็นสปาเก็ตตี้

3 state กับ 4 transition คิดตามได้ง่าย แต่ศัตรูจริง ๆ ในที่สุดก็ต้องการมากกว่านี้ เช่น Flee (หนี) เมื่อเลือดต่ำ, Search (ค้นหา) เมื่อเคยเห็นผู้เล่นแต่ตอนนี้หายไป, Stunned (มึนงง) หลังโดนโจมตีหนัก, Dead (ตาย) 6 state ไม่ได้ต้องการแค่ 6 transition แต่ต้องการมากถึง 6 × 5 = 30 transition ที่เป็นไปได้ เพราะโดยหลักการแล้ว state ไหนก็อาจต้องขัดจังหวะ state อื่นได้ทั้งนั้น:

ปัญหาไม่ใช่แค่การนับลูกศรเท่านั้น แต่คือ state class แต่ละอันจบลงด้วยการต้องรู้จัก state อื่น ๆ ทุกตัวที่อาจมาขัดจังหวะตัวเอง:

// FleeState now has to know about every other state that
// might need to interrupt fleeing -- coupling grows with
// every new feature anyone adds to the game.
public class FleeState : IEnemyState
{
    public void Tick(EnemyAI enemy)
    {
        if (enemy.Health <= 0)
        {
            enemy.ChangeState(new DeadState());
        }
        else if (enemy.IsCornered())
        {
            enemy.ChangeState(new StunnedState());
        }
        else if (enemy.Health > enemy.fleeThreshold)
        {
            enemy.ChangeState(new PatrolState());
        }
        else if (enemy.CanSeePlayer() && enemy.HasBackup())
        {
            enemy.ChangeState(new ChaseState());
        }
        // ...one more line for every future state, forever.
    }
}

นี่คือปัญหาที่รู้กันดีของ FSM เมื่อขยายสเกล คือจำนวน transition ที่ต้องคิดถึงจะโตขึ้นประมาณกำลังสองของจำนวน state, state class แต่ละอันเชื่อมโยงแน่นกับ class อื่นจำนวนมาก และเงื่อนไขตรวจสอบแบบเดิม ๆ (ศัตรูตายไหม? มึนงงไหม? กระสุนหมดไหม?) ก็ถูกก๊อปวางซ้ำ ๆ ในทุก state นี่คือปัญหาโค้ดพันกันจนตามยาก ที่เรียกว่า spaghetti code (สปาเก็ตตี้โค้ด) จากบทเรื่อง gameplay architecture นั่นเอง แต่คราวนี้มันเกิดขึ้นข้างใน AI ของคุณ นี่ไม่ใช่สัญญาณว่าคุณเขียน FSM แย่ แต่มันคือข้อจำกัดเชิงโครงสร้างของรูปแบบ FSM เอง และนี่คือเหตุผลว่าทำไมเครื่องมือถัดไปถึงมีอยู่

5. Behavior Tree: Node และ Tick

behavior tree (BT) คือต้นไม้ของ node เล็ก ๆ ที่ถูกประเมินจากบนลงล่าง ซ้ายไปขวา ครั้งละหนึ่งเฟรม — การประเมินหนึ่งรอบนี้เรียกว่า tick ทุก node จะคืนค่าผลลัพธ์อย่างใดอย่างหนึ่งจากสามแบบเมื่อถูก tick:

• Success — node ทำงานเสร็จแล้ว และสำเร็จ
• Failure — node ทำงานเสร็จแล้ว แต่ไม่สำเร็จ
• Running — node ยังทำงานไม่เสร็จ (เช่น action ที่ใช้เวลาหลายเฟรม อย่างการเดินไปที่ไหนสักที่) ให้ถามใหม่ใน tick ถัดไป

public enum NodeStatus
{
    Success,
    Failure,
    Running
}

public interface IBTNode
{
    NodeStatus Tick();
}

node มีสองตระกูล Composite node มีลูก (children) และรวมผลลัพธ์ของลูกเข้าด้วยกัน ส่วน leaf node (node ใบ) ทำหน้าที่เช็คหรือลงมือทำจริง ๆ และไม่มีลูก composite node สองตัวที่ต้องรู้จักก่อนคือ:

• Sequence — เหมือนเช็คลิสต์ ("AND") ไล่ tick ลูกจากซ้ายไปขวา ถ้าลูกตัวไหน fail Sequence จะหยุดทันทีและคืนค่า Failure จะคืนค่า Success ก็ต่อเมื่อลูกทุกตัวสำเร็จ
• Selector — เหมือนลิสต์ลำดับความสำคัญ ("OR") ไล่ tick ลูกจากซ้ายไปขวา ถ้าลูกตัวไหนสำเร็จ (หรือ Running) Selector จะหยุดทันทีและคืนค่านั้น จะคืนค่า Failure ก็ต่อเมื่อลูกทุกตัว fail

สังเกตว่า composite ทั้งสองแบบ short-circuit (หยุดกลางคันได้): Sequence จะไม่ tick ลูกตัวถัดไปหลังเจอ failure ตัวแรก และ Selector จะไม่ tick ลูกตัวถัดไปหลังเจอ success ตัวแรก พฤติกรรม "หยุดเร็ว" แบบนี้แหละที่ทำให้ต้นไม้แสดงลำดับความสำคัญได้ กิ่งซ้ายสุดของ Selector จะถูกลองก่อนเสมอ และจะดูตัวเลือกถัดไปก็ต่อเมื่อกิ่งนั้น fail เท่านั้น

6. สร้าง Behavior Tree Framework ด้วย C#

Composite node: Sequence กับ Selector

public class Sequence : IBTNode
{
    private readonly IBTNode[] children;

    public Sequence(params IBTNode[] children)
    {
        this.children = children;
    }

    public NodeStatus Tick()
    {
        foreach (var child in children)
        {
            NodeStatus status = child.Tick();
            if (status != NodeStatus.Success)
            {
                return status; // Failure or Running: stop here
            }
        }
        return NodeStatus.Success; // every child succeeded
    }
}

public class Selector : IBTNode
{
    private readonly IBTNode[] children;

    public Selector(params IBTNode[] children)
    {
        this.children = children;
    }

    public NodeStatus Tick()
    {
        foreach (var child in children)
        {
            NodeStatus status = child.Tick();
            if (status != NodeStatus.Failure)
            {
                return status; // Success or Running: stop here
            }
        }
        return NodeStatus.Failure; // every child failed
    }
}

Leaf node: Condition กับ Action

Condition node เช็คบางอย่างเกี่ยวกับโลกแล้วคืนค่า Success หรือ Failure ทันที — ไม่มีทางเป็น Running ส่วน Action node ลงมือทำจริง ๆ และสามารถคืนค่า Running ได้ระหว่างที่ action ยังไม่เสร็จ:

using System;

public class ConditionNode : IBTNode
{
    private readonly Func<bool> condition;

    public ConditionNode(Func<bool> condition)
    {
        this.condition = condition;
    }

    public NodeStatus Tick()
    {
        return condition() ? NodeStatus.Success : NodeStatus.Failure;
    }
}

public class ActionNode : IBTNode
{
    private readonly Func<NodeStatus> action;

    public ActionNode(Func<NodeStatus> action)
    {
        this.action = action;
    }

    public NodeStatus Tick()
    {
        return action();
    }
}

เท่านี้ก็ได้ framework ครบแล้ว composite สองแบบ leaf สองแบบ และสัญญาการทำงาน Tick() ที่ใช้ร่วมกันหนึ่งอัน behavior tree ทุกต้นที่คุณจะสร้างต่อจากนี้ ไม่ว่าจะใหญ่แค่ไหน ก็ประกอบขึ้นจากชิ้นส่วนพื้นฐานสี่แบบนี้เท่านั้น

7. Behavior Tree ฉบับเต็ม: Patrol, Chase, Attack

นี่คือศัตรูตัวเดิมจากข้อ 3 — Patrol, Chase, Attack — แต่สร้างใหม่เป็น behavior tree แทน FSM เพื่อให้เทียบกันได้โดยตรง:

อ่านต้นไม้นี้แบบเดียวกับที่อ่านความหมายของ Selector ในข้อ 5 คือลองกิ่งซ้ายสุดก่อน แล้วค่อยตกไปกิ่งถัดไปเมื่อกิ่งนั้น fail เท่านั้น

using UnityEngine;

public class EnemyAI : MonoBehaviour
{
    public float attackRange = 2f;
    private IBTNode root;

    void Start()
    {
        root = new Selector(
            new Sequence(
                new ConditionNode(CanSeePlayer),
                new Selector(
                    new Sequence(
                        new ConditionNode(InAttackRange),
                        new ActionNode(AttackPlayer)
                    ),
                    new ActionNode(ChasePlayer)
                )
            ),
            new ActionNode(Patrol)
        );
    }

    void Update()
    {
        root.Tick();
    }

    bool CanSeePlayer() { /* raycast toward the player */ return false; }
    bool InAttackRange() { /* distance check against attackRange */ return false; }

    NodeStatus AttackPlayer()
    {
        Debug.Log("Attack!");
        return NodeStatus.Running; // the attack animation is still playing
    }

    NodeStatus ChasePlayer()
    {
        Debug.Log("Chasing...");
        return NodeStatus.Running; // still closing the distance
    }

    NodeStatus Patrol()
    {
        Debug.Log("Patrolling...");
        return NodeStatus.Running; // walking to the next waypoint
    }
}

ผลลัพธ์ที่คาดไว้ ไล่ทีละขั้นด้วยมือสำหรับสามสถานการณ์:

• มองไม่เห็นผู้เล่น: root Selector tick ลูกตัวแรกคือ Sequence ชั้นนอก Sequence นั้น tick CanSeePlayer ซึ่งคืนค่า Failure Sequence หยุดทันทีและคืนค่า Failure — ChasePlayer กับ AttackPlayer ไม่ถูกเช็คเลยด้วยซ้ำ root Selector จึงไปต่อที่ลูกถัดไปคือ Patrol ซึ่งพิมพ์ Patrolling...
• เห็นผู้เล่นแต่ยังไกล: CanSeePlayer สำเร็จ Sequence ชั้นนอกจึงไป tick Selector ชั้นใน Selector นั้นลองลูกตัวแรกคือ Sequence ชั้นใน ซึ่ง tick InAttackRange — Failure เพราะผู้เล่นยังไกล Sequence ชั้นในหยุดและคืนค่า Failure Selector ชั้นในจึงตกไปที่ ChasePlayer ซึ่งพิมพ์ Chasing... และคืนค่า Running ค่า Running นี้จะไหลขึ้นผ่าน Selector ทั้งสองชั้นโดยไม่เปลี่ยน ไปถึง root
• เห็นผู้เล่นและอยู่ใกล้: เงื่อนไขทั้งสองสำเร็จหมด AttackPlayer จึงทำงาน พิมพ์ Attack! และคืนค่า Running

เทียบกับ FSM ในข้อ 3: พฤติกรรมสามแบบเดียวกัน กฎเดียวกัน แต่ที่นี่ไม่มีอะไรถูกเขียนตายตัวว่า "state X ไปที่ state Y" ลำดับความสำคัญและตรรกะสำรองอยู่ในรูปทรงของต้นไม้ทั้งหมด

8. ทำไม Behavior Tree ถึงขยายสเกลได้ดีกว่า FSM

ย้อนกลับไปดูปัญหา Flee/Search/Stunned/Dead จากข้อ 4 แล้วลองจินตนาการว่ามันเป็นต้นไม้แทน การเพิ่ม "หนีเมื่อเลือดต่ำ" หมายถึงการเพิ่มกิ่ง Sequence ใหม่หนึ่งอันไว้ใกล้ด้านบนของ Selector:

root = new Selector(
    new Sequence(new ConditionNode(IsCritical), new ActionNode(Flee)),   // new
    new Sequence(new ConditionNode(CanSeePlayer), /* chase/attack subtree */ null),
    new ActionNode(Patrol)
);

ข้างในกิ่งย่อย chase/attack ไม่มีอะไรเปลี่ยนเลย PatrolState, ChaseState และ AttackState ไม่ต้องเพิ่มบรรทัดใหม่แม้แต่บรรทัดเดียวเพื่อเช็คว่า "ตอนนี้ศัตรูกำลังหนีอยู่หรือเปล่า" — โครงสร้างต้นไม้เองรับประกันอยู่แล้วว่ากิ่ง Flee จะถูกเช็คก่อนเสมอ และถ้ามัน fail (เลือดยังปกติ) ทุกอย่างข้างใต้ก็ทำงานเหมือนเดิมทุกประการ นี่คือเหตุผลหลักที่ behavior tree ขยายสเกลได้ดีกว่า FSM:

• ไม่มีตาราง transition ต้องคอยดูแล ลำดับการ tick กับการ short-circuit เข้ารหัส "ลองอันนี้ก่อน ถ้าไม่ได้ค่อยไปอันนั้น" ไว้อยู่แล้ว ไม่ต้องมีตาราง N × N ของ transition ที่อนุญาตให้คอยซิงค์แยกต่างหาก
• พฤติกรรมใหม่คือการเพิ่ม node ไม่ใช่แก้ node เดิม กิ่งเดิมไม่ถูกแตะต้อง จึงไม่มีทางที่การเพิ่ม Flee จะทำ Patrol พังโดยไม่ตั้งใจ
• Subtree นำกลับมาใช้ซ้ำได้ subtree อย่าง "LookAround" หรือ "PlayHurtAnimation" เมื่อสร้างเสร็จแล้วก็เอาไปเสียบในกิ่งพ่อแม่หลาย ๆ อัน หรือศัตรูหลายชนิดได้เลย
• Running จัดการ action หลายเฟรมได้เป็นธรรมชาติ FSM ต้องใช้ bool หรือ timer แบบมือ ๆ เพื่อติดตามว่า "action นี้ยังทำอยู่ไหม" ส่วน behavior tree ได้สิ่งนี้มาฟรีจากค่าคืนสามแบบอยู่แล้ว

9. GOAP: Goal-Oriented Action Planning

ทั้ง FSM และ behavior tree ต้องการให้คนมานั่งเขียนทุกเส้นทางที่ agent เดินได้ด้วยมือ GOAP (Goal-Oriented Action Planning) ใช้วิธีที่ต่างออกไป แทนที่จะเขียนเส้นทางเอง คุณแค่บรรยาย action แต่ละตัวที่ agent ทำได้ แล้วให้ planner ค้นหาตอนรันจริงว่าลำดับ action แบบไหนพาไปถึง goal (เป้าหมาย) ได้ นี่คือเทคนิคที่ทหารในเกมยิงปี 2005 อย่าง F.E.A.R. ทำให้โด่งดัง แทนที่จะสคริปต์ตายตัวว่า "หลบก่อน แล้วรีโหลด แล้วยิง" เกมแค่บอกเป้าหมาย ("ฆ่าเป้าหมาย") แล้วปล่อยให้ทหารแต่ละคนคิดแผนของตัวเองจาก action ที่มีอยู่และเป็นประโยชน์ในตอนนั้น

Action: Precondition กับ Effect

แต่ละ action มี precondition (เงื่อนไขที่โลกต้องเป็นจริงอยู่แล้วก่อน action นี้จะทำได้) และ effect (สิ่งที่จะกลายเป็นจริงในโลกเมื่อ action ทำเสร็จ) บวกกับ cost (ต้นทุน) ที่ planner จะพยายามทำให้น้อยที่สุด:

using System.Collections.Generic;

public class GoapAction
{
    public string Name;
    public float Cost = 1f;
    public Dictionary<string, bool> Preconditions = new Dictionary<string, bool>();
    public Dictionary<string, bool> Effects = new Dictionary<string, bool>();
}

GoapAction moveToCover = new GoapAction
{
    Name = "MoveToCover",
    Cost = 1f,
    // no preconditions -- the agent can always try to move to cover
    Effects = { ["InCover"] = true }
};

GoapAction reload = new GoapAction
{
    Name = "Reload",
    Cost = 1f,
    Preconditions = { ["AmmoInReserve"] = true },
    Effects = { ["HasAmmo"] = true }
};

GoapAction attackFromCover = new GoapAction
{
    Name = "AttackFromCover",
    Cost = 2f,
    Preconditions = { ["InCover"] = true, ["HasAmmo"] = true },
    Effects = { ["EnemyDead"] = true }
};

Planner: ค้นหาแผน

เมื่อมี world state เริ่มต้นกับ world state เป้าหมาย planner จะค้นหาย้อนกลับ: "effect ของ action ไหนที่ทำให้เป้าหมายเป็นจริงได้บ้าง? action นั้นต้องการ precondition อะไร? ไล่ย้อนกลับแบบนี้ไปเรื่อย ๆ จนกว่าทุกความต้องการที่เหลือจะเป็นจริงอยู่แล้ว ณ ตอนนี้" นี่คือการค้นหาแบบกราฟชนิดเดียวกับ pathfinding เพียงแต่ "แผนที่" ทำจาก world state แทนที่จะเป็นตำแหน่งจริง และ "ถนน" ระหว่างกันคือ action:

// Conceptual pseudocode for how the plan gets used once found.
// Real planners run an A*-style search with a priority queue --
// this sketch shows the idea, not a production implementation.
WorldState goal = new WorldState { EnemyDead = true };
WorldState current = agent.GetCurrentWorldState();

List<GoapAction> plan = Planner.FindPlan(current, goal, availableActions);

foreach (GoapAction step in plan)
{
    Debug.Log("Plan step: " + step.Name);
}
// Prints, for the example above:
//   Plan step: MoveToCover
//   Plan step: Reload
//   Plan step: AttackFromCover

ผลตอบแทนคือความสามารถในการปรับตัว ถ้าโลกเปลี่ยนกลางแผน (ที่กำบังถูกทำลาย กระสุนหมดที่อื่น) agent ก็แค่วางแผนใหม่จาก world state ปัจจุบันของมัน ไม่มีใครต้องนั่งเขียนกฎเฉพาะสำหรับสถานการณ์นั้น เพราะ planner ค้นหาใหม่ทุกครั้งที่ถูกเรียกใช้

10. Utility AI: ให้คะแนนทุกตัวเลือก

Utility AI ข้ามทั้งต้นไม้และการวางแผนไปเลย action ที่เป็นไปได้ทุกตัวจะได้ score (คะแนน หรือเรียกอีกอย่างว่า utility) เป็นตัวเลข คำนวณจากสถานการณ์ปัจจุบัน โดยใช้ scoring function (ฟังก์ชันให้คะแนน) เล็ก ๆ ต่อ action หนึ่งตัว แล้ว agent ก็แค่รัน action ที่คะแนนสูงสุดในเฟรมนั้น มันคือเครื่องมือที่ถูกต้องเมื่อตัวเลือกที่ "ถูกต้อง" ขึ้นอยู่กับการผสมปัจจัยต่อเนื่องหลายอย่างพร้อมกันจริง ๆ ไม่ใช่กฎ yes/no ที่ชัดเจน

public interface IUtilityAction
{
    string Name { get; }
    float Score(EnemyAI enemy);
    void Execute(EnemyAI enemy);
}

public class FleeAction : IUtilityAction
{
    public string Name => "Flee";

    public float Score(EnemyAI enemy)
    {
        // Full health never wants to flee; near-death wants it badly.
        float missingHealthFraction = 1f - (enemy.Health / enemy.MaxHealth);
        return missingHealthFraction * 10f; // ranges 0 .. 10
    }

    public void Execute(EnemyAI enemy) { enemy.RunAwayFromPlayer(); }
}

public class AttackAction : IUtilityAction
{
    public string Name => "Attack";

    public float Score(EnemyAI enemy)
    {
        if (enemy.Ammo <= 0) return 0f; // can't attack with no ammo

        float closeness = Mathf.Clamp01(1f - enemy.DistanceToPlayer() / enemy.MaxAttackDistance);
        return closeness * 6f; // ranges 0 .. 6, higher when the player is close
    }

    public void Execute(EnemyAI enemy) { enemy.AttackPlayer(); }
}

public class PatrolAction : IUtilityAction
{
    public string Name => "Patrol";

    public float Score(EnemyAI enemy) => 1f; // a low, constant fallback

    public void Execute(EnemyAI enemy) { enemy.MoveAlongPatrolRoute(); }
}

using System.Collections.Generic;
using UnityEngine;

public class UtilityAI : MonoBehaviour
{
    public EnemyAI enemy;
    private List<IUtilityAction> actions;

    void Awake()
    {
        actions = new List<IUtilityAction>
        {
            new FleeAction(),
            new AttackAction(),
            new PatrolAction()
        };
    }

    void Update()
    {
        IUtilityAction best = null;
        float bestScore = float.MinValue;

        foreach (var action in actions)
        {
            float score = action.Score(enemy);
            if (score > bestScore)
            {
                bestScore = score;
                best = action;
            }
        }

        best.Execute(enemy);
    }
}

ไล่คำนวณทีละขั้น: สมมติ Health = 20, MaxHealth = 100, Ammo = 3, DistanceToPlayer = 4, MaxAttackDistance = 10:

Flee ชนะ ทั้งที่ผู้เล่นอยู่ในระยะโจมตีสบาย ๆ และศัตรูยังมีกระสุน เพราะเลือดเหลือน้อยวิกฤต นี่คือความละเอียดอ่อนแบบ "ขึ้นอยู่กับหลายอย่างพร้อมกัน" ที่ FSM จะต้องเพิ่มกฎพิเศษเข้าไปอีกอัน และ behavior tree จะต้องเพิ่ม Condition node อีกตัว ส่วน Utility AI ได้สิ่งนี้มาฟรี เพราะ score function ผสมทุกปัจจัยเข้าด้วยกันอยู่แล้ว

11. เลือกระหว่าง FSM, BT, GOAP และ Utility AI

ไม่มีเครื่องมือไหนใน 4 อันนี้ที่ "ดีกว่า" อีกอันแบบเด็ดขาด แต่ละอันเหมาะกับรูปแบบปัญหาการตัดสินใจที่ต่างกัน:

• FSM — เหมาะกับจำนวนโหมดที่แยกกันชัดเจนและตายตัวจริง ๆ ไม่กี่โหมด เช่น ไฟจราจร ประตู หน้าจอเมนู หรือศัตรูง่าย ๆ ที่มี 3-4 พฤติกรรม เขียนง่ายและอธิบายง่าย หลีกเลี่ยงมันเมื่อเกิน 5-6 state หรือเมื่อ state เริ่มต้องขัดจังหวะกันหลายรูปแบบเกินไป (ข้อ 4)
• Behavior Tree — ตัวเลือกมาตรฐานสำหรับ AI ของศัตรูและ NPC ส่วนใหญ่ในเกมที่วางขายจริงทุกวันนี้ เหมาะเมื่อพฤติกรรมเป็นแบบ "ลองอันนี้ก่อน ถ้าไม่ได้ค่อยตกไปอันนั้น" โดยธรรมชาติ นำกลับมาใช้ซ้ำได้ดีกับศัตรูหลายชนิด และมีเครื่องมือรองรับแข็งแรง (editor ในตัวของ Unreal, แพ็กเกจ Behavior ของ Unity และเครื่องมือจากภายนอก)
• GOAP — เหมาะเมื่อต้องการลำดับ action ที่ปรับตัวและเกิดขึ้นเองจริง ๆ (emergent) ในโลกที่มี action และ world state จำนวนมาก จนการนั่งเขียนทุกเส้นทางด้วยมือไม่คุ้ม (กลยุทธ์หมู่ของ F.E.A.R.) ต้นทุนสร้าง ปรับจูน และดีบักสูงกว่า มักสงวนไว้ให้เกมทุนสูงหรือเกมที่มีระบบลึก
• Utility AI — เหมาะเมื่อการตัดสินใจโดยพื้นฐานคือ "ตัวเลือกไหนในหลาย ๆ ตัวที่ดีที่สุดตอนนี้" โดยผสมจากปัจจัยต่อเนื่อง เช่น ตัวละครสไตล์ The Sims ที่ชั่งน้ำหนักระหว่างความหิว ความเหนื่อย และความสนุก หรือหน่วยใน RTS ที่เลือกเป้าหมายจากหลายตัวในระยะ หลีกเลี่ยงการสลับแบบฉับพลันหักดิบที่ state machine หรือต้นไม้อาจเกิดขึ้นเมื่อค่าข้ามเกณฑ์ที่ตายตัว

กฎง่าย ๆ ที่ใช้งานได้จริง: เริ่มจากเครื่องมือที่เรียบง่ายที่สุดที่เหมาะกับงานจริง ๆ — มักเป็น FSM สำหรับโปรโตไทป์เล็ก ๆ — แล้วค่อยย้ายไป behavior tree ทันทีที่รู้สึกว่ากำลังสู้กับปัญหาตาราง transition จากข้อ 4 หยิบ GOAP หรือ Utility AI มาใช้ก็ต่อเมื่อมีการตัดสินใจที่เป็นรูปธรรมซึ่งเครื่องมือที่ง่ายกว่าแสดงออกมาให้ชัดเจนไม่ได้จริง ๆ ไม่ใช่เพราะมันฟังดูล้ำกว่า

12. ผสมผสานเทคนิค: ตัวอย่างไฮบริดที่ใช้งานจริง

เกมที่วางขายจริงแทบไม่เคยใช้แค่อันใดอันหนึ่งแบบโดด ๆ วิธีผสมที่พบบ่อยและใช้งานได้จริงคือ ใช้ Utility AI (หรือตัวเลือก goal แบบ GOAP เบา ๆ) หนึ่งครั้งในระดับหยาบเพื่อเลือกเป้าหมายระดับสูง แล้วส่งเป้าหมายนั้นให้ behavior tree ที่รู้วิธีลงมือทำทีละขั้น:

Utility AI เก่งเรื่องคำถามหยาบ ๆ ที่ต้องผสมหลายปัจจัยแบบ "ควรให้ความสำคัญกับอะไรตอนนี้" ส่วน behavior tree เก่งเรื่องการลงมือทำขั้นตอนที่เป็นรูปธรรมของสิ่งที่ชนะได้อย่างน่าเชื่อถือ ไม่มีเครื่องมือไหนต้องทำงานแทนอีกอัน รูปแบบเดียวกันนี้ใช้ได้กับ GOAP ที่มายืนแทนชั้นบนสุดเช่นกัน คือ GOAP ตัดสินใจลำดับ action ระดับสูง แล้วแต่ละ action นั้นก็อาจถูก implement เป็น behavior tree เล็ก ๆ ของตัวเองได้ ไม่มีกฎว่าโปรเจกต์ต้องเลือกใช้แค่หนึ่งในสี่ระบบนี้เท่านั้น เลือกตามปัญหาแต่ละอัน แล้วผสมมันเข้าด้วยกันตรงจุดที่ทำให้โค้ดง่ายขึ้นจริง ๆ

13. อภิธานศัพท์ (Glossary)

• AI agent — วัตถุในเกมที่กำลังตัดสินใจ: ศัตรู, NPC, ตัวช่วยเหลือ
• Decision-making — ส่วนของโค้ด agent ที่เลือกว่าจะทำ action ไหน
• Finite state machine (FSM) — ระบบที่อยู่ใน state ที่มีชื่อเรียกได้แค่หนึ่งอันเสมอ พร้อมกฎ transition ชัดเจนระหว่าง state
• State — โหมดพฤติกรรมหนึ่งที่มีชื่อเรียก (Patrol, Chase, Attack, ...)
• Transition — กฎที่สลับ FSM จาก state หนึ่งไปอีก state หนึ่ง
• Behavior tree (BT) — ต้นไม้ของ node ที่ถูก tick ตามลำดับความสำคัญ คืนค่า Success, Failure หรือ Running
• Tick — การประเมินหนึ่งรอบผ่าน behavior tree (หรือ node หนึ่งตัว) โดยปกติครั้งละหนึ่งเฟรม
• Composite node — node ของ behavior tree ที่มีลูกและรวมผลลัพธ์ของลูกเข้าด้วยกัน (Sequence, Selector)
• Leaf node — node ของ behavior tree ที่ไม่มีลูก ทำหน้าที่เช็คหรือลงมือทำจริง (Condition, Action)
• Sequence node — รันลูกจากซ้ายไปขวา หยุดและ fail ที่ลูกตัวแรกที่ล้มเหลว สำเร็จก็ต่อเมื่อลูกทุกตัวสำเร็จ
• Selector node — รันลูกจากซ้ายไปขวา หยุดและสำเร็จที่ลูกตัวแรกที่สำเร็จ ล้มเหลวก็ต่อเมื่อลูกทุกตัวล้มเหลว
• Running — สถานะ node ที่แปลว่า "ยังทำงานไม่เสร็จ ให้ tick อีกครั้งในเฟรมถัดไป"
• GOAP (Goal-Oriented Action Planning) — ระบบที่ planner ค้นหาชุด action (ที่มี precondition และ effect) เพื่อหาลำดับที่พาไปถึง goal
• Precondition — สิ่งที่ต้องเป็นจริงอยู่แล้วในโลกก่อน action จะทำได้
• Effect — สิ่งที่กลายเป็นจริงในโลกเมื่อ action ทำเสร็จ
• Planner — อัลกอริทึมที่ค้นหาลำดับ action ที่ถูกต้องและต้นทุนต่ำที่พาไปถึง goal
• World state — ชุดข้อเท็จจริงแบบ true/false ที่เกี่ยวข้อง ซึ่ง GOAP planner ใช้คิด (HasAmmo, InCover, ...)
• Utility AI — ระบบที่ให้คะแนน action ที่เป็นไปได้ทุกตัวด้วยฟังก์ชัน แล้วรันตัวที่คะแนนสูงสุด
• Score / utility function — สูตรที่แปลงสถานการณ์ปัจจุบันให้กลายเป็นตัวเลขเดียวสำหรับ action หนึ่งตัว
• Spaghetti code — โค้ดที่พันกันจนการตามรอยส่วนหนึ่งต้องดึงส่วนอื่นที่ไม่เกี่ยวข้องเข้ามาด้วยจำนวนมาก

14. แบบฝึกหัด

public class FleeState : IEnemyState
{
    public void Enter(EnemyAI enemy)
    {
        Debug.Log("Enter Flee");
    }

    public void Tick(EnemyAI enemy)
    {
        enemy.RunAwayFromPlayer();

        if (enemy.Health > 50)
        {
            enemy.ChangeState(new PatrolState());
        }
    }
}

// And inside EACH of PatrolState.Tick, ChaseState.Tick, AttackState.Tick,
// as the very first check:
if (enemy.Health <= 20)
{
    enemy.ChangeState(new FleeState());
    return;
}

root = new Selector(
    new Sequence(
        new ConditionNode(HeardNoise),
        new ActionNode(Investigate)
    ),
    new Sequence(
        new ConditionNode(CanSeePlayer),
        new ActionNode(Chase)
    ),
    new ActionNode(Patrol)
);

bool HeardNoise() { /* check a recent noise event */ return false; }
bool CanSeePlayer() { /* raycast toward the player */ return false; }

NodeStatus Investigate()
{
    Debug.Log("Investigating noise...");
    return NodeStatus.Running;
}

NodeStatus Chase()
{
    Debug.Log("Chasing...");
    return NodeStatus.Running;
}

NodeStatus Patrol()
{
    Debug.Log("Patrolling...");
    return NodeStatus.Running;
}

Flee   : (1 - 60/100) * 10 = 0.4 * 10 = 4.0
Attack : Ammo <= 0, so Score() returns 0 immediately, regardless of distance
Patrol : constant                                                    = 1.0

Winner: Flee, with a score of 4.0