18.2 Game Jam

คุณน่าจะเคยเริ่มโปรเจกต์เกมมาห้าโปรเจกต์ แล้วทำเสร็จไปศูนย์โปรเจกต์เลย นั่นคือแพทเทิร์นปกติของมือใหม่ และเป็นเหตุผลใหญ่ที่สุดข้อเดียวที่ทำให้มือใหม่ยังคงเป็นมือใหม่อยู่ตลอด: การทำเกมให้เสร็จเป็นทักษะที่แตกต่างจากการเริ่มทำเกมโดยสิ้นเชิง และคุณจะเก่งขึ้นได้ก็ต่อเมื่อทำมันภายใต้ deadline จริง ๆ เท่านั้น game jam คือที่ที่คุณจะได้ฝึกการทำให้เสร็จ บทนี้จะพูดถึงว่า jam จริง ๆ แล้วคืออะไร jam หลัก ๆ ที่คุณเข้าร่วมได้ วิธีตัด idea ใหญ่ ๆ ให้เหลือแค่สิ่งที่สร้างได้ในหนึ่งสุดสัปดาห์ แผนงานแบบชั่วโมงต่อชั่วโมงสำหรับ 48 ชั่วโมง ลำดับการสร้างสิ่งต่าง ๆ สิ่งที่ต้องตัดทิ้งเมื่อเวลาใกล้หมด วิธีใช้ asset ฟรีโดยไม่ผิดกฎ วิธีเตรียมตัวล่วงหน้าเพื่อไม่ให้เสียเวลา jam ไปกับ boilerplate และหน้าตาของการ submit ที่ดีควรเป็นยังไง

1. Game Jam คืออะไร?

game jam คืออีเวนต์แบบ timeboxed (มีเวลาเริ่มตายตัวและเวลาจบตายตัว ไม่มีต่อเวลา) ที่คุณต้องสร้างเกมจากศูนย์จนถึงสถานะที่ submit ได้และเล่นได้จริงภายในกรอบเวลานั้น ความยาวที่พบบ่อยที่สุดคือ 48 ชั่วโมง (หนึ่งสุดสัปดาห์) หรือ 72 ชั่วโมง (สุดสัปดาห์ยาว) พอถึงเวลาเริ่มพอดี ผู้จัดจะประกาศ theme (ธีม) — คำหรือวลีสั้น ๆ เช่น "Roles Reversed" หรือ "รวมสองแนวเกมที่ไม่น่าจะเข้ากันได้" — แล้วผู้เข้าร่วมทุกคนต้องเชื่อมเกมของตัวเองเข้ากับธีมนั้นไม่ทางใดก็ทางหนึ่ง ตามที่ตัวเองตีความ

ไม่มีใครรู้ธีมล่วงหน้า นั่นคือประเด็นสำคัญ: คุณสร้างเกมไว้ล่วงหน้าเป็นเดือน ๆ แล้วแปะธีมทับตอนท้ายไม่ได้ (เอาจริงก็มีคนพยายามทำแบบนั้นเหมือนกัน แต่มันมักจะดูออก) คุณเริ่มจากศูนย์จริง ๆ — ดีไซน์เป็นศูนย์ อาร์ตเป็นศูนย์ โค้ดเป็นศูนย์ ยกเว้น template ที่ reuse ได้ที่คุณเตรียมไว้เองล่วงหน้า ซึ่งหัวข้อ 5 จะพูดถึง

หลัง deadline jam ส่วนใหญ่จะมี rating period (ช่วงให้คะแนน) ที่แยกออกมาต่างหากและยาวกว่า — เป็นวันหรือสัปดาห์ที่ผู้เข้าร่วมทุกคนไปเล่นและให้คะแนนเกมของคนอื่น หัวข้อ 11 จะพูดถึงว่าต้องทำอะไรบ้างในช่วงนั้น

2. ทำไม "การทำให้เสร็จ" คือทักษะที่ Jam สอนคุณ

ลองเปิดโฟลเดอร์โปรเจกต์ของตัวเองดูตอนนี้เลย ถ้ามี มันน่าจะหน้าตาประมาณนี้:

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

Jam ตัดข้ออ้างทั้งสองอย่างนี้ออกไปพร้อมกัน deadline เป็นเรื่องจริงและเปิดเผยต่อสาธารณะ — หน้า submit ปิดตรงเวลาเป๊ะ ไม่มีข้อยกเว้น คนดูก็เป็นเรื่องจริงเหมือนกัน — ผู้เข้าร่วม jam คนอื่น ๆ จะเปิดเกมของคุณเล่นจริงและให้คะแนนจริง ซึ่งแปลว่า "ทำให้เสร็จ ไม่งั้นไม่มีใครได้เห็นเลย" ไม่ใช่แค่สมมติฐาน ภายใต้แรงกดดันนี้ คุณถูกบังคับให้ฝึกทักษะที่งานสตูดิโอจริงต้องใช้ทุกวัน: ตัดสินใจว่าอะไรจำเป็นจริง ๆ กับอะไรแค่ดีถ้ามี ตัดฟีเจอร์ทิ้งภายใต้ deadline ส่งของที่ไม่สมบูรณ์ตรงเวลาแทนที่จะรอของสมบูรณ์แบบที่ไม่มีวันเสร็จ และแพ็กเกจ build ให้คนแปลกหน้ารันได้จริง ไม่มีอะไรในนี้จะโผล่มาให้เห็นถ้าคุณมีเวลาไม่จำกัดในโปรเจกต์เดี่ยว แต่ทั้งหมดนี้จะโผล่มาให้เห็นภายใน 48 ชั่วโมง

