5.4 Unity กับ Unreal — เลือกและสลับ

1. สองเอนจิน งานเดียวกัน

ก่อนหน้านี้คุณเขียน C# สำหรับสคริปต์ MonoBehaviour ของ Unity และเขียน C++ สำหรับโค้ดระดับเอนจินมาแล้ว บทนี้จะเอาเอนจินเชิงพาณิชย์จริงสองตัวมาเทียบกัน คือ Unity กับ Unreal Engine (มักเรียกสั้น ๆ ว่า "Unreal" หรือ "UE") ทั้งคู่ถูกใช้สร้างเกมจริงที่วางขายจริง คำถามไม่ใช่ "ตัวไหนดีกว่ากัน" แต่เป็น "ตัวไหนเหมาะกับงานที่คุณอยากทำ และการสลับไปมาระหว่างสองตัวนี้ต้องแลกด้วยอะไรบ้าง"

บทนี้เป็นบทเปรียบเทียบ ไม่ใช่การสอนเอนจินตัวใดตัวหนึ่งใหม่ทั้งหมด ถ้าเจอศัพท์ที่ไม่คุ้น จะอธิบายทันทีตอนที่มันโผล่มาครั้งแรก จบบทนี้แล้วคุณควรอ่านประกาศรับสมัครงานที่เขียนว่า "Unity/C#" หรือ "UE5/C++" แล้วรู้ทันทีว่างานประจำวันจะเป็นแบบไหน

game engine (เอนจินเกม) คือซอฟต์แวร์ที่แก้ปัญหายาก ๆ ที่ต้องทำซ้ำ ๆ ไว้ให้แล้ว — render พิกเซล, เล่นเสียง, จัดการ input, รัน physics, โหลด asset — เพื่อให้คุณโฟกัสที่กติกาของเกมตัวเองได้ Unity กับ Unreal ทำหน้าที่นี้ทั้งคู่ ไม่มีตัวไหนเป็น "เคล็ดลับ" ที่ทำให้เกมดี แต่ละตัวคือโรงงานที่คุณใช้สร้างเกม

เอนจินสองตัวนี้ trade-off กันแทบทุกจุด: ภาษาที่คุณเขียน, หน้าตาโปรเจกต์ใหม่ก่อนที่คุณจะแตะอะไรเลย, แพลตฟอร์มที่มันถูก tune มาให้ และใครมักจ้างงานเอนจินไหน trade-off พวกนี้ไม่เกี่ยวกับความสามารถดิบ ๆ เลย เพราะทั้งสองเอนจินสร้างเกม gacha บนมือถือหรือเกมยิงคอนโซล AAA ได้ทั้งคู่ในทางเทคนิค ความต่างอยู่ที่ว่าเส้นทางไหนถูกปูทางไว้ดีกว่ากัน

2. ภาษาและการเขียนสคริปต์: C# vs C++ กับ Blueprint

ใน Unity โค้ด gameplay เกือบทั้งหมดคือ C# คุณเขียนสคริปต์ แนบมันเข้ากับ GameObject (object ที่วางอยู่ใน scene) ในฐานะ MonoBehaviour (base class ที่สคริปต์ Unity สืบทอดมา) แล้ว Unity จะเรียก method บางตัวในเวลาที่กำหนด — Start() ครั้งเดียวตอนที่มันเข้ามาใน scene ครั้งแรก, Update() ทุกเฟรม

using UnityEngine;

public class Health : MonoBehaviour
{
    public int maxHP = 100;
    private int hp;

    void Start()
    {
        hp = maxHP;
        Debug.Log("Health ready: " + hp + " HP");
    }

    public void TakeDamage(int amount)
    {
        hp -= amount;
        if (hp <= 0)
        {
            Debug.Log("Character died");
        }
        else
        {
            Debug.Log("HP left: " + hp);
        }
    }
}

เรียก TakeDamage(30) แล้วตามด้วย TakeDamage(90) จากสคริปต์อื่น จะพิมพ์:

Health ready: 100 HP
HP left: 70
Character died