3. Jam หลัก ๆ และวิธีเข้าร่วม

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

• Ludum Dare — jam ที่จัดโดยชุมชนที่เก่าแก่ที่สุด จัดปีละสามครั้ง จริง ๆ แล้วมันมีสองแทร็ก: Compo (48 ชั่วโมง เดี่ยวเท่านั้น และคุณต้องสร้างทุก asset เอง — อาร์ต เพลง โค้ด — ภายใน 48 ชั่วโมงนั้น) กับ Jam (72 ชั่วโมง มีทีมได้ ใช้ asset สำเร็จรูปได้) มือใหม่มักเริ่มจากแทร็ก Jam เพราะมีทีมและ asset จากภายนอกช่วยลดความกดดันลง
• Global Game Jam (GGJ) — jam ที่ใหญ่ที่สุดในโลกนับตามจำนวนผู้เข้าร่วม จัดในสุดสัปดาห์เดียวกันทุกเดือนมกราคม จัดพร้อมกันในสถานที่จริงหลายร้อยแห่งทั่วโลก (มหาวิทยาลัย สตูดิโอ พื้นที่ชุมชน) รวมถึงแบบออนไลน์เต็มรูปแบบด้วย ธีมจะประกาศในงาน keynote สดตอนเริ่มงาน 48 ชั่วโมง
• GMTK Game Jam — จัดปีละครั้งโดย Mark Brown เจ้าของช่อง YouTube Game Maker's Toolkit ปกติมีผู้เข้าร่วมเกิน 100,000 คน ทำให้เป็น jam ที่มีธีมเดียวใหญ่ที่สุดในแทบทุกปี 48 ชั่วโมง ธีมเดียว การมองเห็นสูงมากถ้าเกมของคุณโดดเด่น
• itch.io community jams — itch.io (เว็บโฮสต์เกม indie ที่ jam ส่วนใหญ่ก็ submit ไปที่นี่อยู่แล้ว) มีปฏิทิน jam สาธารณะที่รวม jam ที่จัดโดยชุมชนเป็นพัน ๆ งานตลอดทั้งปี ทุกความยาว ทุกธีมที่นึกออก ถ้าอยากจอย jam สุดสัปดาห์นี้เลย มีโอกาสสูงมากที่จะมีงานจัดอยู่แล้ว

การเข้าร่วมแต่ละที่ก็ขั้นตอนพื้นฐานเดียวกัน: สร้างบัญชีฟรีบน itch.io เข้าไปที่ itch.io/jams หา jam ที่กำลังเปิดรับสมัครอยู่ แล้วกด "Join Jam" ก่อนงานเริ่ม พอถึงเวลาเริ่ม ธีมจะถูกประกาศบนหน้า jam นั้น คุณสร้างเกมไปตลอดระยะเวลาของ jam แล้ว submit หน้าเกมของคุณ (พร้อม build ที่เล่นได้แนบมาด้วย) ก่อน deadline หลาย jam ยังคาดหวัง — หรือถึงขั้นบังคับ — ให้คุณไปให้คะแนนเกมของคนอื่นสักสองสามเกมหลังจากนั้น ซึ่งหัวข้อ 11 จะพูดถึง

4. Scope คือเกมทั้งเกม: ตัด Idea ให้เหลือแค่ขนาดสุดสัปดาห์

Scope หมายถึงทุกอย่างที่สิ่งที่เสร็จแล้วต้องมีจริง ๆ — ไม่ใช่แค่ "ฟีเจอร์" แต่รวมถึงหน้าเมนูทุกหน้า อาร์ตทุกชิ้น เสียง effect ทุกเสียง ด่านทุกด่าน บั๊กทุกตัวที่ต้องแก้ และตัว build ที่ export ออกมาด้วย มือใหม่มักคิดว่า scope คือ "กลไกเจ๋ง ๆ ที่ฉันอยากได้" แล้วลืมไปว่าเมนูหลักที่ใช้งานได้จริง วิธีแพ้เกม และไฟล์ .exe ที่ export แล้วไม่ crash ก็เป็นส่วนหนึ่งของ scope เหมือนกัน

นี่คือกฎที่มีประโยชน์ที่สุดข้อเดียวสำหรับ jam: idea แรกของคุณใหญ่เกินไปเสมอ นี่ไม่ใช่แค่ "อาจจะ" — มันเกือบจะเป็นกฎธรรมชาติไปแล้ว ทันทีที่ธีมถูกประกาศ สมองคุณจะตื่นเต้นและจินตนาการถึงเวอร์ชันที่ทะเยอทะยานที่สุดของเกมรอบธีมนั้น ไม่ใช่เวอร์ชันขั้นต่ำที่สร้างได้จริง idea แรกของทุกคน ทุก jam ต้องถูกตัดลง มักจะมากกว่าหนึ่งครั้งด้วยซ้ำ