ใน Unreal แนวคิดเดียวกันนี้มีอยู่ แต่เครื่องมือแบ่งออกเป็นสองชั้น C++ คือภาษาสำหรับตัวเอนจินเองและสำหรับโค้ด gameplay ที่ต้อง performance สูงหรือเป็นโครงสร้างพื้นฐาน ส่วน Blueprint คือ visual scripting layer (ชั้นการเขียนสคริปต์แบบมองเห็นภาพ) — คุณต่อ logic ด้วยการลาก node มาเชื่อมกันแทนการพิมพ์ตัวหนังสือ และมัน compile ออกมาเป็น bytecode จริง ไม่ใช่ของเล่น รูปแบบที่สตูดิโอมักใช้คือ: engineer เขียน "ชิ้นส่วนพื้นฐาน" เป็น C++ แล้วเปิดให้ใช้งานได้ จากนั้น designer เอาชิ้นส่วนพวกนั้นมาต่อกันใน Blueprint เพื่อทดลองปรับ feel ของ gameplay ได้เร็ว ๆ

นี่คือไอเดีย Health เดียวกันเขียนเป็น Unreal C++ (โปรเจกต์จริงจะแยกไฟล์นี้เป็น .h กับ .cpp แต่เอามารวมกันตรงนี้เพื่อประหยัดพื้นที่):

#include "CoreMinimal.h"
#include "GameFramework/Actor.h"
#include "HealthActor.generated.h"

UCLASS()
class AHealthActor : public AActor
{
    GENERATED_BODY()

public:
    int32 MaxHP = 100;

    void TakeDamage(int32 Amount);

protected:
    virtual void BeginPlay() override;

private:
    int32 HP;
};

void AHealthActor::BeginPlay()
{
    Super::BeginPlay();
    HP = MaxHP;
    UE_LOG(LogTemp, Log, TEXT("Health ready: %d HP"), HP);
}

void AHealthActor::TakeDamage(int32 Amount)
{
    HP -= Amount;
    if (HP <= 0)
    {
        UE_LOG(LogTemp, Log, TEXT("Character died"));
    }
    else
    {
        UE_LOG(LogTemp, Log, TEXT("HP left: %d"), HP);
    }
}

เรียก TakeDamage(30) แล้วตามด้วย TakeDamage(90) จะพิมพ์เรื่องเดียวกัน แค่ไปที่ Output Log ของ Unreal แทน Console ของ Unity:

LogTemp: Health ready: 100 HP
LogTemp: HP left: 70
LogTemp: Character died

logic เดียวกัน ผลลัพธ์เดียวกัน แค่ syntax ต่างกันและมีระบบ macro ต่างออกไป (UCLASS(), GENERATED_BODY(), UE_LOG) ห่อรอบมันอยู่ designer ที่ไม่เคยเปิดไฟล์ C++ นั้นเลยก็สร้างพฤติกรรม BeginPlay แบบเดียวกันเป๊ะได้ด้วยภาพ:

ในชีวิตประจำวัน สิ่งนี้เปลี่ยนวิธีทำงานของคุณ ใน Unity คุณแทบจะเขียน C# ตลอดเวลา ใน Unreal คุณต้องสลับหมวกตลอด: ใช้ C++ เมื่อต้องการ performance ดิบ ๆ หรือสร้างระบบที่ใช้ซ้ำได้ ใช้ Blueprint เมื่อกำลังทดลองปรับ feel ของ gameplay อย่างรวดเร็ว

3. ภาพที่ได้ตั้งแต่แกะกล่อง: สมจริงสุด ๆ vs ยืดหยุ่นสูง

สร้างโปรเจกต์ใหม่เปล่า ๆ ในแต่ละเอนจินแล้วดูแสงเริ่มต้น ความต่างเห็นได้ทันที

renderer เริ่มต้นของ Unreal มี Lumen (ระบบคำนวณแสงสะท้อนแบบสมจริงแบบเรียลไทม์ โดยไม่ต้อง bake อะไรเองด้วยมือ) และ Nanite (ระบบที่ให้คุณใช้ mesh คุณภาพระดับภาพยนตร์ที่มีรายละเอียดเยอะมาก โดยไม่ต้องสร้างเวอร์ชันย่อสำหรับระยะไกลเอง — เวอร์ชันย่อพวกนั้นเรียกว่า LOD) รวมกันแล้วทำให้ scene ใหม่ของ Unreal ดูใกล้เคียง photoreal (ย่อจาก photorealistic คือใกล้เคียงภาพถ่ายจริง) แทบจะทันที นี่คือเหตุผลหลักที่ Unreal โผล่บ่อยในงาน cinematic และงาน virtual production ของหนัง/ทีวี

Unity ไม่ได้มี renderer ระดับสูงตัวเดียวตายตัว แต่คุณต้องเลือก Scriptable Render Pipeline (SRP ระบบ render ที่สลับได้): URP (Universal Render Pipeline — เบา เร็ว ปรับให้รันได้ตั้งแต่ PC ระดับท็อปไปจนถึงมือถือระดับกลาง) หรือ HDRP (High Definition Render Pipeline — หนักกว่า เล็งไปที่ภาพระดับสูงบน PC/console ใกล้เคียงกับที่ Unreal ให้มาเป็นค่าเริ่มต้น) scene ใหม่ของ Unity เริ่มต้นแบบเรียบ ๆ แล้วคุณค่อยสร้างลุคขึ้นมาเอง

ไม่มีแนวทางไหน "ดีกว่า" อีกฝ่ายจริง ๆ หรอก ทั้งคู่ optimize เพื่อเป้าหมายต่างกัน Unreal optimize ให้ดูดีโดยที่คุณต้อง tune เองน้อยลง ส่วน Unity optimize ให้คุณคุม performance ได้เอง ซึ่งสำคัญมากเมื่อเป้าหมายของคุณคือมือถืออายุสามปี ไม่ใช่ gaming PC

4. แพลตฟอร์มเป้าหมาย: จุดแข็งของแต่ละเอนจินอยู่ตรงไหน

ทั้งสองเอนจินในทางเทคนิค export ไปได้แทบทุกแพลตฟอร์ม — มือถือ, PC, console, web แต่คำว่า "ทำได้" กับ "ถูก tune มาให้เป็นค่าเริ่มต้น โดยไม่ต้องฝืนเอนจินเยอะ" เป็นคนละคำถามกัน

ขนาดที่เบากว่าเป็นค่าเริ่มต้นของ Unity และประวัติศาสตร์ยาวนานบนฮาร์ดแวร์มือถือ ทำให้มันเป็นตัวเลือกที่ใช้งานได้จริงสำหรับเกมที่ต้องรันดีบนมือถืออายุห้าปีแบตน้อย ๆ — ซึ่งตรงกับตลาด live-service บนมือถือส่วนใหญ่ (เกมที่ยังคงปล่อยเนื้อหาใหม่ตามตารางเวลาต่อเนื่อง ไม่ใช่ปล่อยครั้งเดียวแล้วจบ) พลังภาพเริ่มต้นและเครื่องมือสำหรับ console ของ Unreal ทำให้มันเป็นตัวเลือกที่ใช้งานได้จริงสำหรับเกมที่จุดขายทั้งหมดคือ "ดูภาพนี้สิ"

5. ใครใช้เอนจินไหนบ้าง

คุณเห็นแพทเทิร์นของแพลตฟอร์มนี้ได้จากเกมจริงที่วางขายแล้ว:

นี่คือเหตุผลที่คำตอบของ "ควรเรียนเอนจินไหน" เปลี่ยนไปตามเป้าหมาย เกมทั้งหมดที่ HoYoverse วางขายแล้ว รันบน Unity หมด สตูดิโอเกมยิง console งบสูงมีโอกาสสูงกว่ามากที่จะใช้ Unreal สตูดิโอ indie แบ่งกันคร่าว ๆ ตาม genre กับความทะเยอทะยาน — เกมเล็ก ๆ แบบ 2D หรือ 3D สไตล์การ์ตูนมักเอียงไปทาง Unity ส่วนเกมเล็ก ๆ ที่ไล่ตามลุคแบบภาพยนตร์มักเอียงไปทาง Unreal

6. Learning curve: ตัวไหนเริ่มง่ายกว่า

สำหรับคนที่เรียนเอนจินเป็นครั้งแรก Unity มักเป็นทางลาดที่นุ่มนวลกว่า C# เป็น managed language (runtime จัดการ memory ให้คุณเอง ไม่ต้องคอยจด allocation/free เองแบบ C++ ดิบ ๆ) สคริปต์หนึ่งไฟล์คือหนึ่งไฟล์ และ Unity compile ให้ใหม่อัตโนมัติในไม่กี่วินาทีทุกครั้งที่คุณ save

ฝั่ง C++ ของ Unreal หนักกว่า: ตั้งค่าโปรเจกต์ใหญ่กว่า, compile time นานกว่าเมื่อแก้อะไรใหญ่ ๆ และมี codebase ของเอนจินขนาดมหึมาซ่อนอยู่ใต้โค้ดของคุณเอง นั่นคือต้นทุนจริงตอนที่คุณยังเรียนอยู่ แต่ Unreal ผ่อนหนักเป็นเบาด้วย Blueprint — การทดลองช่วงแรก ๆ ของผู้เรียนใหม่ส่วนใหญ่เกิดขึ้นใน visual graph ล้วน ๆ โดยไม่ต้องผ่านขั้นตอน compile C++ เลย