นี่คือตัวอย่างที่ลงมือทำจริงของกระบวนการตัดนี้ เริ่มจาก idea ที่ใหญ่เกินไปจริง ๆ:

สังเกตว่าอะไรรอดมาถึง v3: ยังมี player action ที่ชัดเจน (โจมตี หลบ) มีภัยคุกคามที่ชัดเจน (มอนสเตอร์เป็นเวฟ) มีกรอบแพ้/ชนะที่ชัดเจน (รอดให้นานที่สุด) และมี hook คะแนนที่ชัดเจน (วินาทีที่รอดชีวิต ซึ่งใครก็ตามที่มาให้คะแนนอ่านเข้าใจทันที) สิ่งที่ถูกตัดออกคือทุกอย่างที่ทำให้ปริมาณเนื้อหาที่ต้องสร้างเพิ่มขึ้นทวีคูณ — หมู่บ้านทั้งหมู่บ้าน ไอเทม craft สิบชิ้น ตัว generator แบบ procedural — โดยไม่ได้ทำให้ 10 วินาทีแกนกลางของ gameplay สนุกขึ้นเลย

กระบวนการที่ทำซ้ำได้: เขียน idea ของคุณลงเป็นประโยคเดียว สำหรับทุกคำนามและคำกริยาในประโยคนั้น ถามว่า "ตัดสิ่งนี้ออกแล้วยังเป็นเกมอยู่ไหม?" ตัดไปเรื่อย ๆ จนกว่าจะตัดอะไรเพิ่มไม่ได้แล้วโดยไม่เสีย "ความเป็นเกม" ไปทั้งหมด — พูดให้ชัดคือ จนกว่าการตัดอีกสิ่งเดียวจะทำให้เงื่อนไขชนะ เงื่อนไขแพ้ หรือ input แกนกลางหนึ่งอย่างที่ผู้เล่นต้องเรียนรู้หายไป

5. เตรียม Template Project ที่ Reuse ได้ก่อน Jam เริ่ม

48 ชั่วโมงของ jam มีไว้สำหรับสร้างส่วนที่เป็นของใหม่จริง ๆ ใน idea ของคุณ ไม่ใช่เอาไว้แก้ปัญหาที่คุณเคยแก้ไปแล้วในโปรเจกต์ก่อนหน้า — วิธีสลับ scene วิธีเล่นเสียง effect วิธีอ่าน input จากผู้เล่น ทุกชั่วโมงที่เสียไปกับการสร้าง boilerplate พวกนี้ใหม่ระหว่าง jam คือชั่วโมงที่ไม่ได้ใช้กับกลไกแกนกลางของคุณ ทางแก้ง่ายมาก: สร้าง template project เล็ก ๆ ในเวลาว่างของตัวเอง ก่อน jam ไหนจะเริ่ม แล้ว copy มันเป็น commit แรกสุดของทุกโปรเจกต์ jam ที่คุณทำ

อย่างน้อยที่สุด template ของ jam ควรแก้ปัญหาสามอย่างนี้ไว้แล้ว: อ่าน input ของผู้เล่นในที่เดียว โหลด scene และเล่นเสียง นี่คือจุดเริ่มต้นกระชับ ๆ สำหรับแต่ละอย่าง โดยใช้แพทเทิร์นที่เรียกว่า singleton (คลาสที่รับประกันว่ามีอินสแตนซ์ของตัวเองอยู่แค่ตัวเดียว และเรียกใช้ได้จากทุกที่ผ่าน static field ชื่อ Instance — มีประโยชน์ตรงนี้เพราะคุณอยากได้ audio manager แค่ตัวเดียวและ scene loader แค่ตัวเดียวสำหรับทั้งเกม ไม่ใช่ตัวละหนึ่งต่อ scene)

using UnityEngine;

// One place that reads raw input, so gameplay code never calls
// Input.GetAxis directly. Swap the inside of this file for a new
// control scheme without touching any other script in the jam.
public class InputReader : MonoBehaviour
{
    public static InputReader Instance { get; private set; }

    public Vector2 Move { get; private set; }
    public bool JumpPressed { get; private set; }

    void Awake()
    {
        Instance = this;
    }

    void Update()
    {
        Move = new Vector2(Input.GetAxisRaw("Horizontal"), Input.GetAxisRaw("Vertical"));
        JumpPressed = Input.GetButtonDown("Jump");
    }
}

using UnityEngine;
using UnityEngine.SceneManagement;

// Put this on an empty GameObject in a "Bootstrap" scene that loads
// first. It survives every later scene load, so any script anywhere
// can call SceneLoader.Instance.LoadScene(...) without a reference.
public class SceneLoader : MonoBehaviour
{
    public static SceneLoader Instance { get; private set; }

    void Awake()
    {
        if (Instance != null && Instance != this)
        {
            Destroy(gameObject);
            return;
        }
        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    public void LoadScene(string sceneName)
    {
        SceneManager.LoadScene(sceneName);
    }
}

using UnityEngine;

// Also lives in the Bootstrap scene. Anything in the jam game can
// call AudioManager.Instance.PlaySfx(clip) starting hour 1, instead
// of you rebuilding an audio system at hour 30.
public class AudioManager : MonoBehaviour
{
    public static AudioManager Instance { get; private set; }

    public AudioSource musicSource;
    public AudioSource sfxSource;

    void Awake()
    {
        if (Instance != null && Instance != this)
        {
            Destroy(gameObject);
            return;
        }
        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    public void PlaySfx(AudioClip clip)
    {
        sfxSource.PlayOneShot(clip);
    }

    public void PlayMusic(AudioClip clip)
    {
        if (musicSource.clip == clip) return;
        musicSource.clip = clip;
        musicSource.loop = true;
        musicSource.Play();
    }
}

ลองไล่ trace guard clause ใน SceneLoader และ AudioManager ดู: สมมติว่าคุณเผลอทิ้งสำเนาที่สองของ Bootstrap object ไว้ใน scene Level1 ของคุณ จากการทดสอบครั้งก่อน พอ Level1 โหลดทับ Bootstrap scene จริง Unity จะเรียก Awake บน AudioManager ทั้งสองตัว ตัวแรก (ตัวจริง ที่เป็น Instance อยู่แล้ว) เจอว่า Instance != null && Instance != this เป็น false สำหรับตัวมันเอง เลยทำงานต่อตามปกติ ตัวที่สอง (สำเนาที่เผลอทิ้งไว้ใน Level1) เจอว่า Instance ถูกตั้งเป็นอ็อบเจกต์อื่นไปแล้ว เงื่อนไขเลยเป็นจริง แล้วมันก็ทำลายตัวเองทันที ผลลัพธ์: มี AudioManager รอดอยู่แค่ตัวเดียวเสมอ ไม่ว่าจะมีสำเนาเผลอโหลดมากี่ตัวก็ตาม และคุณจะไม่ได้ยินเพลงซ้อนกันสองเพลงเลย ถ้าไม่มี guard clause นี้ ทั้งสองตัวจะรอด แล้วคุณจะเจอบั๊กแบบนั้นเป๊ะ — ซึ่งก็คือ Exercise 3 ท้ายบทนี้ด้วย

6. แผนแบบชั่วโมงต่อชั่วโมงสำหรับ Jam 48 ชั่วโมง

ตารางเวลาคร่าว ๆ ช่วยไม่ให้คุณค้างที่ชั่วโมงที่ 0 หรือมารู้ตัวตอนชั่วโมงที่ 40 ว่ายังไม่มีอะไรทำงานเลย นี่ไม่ใช่กฎตายตัว — ปรับให้เข้ากับความเร็วของตัวเองได้ — แต่ checkpoint สำคัญกว่าตัวเลขชั่วโมงที่แน่นอน

Checkpoint ชั่วโมงที่ 12 คือบรรทัดที่สำคัญที่สุดในตารางทั้งหมดนั้น "เล่นได้ภายในชั่วโมงที่ 12" หมายความว่าคนอื่นนั่งลงแล้วกดปุ่มทำ core action ของเกมคุณได้จริง — แม้จะเป็นกล่องสีเทาแทนอาร์ต แม้จะไม่มีเสียงเลยก็ตาม ถ้าถึงชั่วโมงที่ 12 แล้วยังไม่ถึงจุดนั้น ทางเลือกที่ซื่อตรงคือตัด scope เพิ่มทันทีตรงนั้นเลย ไม่ใช่ดันต่อไปโดยหวังว่าจะ "ตามทัน" ทีหลัง jam ไม่ได้ให้รางวัลกับความมองโลกในแง่ดีเรื่องชั่วโมงที่เหลือ มันให้รางวัลกับสิ่งที่รันได้จริงตอน deadline มาถึง

อีก checkpoint หนึ่งที่ควรจำไว้คือ "submit แต่เนิ่น ๆ" สร้าง package ที่ export แล้ว submit ได้จริงตัวแรกให้เสร็จก่อน deadline จริงมาก ๆ — ประมาณชั่วโมงที่ 44 ถึง 46 ในตารางข้างบน — เพราะการ export อาจล้มเหลว เว็บอัปโหลดอาจช้าลงตอนใกล้ deadline ที่ทุกคนอัปโหลดพร้อมกัน และคอมพิวเตอร์ของคุณเองก็อาจ crash ในจังหวะที่แย่ที่สุดได้ build หยาบ ๆ ที่ submit ตอนชั่วโมงที่ 45 ดีกว่า build สมบูรณ์แบบที่อัปโหลดไม่เสร็จตอนชั่วโมงที่ 48

7. Vertical Slice ก่อน: สร้างส่วนที่สนุกก่อนเมนู

vertical slice หมายถึงเส้นทางบาง ๆ หนึ่งเส้นที่ลัดผ่านทั้งเกม ทำงานได้สมบูรณ์ตั้งแต่ต้นจนจบ แทนที่จะให้ทุกระบบถูกสร้างครึ่ง ๆ กลาง ๆ พร้อมกันหมด ชื่อนี้มาจากการจินตนาการเกมของคุณเป็นเลเยอร์วางซ้อนกันตามแนวนอน (เมนู ด่าน 1 ด่าน 2 enemy AI เสียง) — vertical slice คือการตัดตรงลงมาผ่านทุกเลเยอร์พร้อมกัน แต่กว้างแค่พอที่จะพิสูจน์ว่า loop เต็มรูปแบบหนึ่งรอบทำงานได้จริง

การสร้างส่วนที่สนุก — core mechanic — ก่อนเมนู ไม่ใช่แค่ความชอบส่วนตัวเรื่องสไตล์ มีเหตุผลที่จับต้องได้สองข้อ ข้อแรก ถ้า core mechanic ไม่สนุก สิ่งอื่นที่คุณสร้างต่อจะไม่มีความหมายเลย และคุณต้องรู้เรื่องนี้ให้เร็วที่สุดในขณะที่ยังมีเวลาเปลี่ยนทิศทางได้ — เมนูหลักที่สวยงามติดอยู่กับกลไกที่น่าเบื่อ ก็ยังเป็นเกมที่น่าเบื่ออยู่ดี ข้อสอง คนให้คะแนน jam ส่วนใหญ่ใช้เวลาไม่ถึงนาทีต่อเกม — นาทีนั้นควรถูกใช้เล่น core loop ของคุณ ไม่ใช่คลิกผ่านหน้าไตเติลกับเมนู option กว่าจะไปถึง เกม jam สามารถ ถ้าเวลาหมดจริง ๆ เริ่มผู้เล่นเข้า gameplay ตรง ๆ โดยไม่มีเมนูหลักเลยก็ได้ แล้วแทบไม่เสียอะไรเลยด้วยซ้ำ

ลำดับการทำงานที่เป็นรูปธรรมซึ่งตามมาจากเรื่องนี้:

• 1. Core mechanic เล่นได้ด้วยกล่องสีเทา ไม่มีอาร์ตเลย
• 2. Loop เต็มรูปแบบหนึ่งรอบ: เริ่ม ทำ action ชนะหรือแพ้ เริ่มใหม่
• 3. UI ขั้นต่ำที่จำเป็นต่อการเข้าใจกฎ (คะแนน เลือด เวลา)
• 4. เนื้อหา: ด่านเพิ่ม เวฟเพิ่ม หรือ enemy type เพิ่ม โดยใช้กลไกเดิมซ้ำ
• 5. อาร์ตพาส
• 6. เสียงพาส
• 7. เมนูหลัก — ใช่ ทำทีหลังสุด ถ้าเวลาหมดก่อนถึงตรงนี้ก็ยอมรับได้
• 8. Polish และแก้บั๊กด้วยเวลาที่เหลือ

8. สิ่งที่ต้องตัดเมื่อเวลาใกล้หมด และสิ่งที่ห้ามตัดเด็ดขาด

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

เรียงลำดับคร่าว ๆ จาก "ตัดอันนี้ก่อนเลย ไม่มีใครคิดถึงมันหรอก" ไปจนถึง "ตัดอันนี้เป็นทางเลือกสุดท้ายจริง ๆ เท่านั้น":

• Multiplayer หรือ networking — ถ้าเคยอยู่ใน scope ควรถูกตัดไปตั้งแต่หัวข้อ 4 แล้ว ถ้าแอบหลุดเข้ามาอยู่ดี ตัดมันตอนนี้เลย
• Procedural generation — แทนที่ด้วยด่านที่สร้างมือหนึ่งหรือสองด่าน สร้างมือทำให้เชื่อถือได้เร็วกว่าในเวลาที่เหลืออยู่
• ด่านเพิ่มเติมเกินหนึ่งหรือสองด่าน — ด่านดีหนึ่งด่านดีกว่าด่านพังสามด่าน
• Enemy หรือ mechanic type เพิ่มเติมเกินหนึ่งหรือสองแบบแรก — reuse สิ่งที่ทำงานอยู่แล้วแทนที่จะเพิ่มของใหม่ที่ต้องเทสต์ใหม่
• ระบบเซฟ — แทบไม่มีเกม jam ไหนต้องการมันเลย เพราะ jam session เล่นจบในรอบเดียว
• เมนู settings — ค่า default ที่คงที่และสมเหตุสมผล (volume, resolution) ก็พอแล้ว
• ข้อความ tutorial หรือด่าน tutorial — แทนที่ด้วยข้อความบนหน้าจอบรรทัดเดียวที่บอก control ตามหัวข้อ 10
• เพลงพื้นหลัง — อย่างน้อยเก็บเสียง effect พื้นฐานไว้เป็น feedback (เสียงโดนตี เสียงได้คะแนน) ความเงียบที่ไม่มี audio feedback เลยจะรู้สึกเหมือนพังทั้งที่จริง ๆ ไม่ได้พัง
• Polish ด้านภาพเพิ่มเติม particle effect, screen shake — ดีถ้ามี แต่ไม่จำเป็นจริง ๆ

มีสองอย่างที่ไม่มีวันอยู่ในลิสต์ที่ตัดได้ ไม่ว่าจะเหลือเวลาน้อยแค่ไหน:

เช็คตัวเองแบบเร็ว ๆ ก่อน submit: เอา build ให้เพื่อนลอง ต่อหน้าหรือผ่านคอล ไม่พูดอะไรเลย แล้วดูว่าเกิดอะไรขึ้นใน 30 วินาทีแรก ถ้าตอนนั้นเขากำลังทำ core action ของเกมคุณอยู่แล้ว แปลว่าเสร็จ ถ้าเขากำลังจ้องจอดำหรือถามว่า "เอ๊ะ เริ่มยังไง" ให้แก้จุดนั้นก่อนแตะอย่างอื่นเลย — มันสำคัญกว่างาน polish ที่เหลือทุกอย่างในลิสต์ของคุณ

9. ใช้ Asset ฟรีอย่างถูกกฎหมาย และให้เครดิต

ไม่มีใครคาดหวังให้คุณวาดสไปรท์ทุกชิ้นและแต่งเพลงทุกเพลงเองตั้งแต่ต้นภายใน 48 ชั่วโมง — ยกเว้นกรณีเดียว: บาง jam อย่างแทร็ก Compo ของ Ludum Dare จากหัวข้อ 3 กำหนดชัดเจนว่าต้องสร้างทุก asset เองในช่วงเวลา jam เป็นส่วนหนึ่งของความท้าทาย เช็คกฎของ jam ที่คุณเข้าร่วมก่อนเสมอ นอกเหนือจากแทร็กเดี่ยวที่เข้มงวดแบบนั้น การใช้ asset ฟรีหรือมีไลเซนส์ถือเป็นเรื่องปกติและคาดหวังได้เลย

แหล่งที่พบบ่อย: kenney.nl (คลังอาร์ตเกมขนาดใหญ่ เกือบทั้งหมดปล่อยเป็น CC0) opengameart.org (อาร์ตและเพลงที่มีไลเซนส์ปนกัน — เช็คหน้า asset แต่ละชิ้นเอง) freesound.org (เสียง effect ไลเซนส์ Creative Commons ปนกัน) และตลาด asset ของ itch.io (บาง pack ฟรี บางอันเสียเงิน ไลเซนส์ระบุไว้ในแต่ละหน้า)

ไลเซนส์บน asset แต่ละชิ้นบอกว่าคุณทำอะไรกับมันได้บ้าง สามแบบที่คุณจะเจอบ่อยที่สุด:

• CC0 (Creative Commons Zero) — ถือว่าเป็น public domain แทบจะเต็มตัว ไม่จำเป็นต้องให้เครดิตตามกฎหมาย แต่การให้เครดิตอยู่ดีก็เป็นมารยาทที่สุภาพในวงการ jam
• CC-BY (Creative Commons Attribution) — ใช้ได้ฟรี แต่ต้องให้เครดิต ปกติในรูปแบบเฉพาะที่ผู้สร้างขอไว้ (ชื่อเขา ลิงก์กลับไปที่ asset)
• EULA (End User License Agreement) เฉพาะของ asset นั้น ๆ — อ่านก่อนสมมติอะไรทั้งนั้น บาง pack ฟรีห้ามใช้เชิงพาณิชย์ ซึ่งสำคัญมากถ้าเกม jam ในอนาคตกลายเป็นอะไรที่คุณอยากขาย (หัวข้อ 11)

การให้เครดิตทำง่ายมาก: เพิ่มไฟล์ CREDITS.txt เข้าไปใน build หรือทำ section credits บนหน้า itch.io ของคุณ ระบุ asset แต่ละชิ้น ผู้สร้าง ไลเซนส์ และลิงก์

CREDITS

Music: "Chiptune Adventure" by KubaAudio (CC-BY 4.0)
  https://opengameart.org/example-music-page

SFX: Kenney "Interface Sounds" pack (CC0)
  https://kenney.nl/assets/interface-sounds

Font: "Press Start 2P" by CodeMan38 (OFL)
  https://fonts.google.com/specimen/Press+Start+2P

10. Submit: ชื่อเรื่อง, GIF, และ Controls

หน้า itch.io ของคุณคือความประทับใจแรกของเกม และมันเกิดขึ้นก่อนที่ใครจะกดเล่นด้วยซ้ำ สามอย่างบนหน้านั้นสำคัญกว่าที่มือใหม่คิดไว้มาก:

• ชื่อเรื่องที่ดี เฉพาะเจาะจงและจำง่าย ถ้าเชื่อมกับธีมได้ยิ่งดี "Untitled Game" หรือ "My Jam Game" จะถูกเลื่อนผ่านไปในลิสต์เกมเป็นร้อย ๆ เกม ส่วนชื่อที่ใบ้มุกหรือกลไกของเกมจะถูกคลิก
• GIF หรือคลิปสั้น ๆ ของ gameplay จริงบนหน้า — ไม่ใช่แค่ screenshot หน้าไตเติลนิ่ง ๆ คนให้คะแนนส่วนใหญ่ตัดสินใจว่าจะดาวน์โหลดหรือเล่นเกมคุณหรือเปล่าจากสิ่งที่เห็นบนหน้าก่อนคลิกอะไรเลยด้วยซ้ำ และภาพนิ่งของเมนูก็ไม่บอกอะไรเลยว่าตัวเกมเองดีหรือไม่
• Control ที่ชัดเจน เขียนเป็นข้อความธรรมดาบนหน้าโดยตรง "WASD เดิน, Space กระโดด, คลิกซ้ายโจมตี" คุณไม่สามารถยืนข้าง ๆ ทุกคนที่เปิด submission ของคุณเพื่ออธิบายได้ — หน้าเพจต้องทำหน้าที่นั้นแทนคุณ

เลือก web build (WebGL หรือชื่อ export ที่ engine ของคุณใช้เรียก browser export) มากกว่า zip ที่ต้องดาวน์โหลด ทุกครั้งที่ engine รองรับ คนให้คะแนนมีโอกาสสูงกว่ามากที่จะคลิก "play in browser" ตรงนั้นเลย มากกว่าจะดาวน์โหลด zip แตกไฟล์ แล้วรัน .exe ที่ไม่มีลายเซ็นจากคนแปลกหน้าผ่าน antivirus warning — friction ตรงจุดนี้ทำให้คุณเสียยอดเล่นและคะแนนไปตรง ๆ

11. หลัง Jam จบ: ให้คะแนน, รับ Feedback, และตัดสินใจว่าจะขยายต่อไหม

การ submit ไม่ใช่จุดจบเป๊ะ ๆ มีสองอย่างที่ควรทำทันทีหลังจากนั้น และหนึ่งการตัดสินใจที่ควรทำเมื่อฝุ่นเริ่มจาง

อย่างแรก ให้คะแนนเกมของคนอื่น หลาย jam คาดหวังให้ทำแบบนี้ และบางงาน — ระบบจัดอันดับของ GMTK เป็นตัวอย่างที่รู้จักกันดี — ให้การมองเห็นเกมของคุณเองขึ้นอยู่กับว่าคุณให้คะแนนเกมคนอื่นไปกี่เกมด้วย นอกเหนือจากแรงจูงใจนั้น นี่คือหนึ่งในวิธีเรียนรู้ที่เร็วที่สุดจริง ๆ: คุณจะได้เห็นว่าคนอื่นอีกหลายสิบหรือหลายร้อยคนสร้างอะไรขึ้นมาภายใต้ธีมและเวลาจำกัดเดียวกันกับที่คุณมี ซึ่งทำให้เห็น idea เทคนิค และการตัดสินใจเรื่อง scope ที่คุณเองอาจไม่เคยคิดถึงได้ง่ายมาก

อย่างที่สอง อ่าน feedback ที่ได้รับ โดยไม่ต้องตั้งการ์ดป้องกันตัว comment และคะแนนที่ได้รวม ๆ กันจะบอกว่าอะไรเวิร์ก อะไรทำให้คนสับสน — ถ้าคนให้คะแนนห้าคนต่างพูดว่า "หนูไม่เข้าใจว่าโจมตียังไง" นั่นไม่ใช่ห้าคนไม่แฟร์กับคุณหรอก นั่นคือสัญญาณจริงว่ากฎ "เข้าใจได้ภายใน 30 วินาที" ในหัวข้อ 8 ของคุณยังไม่ค่อยเข้าเป้า มองหาแพทเทิร์นที่เกิดซ้ำในหลาย ๆ feedback แทนที่จะตอบสนองแรง ๆ กับ comment เดียว

อย่างที่สาม พอผ่านไปสักหนึ่งหรือสองสัปดาห์ ตัดสินใจว่าเกมนี้คุ้มค่าที่จะขยายเป็นอะไรที่ใหญ่กว่าไหม — portfolio piece ที่มีเนื้อหามากขึ้น อาร์ตดีขึ้น และ polish มากกว่าที่สุดสัปดาห์ jam จะให้ได้ ไม่ใช่ทุกเกม jam ที่สมควรได้รับสิ่งนี้ และนั่นก็โอเคเต็มที่ คุณค่าของแบบฝึกหัดนี้อยู่ที่การทำให้เสร็จ ไม่ใช่ทุกผลลัพธ์ต้องกลายเป็นของที่เก็บไว้ วิธีตัดสินใจที่สมเหตุสมผล: ถ้าคุณยังอยากเปิดมันขึ้นมาเล่นหลังจากห่างหายไปหนึ่งสัปดาห์ และ core mechanic ผ่านการทดสอบกับผู้เล่นคนอื่นด้วยดี (ไม่ใช่แค่ตัวคุณเอง) มันก็เป็นตัวเลือกที่ดีสำหรับการขยายแบบมี scope หลัง jam ถ้าทั้งสองอย่างนั้นไม่จริง ก็เก็บมันไว้เฉย ๆ เก็บส่วนที่ปรับปรุง template ระหว่างทาง (หัวข้อ 5) ไว้ใช้ต่อ แล้วเอาสิ่งที่เรียนรู้ไปใช้ใน jam ครั้งถัดไปแทน

12. ศัพท์สำคัญ

• Game jam — อีเวนต์แบบ timeboxed ที่คุณสร้างเกมจากศูนย์จนถึงสถานะ submit ได้และเล่นได้จริงภายในกรอบเวลาที่กำหนด ปกติ 48 ถึง 72 ชั่วโมง
• Timeboxed — มีเวลาเริ่มตายตัวและเวลาจบตายตัว ไม่มีต่อเวลา
• Theme — คำหรือวลีสั้น ๆ ที่ประกาศตอนเริ่ม jam ซึ่งทุกเกมที่ส่งเข้าประกวดคาดว่าจะเชื่อมโยงเข้ากับมันไม่ทางใดก็ทางหนึ่ง
• Compo — แทร็กเดี่ยวที่เข้มงวดของ Ludum Dare: 48 ชั่วโมง และทุก asset ต้องสร้างเองภายในกรอบเวลานั้น
• Rating period — ช่วงวันหรือสัปดาห์หลัง deadline ของ jam ที่ผู้เข้าร่วมเล่นและให้คะแนนเกมของกันและกัน
• Scope — ทุกอย่างที่เกมที่เสร็จแล้วต้องมีจริง ๆ: ทุกกลไก ทุกเมนู ทุก asset บั๊กทุกตัวที่แก้แล้ว และตัว build ที่ export ออกมาด้วย
• Core mechanic — action หรือระบบหลักหนึ่งเดียวที่ทั้งเกมถูกสร้างขึ้นรอบมัน
• Vertical slice — เส้นทางบาง ๆ หนึ่งเส้นที่ลัดผ่านทั้งเกม ทำงานได้สมบูรณ์ตั้งแต่ต้นจนจบ สร้างก่อนที่ระบบอื่นจะถูกขยาย
• Playable — อยู่ในสถานะที่คนอื่นนั่งลงแล้วทำ core action ของเกมได้จริง แม้จะไม่มีอาร์ตหรือ polish ก็ตาม
• Template project — โปรเจกต์เริ่มต้นเล็ก ๆ ที่เตรียมไว้ก่อน jam มีปัญหาที่แก้ไว้แล้วและ reuse ได้ เช่น การจัดการ input การโหลด scene และเสียง
• Singleton — คลาสที่รับประกันว่ามีอินสแตนซ์ที่ยัง alive อยู่แค่ตัวเดียว เรียกใช้ได้จากทุกที่ผ่าน static field ชื่อ Instance
• DontDestroyOnLoad — คำสั่งของ Unity ที่ทำให้ GameObject ยังอยู่รอดข้ามการโหลด scene แทนที่จะถูกทำลายไปพร้อมกับ scene เก่าของมัน
• CC0 — ไลเซนส์ Creative Commons ที่หมายถึง public domain แทบเต็มตัว ไม่จำเป็นต้องให้เครดิตตามกฎหมาย
• CC-BY — ไลเซนส์ Creative Commons ที่อนุญาตให้ใช้ฟรีแต่กฎหมายกำหนดให้ต้องให้เครดิตผู้สร้าง
• EULA — End User License Agreement เงื่อนไขเฉพาะที่ผูกกับ asset หรือ asset pack แต่ละชิ้น
• Build — แพ็กเกจเกมที่ export แล้วรันได้จริง (web build, executable ฯลฯ) ที่ผู้เล่นเปิดขึ้นมาใช้จริง
• Post-mortem — บันทึกทบทวนหลังโปรเจกต์หรือหลัง jam ว่าอะไรเวิร์ก อะไรไม่เวิร์ก และครั้งหน้าจะทำอะไรต่างออกไป

13. แบบฝึกหัด

using UnityEngine;

public class AudioManager : MonoBehaviour
{
    public static AudioManager Instance { get; private set; }