ตรงนี้แหละที่บทก่อน ๆ ที่คุณเรียนมาจะคุ้มค่า ถ้าคุณเคยฝ่าฟันเรื่อง pointer, stack vs heap และ undefined behavior ในบท C มาแล้ว C++ ของ Unreal จะน่ากลัวน้อยกว่ามากเมื่อเทียบกับคนที่เจอ C++ เป็นครั้งแรกในอ้อมกอดของ codebase เอนจินยักษ์

7. แนวคิดถ่ายทอดกันได้: รูปทรงเดียวกัน ชื่อต่างกัน

นี่คือข้อเท็จจริงที่มีประโยชน์ที่สุดในบทนี้: ใต้ชื่อที่ต่างกัน Unity กับ Unreal ใช้ โครงสร้างแกนกลางเดียวกัน มีบางอย่างอยู่ในโลกเกมในฐานะ object; object นั้นถือ component ที่ให้ data กับ behavior กับมัน; component เหล่านั้นรันโค้ดของตัวเองตามจังหวะ lifecycle ที่กำหนดไว้แน่นอน

ย้อนไปดูตัวอย่าง Health ในหัวข้อ 2 Start() กับ BeginPlay() คือไอเดียเดียวกัน แค่ชื่อต่างกัน: "รันสิ่งนี้ครั้งเดียว ตอนที่ฉันเพิ่งโผล่มา" MonoBehaviour กับ AActor ทั้งคู่คือ "base type ที่สิ่งของในโลกเกมสืบทอดมาจาก" Unity Prefab (template ที่บันทึกไว้ ใช้ซ้ำได้ — สร้างศัตรูตัวเดียวแล้ว stamp ออกมาสิบตัว) กับ Unreal Blueprint Class (class ที่คุณสร้างด้วยภาพ แล้ววาง instance ได้หลายตัว) แก้ปัญหาเดียวกันเป๊ะ: กำหนดครั้งเดียว ใช้ซ้ำได้ทุกที่

นั่นแปลว่าการเรียนเอนจินตัวหนึ่งให้ลึกไม่ใช่การเสียเวลาเปล่า ถ้าวันหนึ่งคุณต้องใช้อีกตัว คุณไม่ได้เริ่มจากศูนย์ คุณแค่แปะป้ายชื่อใหม่ให้กับรูปทรงที่คุณเข้าใจอยู่แล้ว ส่วนที่ใหม่จริง ๆ ตอนสลับเอนจินคือเครื่องมือกับ syntax (ขั้นตอน compile C++, editor แบบ node-graph, ชื่อเมนูที่ต่างกัน) ไม่ใช่ไอเดียเบื้องหลัง

8. เทียบกันแบบเคียงข้าง

เอาหกหัวข้อที่ผ่านมารวมเป็นตารางเดียว:

ไม่มีอะไรในตารางนี้เป็นกฎตายตัว Unity ก็มีเกม HDRP ระดับสูงวางขายอยู่ Unreal ก็มีเกมมือถือเบา ๆ วางขายอยู่ อ่านมันในฐานะ "เส้นทางที่ปูทางไว้ดีมันพาไปทางไหน" ไม่ใช่ "อะไรทำได้บ้างในทางกายภาพ"

9. สรุปว่าควรทำอะไรจริง ๆ: HoYoverse vs สาย AAA กว้าง ๆ

จากทั้งหมดข้างบน นี่คือการแบ่งแบบใช้งานได้จริง:

ถ้าเป้าหมายของคุณคือ HoYoverse โดยเฉพาะ (หรือสตูดิโอ live-service gacha แบบ mobile-first ที่คล้ายกัน) — เจาะลึก Unity กับ C# ไปเลย เกมทั้งหมดที่พวกเขาวางขายรันบน Unity หมด นี่ไม่ใช่การเดา มันคือ stack จริงของบริษัทเลย ให้ priority กับ: พื้นฐาน C# ที่แน่น (ซึ่งคุณมีอยู่แล้วจากบทก่อน ๆ), URP, performance กับการ profile บนมือถือ, ระบบ UI และแพทเทิร์นแบบ "เนื้อหาที่ปล่อยตามตาราง" ที่เกม live-service ต้องพึ่งพา เวลาที่ใช้ไปกับ Unreal แทนไม่ได้ผิดอะไร แต่มันไม่ใช่การใช้เวลาที่มีจำกัดอย่างมีประสิทธิภาพที่สุดสำหรับเป้าหมายนี้โดยเฉพาะ