    public AudioSource musicSource;

    void Awake()
    {
        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    public void PlayMusic(AudioClip clip)
    {
        musicSource.clip = clip;
        musicSource.loop = true;
        musicSource.Play();
    }
}

using UnityEngine;

public class AudioManager : MonoBehaviour
{
    public static AudioManager Instance { get; private set; }

    public AudioSource musicSource;

    void Awake()
    {
        if (Instance != null && Instance != this)
        {
            Destroy(gameObject);
            return;
        }
        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    public void PlayMusic(AudioClip clip)
    {
        musicSource.clip = clip;
        musicSource.loop = true;
        musicSource.Play();
    }
}

บทนี้ครอบคลุมเรื่อง game jam แบบครบวงจร: jam คืออะไรจริง ๆ jam หลัก ๆ ที่เข้าร่วมได้ในปีนี้ ทำไม deadline เองถึงเป็นสิ่งที่สอนอะไรคุณได้ วิธีตัด idea ให้เหลือ scope ขนาดสุดสัปดาห์จริง ๆ แผนแบบชั่วโมงต่อชั่วโมงพร้อม checkpoint เล่นได้ที่หนึ่งในสี่ของเวลาแบบเข้มงวด การสร้างส่วนที่สนุกก่อนเมนู สิ่งที่ต้องตัดและกฎสองข้อที่ห้ามตัดเด็ดขาด การใช้ asset ฟรีโดยไม่ผิดไลเซนส์ของใคร การเตรียม template เพื่อให้ชั่วโมง jam ไปลงกับเกมจริงของคุณ และหน้า submission ต้องมีอะไรบ้างถึงจะได้ 30 วินาทีของคนแปลกหน้ามา ครั้งต่อไปที่คุณเห็นการประกาศธีม คุณจะรู้เส้นทางทั้งหมดจากศูนย์ไปจนถึงเกมที่เสร็จและ submit แล้วอยู่แล้ว