ถ้าเป้าหมายของคุณคือสาย AAA กว้าง ๆ หรือคุณยังไม่รู้จริง ๆ ว่าอยากไปสตูดิโอไหน — เรียนทั้งคู่ แต่ไม่พร้อมกันและไม่ลึกเท่ากันตั้งแต่วันแรก เริ่มจาก Unity ก่อน มันเป็นทางลาดที่นุ่มนวลกว่า และเพราะหัวข้อ 7 ทุกอย่างที่คุณเรียนรู้เกี่ยวกับรูปทรง GameObject/Component/lifecycle ถ่ายทอดตรงไปได้เลย พอรูปทรงนั้นกลายเป็นเรื่องธรรมชาติแล้ว ค่อยย้ายไปเรียน C++ กับ Blueprint ของ Unreal คุณจะใช้เวลาไปกับการเรียนชื่อใหม่และเครื่องมือใหม่ ไม่ใช่ concept ใหม่ ดังนั้นเอนจินตัวที่สองควรไปได้เร็วกว่าตัวแรกอย่างเห็นได้ชัด

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

• Engine — ชั้นซอฟต์แวร์ที่จัดการ rendering, input, physics, และการโหลด asset เพื่อให้คุณโฟกัสที่กติกาเกมได้
• GameObject (Unity) / Actor (Unreal) — "สิ่งของ" ที่วางอยู่ใน scene/level
• Component — ก้อนของ data กับ behavior ที่แนบอยู่กับ GameObject/Actor
• Prefab (Unity) / Blueprint Class (Unreal) — template ที่บันทึกไว้ ใช้ซ้ำได้ แก้ไขได้ วาง instance ออกมาได้หลายตัว
• MonoBehaviour — base class ที่สคริปต์ Unity สืบทอดมา
• AActor — base class ที่ object ส่วนใหญ่ที่วางได้ใน Unreal สืบทอดมา
• Start() / BeginPlay() — รันครั้งเดียวตอนที่ object เข้ามาในโลกเกม (Unity / Unreal)
• Update() / Tick() — รันทุกเฟรม (Unity / Unreal)
• Blueprint — visual scripting layer แบบต่อ node ของ Unreal; compile ได้จริง ไม่ใช่ของเล่น
• SRP (Scriptable Render Pipeline) — ระบบ render ที่สลับได้ของ Unity
• URP / HDRP — pipeline เบา เป็นมิตรกับมือถือ / pipeline หนัก ระดับสูง ของ Unity
• Lumen / Nanite — ระบบแสงสะท้อนแบบเรียลไทม์ / ระบบ mesh รายละเอียดสูงมาก ของ Unreal
• Photoreal — ย่อจาก "photorealistic" คือดูใกล้เคียงภาพถ่ายจริง
• Live-service — เกมที่ยังคงปล่อยเนื้อหาใหม่ตามตารางเวลาต่อเนื่องหลังเปิดตัว
• Gacha — โมเดลการหารายได้/เนื้อหาที่สร้างขึ้นจากการสุ่มดึงตัวละครหรือไอเทม

11. แบบฝึกหัด

public class Mover : MonoBehaviour
{
    public int distance = 0;
    public int speed = 4;

    void Update()
    {
        distance += speed;
        if (distance > 10)
        {
            Debug.Log("Reached checkpoint at distance " + distance);
        }
    }
}

สรุปแบบตรงไปตรงมา: Unity กับ Unreal เป็นชุดเครื่องมือคนละชุดที่สร้างอยู่บนไอเดียเดียวกัน เลือกตัวที่ตรงกับที่ที่คุณอยากทำงานจริง ๆ เจาะลึกตัวนั้นก่อน แล้วมองอีกเอนจินเป็นแค่ปัญหาที่ต้องไปเปิดดูทีหลัง — โมเดล object, component, และ lifecycle ที่คุณรู้อยู่แล้วจะยังอยู่ตรงนั้น แค่ใส่ชื่อคนละชื่อเท่านั้นเอง