AI dan Claude Code untuk Praktik Game Design: Panduan Langsung Pakai

Tidak ada satu angka pun yang dibuat-buat — alur kerja AI yang saya jalankan selama enam bulan, dibuka seluruhnya hingga prompt, kode, dan verifikasinya

304 aturan, 48 alat, dan sistem otomasi yang benar-benar dioperasikan seorang direktur dengan pengalaman 24 tahun di sebuah tim berukuran menengah (10–50 orang) — apa adanya

Ditulis oleh Minsoo Lee · 2026

Seluruh isi buku ini mengacu pada paruh pertama 2026. Harga, model, dan fitur alat AI berubah dengan cepat, jadi mohon periksa angka spesifik dan cara pemasangan pada masing-masing halaman resmi untuk informasi terbaru.

Distribusi dan Hak Cipta Buku Ini

Buku ini dipublikasikan secara gratis dengan harapan dapat dibaca seluas-luasnya. Namun, baik versi asli berbahasa Korea maupun terjemahan Bahasa Inggris dan Jepang, satu hal harus tetap dipertahankan di mana pun: bahwa penulis asli buku ini adalah Minsoo Lee (이민수).

• Lisensi: Creative Commons Atribusi-NonKomersial-BerbagiSerupa 4.0 (CC BY-NC-SA 4.0)
• Penulis asli: Minsoo Lee (이민수), 2026
• Edisi resmi (canonical): https://eremes81.github.io/game-design-ai-practice (GitHub Pages penulis — edisi resmi yang hak penyuntingannya berada pada penulis)

Anda bebas melakukan hal berikut. Pembelajaran pribadi, berbagi dan mengutip untuk tujuan nonkomersial, penerjemahan nonkomersial, serta pemanfaatan untuk studi internal di kantor — selama Anda mencantumkan penulis asli beserta tautan edisi resmi, dan jika Anda mengubah isinya atau mengalihbahasakannya ke bahasa lain, sebutkanlah hal itu. Mohon bagikan pula karya turunan dengan ketentuan yang sama.

Mohon minta izin terlebih dahulu untuk hal berikut. Penerbitan atau penjualan komersial, penggunaan sebagai materi kursus berbayar, penyertaan dalam produk atau layanan perusahaan, serta redistribusi yang menghapus atribusi penulis asli.

Pengetahuan yang termuat dalam buku ini sudah lengkap dalam satu jilid, dan dengan sendirinya gratis. Jika buku ini bermanfaat dan Anda ingin mendukung penulis, saya akan berterima kasih bila Anda turut menyumbang lewat e-book resmi atau kit berbayar.

Kata Pengantar — Buku yang Ditulis Tiga Kali

Buku ini ditulis tiga kali.

Yang pertama bukanlah sebuah buku, melainkan manual internal. Selama enam bulan menjalankan alur kerja AI di perusahaan, saya membakukan keputusan, alat, dan prosedur ke dalam dokumen agar tim tidak perlu menanyakan aturan yang sama dua kali. Dokumen itu tidak dibuat untuk diterbitkan, melainkan dokumen operasional yang menumpuk demi mengurangi pengulangan harian. Dari sanalah kekonkretan buku ini berasal — artinya, fondasinya bukan kasus yang direka-reka demi sebuah buku, melainkan manual yang benar-benar berjalan.

Yang kedua adalah draf pertama yang memindahkan manual itu menjadi sebuah buku. Tetapi hasilnya malah menjadi generalisasi yang terdengar meyakinkan tentang "AI bisa melakukan hal-hal semacam ini". Tabelnya banyak, dan angka yang memperlihatkan dampaknya pun banyak. Sebagian besar angka itu diberi keterangan dengan huruf kecil "angka rekaan". Ketika saya membacanya ulang, justru itulah cacat terbesarnya. Saya berbicara tentang pemanfaatan AI tetapi tidak memperlihatkan layar yang sesungguhnya, dan berbicara tentang dampak tetapi mengangkat angka yang dibuat-buat. Saat memindahkan kekonkretan manual ke dalam buku, justru kekonkretan itulah yang hilang.

Maka untuk yang ketiga, saya menulis ulang semuanya. Inilah naskah yang kini ada di tangan Anda. Saya menghidupkan kembali kekonkretan manual internal, tetapi menjaga prinsip buku ini tetap sederhana.

Pertama, setiap bab memperlihatkan sesi nyata hingga tuntas. Saya memuat prompt lengkap yang saya ketik, keluaran mentah yang dilontarkan AI, apa yang saya tolak dari keluaran itu, hingga bagaimana saya memintanya kembali. Saya tidak mengakhiri bab dengan kalimat "AI yang mengerjakannya".

Kedua, angka hanya berasal dari salah satu dari tiga sumber. Standar publik yang dapat diperiksa siapa pun (harga token model, pedoman aksesibilitas), konstanta yang benar-benar tertanam dalam kode sistem saya, atau nilai yang secara eksplisit saya nyatakan sebagai "ini perkiraan saya". Tidak ada satu pun tabel penghematan biaya yang dibuat-buat. Kejujuran saya jadikan sebagai pembeda.

Ketiga, saya mengutip apa adanya sistem nyata yang telah saya jalankan selama enam bulan di lapangan. 304 decision card (atom), 48 alat (skill), hook yang secara otomatis menarik ingatan terkait pada setiap masukan, hingga struktur memori yang memungkinkan satu orang mengelola konteks kolaborasi setara empat orang. Bukan "suatu alat" yang abstrak, melainkan nama berkas, kode, dan skornya saya tulis apa adanya. Pada kasus-kasus di dalam buku, saya hanya menyamarkan nama perusahaan, proyek, dan rekan tim, tanpa menghapus kekonkretan alur kerjanya. (Perusahaan yang mengizinkan penerbitan buku ini saya sebut dengan nama sebenarnya pada bagian ucapan terima kasih — karena saya telah memperoleh persetujuannya.)

Saya seorang Game Designer dengan pengalaman 24 tahun. Saya memasuki industri ini lewat QA dan tinjauan untuk game single-player, lalu menghabiskan waktu membuat RPG, MMORPG, beserta variasinya — dari direktur sebuah MMORPG yang dilayankan ke puluhan negara, pengembangan awal MMORPG AAA berskala 200 orang, hingga Live Ops MMORPG mobile global. Saya terlibat dalam proyek seperti Ragnarok Online, Bless Online, dan seri Mir dengan berbagai peran — sebagai direktur, lead desain, System Designer, dan kadang PM — bahkan pernah mendirikan perusahaan game mobile kecil.

Sejujurnya, saya menyandang kursi direktur terlalu dini. Setelah itu, saya melewati masa panjang sebagai anggota tim: sebagai System Designer yang langsung menyentuh sheet data dan angka pertarungan, sebagai Content Designer yang memproduksi quest dan NPC baris demi baris, merancang event, dan memproduksi konten baru. Sebagian besar alur kerja dalam buku ini lahir dari kursi itu — kursi yang membuat tangan kotor secara langsung, bukan kursi orang yang mengelola — dengan tekad "bagaimanapun caranya saya ingin mengurangi pengulangan ini". Kini di lapangan saya memimpin sebuah tim berukuran menengah (10–50 orang) sebagai Design Director sebuah MMORPG, tetapi alat-alat dalam buku ini bukan alat manajemen seorang direktur, melainkan lahir dari tangan seorang praktisi. Oleh karena itu, sistem dalam buku ini bukanlah teori, melainkan lingkungan kerja yang berjalan setiap hari. Saya juga membahas dengan cara yang sama satu kasus game puzzle kecil yang saya buat sendiri di rumah — saya mengutip apa adanya commit git dan kode nyata game tersebut.

AI tidak dapat menggantikan pekerjaan seorang Game Designer. Namun, AI membebaskan tangan kita dari pekerjaan remeh. Apa yang akan dikerjakan dengan tangan itu tetap menjadi bagian manusia. Saya berharap buku ini menjadi panduan praktis untuk peralihan tersebut.

Cara Membaca Buku Ini

Buku ini tidak harus dibaca berurutan dari awal hingga akhir. Pilihlah jalur yang sesuai dengan situasi Anda. Jika Anda baru pertama kali berkenalan dengan terminal dan pemasangan, bukalah lebih dulu 1.0 "Sebelum Memulai" — bab yang lebih dahulu meredakan rasa takut terhadap layar hitam.

Di akhir setiap bab terdapat "Coba Sendiri". Tujuannya bukan bab yang dibaca lalu ditutup, melainkan membuat Anda menggerakkan tangan walau satu langkah saja di lingkungan Anda sendiri hari ini.

Satu hal lagi untuk Anda yang bekerja di luar game. Sebagian besar alur kerja dalam buku ini — mengubah notula rapat menjadi keputusan, melacak dampak sebuah keputusan, verification gate (gerbang verifikasi), pengelolaan biaya, hak cipta dan etika — bekerja apa adanya tanpa kaitan dengan game. Anda boleh membacanya dengan mengganti "game design" menjadi pekerjaan Anda sendiri. Kotak "Penerapan di Luar Game" di tiap bab adalah jembatannya, dan jika waktu Anda terbatas, dengan mengikuti kursus kilat 90 menit saja (17.1 → 16.2 → 22.1 → 21.1) Anda sudah dapat merasakan kerangka intinya dengan tangan sendiri.

Saya tegaskan satu pembedaan. Dalam buku ini, "solo" dipakai dengan dua makna. Yang satu adalah direktur solo — seorang lead yang memikul sendirian konteks kolaborasi setara beberapa orang — dan yang lain adalah developer solo · hobiis yang membuat game seorang diri. "Versi Ringkas Solo" di akhir tiap bab ditujukan untuk yang kedua, menuliskan jalur untuk mengambil hanya inti bab tersebut tanpa tim maupun folder perusahaan.

Buku ini boleh dibaca tuntas sebagai satu jilid, atau dibagi menjadi dua jalur — Bagian 1–15 'fondasi · bidang' dan Bagian 16–24 'proses · operasional' — dengan membaca lebih dulu sisi yang Anda butuhkan. Selain itu, sebagian besar kode dalam isi buku dapat dijalankan apa adanya tanpa dependensi eksternal, hanya dengan pustaka standar Python. Hanya sebagian alat seperti grafik relasi yang memerlukan paket di luar standar (networkx, PyYAML), dan di situ saya tuliskan satu baris pemasangan (pip install …) berdampingan dengan kodenya. Selain kasus tersebut, tanpa perlu mengunduh apa pun, Anda dapat menyalin blok kode dan langsung menjalankannya untuk memeriksanya.

Bila Anda tersangkut pada sebuah istilah, jangan berhenti di situ; lewati saja dulu. Asingnya terminal hitam bukanlah cacat alat, melainkan soal kebiasaan, dan jarak itu kita perpendek bersama di 1.0 dan Bagian 1.

Cara Pemanfaatan Termudah

Terakhir, saya bisikkan satu cara tercepat untuk memanfaatkan buku ini: membiarkan alat AI seperti Claude Code membaca buku ini secara utuh.

Buku ini tidak ditulis hanya untuk dibaca manusia. Prompt lengkap, kode, dan prosedur verifikasi tiap bab saya tulis dalam bentuk yang dapat dipahami dan direproduksi langsung oleh AI. Jadi, di folder proyek Anda sendiri, Anda dapat menyerahkan buku ini kepada AI — entah dalam bentuk PDF maupun teks — dan memintanya seperti "Baca pola pemeriksaan konsistensi dalam buku ini, lalu buatkan alat pemeriksa yang sesuai dengan sheet data kami". Maka AI akan memasang alur kerja bab terkait sesuai lingkungan Anda. Jalur membuat sendiri bab demi bab dengan tangan, dan jalur menyerahkan buku secara utuh kepada AI lalu membuatnya bersama-sama — keduanya sama-sama terbuka.

Hanya satu hal yang tidak berubah. Apa yang akan diadopsi dan apa yang akan ditolak — keputusan akhir itu, seperti yang berulang kali ditegaskan buku ini dari awal hingga akhir, tetap menjadi bagian Anda. Sekalipun Anda membiarkan AI membaca buku ini untuk memasang sistem, kursi untuk meninjau kandidat yang dilontarkan sistem itu tetap dijaga oleh manusia. Bahkan cara pemanfaatan termudah pun bekerja di atas prinsip tersebut.

Satu Janji

Tidak ada satu pun tabel dalam buku ini yang memuat "angka yang digelembungkan demi meyakinkan pembaca". Alih-alih melebih-lebihkan dampak, saya memperlihatkan struktur tempat dampak itu muncul. Jika Anda memindahkan struktur yang sama ke proyek Anda sendiri, angka Anda akan Anda ukur sendiri. Itulah bantuan paling jujur yang dapat buku ini berikan.

Janji di Balik Kata 'Rekonstruksi'

Dalam isi buku ini, keluaran worked transcript (rekaman sesi nyata) sering diberi keterangan 'rekonstruksi (reconstruction)' — misalnya seperti "Langkah 3 — Keluaran Claude (rekonstruksi)". Apa yang dipertahankan dan apa yang disentuh oleh kata ini, akan saya janjikan dengan tepat sekali saja. Sebab inilah tempat yang tidak boleh dibiarkan paling kabur oleh sebuah buku yang menjadikan kejujuran sebagai judulnya.

'Rekonstruksi' bukan berarti dibuat-buat, melainkan berarti sesi nyata yang disunting. Batasannya begini.

Dengan kata lain, pada keluaran yang direkonstruksi, saya tidak menambahkan angka yang menggelembungkan dampak ataupun keberhasilan yang tidak pernah ada. Saya hanya menyamarkan, mengutip, dan merapikannya agar sesuai dengan halaman. Tidak ada satu tempat pun yang keluaran gagalnya saya ubah menjadi keberhasilan — justru saya sengaja membiarkan kegagalannya. Sebab itulah tempat yang memperlihatkan apa yang ditolak manusia. (Sebaliknya, tempat yang saya tandai sebagai 'hasil ukur nyata' · 'dikutip apa adanya' untuk hasil eksekusi kode atau log sistem adalah yang dipindahkan tanpa penyuntingan.)

Catatan penerjemah: Edisi Bahasa Indonesia ini diterjemahkan dengan AI sebagai draf awal, lalu ditinjau dan disunting oleh manusia. Seluruh worked transcript dalam edisi ini adalah terjemahan dari sesi asli berbahasa Korea — bukan dijalankan ulang dalam Bahasa Indonesia. Prompt dan keluaran di dalam blok kode juga diterjemahkan agar mudah dibaca. Teks asli Korea — materi yang dijanjikan buku ini untuk tidak diubah — tetap dipertahankan apa adanya di edisi Korea (pada repository sumber di GitHub). Sintaksis kode, pengidentifikasi, angka, dan nilai verifikasi tidak diubah sama sekali. Konversi mata uang bersifat perkiraan, dengan kurs sekitar 1.500 won per dolar AS pada pertengahan 2026.

Bagian 1 · Pengenalan

1.0 Sebelum Memulai — Instalasi, Akun, Biaya, dan Kit Bertahan Terminal

Bab 1.1 adalah "pertemuan pertama". Itulah momen ketika Anda duduk di depan kursor yang berkedip dan mencoba mengetikkan sesuatu. Namun untuk bisa duduk di kursi itu, ada beberapa hal yang harus disiapkan lebih dulu. Alatnya sudah terpasang, Anda sudah masuk (login), Anda sudah punya gambaran kasar tentang bagaimana biaya dikenakan, dan Anda bisa mengetikkan beberapa karakter di layar hitam. Bab ini berada satu langkah sebelum 1.1.

Banyak buku pengantar melewatkan tahap ini. Mereka menulis satu baris saja, "Buka terminal," lalu melanjutkan. Padahal pemula justru tersangkut tepat pada satu baris itu. Di mana terminalnya, apa yang harus dipasang, dan apa yang harus dilakukan ketika tulisan merah muncul saat memasang — orang yang berhenti di baris pertama tidak akan pernah sampai ke 1.1. Tujuan bab ini hanya satu: memastikan Anda tidak tersangkut di baris pertama.

Bab ini terdiri atas lima bagian: instalasi, akun dan login, konsep paket biaya, kit bertahan terminal, dan daftar periksa "lima menit pertama menjalankan". Jika Anda mengikutinya secara berurutan, persiapan untuk duduk di kursi 1.1 akan selesai.

flowchart LR
    A["1.0 Tahap Persiapan
(bab ini)"] --> B["1.1 Pertemuan Pertama
(duduk di depan kursor)"]
    A1["① Instalasi"] --> A2["② Akun·Login"]
    A2 --> A3["③ Konsep Paket Biaya"]
    A3 --> A4["④ Kit Bertahan Terminal"]
    A4 --> A5["⑤ Lima Menit Pertama Menjalankan"]
    A5 --> B
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class A1,A2,A3,A4,A5 human
    class B pass

1.0.1 Instalasi — Satu Baris untuk Tiap OS

Prinsipnya, ikuti panduan resmi saat memasang. Alat sering berubah, dan berkas instalasi yang diunduh dari jalur tidak resmi itu berbahaya. Karena itu buku ini tidak mencantumkan tautan unduhan, melainkan memandu cara menemukan jalur resmi. Jika Anda mengetik "Claude Code dokumentasi resmi" atau "Claude Code install" di kotak pencarian, halaman dokumentasi resmi Anthropic akan muncul paling atas. Cara teraman adalah menggunakan perintah instalasi persis seperti yang tertera di halaman itu.

Ada baiknya Anda memahami gambaran besarnya. Claude Code (buku ini menyeragamkan penulisannya dalam bahasa Inggris) adalah alat yang berjalan di terminal, dan biasanya dipasang dengan perintah satu baris. Alurnya sedikit berbeda untuk tiap OS.

Pada ketiga OS, alurnya sama: "Buka terminal → tempelkan satu baris dari dokumentasi resmi → tekan Enter." Anda tidak perlu menghafal perintahnya. Yang baku adalah menyalin dan menempelkannya dari dokumentasi resmi.

Jika tulisan merah (error) muncul saat memasang, Anda tidak perlu panik. Error instalasi yang ditemui pemula umumnya salah satu dari dua hal: masalah izin, atau ketiadaan alat prasyarat (misalnya runtime seperti Node.js). Jika tulisan merah muncul, salin seluruh kalimat itu apa adanya lalu cari di mesin pencari atau tanyakan ke AI, dan sembilan dari sepuluh kali masalahnya akan terpecahkan. Pesan error bukanlah musuh, melainkan petunjuk.

Cara memastikan instalasi berhasil: ketik claude --version di terminal lalu tekan Enter. Jika satu baris nomor versi muncul, instalasi berhasil. Jika muncul pesan semacam "command not found" (perintah tidak ditemukan), berarti instalasi belum selesai atau Anda perlu membuka terminal yang baru. Tutup terminal sepenuhnya, buka kembali, lalu periksa sekali lagi.

1.0.2 Akun dan Login

Selesai memasang bukan berarti langsung bisa dipakai. Claude Code adalah alat yang meminjam model AI dari Anthropic, sehingga diperlukan tahap login untuk memastikan siapa yang memakainya.

Alurnya sederhana. Saat Anda menjalankan claude untuk pertama kali di terminal, panduan login akan muncul. Biasanya peramban web terbuka secara otomatis, dan di sana Anda cukup masuk dengan akun Anthropic (jika belum punya, Anda bisa membuatnya di layar itu juga). Setelah login selesai, peramban menampilkan panduan semacam "Anda sudah bisa kembali ke terminal," dan di sisi terminal pun muncul tanda selesai.

Ada dua titik yang sering menyangkut pemula di sini.

Pertama, kasus ketika peramban tidak terbuka secara otomatis. Dalam hal ini, sebuah alamat panjang (URL) ditampilkan dalam satu baris di terminal. Salin alamat itu, tempelkan ke kolom alamat peramban, lalu masuk. Anda tidak benar-benar tersangkut — hanya perlu satu langkah manual tambahan.

Kedua, kasus tertukar jenis akun. Bagaimana akun yang Anda pakai di obrolan web (Claude.ai) terhubung dengan akun dan biaya Claude Code bisa berbeda kebijakannya dari waktu ke waktu. Yang paling akurat adalah mengikuti panduan di layar login dan dokumentasi resmi. Jika Anda mengikuti apa yang diminta layar saat pertama dijalankan, login umumnya berjalan tanpa kendala.

Login cukup dilakukan sekali dan akan tetap tersimpan di PC tersebut. Anda tidak perlu mengulanginya setiap kali.

1.0.3 Konsep Paket Biaya — Langganan Tetap vs API Pakai-Bayar

Bagian yang paling membuat pemula cemas adalah "berapa biayanya nanti?". Ada ketakutan samar bahwa biaya bertambah setiap kali mengetik sebuah karakter. Jika Anda memahami gambaran besarnya lebih dulu, kecemasan ini akan berkurang. Cara penagihan secara garis besar terbagi dua.

Langganan tetap adalah cara membayar jumlah tertentu per bulan dan memakainya sampai batas kuota. Mirip paket tarif ponsel berlangganan. Karena jumlah yang keluar sama setiap bulan, prediksinya mudah dan Anda tidak perlu memikirkan "berapa biaya tiap baris yang saya ketik". Karena itu, biasanya pemula lebih tenang jika memulai dengan langganan tetap (perkiraan penulis — karena susunan paket dan kuota yang tepat berubah dari waktu ke waktu, periksa di halaman biaya resmi). Jika melewati kuota, Anda menunggu hingga siklus berikutnya atau menaikkan ke paket yang lebih tinggi.

API pakai-bayar adalah cara penagihan yang sebanding dengan jumlah yang benar-benar dipakai (token). Seperti meteran listrik, Anda ditagih sebanyak yang dipakai. Cara ini cocok untuk pemrosesan volume besar, alur kerja otomatis (pipeline), atau integrasi dengan program lain. Jika digunakan dengan cermat, ia efisien, tetapi pada tahap awal prediksi biayanya bisa sulit sampai Anda punya rasa terhadap volume pemakaian.

Apa itu token dan mengapa penagihan dilakukan berdasarkan token dibahas lebih rinci di 1.2 (Model AI·Token·Harness). Di sini Anda cukup mengingat satu hal saja. Pemula biasanya memulai dengan langganan tetap. Sebab jumlah tiap bulan tetap, sehingga Anda bisa berlatih tanpa rasa takut "jangan-jangan tiba-tiba kena tagihan besar saat dipakai". Karena nama paket, harga, dan kuota sering berubah, buku ini tidak mencantumkan angka tertentu. Isi buku ini ditulis dengan acuan pertengahan tahun 2026, dan paket biaya, model, serta fitur akan terus berubah setelahnya. Nilai terkini paling akurat diperiksa di halaman biaya resmi.

Ringkasan satu baris: ketakutan jangan-jangan biaya keluar tiap kali memakai → dengan langganan tetap, jumlahnya tetap setiap bulan. Untuk pemula, memulai dengan langganan tetap membuat hati lebih tenang.

1.0.4 Kit Bertahan Terminal — Mengurangi Rasa Takut pada Layar Hitam

Sekarang tembok terbesarnya: layar hitam. Inilah alasan mengapa 1.1 dimulai dengan "tersendat di depan kursor yang berkedip". Bagi tangan yang sudah 24 tahun bekerja dengan GUI, terminal terasa asing. Namun perintah yang dibutuhkan agar tidak tersangkut di baris pertama tidaklah banyak. Enam perintah berikut sudah cukup.

(Pada Windows PowerShell pun ls·cd·pwd tetap berfungsi. Di macOS·Linux juga sama. Karena itu enam perintah ini tidak memilih-milih OS.)

Jika fungsi keenam perintah ini digambarkan, hasilnya seperti berikut. Berpindah di terminal pada akhirnya hanyalah keluar-masuk folder, dan itu sama dengan tindakan klik ganda folder atau kembali ke belakang di GUI.

flowchart TD
    Q["pwd
Saya di mana ini?"] --> L["ls
Ada apa di sini?"]
    L --> D{"Apakah ada folder
untuk dimasuki?"}
    D -- "Ya" --> IN["cd nama_folder
Masuk"]
    D -- "Tidak, ke atas" --> UP["cd ..
Keluar"]
    IN --> L
    UP --> L
    RUN["Setelah mengetik perintah"] --> ENT["Enter
Jalankan"]
    STUCK["Saat sesuatu tampak berhenti"] --> STOP["Ctrl + C
Hentikan dan kembalikan kursor"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    class Q,L,IN,UP,ENT,STOP code
    class D human

Alasan sebenarnya layar hitam terasa menakutkan adalah perasaan "kalau salah ketik, sepertinya akan rusak". Namun di antara keenam perintah di atas tidak ada satu pun yang merusak sesuatu. pwd·ls·cd hanya melihat atau berpindah, tidak menghapus atau mengubah berkas. Enter hanyalah menjalankan, Ctrl + C hanyalah menghentikan. Jadi keenam perintah ini boleh Anda ketik dengan tenang kapan saja.

Ada kalanya layar tampak seperti berhenti. Yaitu ketika Anda sudah mengetik perintah tetapi lama tidak ada respons, atau kursor berkedip di baris lain seolah menunggu sesuatu yang lain. Saat itu, tekan Ctrl + C sekali dan biasanya Anda akan kembali ke kursor semula. Cukup dengan mengetahui bahwa ada "tombol stop" ini saja, layar hitam terasa jauh lebih tidak menakutkan. Jika tersangkut, keluar dengan Ctrl + C lalu mulai lagi.

Terakhir, ketika karakter yang Anda ketik menumpuk banyak dan terasa kacau, Anda bisa mengosongkan layar. Windows PowerShell·macOS·Linux semuanya mengosongkannya dengan perintah clear. Mengosongkan layar tidak menghilangkan apa yang sudah dikerjakan; hanya karakter yang terlihat saja yang dirapikan.

1.0.5 Daftar Periksa "Lima Menit Pertama Menjalankan"

Jika Anda sudah sampai di sini, persiapan sudah selesai. Jika Anda bisa melewati lima kolom berikut dalam waktu lima menit, Anda telah memenuhi syarat untuk duduk di kursi 1.1. Jika tersangkut pada satu kolom saja, kembalilah ke subbab terkait (1.0.1\~1.0.4).

flowchart LR
    C1["① Terminal
terbuka"] --> C2["② claude --version
versi muncul"]
    C2 --> C3["③ jalankan claude →
login selesai"]
    C3 --> C4["④ folder saya terlihat
dengan pwd·ls"]
    C4 --> C5["⑤ bisa keluar
dengan Ctrl+C"]
    C5 --> OK["✅ Lanjut ke 1.1"]
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class C1,C2,C3,C4,C5 human
    class OK pass

• [ ] ① Saya bisa membuka terminal (Windows: PowerShell / macOS: Terminal)
• [ ] ② Saat saya mengetik claude --version, satu baris nomor versi muncul (konfirmasi instalasi)
• [ ] ③ Saat saya menjalankan claude, saya sudah dalam keadaan login (atau login selesai sesuai panduan)
• [ ] ④ Saya bisa melihat lokasi saat ini dengan pwd dan isi folder dengan ls
• [ ] ⑤ Saat sesuatu berhenti, saya bisa keluar dengan Ctrl + C

Jika kelima kolom sudah terisi, layar hitam bukan lagi tembok yang misterius. Alatnya sudah terpasang, Anda sudah login, Anda tahu gambaran besar cara penagihan, serta bisa berpindah dan berhenti di dalam layar. Bab 1.1 dimulai di atas persiapan ini. Anda tinggal beranjak ke momen itu — duduk di depan kursor yang berkedip dan untuk pertama kalinya mengetik "ringkas apa saja yang ada di folder ini".

1.0.6 Python·pip — Kalau Mau Menjalankan Alatnya (hanya saat diperlukan)

Bagian awal buku ini (Bagian 1·2) bisa diikuti hanya dengan prompt berbahasa alami. Namun mulai Bagian 4, sebagian bab langsung menjalankan skrip Python kecil (misalnya pip install pyyaml, pip install pyvis). Tidak masalah jika Anda baru pertama kali berkenalan dengan Python. Ada dua jalan.

Pertama, jalan memasang sendiri. Python diunduh dan dipasang dari python.org (pada layar instalasi, jangan lupa centang "Add to PATH"), lalu dipastikan dengan python --version di terminal. pip adalah alat pemasang paket yang ikut terpasang bersama Python, sehingga paket yang Anda butuhkan bisa diambil dalam satu baris seperti pip install pyyaml.

Kedua, jalan menyerahkannya ke AI (disarankan). Jalan yang lebih mudah adalah menyuruh AI sendiri yang menyiapkan lingkungannya. Anda cukup memintanya seperti ini di terminal.

Periksa apakah Python sudah terpasang, dan jika belum, beri tahu cara instalasi yang sesuai dengan OS saya.
Lalu berikan perintah satu baris untuk memasang paket pyyaml yang diperlukan di bab ini.

AI akan memeriksa lingkungan Anda dan membuatkan perintah instalasinya. Jika tersangkut, di tempat itu juga tempelkan pesan error apa adanya lalu tanyakan "bagaimana cara mengatasi error ini?". Untuk tiap bab yang menjalankan alat, satu pola ini sudah cukup. Pada tahap di mana Python·pip terasa memberatkan, bagian "Versi Ringkas Solo" di bab tersebut memandu jalan yang lebih ringan tanpa kode.

Pratinjau Bab Berikutnya

• 1.1 Pertemuan Pertama Game Designer dengan Claude Code — bertahan 30 menit pertama di depan kursor

Coba Sendiri

setup 1. Bukalah terminal pada OS yang Anda pakai (Windows: PowerShell, macOS: Terminal). 2. Cari "Claude Code dokumentasi resmi" lalu buka halaman panduan instalasi resmi. 3. Setel pengatur waktu ke 5 menit — tujuannya adalah melewati lima kolom daftar periksa 1.0.5.

prompt (ketik satu per satu, secara berurutan. Ini perintah, bukan pertanyaan berbahasa alami)

① claude --version      # Jika versi muncul, instalasi berhasil
② pwd                   # Folder mana yang sedang saya tempati
③ ls                    # Ada apa di folder ini
④ cd ..                 # Keluar satu tingkat ke atas (lalu ls lagi)
⑤ claude                # Jalankan Claude Code (jika panduan login muncul, ikuti saja)

verify - Pada ①, jika satu baris nomor versi muncul, instalasi sudah selesai. Jika muncul "command not found", tutup terminal lalu buka kembali dan coba sekali lagi. - Selagi melihat dan berpindah folder dengan ②·③·④, pastikan sendiri bahwa tidak ada apa pun yang rusak. Ketiganya adalah perintah aman yang hanya melihat dan berpindah. - Jika tampak berhenti saat menjalankan ⑤, keluar dengan Ctrl + C. Jika Anda berhasil keluar, Anda telah membuktikan langsung melalui pengalaman bahwa "ada tombol stop".

Versi Ringkas Solo

Jika Anda perorangan yang tidak punya tim maupun folder perusahaan, kuasai dulu instalasi (①) dan keluar dengan Ctrl + C saja. Dengan memastikan "alatnya terpasang" lewat claude --version dan "saya bisa keluar walau tersangkut" lewat Ctrl + C, separuh dari rasa takut pada layar hitam bisa dibereskan sendirian dalam waktu lima menit. Untuk biaya, jika Anda memulai dengan langganan tetap, Anda bisa berlatih sepuasnya tanpa khawatir soal biaya.

1.1 Perjumpaan Pertama Seorang Game Designer dengan Claude Code

Layar hitam muncul. Kursor berkedip. Di hadapannya duduk seorang Game Designer dengan pengalaman 24 tahun. Tangan yang selama 24 tahun bekerja dengan PowerPoint dan Excel, wiki dan Figma, berhenti sejenak di atas keyboard. Sekilas teringat zaman ketika masih ada kursus komputer, mirip DOS. Setelah itu, benda bernama terminal hanyalah sesuatu yang terlihat di meja para programmer. Tidak tahu harus mengetik apa, dan rasanya kalau salah ketik, sesuatu akan rusak. Keraguan inilah titik awal buku ini.

Kebanyakan orang menutup jendelanya di titik ini. Lalu di rapat mereka kembali mengulang, "Kita juga harus mencoba sesuatu." Bab ini ikut duduk di posisi orang yang tidak menutup jendela itu dan bertahan selama 30 menit pertama. Tujuannya bukan strategi adopsi yang muluk-muluk, melainkan memberi Anda hal konkret untuk dipegang: apa yang bisa Anda ketik di depan kursor yang berkedip untuk mencairkan rasa asing itu.

Ketika seorang Game Designer pertama kali duduk di depan alat pengodean AI seperti Claude Code, rasa kagum dan rasa tidak nyaman muncul bersamaan di tempat yang sama. Fakta bahwa kedua emosi ini berbenturan justru menjadi petunjuk pertama dalam adopsi.

Alasan kagumnya jelas. Pemeriksaan konsistensi sheet data yang biasanya memakan setengah hari kini selesai dalam hitungan menit, notula rapat yang berlarut-larut diringkas menjadi tabel keputusan, dan dokumen desain yang terkubur setahun lalu bisa ditarik kembali hanya dengan satu kalimat bahasa sehari-hari.

Alasan tidak nyamannya pun sama jelasnya. Layar hitam, kursor yang berkedip, dan perintah berbahasa Inggris terlalu berbeda dari lanskap pekerjaan sehari-hari. Hari-hari seorang Game Designer mengalir di atas GUI, sementara tindakan mengetik huruf di terminal hitam terasa kurang menyatu dengan identitas profesi. Namun, rasa tidak nyaman ini bukan cacat alatnya, melainkan biaya adaptasi bagi orang yang sudah terbiasa dengan GUI. Hanya dengan mengakui satu hal ini saja, separuh rasa asing itu sudah terselesaikan.

Buku ini hadir untuk mengurangi rasa asing tersebut. Subbab 1.1 ikut duduk di tempat perjumpaan pertama dan merangkum apa yang perlu dilihat, apa yang perlu dicoba, dan apa yang boleh ditunda untuk sementara.

1.1.1 Mengapa Sekarang Seorang Game Designer Harus Menggunakan AI

Game design bergabung dengan arus AI lebih lambat dibanding profesi lain. Orang-orang yang menangani kode masuk lebih dulu, lalu diikuti desainer dan artis. Game Designer sering kali terjebak pola menunda sambil mengulang, "Kita juga harus mencoba sesuatu."

Alasan menundanya masuk akal. Hasil kerja seorang Game Designer tidak terstandardisasi seperti kode; teks, tabel, diagram, rapat, dan kesepakatan lisan tercampur menjadi satu. Keandalan keluaran AI tampak rendah, kebohongan yang terdengar meyakinkan terasa berbahaya, dan apakah AI benar-benar memahami sistem game pun masih diragukan.

Namun, di antara tahun 2024–2026, ada tiga hal yang berubah.

Pertama, kemampuan penalaran model AI telah melewati titik kritis. Ia tidak lagi sekadar menghasilkan kalimat sederhana, melainkan menangani desain sistem yang kompleks, verifikasi konsistensi, dan analisis dampak. Seri Claude terbaru membantu sebagian besar alur kerja game design. Namun, ini tidak berarti semuanya bisa diserahkan. Verifikasi dan tanggung jawab tetap menjadi bagian manusia. (Cakupan bantuannya sangat bervariasi tergantung jenis pekerjaan dan kematangan tim — perkiraan penulis, belum terverifikasi.)

Kedua, harness telah matang. Alat seperti Claude Code bukan sekadar chat. Ia membaca dan menulis file secara langsung, menjalankan perintah, dan menerima kembali hasilnya sebagai masukan. Cara kerjanya menyerupai cara manusia bekerja.

Ketiga, teknik operasional seperti memori, atom, dan skill telah mapan. AI tidak dipakai sekali lalu selesai; melainkan ada metodologi yang mengakumulasi pengetahuan tim sehingga semakin lama semakin cerdas. Bagian akhir buku ini membahas inti dari akumulasi inilah.

Ketika ketiga hal ini berkumpul, adopsi AI pun menjadi pilihan yang masuk akal bagi seorang Game Designer. Memulai sebelum terlambat adalah keuntungan.

1.1.2 Apa Itu Claude Code — Perbedaannya dengan Alat Lain

Alat AI yang biasa ditemui seorang Game Designer ada dua jenis. Tipe chatbot yang melempar pertanyaan ke jendela chat (ChatGPT, aplikasi web Claude) dan tipe terintegrasi editor yang melakukan pelengkapan otomatis di dalam editor kode (Cursor, Copilot).

Claude Code adalah jenis ketiga. Ia bekerja di CLI (terminal) dan mengakses keseluruhan lingkungan kerja seseorang. Berikut adalah satu lembar yang menunjukkan di mana ketiga jenis ini berbeda.

Pekerjaan seorang Game Designer bukanlah kode, melainkan dokumen, tabel, dan relasi. Kekuatan Claude Code terletak pada kemampuannya melihat, memahami, dan memanipulasi seluruh folder tempat seseorang bekerja. Anda tidak perlu menyalin dan menempel materi setiap kali seperti pada chatbot.

Dengan perumpamaan kantor, tipe chatbot itu seperti meja resepsionis. Satu pertanyaan, satu jawaban, dan materinya harus dikeluarkan lagi setiap kali. Claude Code lebih mirip rekan kerja di meja sebelah. Ia tahu di mana materinya berada, membuka file dengan tangannya sendiri, dan merapikan hasilnya lalu meletakkannya kembali di meja. Walaupun sama-sama Claude, pekerjaan yang dikuasainya berbeda tergantung di meja mana ia didudukkan.

1.1.3 30 Menit Pertama — Apa yang Dilihat dan Apa yang Dicoba

Instalasi dan konfigurasi dibahas di subbab 1.0. Subbab 1.1 berfokus pada apa yang perlu dialami dalam 30 menit pertama agar rasa asing berkurang. 30 menit pertama terbagi menjadi empat segmen, dan di setiap segmen sebagian rasa asing menghilang secara bertahap.

flowchart LR
    A["Melihat (5 menit)
Ringkas folder ini
→ 'ia memahami bahasa sehari-hari'"]
    B["Mencari (5 menit)
Mencari kata kunci & file terbaru
→ 'ia menggantikan pekerjaan remeh harian'"]
    C["Mengonversi (10 menit)
Notula→tabel, Excel→Markdown
→ 'ia menciptakan waktu'"]
    D["Verifikasi (10 menit)
Meragukan keluaran yang baru dibuat
→ 'alat ini harus diragukan'"]
    A --> B --> C --> D
    D --> E["Rasa asing teratasi 80%"]
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class A,B,C ai
    class D human
    class E pass

5 Menit Pertama — Melihat

Saat Anda membuka terminal dan menjalankan Claude Code, layar hitam muncul dan kursor berkedip. Banyak orang berhenti di titik ini, tetapi kalau berhenti, Anda kehilangan kesempatan pertama untuk mencairkan rasa asing. Ketiklah satu kalimat dalam bahasa sehari-hari.

Tolong ringkas apa saja yang ada di folder ini

Ini satu kalimat, bukan kode maupun perintah. Claude Code memindai struktur folder, lalu merapikan dan menjawab file apa saja yang ada dan tampak sebagai proyek yang menangani apa. Jika Anda mengetik baris ini di folder berisi dokumen desain, kira-kira respons seperti inilah yang kembali.

Tolong ringkas apa saja yang ada di folder ini


Saya telah memindai folder ini. Tampaknya ini folder kerja untuk data game & dokumen desain.

  Jenis File       Jumlah  Perkiraan Isi
  ─────────────   ────    ───────────────────────────
  .xlsm            12     Sheet data (item, quest, NPC, dll.)
  .md              34     Draf dokumen desain & notula rapat
  .png             88     Mockup UI & gambar referensi
  Subfolder         6     /data /docs /ref /meeting /export /tmp

Observasi:
  - Di folder /meeting menumpuk 5 notula rapat dari seminggu terakhir.
  - item_table.xlsm dan quest_table.xlsm tampak berbagi
    kolom ID yang sama (kandidat FK).
  - Di folder /tmp ada banyak file export sementara — mungkin perlu dirapikan.

Mana yang ingin Anda telusuri lebih dulu?

Dari satu respons ini, fakta bahwa "alat ini memahami bahasa sehari-hari, bukan perintah" masuk ke dalam diri Anda secara langsung. Pengalaman menerima gambaran rapi tentang apa yang ada di mana, tanpa harus membuka folder secara langsung, mengikis separuh rasa asing seketika di tempat itu.

5 Menit Berikutnya — Mencari

Mintalah pencarian kecil. Permintaan seperti "Beri tahu saya 5 file Markdown yang diubah dalam seminggu terakhir" atau "Di file mana ada kata 'reward'?". Pekerjaan yang biasa dilakukan seorang Game Designer setiap hari — membuka Find in Files, mengetik kata kunci, lalu menggulir hasilnya — diterima Claude Code dalam bahasa sehari-hari, dirapikan, dan dikembalikan. Sensasi bahwa alat ini menggantikan pekerjaan remeh harian akan tertanam di 5 menit kedua ini.

10 Menit Berikutnya — Mengonversi

Mintalah konversi kecil. Permintaan seperti "Ekstrak hanya keputusan dari notula rapat ini dan buatkan tabel" atau "Ubah baris 1–10 sheet Excel ini menjadi tabel Markdown". Pengalaman konversi yang secara manual butuh 5–10 menit, lalu selesai dalam waktu singkat, mengantar pada sensasi bahwa alat ini tidak berhenti pada menggantikan pencarian, melainkan menciptakan waktu untuk Anda.

10 Menit Terakhir — Verifikasi

Alasan mengapa berbahaya jika berhenti di sini adalah karena AI bisa berbohong dengan meyakinkan. Buatlah AI meragukan sendiri keluaran yang baru saja ia buat.

Tolong periksa lagi apakah tabel yang baru kamu buat cocok dengan aslinya. Ada item yang terlewat?

Maka Claude Code akan membaca ulang aslinya, membandingkan keluarannya sendiri baris demi baris, dan melaporkan ketidakcocokan. Pada segmen ini sering muncul layar seperti ini.

Tolong periksa lagi apakah tabel yang baru kamu buat cocok dengan aslinya. Ada item yang terlewat?


Saya telah membandingkan ulang aslinya (meeting_0603.md) dengan tabel yang baru saya buat.
Saya menemukan 3 ketidakcocokan.

  ⚠ Terlewat  "Penurunan reward tutorial 50%" — ada di baris 12 aslinya tetapi tidak ada di tabel
  ⚠ Salah tulis  Penanggung jawab "Kim OO" → di tabel keliru ditulis "Lee OO"
  ⚠ Ambigu   "Pembahasan ulang reward" — tidak jelas dari teks aslinya apakah ini keputusan atau ditunda.
           Saya memasukkannya ke 'keputusan' atas penilaian sendiri, tetapi perlu dikonfirmasi.

Apakah saya buatkan ulang tabel yang sudah dikoreksi? Beri tahu saya
bagaimana menangani item yang ambigu, akan saya terapkan.

Bahwa alat ini mampu meragukan keluarannya sendiri, dan bahwa ia melakukan keraguan itu bersama manusia, adalah inti dari 10 menit terakhir. Sikap balik bertanya seperti pada item ketiga — "saya menilai sendiri, jadi tolong dikonfirmasi" — adalah pengaman yang menyisakan verifikasi di tangan manusia.

Setelah 30 menit berlalu, 80% rasa asing sudah menghilang. Sisa 20% akan berkurang perlahan di bab-bab berikutnya.

1.1.4 Pemandangan dari Perusahaan — Enam Bulan Sebuah Tim Menengah

Sebuah proyek MMORPG yang penulis kelola sebagai Design Director (selanjutnya disebut "Proyek A") telah menjalankan alur kerja berbasis Claude Code selama sekitar 6 bulan bersama tim desain (4–5 orang) (tim pengembangan Proyek A secara keseluruhan berukuran menengah, 10–50 orang). Berikut beberapa pemandangannya.

Mari kita pisahkan satu kasus yang paling konkret dengan pengukuran nyata. Yaitu pemeriksaan konsistensi FK (foreign key/kunci asing) yang menjangkau lebih dari 30 sheet data. Ini pekerjaan menelusuri dengan mata manusia apakah ID di satu sheet direferensikan dengan benar di sheet lain, dan semakin bertambah sheet-nya, kombinasinya membengkak secara eksponensial.

• Before: Seorang Game Designer membuka sheet bergantian untuk membandingkan ID. Satu kali putaran melalui 30-an sheet butuh setengah hari (sekitar 4 jam). Kalau konsentrasi terputus di tengah, ada baris yang terlewat.
• After: Alat deteksi relasi membandingkan FK antar-sheet secara otomatis dan hanya mengeluarkan daftar referensi yang rusak. Satu kali putaran sekitar 5 menit.

Dari setengah hari menjadi 5 menit. Saya tidak akan menggeneralisasi satu baris ini. Pekerjaan lain punya margin penghematan yang lebih kecil, atau malah menambah waktu peninjauan baru. Pemandangan-pemandangan lain yang saya lihat selama 6 bulan yang sama hanya saya tuliskan dalam arah dan proporsi.

• Ekstraksi keputusan dari notula rapat (akumulasi 5–10 kasus per minggu): pekerjaan yang dilacak manusia dengan pencarian & menggulir → tabel ekstraksi otomatis. Beban pelacakan hampir hilang.
• Draf GDD (Game Design Document): waktu penulisan turun menjadi kurang dari separuh, tetapi sebagai gantinya waktu peninjauan & penghalusan bertambah. Total berkurang, namun pusat gravitasi pekerjaan bergeser dari 'menulis' ke 'menilai'.
• Diagram relasi sheet data: struktur dependensi yang berulang dijelaskan secara lisan di rapat → dibuat sekali sebagai HTML interaktif lalu dibagikan.

Akumulasi waktu yang dihemat selama 6 bulan setelah setiap alat dibuat sekali, menurut penghayatan penulis, bukan dalam satuan person-week melainkan person-month (penjumlahan persisnya belum diukur, masih perkiraan). Dengan waktu itu, kami bisa berfokus pada desain yang lebih mendalam.

Alat semacam ini, sekali dibuat, akan bekerja lama. Namun, 'lama' tidak otomatis berarti 'tanpa awak'. Ia bertahan lama hanya kalau orang yang mengoperasikan dan struktur verifikasi disiapkan bersama-sama; jika alatnya ditinggal dan orangnya pergi, ia membusuk dalam dua kuartal. Bagian-bagian akhir buku ini membahas bagaimana masing-masing alat di atas dibuat dan dioperasikan.

1.1.5 Ketakutan dan Harapan — Membahasnya dengan Jujur

Mari kita bahas dengan jujur ketakutan yang umum dimiliki seorang Game Designer di depan alat AI. Membahasnya tanpa menghindar adalah langkah pertama adopsi.

Ketakutan bahwa "AI menggantikan pekerjaan saya" separuh benar, separuh salah. Pekerjaan remeh sederhana (pemeriksaan konsistensi, konversi dokumen, pencarian) memang digantikan AI, tetapi keputusan, prioritas, dan desain emosi pemain tidak bisa digantikan. Sebaliknya, Game Designer yang pandai memakai AI terbebas dari pekerjaan remeh dan berfokus pada esensi. Mari bertanya pada diri sendiri: "Berapa rasio pekerjaan remeh dan esensi dalam pekerjaan saya?" Kalau pekerjaan remeh 70%, maka esensi 30% tetap menjadi bagian Anda sendiri, dan intinya 30% itu justru menjadi lebih penting.

Pertanyaan "Kalau AI salah, siapa yang bertanggung jawab" juga sering muncul. Tanggung jawab atas keputusan seorang Game Designer selalu menjadi milik Game Designer itu. Menggunakan keluaran AI begitu saja tanpa verifikasi adalah kesalahan Game Designer, bukan kesalahan AI. Merancang prosedur verifikasi bersama-sama adalah bagian dari adopsi. 'Membuat AI meragukan keluarannya sendiri' yang kita lihat di 10 menit terakhir subbab 1.1.3 adalah benih terkecil dari prosedur itu.

Ketakutan "Saya tidak bisa pakai karena tidak paham kode" akan segera terurai. Claude Code bekerja dengan bahasa sehari-hari, jadi kalau tidak paham kode, Anda bisa mulai apa adanya sesuai keadaan itu. Karena Anda membaca skrip buatan AI bersama-sama, setelah beberapa bulan Anda akan bisa membaca dan memodifikasi skrip sederhana. Pembelajaran mengikuti dengan sendirinya.

"Alatnya berubah terlalu cepat" juga kekhawatiran yang umum. Kalau Anda berusaha mengejar semua model, fitur, dan tren, Anda akan kelelahan. Dalamilah hanya 1–2 fitur yang berguna bagi alur kerja Anda, dan sisanya lihat saat dibutuhkan.

Saya ingatkan lebih dulu. Walaupun layar respons di subbab 1.1.3 tampak mulus, dalam 30 menit pertama yang sesungguhnya akan tercampur jawaban yang meleset, ringkasan file yang ngawur, dan keluaran yang tersendat. Itu normal. Buku ini bukan kisah sukses yang mulus, melainkan lebih banyak membahas bagaimana meminta ulang keluaran yang meleset untuk membetulkannya.

1.1.6 Cara Menggunakan Buku Ini

Buku ini terdiri dari 24 bagian. Anda tidak harus membacanya berurutan dari awal sampai akhir. Pilih saja salah satu dari tiga pola berikut yang sesuai dengan situasi Anda.

Kalau Anda bingung memilih jalur, bagilah berdasarkan posisi mana yang paling dekat dengan Anda. Jika Anda perencana, PM, atau karyawan umum di luar industri game, alih-alih tiga pola di atas, saya sarankan "Jalur Profesi Umum" (Bagian 1·2 → Bagian 17 notula rapat → Bagian 16 kolaborasi → Bagian 18 pengambilan keputusan → Bagian 21·22 perbaikan-diri & tata kelola) — bahkan dengan melewati bab-bab domain game, kerangka intinya tetap berdiri utuh, dan kotak "Penerapan di Luar Game" pada tiap bab menjadi jembatan untuk membacanya ke dalam profesi Anda sendiri (indeksnya di Lampiran F.5). Kalau tidak ada waktu, mengikuti empat bab saja — 17.1 → 16.2 → 22.1 → 21.1 — sudah cukup. Jika Anda pembaca non-teknis yang baru memulai alat AI, dengan "Pola Adopsi" peganglah erat satu bidang Anda sendiri (atau bidang yang paling dekat) sampai tuntas, dan untuk bagian bidang yang mendalam (4, 8, 11, dll.) cukup ambil 'satu baris untuk non-teknis' di bagian pendahuluannya, lalu turun ke isi utama saat dibutuhkan.

Setiap bab dalam buku ini tidak masuk sampai kedalaman akademis, melainkan berhenti di tingkat yang bisa dioperasikan. Tujuannya adalah memindahkan apa adanya teknik yang benar-benar berjalan selama 6 bulan di tim menengah, lalu berjalan bersama Anda menempuh jalan untuk mulai dari kecil dan membesarkannya.

1.1.7 Sambungan ke Bab Berikutnya

Subbab 1.1 adalah bab untuk mengurangi rasa asing. Subbab 1.2 masuk satu tingkat lebih dalam dan menjelaskan mekanisme dasar alat ini dengan bahasa yang ramah bagi Game Designer. Tujuan subbab 1.2 adalah membuat Anda tidak lagi takut pada kata-kata seperti model, token, konteks, dan harness. Penyiapan yang sesungguhnya (memori, izin, settings.json) dibahas di subbab 1.3.

Poin-Poin Penting

• Rasa asing pada perjumpaan pertama bukan cacat alat, melainkan biaya adaptasi bagi orang yang terbiasa dengan GUI
• Claude Code bukan chatbot, melainkan lebih mirip rekan kerja di sebelah yang menangani seluruh folder
• Dengan melewati melihat, mencari, mengonversi, dan verifikasi masing-masing sekali dalam 30 menit pertama, 80% rasa asing menghilang

Pratinjau Bab Berikutnya

• Bab 2. Model AI, Token, Harness — Mekanisme dasar untuk seorang Game Designer

Coba Sendiri

setup 1. Bukalah terminal (Windows: PowerShell, macOS: Terminal). 2. Pindahlah ke folder tempat dokumen desain Anda terkumpul, lalu jalankan Claude Code (instalasi di 1.0). 3. Setel timer ke 30 menit — 5 menit (melihat), 5 menit (mencari), 10 menit (mengonversi), 10 menit (verifikasi).

prompt (satu baris per segmen, ketiklah secara berurutan)

① Tolong ringkas apa saja yang ada di folder ini
② Di file mana ada kata 'reward'?
③ Ekstrak hanya keputusan dari notula rapat ini dan buatkan tabel
④ Tolong periksa lagi apakah tabel yang baru dibuat cocok dengan aslinya. Ada item yang terlewat?

verify - Pada ①, cocokkan dengan mata apakah ringkasan struktur folder sesuai dengan folder yang sebenarnya. - Kalau laporan ketidakcocokan pada ④ keluar walau hanya satu kasus, berarti berhasil. Artinya Anda telah melihat sendiri adegan AI meragukan keluarannya sendiri. - Kalaupun keluar jawaban yang meleset, itu bukan kegagalan. Meminta ulang seperti "barusan jawabannya salah, tolong lihat lagi file ini saja" pun termasuk bagian dari latihan 30 menit pertama.

Versi Ringkas Solo

Jika Anda perorangan yang tidak punya tim maupun folder perusahaan, cobalah ketik hanya prompt ① dan ④ di atas pada salah satu folder kerja apa pun di PC Anda (misalnya folder Unduhan atau folder catatan). Dengan ① mengonfirmasi "ia memahami bahasa sehari-hari" dan dengan ④ mengonfirmasi "keluaran bisa diragukan", dua poin inti bab ini bisa Anda hayati sendirian dalam 5 menit pun.

1.2 Model, Token, Harness — Jalan yang Dilalui Token dalam Satu Pekerjaan

Saat itu saya baru menyelesaikan satu pekerjaan lalu mengecek penggunaan. Lima notula rapat minggu ini menumpuk di sebuah folder, dan sebelum stand-up pagi Senin saya harus merangkum "hanya yang sudah diputuskan" ke dalam satu halaman. Saya menuliskan satu baris di jendela Claude Code: "Ambil hanya keputusan dari notula rapat di folder ini dan buatkan tabel." Kira-kira 0.4 detik setelah saya menekan Enter, tulisan abu-abu kecil berkedip di bagian bawah layar.

Reading meeting-2026-05-25.md ... (1,840 tokens)
Reading meeting-2026-05-27.md ... (2,310 tokens)

Tulisan abu-abu inilah tema bab ini. Ketika saya melemparkan satu kalimat berbahasa Korea, alat tersebut memotongnya menjadi token, membaca file menjadi token lalu memasukkannya ke model, menerima jawaban model, dan menuliskannya ke file. Setiap kali siklus bolak-balik ini berputar sekali, biaya dikenakan, dan materi menumpuk dalam "jangkauan pandang" model. Bab ini membongkar apa yang terjadi di balik tulisan abu-abu itu dengan bahasa seorang Game Designer. Empat kata sudah cukup: model, token, konteks, dan harness.

Catatan Istilah - Model (model): otak yang menghasilkan jawaban. Ada berbagai jenis dengan ukuran dan karakter berbeda seperti Opus, Sonnet, dan Haiku. - Token (token): potongan teks yang dipotong halus. Penagihan, kecepatan, dan jangkauan pandang semuanya dihitung dalam satuan ini. - Context window (jendela konteks): jumlah maksimum token yang dapat ditampung model dalam pikirannya sekaligus. - Harness (harness): rangka yang membuat model bekerja. Claude Code adalah salah satu contohnya.

1.2.1 Loop Harness — Identitas Tulisan Abu-Abu

Tulisan abu-abu di atas bukan log acak, melainkan satu kotak dari sebuah siklus yang sudah ditetapkan. Apa yang dilakukan harness pada akhirnya adalah memutar lingkaran yang sama dengan cepat. Ia membaca file lalu memasukkannya ke model; jika model berkata "jalankan perintah ini", ia menjalankannya; lalu hasilnya dimasukkan kembali ke model. Lingkaran ini berputar sampai pekerjaan selesai.

flowchart TD
    Start([Manusia: instruksi satu baris]) --> Read[Harness: baca file/materi
ubah menjadi token]
    Read --> Inject[Harness: suntikkan ke konteks
+ jumlahkan token kumulatif]
    Inject --> Model{Model: tentukan tindakan berikutnya}
    Model -->|Perlu jalankan perintah| Exec[Harness: jalankan perintah shell/skrip]
    Exec --> Result[Masukkan kembali hasil eksekusi
sebagai token]
    Result --> Inject
    Model -->|Jawaban siap| Write[Harness: tulis file/keluaran]
    Write --> Verify{Lolos verifikasi?}
    Verify -->|Gagal| Inject
    Verify -->|Lolos| Done([Simpan hasil])
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class Start,Verify human
    class Read,Inject,Exec,Write code
    class Model ai
    class Result data
    class Done pass

Dalam gambar ini, kotak yang disentuh manusia hanya dua: paling atas (instruksi) dan paling bawah (memeriksa hasil verifikasi); lingkaran di tengah diputar harness secara otonom. Tulisan abu-abu yang berkedip lima kali sewaktu membaca lima notula rapat berarti kotak Read → Inject telah berputar lima putaran. Kalau ini chat web, Anda harus membuka kelima file secara langsung lalu menyalin dan menempelnya. Bahwa harness mengambil alih kerja itu menggantikan Anda — inilah perbedaan menentukan yang membuat chatbot dan harness berbasis CLI menjadi dua alat yang berbeda.

Setiap kali loop berputar satu putaran, token kumulatif dijumlahkan di kotak Inject. Karena itu, tanpa lebih dulu memahami token, baik biaya maupun batas loop ini tidak akan terlihat. Kita mulai dari token.

1.2.2 Token — Mata Uang Nyata yang Dibelanjakan Satu Pekerjaan

Token bukan huruf, melainkan potongan teks yang dipotong oleh model. Sebagai aturan praktis, bahasa Inggris kira-kira 4 huruf per token, sedangkan bahasa Korea mendekati 2 huruf per token (ini bukan konversi resmi, melainkan perkiraan operasional — nilai sebenarnya ditentukan oleh tokenizer model dan berbeda untuk tiap kalimat). Untuk bahasa Korea, 20 huruf termasuk spasi kira-kira setara 10 token.

Mari kita telusuri pekerjaan notula rapat tadi dalam satuan token (angka di bawah ini adalah satu kali pengukuran tunggal dari pekerjaan yang sama. Karena nilainya berubah tergantung volume notula dan panjang ringkasan, saya sarankan membacanya bukan sebagai nilai absolut melainkan sebagai orde besaran dan rasio).

Dua hal langsung terlihat. Pertama, instruksi yang saya ketik hanya 25 token, tetapi keseluruhan pekerjaan melebihi 11 ribu token hanya pada masukan. Hampir seluruh biaya datang bukan dari kalimat saya, melainkan dari materi yang dibaca oleh alat itu. Kedua, keluaran (1,810) hanya sekitar seperenam dari masukan (11,225). Sebagian besar otomatisasi perancangan memang banyak membaca dan sedikit menulis seperti ini. Karena itu, untuk menekan biaya, jauh lebih besar dampaknya mengendalikan volume materi masukan ketimbang memoles keluaran.

Setelah pekerjaan selesai, ketik /context dan Anda akan melihat seberapa besar konteks yang dipakai sesi itu. Kalau tidak menyadari token, ia mengalir keluar tanpa disadari seperti kertas cetak, tetapi begitu sekali dijadikan terlihat, sikap Anda berubah. Visualisasi inilah titik awal penghematan.

Alat untuk mengendalikan token bukan semangat penghematan yang abstrak, melainkan teknik-teknik konkret untuk memperlakukan materi masukan secara halus.

1. Penyuntikan JIT — alih-alih memuat seluruh materi terlebih dahulu, materi ditarik hanya saat dibutuhkan lewat pencocokan kata kunci. "Menyuntikkan aturan klasifikasi 480 token" pada tabel di atas adalah contohnya. Bukan seluruh dokumen aturan klasifikasi rapat (ribuan token), melainkan hanya satu atom yang cocok yang masuk.
2. Cache ringkasan — untuk dokumen panjang, sediakan versi ringkasan untuk AI terpisah dari aslinya untuk manusia. AI membaca versi ringkasan.
3. Pemecahan atom — kalau satu file hanya memuat satu keputusan (dijelaskan rinci di 2.2), hanya potongan yang dibutuhkan yang dapat ditarik secara tepat, sehingga token dihemat.
4. Merapikan konteks — kalau sesi memanjang, lakukan kompresi. Claude Code mendukung kompresi otomatis.
5. Pemilihan model — memakai model besar untuk konversi sederhana membuat token yang sama jadi lebih mahal. Inilah tema bagian berikutnya.

Di antaranya, nomor 1, penyuntikan JIT, adalah perangkat yang benar-benar berjalan di lingkungan kerja buku ini. Ketika satu baris masukan masuk, hook inject_memory.py mencocokkan atom memori berdasarkan urutan skor, memilih beberapa teratas saja untuk disuntikkan, dan tidak menghentikan alur kerja meski gagal (detail implementasi dijelaskan rinci di 1.3). Prinsip penghematan token — "hanya materi yang dibutuhkan, hanya beberapa teratas, dan diam-diam saja meski gagal" — termuat apa adanya dalam satu file kode.

1.2.3 Model — Rangka yang Sama, Mesin yang Berbeda

Model bagaikan mesin mobil, sehingga ke rangka yang sama bernama Claude Code dapat dipasangkan mesin berbeda bernama Opus, Sonnet, dan Haiku. Mengganti mesin mengubah sifat pekerjaan.

Disesuaikan dengan pekerjaan perancangan, pembagiannya seperti ini. Pekerjaan yang membutuhkan penalaran mendalam dan konsistensi — seperti tinjauan desain sistem atau sintesis draf GDD (Game Design Document, dokumen spesifikasi rinci) yang menggabungkan berbagai materi — ke Opus; sebagian besar pekerjaan harian seperti ekstraksi keputusan dari notula atau ringkasan harian ke Sonnet; dan pekerjaan yang nyaris tanpa pertimbangan seperti konversi format sederhana sheet data ke Haiku. Menjalankan pekerjaan notula di bagian sebelumnya dengan Sonnet pun mengikuti kriteria ini — memilih keputusan dan memindahkannya ke tabel lebih cocok dengan keseimbangan dan kecepatan ketimbang penalaran mendalam.

Ada jebakan yang dijatuhi siapa pun di awal adopsi. Yaitu dorongan untuk menjalankan semua pekerjaan dengan mesin terbaik, yakni Opus. Kalau mengikuti dorongan itu, beban biaya dan kecepatan segera berbalik menjadi beban operasional, dan kepekaan untuk mencocokkan model dengan pekerjaan tidak akan tertanam. Keterampilan operasional yang sesungguhnya bukan memilih model di kepala setiap kali, melainkan mengunci pola dengan otomatisasi setelah polanya tertangkap.

• Penulisan retrospektif harian → otomatis Sonnet
• Tinjauan desain sistem → otomatis Opus
• Pemeriksaan konsistensi sheet data → otomatis Haiku

Penetapan semacam ini dilakukan dengan menuliskan model secara eksplisit di dalam settings.json atau slash command (dijelaskan rinci di 1.3). Sekali dikunci, repotnya memilih setiap kali pun lenyap.

Model merilis versi baru kira-kira setiap setengah tahun, dan meski namanya sama, 4.5 dan 4.6 itu berbeda. Saat versi baru muncul, bandingkan hanya lima pekerjaan inti dari alur kerja dengan masukan yang sama. Kalau berusaha menguji semuanya, Anda akan kelelahan. Perbedaan hasil dari kelima pekerjaan itu saja sudah cukup untuk memutuskan apakah perlu beralih.

1.2.4 Context Window — Batas yang Terisi oleh Loop

Tadi disebutkan bahwa setiap kali loop berputar satu putaran, token menumpuk di kotak Inject. Langit-langit yang dibentur oleh tumpukan itu adalah context window, yakni jumlah maksimum token yang dapat diproses model dalam sekali jalan. Bila diibaratkan manusia, inilah working memory (memori kerja).

• Seri Claude 4: standar 200K token, opsi perluasan 1M token
• 200K token ≈ setara sekitar 400 halaman A4 dalam bahasa Korea

Pekerjaan notula sebelumnya memiliki masukan kumulatif di kisaran 11 ribu token, sekitar 6% dari langit-langit 200K, jadi masih longgar. Namun kalau Anda menarik sesi panjang di jendela yang sama tanpa beralih pekerjaan, Anda mendekati langit-langit. Begitu terisi penuh, isi lama terpotong dan model mulai kehilangan "ingatan" bagian awal, lalu kompresi otomatis terpicu dan percakapan sebelumnya digantikan oleh versi ringkasan.

Ada empat kebiasaan untuk mengendalikan langit-langit ini.

Kasus berat yang sering ditemui Game Designer adalah pekerjaan yang sekaligus membutuhkan materi rapat, GDD, dan sheet data; di saat seperti inilah opsi 1M berguna. Namun karena 1M disertai beban biaya dan kecepatan, biasanya 200K sudah cukup dan opsi itu hanya dikeluarkan saat kumpulan materi benar-benar besar.

1.2.5 Saat Harness Benar-Benar Menyaring Kebohongan — Kotak Verifikasi

Kita kembali ke kotak Lolos verifikasi? di paling bawah gambar loop. Tanpa kotak ini, kebohongan model yang tampak meyakinkan akan langsung tersimpan ke file. Model kadang mengeluarkan jawaban yang salah dengan penuh percaya diri seolah-olah itu benar (halusinasi, hallucination), dan frekuensinya berkurang seiring naiknya generasi tetapi tidak pernah menjadi nol. Karena itu verifikasi ditempatkan sebagai kotak permanen.

Halusinasi yang berbahaya dalam perancangan bersifat konkret. Model mengutip kolom sheet data yang tidak ada, menghitung balancing dengan rumus yang salah, atau merangkum hal yang belum diputuskan dalam rapat seolah-olah sudah diputuskan. Dalam pekerjaan notula, yang paling menakutkan adalah yang ketiga — kasus di mana "hal yang hanya dibahas lalu ditangguhkan" menyelinap naik ke tabel keputusan.

Verifikasi memiliki lima pola.

1. Pencocokan dengan sumber asli — keluaran AI dibandingkan ulang dengan materi aslinya ("tolong periksa apakah ini benar-benar ada di materi itu").
2. Konversi dua arah — setelah diubah A→B, dikonversi balik B→A untuk melihat kecocokannya.
3. Tinjauan sampel — 3–5 keluaran acak diperiksa langsung oleh manusia.
4. Otomatisasi linter — diperiksa secara otomatis apakah keluaran melanggar format, rentang, atau aturan yang ditetapkan.
5. Verifikasi silang dua model — keluaran Sonnet ditinjau oleh Opus.

Kelimanya tidak dilakukan semua setiap kali, melainkan 1–3 yang dipilih sesuai tingkat risiko pekerjaan. Dalam pekerjaan notula, saya menggabungkan nomor 4 linter ("apakah keputusan memuat lengkap subjek, isi, dan tenggat") dengan satu kali tinjauan sampel nomor 3. Baris terakhir tabel token sebelumnya, "masukan ulang verifikasi 320 token", justru itulah putaran bolak-balik ketika linter menangkap kekurangan lalu menanyakannya kembali ke model — kalau diukur dengan gambar loop, ia berputar satu putaran lagi lewat verifikasi gagal → Inject.

Kalau manusia memverifikasi semuanya setiap kali, manfaat adopsi berkurang separuh, jadi verifikasi pun menjadi sasaran otomatisasi. Pada ekstraksi keputusan notula, linter memeriksa kekurangan format secara otomatis; pada konversi sheet data, jumlah baris, total, dan konsistensi kunci asing (FK); pada pembuatan GDD otomatis, kekurangan bagian inti. Yang lolos tidak perlu dilihat manusia, dan hanya yang tidak lolos yang dilihat. Pemandangannya seperti di antara dokumen yang memenuhi lemari, hanya mengambil folder bertanda merah ke tangan. Merancang agar pandangan manusia hanya jatuh ke tempat yang berbahaya — itulah tujuan otomatisasi verifikasi.

1.2.6 Tempat Keempat Kata Terangkai dalam Satu Pekerjaan

Sekarang mari kita rapikan bagaimana keempat kata terjalin dalam satu baris, dari awal sampai akhir pekerjaan notula itu.

Kalau dikerjakan dengan tangan, membuka dan membaca lima notula, memilih hanya keputusan lalu menyalinnya, dan menyesuaikan formatnya butuh 30 menit. Begitu diotomatisasi, ia menyusut menjadi 5 menit, dan dalam 5 menit itu kerja tangan manusia hanya menyapu sekali sampel verifikasi. Waktu manusia jatuh hanya ke tempat yang benar-benar membutuhkannya (apakah hal yang ditangguhkan tidak salah naik menjadi keputusan). Yang menjadi inti bukanlah 25 menit yang dihemat, melainkan berubahnya tempat ke mana pandangan itu jatuh.

1.2.7 Kesalahpahaman yang Umum

"Opus selalu lebih baik" adalah yang paling umum. Itu benar kalau biaya dan kecepatan diabaikan, tetapi untuk pekerjaan sederhana Opus adalah pemborosan. Pencocokan per pekerjaan adalah jawabannya.

"Konteks 1M selalu dibutuhkan" juga sering muncul. Sebagian besar cukup dengan 200K, dan karena 1M disertai beban, ia hanya dipakai untuk kumpulan materi yang benar-benar besar.

"Verifikasi itu pekerjaan manusia" hanya benar separuh. Sebagian besar dapat diverifikasi secara otomatis, dan manusia berfokus pada sisanya.

"Token tidak perlu dipikirkan" sampai batas tertentu berlaku pada pekerjaan pribadi, tetapi kalau dipakai bersama banyak orang, biaya kumulatif membesar dengan cepat. Lebih aman menanamkan pola visualisasi dan penghematan sejak awal.

"Harness tidak ada bedanya" juga ternyata banyak. Model yang sama pun terbelah menjadi alat yang berbeda tergantung apakah chatbot atau CLI. Ada-tidaknya kerja salin-tempel yang kita lihat di awal adalah perbedaan itu.

1.2.8 Coba Sendiri

Putar langsung keempat kata bab ini dengan satu pekerjaan kecil.

setup

• Dalam keadaan Claude Code sudah terpasang, siapkan satu folder berisi 2–3 catatan teks (notula/memo).
• Buka Claude Code di folder itu.

prompt

Pilih hanya "yang sudah diputuskan" dari catatan-catatan di folder ini
dan buatkan tabel 3 kolom: subjek, isi, tenggat.
Kecualikan yang ditangguhkan atau masih dibahas, dan untuk setiap baris
yang dimasukkan ke tabel, tuliskan juga nama file asalnya.

verify

• Setelah pekerjaan selesai, ketik /context untuk melihat token yang dipakai sesi ini (Anda akan mendapati masukannya lebih besar dari dugaan).
• Pilih satu-dua baris tabel, buka nama file yang tertera, dan cocokkan dengan sumber asli apakah memang tertulis sebagai "keputusan" (verifikasi pencocokan sumber asli).
• Sapu sekali untuk memastikan hal yang ditangguhkan tidak salah naik ke tabel (tinjauan sampel).

Versi Ringkas Solo

Kalau Anda baru saja memulai alat ini, ambil dua hal saja dari atas. Pertama, serahkan catatan sefolder utuh dan jangan menyalin-tempel sendiri (serahkan ke loop harness). Kedua, tabel keluaran mutlak harus diterima dengan nama file, dan buka sumber asli hanya untuk baris yang mencurigakan. Pemilihan model atau visualisasi token tidak terlambat untuk ditambahkan setelah Anda terbiasa. Hanya dengan dua kebiasaan ini — tidak mengangkut materi dengan tangan dan mencocokkan keluaran dengan sumber asli — separuh dari adopsi sudah tertata.

Poin-Poin Penting

• Harness memutar loop baca→eksekusi→masukan ulang secara otonom, dan manusia hanya menyentuh dua kotak: instruksi dan verifikasi
• Biaya satu pekerjaan datang hampir seluruhnya bukan dari instruksi yang saya ketik, melainkan dari materi yang dibaca oleh alat
• Model diganti-pasang sesuai pekerjaan, sedangkan langit-langit konteks dan verifikasi dikendalikan dengan otomatisasi

Pratinjau Bab Berikutnya

• Bab 3. Infrastruktur Memori, Izin, dan Pengaturan — fondasi yang sekali diatur lalu bekerja selamanya

1.3 Infrastruktur Memori, Izin, dan Konfigurasi

Saya membuka sesi baru dan mengetik, "Coba kita lihat penyeimbangan cooldown skill." Sebelum menekan Enter, sebaris teks abu-abu kecil melintas di bagian bawah layar. [memory injected: 2 atoms, 1,842 chars]. Artinya, meskipun saya belum membuka satu berkas pun, dokumen aturan cooldown yang saya kunci jadi aturan minggu lalu sudah menempel di depan masukan model. Inilah sinyal pertama dari lingkungan kerja yang sudah terpasang infrastrukturnya. Begitu alat dinyalakan, alat itu sudah mengingat saya.

Agar adegan ini bisa terjadi, tiga hal harus lebih dulu menempati posisinya. Apa yang akan diingat AI (memori), apa yang boleh dilakukan AI tanpa persetujuan manusia (izin), dan sakelar pusat yang menghidupkan serta mematikan keduanya (settings.json). Waktu yang dibutuhkan untuk pemasangan pertama paling lama satu jam, dan satu jam itu akan kembali sebagai waktu yang dihemat setiap hari selama enam bulan berikutnya. Hampir seluruhnya adalah investasi yang terbayar kembali.

Bab ini adalah panduan langkah demi langkah (walk-through) yang membentangkan secara berurutan satu baris settings.json yang benar-benar saya jalankan di PC pribadi, inject_memory.py yang dipanggil baris itu, dan _jit_manifest.json yang dibaca berkas tersebut. Jika Anda membacanya sampai habis, Anda akan bisa menunjuk dengan tangan di berkas mana dan baris mana ungkapan "memori disuntikkan secara otomatis" itu sebenarnya terjadi.

1.3.1 settings.json — Satu Baris tempat Segalanya Bermula

Mari kita lihat kesimpulannya lebih dulu. Yang menghidupkan penyuntikan memori otomatis di PC pribadi saya hanyalah satu blok di dalam settings.json.

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python ~/.claude/hooks/inject_memory.py"
          }
        ]
      }
    ]
  }
}

Jika diuraikan, inilah maksud blok tersebut. "Setiap kali terjadi peristiwa pengguna mengirimkan prompt (UserPromptSubmit), jalankan satu kali skrip Python bernama inject_memory.py." Itu saja. AI tidak mengingat dengan sendirinya karena pintar, melainkan strukturnya begini: setiap kali masukan datang, skrip yang sudah didaftarkan manusia menyisip satu kali.

settings.json adalah berkas pusat yang mengendalikan seluruh perilaku Claude Code, dan terbagi menjadi dua lapis.

• ~/.claude/settings.json — global. Berlaku untuk semua sesi. Konfigurasi yang bisa dibagikan ke tim.
• ~/.claude/settings.local.json — lokal. Berlaku hanya di PC ini. Konfigurasi khusus PC pribadi.

Keduanya diterapkan setelah digabungkan (merge). Karena itu, saya menempatkan hook dan izin yang perlu dibagikan tim di settings.json, sedangkan jalur absolut atau jalur alat pribadi yang hanya dipakai di PC rumah ini saya pisahkan ke settings.local.json. Pemisahan ini menghindari konflik git saat berkolaborasi dan mencegah konfigurasi pribadi bocor ke repositori tim.

Selain hook, ada beberapa butir lain yang sering disinggahi.

• effortLevel — kedalaman penalaran model. low / medium / high. Pekerjaan yang membutuhkan pertimbangan mendalam, seperti merancang GDD, saya setel ke high.
• permissions — cakupan perintah yang boleh dijalankan AI tanpa persetujuan (dibahas rinci di 1.3.4).
• enabledPlugins — daftar plugin yang diaktifkan.

Di sini ada satu kebiasaan operasional terpenting. settings.json bisa membuat alatnya sendiri gagal muncul hanya karena satu salah ketik kecil. Satu koma JSON yang hilang saja sudah merusak penguraian (parsing). Karena itu, mencadangkan sebelum mengubah adalah wajib. Di PC saya, berkas cadangan semacam ini benar-benar ada.

settings.json.bak_2026-05
settings.local.json.bak_2026-05

Cukup buat satu salinan dengan akhiran (suffix) tanggal, dan rollback hanya butuh 1 detik. Akan lebih baik lagi jika dikelola dengan git. Seperti sekumpulan kunci tua di dalam laci, biasanya tidak terpakai, tetapi pasti tiba saat ia dibutuhkan satu kali di depan pintu yang terkunci.

1.3.2 inject_memory.py — Apa yang Sebenarnya Terjadi di Dalam hook

Sekarang kita masuk ke dalam skrip yang dipanggil settings.json. Inilah tulang punggung panduan langkah demi langkah ini. Kodenya kira-kira 100 baris, tetapi intinya ada lima tindakan.

flowchart TD
    A["Sesi: pengguna mengirim prompt\ncontoh: 'lihat penyeimbangan cooldown skill'"] --> B["hook UserPromptSubmit terpicu\nsettings.json menjalankan inject_memory.py"]
    B --> C["Muat _jit_manifest.json\nmetadata 17 atom"]
    C --> D["Urutkan score menurun\n→ coba pencocokan regex tiap atom"]
    D --> E{"Ada atom\nyang cocok?"}
    E -->|Tidak| Z["Tidak menyuntik apa pun\nexit 0"]
    E -->|Ya| F["Pilih hanya max_matches(3) teratas"]
    F --> G["Jika total melampaui 6,000 karakter\ntruncate"]
    G --> H["Lampirkan isi atom\ndi depan masukan pengguna"]
    H --> I["Model menerima atom + prompt\nbersamaan → merespons"]
    D -.->|Eksepsi apa pun| Z2["Eksepsi selalu ditelan\nexit 0 (alur tak terhambat)"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    class A human
    class B,C,D,E,F,G,H code
    class I ai

Jika kelima tindakan diuraikan, hasilnya begini.

1) Membaca manifest. Skrip pertama-tama membuka ~/.claude/projects/C--Users-user/memory/_jit_manifest.json. Berkas ini berisi metadata atom (nama, jalur, regex pencocokan, skor) yang sudah tertata. PC pribadi saya saat ini terdaftar 17 atom.

2) Mengurutkan score secara menurun. Setiap atom memiliki nilai score. Atom dengan skor lebih tinggi dicoba dicocokkan lebih dulu. Saat satu kata kunci yang sama tersangkut beberapa atom, skor inilah yang menentukan siapa yang lebih diprioritaskan.

3) Mencocokkan dengan regex. Skrip membandingkan string masukan pengguna dengan pola regex tiap atom. Jika "쿨다운" ada dalam masukan, atom yang memiliki pola 쿨다운|cooldown|GCD akan tersangkut. Perbandingan dilakukan tanpa membedakan huruf besar dan kecil.

4) Memotong hingga maksimal 3. Sebanyak apa pun yang cocok, jika melampaui max_matches (di lingkungan saya 3), hanya 3 teratas yang disisakan. Selain itu, jika total panjang isi atom yang terpilih melampaui 6,000 karakter, isi tersebut akan dipotong (truncate). Dua lapis batas ini adalah pengaman agar masukan tidak membengkak.

5) Selalu berakhir dengan exit 0 pada eksepsi apa pun. Inilah inti rancangannya. Entah manifest rusak, berkas hilang, atau regex keliru, skrip diam-diam menelan eksepsi dan berakhir dengan kode keluar 0. Sebab, jika hook mati dengan kode selain 0, prompt pengguna itu sendiri bisa terhambat. Prinsip "meskipun penyuntikan memori gagal, alur kerja pengguna tidak boleh terhambat sama sekali" tercatat di try/except paling luar dari kode.

Titik berat ada pada nomor 4 dan 5. Nomor 4 (batas) mencegah memori meledakkan jumlah token, dan nomor 5 (menelan eksepsi) mencegah infrastruktur mengganggu pekerjaan. Keduanya adalah dua wajah dari filosofi yang sama: "otomatisasi tidak boleh membuat manusia terbebani."

1.3.3 _jit_manifest.json — Kamus Kata Kunci yang Membangunkan atom

Di 1.2 saya berjanji soal prinsip penghematan token "hanya materi yang perlu, hanya beberapa teratas, dan diam saja meski gagal," lalu menyerahkan detail implementasinya ke bab ini. Tempat tinggal detail itu adalah manifest yang dibaca inject_memory.py. Ini adalah jantung JIT (Just-In-Time, cara memuat materi hanya saat dibutuhkan), dan satu entri atom berbentuk seperti berikut.

{
  "atoms": [
    {
      "name": "combat_cooldown_rule_v2",
      "path": "atoms/combat/combat_cooldown_rule_v2.md",
      "regex": "쿨다운|cooldown|GCD",
      "score": 80
    },
    {
      "name": "user_health",
      "path": "memory/user_health.md",
      "regex": "건강|복약|컨디션|약물",
      "score": 95
    }
  ],
  "config": {
    "max_matches": 3,
    "case_insensitive": true
  }
}

Empat ruas (field) mendefinisikan satu atom.

• name — nama unik atom.
• path — jalur berkas yang isinya dibaca ketika cocok.
• regex — pola yang mendefinisikan kata kunci mana di masukan yang akan membangunkan atom ini.
• score — prioritas pengurutan. Makin tinggi, makin dulu dicocokkan dan makin dulu menempati tempat.

max_matches: 3 pada blok config adalah sumber dari batas "maksimal 3" yang kita lihat di 1.3.2. Begitu manifest diubah dengan tangan, perilakunya langsung berganti.

Saya tegaskan satu rasa skala. PC pribadi saya beroperasi ringan dengan 17 atom dan satu manifest. Sebaliknya, lingkungan kerja nyata (Proyek A) per Mei 2026, berdasarkan cadangan, terdaftar 304 atom tim dan 48 skill. Satu hot atom punya score yang naik sampai 356.53 (seri view_html_filename_convention yang menangani aturan penamaan berkas); angka itu tidak tinggi sejak awal, melainkan jejak yang terakumulasi melalui pemanggilan dan verifikasi berulang.

Yang dikatakan selisih antara 17 atom di PC pribadi dan 304 di kantor adalah: meskipun mekanisme JIT-nya sama, kecepatan dan skala penumpukan materi sebanding dengan kepadatan proyek. Tidak perlu membuat 304 dari awal. Jika Anda mulai dengan lima atom inti dan mengunci satu-dua atom jadi aturan setiap minggu, tanpa terasa manifest pun menebal.

Perkiraan penulis (belum terverifikasi): Pernyataan bahwa score terakumulasi sesuai jumlah pencocokan dan verifikasi adalah interpretasi berdasarkan pola operasional. Karena rumus penghitungan skor itu sendiri berbeda-beda menurut desain manifest tiap lingkungan, nilai absolut seperti 356.53 di atas hanyalah cuplikan terukur dari lingkungan saya, bukan standar umum.

Prinsip membagi memori menjadi dua lapis juga saya tegaskan kembali di sini.

Menjaga global tetap ringan lebih aman. Sebab, jika global menjadi berat, beban itu terakumulasi sebagai biaya token di semua sesi. Jika diandaikan dengan kantor, global adalah tempat kartu nama di atas meja (makin ringan makin nyaman dipakai sehari-hari), sedangkan memori proyek adalah folder di kabinet di sebelah (boleh menebal per proyek tanpa membebani keseharian). Karena itu, di global yang dimuat otomatis hanya ditaruh yang inti, lalu materi yang kaya ditumpuk di memori proyek dan dibangunkan dengan JIT hanya saat dibutuhkan.

1.3.4 Izin — Daftar Putih tempat Jejak Penumpukan Pekerjaan Mengendap

Sekarang sumbu ketiga infrastruktur, yaitu izin. Claude Code bisa menghapus berkas, menjalankan perintah, dan memanggil API eksternal. Kekuatan datang bersama bahaya. Sistem izin mengelola bahaya itu.

Izin terbagi menjadi dua jenis. Yang dijalankan otomatis tanpa persetujuan manusia, dan yang setiap kali harus mendapat persetujuan. Apa yang ditaruh di sisi mana didefinisikan di blok permissions pada settings.json.

{
  "permissions": {
    "allow": [
      "Bash(ls:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Read(*)",
      "Grep(*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ]
  }
}

Di sini diperlukan pergeseran sudut pandang. Daftar allow ini bukan sekadar nilai konfigurasi, melainkan jejak penumpukan pekerjaan. Pada awalnya, hanya membaca dan mencari yang ditaruh sebagai izin otomatis, dan daftarnya hampir kosong. Namun, setelah satu-dua bulan mengulang pekerjaan yang sama, muncul pola "perintah ini repot kalau harus menekan persetujuan setiap kali," dan saya memindahkannya satu per satu ke allow. Daftar yang memanjang itu segera menjadi sidik jari tentang apa yang berulang kali saya kerjakan dengan alat ini.

Lingkungan kerja saya (Proyek A) memiliki sekitar 80 pola izin otomatis. Dimulai dengan 20, lalu selama enam bulan bertambah 60 lagi; dan jika 60 itu dibaca terbalik, terungkap pekerjaan apa yang berulang saya lakukan selama setengah tahun terakhir. Ekstraksi sheet data, pembuatan diagram relasi, pendokumentasian skema — alat yang sering dipakai adalah izin yang sering diberikan.

Dalam pengelolaan izin, terbentuk empat pola.

• Mulai dengan whitelist — izin otomatis berangkat dari minimum dan ditambah hanya saat diperlukan. Bukan membuka lebar lalu menyempitkan, melainkan menutup sempit lalu membuka.
• Perintah berbahaya diblokir secara eksplisit — perintah yang satu kesalahannya fatal, seperti rm -rf dan git push --force, dimasukkan ke deny. Sekalipun izin otomatis diperluas, kedua hal ini tidak disentuh.
• Pembersihan berkala — tiap kuartal, allow ditinjau ulang dan izin yang sudah tidak terpakai dikurangi. Jejak yang hanya menumpuk akan menjadi derau (noise).
• Pemisahan per domain — pisahkan izin global dan izin proyek. Sebagaimana PC rumah dan PC kantor punya kebijakan berbeda, cakupan izin pun berbeda per lingkungan.

Jika pop-up persetujuan muncul setiap kali, manusia menjadi lelah. Ada pula perangkat untuk mengurangi kelelahan itu. Misalnya, mendaftarkan sekaligus pola yang sering muncul lewat slash command seperti fewer-permission-prompts, memberikan izin sementara hanya selama satu sesi, atau menggunakan mode izin otomatis penuh khusus untuk pekerjaan pribadi. Hanya saja, opsi terakhir tidak saya sarankan di lingkungan tim.

Keseimbangan antara rasa lelah dan keamanan diatur sendiri. Jika terlalu ketat, pekerjaan tidak bergulir; jika terlalu longgar, terjadi kecelakaan. Sekalipun mulai dengan longgar, asalkan ada siklus pembersihan kuartalan, keseimbangan akan terbentuk secara alami.

1.3.5 Saat Sesi Dimulai — Gambar Memori dan Izin yang Dimuat Bersamaan

Sekarang saya bentangkan, dengan acuan satu baris masukan, bagaimana ketiga sumbu (settings, memori, izin) yang sudah kita lihat sejauh ini bekerja serentak dalam satu sesi. Berikut adalah penampang dari apa yang sebenarnya terjadi ketika "lihat penyeimbangan cooldown skill" dimasukkan.

Ketiga lajur bertemu pada satu masukan. settings.json membangunkan hook, hook memilih memori lalu menempelkannya ke masukan, dan ketika respons yang terbentuk demikian memanggil alat, izin bekerja sebagai gerbang terakhir. Pengguna hanya mengetik satu baris "lihat cooldown," tetapi ketiga infrastruktur bekerja secara berurutan di tempat yang tak terlihat. Inilah struktur internal dari momen ketika alat terasa sebagai "alat saya sendiri."

1.3.6 Panduan Konfigurasi Pertama — Siap Beroperasi dalam 1 Jam

Setelah melihat teorinya, kini saatnya menggerakkan tangan. Setelah pertama kali memasang Claude Code, dalam satu jam Anda bisa memasang seluruh gambar di atas ke PC Anda sendiri. Kita bagi menjadi lima rentang.

0\~10 menit, memastikan instalasi dan eksekusi. Setelah instalasi, jalankan Claude Code dari terminal. Di sebuah folder, tanyakan "ada apa di folder ini?" dan periksa responsnya. Mulailah dari memastikan apakah alatnya hidup.

10\~25 menit, menulis tiga memori global. Untuk global yang dimuat otomatis, tiga berkas sudah cukup.

• MEMORY.md (5 baris) — satu baris identitas diri + penunjuk (pointer) ke berkas-berkas lain.
• user-profile.md (20\~30 baris) — nama, peran, bidang keahlian, kontak.
• feedback-collaboration-style.md (20\~30 baris) — aturan kolaborasi seperti bahasa, gaya bicara, prioritas eksekusi, dan penjelasan yang ringkas.

Anda boleh memulai dengan menyalin langsung contoh dari saya. Cukup disempurnakan sambil beroperasi.

25\~40 menit, pengaturan dasar settings.json. Setel effortLevel ke high, masukkan set izin awal (baca dan cari otomatis; tulis dan hapus disetujui), lalu buat satu cadangan (settings.json.bak_<tanggal>). Cadangan adalah satu baris terpenting di rentang ini.

40\~55 menit, lima atom proyek pertama. Buat lima atom dari keputusan yang selalu Anda lupakan dan informasi yang sering Anda tanyakan. Foldernya ~/.claude/projects/<proyek>/memory/. Untuk formatnya, lihat Bab 5. Dengan lima atom, tanpa harus segera membuat manifest JIT pun, efeknya sudah muncul hanya dari pemuatan otomatis global.

55\~60 menit, satu kali pengujian. Buka sesi baru dan lemparkan satu pertanyaan dari bidang Anda. Periksa apakah memori global termuat otomatis dan apakah nada responsnya mengikuti aturan kolaborasi Anda.

Sampai sini satu jam. Manifest JIT dan hook tidak terlambat diperkenalkan sekitar saat jumlah atom melampaui 50, ketika pemuatan otomatis mulai terasa berat. Pada titik itu, Anda tinggal memasang inject_memory.py dari 1.3.2.

1.3.7 Kesalahan Umum dan Cara Menghindarinya

Kesalahan yang berulang pada awal penerapan dapat dikelompokkan menjadi lima, dan masing-masing berdiri di atas akar penyebab yang sama.

Tidak perlu menghindari kelimanya sejak hari pertama. Pembengkakan global dan luputnya cadangan sebaiknya pola penghindarannya sudah dipasang dalam satu jam pertama, sedangkan tiga sisanya lebih alami jika perangkat penghindarnya disisipkan di tempat yang paling mungkin menjadi kecelakaan bagi Anda, sambil beroperasi sekitar satu bulan.

1.3.8 Menutup Bagian 1

1.1 adalah tempat untuk mengurangi rasa jarak di hadapan alat, 1.2 adalah tempat untuk memahami mekanisme kerja minimum alat itu, dan 1.3 adalah tempat untuk memasang infrastruktur pertama dengan memori, izin, dan settings. Ketiga bab ini merupakan bagian pembuka buku. Begitu sampai sini, kerangka dasar untuk mengoperasikan alat tanpa berhenti pun sudah menempati posisinya.

Intinya adalah bahwa kerangka ini bukanlah konfigurasi yang statis. atom di manifest bertambah tiap minggu, daftar allow memanjang mengikuti jejak pekerjaan, dan score terakumulasi melalui verifikasi. Infrastruktur tidak selesai begitu dipasang, melainkan tumbuh bersama pengguna di atas yang sudah terpasang. Selisih yang melebar dari 17 di PC pribadi menjadi 304 di kantor adalah jarak pertumbuhan itu.

Mulai Bagian 2, kita masuk ke arsitektur informasi yang sesungguhnya. Bab 4 YAML frontmatter, Bab 5 Atom, Bab 6 Layer, dan Bab 7 ontologi mengikuti secara berurutan. atom yang di 1.3 hanya kita lihat sebagai satu entri manifest akan menjadi tokoh utama satu bab di 2.2. Hanya setelah tulang punggung terpasang, bab-bab per bidang akan menemukan tempatnya masing-masing di atas koordinat yang sama.

Poin-Poin Penting

• Penyuntikan memori otomatis berstruktur: satu baris hook di settings.json membangunkan inject_memory.py
• Daftar allow izin bukanlah konfigurasi melainkan jejak penumpukan pekerjaan, dan dibersihkan tiap kuartal
• Infrastruktur bukan selesai begitu dipasang, melainkan kerangka hidup tempat atom, izin, dan score tumbuh bersama

Pratinjau Bab Berikutnya

• Awal Bagian 2: Bab 4. YAML frontmatter — Menjadikan setiap dokumen sebagai data

Coba Sendiri

setup 1. Buka ~/.claude/settings.json, dan sebelum mengubah, buat cadangan sebagai settings.json.bak_<tanggal hari ini>. 2. Masukkan Read(*), Grep(*), Bash(ls:*), Bash(git status:*) ke permissions.allow, dan masukkan Bash(rm -rf:*), Bash(git push --force:*) ke permissions.deny. 3. (Saat atom 50 atau lebih) Daftarkan python ~/.claude/hooks/inject_memory.py di hooks.UserPromptSubmit, lalu tulis entri atom (name, path, regex, score) dan config.max_matches: 3 di _jit_manifest.json.

prompt - Di sesi baru, lemparkan pertanyaan yang sengaja memuat salah satu kata kunci atom di manifest. Contoh: "lihat penyeimbangan skill berdasarkan aturan cooldown".

verify - Periksa apakah segera setelah masukan muncul sinyal seperti [memory injected: N atoms]. - Lihat apakah atom yang Anda maksudkan tercermin dalam respons. - Coba sengaja masukkan JSON yang rusak ke manifest, lalu pastikan prompt tetap tidak terhambat dan berjalan (exit 0 dijamin), kemudian kembalikan ke semula.

Versi Ringkas Solo - Mulailah tanpa hook maupun manifest. Tulis saja 3 baris identitas + 3 baris aturan kolaborasi di satu berkas global MEMORY.md, dan setel hanya Read(*) dan Grep(*) sebagai izin otomatis. Saat atom sudah terbiasa di tangan dan mendekati 50, baru saat itu pasangkan hook dari 1.3.2. Infrastruktur dimulai kecil lalu dibesarkan mengikuti jejak, bukan dilengkapi 304 sejak awal.

Bagian 2 · Arsitektur Informasi

2.1 YAML Frontmatter — Setiap Dokumen sebagai Data

Malam menjelang build milestone, rekan tim System Designer, anggota A, bertanya lewat messenger. "Ada berapa dokumen yang menyentuh kurva reward minggu ini? Sampai mana yang sudah selesai ditinjau?" Saya tidak tahu jawabannya. Dokumen-dokumen itu ada di suatu tempat dalam folder, dan soal siapa yang terakhir menyentuhnya atau milestone mana — semuanya tercecer di ingatan masing-masing orang dan di kesepakatan penamaan file. Yang kami lakukan malam itu adalah membuat satu kesepakatan: menulis enam baris di awal setiap dokumen. Enam baris itulah yang, mulai milestone berikutnya, membuat pertanyaan anggota A bisa dijawab tanpa seorang pun perlu membuka folder.

Beberapa baris YAML yang ditulis di antara tanda --- di paling atas dokumen. Inilah yang disebut frontmatter. Kesepakatan ini memberi tahu "dokumen ini apa" kepada manusia dan mesin secara bersamaan, tanpa membaca satu huruf pun dari isi dokumen. Bab ini menelusuri bagaimana satu baris itu menjadi koordinat masuk ke seluruh arsitektur informasi, dengan skrip yang benar-benar berjalan.

Ada satu istilah yang ingin saya tegaskan lebih dulu. Buku ini membagi dokumen desain menjadi lima Layer (dibahas serius di Bab 6). L0=worldview/konsep, L1=aturan sistem, L2=konten, L3=data, L4=koordinat implementasi. Arah ketergantungan yang normal adalah dari atas ke bawah. layer: 2 yang muncul di subbab berikutnya adalah deklarasi koordinat yang berarti "dokumen ini adalah Layer konten".

2.1.1 Mengapa Bukan "Dokumen", tetapi "Dokumen sebagai Data"

Dokumen desain tradisional hidup di atas Word, PPT, dan Google Docs. Isinya dioptimalkan agar enak dibaca manusia. Namun metainformasi seperti jenis dokumen, penanggung jawab, status, dan lokasi justru melebur ke dalam isi, atau bergantung pada struktur folder dan kesepakatan penamaan file. Akibatnya, untuk mengetahui "dokumen ini milik milestone yang mana, siapa penanggung jawabnya, dan kapan terakhir ditinjau", Anda harus membuka dan membaca isinya.

Di sini bertumpuk dua keterbatasan. Pertama, dokumen tidak menyatakan identitasnya sendiri. Identitas itu ada di ingatan orang dan kesepakatan folder, dan kesepakatan itu lapuk seiring waktu. Kedua, AI tidak punya petunjuk untuk menyimpulkan konteks. Jika Anda meminta Claude Code "tinjau dokumen ini", ia akan membaca isinya dari awal hingga akhir sambil memboroskan token, dan ia pun tidak tahu sampai mana batas tanggung jawab dokumen itu.

YAML frontmatter menyelesaikan keduanya sekaligus. Jika Anda menuliskan metadata secara eksplisit di baris-baris awal dokumen, manusia maupun mesin bisa mengidentifikasi dokumen tanpa membuka isinya. Sama seperti label yang ditempel di muka laci lemari arsip: Anda tahu isi laci tanpa membukanya. Dan label ini bukan sekadar alat klasifikasi. Seperti yang akan kita lihat nanti, satu field layer saja menjadi koordinat masuk bagi procedural generation (pembangkitan prosedural) dan tinjauan otomatis.

2.1.2 Frontmatter Nyata — 14 Baris Pertama dari Sebuah Dokumen

Alih-alih contoh abstrak, kita lihat langsung frontmatter yang benar-benar terpasang di kepala dokumen kurva reward Proyek A (hanya ID dan nama asli yang disamarkan; strukturnya persis seperti yang dioperasikan).

---
title: "Kurva Reward Quest Utama Bab 12"
layer: 2
status: review
owner: teammate_a
created: 2026-04-15
updated: 2026-05-20
related:
  - quest_main_chapter12
  - reward_curve_milestone_2
affects:
  - L3_BalanceSheet_v2
ip_check: passed
---

# Kurva Reward Quest Utama Bab 12

(isi dokumen dimulai)

Intinya adalah pemisahan antara bagian di atas dan di bawah ---. Bagian atas adalah data yang dibaca parser; bagian bawah adalah isi yang dibaca manusia. Renderer Markdown umumnya menyembunyikan frontmatter, sehingga tidak mengganggu saat dibaca. Satu file memuat data (frontmatter) dan konten (isi) sekaligus, sehingga menjadi sumber kebenaran tunggal (single source of truth).

layer: 2 dan affects: [L3_BalanceSheet_v2] — dua baris inilah yang patut diperhatikan. Ini adalah deklarasi bahwa "dokumen konten (L2) ini memberi pengaruh pada balance sheet di Layer data (L3)". Hanya dengan ini, alat bantu bisa menggambar relasi ketergantungan L2→L3 dalam bentuk graf tanpa membaca isi. Sebaliknya, jika dokumen data L3 mereferensikan aturan sistem L1 lewat depends_on (ketergantungan terbalik dari bawah ke atas), itu adalah aroma desain (design smell). Alat bantu mendeteksi referensi terbalik itu secara otomatis.

Alasan YAML lebih nyaman ditulis tangan daripada JSON sederhana saja: struktur dinyatakan dengan indentasi, tanda kutip nyaris tak diperlukan, dan Anda bisa menulis komentar dengan #. Cocok untuk diisi sendiri oleh Game Designer.

2.1.3 Di Mana Standar Itu Tinggal — _NAMING_FRONTMATTER_STANDARD

Field bisa ditambah tanpa batas. Semakin banyak ditambah, beban penulisan makin besar dan standar pun runtuh. Karena itu Proyek A mengoperasikannya dalam dua lapis: field inti minimum yang sama untuk semua dokumen, dan field perluasan domain per bidang.

Field inti minimum yang berlaku umum ada enam.

Hanya dengan enam ini, Anda langsung tahu kesegaran, tanggung jawab, dan lokasi dokumen. Tahan dorongan untuk menambah lebih banyak selama bulan pertama. Saat dijalankan, field mana yang benar-benar diperlukan akan muncul dengan sendirinya.

Field perluasan per bidang berbeda-beda untuk tiap domain. System Designer gemar memakai depends_on·affects, Combat Designer memakai combat_phase·anim_target, naratif memakai world_region·chapter, dan balancing memakai data_sheet·formula_id. Karena field-field perluasan ini tidak boleh tercecer bebas, satu dokumen standar tunggal yang memaku nama resmi, nilai yang diizinkan, dan contohnya. Dokumen itu adalah _NAMING_FRONTMATTER_STANDARD.md. Untuk menambah field baru, Anda harus melewati dokumen ini. Dan dokumen standar ini sendiri terdaftar sebagai atom, sehingga dikelola dalam keluarga yang sama dengan aturan yang memaksa nomor Layer di depan nama dokumen (atom docs_layer_numeric_prefix_naming).

Di sinilah terjadi peralihan penting. Jika standar hanya berupa dokumen yang dibaca manusia, manusia akan melanggarnya. Jika standar dijadikan data yang dibaca mesin, mesin yang akan memaksanya. Subbab berikutnya adalah kode nyata dari peralihan itu.

2.1.4 Worked Transcript — Memaksa Standar Lewat Kode, dan Pelajaran dari Bug datetime

Sekarang saya menyuruh Claude Code membuat "Linter yang memeriksa apakah semua dokumen Markdown Proyek A mematuhi standar frontmatter". Tuntutan intinya ada dua. Pertama, ia harus menangkap item pemeriksaan (field wajib yang hilang, nilai status non-standar, pelanggaran layer 0\~4, dokumen yang berstatus review tetapi tak berubah lebih dari 90 hari). Kedua, jangan menanam nilai yang diizinkan langsung ke dalam kode (hardcode); bacalah dari dokumen standar. Pemisahan inilah intinya. Jika Anda mengubah standar, kriteria pemeriksaan berubah tanpa perlu mengubah kode. (Naskah lengkap skrip dan prosedur menjalankannya secara langsung diletakkan di bagian "Coba Sendiri" di akhir bab ini.)

Di sini terjadi sebuah insiden. Kode yang pertama kali dikeluarkan Claude menghitung selisih tanggal dengan today - fm["updated"] di pemeriksaan STALE, dan pada komentar ia menulis "kalau ditulis seperti updated: 2026-05-20, PyYAML akan otomatis mem-parsing-nya menjadi datetime.date". Pernyataan ini hanya separuh benar. Saat dijalankan pada dokumen nyata, sebagian file memunculkan traceback.

TypeError: unsupported operand type(s) for -: 'datetime.date' and 'str'

Penyebabnya ada di tangan manusia. Sebagian penulis menulis updated: 2026-05-20 (terparsing sebagai date), sebagian lain menulis updated: "2026-05-20" dengan tanda kutip (terparsing sebagai string). Di tempat yang tidak dipaku standar soal format tanggal, tangan manusia bercabang, dan Claude hanya berasumsi pada satu sisi. Saya menolak kode itu dan kembali meminta "normalisasikan kedua notasi dengan aman menjadi date, dan saring juga kasus saat updated tidak ada". Claude menyisipkan helper yang memeriksa tipe input lalu menormalkan keduanya menjadi datetime.date (blok perbaikannya juga ada di "Coba Sendiri").

Pelajaran yang sesungguhnya bukanlah bug kode itu. Melainkan bahwa di tempat yang tidak dipaku standar soal format penulisan tanggal, tangan manusia bercabang. Karena itu saya menambahkan satu baris updated: YYYY-MM-DD (tanpa tanda kutip) ke dalam _NAMING_FRONTMATTER_STANDARD.md. Linter, saat memeriksa kode, justru menyingkapkan lubang pada standar yang menjadi acuan pemeriksaan itu sendiri.

Keluaran pertama dari skrip yang sudah diperbaiki tidaklah bersih. Saya biarkan apa adanya hasil berantakan yang benar-benar muncul.

[NO-FM]   manuscript/legacy/old_combat_notes.md
[MISSING] manuscript/system/quest_flag_table.md: layer
[STATUS]  manuscript/content/town_intro.md: WIP
[LAYER]   manuscript/balance/dps_v2.md: None
[STALE]   manuscript/system/inventory_rules.md: 134d

Lima baris ini adalah kondisi nyata tim di awal penerapan. Dokumen lama sama sekali tak punya frontmatter (NO-FM), satu dokumen melupakan layer, seseorang memakai nilai non-standar status: WIP, satu dokumen balancing mengosongkan layer menjadi None, dan satu dokumen aturan sistem tertidur dalam status review selama 134 hari. Standar memang tidak dipatuhi sejak awal. Linter hanya menyingkapkan kenyataan itu setiap pagi.

2.1.5 Dari frontmatter ke Skrip — Alurnya

Jika worked transcript di atas dipadatkan menjadi satu alur, hasilnya seperti berikut. Ia memperlihatkan bagaimana satu baris yang ditulis manusia mengalir hingga ke gerbang pemeriksaan mesin.

flowchart TD
    A["Penulis: membuat dokumen baru
template menyisipkan 6 field frontmatter otomatis"] --> B["Isi hanya nilai yang kosong
title / layer / status / owner ..."]
    B --> C["File .md tersimpan
--- frontmatter --- + isi"]
    C --> D["Jalankan skrip Linter
rglob('*.md')"]
    D --> E["_NAMING_FRONTMATTER_STANDARD.md
membaca nilai yang diizinkan"]
    E --> F{"Periksa
field wajib / status / layer / stale"}
    F -->|"Lolos"| G["Masukan graf relasi
related·affects → ketergantungan koordinat L"]
    F -->|"Langgar"| H["Laporan harian
notifikasi otomatis ke owner penanggung jawab"]
    H --> B
    G --> I["Bisa ditanya AI
'kumpulkan dokumen Layer2 review' → jawaban instan"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class A,B human
    class D,F code
    class C,E,G data
    class H fail
    class I ai

Intinya ada dua. Pertama, standar (E) terpisah dari skrip (D). Jika Anda mengubah standar, kriteria pemeriksaan berubah tanpa perlu mengubah kode. Kedua, pelanggaran (H) bukanlah jalan buntu, melainkan loop yang berputar kembali ke tahap penulisan (B). Ini bukan menyalahkan orang, melainkan mengembalikan agar penulis sendiri memperbaiki dokumennya sendiri.

2.1.6 Kasus Operasional — Enam Bulan di Sebuah Tim Berukuran Menengah

Proyek A yang saya operasikan sebagai direktur menerapkan frontmatter ke seluruh tim desain (4\~5 orang) kira-kira enam bulan lalu. Penerapannya tidak terjadi sekaligus, melainkan melewati empat ruas.

Penolakan terbesar di minggu pertama penerapan adalah "harus menulis ini dengan tangan setiap kali?" Menghafal dan menuliskan enam baris untuk tiap dokumen baru itu merepotkan. Solusinya adalah penyisipan template otomatis. Snippet VSCode, template Obsidian, dan tombol "dokumen baru" di portal desain menyisipkan blok YAML kosong secara otomatis. Penulis hanya mengisi nilai yang kosong. Penolakan itu lenyap dalam waktu seminggu.

Pada bulan pertama, bentrokan standar meletus. Saat banyak orang menambah field secara bebas, owner·responsible·author muncul bersamaan. Konsepnya sama tetapi notasinya tiga macam, sehingga pencarian maupun otomatisasi pun rusak. Solusinya adalah merapikan nama resmi, nilai yang diizinkan, dan contoh untuk semua field ke dalam satu dokumen _NAMING_FRONTMATTER_STANDARD.md, lalu menjadikan penambahan field baru sebagai aturan yang harus lewat dokumen ini. Standar stabil dalam waktu sebulan.

Pada bulan ketiga, masuklah Linter yang kita lihat di 2.1.4. Meski ada standar, manusia tetap melanggar. Karena itu setiap pagi laporan konsistensi dibuat otomatis dan jatuh ke kanal bersama di messenger tim. Penanggung jawab cukup melihat dokumennya sendiri. Setelah otomatisasi, pelanggaran standar berkurang secara mencolok (perkiraan penulis, bukan nilai pengukuran presisi — terasa kira-kira separuh ke bawah).

Pada bulan keenam, perpaduan dengan AI bersinar. Begitu standar stabil, pertanyaan seperti berikut kembali sebagai jawaban instan.

• "Kumpulkan semua dokumen Layer 2 yang diperbarui dalam 2 minggu terakhir yang status-nya review"
• "Gambarkan linimasa perubahan status dari semua dokumen yang owner-nya saya"
• "Tarik daftar dokumen lain yang terpengaruh oleh permintaan perubahan ini" — secara otomatis mengikuti graf related·affects

Pada akhirnya frontmatter menjadi kosakata bersama antara manusia dan AI. Saat manusia menulis, AI memahaminya; saat AI menulis, manusia memverifikasinya. Keduanya melihat key yang sama. Hanya saja, penolakan minggu pertama, bentrokan bulan pertama, Linter bulan ketiga, perpaduan bulan keenam — semua itu hasil dari enam bulan yang menumpuk, bukan sesuatu yang muncul dalam sekali jalan.

2.1.7 Kesalahan Umum dan Cara Menghindarinya

Kesalahan yang berulang di awal penerapan terangkum dalam lima hal. Semuanya berdiri di atas akar yang sama — "tempat di mana standar hanya diserahkan kepada kemauan manusia".

Tak perlu mencegah kelima kesalahan ini sejak hari pertama. Lebih alami jika pola penghindaran untuk nomor 1·3 ditetapkan di minggu pertama penerapan, sementara nomor 2·4·5 disisipkan satu per satu mulai dari tempat yang paling sering ditubruk tim Anda sendiri sambil berjalan.

2.1.8 Mulai dari yang Kecil — Memapankan dalam 3 Minggu

Penerapan frontmatter ternyata pekerjaan yang ringan. Dalam 3 minggu, ia sudah mapan dalam satu tim.

Pada minggu pertama, definisikan enam field inti dan buat template, lalu terapkan hanya pada dokumen baru agar beban penulisan minimal. Pada minggu kedua, terapkan secara manual pada 20 dokumen teratas yang paling sering dilihat, untuk memeriksa field mana yang kurang dalam penggunaan nyata. Pada minggu ketiga, jika Linter dan laporan harian dijalankan, sejak saat itu standar dijaga bukan oleh kemauan manusia, melainkan oleh kekuatan alat.

Jangan memigrasikan seluruh dokumen lama sekaligus. Terapkan mulai dari yang sering dilihat, mulai dari dokumen baru. Setelah sekitar enam bulan, frontmatter menempel pada hampir semua dokumen. Meski begitu, 100% bukanlah targetnya. Menghabiskan waktu memigrasikan bahkan dokumen lama yang tak pernah sekali pun dibuka adalah pemborosan.

Coba Sendiri

Dalam unit terkecil, kita putar satu siklus secara langsung.

setup - Taruh 2\~3 dokumen .md sasaran pemeriksaan di folder kerja. Sengaja kosongkan layer pada sebagian, atau masukkan nilai non-standar seperti status: WIP. - Taruh satu baris dokumen standar di folder yang sama. status: allowed = ["draft", "review", "approved", "archived"] updated: YYYY-MM-DD (tanpa tanda kutip)

prompt (masukkan ke Claude Code)

Tuliskan skrip Python yang memeriksa YAML frontmatter dari semua .md di bawah folder ini. Tangkap field wajib title·layer·status·owner yang hilang, pelanggaran nilai status yang diizinkan (baca dari dokumen standar), pelanggaran layer yang bukan bilangan bulat 0\~4, dan dokumen berstatus review yang updated-nya melebihi 90 hari. Tangani dengan aman baik saat updated datang sebagai string maupun sebagai date, dan keluarkan pelanggaran per file.

verify - Jalankan skrip dan pastikan semua pelanggaran yang sengaja ditanam tertangkap. - Tambahkan WIP ke daftar allowed di dokumen standar, lalu jalankan ulang, dan pastikan status: WIP berubah menjadi lolos meski Anda tidak mengubah satu baris kode pun. Ini bukti bahwa standar dan kode terpisah. - Masukkan baik dokumen yang updated-nya diberi tanda kutip maupun yang tidak, dan pastikan TypeError yang kita lihat di 2.1.4 tidak muncul.

Referensi: Naskah Lengkap Skrip Linter

Inilah kode yang pertama kali dikeluarkan Claude di 2.1.4. Pada baris pemeriksaan STALE (age = (today - fm["updated"]).days) bug datetime masih ada apa adanya.

import sys, datetime, pathlib, re
import yaml  # PyYAML

ROOT = pathlib.Path("manuscript")
STANDARD = pathlib.Path("_NAMING_FRONTMATTER_STANDARD.md")
REQUIRED = ["title", "layer", "status", "owner"]

def load_allowed_status(standard_path):
    # Mengekstrak nilai `status` yang diizinkan dari dokumen standar
    text = standard_path.read_text(encoding="utf-8")
    m = re.search(r"status:\s*allowed\s*=\s*\[(.*?)\]", text)
    if not m:
        return ["draft", "review", "approved", "archived"]
    return [s.strip().strip('"').strip("'") for s in m.group(1).split(",")]

def parse_frontmatter(md_path):
    text = md_path.read_text(encoding="utf-8")
    if not text.startswith("---"):
        return None
    end = text.find("---", 3)
    block = text[3:end]
    return yaml.safe_load(block)

def main():
    allowed = load_allowed_status(STANDARD)
    today = datetime.date.today()
    violations = 0
    for md in ROOT.rglob("*.md"):
        fm = parse_frontmatter(md)
        if fm is None:
            print(f"[NO-FM]   {md}")
            violations += 1
            continue
        for field in REQUIRED:
            if field not in fm:
                print(f"[MISSING] {md}: {field}")
                violations += 1
        if fm.get("status") not in allowed:
            print(f"[STATUS]  {md}: {fm.get('status')}")
            violations += 1
        if not isinstance(fm.get("layer"), int) or not (0 <= fm.get("layer") <= 4):
            print(f"[LAYER]   {md}: {fm.get('layer')}")
            violations += 1
        if fm.get("status") == "review":
            age = (today - fm["updated"]).days   # ← di sinilah yang rusak
            if age > 90:
                print(f"[STALE]   {md}: {age}d")
                violations += 1
    sys.exit(violations)

Blok inti yang diperbaiki setelah permintaan ulang. updated dinormalkan dengan aman baik saat datang sebagai string maupun sebagai date.

def as_date(v):
    if isinstance(v, datetime.date):
        return v
    if isinstance(v, str):
        return datetime.date.fromisoformat(v.strip())
    return None

# Bagian pengganti pemeriksaan STALE di dalam main()
if fm.get("status") == "review":
    upd = as_date(fm.get("updated"))
    if upd is None:
        print(f"[MISSING] {md}: updated")
        violations += 1
    elif (today - upd).days > 90:
        print(f"[STALE]   {md}: {(today - upd).days}d")
        violations += 1

Versi Ringkas Solo

Anda tidak perlu punya tim. Di folder catatan yang Anda pakai sendiri, kurangi field inti menjadi tiga saja — title·status·updated — dan biarkan Linter hanya menangkap "dokumen yang status-nya review tetapi updated-nya melebihi 30 hari". Hanya dengan ini pun, "dokumen yang saya tinggalkan setengah jadi saat meninjau lalu lupa" akan muncul ke permukaan sekali setiap minggu. Segitiga standar-template-pemeriksaan tetap bekerja apa adanya bahkan pada skala satu orang.

Poin-Poin Penting

• Satu baris frontmatter adalah bata data terkecil untuk mengidentifikasi dokumen tanpa membaca isinya
• Jika standar dipisahkan dari kode dan ditaruh sebagai dokumen, kriteria pemeriksaan bisa diubah tanpa mengubah kode
• Satu field layer menjadi koordinat masuk bagi procedural generation (pembangkitan prosedural) dan tinjauan otomatis

2.2 Atom per Halaman — Anatomi Satu Dokumen Satu Keputusan

Pada minggu pertama seorang anggota baru bergabung, ia bertanya lewat chat. "Apakah cooldown (waktu jeda) tempur memang 0.6 detik? Tertulis di dokumen yang mana?" Saya menjawab, "Ada di GDD (Game Design Document, spesifikasi rinci) sistem skill." Ia bertanya lagi. "Bagian mana di GDD itu? Setelah desain class ada kurva damage, lalu sampai cara menampilkan UI — totalnya 220 baris, lho." Saya buka filenya dan saya carikan sendiri untuknya. Ada di baris ke-137. Pertanyaan terakhirnya: "Tapi kenapa 0.6 detik? Apa 0.5 tidak boleh?" Jawaban itu tidak ada di dokumen mana pun. Saya ingat keputusannya diambil pada rapat 6 bulan lalu, tetapi alasannya terkubur di suatu tempat dalam notulen rapat.

Di dalam percakapan 5 menit ini, terkandung tiga kegagalan dari dokumen gabungan 220 baris itu. Tidak bisa menemukan lokasinya (kegagalan pencarian), tidak ada alasannya (konteks hilang), dan setiap kali harus ada manusia yang menjadi perantara (tidak bisa diotomasi). Jika pertanyaan yang sama dilemparkan ke AI, keadaannya bahkan lebih buruk. AI membaca seluruh 220 baris itu, lalu menjawab sambil mencampurkan pembahasan kurva damage yang sama sekali tidak berhubungan dengan cooldown.

Resep bab ini sederhana. Satu dokumen hanya memuat satu keputusan. Dokumen unit keputusan yang dipotong halus dengan prinsip ini saya sebut atom. Jika GDD 220 baris itu dipecah, "cooldown adalah 0.6 detik" menjadi satu atom, dan di dalam atom itu lokasi, isi, alasan, pengecualian, dan relasi berkumpul di satu tempat. Bab ini, alih-alih berbicara secara abstrak, membedah satu atom nyata hingga tuntas. Bagaimana memberinya nama, frontmatter apa yang diisi, bagaimana relasinya dinyatakan, dan akhirnya bagaimana AI memilih tepat satu atom itu saja secara akurat.

2.2.1 Memilih Satu Spesimen — combat_cooldown_rule_v2

Spesimen yang akan dibedah adalah satu atom yang benar-benar dijalankan di Proyek A. Namanya combat_cooldown_rule_v2. Isi lengkap filenya seperti berikut. Tidak panjang. Karena hanya memuat satu keputusan.

---
name: combat_cooldown_rule_v2
title: "Aturan Cooldown Tempur — v2"
type: rule
layer: 1
status: approved
owner: 이민수
created: 2026-03-10
updated: 2026-05-12
applies_to: [skill_system, item_system]
---

# Aturan Cooldown Tempur v2

Why (mengapa): Untuk membatasi jumlah skill yang dapat dipakai
bersamaan sehingga beban pengambilan keputusan instan berkurang,
dan untuk mempertahankan makna dari input combo.

Rule (aturan): Semua skill aktif memiliki global cooldown 0.6 detik +
cooldown individual (didefinisikan per skill). Selama global cooldown
sedang berjalan, tidak ada skill aktif yang bisa di-cast.

How to apply (penerapan):
- Saat mendefinisikan skill baru, cooldown individual wajib dinyatakan
- Jika kolom cooldown pada L3_SkillSheet bernilai 0, itu pelanggaran aturan ini
- Pemeriksaan konsistensi pada tahap build mendeteksi pelanggaran secara otomatis

Exceptions (pengecualian):
- Skill pasif tidak terkena aturan ini
- Ultimate menggunakan sistem gauge tersendiri (See: [[ultimate_gauge_system]])

Relations (relasi):
- affects: [[combat_dps_calculation_v3]], [[balance_curve_v3]]
- derives_from: [[principle_decision_load_reduction]]
- conflicts_with: [[skill_cancel_rule_legacy_v1]]
- requires: [[combat_input_buffer_system]], [[skill_system_v2]]
- is_a: rule
- part_of: combat_system_master

Satu lembar file ini saya belah menjadi lima bagian: penamaan, frontmatter, keputusan tunggal, relasi, dan ketertelusuran. Kelima bagian itu harus lengkap agar AI membaca atom ini sebagai "unit yang masuk akal meski berdiri sendiri".

2.2.2 Bagian ① Penamaan — Nama Itu Sendiri adalah Koordinat

Nama filenya adalah combat_cooldown_rule_v2. Bukan nama yang dibuat asal-asalan, melainkan memiliki struktur tiga potongan.

combat_         cooldown_rule          _v2
└ prefix        └ isi keputusan        └ versi
  (domain mana)   (keputusan tentang apa) (revisi ke berapa)

Prefix combat_ adalah koordinat yang menyatakan "ini keputusan di domain tempur". Atom aturan Proyek A dipisahkan domainnya berdasarkan prefix. quest_ (quest), data_ (operasional data), docs_ (operasional dokumen), meeting_ (notulen rapat), portal_ (penampil desain). Cukup dengan melihat prefix saja, sudah terlihat keputusan ini berada di wilayah tanggung jawab siapa dan dari mana ia menerima pengaruh.

Jika penamaan goyah, semuanya ikut goyah. Jika keputusan yang sama hadir dua kali sebagai skill-cooldown.md dan cooldown_skill_v2.md, pencarian pun rusak dan pencocokan JIT yang akan dibahas nanti juga rusak. Karena itu, Proyek A lebih dulu mengunci aturan penamaan itu sendiri sebagai satu atom. Itulah atom_naming_convention_v1, yang memaksakan snake_case, prefix wajib, dan suffix versi. Dan aturan ini dijaga bukan oleh kemauan manusia, melainkan oleh Linter. Jika nama file tanpa prefix di-commit, ia akan tertangkap pada tahap build.

Di balik penamaan tertanam desain yang lebih besar, yang menembus seluruh buku ini. layer: 1 pada frontmatter adalah koordinat kedua itu. Jika prefix menyatakan "domain mana", maka Layer menyatakan "lapisan abstraksi mana". Kedua koordinat harus bergabung agar posisi atom terkunci sebagai satu titik pada sebuah bidang. Di sini Layer hanyalah koordinat (detail definisi lapisan 0\~4 ada di 2.3). Aturan cooldown adalah "aturan input yang mengontrol pembangkitan", sehingga ia duduk di Layer 1. Ada pula aturan tersendiri yang memaksakan koordinat Layer ini sebagai prefix angka di depan nama dokumen — docs_layer_numeric_prefix_naming. Dengan kata lain, di dalam satu nama tertera dua sumbu koordinat.

Esensi dari desain ini bukanlah obsesi kerapian. Ada kalimat yang berulang kali saya katakan ke tim. "Layer itu kita bagi memang demi procedural generation, kan." Jika setiap atom memiliki koordinat domain (prefix) dan koordinat lapisan (Layer) yang dinyatakan secara eksplisit, nantinya menjadi mungkin bagi AI untuk "menerima seluruh aturan combat Layer 1 sebagai input dan membangkitkan konten Layer 2 secara otomatis". Nama adalah sistem alamat dari otomasi itu.

2.2.3 Bagian ② frontmatter — Label yang Dibaca Mesin

Blok YAML di antara --- di atas isi adalah frontmatter. Ini adalah penerapan standar yang dibahas di 2.1 langsung ke atom, dan merupakan label yang dibaca bukan oleh manusia melainkan oleh mesin (skrip build, hook JIT, generator peta relasi).

Jika label-label ini sudah terisi, pemeriksaan otomatis menjadi mungkin. Sebagai contoh, jika sebuah aturan sistem yang dideklarasikan dengan layer: 1 di dalam isinya langsung mereferensikan atom data (Layer 3) seperti [[L3_SkillSheet_row_0042]], maka itu adalah referensi terbalik (L3→L1) di mana lapisan atas terikat pada nilai konkret lapisan bawah. Proyek A mendeteksi pola ini secara otomatis pada tahap build. Sebab aturan harus mereferensikan format data, bukan satu baris data. Tanpa satu baris layer di frontmatter, pemeriksaan ini sendiri tidak dapat terbentuk.

Penanganan status: archived juga merupakan tugas frontmatter. Jika sebuah keputusan berubah, atom tidak dihapus melainkan menerima status: archived + tanggal archived_at. Build dan JIT mengecualikan atom yang archived. Catatannya tetap ada, tetapi ia keluar dari barisan aktif. Dalam operasional 6 bulan di Proyek A, tingkat pengarsipan (archived) sekitar 15% (pengukuran nyata penulis). Jika rasio ini mendekati 0%, saya membacanya sebagai sinyal bahwa alur kerja pengarsipan tidak berfungsi.

2.2.4 Bagian ③ Keputusan Tunggal — Apakah Bisa Diringkas dalam Satu Kalimat

Inti dari membedah atom adalah memastikan bahwa isinya hanya memuat satu keputusan. Cara memeriksanya sederhana. Coba ringkas keputusan atom ini dalam satu kalimat.

"Semua skill aktif memiliki global cooldown 0.6 detik."

Selesai dalam satu kalimat. Lulus. Jika ringkasannya menjadi dua kalimat seperti "cooldown adalah 0.6 detik, dan selama combo dipangkas 50%", itu berarti dua keputusan. Pecahlah menjadi combat_cooldown_rule_v2 (cooldown dasar) dan combat_combo_cooldown_reduction_v1 (pemangkasan combo).

Ada dua pemeriksaan bantu lagi untuk melihat ketunggalan.

Pemeriksaan penghapusan independen. Apakah jika hanya atom ini saja yang dihapus, sistem tidak runtuh? Jika aturan cooldown dihapus, balance tempur memang goyah, tetapi sistem tetap berjalan. Unitnya tepat. Sebaliknya, jika saat dihapus lima atom lain ikut runtuh bersamanya, maka kelima atom itu sebenarnya adalah lima kepingan dari satu keputusan. Mereka harus disatukan menjadi atom yang lebih besar.

Pemeriksaan referensi tunggal. Apakah dari tempat lain, dengan hanya men-link [[combat_cooldown_rule_v2]] satu kali, maknanya sudah tersampaikan? Jika ya, unitnya tepat. Jika untuk mereferensikan satu baris ini Anda harus membaca banyak bagian isi, berarti ia belum cukup dipecah.

Isi yang lolos pemeriksaan-pemeriksaan ini secara alami tertata menjadi lima seksi — Why, Rule, How, Exceptions, Relations. Terutama, jangan hapus Why. Jawaban atas "kenapa 0.6 detik?" yang ditanyakan anggota baru di akhir pada pengantar di depan tadi ada di sini — "untuk mengurangi beban pengambilan keputusan instan dan mempertahankan makna input combo." Saat 6 bulan kemudian seseorang mengusulkan "ayo turunkan jadi 0.5 detik", satu baris ini menjadi titik tolak diskusi. Atom yang Why-nya hilang akan menjadi fosil yang tak seorang pun berani menyentuhnya.

2.2.5 Bagian ④ Relasi — Panah Membuat Analisis Dampak

Seksi Relations di paling bawah atom menjadikan spesimen ini bukan memo yang terisolasi, melainkan satu node dalam sebuah graf. Intinya bukan sekadar "dokumen terkait", melainkan bahwa ia menyatakan secara eksplisit jenis relasinya.

flowchart TD
    P["Prinsip: pengurangan beban keputusan"] -->|derives_from| C["combat_cooldown_rule_v2"]
    C -->|affects| A1["combat_dps_calculation_v3"]
    C -->|affects| A2["balance_curve_v3"]
    C -->|requires| R1["combat_input_buffer"]
    C -->|requires| R2["skill_system_v2"]
    C -.->|conflicts_with| X["skill_cancel_legacy_v1
(konflik, akan dihapus)"]
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class P,C,A1,A2,R1,R2 data
    class X fail

Enam jenis relasi masing-masing melakukan tugas yang berbeda.

• derives_from: dari prinsip atas mana keputusan ini diturunkan. Cooldown 0.6 detik adalah perwujudan konkret dari prinsip "pengurangan beban pengambilan keputusan".
• affects: jika atom ini berubah, apa yang terkena dampak. Jika 0.6 detik diubah jadi 0.5 detik, kalkulasi DPS dan kurva balance akan goyah. Sebelum melakukan perubahan, jangkauan dampaknya bisa ditarik secara otomatis.
• requires: agar keputusan ini berdiri, apa yang harus ada lebih dulu. Tanpa sistem input buffer, global cooldown akan "memakan" input.
• conflicts_with: dengan apa ia bertentangan. Ia berkonflik dengan aturan skill cancel versi lama, dan link ini adalah sinyal bahwa "salah satu dari keduanya harus dihapus".
• is_a / part_of: klasifikasi (rule) dan keanggotaan (combat_system_master). Kerangka graf.

Seandainya hanya berupa link sederhana "Related: [Dokumen A], [Dokumen B]", manusia harus menelaahnya satu per satu. Jika jenis relasi diisi sebagai enum, mesinlah yang menelaahnya. "Tunjukkan semua yang terkena dampak jika atom ini diubah" menjadi kueri otomatis yang menelusuri affects, dan "cari semua aturan yang sekarang saling bertentangan" menjadi pemeriksaan otomatis yang memindai conflicts_with. Desain ontologi yang lengkap untuk keenam enum ini dibahas di 2.4, dan 2.2 hanya menegaskan bahwa standar atom sudah menerapkan enum itu terlebih dahulu.

Panah relasi juga merupakan input bagi alat pembuat peta relasi. gen_relation_map.py milik Proyek A membaca layer di frontmatter dan seksi Relations dari setiap atom, lalu secara otomatis menggambar peta relasi HTML interaktif yang diwarnai per Layer. Ini mungkin karena tiap-tiap atom memiliki koordinat (Layer) dan panah (Relations).

2.2.6 Bagian ⑤ Ketertelusuran — 30 Menit yang Dicegah oleh Satu Atom

Atom yang kelima bagiannya lengkap dapat ditelusuri. Siapa, kapan, dan mengapa membuat keputusan ini, serta apa yang ditangkap sebagai pelanggaran — semuanya ada di satu tempat. Nilai ketertelusuran paling jelas terlihat bukan dari statistik, melainkan dari insiden nyata yang berhasil dicegah.

Atom meeting_image_caption_standard milik Proyek A adalah aturan yang mewajibkan, pada gambar lampiran notulen rapat, menyatakan dalam caption "layar apa ini, mengapa dilampirkan, dan apa keputusannya". Pada masa sebelum atom ini ada, sebuah screenshot ditempel tanpa caption di suatu notulen, dan seminggu kemudian anggota tim yang melihatnya butuh 30 menit untuk mengonfirmasi "ini layar apa, ya?" kepada penulis notulen. Setelah atom itu dibuat, ketika kelalaian yang sama terulang, Linter pada tahap build secara otomatis menangkap gambar tanpa caption. Sampai perbaikannya selesai: 5 menit. 30 menit menjadi 5 menit.

Spesimen lain, skill_listing_budget_wrapper_only_policy, adalah aturan yang membatasi slot slash command global menjadi 12 buah, dan menempatkan skill induk di direktori terpisah tetapi hanya mengekspos 12 wrapper saja ke global. Sebelum dikunci jadi aturan, slash command global membengkak hampir 40 buah sehingga menggerogoti anggaran token setiap kali sesi dimulai. Setelah definisi atom, alat perapian otomatis merapikan kelebihannya setiap kali sesi dimulai. Aturan ditegakkan oleh alat, bukan oleh ingatan manusia.

Atom semacam ini terkumpul sekitar 304 buah di Proyek A (pengukuran nyata penulis, pada titik operasional 6 bulan). Jika dilihat hanya cabang besar distribusinya, aturan pencegahan kekambuhan (rule) memiliki porsi terbesar, lalu disusul oleh pengunci keputusan sekali pakai (decision), konsep domain (concept), dan koreksi kolaborasi (feedback), berurutan. Waktu yang dicegah oleh satu atom memang dalam hitungan menit, tetapi jika 304 buah terkumpul, akumulasi penghematannya melewati hitungan hari. Inilah alasan saya menyebut atom sebagai "aset" dan bukan "kerapian".

2.2.7 Dari Anatomi ke Injeksi Otomatis — Cara Kerja Nyata JIT

Sejauh ini saya membedah satu atom secara statis. Sekarang kita lihat saat ia bergerak hidup. Hook JIT (Just-In-Time) dari 1.3 hanya memilih atom yang cocok dengan kata kunci input, lalu menginjeksikannya ke konteks di tempat itu juga. Manifest JIT adalah JSON yang memetakan kata kunci pencocokan dan skor ke tiap atom.

{
  "name": "combat_cooldown_rule_v2",
  "path": "atoms/combat/combat_cooldown_rule_v2.md",
  "regex": "쿨다운|cooldown|글로벌 쿨다운|GCD",
  "score": 75
}

Injeksi yang sebenarnya mengalir seperti ini.

flowchart TD
    A["Input pengguna:
Kalau cooldown skill diturunkan jadi 0.5 detik?"] --> B["Hook JIT:
memindai regex di manifest"]
    B --> C{"Cocok dengan cooldown?"}
    C -->|"Ya score=75"| D["combat_cooldown_rule_v2
diinjeksikan utuh"]
    C -->|"Tidak"| E["Tidak diinjeksikan"]
    D --> F["AI membaca sampai Why·Rule·Exception
lalu merespons"]
    F --> G["Jawaban: 0.6 detik berdasar pengurangan
beban keputusan. Jika diturunkan ke 0.5 detik,
kalkulasi DPS·kurva balance yang menjadi
target affects perlu ditinjau ulang"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A human
    class B,C code
    class D data
    class F,G ai

Intinya ada di kotak terakhir. AI tidak hanya menjawab "tadinya 0.6 detik". Karena ia membaca Why dari atom, ia memberikan alasan; dan karena ia membaca affects dari Relations, ia bahkan menunjukkan lebih dulu target yang akan goyah saat diubah (kalkulasi DPS, kurva balance). Kelima bagian — yang dipecah halus, ditulis alasannya, dan dinyatakan relasinya — semuanya hidup dalam respons.

Di sinilah terlihat bahwa prinsip keputusan tunggal adalah prasyarat otomasi. Seandainya atom ini adalah GDD gabungan 220 baris, begitu satu kata "cooldown" cocok, desain class, kurva damage, hingga UI ikut diinjeksikan utuh sehingga anggaran token terpangkas, dan AI kehilangan fokus harus menjawab keputusan yang mana dari lima keputusan itu. Semakin kecil dan jelas atom, semakin tinggi akurasi JIT. Keadaan yang dipecah halus bukanlah kebajikan kerapian, melainkan prasyarat dari injeksi otomatis.

score adalah perangkat untuk menjaga anggaran konteks. Jika beberapa atom cocok dengan satu input, hanya N teratas berdasarkan score yang diinjeksikan (default 3 buah). Kriteria pemberian skor ditetapkan sambil beroperasi.

• atom terkait keselamatan·keamanan·kesehatan = 95\~99 (pantang terlewat)
• atom pesan inti·filosofi = 90\~94
• aturan inti domain = 75\~89 (aturan cooldown di sini, 75)
• atom rujukan·riwayat = 30\~50

2.2.8 Atom Pribadi dan Atom Bersama Tim — Pemisahan Dua Lapis

Spesimen yang dibedah, combat_cooldown_rule_v2, adalah atom bersama tim yang telah menerima status: approved. Tidak semua atom langsung sampai di posisi ini sejak awal. Proyek A membagi atom menjadi dua lapis.

• Atom pribadi — hipotesis belum pasti, memo pribadi, pengunci momen. Hanya dilihat sendiri. Standarnya longgar.
• Atom bersama tim — aturan yang sudah terverifikasi. Dilihat seluruh anggota tim. Harus lolos prosedur penamaan, struktur, dan persetujuan.

Alasan pemisahannya bersifat psikologis. Atom pribadi harus bebas agar hipotesis sebelum verifikasi bisa dicatat tanpa beban, dan bisa dibuang seminggu kemudian. Jika sejak awal terbuka ke tim, muncul pikiran "bagaimana kalau ini salah" sehingga akhirnya malah tidak dicatat sama sekali. Sebaliknya, atom bersama tim harus ketat agar semua orang mempercayai dan mereferensikannya.

combat_cooldown_rule_v2 pun mungkin pada awalnya hanyalah memo satu baris di atom pribadi, "ayo kita tes cooldown 0.6 detik". Setelah terverifikasi pada build alpha, ia dipromosikan menjadi atom bersama tim dalam bentuk permintaan perubahan, lalu melalui tinjauan game designer lain ia menjadi approved. Alur promosi dari pribadi ke tim ini sendiri adalah salah satu sumbu dari loop self-improving, tempat sistem atom menjadi makin pintar seiring waktu.

2.2.9 Lima Kesalahan yang Umum Terjadi

Kesalahan yang berulang pada awal operasional atom dapat dirangkum menjadi lima. Semuanya berasal dari akar yang sama: "memperlakukan atom sebagai memo sekali pakai, bukan aset".

Tidak perlu menghindari kelimanya secara sempurna sejak bulan pertama. Nomor 1 dan 4 terselesaikan bersamaan hanya dengan satu atom aturan penamaan, sementara nomor 2·3·5 akan tertata secara alami jika tinjauan triwulanan dijalankan sekali pada titik operasional 3 bulan.

2.2.10 Menuju Bab Berikutnya

Pada bab ini saya membelah satu atom menjadi lima bagian. Nama (koordinat), frontmatter (label mesin), keputusan tunggal (pemeriksaan satu kalimat), relasi (analisis dampak), ketertelusuran (30 menit yang dicegah). Dan saya konfirmasi bagaimana kelima bagian itu hidup utuh pada injeksi otomatis JIT.

Salah satu dari dua koordinat yang tertera pada nama, yaitu layer: 1, hanya disinggung sekilas oleh 2.2. 2.3 membahas Layer itu secara langsung. Jika setiap atom diberi koordinat Layer, meski bidangnya berbeda, mulai terlihat di mana letak luaran masing-masing. Dan 2.4 memformalkan menjadi ontologi keenam relasi yang pada bab ini hanya dipinjam namanya sebagai enum (affects·derives_from·conflicts_with·requires·is_a·part_of). Dari rangka arsitektur informasi yang berlanjut YAML (2.1) → Atom (2.2) → Layer (2.3) → Ontology (2.4), bab ini adalah ruas keduanya.

Poin-Poin Penting

• Satu atom adalah jumlah dari lima bagian: nama·frontmatter·keputusan tunggal·relasi·ketertelusuran
• Prinsip keputusan tunggal bukan obsesi kerapian, melainkan prasyarat dari injeksi otomatis JIT
• Dua koordinat domain·Layer yang tertera pada nama menjadi sistem alamat dari procedural generation

Coba Sendiri — Membuat Satu Atom lalu Menginjeksikannya lewat JIT

setup. Buatlah direktori atoms/ di folder kerja Anda, dan tulislah lebih dulu atom aturan penamaan (atom_naming_convention_v1). Menulis tiga baris saja — snake_case·prefix wajib·suffix versi — sudah cukup. Jika Anda memakai JIT, sediakan satu _jit_manifest.json berisi array kosong.

prompt. Pilihlah satu keputusan yang selalu Anda lupakan, lalu mintalah draf atom dengan prompt berikut.

"Buatkan keputusan berikut dalam format standar atom. Keputusan: 'Skill aktif memiliki global cooldown 0.6 detik.' Seksinya lima: Why·Rule·How to apply·Exceptions·Relations. Pada frontmatter, masukkan name (snake_case+prefix), type, layer, status: draft, owner, created. Pastikan juga di akhir apakah keputusan ini bisa diringkas dalam satu kalimat."

verify. Periksalah atom yang Anda terima dengan tiga hal. ① Apakah keputusannya bisa diringkas dalam satu kalimat (kalau tidak, pecahlah). ② Apakah Why tidak kosong. ③ Tambahkan satu baris {"name", "path", "regex", "score"} ke manifest, lalu apakah atom terinjeksikan saat kata kunci regex itu benar-benar Anda lemparkan sebagai input. Jika ketiganya lolos, berarti atom pertama Anda sudah jadi.

Versi Ringkas Solo

Jika Anda developer solo tanpa tim, tanpa Linter, dan tanpa pipeline build, Anda bisa menyusutkan seluruh bab ini menjadi satu folder di aplikasi catatan.

• Penamaan: Satukan nama file dengan satu aturan domain_decision_v1. Sebagai ganti Linter, Anda yang menjaganya dengan mata sendiri.
• Keputusan tunggal: Satu catatan satu keputusan. Jika judulnya tidak bisa ditulis dalam satu kalimat, pecahlah menjadi dua catatan.
• Why wajib: Tulislah satu baris "mengapa saya memutuskan demikian" di paling atas catatan. Satu baris ini menyelamatkan diri Anda sendiri 6 bulan kemudian.
• Pengganti relasi: Sebagai ganti enum resmi, hanya dengan menulis tiga tanda → dampak:, ↑ dasar:, ✕ konflik:, sekitar 90% dari pelacakan dampak sudah terselamatkan.
• Pengganti JIT: Sebagai ganti manifest, sebelum memulai pekerjaan, bukalah sendiri 1.2\~1.3 catatan terkait dan tempelkan ke AI. Itu JIT manual.

Intinya bukan alat, melainkan kebiasaan lima bagian itu. Sepuluh catatan pertama paling sulit, dan begitu Anda melewati rintangan itu, 100 catatan berikutnya akan dibuat sendiri oleh tangan Anda.

2.3 Desain Layer — Abstraksi Sistem Game

Ini terjadi pada masa ketika jumlah disiplin kami bertambah dari tiga menjadi delapan. Seorang Game Designer combat menetapkan jangkauan skill pada 8m. Pada minggu yang sama, seorang Level Designer mengunci lebar lorong dungeon pada 6m. Keduanya merupakan keputusan yang sepenuhnya masuk akal di dalam disiplin masing-masing. Masalahnya baru terungkap pada build tiga minggu kemudian. Skill area-of-effect (AoE) menembus dinding lorong, dan musuh mati di tempat yang bahkan tidak terlihat. Itu bukan kesalahan siapa pun. Kedua orang itu hanya tidak punya jendela untuk mengintip keputusan satu sama lain.

Bab ini bercerita tentang cara membuat jendela tersebut. Yaitu, membuat setiap disiplin tetap memiliki ruangannya sendiri, sambil bisa mengetahui apa yang terjadi di ruangan sebelah hanya melalui satu koordinat. Sistem koordinat itu kita sebut Layer.

2.3.1 Silo — Musuh yang Berulang Kali Kita Temui

Desain game terbagi-bagi menjadi disiplin yang sangat halus. Sistem, combat, naratif, konten, level, balance, UX, QA. Setiap disiplin punya alat, keluaran, dan rapatnya sendiri. Semakin besar skalanya, masing-masing semakin tenggelam dalam wilayahnya sendiri, hingga tidak tahu apa yang dikerjakan disiplin lain. Keadaan ini disebut silo.

Biaya dari silo baru terlihat setelah waktu berlalu.

• Jangkauan skill yang diputuskan oleh desain combat tidak cocok dengan lebar lorong dari desain level.
• Motivasi NPC yang dirancang naratif berbenturan dengan struktur reward quest dari desain konten.
• Siklus ekonomi yang ditetapkan desain balance tidak selaras dengan jadwal reward kehadiran dari Live Ops.

Penyebabnya bukan kurangnya kemampuan. Masing-masing memutuskan secara rasional di dalam disiplinnya sendiri, dan hanya tidak memiliki jalur untuk menyadari keputusan disiplin lain. Jika ditambal dengan rapat, rapat akan meledak jumlahnya; jika ditambal dengan grup chat, sinyal akan tenggelam dalam noise. Bukan berarti rapat dan grup chat tidak berharga, melainkan intinya adalah memperjelas batas antara bagian yang bisa ditambal dan yang tidak.

Solusinya adalah membuat agar setiap disiplin bisa saling mengetahui alur kerja masing-masing (visibilitas terintegrasi) tanpa mempersempit wilayahnya (mempertahankan diferensiasi disiplin). Dua kebutuhan yang tampak berseberangan ini bisa dicapai sekaligus jika diselaraskan di atas satu sistem koordinat yang sama. Sistem koordinat itu adalah Layer. Diibaratkan kantor, ini seperti masing-masing punya mejanya sendiri sambil melihat jam dinding dan kalender yang sama.

2.3.2 Definisi Layer — Abstraksi 5 Tingkat

Layer yang digunakan dalam buku ini adalah abstraksi 5 tingkat dari 0 sampai 4. Semakin ke atas semakin abstrak dan jarang berubah; semakin ke bawah semakin konkret dan sering berubah.

Peran yang dipikul masing-masing dari lima tingkat ini dalam pipeline procedural generation dan otomatisasi tertera pada label sisi kanan diagram di atas. Pemetaan inilah tulang punggung bab ini. Jika Anda hanya memandang Layer sebagai "folder yang rapi", Anda baru melihat setengahnya. Setiap tingkat berkorespondensi tepat dengan satu tahap pipeline generasi (jangkar → aturan → isi → nilai → gate).

Kelima tingkat ini bukan konsep eksklusif game. Tulang punggung yang sama bisa dipindahkan apa adanya ke pengembangan produk IT umum. Pembaca yang belum pernah membuat game dapat menyandingkan setiap tingkat dengan keluarannya sendiri melalui tabel terjemahan peran di bawah (kiri adalah Layer desain game, kanan adalah keluaran yang menempati posisi yang sama pada SaaS, aplikasi, sistem internal, dan sebagainya).

Cara membacanya sama persis dengan game. Semakin ke atas semakin jarang berubah (visi produk berubah sekali per kuartal), semakin ke bawah semakin sering (nilai konfigurasi berubah setiap hari). Kecelakaan silo yang kita lihat sebelumnya — adegan ketika jangkauan dan lebar lorong berbenturan — memiliki struktur yang persis sama dengan kejadian di IT umum: "definisi field backend (L3) dan aturan tampilan frontend (L1) tidak selaras lalu meletus tepat sebelum peluncuran". Hanya nama disiplinnya yang berbeda, tulang punggungnya satu.

Kelima tingkat ini tidak bersifat absolut. Tergantung skala dan domain, 4 tingkat bisa pas, atau 6 tingkat bisa diperlukan. Intinya bukan bahwa angkanya 5, melainkan tindakan mendefinisikan tingkat secara eksplisit itu sendiri.

Satu keluaran bisa membentang di dua Layer. "GDD (Game Design Document, spesifikasi rinci) sistem skill" memuat desain sistem (Layer 1) dan data konkret (Layer 3) sekaligus. Dalam kasus ini, pecah dokumennya atau letakkan Layer utama pada 1 lalu pisahkan bagian data menjadi sheet tersendiri; cara apa pun yang dipakai, nyatakan secara eksplisit di Layer mana setiap bagian berada.

2.3.3 Prinsip Meta — Diferensiasi dan Integrasi Sekaligus

Disiplin membentang secara horizontal, sedangkan Layer bertumpuk secara vertikal. Pekerjaan satu disiplin membentang di beberapa Layer. Matriks di bawah merepresentasikan pusat massa distribusi dari 11 disiplin (horizontal) × Layer 0 sampai 4 (vertikal) melalui tingkat kepekatan warna sel. Sel yang lebih pekat adalah Layer pusat massa disiplin tersebut.

Jika dibaca secara vertikal, terlihat satu disiplin membentang di Layer mana saja; jika dibaca secara horizontal, terlihat disiplin mana saja yang berkumpul di satu Layer. Baris L0 (visi) paling pekat pada naratif dan art direction — dua disiplin yang paling dekat dengan visi. Baris L3 (data) berkumpul pekat pada sistem, combat, level, balance, dan karakter — sinyal bahwa mereka saling berbenturan di sheet data.

Dengan memiliki distribusi ini secara eksplisit, disiplin lain langsung tahu posisinya ketika berkata "aku harus melihat Layer 2 milik combat". Bukan tembok silo yang runtuh, melainkan jendela yang dilubangkan di tembok itu.

Jika seluruh matriks diringkas menjadi satu kalimat, jadinya begini. Sumbu vertikal Layer dibagi untuk mengotomatiskan generasi, sumbu horizontal disiplin dibagi untuk menghidupkan keahlian. Keduanya bertemu di satu sel kisi.

2.3.4 Studi Kasus Operasional — Pengukuran Nyata Sebuah Proyek MMORPG

Proyek MMORPG A yang saya kelola sebagai Design Director telah mengoperasikan sistem Layer selama sekitar 6 bulan bersama tim desain (4 sampai 5 orang) (keseluruhan tim pengembangan berskala menengah, 10 sampai 50 orang). Mari kita lihat kasus konkretnya.

Pertama, 5 tingkat naratif. Folder desain naratif itu sendiri terbagi berdasarkan Layer.

Ketika penulis naratif mengubah satu percabangan main story di Layer 2, dampaknya merembet ke sheet dialog Layer 3, dan ke voice Layer 4 yang sudah direkam bisa muncul dampak yang tidak dapat dibalik. Karena Layer dinyatakan eksplisit, rentang dampak langsung dapat dilacak.

Alat pembuat peta relasi otomatis gen_relation_map.py juga dioperasikan bersama. Alat ini menganalisis relasi foreign key antar-sheet data untuk membuat peta relasi HTML interaktif, dan merepresentasikan Layer melalui warna node (merah=L1 sistem, kuning=L2 konten, hijau=L3 data). Dari Layer mana ke Layer mana dependensi mengalir terlihat sekilas. Jika dependensi mengalir terbalik — jika L3 menembakkan panah ke arah L1 — hampir selalu itu cacat desain.

Dokumen master procedural level generation menyatakan koordinat Layer di frontmatter.

---
title: Master Desain Level Prosedural v0.1
layer_inputs: [L1.World, L2.StoryLine]
layer_outputs: [L3.LevelData, L4.PlayCapture]
---

Dengan dua baris ini, dideklarasikan bahwa "pipeline ini menerima input Layer 1·2 dan membuat Layer 3·4", dan penghitungan rentang dampak saat perubahan menjadi otomatis. Visi L0 selalu menjadi input meski tidak dinyatakan — karena jangkar visi selalu ikut menempel di setiap generasi apa pun.

Ada pula aturan atom yang memaksakan prefix Layer pada nama dokumen. Salah satu atom yang dibagi tim adalah seperti ini.

docs_layer_numeric_prefix_naming: Nama file sheet data wajib memiliki prefix nomor Layer (L1_, L2_, L3_). Sheet tanpa prefix akan diberi peringatan pada pemeriksaan konsistensi.

Aturan semakin sederhana semakin kuat. Dengan sekadar mengurutkan berdasarkan nama saja, file sudah terkelompok per Layer, dan alat AI pun tahu Layer hanya dari nama file. Meski manusia lupa, pemeriksaan konsistensi akan menangkapnya.

2.3.5 Deteksi Referensi Terbalik — Worked Transcript (rekaman sesi nyata)

Pada subbab sebelumnya (2.3.4) telah dikatakan "jika L3 menembakkan panah ke arah L1, hampir selalu itu cacat desain". Apa yang terjadi jika deteksi ini diserahkan kepada AI alih-alih mata manusia? Saya pindahkan apa adanya satu sesi nyata yang benar-benar saya jalankan, tanpa dirapikan (hanya informasi yang mengidentifikasi perusahaan yang dianonimkan).

[Teks Lengkap Prompt]

Lihat dua frontmatter terlampir dan periksa apakah arah dependensi Layer normal.
Referensi hanya boleh mengalir dari nomor tinggi → nomor rendah agar normal. Kalau terbalik, beri peringatan.

--- Dokumen A (L1_combat_system.md) ---
title: Kerangka Sistem Combat
layer: L1
refs: [L3_skill_damage_sheet, L2_combat_flow]

--- Dokumen B (L3_skill_damage_sheet.md) ---
title: Sheet Damage Skill
layer: L3
refs: [L1_combat_system]

[Keluaran Mentah Claude — Apa Adanya Tanpa Ringkasan]

Saya telah memeriksa kedua dokumen.

Dokumen B (L3_skill_damage_sheet, L3):
  refs → [L1_combat_system]
  Arah: L3 → L1 (konkret → abstrak)
  Putusan: Normal. Sheet data yang merujuk kerangka sistem
        yang diikutinya adalah arah yang wajar.

Dokumen A (L1_combat_system, L1):
  refs → [L3_skill_damage_sheet, L2_combat_flow]
  - L1 → L2 : Normal (desain menunjuk ke alur di bawahnya)
  - L1 → L3 : ⚠ Peringatan arah terbalik
        Kerangka sistem L1 secara langsung merujuk sheet
        data L3. Ini berarti "dokumen desain bergantung pada
        nilai data tertentu", sehingga menciptakan kopling
        yang mengharuskan dokumen desain disentuh setiap kali
        data berubah.

Rekomendasi: Hapus L3_skill_damage_sheet dari refs Dokumen A.
      Jika kerangka sistem perlu mengetahui nilai konkret,
      pindahkan nilai itu menjadi aturan abstrak di L1
      (misal: "damage dasar adalah koefisien kelas × level"),
      atau lewati melalui dokumen flow L2.

Ringkasan: 1 referensi arah terbalik terdeteksi (A: L1 → L3).

[Verifikasi Manusia / Penolakan]

Putusan AI benar. Hanya saja, rekomendasi "lewati melalui dokumen flow L2" terlalu berlebihan pada kasus ini. Yang perlu diketahui L1 adalah bentuk rumus damage, bukan sel tertentu dari sheet. Karena itu saya hanya menerima rekomendasi kedua (mengangkatnya menjadi aturan abstrak) dan menolak usul melewati L2.

[Permintaan Ulang]

Tanpa usul melewati, tunjukkan saja diff perbaikan
L1_combat_system.md ke arah "hanya bentuk rumus damage yang
diangkat menjadi aturan abstrak di L1". Rapikan juga refs-nya.

Satu siklus inilah markas besar deteksi referensi terbalik. AI menangkap pelanggaran arah (otomatis), manusia memangkas batas kewajaran rekomendasi (tinjauan), lalu hanya pekerjaan yang sudah dipersempit yang dijalankan ulang (permintaan ulang). Pada Proyek A, gen_relation_map.py bekerja pada level graf, dan atom portal_layer_change_impact_check aktif pada saat perubahan terdeteksi untuk memaksakan pemeriksaan rentang dampak.

Jika perbandingan ini dilakukan manusia sendiri, membuka dua dokumen, mencocokkan refs, dan memutuskan arahnya butuh beberapa menit. Jika dokumen bertambah menjadi ratusan, ini praktis mustahil. Referensi terbalik selalu menyusup satu-dua diam-diam, dan baru meletus pada build jauh kemudian.

2.3.6 Dekomposisi Layer = Prasyarat Procedural Generation dan Otomatisasi

Tujuan permukaan integrasi Layer adalah menghapus silo dan menyatukan bahasa kolaborasi (2.3.1\~2.3.5). Tujuan esensialnya satu langkah lebih dalam. Jika dekomposisi Layer mengakar, prasyarat untuk procedural generation dan otomatisasi pun terpenuhi.

Studi kasus operasional dari dua subbab sebelumnya berada pada tahap manusia memutuskan dan AI membantu verifikasi serta injeksi. Berikutnya, kita masuk ke tahap di mana produksi massal disiplin itu sendiri dibuat AI sebagai kandidat dan manusia yang mengadopsinya. Ada tiga alasan mengapa prasyarat perpindahan ini adalah dekomposisi Layer. ① Generasi kandidat AI harus bisa menyatakan secara eksplisit "Layer mana dan apa yang akan digenerasi". ② Pemeriksaan konsistensi otomatis baru bekerja jika arah dependensi antar-Layer terstandar (deteksi referensi terbalik pada 2.3.5). ③ Penghitungan dampak perubahan otomatis baru mungkin jika ada koordinat tentang di Layer mana perubahan terjadi. Ketiganya berkumpul pada satu titik: "tanpa dekomposisi Layer, otomatisasi itu sendiri tersumbat". Di ujung tangan yang membagi koordinat, sejak awal sudah terletak procedural generation.

Karena belum perlu masuk dalam-dalam pada tahap di mana bagian per-disiplin belum dilihat, saya hanya menggariskan dua tahap penerapannya secara garis besar. Penerapan konservatif adalah manusia memutuskan, dan AI secara otomatis membantu pemeriksaan konsistensi, penghitungan dampak perubahan, dan injeksi JIT — studi kasus operasional 2.3.4·2.3.5 ada di sini. Biaya alatnya kecil dan efek akumulatifnya muncul sekitar bulan ke-6 operasional, sehingga sebagian besar tim berskala menengah (10 sampai 50 orang) dapat mencapainya. Penerapan progresif melangkah satu langkah lebih jauh: AI membuat produksi massal disiplin itu sendiri sebagai kandidat (Persona naratif, rulebook PCG, level prosedural, kandidat perubahan balance, aset art, dan sebagainya) dan manusia hanya memutuskan "kandidat mana yang diadopsi". Bentuk dan kematangan alat per-disiplin dibahas pada bagian disiplin yang bersangkutan.

Tiga elemen yang dibutuhkan secara umum lintas disiplin untuk penerapan progresif adalah ① infrastruktur pemisahan dan pelabelan Layer (frontmatter · atom · prefix nama file), ② siklus generasi dan evaluasi kandidat (N kandidat AI → evaluasi otomatis → laporan peringkat dan dasar), ③ verification gate (gerbang verifikasi) manusia (hanya hasil yang diadopsi yang naik ke Layer berikutnya). Namun, pada titik kapan pun, inti deterministik (simulasi · fisika · kendala hukum) ditangani oleh manusia dan kode deterministik, dan semua tinjauan diselesaikan pada tahap yang dapat dibalik sebelum memasuki tahap yang tidak dapat dibalik (rekaman · casting · paparan live, dan sebagainya) — batas dapat dibalik / tidak dapat dibalik ini adalah prinsip umum lintas disiplin.

Terakhir, satu catatan waktu. Penerapan konservatif sebagian mungkin dilakukan bahkan pada dekade 2010-an, tetapi penerapan progresif terhalang tiga keterbatasan: daya ungkap generasi kandidat AI, interpretasi bahasa alami pada evaluasi otomatis, dan beban tinjauan manusia. Setelah perkembangan LLM, ketiganya masuk ke ranah praktis, dan penerapan progresif turun dari visi di atas kertas ke tahap praktik. Di sinilah letak pesan meta yang menembus seluruh buku ini: perkembangan AI mengangkat kelayakan realisasi procedural generation dan otomatisasi.

2.3.7 Koordinat Disiplin — Tempat Bagian Per-Disiplin Buku Ini Tinggal

Bagian per-disiplin buku ini menyatakan secara eksplisit di pengantar Layer mana yang umumnya didistribusi tiap disiplin, dan di dalam bab pun sering menggunakan koordinat Layer. Saya rangkum lebih dahulu (ini memindahkan pusat massa matriks 2.3.3 ke dalam tabel).

Setiap disiplin menyentuh Layer lain juga, tetapi jika kita tahu pusat massanya, jalur kolaborasi terlihat. Balance (L3) dan Live (L2\~L4) bertemu di L3 sehingga harus selalu berkolaborasi erat, dan dua disiplin yang paling dekat dengan visi (L0) adalah naratif dan art direction. Hubungan kedekatan seperti ini terungkap secara alami di atas sistem koordinat.

2.3.8 Mulai Kecil, Tumbuhkan Besar

Jika Anda berniat menerapkan sistem Layer dengan sempurna sejak awal, Anda bahkan tidak akan bisa memulai. Memasukkannya secara bertahap adalah jawabannya.

flowchart LR
    S1["Tahap 1
Adopsi satu disiplin
(rekomendasi: naratif)"] --> S2["Tahap 2
Perluasan disiplin tetangga
(naratif+konten)"]
    S2 --> S3["Tahap 3
Standarisasi semua disiplin
(prefix nama file·pemeriksaan konsistensi)"]
    S3 --> S4["Tahap 4
Integrasi alat AI
(JIT·dampak perubahan·klasifikasi retrospektif)"]
    S1 -.->|"Tim kecil (~10 orang)"| E1["Cukup sampai sini"]
    S3 -.->|"Tim menengah (10~50 orang)"| E2["Direkomendasikan sampai sini"]
    S4 -.->|"Tim besar (100+)"| E3["Efektif jika sampai sini"]
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class S1,S2,S3,S4 human
    class E1,E2,E3 pass

• Tahap 1 (Satu Disiplin): Pilih hanya satu disiplin (rekomendasi: naratif) lalu bagi foldernya berdasarkan Layer. Biarkan disiplin lain, operasikan satu-dua bulan sambil mematangkan definisi Layer.
• Tahap 2 (Perluasan Disiplin Tetangga): Terapkan sekaligus pada dua disiplin yang kurva diferensiasinya berdekatan (misal: naratif+konten) untuk mengamati pola bagaimana Layer saling bertaut, lalu buat 1\~2 aturan konsistensi dengan atom.
• Tahap 3 (Standarisasi Semua Disiplin): Berikan koordinat Layer ke semua disiplin, perkenalkan aturan nama file (prefix L1_·L2_·L3_), dan otomatiskan peta relasi serta pemeriksaan konsistensi.
• Tahap 4 (Integrasi Alat AI): Manfaatkan metadata Layer pada JIT hook, hitung otomatis rentang dampak perubahan, dan tambahkan klasifikasi Layer ke sistem retrospektif.

Setiap tahap minimal satu bulan, paling lama satuan kuartal. Jika dipaksakan, manusia akan lelah. Mengatur kecepatan agar beban operasional tidak melampaui nilai adopsi adalah tugas direktur.

Skala kecil (\~10 orang) sampai tahap 1\~2, menengah (10\~50 orang) tahap 3, besar (100+) harus sampai tahap 4 baru efektif. Bukan berarti tim kecil tidak bisa menggunakannya. Hanya kedalamannya yang berbeda; nilai intinya sudah dimulai sejak tahap 1.

2.3.9 Kesimpulan — Tulang Punggung Seluruh Buku

Layer bukan sekadar teknik merapikan folder. Ia adalah prinsip meta yang mengikat desain game yang terdiferensiasi menjadi satu sistem koordinat agar AI bisa bernalar, dan lebih jauh lagi merupakan prasyarat umum procedural generation dan otomatisasi per-disiplin.

• Diferensiasi dihidupkan — keahlian dan alat setiap disiplin dibiarkan apa adanya.
• Integrasi ditambahkan — semua keluaran diselaraskan di atas sistem koordinat yang sama.
• AI memahami sistem koordinat ini untuk melakukan injeksi otomatis · pemeriksaan konsistensi · propagasi perubahan (penerapan konservatif).
• Di atas sistem koordinat yang sama, penerapan progresif per-disiplin tumbuh secara bertahap.

Seluruh bagian buku ini yang tersisa mengandaikan bab ini. Bagian per-disiplin menyatakan secara eksplisit di pengantar koordinat yang ditempati tiap disiplin pada Layer, bagian proses membahas sistem operasional yang melintasi Layer, dan bagian operasional membahas siklus self-improving dari sistem Layer itu sendiri.

Bab berikutnya (Ontologi Game dan Knowledge Graph) menambahkan relasi makna di atas Layer. Jika Layer adalah koordinat, ontologi adalah panah makna di atas koordinat itu. Hanya jika keduanya bergabung, AI baru dapat bernalar secara mandiri bahwa "dokumen ini memberi dampak pada dokumen itu".

Ada satu hal yang perlu saya pertegas. Tidak ada otomatisasi apa pun di bab ini yang menggantikan keputusan. Pada deteksi referensi terbalik, mesin hanya menggelar kandidat pelanggaran; yang memilih apa dan sampai mana harus diterima adalah tangan manusia. Layer adalah sistem koordinat yang membantu manusia mengambil keputusan yang lebih baik dengan lebih cepat, bukan perangkat untuk melempar keputusan.

Poin-Poin Penting

• Layer adalah sistem koordinat yang menambahkan visibilitas terintegrasi sambil menghidupkan diferensiasi disiplin, sekaligus tulang punggung seluruh buku.
• Masing-masing dari 5 tingkat berkorespondensi dengan satu peran procedural generation (jangkar · aturan · isi · nilai · gate).
• Seperti deteksi referensi terbalik (L3→L1), bentuk jawaban otomatisasi yang benar adalah AI menangkap dan manusia memangkas.

Atom Inti Bab Ini (Referensi)

• layer_unified_design_philosophy — atom induk bab ini
• docs_layer_numeric_prefix_naming — aturan pemaksaan prefix nama file
• dead_table_5layer_cleanup — aturan perapian sheet di luar 5 tingkat
• portal_layer_change_impact_check — pemeriksaan otomatis dampak perubahan

Pratinjau Bab Berikutnya

• Bab 7. Ontologi Game dan Knowledge Graph — Menambahkan panah makna di atas koordinat Layer
• Bab 8. Sistem Wikilink — Pola referensi yang diekstrak dari pengetahuan operasional

Coba Sendiri

setup — Pilih satu folder disiplin (rekomendasi: naratif) lalu bagi subfoldernya menjadi 5, dari Layer0_Vision/ sampai Layer4_BuildVO/. Pindahkan file yang ada ke Layer yang sesuai. File yang namanya ambigu ditempatkan berdasarkan "seberapa sering dokumen ini berubah" (semakin sering berubah, semakin ke Layer bawah).

prompt — Pilih dua frontmatter sheet data, tempel apa adanya teks lengkap prompt 2.3.5, dan minta AI memutuskan arah dependensi Layer. Cukup berikan satu baris aturan inti dengan tepat. "Referensi hanya boleh mengalir dari konkret→abstrak (nomor tinggi→nomor rendah) agar normal."

verify — Jika AI menangkap referensi arah terbalik, jangan terima rekomendasinya apa adanya, tetapi pangkas sendiri batas kewajarannya (lihat "Verifikasi Manusia/Penolakan" pada 2.3.5). Minta ulang hanya arah yang Anda adopsi dalam bentuk diff. Jika setelah diurutkan berdasarkan nama Layer terlihat terkelompok dari atas ke bawah, berarti aturan prefix sudah mengakar.

Versi Ringkas Solo

Layer tetap bekerja meski Anda bekerja sendiri. Karena tidak ada tim, tidak ada "silo antar-disiplin", tetapi ada "silo antar-waktu". Saya tiga minggu lalu dan saya hari ini saling melupakan keputusan masing-masing. Dengan sekadar membagi folder menjadi Layer 0\~4 saja — satu lembar visi, beberapa lembar kerangka sistem, alur progresi, sheet data, memo build — saya langsung menemukan di sel mana saya yang dahulu menaruh apa. Jika kepada AI saya tambahkan satu baris saja "sekarang sedang mengerjakan L2", ia tidak akan menarik materi Layer yang tak relevan. Boleh juga dikurangi menjadi 4 tingkat atau 3 tingkat. Yang menjadi inti bukan angkanya, melainkan tindakan "menyatakan tingkat secara eksplisit".

2.4 Ontologi dan Graf wikilink — Memverifikasi Panah Makna

Senin pagi, sebuah permintaan perubahan masuk. Anggota tim A dari tim combat menulis satu baris di messenger tim internal. "Saya akan ubah global cooldown dari 0.5 detik → 0.3 detik. Ada yang terdampak?" Biasanya, dari sinilah rapat 30 menit dimulai. Penanggung jawab rumus perhitungan damage mengangkat tangan, penanggung jawab aturan combo cancel ikut menimpali, dan seseorang bertanya, "Bukankah pola boss juga terpengaruh?" Tidak ada satu orang pun yang memegang seluruh gambaran di kepalanya, jadi rapat pun terisi dengan upaya mengingat-ingat.

Tapi kali ini berbeda. Satu detik setelah permintaan diajukan, sebuah bot otomatis menambahkan komentar. "Jika Anda mengubah atom ini, 4 atom akan terdampak. skill_dps_calculation, combat_combo_cancel_v3, refgame_boss_pattern_phase2, balance_curve_v3. Penanggung jawab: anggota tim B, anggota tim A, anggota tim C." Rapat tidak digelar. Empat orang masing-masing memeriksa atom-nya sendiri, dan selesai. (Bot ini akan kita buat sendiri nanti — 2.4.3.)

Komentar ini bukan sihir. Pada 2.3, kita memberikan koordinat Layer ke setiap atom, dan di atasnya, pada bab ini, kita menambahkan panah makna — keputusan mana memengaruhi keputusan mana. Koordinat hanya menyatakan sejauh "ada sesuatu di sini". Relasi seperti "ini memengaruhi itu", "itu harus ada lebih dulu agar ini berlaku", "kedua hal ini tidak boleh diaktifkan bersamaan" adalah panah yang digambar di atas koordinat. Bab ini membahas bagaimana menuliskan panah itu, dan bagaimana menangkap panah yang rusak secara otomatis.

Catatan Istilah - ontologi (ontology): sistem yang mendefinisikan secara eksplisit konsep beserta relasi di antaranya. Dalam buku ini kita memakai versi ringan yang disederhanakan menjadi 6\~12 relasi. - wikilink: tautan antar-dokumen dalam format [[atom_name]]. Notasi ini dipinjam dari Obsidian, Roam, dan sejenisnya. - backlink (rujukan balik): daftar "atom-atom yang menunjuk ke atom ini". Arah kebalikan dari rujukan maju. - orphan (node yatim): atom yang tidak dirujuk dari mana pun. Sinyal kandidat untuk dihapus. - broken link (tautan rusak): wikilink yang menunjuk ke atom yang tidak ada. Jejak salah ketik atau perubahan nama.

2.4.1 Relasi Adalah Panah — Mengapa wikilink Saja Tidak Cukup

Pada 2.1 kita melekatkan metadata dengan frontmatter YAML, dan menaburkan wikilink di badan atom. Hanya dengan itu, dokumen sudah saling terhubung seperti jaring. Masalahnya, koneksi itu tidak menuliskan apa maknanya.

Keputusan ini berlaku di atas [[skill_cooldown_rule_v2]].

Satu baris ini hanya menyatakan sejauh "menyebut skill_cooldown_rule_v2". Mengapa menyebutnya? Apakah keputusan ini membutuhkan aturan itu (requires), diturunkan dari aturan itu (derives_from), atau berkonflik dengan aturan itu (conflicts_with)? Manusia tahu begitu membaca kalimatnya, tapi mesin tidak. Bahkan jika Anda bertanya ke AI "kalau keputusan ini saya aktifkan, ada yang rusak?", tautan tanpa makna saja tidak bisa menjawabnya.

Karena itu kita melapisi wikilink dengan tipe relasi. Relasi yang benar-benar dipakai dalam game design ternyata sedikit. Enam relasi berikut menutupi lebih dari 90%.

Atom yang mengunci keenam relasi ini sebagai enum adalah ontology_relation_enum_v1. Untuk menambahkan tipe relasi baru, kita haruskan melewati tinjauan permintaan perubahan. Bahkan kalau bertambah, 10\~12 relasi sudah merupakan batas yang wajar, dan untuk awal cukup mulai dengan tiga saja: affects, derives_from, requires. Tempat menuliskan relasi adalah frontmatter YAML dari atom.

---
name: combat_combo_cancel_v3
layer: 1
affects: [skill_dps_calculation, refgame_boss_pattern_phase2]
derives_from: [vision_taste_focused_combat]
requires: [combat_input_buffer_system, skill_cooldown_rule_v2]
conflicts_with: [skill_cancel_rule_legacy_v1]
---

Manusia hanya menulis satu baris arah maju. Arah balik ("siapa yang meng-affects saya") dihitung oleh alat yang memindai keseluruhan. Jika affects ditulis di kedua sisi, beban sinkronisasi menjadi dua kali lipat, dan begitu Anda memperbaiki satu sisi lalu lupa sisi lainnya, graf mulai berbohong. Satu arah dengan tangan, arah sebaliknya dengan alat — itulah prinsip yang menembus seluruh bab ini.

2.4.2 worked transcript — Memverifikasi Rujukan Balik wikilink dan Integritas Graf Sekaligus

Mulai dari sini saya memindahkan satu sesi nyata secara utuh. Situasinya begini. Saat mengganti aturan combo cancel dari v2 ke v3, saya memutuskan untuk menghentikan skill_cancel_rule_legacy_v1. Namun sebelum menghentikannya, saya harus memastikan apakah ada atom lain yang menunjuk ke atom ini (rujukan balik), dan apakah setelah dihentikan tidak ada tautan rusak atau konflik yang tersisa (integritas graf). Kalau grep dengan tangan, pasti ada yang terlewat. Saya serahkan ke Claude.

Prompt (Lengkap)

Di folder atom yang dilampirkan (decisions/) ada atom-atom, dan di
frontmatter-nya tertulis relasi (affects/derives_from/requires/
conflicts_with/is_a/part_of). Di badan teks juga ada wikilink. Sekarang
saya hendak menghentikan skill_cancel_rule_legacy_v1; sebelum dihentikan,
periksa 3 hal: 1) rujukan balik 2) tautan rusak 3) konflik. Jangan menebak,
baca file-nya sungguhan lalu jawab. Kalau tidak ketemu, bilang tidak ketemu.
// rujukan balik = relasi YAML + wikilink badan teks, kedua sisi
// tautan rusak = tautan yang jadi stale/tidak ada akibat penghentian
// konflik = apakah lawan conflicts_with masih hidup dengan status: approved

Keluaran Claude (Mentah — Tidak Diringkas atau Dirapikan)

Saya telah membaca 47 file di folder decisions/. Berikut hasil 3 pemeriksaan terhadap skill_cancel_rule_legacy_v1.

1. Rujukan balik (atom yang menunjuk ke atom ini)

Atom yang menunjuk via relasi YAML: - combat_combo_cancel_v3 — conflicts_with: [skill_cancel_rule_legacy_v1] - skill_cancel_rule_v2 — derives_from: [skill_cancel_rule_legacy_v1]

Atom yang menunjuk via wikilink badan teks: - badan combat_combo_cancel_v3: "menyelesaikan masalah input buffer pada versi lama [[skill_cancel_rule_legacy_v1]]" - badan qa_combat_regression_checklist: "Item regresi nomor 3 disusun berdasarkan [[skill_cancel_rule_legacy_v1]]"

Jadi 4 atom merujuk ke atom ini. (YAML 2 + wikilink badan teks 2, namun karena combat_combo_cancel_v3 muncul di kedua sisi, jumlah atom sebenarnya adalah 3)

2. Tautan rusak (yang rusak saat penghentian)

Penghentian itu sendiri tidak membuat wikilink "rusak" — file-nya tetap ada, hanya status-nya menjadi deprecated. Tapi: - qa_combat_regression_checklist mendefinisikan item regresinya berdasarkan atom yang dihentikan, sehingga menjadi tidak sahih secara isi. Ini bukan tautan rusak, melainkan stale link. Perlu ditinjau. - Jika Anda sampai menghapus file-nya, maka keempat rujukan di atas semuanya menjadi tautan rusak.

⚠️ Satu hal yang ambigu: di badan balance_curve_v3 ada tautan [[skill_cancel_rule_legacy]] (tanpa _v1 di belakang). Apakah ini salah ketik yang sebenarnya hendak menunjuk _v1, atau memang dimaksudkan ke atom terpisah, tidak dapat saya pastikan hanya dari file. File dengan nama skill_cancel_rule_legacy tidak ada di folder. Jadi besar kemungkinan ini sudah merupakan tautan rusak. Perlu konfirmasi.

3. Sisa konflik (apakah lawan conflicts_with masih hidup)

Atom yang terikat conflicts_with dengan skill_cancel_rule_legacy_v1: hanya satu, combat_combo_cancel_v3. - status combat_combo_cancel_v3: approved (masih hidup)

→ Aturan baru yang berkonflik dengan target penghentian berada dalam status disetujui secara normal. Ini normal. Ini pergantian wajar di mana versi lama dihentikan dan versi baru bertahan. Bukan peringatan sisa konflik.

---

Ringkasan: Penghentian aman, tapi tangani dua hal ini lebih dulu. (a) stale link pada qa_combat_regression_checklist — perbarui item regresi nomor 3. (b) [[skill_cancel_rule_legacy]] pada balance_curve_v3 — diduga salah ketik. Bisa jadi sudah merupakan tautan rusak.

Verifikasi dan Penolakan oleh Manusia

Di sini saya tidak menerima keluaran begitu saja. (a) benar — saya sendiri yang harus memperbarui checklist regresi. Tapi saya berhenti di (b). Claude menyebut [[skill_cancel_rule_legacy]] pada balance_curve_v3 "diduga salah ketik", tapi apakah itu benar-benar tautan rusak harus saya periksa sendiri dengan membuka folder. "Tidak dapat dipastikan" dari AI adalah sinyal yang jujur, bukan kesimpulan.

Begitu saya buka foldernya dan periksa, file bernama skill_cancel_rule_legacy memang tidak ada. Namun saat saya lihat git log, ada commit yang sekadar mengganti nama skill_cancel_rule_legacy → skill_cancel_rule_legacy_v1 enam bulan lalu. Saat itu tautan di badan balance_curve_v3 tidak ikut diperbarui dan terabaikan. Jadi ini bukan salah ketik, melainkan tautan rusak yang menjadi yatim setelah perubahan nama. Tebakan Claude "diduga salah ketik" hanya benar separuh. Penyebabnya bukan salah ketik, melainkan rename yang terlewat. Andai saya tidak menangkap perbedaan ini, saya hanya akan memperbaiki checklist regresi dan tautan rusaknya akan terkubur begitu saja.

Permintaan Ulang (Mencerminkan Fakta yang Sudah Terkonfirmasi)

Sudah saya periksa. [[skill_cancel_rule_legacy]] bukan salah ketik,
melainkan tautan rusak yang lupa diperbaiki di badan teks saat rename
(_legacy → _legacy_v1) enam bulan lalu.

Kalau begitu, sekalian carikan di seluruh folder semua "wikilink yang
menunjuk ke atom yang tidak ada". Berdasarkan wikilink badan teks, semua
yang file targetnya tidak ada di folder. Tampilkan nama file dan tautan
rusak di dalamnya dalam bentuk tabel.

Saya mengumpulkan semua wikilink badan teks [[...]] dari 47 file dan membandingkannya dengan daftar file di folder. Tautan rusak yang file targetnya tidak ada berjumlah 3 buah.

File yang memuat tautan	wikilink rusak	Dugaan penyebab
balance_curve_v3	[[skill_cancel_rule_legacy]]	rename terlewat (→ _v1)
quest_reward_table_v2	[[concept_reward_currency]]	atom target belum dibuat (baru direncanakan, file belum ada)
refgame_boss_pattern_phase2	[[skill_global_cooldown]]	rename terlewat (→ skill_global_cooldown_rule)

Dari 3 kasus, 2 (rename terlewat) cukup diperbaiki dengan mengoreksi nama atom target menjadi _v1 / _rule. 1 kasus (concept_reward_currency) atom yang dituju memang tidak ada, jadi Anda harus membuatnya atau menghapus tautannya. Saya tidak memperbaikinya secara otomatis — silakan konfirmasi mana yang Anda maksudkan, baru lanjutkan.

Ketiga kasus itu benar. Andai saya grep dengan tangan, tautan rusak pada quest_reward_table_v2 hampir pasti terlewat. Tautan itu adalah rujukan masa depan yang disengaja — "menunjuk lebih dulu ke atom yang belum dibuat" — tapi selama 6 bulan tak seorang pun membuat atom itu, sehingga praktis menjadi janji yang mati.

Apa yang ditunjukkan sesi ini sederhana. Deteksi rujukan balik dan deteksi tautan rusak adalah pekerjaan yang AI unggul melakukannya — membaca seluruh folder lalu membandingkan — sedangkan penilaian penyebab dan konfirmasi maksud dilakukan manusia. AI sampai "ini rusak", manusia sampai "kenapa rusak dan bagaimana memperbaikinya".

2.4.3 Yang Terlihat Saat Digambar sebagai Graf — Memindahkan Verifikasi ke Bidang Visual

Pemeriksaan di subbab sebelumnya bisa saja dijalankan ulang dengan prompt setiap kali, tapi jika pemeriksaan yang sama dibekukan menjadi kode, semuanya terlihat sekaligus di atas graf. Pada Proyek A, alat graf yang memperluas gen_relation_map.py yang diperkenalkan di 2.3 sedang berjalan sebagai R&D. Intinya adalah membaca atom di folder, membangunnya menjadi graf berarah networkx, lalu menambahkan empat fungsi pemeriksaan.

import networkx as nx

# build_graph(folder): membaca folder atom lalu membuat DiGraph dari
#   node (=atom) dan edge relasi YAML. (lengkapnya di "Coba Sendiri")

def find_cycles(G):                      # dependensi siklik
    return list(nx.simple_cycles(G))

def find_orphans(G):                     # inbound 0 = kandidat yatim
    return [n for n in G.nodes if G.in_degree(n) == 0]

Intinya dua baris. simple_cycles menangkap dependensi siklik (A requires B requires C requires A), dan in_degree(n) == 0 menangkap node yatim — Anda tidak perlu menulis DFS sendiri. Dua fungsi sisanya pun sama-sama berupa satu baris dengan watak yang sama. find_broken_wikilinks mengumpulkan [[...]] badan teks dengan ekspresi reguler lalu menyaring yang tidak ada di daftar node, dan rujukan balik muncul dengan menyusuri graf secara terbalik (lengkapnya di "Coba Sendiri"). Visualisasi mewarnai node berdasarkan Layer dan edge berdasarkan tipe relasi, serta menggambar node yang banyak dirujuk (banyak edge inbound) lebih besar agar hub menonjol. Seperti folder yang ditata dengan label warna pada kabinet, pola muncul lebih dulu dalam jangkauan pandang.

Di bawah ini graf yang memindahkan relasi nyata dari atom-atom yang dibahas pada sesi 2.4.2. Arah panah berarti "atom asal menjalin relasi menuju atom tujuan".

graph LR
    combo[combat_combo_cancel_v3
L1·approved]
    legacy[skill_cancel_rule_legacy_v1
L1·deprecated]
    v2[skill_cancel_rule_v2
L1]
    dps[skill_dps_calculation
L3]
    vision[vision_taste_focused_combat
L0]
    buffer[combat_input_buffer_system
L1]
    boss[refgame_boss_pattern_phase2
L2]
    qa[qa_combat_regression_checklist
L4]
    broken[skill_cancel_rule_legacy
tidak ada]

    combo -->|affects| dps
    combo -->|affects| boss
    combo -->|derives_from| vision
    combo -->|requires| buffer
    combo -->|conflicts_with| legacy
    v2 -->|derives_from| legacy
    qa -.stale.-> legacy
    balance[balance_curve_v3] -.broken.-> broken

    classDef dep fill:#eee,stroke:#999,stroke-dasharray:4
    classDef miss fill:#fff,stroke:#cc2222,stroke-dasharray:4
    class legacy dep
    class broken miss

Dua edge yang digambar dengan garis putus-putus adalah masalah yang ditangkap lewat verifikasi manusia di 2.4.2. qa → legacy adalah stale link berbasis atom yang dihentikan, balance_curve_v3 → skill_cancel_rule_legacy adalah tautan rusak yang menunjuk ke node yang tidak ada. Begitu digambar sebagai graf, kedua garis putus-putus ini menonjol di antara garis-garis utuh. Andai dioperasikan hanya dengan teks, ia akan terkubur di suatu tempat di antara 47 file dan tak pernah terlihat.

Aturan yang berjalan otomatis di gerbang verifikasi (Layer 4) ada empat.

• Dependensi siklik: jika rantai requires kembali ke dirinya sendiri, beri peringatan. Dideteksi dengan simple_cycles.
• Aktivasi konflik: jika dua atom yang terikat conflicts_with keduanya status: approved, beri peringatan. (Kasus di 2.4.2 lolos karena salah satu sudah deprecated.)
• Node yatim: atom dengan inbound 0 dan tanpa induk pun menjadi kandidat penghentian untuk diperiksa per kuartal. Atom graph_orphan_detection_quarterly menyatakan siklus ini.
• Pembalikan Layer: affects L1 → L3 normal (keputusan tingkat atas memengaruhi data tingkat bawah), affects L3 → L1 mencurigakan. Prinsipnya sama dengan deteksi rujukan terbalik di 2.3. Karena atom docs_layer_numeric_prefix_naming mewajibkan prefix nomor Layer pada nama dokumen, pembalikan tersaring lebih awal hanya dengan melihat nama file.

Jika keempat aturan ini dibekukan menjadi kode, Anda tidak perlu menyusun prompt setiap kali seperti di 2.4.2. Begitu permintaan perubahan masuk, bot membangun ulang graf dan menambahkan komentar otomatis berisi daftar atom yang terdampak beserta tautan rusak, siklus, dan konflik. Komentar "4 atom terdampak" di awal bab inilah itu — bot ini adalah bot yang sudah diisyaratkan sebelumnya.

2.4.4 Mengapa Layer — Koordinat yang Dibagi demi Procedural Generation

Di sini perlu kita tegaskan mengapa 2.3 dan 2.4 menjadi satu kesatuan. Koordinat Layer dan panah relasi bukan diperkenalkan secara terpisah, melainkan dua sisi dari tujuan yang sama.

Di permukaan, Layer menyatukan bahasa kolaborasi — kalau menyebut "ini keputusan sistem L1", "itu data L3", maka bidang yang berbeda pun berbagi koordinat yang sama. Tapi tujuan esensialnya ada di tempat lain. Layer adalah koordinat yang dibagi demi procedural generation (pembangkitan prosedural).

Visi L0 adalah jangkar konteks — tidak berubah, dan diinjeksikan ke AI setiap kali. Sistem L1 adalah aturan input bagi pembangkitan — rulebook, relasi, tag tinggal di sini. Konten L2 adalah tempat badan teks hasil bangkitan menumpuk, data L3 adalah input simulasi berupa angka, ID, dan relasi, sedangkan build/QA L4 adalah gerbang verifikasi. Panah relasi bekerja di atas koordinat ini sebagai batasan (constraint) bagi pembangkitan. Saat AI membuat konten baru, panah requires menjadi prasyarat "ini harus ada lebih dulu", dan panah conflicts_with menjadi larangan "ini tidak boleh diaktifkan bersamaan".

Bidang-bidang memang terdiferensiasi (combat, quest, ekonomi masing-masing memiliki keahliannya sendiri), tetapi karena semua keluaran memiliki koordinat Layer, mereka saling menyadari satu sama lain. Diferensiasi dan integrasi berlaku bersamaan di atas satu sistem koordinat. Jika graf ini tumbuh cukup besar, AI membaca panah relasi sebagai batasan otomatis sambil membangkitkan kandidat, dan manusia cukup memeriksa apakah ada pelanggaran di gerbang verifikasi. worked transcript di 2.4.2 adalah versi mininya — AI membaca graf untuk menemukan pelanggaran batasan (tautan rusak, konflik), dan manusia memutuskan di gerbang.

2.4.5 Konsep Domain pun Node — Kamus Kosakata Kecil

Node yang menjadi titik asal dan tujuan panah relasi tidak hanya berupa atom keputusan. Atom yang mendefinisikan konsep domain seperti "skill", "quest", "reward" juga merupakan warga kelas satu dalam graf. concept_skill_definition_v1 tampak seperti ini.

# Skill (Skill)
Definition: aksi satuan yang diaktifkan karakter selama combat. Mencakup input, cooldown, sumber daya, dan efek.
Required Properties: input / cooldown / cost / effects
Subtypes: active_skill (is_a) / passive_skill (is_a) / ultimate_skill (is_a)
Bukan skill: serangan otomatis [[concept_auto_attack]] / transformasi [[concept_transformation]]

Jika Anda menulis boss_skill is_a skill, aturan konsep tingkat atas otomatis diwariskan. Pada Proyek A ada sekitar 19 atom definisi konsep semacam ini, dan semua atom keputusan merujuk padanya. Begitu kosakata disatukan menjadi satu kamus, beban penerjemahan antara rapat, dokumen, dan kode lenyap. Ibaratnya berbagi satu kamus yang sama, bukan menaruh kamus yang berbeda di tiap meja. concept_reward_currency yang tertangkap sebagai tautan rusak di worked transcript sebelumnya adalah persis "item kosong yang sudah disepakati untuk didaftarkan di kamus tapi belum dibuat".

2.4.6 Pertahankan Tetap Ringan — Jebakan Ontologi Akademis

Sampai di sini, akan muncul pertanyaan "bukankah ini ontologi formal seperti OWL/RDF?". Bukan. Dan sengaja saya buat bukan seperti itu.

Ontologi akademis (OWL, RDF, SKOS) memang ampuh, tapi tipe relasinya berjumlah puluhan hingga ratusan, memerlukan mesin inferensi khusus, dan untuk mengoperasikannya harus ada pakar ontologi yang mendampingi. Di ranah seperti mesin pencari, medis, dan hukum — di mana inferensi presisi menentukan hidup-mati — itu wajib. Tapi inferensi yang benar-benar dibutuhkan dalam game design hanyalah "cakupan dampak perubahan", "dependensi prasyarat", dan "deteksi konflik", dan semuanya selesai di level penelusuran sederhana (BFS, DFS) yang menyusuri graf satu petak demi satu petak. Subbab sebelumnya yang menangkap siklus dengan satu baris networkx adalah buktinya. Mesin inferensi formal itu berlebihan.

Kriterianya satu. Apakah Game Designer bisa mengoperasikannya dengan tangan. 6 enum YAML, pemrosesan networkx, visualisasi pyvis atau D3.js. Begitu Anda melewati garis ini, alat berhenti menjadi alat dan berubah menjadi satu beban tambahan. Keringanan bukan kompromi, melainkan niat desain.

Ada lima kesalahan yang berulang dalam menghindari jebakan ini. Semuanya tumbuh dari akar yang sama, yaitu "memperlakukan ontologi sebagai standar yang dipaksakan".

Nomor 1·2·3 polanya tertangkap dalam 1 bulan sejak penerapan, dan nomor 4·5 akan tertata secara alami jika diperiksa pada retrospektif bulan ke-3.

2.4.7 Awal yang Kecil dan Bab Berikutnya

Bulan pertama merugi. Hanya beban menulis relasi yang menumpuk dan efek yang terlihat tidak ada. Karena itu kita mulai dari kecil. Pekan pertama hanya tiga relasi affects, derives_from, requires; pada pekan ke-2 sampai 4 terapkan pada 20 atom inti sambil mengamati graf tumbuh. Jika pada bulan ke-1 Anda membuat satu tampilan graf HTML setingkat subbab sebelumnya, maka mulai bulan kedua visualisasi mulai menunjukkan nilainya, dan pada bulan ketiga verifikasi otomatis (siklus, konflik, yatim, tautan rusak) langsung memangkas waktu rapat. Bertahan melewati satu bulan yang merugi itulah titik cabang yang menentukan sukses-gagalnya penerapan.

Bab 8 berikutnya, Wikilink, menggali secara mendalam dari sisi operasional notasi [[...]] yang di bab ini ditangani sebagai panah — bagaimana memakai panel rujukan balik setiap hari, bagaimana memperbarui tautan sekaligus saat mengganti nama (cara mencegah sejak awal rename terlewat seperti di 2.4.2), bagaimana melebur tampilan graf alat seperti Obsidian ke dalam praktik kerja. YAML (bab 4) → Atom (bab 5) → Layer (bab 6) → Ontology (bab 7) → Wikilink (bab 8) adalah pentagon utuh dari arsitektur informasi.

Coba Sendiri

setup. Tentukan folder tempat atom dikumpulkan (mis. decisions/), dan siapkan untuk menulis kunci relasi pada YAML tiap atom. Untuk awal hanya tiga: affects, derives_from, requires. Satukan tautan badan teks ke format [[atom_name]].

prompt. Lemparkan yang berikut sebelum penghentian atau perubahan nama.

Baca atom-atom markdown di folder ini; saya hendak menghentikan/mengubah
[target_atom], lalu periksakan:
(1) rujukan balik: semua atom yang menunjuk ke atom ini lewat relasi YAML dan wikilink badan teks
(2) tautan rusak: tautan yang rusak atau menjadi stale saat perubahan/penghapusan
(3) sisa konflik: lawan conflicts_with yang status: approved
Jangan menebak, baca file-nya sungguhan, dan kalau tidak ketemu bilang tidak ketemu.

verify. Bukalah sendiri tempat-tempat yang ditandai AI sebagai "diduga salah ketik" atau "tidak dapat dipastikan". Penyebab tautan rusak (salah ketik, rename terlewat, atau belum dibuat) diputuskan manusia lewat git log dan kondisi nyata folder. Jangan suruh perbaikan otomatis; perbaiki sendiri setelah memastikan maksudnya.

Graf Tool Lengkap (Cuplikan 2.4.3)

Di badan teks (2.4.3) saya hanya menampilkan dua fungsi inti. Versi lengkap yang membangun seluruh folder menjadi graf dan memasang empat pemeriksaan adalah sebagai berikut.

import networkx as nx
import re, yaml, glob, os

REL_TYPES = ["affects", "derives_from", "requires",
             "conflicts_with", "is_a", "part_of"]
WIKILINK = re.compile(r"\[\[([a-zA-Z0-9_]+)\]\]")

def build_graph(folder):
    G = nx.DiGraph()
    files = {}
    for path in glob.glob(os.path.join(folder, "*.md")):
        name = os.path.splitext(os.path.basename(path))[0]
        text = open(path, encoding="utf-8").read()
        fm = yaml.safe_load(text.split("---")[1]) or {}
        files[name] = fm
        G.add_node(name, layer=fm.get("layer"), status=fm.get("status"))
    # edge relasi YAML
    for name, fm in files.items():
        for rel in REL_TYPES:
            for tgt in (fm.get(rel) or []):
                G.add_edge(name, tgt, type=rel)
    return G, files

def find_broken_wikilinks(folder, known_nodes):
    broken = []
    for path in glob.glob(os.path.join(folder, "*.md")):
        text = open(path, encoding="utf-8").read()
        for m in WIKILINK.findall(text):
            if m not in known_nodes:
                broken.append((os.path.basename(path), m))
    return broken

def find_orphans(G):
    # node dengan inbound 0 dan tanpa induk part_of/is_a
    return [n for n in G.nodes if G.in_degree(n) == 0]

def find_cycles(G):
    return list(nx.simple_cycles(G))

Versi Ringkas Solo

Anda tidak perlu alat. Satu folder atom dan satu Claude sudah cukup. Saat menulis keputusan baru, tambahkan saja dua baris requires·affects pada YAML, dan setiap kali ada penghentian atau perubahan nama, jalankan prompt di atas sekali. Visualisasi graf urusan belakangan — kebiasaan menyapu tautan rusak dan konflik sekali tepat sebelum perubahan, satu sapuan itulah yang mencegah kerugian terbesar dalam operasi solo.

Poin-Poin Penting

• Hanya dengan melapisi panah makna di atas koordinat, "apa memengaruhi apa" bisa disimpulkan secara otomatis
• Deteksi rujukan balik dan tautan rusak dilakukan AI, penilaian penyebab dan konfirmasi maksud dilakukan manusia
• Keringanan bukan kompromi melainkan niat desain — kalau tidak bisa dioperasikan dengan tangan, alat menjadi beban

Bagian 3 · System Design

3.1 Pekerjaan System Designer dan Koordinat Layer

Kamis pukul 16.50. Sheet skill yang baru saja diisi oleh penanggung jawab balancing baru saja diunggah. 312 skill. Setiap skill harus mengisi nomor efek di kolom bernama effect_id, dan nomor itu menunjuk ke sebuah baris pada sheet efek terpisah. Keduanya harus cocok agar game berjalan. Kalau tidak cocok, klien akan memanggil efek kosong atau mati diam-diam.

Dulu saya memeriksa ini dengan tangan. Satu sel di sheet skill, lompat ke sheet efek, cek nomor, lalu kembali lagi. 312 kali. Paling cepat dua jam. Pada 50 baris terakhir, saat mata mulai kabur, selalu ada satu-dua yang terlewat, dan satu-dua itulah yang meledak di build QA.

Bab ini adalah cerita tentang ke mana dua jam itu pergi, dan tentang di koordinat mana pada peta kerja System Designer pemeriksaan konsistensi tersebut ditandai. Kalau koordinat tidak ditetapkan lebih dulu, Anda akan selamanya menentukan tempat menyisipkan AI hanya dengan firasat.

3.1.1 System Designer Membuat Empat Hal

System Designer adalah orang yang berpindah paling lebar antara tingkat abstraksi dan tingkat konkret. Ia menerima kabut bernama visi, lalu menariknya turun sampai ke angka padat berupa sel terakhir pada sheet data. Sepanjang perjalanan itu, ada empat jenis keluaran yang dihasilkan.

(1) Menerjemahkan visi menjadi struktur. Ketika direktur berkata "pertempuran aksi dengan rasa hantaman yang hidup", System Designer mengubahnya menjadi kerangka berupa skill, combo, cancel, dan hitstop. "Hak penentuan diri atas pertumbuhan" menjadi sistem class, skill tree, dan equipment. Inilah momen pertama saat kabut berubah menjadi struktur.

(2) Menspesifikasikan antarmuka antar-sistem. Combat, gerakan, inventory, toko, quest, dan guild berjalan bersamaan. Apakah membuka inventory di tengah pertempuran memberikan kekebalan? Bagaimana jika ada ajakan PvP masuk di tengah proses enhancement? Jawaban atas kasus-kasus ini berkumpul dan menciptakan rasa "dibuat dengan baik". Di setiap tempat yang jawabannya hilang, pengguna merasa kesal.

(3) Bertanggung jawab atas sheet data dan skemanya. Koefisien dari 312 skill, efek dari ratusan item, perilaku dari puluhan jenis monster. Nilainya bisa diisi sendiri atau diserahkan ke bidang balancing dan content. Namun definisi kolom (skema) dari sheet itu wajib dipegang oleh System Designer. Ini adalah pekerjaan membuatkan laci berlabel. Kalau lacinya asal-asalan, tiap orang mengisinya dengan cara berbeda sehingga konsistensi pun rusak.

(4) Merancang logika perilaku. AI karakter dan monster keluar dalam bentuk seperti state machine (FSM, Finite State Machine, mesin keadaan terhingga), Behavior Tree (selanjutnya BT), tabel keputusan, dan aturan prosedural. Materi ini diserahkan ke programmer dan menjadi kode.

Intinya adalah keempat hal ini bertemu di atas meja satu orang yang sama. Karena itu, "hari ini akan dipakai untuk apa waktunya" menjadi keputusan operasional terbesar bagi seorang System Designer.

3.1.2 Keluaran Sistem Memiliki Koordinat Layer

Pada 2.3 kita menempatkan seluruh produk pembuatan game di atas sumbu koordinat dari L0 (visi) sampai L4 (build). Sekarang keempat keluaran dari 3.1.1 kita tandai langsung di atas sumbu itu. Jarang ada bidang yang keluarannya tersebar selebar System Designer di banyak Layer.

Berikut adalah peta yang menggambar dalam satu lembar: di mana keluaran itu tinggal di atas Layer, dan di setiap koordinat bertemu dengan siapa.

Peta ini menyampaikan dua hal. Pertama, System Designer bertanggung jawab atas jarak panjang dari menerima L0 hingga menyentuh sampai L4. Kedua, rentang yang dibuat langsung dengan tangan adalah L1–L3, dan di setiap tiga kotak itu mitra kolaborasinya berganti. Karena bahasa kolaborasi berubah setiap kali kotaknya berganti, kalau koordinatnya tidak disadari, rapat akan terus berputar sia-sia.

Namun ini bukan berarti satu orang menyentuh seluruh L1–L3. Kalau timnya besar, penanggung jawab L1–L2 dan penanggung jawab L3 terpisah. Kalau timnya kecil, satu orang menangani semuanya. Koordinat adalah peta pembagian peran, bukan perintah untuk menimpakan semuanya pada satu orang.

3.1.3 Begitu Koordinat Ditetapkan, Tempat Menyisipkan AI Pun Terlihat

Petanya sudah digambar, sekarang saatnya memberi warna. Koordinat mana yang efek pengenalan AI-nya besar? Bukan asal "otomatiskan semua", melainkan pilih dengan melihat sifat koordinatnya.

flowchart TD
    L1["L1 Kerangka sistem
(jumlah class, model combat)"]
    L2["L2 Antarmuka
(aturan interaksi)"]
    L3["L3 Skema + data
(sheet 312 baris)"]

    L1 -->|"Terkait langsung identitas game
manusia yang memutuskan"| H1["AI = bantu variasi/verifikasi keputusan manusia"]
    L2 -->|"Ledakan kasus
cakupan dampak besar"| H2["AI = ekstraksi otomatis cakupan dampak perubahan"]
    L3 -->|"Terstruktur, berulang
pemeriksaan konsistensi"| H3["AI = tangani penuh pembangkitan, verifikasi, konversi"]

    H1 --> R["Manusia ambil keputusan inti,
AI tangani detail, konsistensi, pengulangan"]
    H2 --> R
    H3 --> R

    style L3 fill:#fff8e1,stroke:#f9a825
    style H3 fill:#e8f5e9,stroke:#2e7d32
    style R fill:#e3f2fd,stroke:#1565c0

Intinya adalah semakin koordinat turun ke bawah, semakin besar porsi yang ditangani penuh oleh AI. "Mau berapa class" pada L1 adalah identitas game sehingga harus dipegang manusia. Sebaliknya "apakah 312 baris foreign key (kunci asing) semuanya cocok" pada L3 bersifat terstruktur dan berulang, jadi AI harus mengambilnya secara utuh. L2 berada di tengah — keputusannya tetap diambil manusia, tetapi AI menopang ekstraksi cakupan dampak berupa "kalau aturan ini diubah, sejauh mana yang ikut goyah".

Gambar ini menjelaskan mengapa semua latihan setelah 3.1.4 dimulai di sekitar L3. Karena di situlah tempat dengan efek terbesar dan risiko terkecil. Sekalipun alat skema salah berfungsi, tidak terjadi kecelakaan; relation map hanya menggambar gambar saja; dan pemeriksaan konsistensi bisa ditolak manusia.

3.1.4 Worked Transcript: Menyerahkan Pemeriksaan Konsistensi ke AI di Koordinat L3

Teorinya sampai di sini. Sekarang kita kembali ke Kamis di awal 3.1 itu. Apakah effect_id dari 312 skill cocok dengan sheet efek, mari kita coba serahkan ke AI. Tanpa rangkuman, dipindahkan persis seperti yang benar-benar dipertukarkan.

Input data mengikuti prinsip schema-first. Artinya, manusia lebih dulu mendefinisikan sheet spesifikasi, dari situ keluar Enum dan .proto (Export VBA (bahasa makro Excel)), dan terakhir data csv diisi. Karena itu prompt verifikasi pun dimulai dengan "baca dari skema dulu". Saya menegaskan bahwa sumber resmi bukanlah dokumen skema, melainkan JSON yang benar-benar di-export (json_over_schema_doc_as_source_of_truth). Sebab dokumen bisa berbohong, tetapi JSON hasil export tidak bisa berbohong.

Prompt (Lengkap)

Kamu adalah pemeriksa konsistensi data untuk proyek kami. Inputnya adalah dua export JSON. 1) skill.json — setiap objek skill memiliki field skill_id, name, effect_id. 2) effect.json — setiap objek efek memiliki effect_id, effect_type.

Periksa hal-hal berikut. (A) Apakah semua effect_id di skill.json ada di effect.json (konsistensi foreign key). (B) Efek orphan (yatim) yang ada di effect.json tetapi tidak dirujuk oleh skill mana pun. (C) Baris di dalam skill.json yang effect_id-nya kosong atau 0.

Aturan: jangan menebak. Field yang tidak ada di JSON laporkan sebagai "field tidak ada". Keluaran terdiri dari tiga bagian (A)(B)(C), untuk setiap kasus pelanggaran tulis skill_id (atau effect_id) dan alasannya dalam satu baris. Jika tidak ada pelanggaran, cukup tulis "tidak ada pelanggaran" di bagian terkait.

Keluaran Mentah Claude (Tanpa Olah, Tanpa Poles)

Saya tidak menerima dua input JSON tersebut. Pada pesan saat ini tidak ada isi file yang dilampirkan. Silakan kirim ulang dengan salah satu cara berikut. - Isi sebenarnya dari skill.json dan effect.json (tempel atau lampirkan file) - Atau path kedua file

Setelah menerima isinya, saya akan memeriksa dengan urutan (A)(B)(C). Saya tidak akan mengarang hasil tanpa file.

Berhenti di sini justru merupakan sinyal kepercayaan. Seandainya laporan yang terlihat meyakinkan tetap dikembalikan padahal input kosong, justru kerapian itulah yang menjadi sinyal bahaya. Pihak yang tidak mengarang hasil pemeriksaan dengan tangan kosong dan malah balik bertanya "berikan filenya dulu" lebih layak dipercaya. Saya benar-benar menempelkan kedua JSON dan meminta ulang (karena keterbatasan ruang, di teks utama hanya dikutip sebagian).

// skill.json (kutipan)
[
  {"skill_id": 1001, "name": "Hantaman Keras", "effect_id": 5001},
  {"skill_id": 1002, "name": "Tebasan Putar",  "effect_id": 5002},
  {"skill_id": 1003, "name": "Angkat Perisai", "effect_id": 0},
  {"skill_id": 1004, "name": "Olesan Racun",   "effect_id": 5099}
]

// effect.json (kutipan)
[
  {"effect_id": 5001, "effect_type": "DAMAGE"},
  {"effect_id": 5002, "effect_type": "DAMAGE"},
  {"effect_id": 5003, "effect_type": "BUFF"}
]

Keluaran Kedua Claude (Berdasarkan Data Sebenarnya)

(A) Konsistensi foreign key — 1 pelanggaran - skill_id: 1004 → effect_id: 5099 tidak ada di effect.json (dangling reference)

(B) Efek orphan — 1 pelanggaran - effect_id: 5003 (BUFF) → tidak dirujuk oleh skill mana pun

(C) effect_id kosong/0 — 1 pelanggaran - skill_id: 1003 → effect_id: 0. Bisa jadi ini "tanpa efek" yang disengaja, jadi perlu dicek di skema apakah 0 merupakan nilai yang valid.

Verifikasi dan Penolakan oleh Manusia

Dua dari tiga kasus itu jelas bug. 5099 adalah nomor yang ditulis lebih dulu pada skill oleh penanggung jawab balancing sebelum ia menambahkan barisnya ke sheet efek — kasus klasik di mana urutan kerja kebalik. Tertangkap.

Namun (C) saya tolak. Di proyek kami, effect_id: 0 adalah nilai kesepakatan yang valid yang berarti "slot pasif, tanpa efek". AI tidak tahu itu, jadi menaikkannya sebagai "perlu dicek", dan penilaian itu benar tetapi bukan hal yang patut dihitung sebagai pelanggaran. Maka saya beralih ke langkah berikutnya — membakukan kesepakatan ini sebagai atom, supaya mulai pemeriksaan berikutnya AI tahu bahwa 0 adalah nilai yang valid.

Permintaan Ulang (Injeksi Pengetahuan Domain)

Aturan tambahan: effect_id == 0 adalah nilai kesepakatan valid pada proyek kami yang berarti "pasif, tanpa efek". Maka pada (C), effect_id == 0 bukan pelanggaran. Laporkan sebagai pelanggaran (C) hanya jika string kosong, null, atau angka negatif.

(C) effect_id kosong/0 — tidak ada pelanggaran (effect_id: 0 diperlakukan sebagai nilai kesepakatan valid. Tidak ada kosong/null/negatif.)

Kesepakatan satu baris inilah akumulasi pengetahuan domain. Keputusan desain sistem relatif permanen, jadi sekali dibakukan, satu tahun kemudian pun pemeriksaan yang sama berjalan dengan standar yang sama. Satu lembar decision card (kartu keputusan) bertambah di kabinet.

Yang dilakukan manusia dalam transcript ini hanya tiga hal — (1) menentukan urutan input agar membaca dari skema dulu, (2) memastikan bahwa 5099 benar-benar bug, (3) mengetahui bahwa 0 adalah nilai valid lalu menolak dan mengoreksi penilaian AI. Dua jam yang dulu dihabiskan untuk melompati 312 baris satu per satu pun lenyap. Yang diotomatiskan adalah kerja kasar berupa lompatan dan pembandingan, dan tiga baris penilaian yang tersisa itulah intinya.

3.1.5 Aset yang Terakumulasi: Mengeraskan Koordinat Menjadi Kode

Pemeriksaan dari transcript di atas bisa saja diperintahkan dengan tangan setiap kali, tetapi pekerjaan yang berulang di L3 sebaiknya dikeraskan menjadi alat — itulah praktik baku desain sistem. Saya mengutip dua hal yang saya operasikan sendiri — bukan "alat Proyek A" yang abstrak, melainkan hal-hal yang benar-benar berjalan di atas meja.

gen_relation_map.py menganalisis nama kolom dan nilai pada sheet untuk mendeteksi otomatis relasi foreign key dan menghasilkan relation map HTML interaktif. Jika pada 3.1.4 panah skill.effect_id → effect.effect_id digambar manusia di dalam kepala, skrip ini menggambar panah itu menjadi gambar untuk seluruh sheet. Tempat di mana dependensi mengalir mundur (risiko data L3 merujuk balik ke kerangka L1) langsung mencolok dari gambar.

Skill schema-doc mem-parsing sheet $skema dari xlsm dan secara otomatis menghasilkan dokumen skema markdown. Skema yang sama dengan yang muncul pada pertanyaan 3.1.4 (C) "perlu dicek di skema apakah 0 merupakan nilai valid" — membuat manusia langsung membaca skema terkini tanpa harus mengaduk-aduk file lain. Karena dokumen ikut berubah saat sheet berubah, penyakit kronis berupa ketidaksesuaian antara dokumen dan data sebenarnya pun berkurang.

Kalau posisi kedua alat itu dinyatakan ulang dengan koordinat, jadinya seperti ini. schema-doc menjaga definisi kolom di L3, dan gen_relation_map.py menjaga relasi antara L2–L3. Prompt bantuan AI (verifikasi seperti pada 3.1.4) berjalan di atasnya. Ketiganya bukan berjalan sendiri-sendiri, melainkan menangani ketinggian berbeda dari sumbu koordinat yang sama.

Cara penggunaan nyata alat-alat ini diikuti dengan tangan pada 3.2, 3.3, dan 3.4. 3.1 adalah peta yang menentukan di mana menyisipkannya, dan tiga bab berikutnya adalah pekerjaan menyisipkannya.

3.1.6 Pengenalan Bertahap: Dari Koordinat yang Risikonya Kecil

Kalau ketiga alat diaktifkan sekaligus, beban operasional tiba lebih dulu daripada efeknya. Menurut pengalaman saya, urutan yang aman adalah dari koordinat yang risikonya kecil (sisi bawah).

Durasi bukan patokan mutlak. Tergantung ukuran tim dan infrastruktur yang ada, bisa makan waktu dua kali lipat atau selesai dalam setengahnya (perkiraan penulis, belum terverifikasi). Yang tidak berubah adalah urutannya. Dengan menempatkan bantuan keputusan berisiko besar di paling akhir, tempat paling sensitif baru disentuh setelah tim sudah membiasakan diri dengan kebiasaan verifikasi melalui dua alat sebelumnya.

3.1.7 Pengukuran — Secara Jujur

Saya menuliskan angka tanpa memolesnya. Berikut adalah hal yang saya amati di tim desain (4–5 orang, tim pengembangan secara keseluruhan berskala menengah 10–50 orang, operasi sekitar 6 bulan) pada proyek MMORPG yang saya operasikan sebagai direktur (selanjutnya "Proyek A"). Ini bukan pengukuran otomatis yang presisi, melainkan pengamatan penulis berdasarkan log kerja dan catatan retrospektif, dan saya sarankan dibaca hanya sebagai arah dan rasio kasarnya saja.

• Pemeriksaan konsistensi: Pembandingan foreign key skill↔efek sebanyak 312 baris paling cepat dua jam dengan tangan (Kamis di awal itu). Dengan verifikasi AI, di luar persiapan input, daftar pelanggaran keluar dalam hitungan menit. Yang berkurang adalah kerja kasar lompat dan banding, bukan penilaian.
• Onboarding Game Designer baru: Kalau ada satu lembar relation map HTML, rapat yang dulu menjelaskan struktur dependensi sistem dengan kata-kata bisa dikurangi beberapa kali. Jumlah pastinya berbeda tiap orang sehingga tidak saya pastikan (pengamatan penulis).
• Diskusi dampak perubahan: "Kalau aturan ini diubah, di mana yang goyah" yang dulu diraba lewat rapat, saya ubah menjadi cara di mana AI lebih dulu memberi draf cakupan dampak lalu manusia meninjaunya. Rapatnya bukan lenyap, melainkan rapat berubah menjadi tinjauan.

Intinya adalah waktu yang dihemat bukanlah waktu yang tidak dipakai membuat game. Waktu itu dikembalikan ke keputusan mendalam yang tidak bisa diserahkan ke AI, seperti kerangka L1. Mengurangi kerja kasar untuk dipakai pada penilaian — itulah satu baris yang dianjurkan bab ini.

Coba Sendiri: Satu Kali Pemeriksaan Konsistensi di Koordinat L3

setup. Export dua sheet (misal: skill, efek) ke csv. Kalau sempat, konversikan ke JSON terlebih dahulu (prinsip bahwa sumber resmi adalah hasil export, bukan dokumen). Pilih satu pasang foreign key di antara dua sheet (misal: skill.effect_id → effect.effect_id).

prompt. Gunakan prompt lengkap dari 3.1.4 apa adanya. Jangan lewatkan tiga baris intinya — (1) "baca dari skema/struktur dulu", (2) "jangan menebak, yang tidak ada laporkan sebagai tidak ada", (3) "kalau tidak ada pelanggaran cukup tulis tidak ada pelanggaran".

verify. Manusia memeriksa daftar pelanggaran yang dinaikkan AI baris demi baris. Bug sungguhan diperbaiki, sedangkan false positive yang muncul karena nilai kesepakatan domain (misal: 0 = tanpa efek) ditolak dan kesepakatan itu ditambahkan ke prompt (atau atom). Kalau mulai pemeriksaan berikutnya false positive yang sama lenyap, berarti satu lembar aset telah bertambah.

Versi Ringkas Solo

Kalau Anda developer solo yang tidak punya tim maupun sheet, dua tab Google Sheet sudah cukup. Satu tab "skill", tab lainnya "efek". Hubungkan keduanya dengan satu kolom effect_id. Kalau Anda mengunduh tab sebagai csv dan menempelkannya ke prompt 3.1.4, maka bukan hanya pada sheet 312 baris, pada sheet 30 baris pun dangling reference dan efek orphan tetap tertangkap dengan cara yang sama. Hanya skalanya yang berbeda, koordinatnya sama. Mulailah dari L3, dan begitu sudah terbiasa, naiklah satu kotak demi satu kotak ke relation map dan cakupan dampak.

Poin-Poin Penting

• Keempat keluaran sistem memiliki koordinat dari kerangka L1 sampai sheet L3, dan koordinat itu sendiri adalah mitra kolaborasi
• Semakin koordinat turun ke bawah (L3), semakin besar porsi yang ditangani penuh AI dan semakin kecil risikonya
• Yang diotomatiskan adalah kerja kasar lompat dan banding, sedangkan penilaian berupa konfirmasi bug dan penolakan false positive adalah bagian manusia

3.2 Skema Dulu — $skema Datang Sebelum Data

Senin pagi, saya membangun 120 baris sheet skill yang baru saja diisi oleh seorang Game Designer baru menjadi csv, dan log klien menampilkan 28 garis merah. class_id mereferensikan nomor 47, padahal di sheet kelas tidak ada nomor 47. Pada kolom element, seseorang menulis Fire, sementara yang lain menulis fire, dan satu baris bahkan ditulis 화염 dalam aksara Korea. Setengah sore lenyap hanya untuk meraba 28 garis merah itu satu per satu dengan tangan.

Penyebab insiden ini bukanlah datanya yang salah. Penyebabnya adalah aturan yang harus dipatuhi data itu tidak dituliskan sebelum datanya dibuat. Jika aturan hanya ada di dalam kepala, begitu orangnya berganti, aturannya pun ikut berganti. Bab ini membahas alur kerja yang membuat aturan—skema—lebih dulu daripada data. Lalu membuat aturan itu ditegakkan sebagai dokumen oleh alat, bukan oleh tangan manusia.

Catatan Istilah - Skema (schema): definisi kolom pada sheet data. Nama, tipe, rentang, kunci asing, dan deskripsi. - $skema: sheet khusus untuk definisi kolom yang diletakkan di dalam sheet data Excel (xlsm). Sheet ini hanya memuat aturan kolom, bukan baris data. - FK (kunci asing): kolom yang mereferensikan PK (kunci primer) sheet lain. Misalnya class_id menunjuk ke baris pada sheet Class. - proto: definisi Protocol Buffers (.proto). Kontrak struktur data dan Enum yang dibagikan antara klien dan server. - Single source of truth (sumber kebenaran tunggal): prinsip operasional yang mengelola informasi yang sama hanya di satu tempat sehingga semua orang melihat tempat itu.

3.2.1 Urutan Input Itulah Skemanya

Jika "skema dulu" hanya dipahami sebagai "mendefinisikan kolom lebih awal", itu baru setengah ditangkap. Intinya ada pada urutan apa yang diinput lebih dulu. Urutan gerakan tangan yang mengisi data menentukan apakah integritas terjaga atau runtuh.

Urutan input yang direkomendasikan buku ini adalah pipeline beruas empat.

flowchart LR
    A["Sheet $skema
(definisi aturan kolom)"] --> B["Enum / *.proto
(membuat kontrak kode via VBA Export)"]
    B --> C["Data csv
(mengisi baris dalam batas aturan)"]
    A -.->|schema-doc| D["Dokumen skema
(.md dibuat otomatis)"]
    C -.->|gen_relation_map.py| E["Diagram relasi FK
(HTML dibuat otomatis)"]
    D -.-> F(("AI / manusia
membaca definisi yang sama"))
    E -.-> F
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A,B,C,D,E data

Garis penuh yang mengalir dari kiri ke kanan adalah urutan input yang dipaksakan. Definisikan $skema lebih dulu, dari sana tarik Enum dan proto melalui VBA (bahasa makro Excel) Export, dan isi data csv hanya di dalam batas kontrak itu. Garis putus-putus adalah keluaran yang otomatis diturunkan dari input tersebut—dokumen skema (schema-doc) dan diagram relasi FK (gen_relation_map.py)—dan manusia maupun AI melihat definisi yang sama melalui turunan ini.

Selama urutan ini dipaksakan, sebagian besar dari 28 garis merah yang kita lihat di pembuka bab ini akan tertutup sebelum mengisi data. Jika fakta bahwa element adalah salah satu dari empat nilai fire/ice/lightning/none sudah dipatok sebagai Enum proto, maka baik Fire maupun 화염 akan tersaring di tahap input. Jika fakta bahwa class_id mereferensikan PK sheet Class sudah dituliskan di $skema, maka nomor 47 yang hilang akan tertangkap lebih dulu di pemeriksaan, bukan di build.

Jika urutan dibalik—mengisi data lebih dulu lalu merapikan skema kemudian—maka skema menjadi pembersihan setelah fakta. Jika kita mengutak-atik aturan kolom pada posisi yang sudah menumpuk 1000 baris, aturan justru mengikuti data, dan pada saat itu sumber kebenaran terbalik.

3.2.2 Worked Transcript (rekaman sesi nyata) — dari $skema sampai csv Sekaligus

Alih-alih menjelaskan dengan kata-kata, mari kita lewatkan satu sheet sungguhan dari awal sampai akhir. Misalkan kita membuat sheet skill baru. Berikut adalah rekaman lengkap yang dijalankan dengan bantuan AI. Saya tidak meringkasnya, dan membiarkan apa adanya bagian yang melenceng serta bagian yang ditolak manusia.

Langkah 1 — Manusia menulis $skema lebih dulu dengan tangan

Belum memanggil alat maupun AI. Manusia mendefinisikan sendiri aturan kolom secara langsung. Khusus langkah ini tidak didelegasikan.

# $skema sheet Skill (ditulis manusia)
kolom           tipe       rentang/batasan           FK                  deskripsi
skill_id       int        1000~9999            (PK)                ID unik skill
name           string     1~30 karakter         -                  nama tampilan
class_id       int(FK)    -                    Class.class_id      kelas yang dapat memakai
cooldown       float      0.0~120.0            -                   waktu jeda pakai ulang (detik)
damage_coef    float      0.0~10.0             -                   koefisien pengali serangan
element        enum       fire/ice/lightning/none  -              atribut
is_passive     bool       true/false           -                  apakah pasif

Langkah 2 — Menyuruh AI membuat draf Enum proto (prompt lengkap)

Pekerjaan memindahkan enum element dan struktur FK dari $skema ke kontrak proto. Karena ini konversi format, ini pekerjaan yang bisa diserahkan ke AI.

Prompt (lengkap): Berikut adalah spesifikasi kolom sheet data game. Konversikan spesifikasi ini menjadi pesan dan Enum Protocol Buffers (proto3). Aturan: (1) kolom bertipe enum didefinisikan sebagai enum terpisah dan nilai pertama harus dimulai dengan _UNSPECIFIED = 0. (2) kolom FK menyertakan target referensi sebagai komentar. (3) batasan rentang tidak dapat dinyatakan dengan proto, jadi cukup sertakan sebagai komentar. Jangan tambahkan kolom yang tidak ada dalam spesifikasi.

skill_id int PK / name string / class_id int FK→Class.class_id /
cooldown float 0~120 / damage_coef float 0~10 /
element enum{fire,ice,lightning,none} / is_passive bool

Langkah 3 — Keluaran mentah Claude (apa adanya, tanpa disentuh)

syntax = "proto3";

// Kontrak data sheet Skill
// Catatan: batasan rentang (cooldown 0~120, damage_coef 0~10)
//          tidak dapat dipaksakan dengan proto. Periksa di Linter.

enum SkillElement {
  SKILL_ELEMENT_UNSPECIFIED = 0;
  SKILL_ELEMENT_FIRE = 1;
  SKILL_ELEMENT_ICE = 2;
  SKILL_ELEMENT_LIGHTNING = 3;
  SKILL_ELEMENT_NONE = 4;   // ← penanda tinjauan manusia
}

message Skill {
  int32 skill_id = 1;       // PK
  string name = 2;
  int32 class_id = 3;       // FK → Class.class_id
  float cooldown = 4;
  float damage_coef = 5;
  SkillElement element = 6;
  bool is_passive = 7;
}

Langkah 4 — Verifikasi dan penolakan oleh manusia

Di sini manusia menolak satu tempat. AI menempatkan none sebagai SKILL_ELEMENT_NONE = 4 di akhir enum, padahal di $skema none adalah keadaan default yang berarti "tanpa atribut". Persoalannya ada pada nilai ke-0 proto. Dalam proto3, nilai ke-0 enum adalah "posisi yang otomatis terisi ketika nilai tidak diisi", sehingga keputusan terbelah antara mengosongkan nilai ke-0 sebagai _UNSPECIFIED (nilai tidak diinput) atau mengisinya dengan nilai bermakna seperti none (tanpa atribut secara sengaja). Jika keduanya digabung dalam satu posisi, baris yang mengosongkan kolom (kekeliruan) dan baris yang sengaja memilih tanpa atribut (kesengajaan) sama-sama masuk sebagai 0 dan selamanya tidak dapat dibedakan. AI memang menaruh _UNSPECIFIED = 0 dan none secara terpisah, tetapi mengirim none ke posisi akhir nomor 4, sehingga keadaan default yang paling sering muncul justru menjauh dari jangkauan pencarian dan debugging.

Keputusan yang diambil manusia: - _UNSPECIFIED = 0 dipertahankan (untuk deteksi kehilangan). - none dibiarkan apa adanya, tetapi pada aturan penulisan csv ditambahkan "tanpa atribut harus secara eksplisit none, kolom kosong dilarang". Kosong=0=UNSPECIFIED dianggap kesalahan input. - Keputusan ini ditambahkan satu baris ke deskripsi baris element pada $skema: "tanpa atribut pun harus dieksplisitkan (none). Kolom kosong adalah kesalahan."

Keluaran AI tidak dipakai apa adanya. Formatnya diterima, tetapi batas maknanya digariskan oleh manusia.

Langkah 5 — Menarik Enum/proto dari sheet dengan tombol VBA Export

Definisi proto yang sudah terverifikasi dikeluarkan secara konsisten oleh makro Export Excel (tombol pada sheet $skema). Manusia tidak mengetik ulang di IDE. Karena sheet adalah sumber kebenaran, proto keluar dari sheet. Urutan ini adalah kelanjutan dari prinsip "keluaran adalah naskah resmi" (json_over_schema_doc_as_source_of_truth) yang akan dibahas di 3.3—bukan dokumen yang menjelaskan kode, melainkan sheet yang melahirkan kode.

Langkah 6 — Baru kemudian mengisi data csv (dengan bantuan AI, termasuk permintaan ulang)

Prompt (lengkap): Buatkan 5 baris csv yang memenuhi proto Skill dan $skema di atas. Batasan: class_id adalah salah satu dari [1,2,3] (PK yang saat ini ada di sheet Class), damage_coef adalah 0.0 jika pasif (is_passive=true), element adalah string fire/ice/lightning/none apa adanya, dan kolom kosong dilarang.

Pada keluaran pertama Claude, satu baris melenceng.

skill_id,name,class_id,cooldown,damage_coef,element,is_passive
1001,Tebasan Api,1,3.5,2.4,fire,false
1002,Tangan Beku,2,8.0,3.1,ice,false
1003,Pemulihan HP,1,0.0,1.2,none,true     ← ditolak: pasif tapi damage_coef≠0
1004,Tombak Petir,3,5.0,2.8,lightning,false
1005,Sikap Bertahan,2,0.0,0.0,none,true

Baris 1003 melanggar aturan (jika is_passive=true maka damage_coef=0.0 seharusnya). Manusia menolak dan meminta ulang.

Permintaan ulang (lengkap): Baris 1003 melanggar aturan. is_passive=true tetapi damage_coef=1.2. Pasif seharusnya 0.0. Perbaiki hanya 1003 lalu berikan lagi.

Keluaran ulang Claude: 1003,Pemulihan HP,1,0.0,0.0,none,true

AI tidak menjawab semuanya dengan benar pada percobaan pertama bukanlah cacat, melainkan sekadar hal yang biasa terjadi. Yang penting adalah berkat skema sudah terpasang, satu baris yang melenceng itu bisa ditunjuk dengan mata dan dikembalikan dengan satu baris. Seandainya tidak ada skema, baris 1003 baru akan ditemukan sebagai bug pasif yang menghasilkan damage di dalam game setelah build.

Pelajaran dari keseluruhan transcript ini sederhana. Jika urutan input dipatok menjadi $skema → proto → csv, AI mengisi format dengan cepat dan manusia hanya meninjau makna serta pelanggaran. Jika urutan runtuh, manusia memikul semuanya mulai dari format sampai makna.

3.2.3 schema-doc — Agar Manusia Tidak Menyalin Ulang Skema

Meletakkan $skema di dalam Excel memang nyaman bagi Game Designer, tetapi merupakan posisi yang tertutup bagi AI, git, dan alat eksternal. Karena itu saya mengoperasikan alat yang otomatis mengonversi $skema menjadi Markdown. Slash skill schema-doc mengerjakan hal ini.

Cara kerjanya empat langkah.

1. Mem-parsing sheet $skema dari Excel (xlsm) (python-calamine, akselerasi Rust)
2. Mengekstrak 5 elemen definisi kolom
3. Mengonversi menjadi tabel Markdown
4. Membuat <nama_sheet>_schema.md di folder yang sama

Intinya adalah manusia tidak menulis skema dua kali. Setelah didefinisikan sekali di Excel, Markdown-nya dibuat oleh alat. Keduanya tidak mungkin melenceng. Jebakan "jika dokumen skema dijadikan naskah resmi, ia akan melenceng dari keluaran sebenarnya" yang akan dibahas di 3.3, di sini dihindari dengan membaliknya menjadi "Excel adalah naskah resmi, dokumen adalah turunan".

Hasil yang dibuat schema-doc (berdasarkan sheet Skill dari transcript sebelumnya):

# Skema sheet Skill  (dibuat otomatis — dilarang mengubah langsung)

| kolom | tipe | rentang/batasan | FK | deskripsi |
|---|---|---|---|---|
| skill_id | int | 1000~9999 | (PK) | ID unik skill |
| name | string | 1~30 karakter | - | nama tampilan |
| class_id | int(FK) | - | Class.class_id | kelas yang dapat memakai |
| cooldown | float | 0.0~120.0 | - | waktu jeda pakai ulang (detik) |
| damage_coef | float | 0.0~10.0 | - | koefisien pengali serangan |
| element | enum | fire/ice/lightning/none | - | atribut. tanpa atribut pun dieksplisitkan (none), kolom kosong adalah kesalahan |
| is_passive | bool | true/false | - | apakah pasif. jika true maka damage_coef=0 |

_source: Skill.xlsm / generated by schema-doc_

Perhatikan bahwa batas yang digariskan manusia pada langkah 4 dan 6 di 3.2.2 ikut masuk apa adanya ke kolom deskripsi element dan is_passive. Manusia menulis satu baris di $skema, dan dokumen, proto, serta verifikasi semuanya jadi berbagi aturan yang sama. Inilah wujud nyata single source of truth saat bekerja.

Skema yang sudah turun menjadi Markdown langsung dipakai di tiga tempat.

• Pembuatan data AI: sebelum membuat baris, AI membaca tabel ini dan hanya membuat baris yang mematuhi 7 kolom yang didefinisikan, tiap batasan, dan FK.
• Onboarding Game Designer baru: satu lembar tabel ini lebih cepat daripada tiga kali rapat.
• Linter: otomatis membandingkan apakah tiap baris csv melanggar tabel ini.

3.2.4 gen_relation_map.py — Apakah FK Masih Hidup, Lewat Grafik

Jika skema adalah aturan di dalam sheet, maka FK adalah aturan di antara sheet-sheet. Definisi bahwa class_id mereferensikan sheet Class memang tertulis di $skema, tetapi apakah referensi itu benar-benar hidup pada saat ini memerlukan pemeriksaan terpisah.

gen_relation_map.py otomatis mendeteksi relasi FK antar sheet data dan menggambarkannya sebagai diagram relasi HTML interaktif. Ketika panah-panah seperti class_id→Class milik Skill dan set_id→ItemSet milik Item berkumpul dalam satu layar, "FK yang target referensinya telah hilang" mencolok sebagai panah yang terputus. Insiden seperti nomor 47 yang hilang di pembuka bab ini terlihat sebagai garis terputus pada diagram relasi saat sedang mengisi data, bukan sebagai garis merah di log build.

Penggunaan worked transcript dan visualisasi alat ini dibahas serius di 3.3. Yang perlu diingat di bab ini hanya satu. Jika $skema tidak mengeksplisitkan FK, maka baik diagram relasi maupun pemeriksaan integritas tidak punya grafik untuk digambar. Mengeksplisitkan FK bukanlah pilihan, melainkan prasyarat dari skema dulu.

3.2.5 Alur Kerja 5 Langkah Skema Dulu

Jika transcript di 3.2.2 digeneralisasi, jadilah lima langkah. Bila kita pisahkan pelaku dan keluaran tiap langkah, akan jelas apa yang dipegang manusia dan apa yang diserahkan ke alat.

Tidak perlu melengkapi kelima langkah pada bulan pertama. Menjalankan langkah 1 dan 2 saja (desain skema + dokumentasi otomatis) sudah menangkap separuh nilainya. Langkah 3\~5 ditambahkan secara bertahap setelah operasionalnya terbiasa. Jika memaksakan 5 langkah sejak awal, beban penulis akan menghentikan operasional sebelum sempat mapan.

3.2.6 Apa yang Diukur di Proyek A

Pada suatu proyek MMORPG yang saya jalankan sebagai direktur (selanjutnya "Proyek A"), saya menjalankan alur kerja ini selama sekitar 6 bulan. Di antara angka-angka berikut, konsistensi kolom sheet data dan waktu draf sheet baru adalah hasil pengukuran nyata yang dihimpun dari log alat dan catatan kerja, sedangkan frekuensi FK rusak adalah perkiraan penulis (belum terverifikasi) yang dihitung mundur dari isu kegagalan build.

Biaya penerapan adalah pengembangan awal alat sekitar 3 hari + pemantapan operasional sekitar 1 bulan. Kesimpulan operasional adalah bahwa biaya penerapan kecil dibandingkan efek kumulatif selama 6 bulan. Namun rasio di atas adalah kasus tunggal dari satu tim dan satu proyek, sehingga tidak ada jaminan bahwa ia dapat dipindahkan apa adanya ke tim lain.

3.2.7 Sinergi AI dengan Skema, dan Batasnya

Jika skema sudah terpasang, keandalan pembuatan data oleh AI melonjak drastis. Alasannya, skema menutup lebih dulu rentang input ambigu yang menjadi celah bagi halusinasi. Untuk permintaan "buatkan 20 skill", jika tidak ada skema, AI akan menemukan kolom yang tampak masuk akal dan mengisi nilai yang tidak kompatibel dengan sheet Anda sendiri. Jika ada skema, permintaan yang sama kembali sebagai baris yang mematuhi 7 kolom yang didefinisikan, tiap batasan, dan FK. Seperti kasus baris 1003 di 3.2.2, sekalipun muncul pelanggaran, cukup menunjuk satu baris dan meminta ulang, selesai.

Sebagai gantinya batasnya jelas. Nilai balance tidak disuruh dikerjakan AI. Jika AI menentukan damage_coef "sekenanya", ia akan berbenturan dengan maksud game. Bagian AI hanya sampai menggelar kandidat yang formatnya cocok dengan cepat, dan "apakah koefisien skill ini benar 2.4" dijawab oleh manusia. Itu bukan berarti AI tidak berguna untuk balance—kehalusan kurva, pencilan, dan statistik rentang ditangkap AI dengan cepat. Mengukur angka diserahkan ke alat, dan apakah angka itu benar disaring oleh manusia.

3.2.8 Kesalahan Umum dan Cara Menghindarinya

Coba Sendiri

setup 1. Pilihlah satu sheet paling inti dari bidang Anda (salah satu dari skill, item, atau monster). 2. Tambahkan sheet bernama $skema ke file Excel itu, dan tuliskan 5 elemen (nama, tipe, rentang, FK, deskripsi) satu baris untuk tiap kolom. Langkah ini dikerjakan langsung oleh manusia.

prompt (AI hanya dipakai untuk draf proto/csv)

Konversikan $skema di bawah ini menjadi pesan proto3 dan Enum. Nilai pertama enum _UNSPECIFIED = 0. FK menyertakan target referensi sebagai komentar. Batasan rentang cukup sebagai komentar. Dilarang menambah kolom yang tidak ada dalam spesifikasi. (tempelkan $skema Anda di sini)

Lalu lanjutkan:

5 baris csv yang memenuhi proto dan $skema di atas. Jangan buat baris yang melanggar batasan. Jika is_passive=true maka damage_coef=0.

verify 1. Bandingkan 5 baris yang diberikan AI satu per satu dengan skema. Jika ada baris yang melanggar, minta ulang dengan "Baris N melanggar, perbaiki hanya baris itu" (penolakan dan permintaan ulang adalah proses normal). 2. Tarik $skema menjadi .md dengan schema-doc (atau skrip Python sederhana setara), lalu periksa apakah definisi Excel dan dokumen cocok. 3. Jika ada FK, bandingkan sekali apakah PK target referensi benar-benar ada.

Versi Ringkas Solo

Jika Anda memulai sendirian tanpa alat maupun tim, satu file Excel dan satu text editor sudah cukup.

1. Buat $skema pada tab pertama sheet dan tuliskan aturan kolom sebagai 5 elemen (15 menit).
2. Salin spesifikasi itu apa adanya dan minta AI "Enum proto + 5 baris csv" (10 menit).
3. Bandingkan csv yang diterima dengan skema secara visual, dan perbaiki satu baris yang melanggar lewat permintaan ulang (10 menit).
4. Simpan teks $skema ke Notepad sebagai skill_schema.md. Inilah single source of truth pertama Anda.

Saat beralih ke sheet berikutnya, ulangi 4 langkah yang sama. Begitu 5\~10 sheet inti dalam satu kuartal sudah tersusun dengan urutan yang sama, barulah muncul nilai untuk memasang otomatisasi seperti schema-doc.

Poin-Poin Penting

• Jika urutan input dipaksakan menjadi $skema→Enum/proto→csv, pelanggaran tertutup sebelum mengisi data
• Excel adalah naskah resmi dan dokumen adalah turunan, schema-doc mengikat keduanya ke satu sumber sehingga manusia dan AI melihat definisi yang sama
• Nilai balance ditentukan oleh manusia, sedangkan AI hanya menangani kandidat format dan pengukuran pencilan

Pratinjau Bab Berikutnya

• 3.3. Visualisasi diagram relasi — melihat dependensi FK dengan mata lewat gen_relation_map.py

3.3 Visualisasi Peta Relasi — Melihat Dependensi dengan Mata

Seorang Game Designer baru datang ke meja saya pada minggu pertamanya bekerja. "Saya mau menyentuh tabel hadiah quest, tapi kalau ini saya ubah, bagian mana yang akan rusak?" Saya hendak menunjuk monitor untuk menjawab, lalu berhenti. Di kepala saya sudah ada gambarnya. RewardTable menggigit ItemTable, ItemTable menggigit ItemEffectTable, dan di atasnya QuestTable mereferensikan hadiah… tetapi begitu gambar itu saya ubah jadi kata-kata, bentuknya runtuh di kepala si pendengar. Saya menggambar tujuh kotak di papan tulis. Anak-anak panahnya mulai kusut. Tiga puluh menit kemudian, ia mengangguk lalu kembali ke mejanya, dan keesokan harinya ia datang lagi membawa pertanyaan yang persis sama.

Adegan inilah yang membuat saya menulis bab ini. Di kepala seorang System Designer ada graf dependensi. Masalahnya, graf itu hanya ada di kepalanya. Begitu orangnya berganti, gambarnya pun lenyap. Saya butuh alat untuk mengeksternalisasi gambar itu, dan itulah yang saya buat: gen_relation_map.py.

Saat sheet data hanya 5–10 buah, kepala kita masih cukup. Begitu melewati 30, memori kerja manusia tidak sanggup lagi. Folder sheet sebuah proyek biasanya melampaui batas itu sejak dini. Tabel yang menuliskan dependensi dari mana ke mana dalam bentuk teks, sekalipun dibaca, tidak membentuk gambar di kepala. Bab ini mengikuti dari awal sampai akhir proses nyata (worked process) untuk membangkitkan relasi kunci asing (FK) secara otomatis menjadi peta relasi HTML interaktif.

3.3.1 Empat Masalah yang Dipecahkan Peta Relasi

Sebelum membuat alatnya, mari kita tunjuk dahulu apa sebenarnya yang tersumbat saat peta relasi tidak ada. Ada empat adegan yang berulang.

Onboarding Game Designer baru. Seorang Game Designer baru menjadwalkan rapat untuk mempelajari struktur sistem. Itulah adegan di atas. Dependensi yang disampaikan secara lisan tidak bertahan beberapa hari pun di kepala si pendengar. Kalau kita mengeklik satu lembar peta relasi bersama-sama, lebih dari separuhnya sudah terbentuk pada rapat pertama. Perbedaan mendasarnya dengan gambar tangan di papan tulis adalah gambarnya tidak terhapus dan tetap ada di tempatnya.

Diskusi cakupan dampak perubahan. Sebuah permintaan perubahan sistem masuk. "Ini berdampak ke mana saja?" Rapat dijadwalkan, sudah didiskusikan lama pun masih saja ada satu-dua area yang terlewat. Kalau ada peta relasi, dengan mengeklik node yang menjadi target perubahan lalu menelusuri edge masuk (inbound), cakupan dampaknya langsung terlihat. Diskusinya tinggal menetapkan "apakah dampak ini benar-benar tepat" dan prioritasnya saja.

Deteksi dependensi terbalik. Sheet data L3 mereferensikan dokumen sistem L1 adalah hal yang normal. Arah sebaliknya (Layer di atas mereferensikan langsung sheet data di bawahnya) hampir selalu merupakan cacat desain. Pada daftar FK yang dijejer dalam bentuk teks, manusia tidak bisa menangkap arah terbalik ini. Pada gambar, ini langsung tersingkap lewat satu anak panah yang warna Layer-nya bertolak belakang.

Penemuan sheet yang terisolasi. Sesekali ditemukan sheet yang tidak direferensikan dari mana pun. Bisa jadi sisa-sisa desain lama, atau kasus di mana sudah diputuskan untuk dibuang tetapi filenya masih tertinggal. Sama seperti pemandangan kotak tanpa label yang menggelinding di sudut kantor. Kita baru menemukan pulau terpencil itu kalau ada gambarnya.

Kesamaan dari keempat masalah ini adalah semuanya "baru terpecahkan kalau strukturnya dilihat dengan mata". Dengan teks dan tabel, semuanya tersumbat.

3.3.2 Worked Transcript: Dari Sheet Data sampai Peta Relasi

Sekarang kita ikuti prosesnya secara nyata. Inputnya satu folder berisi sheet data, outputnya satu lembar HTML interaktif yang dibuka di browser. Di antara keduanya, saya catat tanpa ada yang terlewat: apa yang dikerjakan AI dan di titik mana manusia memverifikasi/menolak.

3.3.2.1 Alur Keseluruhan

flowchart TD
    A[Folder sheet data
banyak xlsm/xlsx] --> B[1. Pindai: kumpulkan sheet & header kolom]
    B --> C[2. Ekstrak kandidat FK
*_id / *Id / tanda FK di spesifikasi]
    C --> D[3. Cocokkan target referensi
nama kolom → sheet target]
    D --> E{Verifikasi manusia}
    E -->|Tolak false positive| C
    E -->|Lolos| F[4. Bangun graf
node=sheet, edge=FK]
    F --> G[5. Beri meta Layer
rujuk keluaran schema-doc]
    G --> H[6. Render HTML dengan pyvis]
    H --> I[relation_map.html
interaktif di browser]
    I --> J{Diagnosis manusia}
    J -->|Temukan terbalik/terisolasi/siklus| K[Minta perbaikan desain]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A,I data
    class B,C,D,F,G,H code
    class E,J,K human

Intinya ada pada loop verifikasi manusia di antara langkah 3 dan 5. Ekstraksi kandidat FK dikerjakan mesin sebagai draf awal, lalu manusia menyaring false positive dari situ. Kalau loop ini dilewati, peta relasi memang tampak meyakinkan tetapi menjadi gambar yang salah.

3.3.2.2 Dari Mana FK Berasal — Urutan Input

Akurasi alat ini ditentukan oleh dari mana inputnya ditarik. Prinsip schema-first yang ditetapkan di 3.2 berlaku langsung di sini. Urutan sumber utama (canonical) untuk informasi FK adalah sebagai berikut.

1. Sheet $스키마 — sumber utama pertama dari setiap sheet data. Untuk tiap kolom, tipe, Enum, dan target FK ditulis secara eksplisit. Kalau FK sudah tertulis di sini, itulah prioritas pertama.
2. Definisi *.proto / Enum — skema yang dikeluarkan lewat Export VBA (bahasa makro Excel). Memperkuat informasi tipe ketika spesifikasi kosong.
3. Keluaran csv aktual — data nyata yang diekspor oleh sheet. Relasi yang tidak ada di spesifikasi pun tersingkap dari data sebagai sebuah pola (misalnya: kalau semua nilai pada kolom npc_id berada dalam rentang key NPCTable, itu praktis adalah FK).

Di sini ada satu prinsip yang saya tegaskan. Yang menjadi sumber utama adalah keluaran JSON/csv aktual, bukan dokumen skema. Sekalipun di spesifikasi tertulis bahwa reward_id adalah FK, kalau pada data nyata kolom itu kosong atau menunjuk nilai yang tidak relevan, berarti spesifikasinya yang salah. Ketika keduanya bertolak belakang, alat ini memercayai sisi data, dan ketidaksesuaian itu sendiri ditinggalkan dalam laporan. Inilah alasan mengapa schema-doc tidak dijadikan sumber utama.

3.3.2.3 Tahap 1 — Pindai Folder dan Ekstraksi Kandidat FK

Aksi pertama alat ini adalah membuka semua xlsm/xlsx di dalam folder lalu mengumpulkan sheet dan header kolom. Tahap ini sendiri bersifat mekanis sehingga tidak menarik. Yang menarik adalah aturan untuk menarik kandidat FK. Awalnya sederhana. Kalau nama kolom diakhiri *_id atau *Id, dianggap kandidat FK. Namun, hanya dengan satu aturan ini, false positive dan kelewatan sama-sama muncul.

Di sinilah saya menyambungkan AI. Saya serahkan seluruh daftar header kolom dan meminta AI menyimpulkan sheet target FK-nya. Berikut adalah prompt lengkap yang benar-benar saya lemparkan beserta keluaran mentahnya.

Prompt: Berikut adalah nama sheet dan daftar header kolom dari beberapa sheet data game. Simpulkan apakah tiap kolom adalah kunci asing (FK), dan jika FK, kolom dari sheet mana yang direferensikannya. Aturan penamaan kolom biasanya <bentuk_tunggal_sheet_target>_id. Namun, kalau tidak yakin, tandai dengan "tidak pasti" dan tuliskan alasannya. Jangan mengisi dengan tebakan.

QuestTable: quest_id, title, npc_id, reward_id, prev_quest_id, region_id
NPCTable: npc_id, name, region_id, faction_id
RewardTable: reward_id, item_id, count, currency_id
ItemTable: item_id, name, item_effect_id, grade
ItemEffectTable: item_effect_id, effect_type, value
RegionTable: region_id, name, parent_region_id

Keluaran mentah Claude (baris PK dihilangkan, hanya penilaian FK yang dikutip):

QuestTable - npc_id → NPCTable.npc_id (diperkirakan NPC yang memberikan quest) - reward_id → RewardTable.reward_id - prev_quest_id → QuestTable.quest_id (quest pendahulu, referensi mandiri) - region_id → RegionTable.region_id

NPCTable - region_id → RegionTable.region_id - faction_id → tidak pasti: FactionTable tidak ada dalam daftar input. Berdasarkan aturan penamaan kolom, kemungkinan mereferensikan FactionTable.faction_id, tetapi karena sheet tersebut tidak disediakan, targetnya tidak dapat dipastikan.

RewardTable - item_id → ItemTable.item_id - currency_id → tidak pasti: CurrencyTable tidak ada dalam daftar. Ada kemungkinan jenis mata uang dikelola sebagai Enum sehingga mungkin bukan FK. Perlu pengecekan spesifikasi.

ItemTable - item_effect_id → ItemEffectTable.item_effect_id - grade → Bukan FK (diperkirakan Enum: nilai tingkatan/grade)

ItemEffectTable - effect_type → Bukan FK (diperkirakan Enum)

RegionTable - parent_region_id → RegionTable.region_id (referensi mandiri, struktur hierarki wilayah)

Perhatian: inferensi di atas berdasarkan aturan penamaan kolom, dan nilai data aktual belum diperiksa. Khususnya, kolom yang tidak diakhiri _id seperti count, value dikecualikan dari pemeriksaan FK, sehingga kalau ada referensi tersembunyi, hal itu akan terlewat.

Pada keluaran ini, ada tiga hal yang dikerjakan manusia.

• Penolakan 1: faction_id → AI memprosesnya sebagai tidak pasti karena FactionTable tidak ada. Benar. Hanya saja kenyataannya faction_id adalah Enum. Karena faksi tetap berjumlah 6 jenis, ia dikelola sebagai Enum tanpa sheet terpisah. Berkat AI tidak mengarang sheet yang tidak ada dan menghentikan penilaian, manusia bisa melihat spesifikasi lalu memastikannya sebagai Enum. Dikeluarkan dari FK.
• Penolakan 2: currency_id → AI membiarkan kedua kemungkinan terbuka. Setelah melihat data aktual, ternyata CurrencyTable memang ada (saya yang melewatkannya dari daftar input). Dipastikan sebagai FK. Ini kelalaian input dari manusia yang tidak bisa menyalahkan AI.
• Penerimaan: deteksi referensi mandiri pada prev_quest_id dan parent_region_id. Hal ini akan terlewat seandainya hanya mengandalkan aturan ekspresi reguler (regex) sederhana. AI membantu mempercepat verifikasi karena menambahkan makna seperti "quest pendahulu" dan "hierarki wilayah".

Pelajaran yang saya peroleh di sini jelas. Bagian di mana AI paling berguna bukanlah inferensi yang cepat, melainkan pengendalian dirinya untuk membiarkan kosong tempat yang tidak diketahui dengan tanda "tidak pasti". Seandainya kotak kosong itu dipaksa diisi, faction_id akan tersambung ke sheet yang keliru, dan false positive itu akan tertinggal sebagai anak panah palsu di peta relasi serta menyesatkan Game Designer baru.

3.3.2.4 Tahap 2 — Membangun Graf dan Memberi Layer

Begitu daftar FK yang terverifikasi keluar, gen_relation_map.py membangun grafnya. Sheet menjadi node, FK menjadi edge berarah. Jumlah edge masuk (seberapa banyak sheet lain mereferensikan saya) dihitung untuk menentukan ukuran node. Semakin banyak direferensikan, semakin besar node-nya, yaitu hub dari sistem.

Metadata Layer ditarik dari dokumen skema Markdown yang dibuat oleh skill schema-doc. Koordinat Layer (L0–L4) yang didefinisikan di 3.1 melekat sebagai label pada tiap sheet, dan alat ini membacanya untuk mewarnai node. Sambungan ini penting. Kalau peta relasi tidak mengenal Layer, ia hanyalah kotak dan anak panah; baru setelah mengenal Layer, "arah terbalik" bisa didiagnosis dengan warna.

Kalau struktur internal alat ini ditampilkan sebagai kerangka kode, bentuknya seperti ini (hanya alur inti yang dikutip).

# gen_relation_map.py (kutipan alur inti)
from pyvis.network import Network

LAYER_COLORS = {          # Palet Layer — distandarkan jadi satu atom
    "L0": "#2c3e50",      # meta/umum
    "L1": "#2980b9",      # sistem
    "L2": "#27ae60",      # konten
    "L3": "#f39c12",      # instans data
    "L4": "#c0392b",      # turunan/cache
}

def build_graph(fk_list, layer_map):
    net = Network(directed=True, height="900px")
    inbound = count_inbound(fk_list)          # hitung edge masuk
    for sheet in all_sheets(fk_list):
        layer = layer_map.get(sheet, "L0")
        size = 10 + inbound[sheet] * 3        # makin hub, makin besar node
        net.add_node(sheet, color=LAYER_COLORS[layer],
                     size=size, title=sheet_tooltip(sheet))
    for src, dst, col in fk_list:
        # Deteksi Layer terbalik: kalau Layer atas mereferensikan yang bawah, beri warna peringatan
        edge_color = "#e74c3c" if is_reverse(src, dst, layer_map) else "#888"
        net.add_edge(src, dst, title=col, color=edge_color)
    return net

is_reverse adalah inti kecil dari alat ini. Kalau sheet asal sebuah edge berada di Layer yang lebih atas daripada sheet tujuannya (misalnya L1 → L3), itu dianggap arah terbalik dan edge-nya diwarnai merah. Saat manusia membuka gambar dan melihat anak panah merah, itu hampir selalu tempat yang perlu diperbaiki.

3.3.2.5 Tahap 3 — Render HTML dan Struktur Hasil

Tahap terakhir adalah pyvis memuntahkan HTML interaktif. Saat node diklik, kolom, Layer, dan jumlah edge masuk sheet tersebut muncul sebagai tooltip, dan kita bisa memfilter berdasarkan nama sheet di kotak pencarian. Alasan mengapa harus HTML dan bukan PNG statis ada di sini — kalau jumlah node melewati puluhan, pada gambar statis anak panahnya kusut sehingga tidak ada yang terlihat. Kita harus menarik dengan mouse untuk membentangkannya, lalu mempersempit hanya ke area yang diminati dengan klik, barulah polanya tertangkap.

Kalau struktur peta relasi yang dibuat dari data contoh di atas dipindahkan ke SVG, bentuknya seperti ini. Warna menunjukkan Layer, dan anak panah merah berarti tempat arah terbalik (meskipun pada contoh ini tidak ada).

Kalau dilihat dari ukuran node, RegionTable paling banyak direferensikan (Quest dan NPC semuanya menunjuk ke sana). Inilah hub-nya. ItemEffectTable adalah node daun sehingga kecil. Jawaban atas pertanyaan Game Designer baru, "Untuk memahami sistem ini, dari mana saya harus mulai melihat?", sudah ada di dalam gambar berdasarkan urutan ukuran node.

3.3.3 Diagnosis yang Dihasilkan Gambar — Berpadu dengan Layer

Di 3.1 koordinat Layer sudah didefinisikan. Ketika peta relasi pada bab ini mengangkat koordinat itu ke ranah visual, empat diagnosis yang mustahil dilakukan dengan teks atau tabel menjadi mungkin dalam satu layar.

• Layer terbalik — anak panah yang warna Layer-nya mengalir ke arah berlawanan (merah). Struktur tidak wajar di mana sheet data justru memengaruhi desain sistem secara terbalik.
• Node terisolasi — pulau terpencil yang tidak terhubung dengan edge mana pun. Kandidat untuk dibuang.
• Hub kelebihan beban — node raksasa dengan edge masuk yang luar biasa banyak. Ini sinyal bahwa satu sheet memikul terlalu banyak tanggung jawab, sehingga pemecahan (split) perlu dipertimbangkan.
• Dependensi siklik — tempat anak panah membentuk lingkaran. Hampir selalu cacat desain, dan berujung pada masalah urutan pemuatan data.

Namun, ini tidak berarti gambar menangkap semua masalah. Gambar menangkap cacat struktural. Apakah FK ini benar-benar relasi yang tepat secara makna (misalnya: apakah npc_id benar-benar "NPC yang memberikan quest" atau "NPC yang muncul dalam quest") tidak terpecahkan oleh gambar. Itu bagian dari penilaian domain manusia. Alat ini hanya menyiapkan panggung tempat penilaian manusia bisa bekerja.

3.3.4 Tanpa Pembaruan Otomatis, Peta Akan Lapuk

Peta relasi tidak selesai dengan sekali dibuat. Sheet ditambah dan diubah setiap minggu. Peta relasi yang diserahkan pada pembaruan manual akan menyimpang dari struktur nyata dalam satu-dua bulan, dan peta yang menyimpang justru memandu ke jalan yang salah, sehingga lebih baik tidak ada sama sekali. Anggota tim yang pernah kapok karena gambar yang sekali salah, setelah itu tidak akan melihat gambar lagi — inilah kegagalan yang paling mahal.

Karena itu, pembaruan dikaitkan dengan pemicu otomatis.

• Git pre-push hook — membangkitkan ulang peta relasi sebelum mem-push sheet data. Selalu terjamin dalam kondisi paling baru.
• Saat permintaan perubahan — begitu permintaan perubahan sheet data masuk, peta relasi sebelum dan sesudah perubahan dibandingkan secara diff lalu dilampirkan ke komentar. Edge yang ditambahkan berwarna hijau, edge yang hilang berwarna merah. Reviewer melihat cakupan dampak lewat gambar.
• Batch malam — setiap malam dibuat peta relasi baru dan ditinggalkan diff-nya dengan hari sebelumnya.
• Perintah manual — slash command /relation-map untuk pembuatan instan. Dipakai saat ingin menampilkannya secara dadakan di tengah rapat.

HTML yang dihasilkan otomatis di-deploy ke hosting statis internal (portal perencanaan). Tanpa perlu memasang alat tambahan, siapa pun yang punya browser bisa melihat peta yang sama. Sama seperti peta yang selalu terbentang di samping meja. Siapa pun yang bertanya, kami menjawab sambil sama-sama menunjuk gambar yang sama.

3.3.5 Kesalahan Umum dan Cara Menghindarinya

Dalam pengoperasian gen_relation_map.py, yang paling sering membuat saya kapok adalah baris ketiga. Kalau hanya memercayai aturan *_id, referensi tersembunyi seperti count atau value akan terlewat (AI di 3.3.2.3 pun memperingatkan batasan ini sendiri), dan grade yang merupakan Enum jadi false positive sebagai FK. Loop verifikasi yang melihat spesifikasi sekaligus data nyata adalah jawaban untuk baris ini.

3.3.6 Mencoba Dahulu dengan Versi Ringkas Solo

Kalau langsung mencoba menangani seluruh sheet data perusahaan sekaligus, hasilnya berat, dan kita keburu lelah bahkan sebelum bisa menunjukkan nilainya. Mulailah dari kecil, dari satu folder bidang Anda sendiri.

Coba Sendiri

setup. 1. Pilihlah satu folder berisi 5–10 sheet data yang Anda tangani. 2. Pasang dependensi dengan pip install pyvis openpyxl (untuk membaca Excel gunakan skill excel-reader atau openpyxl). 3. Periksa dahulu di sheet $스키마 tiap sheet apakah FK sudah ditulis eksplisit. Kalau tidak ada, cukup kumpulkan header kolomnya.

prompt. Kumpulkan daftar header kolom lalu lemparkan prompt dari 3.3.2.3 apa adanya. Intinya ada di satu baris terakhir — "Kalau tidak yakin, tandai dengan tidak pasti, dan jangan mengisi dengan tebakan." Kalimat inilah yang mencegah anak panah palsu.

verify. 1. Lihatlah kandidat FK yang dilemparkan AI satu baris demi satu baris. Pastikan baris yang ditandai "tidak pasti" dengan spesifikasi/data nyata. 2. Keluarkan dari FK kolom yang dicurigai sebagai Enum (yang tampak seperti FK padahal tanpa _id, seperti grade, effect_type). 3. Pastikan referensi mandiri (prev_*_id, parent_*_id) tertangkap dengan benar. 4. Gambar grafnya dengan daftar yang terverifikasi, buka di browser, lalu cari dengan mata anak panah merah (terbalik) dan pulau terpencil (terisolasi).

Versi Ringkas Solo

Kalau tidak ada waktu untuk membuat alatnya, pada minggu pertama Anda boleh mulai dengan satu lembar mermaid yang digambar tangan. Tuliskan langsung FK dari 5 sheet ke mermaid dengan format 3.3.2.3. Kalau Anda membawa satu lembar ini ke rapat lalu menunjukkan "inilah dependensi sistem kita", nilainya terbukti di tempat itu juga. Begitu nilainya terlihat, alat otomasi secara alami akan menyusul berikutnya. Anda boleh melepaskan beban untuk langsung menghasilkan alat yang berfungsi sempurna sejak awal.

Perluasannya mengalir secara alami dengan urutan ini — minggu ke-1 gambar tangan mermaid sheet Anda sendiri → minggu ke-2 menambahkan warna Layer dan klik → 1 bulan pembaruan otomatis (git hook atau batch malam) → 3 bulan deploy ke portal internal → 6 bulan peta relasi gabungan seluruh sheet.

3.3.7 Sambungan ke Bab Berikutnya

Di 3.2 dibahas bagian dalam sheet (skema), dan di 3.3 dibahas bagian luar sheet (relasi). Di 3.4 di atas semua ini ditumpukkan pola prompt berbantuan AI. Di atas sistem yang skema dan relasinya sudah tertata, pembahasan berlanjut ke pola-pola praktis tentang bagaimana AI membantu pemeriksaan konsistensi dan ekstraksi cakupan dampak.

Poin-Poin Penting

• Kalau graf dependensi yang ada di kepala dieksternalisasi, gambar yang sama tetap ada di tempatnya meskipun orangnya berganti.
• Ekstraksi FK memperoleh akurasinya dari loop verifikasi di mana manusia menyaring false positive dari draf yang dihampar AI.
• Peta relasi tanpa pembaruan otomatis akan lapuk dalam satu-dua bulan dan kehilangan kepercayaan.

Pratinjau Bab Berikutnya

• 3.4. Pola Prompt Desain Sistem Berbantuan AI

3.4 Pola Prompt untuk Desain Sistem Berbantuan AI

Itu minggu menjelang alpha build. Saya menambahkan satu baris class baru ke sheet skill, lalu menyimpannya. Ternyata buff_id yang dirujuk class itu adalah baris yang sehari sebelumnya dihapus oleh seseorang — dan saya baru menyadarinya keesokan paginya, setelah build-nya rusak. Menelusuri kembali build yang rusak itu untuk mencari penyebabnya memakan waktu dua jam. Dua jam yang tidak akan terbuang seandainya, sebelum menghapus satu baris, saya bisa bertanya lebih dulu: "Boleh nggak baris ini dihapus?"

Bab ini adalah tentang cara menyuruh AI mengajukan pertanyaan itu. Intinya bukan kiat menulis prompt yang bagus. Intinya adalah membakukan pertanyaan yang sama agar tidak perlu ditulis ulang dari nol setiap kali. Di 3.2 kita memasang skema, di 3.3 kita memasang peta relasi. Keduanya adalah kerangka data. Bab ini mengukuhkan pertanyaan yang dilemparkan manusia kepada AI di atas kerangka itu menjadi aset.

Lebih dulu saya kunci satu hal. Yang dibuat AI bukan jawaban, melainkan kandidat. Dalam semua pola yang muncul di bab ini, tangan yang membuat keputusan akhir tetap berada di sisi manusia sampai akhir.

3.4.1 Dua Titik Bocor pada Prompt Dadakan

Saat baru mulai menggunakan AI, kita mengetiknya secara dadakan dengan bahasa alami setiap kali. Kira-kira begini.

Coba lihat sheet skill ini. Cek ada nggak foreign key yang rusak,
kalau ada yang aneh kasih tahu ya. Oh iya, dan yang cooldown-nya negatif juga.

Prompt ini bocor di dua titik.

Pertama, item pemeriksaan berubah-ubah setiap kali. Hari ini saya teringat "cooldown negatif", tetapi besok saya lupa. "PK ganda (Primary Key, kunci primer)" yang kemarin sempat tersaring hari ini hilang dari prompt. Pemeriksaan yang bergantung pada ingatan manusia akan terlewat sebanyak kondisi manusia itu sendiri.

Kedua, format hasil berubah-ubah setiap kali. Jika maksud yang sama saya tuliskan berbeda-beda sebagai "tolong cek", "periksa", "lihat sekilas", AI akan menjawab dengan tabel pada satu hari, dan dengan paragraf pada hari lain. Kalau formatnya tidak konsisten, hasilnya tidak bisa diproses ulang secara otomatis.

Solusinya adalah melepaskan prompt dari tangan dan memasukkannya ke laci. Catatan yang setiap kali ditulis tangan diganti menjadi kartu berlabel, lalu diambil dari laci yang sama. Kartu itulah yang dalam buku ini disebut slash command (skill, perintah garis miring) dan atom.

3.4.2 Tiga Bentuk Pembakuan dan Kriteria Memilihnya

Pembakuan punya tiga wadah. Apa yang ditaruh di mana ditentukan oleh frekuensi pemanggilan dan stabilitas.

Pekerjaan yang sering dipakai dan definisinya sudah mengeras dibuatkan slash command. Yang sering dipakai tetapi merupakan "constraint yang tidak boleh dilupakan" diinjeksikan otomatis lewat atom JIT. Pekerjaan yang jarang tetapi berbadan besar dibuatkan file template. Dan pekerjaan yang definisinya masih goyah tidak dibakukan, melainkan dibiarkan dadakan. Tidak perlu memiliki ketiganya sejak awal. Mulai dengan satu-dua slash command, lalu tambah ketika nilainya mulai terlihat.

3.4.3 Pola ① Pemeriksaan Konsistensi — Worked Transcript

Alih-alih menjelaskannya dengan kata-kata, saya akan menelusuri satu pola dari awal hingga akhir. Ini pola yang secara otomatis bertanya "Boleh nggak baris ini dihapus?" sebelum sebuah baris kosong dihapus. Namanya /check-sheet. Di dalamnya, item pemeriksaan dan format keluaran sudah dibakukan.

Aset yang menjadi landasannya ada pada catatan kerja terukur yang ditanamkan di sana-sini dalam buku ini. Entri data mengikuti prinsip schema-first (atom data_entry_schema_first). Urutan entrinya adalah sheet $스키마 → Enum/*.proto (VBA (bahasa makro Excel) Export) → csv. Dan sumber kebenaran bukanlah dokumen skema, melainkan keluaran JSON yang sebenarnya (atom json_over_schema_doc_as_source_of_truth). Pemeriksaan konsistensi adalah memindahkan kedua prinsip itu apa adanya menjadi aturan pemeriksaan.

setup — Isi dari Perintah yang Dibakukan

Jika Anda membuka /check-sheet, di dalamnya termuat badan prompt seperti ini. Inilah bagian yang tidak perlu Anda ketik tangan setiap kali.

Peran: Kamu adalah pemeriksa konsistensi sheet data game.

Sheet yang diperiksa: {{sheet_name}}
Skema yang dapat dirujuk: sheet $스키마 (tipe·rentang·target FK per kolom)
Sumber kebenaran yang dapat dirujuk: export JSON dari sheet yang sama (lebih utama daripada dokumen skema)

Item pemeriksaan (dengan urutan ini):
1. Validitas foreign key — apakah nilai kolom FK benar-benar ada di sheet target rujukan
2. Pelanggaran rentang — nilai yang keluar dari min/max yang didefinisikan di $스키마
3. Kolom wajib yang kosong — baris kosong pada kolom required=true
4. PK ganda — PK yang sama muncul dua kali atau lebih

Format keluaran (wajib persis tabel ini):
| # | Baris | Kolom | Jenis pelanggaran | Nilai saat ini | Kandidat perbaikan | Tingkat keyakinan |

Aturan:
- Kandidat perbaikan hanya diusulkan. Jangan pernah mengubah sheet secara langsung.
- Tingkat keyakinan salah satu dari tinggi/sedang/rendah. Jika menebak, beri rendah.
- Jika tidak ada pelanggaran, cukup keluarkan "0 pelanggaran" lalu selesai.

Yang penting dalam badan ini adalah tiga baris aturan terakhir. "Jangan mengubah langsung", "beri tingkat keyakinan", "akui tebakan sebagai rendah". Ketiga baris ini mengikat AI ke posisi yang mendorong kandidat, bukan posisi yang memberi jawaban.

prompt — Satu Baris yang Benar-Benar Diketik Manusia

/check-sheet skill_table

Selesai. Hanya satu nama sheet yang diteruskan. Keempat item pemeriksaan maupun format tabel keluaran tidak ditulis ulang. Itulah nilai dari pembakuan.

Keluaran Mentah dari Claude

Berikut adalah keluaran yang kembali ketika benar-benar dijalankan. Tanpa diringkas, saya muat apa adanya — termasuk bagian yang ambigu dan tempat AI tampak ragu.

Berikut hasil pemeriksaan konsistensi skill_table. Ditemukan total 4 pelanggaran.

| # | Baris | Kolom      | Jenis pelanggaran | Nilai saat ini | Kandidat perbaikan          | Keyakinan |
|---|-------|------------|-------------------|----------------|-----------------------------|-----------|
| 1 | 142   | buff_id    | Pelanggaran FK    | 9007           | 9070 (dugaan salah ketik, 1 digit) | Sedang    |
| 2 | 142   | buff_id    | Pelanggaran FK    | 9007           | 9012 (nama "racun ganas" mirip)    | Rendah    |
| 3 | 88    | cooldown   | Pelanggaran rentang | -1           | 0 (negatif tidak boleh)     | Tinggi    |
| 4 | 215   | combo_next | Wajib kosong      | (kosong)       | Ditangguhkan                | Rendah    |

Saya tambahkan beberapa catatan.

- Nomor 1 dan 2 adalah dua kandidat berbeda untuk kolom yang sama di baris
  yang sama (142). ID 9007 tidak ada di sheet buff. 9070 berbeda satu digit
  angka sehingga mungkin salah ketik, dan 9012 saya naikkan sebagai kandidat
  karena namanya "racun ganas" yang mirip. Keduanya keyakinannya rendah.
  Manusia harus memilih.

- Nomor 4 (combo_next kosong di baris 215) ambigu. Di $스키마 tertulis
  required=true, tetapi setelah saya lihat export JSON, ada 12 baris lain
  yang kolom ini juga kosong. Bisa jadi spesifikasinya bukan yang terbaru,
  atau ada aturan "skill penutup combo membiarkan combo_next kosong" yang
  belum tercermin di spesifikasi. Karena saya tidak bisa memastikannya,
  saya biarkan sebagai "ditangguhkan".

- Selain cooldown, jika ingin menjalankan lebih banyak pemeriksaan rentang,
  perlu memeriksa min/max kolom lain di $스키마, tetapi pada informasi yang
  saya terima sebagian kolom range_check kosong, sehingga kolom cast_time
  tidak bisa saya periksa.

Alasan keluaran ini bagus di sini bukan karena ia rapi, melainkan karena ia jujur. Ia tidak memastikan nomor 4 dengan "karena wajib, isi saja", melainkan menunjukkan keraguannya sendiri dengan "spesifikasinya mungkin bukan yang terbaru". Ia juga mengakui keterbatasan bahwa ia tidak bisa melihat cast_time. Seandainya AI menyatakan nomor 4 dengan percaya diri "isi dengan 0", itu bisa jadi jawaban salah yang merusak skill penutup combo.

verify — Verifikasi dan Veto oleh Manusia

Sekarang manusia memutuskan baris demi baris. Verifikasi yang otomatis menyertai berarti tabel ini muncul otomatis — bukan berarti manusia tidak melihatnya.

• Nomor 3 (cooldown -1 → 0): Diterima. Keyakinan tinggi, cooldown negatif jelas kesalahan entri. Langsung diperbaiki.
• Nomor 1·2 (buff_id 9007): Ditangguhkan. Keduanya keyakinan rendah. Diputuskan membuka langsung sheet buff untuk memeriksa ID asli buff dari keluarga "racun ganas". Kedua kandidat AI tidak diterima.
• Nomor 4 (combo_next kosong): Ditolak. Yang diragukan AI ternyata benar. Skill ini adalah penutup combo, sehingga combo_next kosong itu normal. Bukan pelanggaran. Ditolak, dan ini masalah di sisi spesifikasi.

Nomor 4 yang terakhir adalah inti. Di titik yang seandainya keluaran AI dipercaya begitu saja akan merusak data yang sehat, veto manusia bekerja. Pada saat yang sama, nomor 4 juga mengungkap cacat pada aturan pemeriksaan itu sendiri. required=true pada spesifikasi itu salah.

Permintaan Ulang — Penolakan Memperbaiki Aturan

Kita tidak berhenti di sini. Penolakan adalah input yang membuat pemeriksaan berikutnya lebih cerdas. Manusia melanjutkan mengetik.

Nomor 4 bukan pelanggaran. Untuk skill dengan combo_finisher=true, combo_next
yang kosong itu normal. Masukkan aturan pengecualian ini ke item pemeriksaan,
supaya ke depan combo_next kosong pada baris finisher tidak dianggap pelanggaran.
Lalu item yang definisi required pada spesifikasinya tampak salah, pisahkan dan
laporkan di bagian "dugaan spesifikasi salah" tersendiri.

Saya mengerti. Saya akan menerapkan pengecualian pada aturan pemeriksaan /check-sheet.

Aturan yang ditambahkan:
- Saat memeriksa kewajiban combo_next, periksa dulu nilai combo_finisher di
  baris yang sama. Jika combo_finisher=true, combo_next kosong diproses sebagai
  normal (dikecualikan dari pelanggaran).

Bagian baru:
- "Dugaan spesifikasi salah" — ketika distribusi nyata export JSON berbeda dari
  definisi $스키마, pisahkan sebagai kandidat yang seharusnya memperbaiki
  spesifikasi, bukan data, lalu laporkan.
  (Sesuai prinsip bahwa sumber kebenaran adalah JSON, jika mayoritas data
   bertentangan dengan spesifikasi, yang dicurigai adalah sisi spesifikasi.)

Apakah perubahan ini perlu saya catat ke atom definisi perintah /check-sheet?

Baris terakhir itulah penyempurnaan pola ini. Satu penolakan tidak berhenti sebagai perbaikan sekali pakai, melainkan tercatat ke atom definisi perintah dan menyebar ke manusia berikutnya dan pemeriksaan berikutnya. Inilah bunga majemuk dari pembakuan. Kesalahan yang sama tidak disaring dua kali.

3.4.4 Pola ② Ekstraksi Cakupan Dampak Perubahan — Worked Transcript

Pola kedua adalah menghapus dua jam dari adegan pembuka itu. Sebelum mengubah satu baris atau satu keputusan, kita bertanya lebih dulu "sejauh mana ini akan menjalar". Namanya /impact. Peta relasi yang dibuat di 3.3 (HTML relasi FK yang dihasilkan gen_relation_map.py) adalah bahan bakar pola ini.

setup — Jalur Penelusuran yang Dibakukan

Di dalam /impact, "ke mana harus menggali agar dampak ditemukan tanpa terlewat" sudah dibakukan dalam empat cabang.

Peran: Kamu adalah pengekstrak cakupan dampak perubahan.

Target perubahan: {{target}}  (salah satu dari nama sheet·kolom·atom_id·keputusan sistem)

Jalur penelusuran (jalankan keempatnya):
1. Inbound peta relasi — di keluaran gen_relation_map.py, sheet-sheet yang
   merujuk {{target}} sebagai FK (panah yang menunjuk ke sheet ini)
2. Penyebutan di teks — dokumen di dalam sources/manuscript tempat ID·nama
   {{target}} muncul langsung
3. Relasi affects atom — atom-atom yang terhubung dengan {{target}} lewat affects
4. Rujukan balik — catatan yang menunjuk {{target}} dengan [[wikilink]]

Format keluaran:
| Jenis | Nama | Dasar koneksi | Kekuatan dampak | Penanggung jawab |

Aturan:
- Kekuatan dampak adalah salah satu dari langsung/tak langsung/lemah. FK langsung = 'langsung', penyebutan teks = 'tak langsung', dugaan = 'lemah'.
- Jika takut ada yang terlewat, naikkan walau hanya sebagai lemah. Lebih baik daripada terlewat.
- Jangan memberi prioritas atau instruksi kerja. Buat daftar saja.

prompt

/impact buff_id=9012

"Saya ingin mengganti buff racun ganas (9012) dengan efek lain, di mana saja yang akan goyah?" ditanyakan dalam satu baris.

Keluaran Mentah dari Claude

Berikut cakupan dampak perubahan buff_id=9012 (racun ganas). Keempat jalur telah ditelusuri.

| Jenis    | Nama                 | Dasar koneksi              | Kekuatan dampak | Penanggung jawab |
|----------|----------------------|----------------------------|-----------------|------------------|
| Sheet    | skill_table          | Rujukan langsung FK buff_id | Langsung        | teammate_a       |
| Sheet    | monster_drop         | Rujukan FK reward_buff      | Langsung        | teammate_b       |
| Sheet    | set_item_effect      | Rujukan FK proc_buff        | Langsung        | teammate_a       |
| Dokumen  | catatan_balance_lini_racun.md | Penyebutan langsung "9012" di teks | Tak langsung | (penulis)   |
| atom     | poison_stack_rule    | affects: 9012              | Tak langsung    | (penulis)        |
| Catatan  | desain_status_effect.md | Rujukan balik [[racun ganas]] | Lemah        | (penulis)        |

Beberapa tambahan.

- Baris yang merujuk 9012 di skill_table ada 3 (skill class assassin).
  Jika diganti, efek nyata dari 3 skill ini berubah. Ini dampak terkuat.

- Untuk reward_buff di monster_drop, keyakinan saya agak lemah. Nama kolomnya
  reward_buff, tetapi sebagian baris tampak mengandung nilai yang menunjuk item
  alih-alih buff. Saya sarankan Anda membuka langsung sheet ini sekali untuk
  memeriksanya.

- "catatan_balance_lini_racun.md" hanya menyebut 9012 sebagai teks dan bukan FK,
  sehingga saya taruh sebagai tak langsung. Namun karena ini dokumen yang memuat
  niat balance, dampak nyatanya bisa kuat. Perhatikan bahwa kekuatan (tak langsung)
  dan tingkat kepentingan bisa berbeda.

- set_item_effect menggunakan 9012 sebagai proc_buff di 4 jenis set item.
  Jika racun ganas dilepas, konsep set-set ini berubah.

verify — Verifikasi dan Veto oleh Manusia

• skill_table (langsung, anggota tim A): Dikonfirmasi. 3 skill assassin terdampak langsung. Perlu dibagikan ke anggota tim A. Diterima.
• monster_drop (langsung): Item yang diragukan AI sendiri. Sheet dibuka langsung untuk diperiksa. Hasil: kolom reward_buff memang mengandung ID item bercampur, dan baris yang merujuk 9012 ternyata hanya 1. Pengakuan "keyakinan lemah" dari AI tepat. Kekuatan diturunkan dari langsung→tak langsung.
• set_item_effect (langsung, anggota tim A): Dikonfirmasi. 4 jenis set terdampak. Diterima.
• desain_status_effect.md (lemah): Rujukan balik biasa, tidak ada dampak pada teks. Tetap disimpan di daftar tetapi dikeluarkan dari target kerja.

Di sini pun kejujuran AI membantu verifikasi. Seandainya monster_drop dipastikan sebagai langsung, dampak akan dilebih-lebihkan dan rapat koordinasi yang tidak perlu akan terjadwal. Berkat AI yang mengoper bola ke manusia dengan "saya sarankan Anda memeriksa", kekuatannya bisa dibenahi.

Permintaan Ulang — Dari Ekstraksi ke Pembagian

Setelah daftar terverifikasi, tangan berikutnya adalah menyampaikannya kepada manusia.

Kelompokkan berdasarkan penanggung jawab yang terdampak langsung, lalu buatkan
draf memo pembagian singkat untuk dikirim ke teammate_a / teammate_b. Pakai format
"sedang mempertimbangkan mengganti racun ganas 9012 dengan X, N baris di sheet Anda
terdampak". Keputusan belum diambil, jadi pakai nada permintaan pendapat, bukan
pemberitahuan.

Berikut draf memo pembagian per penanggung jawab. Saya susun dengan nada permintaan pendapat, bukan pemberitahuan.

[Untuk teammate_a]
Sedang mempertimbangkan opsi mengganti buff racun ganas (9012) dengan efek lain.
Belum final dan saya ingin mendengar pendapat lebih dulu. Cakupan dampak:
- skill_table: 3 baris skill assassin merujuk 9012 (dampak langsung)
- set_item_effect: 4 jenis set item memakai 9012 sebagai proc_buff
Saat diganti, konsep skill·set ini berubah. Jika ada keberatan atau usulan
pelengkap, beri tahu saya dalam minggu ini.

[Untuk teammate_b]
Mohon konfirmasi terkait reward_buff di monster_drop. Sedang dipertimbangkan
penggantian buff racun ganas (9012), dan baris terdampak tampak ada 1 (kolom
reward_buff mengandung ID item bercampur, sehingga awalnya tampak lebih banyak).
Bisakah Anda memastikan apakah benar hanya 1 baris ini?

Kedua memo saya buat sebagai "sedang dipertimbangkan·permintaan pendapat", dan
ungkapan pemberitahuan final tidak saya masukkan. Sebelum mengirim, Anda perlu
mengisi efek kandidat pengganti (posisi X).

Dua jam dari adegan pembuka lenyap di sini. Sebelum perubahan kita menanyakan dampaknya, membagikannya lebih dulu ke penanggung jawab, dan koordinasi selesai sebelum build rusak keesokan harinya. Dan yang dibuat AI sampai akhir hanyalah draf memo — jari yang menekan kirim adalah milik manusia.

3.4.5 Kerangka yang Dibagi Dua Pola

Kedua transcript di atas mengikuti kerangka yang sama. Semua pola lain pun bertumpu pada kerangka ini.

flowchart LR
    A[Perintah yang dibakukan
item periksa·format keluaran·larangan] --> B[Manusia: panggil satu baris
hanya meneruskan target]
    B --> C[Claude: keluaran mentah
kandidat+keyakinan+keraguan diri]
    C --> D{Verifikasi manusia}
    D -->|Terima| E[Diterapkan]
    D -->|Benahi| F[Perbaikan kekuatan·nilai]
    D -->|Tolak| G[Cacat aturan ditemukan]
    G --> H[Pembaruan atom definisi perintah]
    H -.Tercermin di panggilan berikutnya.-> A
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class A,H data
    class B,D,F human
    class C ai
    class E pass
    class G fail

Intinya adalah garis putus-putus di kanan bawah. Penolakan bukan akhir, melainkan kembali sebagai input yang memperbaiki perintah itu sendiri. Nomor 4 yang ditolak dalam pemeriksaan konsistensi menjadi aturan pengecualian finisher, dan aturan itu tercatat ke atom lalu menyebar ke pemeriksaan berikutnya. Tanpa umpan balik ini, jawaban salah yang sama akan disaring ulang setiap minggu.

Tangan manusia tertinggal di tiga titik. Pemanggilan (memilih target), verifikasi (terima, benahi, tolak), dan perbaikan aturan (mengembalikan penolakan ke aliran). AI hanya mengerjakan dorongan kandidat di antara ketiganya.

3.4.6 Pola Sisanya — Variasi dari Kerangka yang Sama

Jika kerangka yang sama dipindahkan ke pekerjaan lain, polanya bertambah. Tanpa transcript, saya hanya menunjuk posisinya. Karena semuanya mengikuti persis kerangka 3.4.5, intinya saat membuat adalah tidak melewatkan "item pemeriksaan yang dibakukan" dan "titik verifikasi manusia".

Pada kalkulasi balance ada satu hal yang saya kunci. Meski kurva turun mulus secara angka, apakah kemulusan itu cocok dengan niat game adalah soal lain. Ada kalanya saya ingin sengaja membuat segmen tepat sebelum boss menjadi curam, tetapi AI memangkasnya rata sambil menyebutnya "outlier". Karena itu meski kalkulasi balance sudah otomatis disertai verifikasi kurva, baris terakhirnya baru tertutup setelah manusia membandingkannya dengan niat.

3.4.7 Lima Prinsip Operasional dan Titik Konvergensi

Ketika pola bertambah, disiplin operasional dibutuhkan. Lima prinsip di bawah ini bukan aturan untuk dihafal, melainkan prinsip desain yang ditanam ke dalam alat itu sendiri.

Terakhir satu titik konvergensi. Pada suatu proyek MMORPG yang penulis operasikan, slash command yang stabil bertahan di desain sistem seiring waktu mengerucut ke kisaran 12 buah. Ini bukan standar publik, melainkan nilai pengamatan satu proyek (pengalaman penulis, belum terverifikasi). Namun arahnya jelas. Perintah bukan untuk ditambah tanpa batas, melainkan berhenti pada jumlah yang muat di kepala dengan menambah dan mengurangi 1\~2 per bulan. Laci dengan 100 label sama saja dengan laci tanpa label.

Adopsi tidak dilakukan sekaligus. Pada bulan pertama, cukup membakukan satu pekerjaan yang Anda ulang setiap minggu menjadi slash command. Jika satu itu menunjukkan nilainya, pada bulan berikutnya ia menyebar sendiri menjadi dua, tiga.

3.4.8 Menutup Part 3

Di 3.1 kita memasang koordinat Layer desain sistem, di 3.2 skema, di 3.3 peta relasi, dan di 3.4 kita menumpangkan prompt bantuan AI di atasnya. Seminggu seorang System Designer yang melewati keempat bab berubah seperti ini.

flowchart LR
    M[Sen: sintesis draf GDD
4h → 1h] --> T[Sel: pemeriksaan konsistensi
setengah hari → 5 menit]
    T --> W[Rab: onboarding, satu peta relasi
5 rapat → 1 lembar]
    W --> Th[Kam: ekstraksi cakupan dampak
rapat 1h → 10 menit]
    Th --> F[Jum: klasifikasi retrospektif otomatis
manual → berbasis data]
    F --> R[Waktu yang dihemat
diinvestasikan ulang ke desain·tinjauan·pengalaman pemain]
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class M,T,W,Th,F ai
    class R pass

Waktu untuk pekerjaan remeh berkurang, dan waktu itu kembali ke pemikiran desain yang mendalam dan pengalaman pemain. Tidak mengisi ulang waktu yang dihemat itu dengan pekerjaan remeh lagi — itulah alasan sebenarnya mengadopsi alat.

Part 4 berikutnya adalah desain tempur. Sebagai saudara terdekat dari desain sistem, alat dan pola 3.1\~3.4 berpindah apa adanya.

Poin-Poin Penting

• Siklus membakukan prompt dadakan menjadi slash command, atom, dan template adalah titik pemulihan nilai terbesar dari bantuan AI.
• Semua pola mengikuti kerangka yang sama: panggilan satu baris → keluaran mentah → verifikasi dan veto manusia → aliran balik aturan.
• AI mendorong kandidat, dan tangan terakhir untuk terima, benahi, dan tolak tetap berada di sisi manusia sampai akhir.

Coba Sendiri

setup. Pilihlah satu pekerjaan pemeriksaan yang Anda ulang setiap minggu (misalnya: konsistensi sheet). Tuliskan 4 item pemeriksaan dan format tabel keluaran untuk pekerjaan itu, lalu bakukan menjadi satu slash command. Tiga baris aturan ("jangan mengubah langsung / beri tingkat keyakinan / akui tebakan") wajib Anda masukkan ke badan perintah.

prompt. Panggil dengan meneruskan hanya target dalam satu baris.

/check-sheet skill_table

verify. Putuskan tabel yang kembali baris demi baris sebagai terima, benahi, atau tolak. Jika muncul penolakan, itu bukan kebetulan melainkan cacat aturan. Kirim ulang satu baris yang menambahkan pengecualian itu ke definisi perintah, agar panggilan berikutnya tidak menyaring kesalahan yang sama dua kali.

Versi Ringkas Solo

Jika Anda tidak punya tim maupun sistem atom, alih-alih slash command taruhlah satu blok teks di aplikasi catatan. Judulnya "Prompt Pemeriksaan Sheet". Isinya adalah 4 item pemeriksaan + 3 baris aturan dari setup di atas. Setiap kali memeriksa, salin blok ini dan tempel ke AI dengan hanya mengganti nama sheet. Ketika ada yang perlu ditolak, tambahkan sendiri satu baris pengecualian ke blok catatan itu. Entah alatnya slash command atau selembar catatan, siklusnya (bakukan → panggil → verifikasi·tolak → perbarui aturan) berjalan dengan cara yang sama.

Bagian 4 · Combat Design

4.1 Combat Designer dan Layer — Di Kotak Mana Hit Feel Diletakkan

Tujuan pembelajaran bab ini (tingkat kesulitan 🟡 praktis · prasyarat: aritmetika dasar·kalkulasi tabel): Anda akan mampu menguraikan kata sifat abstrak seperti hit feel (rasa pukulan) menjadi sinyal yang dapat diukur, dan menentukan secara koordinat di kotak Layer mana lima keluaran seorang combat designer diletakkan.

Ruang rapat build. Programmer menampilkan skill baru yang baru saja ia pasang di monitor. Karakter mengayunkan pedang, musuh terdorong ke belakang. Lima orang sedang menyaksikan. Salah seorang berkata.

"Hmm… hit feel-nya kok terasa agak lemah ya."

Orang di sebelahnya mengangguk. "Iya, agak hambar."

Programmer bertanya. "Bagian mana yang harus saya ubah dan bagaimana?"

Hening. Tak satu pun dari lima orang di ruang rapat itu bisa menjawab pertanyaan tersebut dengan angka. "Hit feel-nya lemah" memang dirasakan oleh kelima orang, tetapi tak ada yang bisa berkata "hitstop dari 3 frame ke 5 frame." Rapat berlangsung 40 menit, saling melempar kata sifat seperti "lebih berat lagi", "impact-nya kurang", lalu berakhir dengan "kita lihat lagi di build berikutnya saja."

Adegan ini memadatkan seluruh persoalan combat design. Ini adalah bidang yang paling langsung dirasakan pemain, tetapi begitu rasa itu coba dituangkan ke dalam kata-kata, yang tersisa hanyalah kata sifat. Kata sifat tidak bisa diukur, dan yang tidak bisa diukur tidak bisa disetel. Tugas pertama seorang combat designer adalah menarik kata sifat ini turun menjadi angka.

Bab ini menetapkan di kotak mana angka itu diletakkan. Lima keluaran yang dibuat seorang combat designer masing-masing diletakkan di mana pada Layer, dan mengapa koordinat itu menjadi prasyarat bagi otomatisasi. Alat praktis pada 4.2·4.3·4.4 bergerak di atas koordinat ini.

Satu baris untuk pembaca nonteknis. Anda tidak perlu menghafal nilai tempur atau satuan frame di bagian ini. Satu hal yang perlu Anda bawa pulang hanyalah ini — "Permintaan yang dipertukarkan dengan kata sifat tidak bisa diukur maupun disetel." Gagasan bahwa kolaborasi mulai berjalan begitu "lebih berat lagi" ditarik turun menjadi "apa, sebanyak berapa" berlaku sama persis pada umpan balik kabur di jabatan mana pun di luar game. Lima keluaran pada 4.1.1 cukup dibaca sekilas; Anda boleh melaju cukup dengan menggenggam satu hal ini saja.

4.1.1 Lima Hal di Atas Meja Seorang Combat Designer

Jika keluaran yang menjadi tanggung jawab combat designer diringkas dalam satu baris, itu adalah "seluruh proses ketika input pemain diubah menjadi aksi di layar." Ini dipecah menjadi lima bongkah.

Pertama, spesifikasi Look & Feel tempur. Dokumen yang menerjemahkan hal abstrak seperti hit feel·responsivitas·rasa berat menjadi nilai yang dapat diukur. Ini adalah keluaran tersulit di bidang ini sekaligus menjadi tolok ukur untuk menilai empat keluaran lainnya.

Look & Feel kembali diuraikan menjadi empat sinyal.

• Hit timing — berapa ms dari saat tombol input ditekan hingga reaksi visual·auditori muncul di layar
• Hitstop — berapa frame layar membeku pada saat pukulan mengenai sasaran (umumnya 1\~6 frame)
• Camera shake — amplitudo·durasi·kurva peluruhan
• Sinkronisasi efek — apakah reaksi VFX·SFX·UI terpicu pada frame yang sama

Tanpa spesifikasi ini, adegan ruang rapat itu terulang. Jika spesifikasinya ada, keluarlah instruksi penyetelan seperti "hitstop 3→5 frame, amplitudo camera shake +20%."

Kedua, sistem skill·combo·cancel. Aturan ketika input diubah menjadi aksi.

• Alur penggunaan skill: input → casting → aktivasi → recovery
• Aturan combo: skill mana yang menyambung setelah skill mana, dan apa bonusnya
• Aturan cancel: dari aksi mana ke aksi mana bisa di-cancel
• Input queue: berapa lebar jendela (ms) untuk menerima input berikutnya di tengah aksi

Ketiga, AI karakter·monster. Logika perilaku NPC — Behavior Tree (BT), state machine (FSM (Finite State Machine, mesin status berhingga)/HFSM), tabel keputusan. Pola perilaku monster, transisi fase bos, kerja sama NPC pendamping, dan simulasi gerombolan masuk di sini.

Keempat, rumus damage·sumber daya·cooldown. Matematika ketika pilihan pemain diubah menjadi hasil. Koefisien damage·pengurangan pertahanan·kritikal·koreksi atribut, kurva konsumsi·pemulihan sumber daya (MP/tenaga/stamina), distribusi cooldown.

Kelima, spesifikasi kontrol animasi. Cetak biru yang menentukan bagaimana intent desain tampil di build sebenarnya — graf animasi·BT·penyambungan IK. Ini biasanya kolaborasi dengan programmer·animator, tetapi jika designer tidak menyediakan spesifikasi intent, intent itu rusak di build. Kalau hanya melempar material tanpa memberi cetak biru, rumah yang lain yang akan dibangun.

Inti di sini adalah kelima hal itu bertemu di atas meja yang sama. Jika aturan combo (kedua) berubah, DPS pada rumus damage (keempat) ikut berbeda, dan itu kembali mengubah rasa berat yang dirasakan pada Look & Feel (pertama). Jika tidak dinyatakan secara eksplisit keluaran mana yang menjadi input keluaran mana, satu perubahan akan menggoyang lima tempat. Karena itulah koordinat dibutuhkan.

4.1.2 Di Kotak Mana Lima Keluaran Diletakkan pada Layer

Di atas koordinat L0\~L4 yang ditetapkan pada 2.3, kita letakkan lima keluaran tempur. Pemetaan ini adalah tulang punggung bab ini.

flowchart TD
    L0["L0 · Visi
'Tempur aksi dengan hit feel yang hidup'"]
    L1["L1 · Kerangka sistem
Struktur combo·cancel / Spesifikasi Look&Feel / Kerangka kelas"]
    L2["L2 · Alur konten
Kurva koloni musuh per chapter / Urutan pembukaan skill"]
    L3["L3 · Sheet data
Koefisien damage·nilai cooldown·konsumsi sumber daya"]
    L4["L4 · Pengukuran build
DPS terukur / Jalur combo nyata / Umpan balik pemain"]

    L0 -->|"menerima"| L1
    L1 -->|"kerangka menetapkan alur"| L2
    L1 -->|"spesifikasi jadi tolok ukur nilai"| L3
    L2 --> L3
    L3 -->|"diterapkan ke build"| L4
    L4 -.->|"pengukuran → umpan balik revisi spesifikasi"| L1
    L4 -.->|"pencilan → penyetelan sheet"| L3

    classDef vision fill:#2d3748,stroke:#1a202c,color:#fff
    classDef build fill:#c05621,stroke:#7b341e,color:#fff
    class L0 vision
    class L4 build

Jika dirangkum kembali dalam tabel, hasilnya seperti ini.

Ciri khas combat design adalah bobot L4 lebih besar dibanding bidang lain. Pada desain skenario, spesifikasi L1 hampir langsung menjadi versi final, tetapi tempur berbeda. "Hit feel-nya bagus" adalah wilayah yang baru bisa diketahui dengan memukul langsung dengan tangan di build dan melihat layar. Sekalipun ditulis "hitstop 5 frame" di spesifikasi, apakah itu benar-benar terasa berat hanya terkonfirmasi di L4. Karena itu, alat simulasi dan pengukuran otomatis menciptakan nilai terbesar di bidang ini (4.4).

Namun, bobot L4 yang besar bukan berarti L1 kurang penting. Lihatlah panah garis putus-putus. Nilai pengukuran L4 diumpan balik ke spesifikasi L1. Tanpa spesifikasi, nilai pengukuran kehilangan "tolok ukur untuk dibandingkan." Spesifikasi 5 frame harus ada agar muncul diagnosis "terukur 4 frame, 1 frame hilang." Siklus spesifikasi → build → pengukuran → revisi spesifikasi melewati kelima Layer. Combat designer adalah posisi yang meletakkan tangannya pada seluruh siklus ini, posisi tempat Layer terbanyak berputar serentak di satu meja.

4.1.3 Kata Sifat Menjadi Angka — Satu Tulang Punggung Pekerjaan Nyata

Pembahasan abstrak sampai di sini. Sekarang kita kembali ke adegan ruang rapat dan melihat proses menarik "hit feel-nya lemah" turun menjadi angka secara nyata, melalui worked transcript (rekaman sesi nyata). Alatnya hanya satu LLM. Keluaran tidak dirapikan, dan bagian yang ditolak manusia pun dibiarkan apa adanya.

Saya merekonstruksi alur nyata ketika men-spesifikasi-kan Look & Feel sebuah skill jarak dekat baru, di TF tempur sebuah proyek MMORPG yang saya jalankan sebagai director (selanjutnya "Proyek A").

Prompt (lengkap)

Ubah Look & Feel skill ini dari kata sifat menjadi nilai ms·frame.
Lima item: hit timing, hitstop, camera shake, sinkronisasi efek, recovery.
Yang tidak yakin, tuliskan "perlu diverifikasi di game ini".

Skill: tebasan vertikal greatsword (heavy_overhead_slash)
Intent: "menebas turun dengan berat, dan musuh terasa terhuyung"
Frame rate: 60fps

Keluaran mentah Claude (tidak diringkas·dirapikan)

"Rasa berat" tebasan vertikal greatsword terutama dibentuk oleh panjang hitstop dan recovery, serta peluruhan camera shake. Saya sajikan per item.

1) Hit timing. Semakin berat senjatanya, startup dari input→aktivasi harus semakin panjang agar rasa berat itu hidup. Disarankan 50\~80ms (3\~5 frame) dari input hingga reaksi visual pertama (karakter mulai mengangkat pedang). Namun, reaksi visual pertama dan reaksi pukulan pertama itu berbeda. Hingga pukulan mengenai sasaran bergantung pada panjang motion, jadi tidak bisa dipastikan di sini — perlu diverifikasi dengan panjang motion game ini.

2) Hitstop. Variabel kunci dari satu pukulan yang berat. Jika serangan ringan adalah 1\~2 frame, maka tebasan vertikal greatsword disarankan 4\~6 frame (sekitar 67\~100ms). Jika melewati 6 frame, "berat" beralih menjadi "tersendat" dan responsivitas memburuk.

3) Camera shake. Amplitudo sekitar 1\~2% dari tinggi layar, durasi 0.2\~0.3 detik, peluruhan ease-out (melemah dengan cepat) ketimbang linear. Untuk satu pukulan berat, kurva yang getaran pertamanya kuat lalu mereda dengan cepat terasa wajar.

4) Sinkronisasi efek. VFX (efek pukulan)·SFX (suara pukulan)·hitstop harus dipicu secara identik pada frame mengenai sasaran. Selisih 1\~2 frame saja sudah terasa sebagai "hambar". Reaksi UI (angka damage) boleh terlambat 1\~2 frame.

5) Recovery. Sebagai harga dari rasa berat, recovery menjadi panjang. Disarankan 20\~30 frame (333\~500ms) dari mengenai sasaran hingga kembali bisa terkena serangan. Namun nilai ini sangat berubah-ubah tergantung tempo tempur game secara keseluruhan (aksi cepat vs jenis soul yang berat dan serius) — perlu diverifikasi pada tempo acuan game ini.

Jika dirangkum, "rasa berat = startup panjang + hitstop 4\~6 frame + shake ease-out + VFX/SFX/stop pada frame yang sama + recovery panjang." Namun angka di atas adalah rentang rekomendasi umum, dan rasa berat sebenarnya baru terpastikan setelah dipukul langsung dengan tangan di build dan disetel.

Verifikasi·Penolakan·Permintaan Ulang dari Manusia

Di sini designer tidak mengadopsi keluaran secara utuh. Ia berhenti di dua tempat.

Penolakan 1 — amplitudo camera shake "1\~2% tinggi layar". Game ini mengutamakan mobile. Di layar kecil, 1\~2% nyaris tidak terlihat. Ada juga isu mabuk gerak (motion sickness) di mobile. Designer menolak nilai rekomendasi ini dan menerapkan prinsipnya sendiri: "di mobile, alih-alih shake, rasa berat diekspresikan dengan penekanan hitstop." LLM hanya memberi teori umum; ia tidak tahu kendala platform game ini.

Penangguhan 2 — hitstop "4\~6 frame". Ini bukan penolakan melainkan penangguhan. Sebagai rentang sudah benar, tetapi nilai persisnya ditetapkan dengan rasa tangan di build. Di spesifikasi ditulis "masukkan 4 frame sebagai nilai default ke build, lalu buat varian 5·6 frame dan bandingkan ketiganya dengan tangan."

Permintaan ulang dikirim seperti ini.

Ini proyek yang mengutamakan mobile. Minimalkan camera shake, dan
tulis ulang spesifikasi ke arah mengekspresikan rasa berat dengan
hitstop·recovery·SFX.
Untuk hitstop, buat tabel tiga varian 4/5/6 frame untuk perbandingan build.

Pada keluaran kedua ini, LLM membuat tabel spesifikasi yang mencerminkan kendala mobile. Tabel itu masuk ke build, dan pada rapat build berikutnya designer berkata, alih-alih kata sifat, "varian 4 frame terlalu ringan, adopsi 5 frame." Rapat 40 menit menyusut menjadi keputusan 5 menit.

Apa yang Ditunjukkan Transcript Ini

Ada tiga hal. Pertama, LLM membuat dengan baik draf pertama yang menarik kata sifat turun menjadi rentang angka — inilah yang memecah keheningan ruang rapat. Kedua, LLM tidak tahu kendala game ini (mobile·tempo·panjang motion) — karena itu ia hanya memberi nilai rekomendasi umum, dan penolakan·penyetelan adalah bagian manusia. Ketiga, LLM sendiri menegaskan dua kali "baru terpastikan setelah dipukul langsung dengan tangan di build" — bahkan alat itu tahu bahwa penilaian akhir atas rasa berat ada di tangan manusia di L4.

4.1.4 Empat Tempat AI Memulihkan Nilai Adopsinya

Transcript di atas hanya menunjukkan satu tempat (spesifikasi). Di seluruh combat design, tempat AI menciptakan nilai ada empat.

1) Simulasi — nilai terbesar. Menghitung di muka kurva DPS (Damage Per Second, damage per detik)·jalur combo·konsumsi sumber daya tanpa build. Jauh lebih cepat ketimbang membuat build lalu mengukur dengan tangan. Pada 4.4 ditangani langsung dengan simulator simulate_dps.

2) Pembangkitan otomatis state machine·BT. Mengubah penjelasan bahasa alami seperti "bos ini mengamuk (enrage) di bawah 50% HP, dan saat mengamuk ia memakai pola 3 pukulan beruntun" menjadi diagram BT/FSM. Akurasinya tinggi — struktur aturan adalah wilayah yang ditangani LLM dengan baik. Waktu untuk memindahkan logika dari kepala ke gambar pun hemat.

3) Analisis otomatis tangkapan build. Mengekstrak secara otomatis hit timing·tingkat keberhasilan combo·distribusi damage dari rekaman gameplay. Namun, ini adalah tempat dengan tingkat kesulitan implementasi tertinggi (di bawah kita timbang dengan jujur).

4) Usulan kandidat penyetelan balance. Menganalisis tiap baris sheet data untuk mendeteksi pencilan·ketidakmulusan kurva, lalu mengajukan kandidat penyetelan. Manusia hanya memilih.

Di antara empat tempat ini, analisis otomatis tangkapan build (3) memiliki jarak terjauh antara "bisa dilakukan" dan "bisa dilakukan dengan mudah." Di buku-buku sering ditulis "AI mengekstrak otomatis semuanya dari video", tetapi pada kenyataannya tidak sesederhana itu. Computer vision berbasis piksel video, vision API jadi, log telemetry dalam game — perbandingan akurasi·beban implementasi ketiga metode tangkapan ini, karena 4.4 adalah rujukan resminya, silakan rujuk ke sana. Di sini hanya kesimpulan yang ditegaskan.

Jalur yang paling realistis adalah log telemetry dalam game. Buat engine langsung mencatat event seperti "pada frame 1204 skill_overhead mengenai sasaran, damage 340, hitungan combo 3." Ini akurat karena merupakan data sumber, dan selesai dengan sekali menyisipkan kode logging. LLM dipakai untuk membaca log itu dan meringkasnya menjadi laporan bahasa alami ("hingga combo 3 efisiensi sumber daya bagus, tetapi mulai combo 4 anjlok drastis"). Video disisakan sebagai pendukung di mana manusia hanya memeriksa kasus yang mencurigakan dengan mata.

Artinya, bentuk realistis dari visi "AI menganalisis video secara otomatis" adalah log telemetry + ringkasan LLM, bukan vision piksel. Pembedaan yang jujur ini adalah titik awal pemilihan alat pada 4.4.

Dan ada satu hal yang tidak berubah di keempat tempat. Penilaian akhir atas "hit feel-nya bagus" tidak bisa dilakukan AI. Itu adalah wilayah emosi pemain, dan tanggung jawab atas emosi itu diambil manusia. AI hanya membuat dengan cepat materi dasar bagi penilaian emosi itu. Nilai simulasi, diagram BT, laporan telemetry — semuanya adalah bahan agar manusia mengambil keputusan dengan rasa tangan.

4.1.5 Alasan Sebenarnya Membagi Koordinat — Prasyarat Otomatisasi

Sejauh ini adalah alasan permukaan: "jika keluaran dibagi ke dalam Layer, komunikasi saat berkolaborasi menjadi nyambung." Aturan combo diletakkan di L1 dan sheet damage di L3 dijelaskan karena frekuensi perubahannya berbeda. Itu benar, tetapi bukan itu seluruhnya.

Alasan esensial membagi koordinat adalah karena otomatisasi hanya bekerja di atasnya. Tesis umum bahwa penguraian Layer adalah prasyarat procedural generation·otomatisasi sudah dibahas pada 2.3, jadi di sini kita persempit ke bagaimana prasyarat itu menentukan nasib tiga otomatisasi di bidang tempur.

Pertama, simulasi baru berputar jika "apa yang menjadi input dan apa yang bisa diubah" terpisah. Jika core deterministik (fisika·hitbox — kerangka L1) dan spesifikasi yang dapat diubah (nilai damage·cooldown — sheet L3) bercampur, simulator tidak bisa mendefinisikan "ruang kandidat perubahan". Core tetap, sheet variabel — pemisahan ini harus ada agar simulate_dps melakukan eksplorasi seperti "naikkan koefisien damage dari 280 hingga 340 dengan kelipatan 20 lalu gambarkan kurva DPS".

Kedua, analisis otomatis tangkapan build baru bermakna jika action atom dilabeli. Harus ada atom yang dilabeli pada tataran spesifikasi sebagai "interval frame ini adalah fase hit dari skill_overhead", agar sinyal yang diekstrak dari log telemetry bisa dibandingkan otomatis dengan spesifikasi. Tanpa label, log hanyalah deretan titik tak bermakna berupa "ada sesuatu yang mengenai sasaran pada frame 1204".

Ketiga, pembangkitan urutan combo oleh LLM baru bekerja jika aturan cancel·input queue terpisah ke dokumen eksternal. Permintaan terbatas seperti "usulkan 10 urutan 5-combo dalam 7 pasangan yang bisa di-cancel dari karakter ini dan input queue 200ms" hanya mungkin ketika aturan cancel tidak dipaku ke dalam kode melainkan tertuang sebagai dokumen.

Ketiga hal itu mengucapkan satu kalimat yang sama. Jika core deterministik bercampur dengan spesifikasi, otomatisasi tersumbat; jika terpisah, otomatisasi terbuka. Penguraian Layer secara permukaan bertujuan menyeragamkan bahasa kolaborasi, sedangkan tujuan esensialnya adalah memasang prasyarat bagi simulasi otomatis·analisis tangkapan·eksplorasi urutan LLM.

Dari Penerapan Konservatif ke Penerapan Progresif

Begitu prasyarat ini terpasang, operasional tempur berevolusi dalam dua tahap.

Penerapan konservatif — manusia merancang, otomatis memverifikasi. Sekarang sebagian besar operasional tempur aksi·MMORPG ada di sini. Jika manusia menulis sendiri spesifikasi combo·cancel, otomatis menyimulasikan DPS·sumber daya dan menangkapnya dengan telemetry untuk mengeluarkan laporan perbandingan "spesifikasi vs pengukuran". Manusia menafsirkan selisih itu untuk memutuskan revisi spesifikasi, lalu siklus berputar lagi ke penulisan spesifikasi. Perancangan oleh manusia, simulasi·tangkapan·perbandingan oleh otomatis.

Penerapan progresif — AI mengajukan kandidat, manusia hanya mengadopsi. Ini tahap berikutnya. AI menyebutkan otomatis 10\~30 urutan dalam pasangan cancel dan input queue, otomatis menyimulasikan secara paralel DPS·sumber daya tiap urutan, dan LLM menempelkan peringkat·tafsir seperti "efisiensi sumber daya peringkat 1, kesulitan input sedang". Keputusan yang tersisa di tangan manusia hanyalah satu, "urutan mana di antara kandidat yang diadopsi sebagai signature", plus keputusan director soal penerapan build·motion capture. Membuat urutan dari nol dan memilih dari 30 adalah beban kerja yang berbeda dimensi.

Agar penerapan progresif tertanam, tiga hal harus tersedia. (1) Infrastruktur simulasi deterministik yang menghitung DPS·sumber daya·waktu bertahan dalam 1 detik tanpa build, (2) action atom dengan combo·cancel·input queue yang terpisah·terlabel ke dokumen eksternal, (3) analisis otomatis tangkapan berbasis telemetry. Ketiganya sama-sama merupakan hasil langsung dari penguraian Layer yang disebut di atas.

Motion Capture adalah Tahap Tidak Dapat Dibalik — Decision Gate

Terakhir, soal keterbalikan. Dalam siklus tinjauan seorang combat designer tercampur tahap yang dapat dibalik dan yang tidak, dan mengetahui batasnya itu penting.

Motion capture adalah tahap tidak dapat dibalik yang paling tebal dalam tempur. Jadwal studio capture, perekrutan aktor, biaya syuting ulang semuanya besar. Karena itu, motion capture aksi signature hanya dijalankan setelah simulasi·analisis otomatis tangkapan berputar cukup baik sehingga urutannya terpastikan. Konservatif maupun progresif, motion capture dan tepat sebelum build live diletakkan sebagai decision gate. Semua tinjauan seorang combat designer harus berakhir di tahap yang dapat dibalik di sisi kiri gate ini agar aman.

4.1.6 Pemandangan di Perusahaan — Apa yang Berkurang

Ini adalah perubahan yang diukur TF tempur Proyek A selama mengoperasikan koordinat dan alat di atas selama 6 bulan. Nilai di bawah adalah rata-rata kasar yang diambil dari catatan operasional TF, dan akan lebih akurat dibaca sebagai arah perubahan yang dirasakan, bukan sebagai nilai pengukuran presisi.

Yang lebih inti dari angka itu sendiri adalah arahnya. Keempat item sama-sama berpindah dari "diskusi subjektif·pengukuran manual·pengulangan build" ke "otomatisasi nilai terukur·simul·diagram". Di ruang rapat, kata sifat berkurang dan angka bertambah. Itulah satu kalimat yang ingin disampaikan seluruh bab ini — pekerjaan seorang combat designer adalah memasang jembatan yang berpindah dari subjektivitas (hit feel·keseruan) ke objektivitas (nilai·simulasi), dan AI adalah alat yang memasang jembatan itu dengan cepat. Di ujung jembatan, tangan yang memutuskan "ini berat" tetaplah milik manusia.

Poin-Poin Penting

• Combat design adalah posisi tempat Layer terbanyak berputar serentak di satu meja, dari spesifikasi L1, sheet L3, hingga pengukuran build L4.
• Penguraian Layer secara permukaan menyeragamkan bahasa kolaborasi, tetapi esensinya adalah prasyarat otomatisasi berupa simulasi·tangkapan·eksplorasi LLM.
• Penilaian akhir atas "hit feel-nya bagus" adalah bagian manusia, dan AI membuat dengan cepat materi dasar bagi penilaian itu.

Coba Sendiri — Menarik Kata Sifat Turun Menjadi Angka

setup. Satu LLM saja cukup. Pilihlah satu skill yang ada di tangan Anda (baru maupun lama). Tuliskan intent skill itu dalam satu baris kata sifat — seperti "berat", "gesit", "tumpul-berat".

prompt. Isilah kerangka di bawah dengan informasi skill.

Kamu adalah asisten combat design. Ubahlah Look & Feel skill di bawah
menjadi "spesifikasi nilai yang dapat diukur". Bukan kata sifat, melainkan
satuan ms·frame·%.
Untuk item yang tidak yakin, nyatakan "perlu diverifikasi di game ini".

Skill: [nama]
Intent: "[satu baris kata sifat]"
Frame rate: [60fps dll]
Item: 1)hit timing 2)hitstop 3)camera shake 4)sinkronisasi efek 5)recovery

verify. Lemparkan dua pertanyaan pada setiap angka di keluaran. (1) Apakah nilai ini tepat di bawah kendala game ini (platform·tempo·panjang motion)? → Kalau tidak tepat, beri tahu kendalanya dan minta ulang. (2) Apakah nilai ini harus dipastikan dengan tangan di build? → Kalau ya, alih-alih nilai tunggal, tulis 2\~3 varian di spesifikasi lalu bandingkan di build. Item yang ditegaskan LLM sebagai "perlu diverifikasi" jangan sekali-kali diadopsi apa adanya.

4.1.7 Versi Ringkas Solo

Kalau game yang Anda buat sendirian, Anda tidak perlu melengkapi seluruh lima keluaran·lima Layer. Lakukan minimal dua hal saja. Satu, spesifikasi Look & Feel satu halaman — untuk 3\~5 aksi inti, tulis hitstop·recovery·sinkronisasi saja dalam angka. Memo yang ditulis dengan kata sifat tidak akan dikenali pun oleh diri Anda sendiri 6 bulan kemudian. Dua, pisahkan combo·cancel dari kode menjadi satu file — kalau pasangan cancel Anda keluarkan menjadi data, nanti Anda bisa menyuruh LLM "usulkan 5 combo yang bisa dibuat dengan pasangan ini." Kedua hal ini adalah koordinat minimal yang membiarkan pintu otomatisasi tetap terbuka bahkan di pengembangan solo.

4.2 Look & Feel Pertarungan — Tempat Menangkap Game Feel dengan Data

Lima orang berkumpul di depan monitor ruang rapat. Build yang sama, skill yang sama, klip 30 detik yang sama sedang diputar ulang untuk ketiga kalinya di layar. Programmer client yang pertama membuka suara. "Buat saya sih oke." Penanggung jawab art melipat tangan. "Lemah. Rasanya ada yang kurang." Game Designer di sebelahnya menyela. "Efeknya bagus, tapi enggak nempel di tangan." Direktur memandang lama, lalu mengambil keputusan. "Hmm… kita buat sedikit lebih berbobot ya."

Lalu rapat selesai. 'Sedikit lebih berbobot' itu tepatnya berapa ms dan berapa frame, tidak ada yang mencatatnya. Di build berikutnya programmer mengimplementasikan 'rasa berbobot' versi pemahamannya sendiri, dan art menempelkan 'rasa berbobot' versi pemahamannya sendiri. Lalu minggu depan, di ruang rapat yang sama, sambil menonton klip yang sama, percakapan yang sama berulang lagi.

Game feel, sensasi di tangan, Look & Feel. Inilah kata yang paling sering dipakai sekaligus paling tidak terdefinisi dalam desain pertarungan. Semua orang yakin mereka paham, tetapi definisi di kepala masing-masing berbeda-beda, sehingga setelah diskusi selesai, tidak ada yang tersisa. Bab ini membahas pekerjaan memecah 'rasa' itu menjadi angka yang dapat diukur. Inilah tempat menarik turun game feel dari ranah abstrak menjadi data.

4.2.1 Pertarungan = Look & Feel, Sistem = Cara Kerja

Pertama-tama saya akan menarik batasnya lebih dahulu. Desain pertarungan terbagi menjadi dua cabang besar.

• Sistem pertarungan: bagaimana ia bekerja. Rumus damage, cooldown, akumulasi stack, aturan status effect. Ini ranah bab berikutnya (4.3 Combo·Cancel, 4.4 Simulasi AI).
• Look & Feel pertarungan: bagaimana ia terasa. Setelah tombol ditekan, kapan layar bereaksi, seberapa lama layar berhenti pada momen tepat sasaran, apakah efek, suara, dan getaran meletus pada momen yang sama.

Bab ini hanya membahas yang kedua. Apakah damage-nya 100 atau 120, tidak berhubungan langsung dengan game feel. Bagaimana pemain merasakan 'momen masuknya' damage 100 itulah yang disebut game feel. Dengan rumus damage yang sama pun, bila timing hit dan hit stop-nya berbeda, game-nya akan terasa benar-benar berbeda.

Pertama, ada hal yang ingin saya tegaskan secara jujur. Game feel tidak selesai hanya dengan tiga angka. Kurva akselerasi·deselerasi dari motion serangan (animasi), reaksi pihak yang terkena (hit reaction·stagger), hingga deformasi (déformer — ekspresi afterimage·distorsi yang melebih-lebihkan karakter dengan meregangkan dan memenyekkannya pada momen pukulan) yang gemar dipakai game action Jepang era 80\~90-an — semuanya harus berkumpul agar sensasi "kena" berdiri sebagai satu kesatuan. Yang dipusatkan bab ini untuk ditarik turun menjadi angka yang dapat diukur adalah tiga sumbu di antaranya. Motion·reaction·deformasi adalah ranah yang lebih banyak disentuh tangan animator·artist, sehingga dibahas di bab-bab berikutnya dan di bagian art; di sini saya menaruh bobot pada tiga sumbu yang dapat dikunci oleh Game Designer sebagai spesifikasi dan diverifikasi di build. Ketiga sumbu itu terbagi seperti ini.

Ketika seseorang di ruang rapat berkata "lemah", kelemahan itu berasal dari salah satu dari ketiganya. Apakah responsnya terlambat (timing), apakah tidak ada sensasi kena (hit stop), atau apakah semuanya bermain sendiri-sendiri (sinkronisasi)? Bila kita memecahnya menjadi tiga sumbu lalu bertanya, barulah 'lemah' menjadi kalimat yang dapat diperbaiki.

Namun penyebab 'lemah' tidak selalu hanya ada pada ketiga sumbu ini. Saya menjabarkan elemen-elemen pembentuk game feel tanpa terlewat, lalu menarik garis sampai sejauh mana bab ini bertanggung jawab.

Keempat yang di atas terikat menjadi tiga sumbu bab ini dan menjadi objek pengukuran·spesifikasi, sedangkan ketiga yang di tengah (motion·reaction·deformasi) tidak boleh hilang namun merupakan ranah art·animasi yang sulit dikunci sendirian oleh Game Designer dengan angka, sehingga saya hanya menegaskan dengan jelas 'bahwa mereka ada'. Bila motion-nya kaku atau pihak yang terkena tetap berdiri tanpa goyah, game feel tidak akan hidup meski ketiga sumbu sudah pas semua.

4.2.2 Timing Hit — Dari Input sampai Reaksi

Ada alasan mengapa di antara tiga sumbu, timing yang pertama dibahas. Ketika pemain meragukan game feel, hal pertama yang tersangkut adalah sensasi 'reaksinya terlambat', dan sehebat apa pun yang lain, bila input-nya lamban, pada momen itu semuanya runtuh. Karena itu kita tangkap timing lebih dahulu.

Sumbu pertama game feel adalah waktu. Dari momen tombol ditekan (0ms) sampai momen layar pertama kali bereaksi, berapa ms yang dibutuhkan. Manusia luar biasa peka terhadap jeda ini. Selisih antara 60ms dan 120ms 'tidak bisa dijelaskan dengan kata-kata, tapi tangan tahu'.

Satu kali serangan bukanlah satu titik sederhana, melainkan beberapa peristiwa yang terbentang di atas sumbu waktu. Bila kita meletakkan 1 hit Basic Attack (serangan dasar) di atas sumbu waktu, bentuknya seperti ini.

Angka terpenting dalam gambar ini adalah '100ms saat hitbox pertama kali menyala'. Artinya, 100ms setelah tombol ditekan, deteksi serangan dimulai. Nilai inilah yang menentukan kecepatan game feel yang dirasakan.

Rentang yang dianjurkan berbeda menurut genre·karakter, tetapi ada garis acuan kasar.

Rentang ini bukan acuan mutlak. Sebagai perkiraan penulis (belum terverifikasi), mobile kasual cenderung bergeser ±50ms ke arah input yang lebih longgar, sedangkan konsol fighting cenderung dikencangkan lebih ketat. Yang inti bukan angkanya sendiri, melainkan tim berbagi garis acuan 'serangan ringan game kita, kita sepakati di 90ms'. Garis acuan harus ada agar kita bisa berkata 'benar/salah' setelah melihat build.

Namun di sini ada satu jebakan. Mata manusia tidak bisa membedakan 90ms dan 110ms. Pada 60fps, 1 frame kira-kira 16.67ms, dan selisih 20ms ini hanya sekitar satu frame. Apakah ucapan "kok rasanya agak lambat ya?" di ruang rapat benar atau salah, dengan mata akhirnya tidak bisa diputuskan. Karena itu pengukuran dibutuhkan.

4.2.3 Bagaimana Menarik Timing dari Build — Perbandingan yang Jujur

Di spesifikasi sudah saya tulis 'hitbox 100ms'. Bagaimana memastikan di build ia benar-benar menyala pada 100ms? Jalur otomasi terbagi tiga (analisis video·tool vision siap-pakai·telemetry dalam game), dan perbandingan presisi·tingkat kesulitan ketiga cara itu dibahas secara baku di 4.4. Di sini saya hanya menegaskan kesimpulannya. Yang harus paling pertama dipasang di praktik adalah telemetry dalam game. Alasannya sederhana. Dibandingkan menyimpulkan dari video 'frame saat VFX muncul' di layar, jauh lebih akurat dan murah bila kode langsung mencetak satu baris [HITLOG] pada frame ketika event OnHit dipicu. Analisis video dipakai untuk video eksternal yang tidak punya overlay input (misalnya analisis game pesaing), dan untuk build kita sendiri, telemetry dipasang lebih dahulu.

Log telemetry bentuknya seperti ini.

[HITLOG] frame=6  t_ms=100  evt=hitbox_on    skill=1001 char=warrior
[HITLOG] frame=6  t_ms=100  evt=vfx_trigger  skill=1001
[HITLOG] frame=6  t_ms=100  evt=sfx_trigger  skill=1001
[HITLOG] frame=7  t_ms=117  evt=damage_apply skill=1001 dmg=124
[HITLOG] frame=7  t_ms=117  evt=ui_dmgnum    skill=1001
[HITLOG] frame=6  t_ms=100  evt=cam_shake    skill=1001 amp=0.4

Yang harus dilakukan Game Designer adalah mencocokkan log ini dengan spesifikasi baris demi baris. Karena sebagian besar berupa konversi angka dan pencocokan mekanis, manusia akan lelah dan salah bila mengulanginya dengan mata, tetapi LLM tidak lelah. Di bagian berikut saya akan benar-benar menyuruhnya melakukannya.

4.2.4 Worked Transcript — Mencocokkan Log Telemetry dengan Spesifikasi

Saya menempelkan kedua-duanya — yaml spesifikasi dan log telemetry build — lalu menyuruh AI mencocokkan keduanya untuk menemukan tempat yang menyimpang. Di bawah ini adalah teks penuh prompt, keluaran mentah Claude, dan seluruh proses verifikasi manusia. Saya pindahkan apa adanya tanpa meringkas.

Prompt Pertama

Berikut adalah 'spesifikasi timing hit' dari satu skill pertarungan, dan
log telemetry yang ditarik dari build nyata. Rangkumlah dalam tabel item-item
di mana build menyimpang dari spesifikasi.

[Spesifikasi]
character: warrior
skill_id: 1001
fps: 60
events:
  hitbox_on:    {expect_ms: 100, tol_frame: 0}
  vfx_trigger:  {expect_ms: 100, tol_frame: 0}
  sfx_trigger:  {expect_ms: 100, tol_frame: 1}
  damage_apply: {expect_ms: 110, tol_frame: 1}
  ui_dmgnum:    {expect_ms: 100, tol_frame: 2}
  cam_shake:    {expect_ms: 100, tol_frame: 1}

[Log telemetry]
[HITLOG] frame=6  t_ms=100  evt=hitbox_on    skill=1001
[HITLOG] frame=6  t_ms=100  evt=vfx_trigger  skill=1001
[HITLOG] frame=8  t_ms=133  evt=sfx_trigger  skill=1001
[HITLOG] frame=7  t_ms=117  evt=damage_apply skill=1001
[HITLOG] frame=9  t_ms=150  evt=ui_dmgnum    skill=1001
[HITLOG] frame=6  t_ms=100  evt=cam_shake    skill=1001

60fps (1 frame=16.67ms). Konversi expect_ms ke frame, bandingkan dengan
frame pada log, dan bila selisihnya melampaui tol_frame, tandai sebagai FAIL.

Keluaran Mentah Claude (apa adanya)

Pertama saya akan mengonversi expect_ms dari spesifikasi menjadi frame. Pada 60fps, frame = round(ms / 16.67).

• hitbox_on: 100 / 16.67 ≈ 6.0 → frame 6
• vfx_trigger: 100 → frame 6
• sfx_trigger: 100 → frame 6
• damage_apply: 110 / 16.67 ≈ 6.6 → frame 7 (dibulatkan)
• ui_dmgnum: 100 → frame 6
• cam_shake: 100 → frame 6

Berikut hasil perbandingan dengan frame aktual pada log.

Event	Frame harapan	Frame aktual	Selisih (frame)	Toleransi	Putusan
hitbox_on	6	6	0	0	PASS
vfx_trigger	6	6	0	0	PASS
sfx_trigger	6	8	+2	1	FAIL
damage_apply	7	7	0	1	PASS
ui_dmgnum	6	9	+3	2	FAIL
cam_shake	6	6	0	1	PASS

Dua item melampaui toleransi. - sfx_trigger: suara terlambat 2 frame (sekitar 33ms) dari hit visual. Melebihi toleransi 1 frame. Pemain kemungkinan besar akan merasa "suaranya sedikit bermain sendiri". - ui_dmgnum: angka damage muncul terlambat 3 frame (sekitar 50ms). Melebihi toleransi 2 frame. Bisa berujung pada kejanggalan "sudah kena tapi angkanya muncul telat".

damage_apply berada di frame 7 sesuai spesifikasi frame 7 (konversi 110ms), jadi normal. Namun, apakah damage_apply yang berada 1 frame setelah hitbox_on (frame 6) merupakan desain yang disengaja perlu dikonfirmasi.

Verifikasi Manusia — Menolak Satu Kolom

Setelah menerima keluaran, saya tidak langsung mempercayai semuanya. Ada dua titik verifikasi.

Verifikasi 1 (batas pembulatan — lolos). Konversi 110ms pada damage_apply mencurigakan. 110 / 16.67 = 6.598… Bila dibulatkan, 7 memang benar. Tetapi bagaimana bila maksud spesifikasi adalah '6 frame = frame yang sama dengan 100ms'? Setelah saya periksa langsung, ternyata di spesifikasi memang ada damage_apply: expect_ms 110 yang sengaja memberi selisih 10ms dari vfx (100). Jadi konversi ke frame 7 itu akurat. AI lolos.

Verifikasi 2 (kalimat terakhir — ditolak). Tambahan AI di akhir, "apakah damage_apply yang berada 1 frame setelah hitbox_on merupakan desain yang disengaja perlu dikonfirmasi", adalah noise. Padahal di spesifikasi maksudnya sudah ditegaskan dengan expect_ms 110, tetapi AI malah membaliknya menjadi 'perlu dikonfirmasi'. Bila spesifikasi sudah diberikan, jawaban harus ditutup di dalam spesifikasi, tetapi AI malah memunculkan pertanyaan yang tidak perlu. Kalimat ini tidak saya pakai.

Saya mengajukan permintaan ulang sambil memuat alasan penolakan.

Prompt Kedua (Permintaan Ulang)

damage_apply sudah dikunci dengan maksud 110 di spesifikasi, jadi buang komentar 'perlu dikonfirmasi'.
// maksudnya: jangan menanyakan ulang item yang jawabannya sudah tertutup di dalam spesifikasi
Sisakan hanya dua FAIL (sfx, ui_dmgnum), dan alih-alih memvonis penyebab,
berikan sebagai checklist 'lokasi kode/resource yang perlu dicek'.

Keluaran Kedua Claude (apa adanya)

Berikut checklist konfirmasi untuk dua FAIL. Saya tidak memvonis penyebab, hanya merapikan titik-titik yang perlu dicek.

sfx_trigger (jeda +2 frame) - [ ] Apakah trigger suara terikat (binding) pada event yang sama dengan hitbox_on, atau tergantung pada animation notify terpisah - [ ] Apakah ada leading silence pada aset audio itu sendiri — bagian kosong di awal file bisa terlihat seolah jeda - [ ] Apakah panggilan pemutaran suara masuk pada frame yang sama tetapi terdorong oleh latency keluaran (buffer audio platform)

ui_dmgnum (jeda +3 frame) - [ ] Apakah UI angka damage memiliki struktur yang diperbarui di tick terpisah setelah damage_apply (frame 7) - [ ] Apakah pembaruan UI diproses sekaligus di akhir frame berikutnya (queue render tertunda) - [ ] Apakah ada nilai delay tambahan yang dimasukkan ke frame awal animasi pop-up angka

Yang dapat dipastikan: kedua item melampaui toleransi spesifikasi dan terlambat dari hit visual (frame 6). Yang tidak dapat dipastikan: mana di antara penyebab di atas yang sebenarnya, tidak dapat diketahui sebelum kode/aset diperiksa.

Keluaran kedua ini saya pakai apa adanya. Tidak mengarang penyebab dan mengubahnya menjadi 'tempat yang perlu dicek' persis bentuk yang saya inginkan. Checklist ini saya serahkan apa adanya kepada penanggung jawab sound dan penanggung jawab UI, dan ternyata pelaku pada sound adalah leading silence 33ms di awal aset audio (item nomor 2 di checklist). UI ternyata berstruktur pembaruan di frame berikutnya (item nomor 1).

Di sinilah garis pembagian kerja menjadi jelas. AI mencocokkan spesifikasi dan log secara mekanis untuk menangkap FAIL, dan manusia (a) menolak pertanyaan-balik yang tidak perlu yang dibuat AI serta (b) memastikan penyebab FAIL yang sebenarnya di dalam kode. Bila AI disuruh memvonis penyebab, ia akan mengarang kebohongan yang tampak masuk akal, sehingga lebih aman menyuruhnya hanya sampai 'tempat yang perlu dicek'.

4.2.5 Hit Stop — Bobot Pukulan

Sumbu kedua adalah penghentian. Efek menghentikan waktu game sangat singkat atau memperlambatnya pada momen hit tepat sasaran. Inilah yang menentukan kekuatan sensasi "kena". Inilah perkakas game feel terkuat dalam game fighting dan action RPG. Bila terlalu panjang terasa menjemukan, bila terlalu pendek tidak ada bobot.

Rentang yang dianjurkan (berbasis 60fps) adalah sebagai berikut. Angka ini adalah konvensi kasar yang lazim dipakai di game action, dan nilai absolutnya disesuaikan per game.

Harus diberikan berbeda per karakter·skill. Bila semuanya diberi sama, selisih bobot tidak muncul, dan akhirnya semua serangan konvergen ke nada yang sama. Inilah titik yang menyambung ke salah satu dari tiga poin penting 4.2.

'Siapa yang berhenti' juga merupakan pilihan desain.

Spesifikasinya diinput seperti ini.

character: warrior
skill_id: 1001
hit_stop:
  attacker: 2          # frames
  victim: 4
  critical_multiplier: 1.5   # 1.5 kali saat critical (dibulatkan)

Hit stop adalah sumbu yang paling pelik dalam verifikasi game feel, yang 'benar/salah'-nya tidak bisa selesai hanya dengan angka spesifikasi. Dengan telemetry, 'apakah benar-benar berhenti 4 frame' bisa ditangkap, tetapi 'apakah 4 frame itu tepat' harus diputuskan manusia dengan menyentuh build secara langsung. AI menjamin kesesuaian dengan spesifikasi, dan manusia menilai ketepatan dari nilai spesifikasi itu sendiri.

4.2.6 Sinkronisasi Efek — Apakah Semuanya Meletus di Frame yang Sama

Sumbu ketiga adalah keserempakan. Bila VFX (efek visual)·SFX (suara)·UI (angka damage)·kamera (shake)·getaran (controller) dimulai pada frame yang sama, otak pemain mengikatnya sebagai 'satu peristiwa'. Menyimpang 1\~2 frame saja sudah muncul reaksi "janggal", menyimpang 3\~5 frame muncul reaksi "kayak bug". Pada worked transcript sebelumnya, sfx yang terlambat 2 frame dan ui yang terlambat 3 frame hingga FAIL adalah persis masalah pada sumbu ini.

Berikut 5 objek sinkronisasi beserta toleransinya.

Intinya, kelima jenis ini semuanya harus masuk ke spesifikasi. Kesalahan yang lazim adalah hanya menulis VFX di spesifikasi dan membiarkan keempat sisanya dengan asumsi 'nanti juga menyesuaikan sendiri'. Bila tidak ada di spesifikasi, acuan verifikasi build pun tidak ada, dan meski ditangkap dengan telemetry, tidak ada objek untuk dibandingkan. Kelima jenis harus ada di spesifikasi agar perbandingan otomatis tertutup.

Untuk perbandingan otomatis, worked transcript di bagian sebelumnya berlaku apa adanya. Bila frame trigger kelima jenis tercetak lengkap di log telemetry, AI mencocokkannya dengan spesifikasi dan hanya melaporkan item yang melampaui toleransi. Manusia tidak perlu memeriksa 100 skill dengan mata setiap build. Namun, AI menangkap penyimpangan spesifikasi dan manusia menangkap ranah "spesifikasinya benar semua tapi rasanya tetap belum hidup" tetap menjadi dua hal yang terpisah.

4.2.7 Dari Spesifikasi sampai Build Berikutnya — Loop Keseluruhan

Saya menyambung potongan-potongan sejauh ini menjadi satu alur. Begitu loop ini mulai berputar, 'sedikit lebih berbobot' dari ruang rapat diterjemahkan menjadi 'hit stop victim 4→6 frame'.

flowchart TD
    A["Menulis spesifikasi
(Game Designer: yaml)"] --> B["Implementasi build
(programmer·artist)"]
    B --> C["Eksekusi build + log telemetry
[HITLOG] output otomatis"]
    C --> D["Pencocokan otomatis AI
spesifikasi yaml vs telemetry"]
    D --> E{"Ada FAIL
melampaui toleransi?"}
    E -->|Ada| F["Item FAIL + checklist konfirmasi
(AI, dilarang memvonis penyebab)"]
    F --> G["Penanggung jawab memastikan penyebab
sebenarnya di kode·aset (manusia)"]
    G --> B
    E -->|Tidak ada| H["Game Designer: tinjauan 'rasa'
spesifikasi pas tapi apakah ada game feel (manusia)"]
    H -->|Perlu penyesuaian| A
    H -->|OK| I["Disimpan sebagai input retrospektif milestone berikutnya"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class C code;
    class D,F ai;
    class A,G,H human;
    class I pass;

Dalam loop ini, kolom yang dipegang AI (D, F) dan kolom yang dipegang manusia (A, G, H) terbagi dengan jelas. AI kuat dalam pencocokan mekanis dan pembuatan checklist, sedangkan manusia kuat dalam penetapan garis acuan·pemastian penyebab·penilaian sensasi akhir. Otomasi bukan menyingkirkan manusia, melainkan membebaskan manusia dari 'menghitung frame dengan mata' yang sebelumnya menghabiskan setengah hari setiap kali, agar bisa berfokus hanya pada 'rasa'.

Kolom terakhir loop (I) itu penting. Data pengukuran ini bukan dipakai sekali lalu dibuang, melainkan masuk lagi sebagai input retrospektif milestone berikutnya. Bila pola seperti 'FAIL game feel kuartal lalu terpusat pada sinkronisasi sfx' tersimpan sebagai data, di kuartal berikutnya pipeline audio yang lebih dulu dibenahi.

4.2.8 Tempat Pengukuran Mengurangi Diskusi — Observasi Operasional

Pada sebuah proyek mobile MMORPG tempat penulis terlibat sebagai direktur (selanjutnya 'Proyek A'), inilah perubahan yang saya amati selama memutar loop di atas sekitar 6 bulan. Angka di bawah ini bukan pengukuran presisi, melainkan observasi operasional penulis (termasuk perkiraan) berdasarkan timestamp notula rapat dan catatan verifikasi build, jadi mohon dibaca sebagai arah dan rasio. Jangan dipakai sebagai benchmark yang dapat dikutip dengan nilai absolutnya.

Yang esensial bukan angkanya sendiri, melainkan perubahan kualitatif. Begitu "lemah nih" muncul di ruang rapat, langsung bisa membalas bertanya "sumbu yang mana? timing? hit stop? sinkronisasi?", dan bila jawabannya tak kunjung muncul, kami menampilkan telemetry bersama-sama. Bahwa objektivitas yang dapat diukur menciptakan titik akhir bagi diskusi adalah perubahan terbesar dalam 6 bulan. 'Sedikit lebih berbobot' makin jarang keluar dari ruang rapat.

4.2.9 Kesalahan Lazim dan Cara Menghindarinya

Coba Sendiri

Berikut prosedur untuk memasang loop ini ke proyek Anda sendiri dalam skala paling minimal.

setup 1. Pilihlah 1 skill yang akan diverifikasi (Basic Attack dianjurkan). 2. Tanam satu baris log di 6 titik trigger pada kode (hitbox_on, vfx, sfx, damage_apply, ui_dmgnum, cam_shake): [HITLOG] frame=X t_ms=Y evt=... skill=.... 3. Tulislah yaml spesifikasi (expect_ms + tol_frame pada blok events). Gunakan contoh prompt pertama di bab ini sebagai template.

prompt 4. Jalankan build sekali untuk mengumpulkan log telemetry. 5. Tempelkan yaml spesifikasi + log telemetry bersama ke AI dan suruh seperti ini: "Cocokkan item-item di mana build menyimpang dari spesifikasi dengan konversi frame 60fps, dan berikan hanya FAIL dalam tabel. Jangan memvonis penyebab, berikan sebagai checklist 'tempat yang perlu dicek'." (bentuk prompt kedua di bab ini)

verify 6. Periksa-ulang sendiri satu kolom konversi frame dari keluaran AI (ms / 16.67 dibulatkan). Bila satu kolom saja salah, curigailah keseluruhannya. 7. Bila AI menanyakan ulang item yang sudah tertutup di dalam spesifikasi atau memvonis penyebab, tolak dan ajukan permintaan ulang. 8. Serahkan checklist FAIL ke penanggung jawab untuk memastikan penyebab sebenarnya di kode·aset.

Versi Ringkas Solo

Bila Anda developer solo tanpa tim maupun infrastruktur telemetry, perkecil seperti ini. Rekam layar build pada 60fps, dan nyalakan overlay input tombol agar momen input terlihat. Setelah merekam satu kali skill yang akan diverifikasi, di editor video hitung langsung 'frame saat tombol ditekan' dan 'frame saat layar pertama berubah'. Berikan kedua nomor frame dan nilai harapan spesifikasi ke AI lalu suruh "konversi ke ms berbasis 60fps dan bandingkan dengan spesifikasi", maka satu sumbu inti (timing hit) bisa diverifikasi bahkan tanpa telemetry. Sinkronisasi 5 jenis memang sulit, tetapi dengan menangkap satu sumbu 'input→reaksi' saja, separuh diskusi game feel sudah berpindah ke ranah objektif.

Bab berikutnya beralih dari satu kali hit ke rangkaian hit-hit. Combo·cancel·input queue — membahas aturan-aturan yang membuat satu hit tersambung secara alami ke hit berikutnya.

Poin-Poin Penting

• Game feel adalah jumlah dari tiga sumbu timing hit·hit stop·sinkronisasi efek, sehingga bila hanya satu sumbu disentuh, sisanya ikut goyah.
• Log telemetry dalam game lebih akurat dan murah ketimbang analisis video — build kita dari telemetry lebih dulu.
• AI menangkap FAIL lewat pencocokan spesifikasi, dan manusia menolak pertanyaan-balik serta memastikan penyebab di kode.

Pratinjau Bab Berikutnya

• 4.3. Combo·Cancel·Input Queue

4.3 Kombo, Cancel, dan Input Queue — Mengenumerasi dan Memverifikasi Setiap Jalur

Rekan tim B, seorang combat designer, berdiri di depan papan tulis ruang rapat sambil menggambar kotak dengan spidol. Dasar 1, dasar 2, dasar 3, lalu cabang serangan berat (heavy) yang mengarah ke samping. Ketika panah sudah bertambah hingga sekitar tujuh buah, seseorang bertanya, "Jadi, setelah heavy launch, kalau di-cancel dengan dodge, apakah bisa kembali lagi ke dasar 1?" Rekan B menghentikan spidolnya. Pada graf di papan tulis itu, jalur tersebut tidak tergambar. Apakah jalur itu bisa digambar tapi tidak digambar, atau memang tidak mungkin secara aturan — bahkan ia sendiri tidak bisa menjawab seketika.

Inilah masalah sebenarnya dalam desain kombo. Di dalam kepala, kombo tampak seperti satu untaian sederhana: "1-2-3 tersambung, lalu bercabang ke heavy." Tetapi begitu cancel dan input queue ikut masuk, untaian itu berubah menjadi graf. Cukup dengan enam node, tambahkan beberapa edge cancel saja, dan jumlah jalur yang benar-benar bisa dilewati membengkak menjadi puluhan cabang. Manusia tidak bisa membentangkan puluhan cabang itu sekaligus di dalam kepala. Itulah sebabnya pemikiran balancing semacam "jalur ini terlalu kuat" baru ditemukan setelah masuk ke dalam build.

Tujuan bab ini hanya satu: membuat alur kerja yang mengenumerasi seluruh jalur kombo secara otomatis tanpa menggambarnya dengan tangan, lalu memverifikasi setiap jalur. Aturan yang ditulis dalam bahasa alami diubah menjadi spesifikasi, jalur dienumerasi dari spesifikasi, dan jalur yang sudah dienumerasi dimasukkan ke dalam simulasi. Dalam proses itu, saya akan menunjukkan apa adanya — sampai sejauh mana AI membantu, dan di titik mana ia berbohong.

4.3.1 Kombo Bukan Tabel, Melainkan Graf

Kalau kombo ditulis sebagai tabel, hasilnya seperti ini. "Setelah dasar 1, dasar 2; setelah dasar 2, dasar 3." Rapi dalam baris dan kolom. Namun tabel ini berbohong, karena tabel mengasumsikan garis lurus. Dalam pertarungan nyata, pemain keluar dari dasar 2 menuju heavy, men-cancel heavy dengan dodge, lalu tepat setelah dodge menekan dasar 1 lagi. Percabangan dan perulangan ini tersembunyi di antara baris-baris tabel.

Karena itu, wujud kombo yang sebenarnya adalah graf berarah (directed graph). Aksi adalah node, sambungan adalah edge. Pada setiap edge melekat input window (kapan input diterima) dan tombol input. Pada node melekat frame durasi, dan pada sebagian node melekat kondisi bonus (pengali damage baru muncul kalau melewati node tertentu).

Kalau satu set kombo dasar karakter prajurit (warrior) digambar sebagai graf, hasilnya seperti berikut. Enam node, termasuk cabang cancel.

Ada dua perbedaan mendasar dibanding papan tulis. Pertama, pada setiap edge dicantumkan rentang frame input window-nya. "Heavy 6\~24f" berarti input heavy diterima mulai frame ke-6 sampai frame ke-24 setelah dasar 2 dimulai. Kedua, ada edge masuk-ulang dodge→dasar 1 yang digambar dengan garis putus-putus. Itulah jalur yang tidak bisa dijawab seketika oleh rekan B di ruang rapat. Begitu dicantumkan dalam graf, "ada/tidak ada" menjadi jelas.

Kalau graf ini digambar manusia dengan tangan, hanya enam node dengan tujuh-delapan edge. Tetapi kalau ada dua puluh karakter dan tiap karakter punya tiga-empat set kombo, grafnya menjadi ratusan lembar. Tangan tidak bisa mengikutinya. Karena itu graf ditulis sebagai spesifikasi teks, lalu gambar dan verifikasi dibangkitkan secara otomatis dari situ.

4.3.2 Spesifikasi Dibaca Manusia, tapi Diuraikan Mesin

Graf di atas dipindahkan ke spesifikasi YAML. Intinya tiga blok: node (nodes), edge (edges), dan bonus (bonuses). Aturan cancel pun dianggap sebagai satu jenis edge — karena memutus lalu berpindah ke node lain pada akhirnya juga adalah edge.

# warrior_basic_chain.yaml
character: warrior
combo_id: basic_chain

nodes:
  - { id: basic_1,  name: Dasar 1,  duration_frames: 21 }
  - { id: basic_2,  name: Dasar 2,  duration_frames: 24 }
  - { id: basic_3,  name: Dasar 3,  duration_frames: 30 }
  - { id: heavy,    name: Heavy,    duration_frames: 33 }
  - { id: launch,   name: Launch,   duration_frames: 28 }
  - { id: dodge,    name: Dodge,    duration_frames: 18, cancels_recovery: true }

edges:
  - { from: basic_1, to: basic_2, input: light, window: [10, 21] }
  - { from: basic_2, to: basic_3, input: light, window: [12, 24] }
  - { from: basic_2, to: heavy,   input: heavy, window: [6, 24] }
  - { from: heavy,   to: launch,  input: heavy, window: [10, 33] }
  - { from: heavy,   to: dodge,   input: dodge, window: [0, 33], type: cancel }
  - { from: basic_3, to: dodge,   input: dodge, window: [0, 30], type: cancel }
  - { from: dodge,   to: basic_1, input: light, window: [8, 18] }   # masuk ulang

bonuses:
  - { on: basic_3, requires_path: [basic_1, basic_2], damage_multiplier: 1.5 }

Spesifikasi ini memuaskan dua pembaca sekaligus. Manusia membaca window: [6, 24] dan memahami "oh, heavy diterima mulai pertengahan dasar 2," sementara mesin menguraikan baris yang sama untuk dipakai menggambar graf dan mengenumerasi jalur. Dari satu sumber, pemahaman manusia dan verifikasi mesin keluar secara bersamaan.

Nilai-nilai frame di atas (21, 24, [6, 24]) bukan hasil pengukuran, melainkan nilai contoh yang penulis susun untuk keperluan penjelasan bab ini (belum terverifikasi). Di proyek nyata, nilai-nilai ini berasal dari panjang montage yang dibuat animator dan timing notify pada build. Saat pertama kali menulis spesifikasi, kita masukkan nilai intensi desainer, lalu setelah build keluar kita capture dan koreksi menjadi nilai pengukuran nyata — loop koreksi ini dibahas di 4.4.

4.3.3 Worked Transcript — Dari Bahasa Alami sampai Spesifikasi

Saya berikan aturan yang ditulis rekan B di papan tulis dalam bentuk bahasa alami, lalu meminta diubah menjadi spesifikasi YAML. Tanpa meringkas, saya pindahkan apa adanya: prompt selengkapnya, keluaran mentah Claude, serta verifikasi/penolakan dari manusia.

Prompt (Selengkapnya)

Berikut ini adalah aturan kombo untuk karakter prajurit. Ubah ini menjadi spesifikasi kombo dalam YAML.

Aturan:
- Serangan dasar tersambung dalam pukulan 1, 2, 3. Tombol serangan ringan (light).
- Kalau tombol heavy ditekan di tengah dasar 2, bisa keluar ke heavy.
- Kalau setelah heavy ditekan heavy sekali lagi, musuh terlempar ke atas (launch).
- Heavy bisa di-cancel dengan dodge kapan saja.
- Dasar 3 juga bisa di-cancel dengan dodge.
- Tepat setelah dodge, dasar 1 bisa dimulai lagi dengan serangan ringan.
- Dasar 3 baru mendapat damage 1.5x kalau sudah melewati dasar 1 dan dasar 2 keduanya.

Format spesifikasi:
- nodes(id, name, duration_frames), edges(from, to, input, window, type),
  bonuses(on, requires_path, damage_multiplier)
- Edge cancel ditandai dengan type: cancel.
- Untuk nilai frame yang tidak aku berikan, jangan kamu tentukan sendiri, biarkan kosong sebagai TODO.

Baris terakhir itulah intinya. Saya menyatakan secara eksplisit: kalau frame tidak diberikan, jangan dikarang. Ini memaksakan standar v3 nomor 3 (kejujuran angka) pada level prompt.

Keluaran Mentah Claude (Tanpa Editan)

Sudah saya ubah menjadi spesifikasi. Nilai frame tidak disediakan, jadi saya biarkan sebagai TODO.

```yaml
character: warrior
combo_id: basic_chain
nodes:
  - { id: basic_1, name: Dasar 1, duration_frames: TODO }
  - { id: basic_2, name: Dasar 2, duration_frames: TODO }
  - { id: basic_3, name: Dasar 3, duration_frames: TODO }
  - { id: heavy,   name: Heavy, duration_frames: TODO }
  - { id: launch,  name: Launch, duration_frames: TODO }
  - { id: dodge,   name: Dodge,   duration_frames: TODO }
edges:
  - { from: basic_1, to: basic_2, input: light, window: TODO }
  - { from: basic_2, to: basic_3, input: light, window: TODO }
  - { from: basic_2, to: heavy,   input: heavy, window: TODO }
  - { from: heavy,   to: launch,  input: heavy, window: TODO }
  - { from: heavy,   to: dodge,   input: dodge, window: TODO, type: cancel }
  - { from: basic_3, to: dodge,   input: dodge, window: TODO, type: cancel }
  - { from: dodge,   to: basic_1, input: light, window: TODO }
bonuses:
  - { on: basic_3, requires_path: [basic_1, basic_2], damage_multiplier: 1.5 }
```

Bagian yang perlu dikonfirmasi:
1. "Mulai ulang dasar 1 tepat setelah dodge" saya masukkan sebagai edge dodge -> basic_1, tetapi
   tidak jelas apakah input diterima selama recovery dodge atau setelah dodge benar-benar selesai.
2. Tidak ada aturan apakah ada air combo yang menyusul setelah launch.
   Perlu dikonfirmasi apakah launch adalah akhir kombo.
3. Tidak jelas apakah dodge ditaruh sebagai node atau hanya sebagai edge (aksi cancel). Untuk sementara saya
   taruh sebagai node — saya menganggap dodge sendiri adalah aksi yang punya durasi.

Mari kita evaluasi di sini. Yang baik: frame tidak dikarang dan semuanya dikosongkan sebagai TODO. Batasan dalam prompt dipatuhi. Lalu ketiga pertanyaan di akhir semuanya benar-benar titik yang ambigu — khususnya nomor 1 (timing input masuk-ulang) adalah persis lubang yang tidak bisa dijawab seketika oleh rekan B di ruang rapat. AI menemukan lubang itu lebih dulu daripada manusia.

Yang masih kabur: keputusan menaruh dodge sebagai node di nomor 3 bisa diperdebatkan. Dodge adalah "aksi cancel" sekaligus "aksi yang punya durasi," jadi keduanya sama-sama benar. AI memilih satu sisi lalu melaporkannya sebagai sesuatu yang ambigu — itu jujur, tapi ini adalah keputusan desain sehingga manusialah yang harus menentukannya.

Verifikasi/Penolakan oleh Manusia

Saya jawab ketiga pertanyaan dan menolak sebagian.

• Nomor 1 (timing masuk ulang): input diterima selama recovery dodge (8\~18f). Bukan setelah dodge ditonton sampai habis, melainkan masuk ulang ke dasar 1 lewat cancel recovery. → Diterima, window: [8, 18].
• Nomor 2 (setelah launch): dalam lingkup bab ini, launch ditaruh sebagai akhir kombo. Air combo dipisahkan ke set tersendiri. → Penilaian AI diterima.
• Nomor 3 (dodge=node): ditaruh sebagai node. Hanya saja saya tambahkan atribut cancels_recovery: true untuk menyatakan bahwa ini adalah "aksi yang memutus recovery." → Diterima sebagian + penambahan atribut.

Dan satu hal saya tolak. AI tidak menempelkan type: cancel pada edge dodge → basic_1, padahal ini memutus recovery dodge lalu masuk, jadi sifatnya memang cancel. Namun di sini saya menganggapnya sebagai "masuk normal setelah dodge" dan menaruhnya sebagai edge biasa — karena untuk karakter ini, pembedaan antara cancel recovery dan sambungan normal tidak menghasilkan perbedaan dari sisi rasa main. Ini adalah kasus di mana manusia menimpa klasifikasi AI dengan penilaian domain.

Permintaan Ulang

Bagus. Keluarkan ulang spesifikasi final dengan mencerminkan hal-hal berikut:
- Tambahkan cancels_recovery: true pada dodge.
- window untuk edge dodge -> basic_1 adalah [8, 18].
- Untuk frame lain, karena aku tetap belum memberikannya, pertahankan TODO. Tapi karena aku akan
  memakai nilai contoh dari graf di atas (basic_1=21, basic_2=24, basic_3=30, heavy=33, launch=28, dodge=18),
  isi dengan nilai-nilai itu. Beri komentar bahwa ini nilai contoh yang belum terverifikasi.

Hasil dari permintaan ulang inilah YAML di 4.3.2. Tidak selesai dalam sekali jalan. Prompt → mentah → verifikasi/penolakan → permintaan ulang. Siklus inilah yang membangun keandalan spesifikasi. AI menandai tempat yang ambigu, dan manusia memutuskan dengan pengetahuan domain — keduanya tidak bisa berjalan sendirian.

4.3.4 Mengenumerasi Jalur Secara Otomatis

Karena spesifikasi adalah graf, enumerasi jalur kombo menjadi persoalan penelusuran graf (graph traversal). Yaitu depth-first search (DFS) yang mencari semua jalur dari node awal sampai node akhir (atau finisher). Manusia tidak bisa melakukannya di kepala, tapi kode menyelesaikannya dalam sekejap.

Di dalam workspace terisolasi tim penulis, 95_BattleTF, ada skrip kecil yang menangani enumerasi ini. Skrip itu membaca spesifikasi YAML, mengeluarkan semua jalur, dan memverifikasi apakah setiap jalur mungkin secara aturan (apakah edge-nya ada). Kalau hanya logika intinya yang ditampilkan, seperti ini.

# 95_BattleTF/enumerate_paths.py (kutipan)
import yaml

def load_graph(path):
    spec = yaml.safe_load(open(path, encoding="utf-8"))
    adj = {}
    for e in spec["edges"]:
        adj.setdefault(e["from"], []).append(e)
    return spec, adj

def enumerate_paths(adj, start, max_depth=8):
    results = []
    def dfs(node, path, edges):
        # node akhir (tanpa edge keluar) atau batas kedalaman, jalur ditetapkan
        outs = adj.get(node, [])
        if not outs or len(path) >= max_depth:
            results.append((list(path), list(edges)))
            return
        for e in outs:
            if e["to"] in path:        # cegah perulangan: node sama 1 kali per jalur
                results.append((list(path), list(edges)))
                continue
            dfs(e["to"], path + [e["to"]], edges + [e])
    dfs(start, [start], [])
    return results

Kalau dijalankan mulai dari basic_1, mengucur jalur-jalur yang dengan tangan mustahil dibentangkan seluruhnya. Kalau hanya sebagian yang ditampilkan, seperti berikut.

Nomor 3 dan 4 penting. Karena edge masuk-ulang dodge, kombo berulang (siklik). Yang tidak terlihat manusia di papan tulis justru jalur siklik semacam ini. Kalau guard cegah-perulangan (node sama 1 kali per jalur) tidak dimasukkan ke DFS, enumerasi terjebak dalam loop tak berujung — ini adalah jebakan yang benar-benar saya sadari saat kode pertama kali dijalankan dan ia berhenti membeku. Kalau graf memuat siklus, enumerator wajib punya guard.

Keluaran tahap enumerasi ada dua. Pertama, daftar semua jalur yang mungkin secara aturan. Kedua, deteksi kontradiksi aturan — kalau di spesifikasi ada edge dodge → basic_1 tetapi definisi node dodge justru hilang, enumerator menangkapnya sebagai "edge yang menunjuk ke node yang tidak terdefinisi." Kesalahan paling umum saat menulis spesifikasi dengan tangan adalah dangling reference semacam ini.

4.3.5 Memasukkan Jalur yang Dienumerasi ke dalam Simulasi

Daftar jalur saja tidak memberi tahu "jalur mana yang terlalu kuat." Setiap jalur harus dimasukkan ke simulator DPS. simulate_dps milik tim penulis berperan di sini — ia menerima jalur (urutan node), damage dan frame tiap node, serta aturan bonus, lalu menghitung total damage dan total frame yang dibutuhkan, dan menghasilkan damage per detik (DPS).

# 95_BattleTF/simulate_dps.py (kutipan, asumsi 60fps)
def simulate(path_nodes, node_dmg, node_frames, bonuses):
    total_dmg = 0
    total_frames = 0
    visited = []
    for nid in path_nodes:
        dmg = node_dmg.get(nid, 0)
        # bonus: kalau requires_path semuanya dilewati, terapkan pengali
        for b in bonuses:
            if b["on"] == nid and all(r in visited for r in b["requires_path"]):
                dmg *= b["damage_multiplier"]
        total_dmg += dmg
        total_frames += node_frames[nid]
        visited.append(nid)
    seconds = total_frames / 60.0
    return {"dmg": total_dmg, "frames": total_frames,
            "dps": round(total_dmg / seconds, 1) if seconds else 0}

Kalau hasil enumerasi di 4.3.4 dialirkan utuh ke sini, DPS tiap jalur jatuh dalam bentuk tabel. Di bawah ini hasil dengan memasukkan damage node sebagai nilai contoh (pukulan dasar 100, heavy 180, launch 140 — semuanya nilai olahan yang belum terverifikasi) lalu dijalankan.

Tabel ini mengubah diskusi. Intuisi "cabang heavy kelihatan lebih kuat daripada 3-pukulan standar?" berubah menjadi angka "DPS jalur heavy 294 vs standar 280, unggul 5%." Kalau keunggulan 5% itu memang disengaja, lolos; kalau tidak, frame heavy diperpanjang untuk menurunkan DPS-nya. Penilaian ini dilakukan sebelum build keluar, pada tahap spesifikasi.

Kalau seluruh alur kerja dilihat dalam satu lembar, hasilnya seperti ini.

flowchart LR
    A["Aturan bahasa alami
(papan tulis teammate_b)"] --> B["Prompt → AI"]
    B --> C{"Spesifikasi mentah
termasuk TODO·pertanyaan"}
    C -->|Verifikasi/penolakan manusia| D["Spesifikasi final YAML
warrior_basic_chain.yaml"]
    D --> E["enumerate_paths.py
Enumerasi DFS semua jalur"]
    E --> F["Deteksi kontradiksi aturan
Edge dangling·loop tak berujung"]
    E --> G["simulate_dps.py
Hitung DPS per jalur"]
    G --> H["Penilaian balance
Selisih DPS antarjalur"]
    F --> D
    H -->|Penyesuaian frame| D

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class E,F,G code;
    class B,C ai;
    class H human;
    class A,D data;

Spesifikasi (D) berada di pusat, dan enumerasi (E), verifikasi (F), serta simulasi (G) bercabang dari situ. Kalau kontradiksi tertangkap atau balance meleset, kembali ke spesifikasi dan perbaiki. Papan tulis tidak punya loop ini — itulah sebabnya kombo papan tulis baru ketahuan salah setelah masuk ke build.

4.3.6 Cancel dan Input Queue — Dua Tuas yang Menambah dan Mempersempit Jalur

Sampai sini kita telah melihat graf kombo dan enumerasi jalur. Cancel dan input queue adalah dua tuas yang menyetel graf ini. Arahnya berlawanan persis.

Cancel menambah edge. Setiap kali satu aturan cancel ditambahkan, sebuah edge menempel pada graf, dan jumlah jalur yang dienumerasi membengkak secara perkalian. Karena itu, cancel bukanlah "semakin longgar semakin baik." Semakin cancel dilonggarkan, semakin jalur meledak, dan semakin tinggi kemungkinan tercampurnya jalur kuat yang tak diniatkan (seperti jalur siklik di subbab sebelumnya). Di sinilah alasan mengapa tradisi fighting game menaruh cancel secara ketat, sementara action RPG menaruhnya secara longgar — genre yang menentukan "berapa banyak jalur yang boleh diizinkan." Tidak ada nilai window jawaban yang absolut.

Saat menangani cancel, harus selalu dipisahkan dan dinyatakan secara eksplisit. Kalau ditaruh sebagai "cancel apa saja" yang terpadu, enumerator akan membuat edge cancel di antara semua node sehingga jalur bertambah tak terkendali.

Input queue tidak mempersempit jalur, melainkan membuatnya benar-benar bisa diinjak. Tanpa queue, pemain harus menepatkan input window tiap edge (misalnya [12, 24]) secara persis per frame. Dengan reaksi manusia, itu hampir mustahil. Queue menyimpan input yang ditekan sebelum window ke dalam buffer, lalu otomatis memicunya tepat saat window terbuka. Artinya, queue tidak mengubah jalur pada graf, tetapi memasangkan sepatu pada manusia agar bisa berjalan di atas graf.

input_queue:
  window_start_ratio: 0.5   # buffering input berikutnya mulai dari progres aksi 50%
  expire_frames: 10         # masa berlaku input yang di-buffer
  priority: latest          # saat banyak input bersamaan, yang terakhir diprioritaskan

Keseimbangan ketiga parameter inilah intinya. Kalau window_start_ratio terlalu kecil, input di awal aksi pun ikut di-buffer sehingga aksi berikutnya yang tak diniatkan melompat keluar. Kalau expire_frames terlalu pendek, queue kehilangan maknanya dan kembali menuntut ketepatan; kalau terlalu panjang, input yang ditekan jauh sebelumnya terpicu telat sehingga muncul kejadian "kenapa tiba-tiba bergerak." Nilai awal yang disarankan adalah expire_frames 5\~15 dan window_start_ratio sekitar 0.5 — tetapi ini adalah garis awal yang perlu disetel sesuai genre dan bobot karakter, bukan jawaban pasti.

Satu hal soal operasional. Jangan menaruh parameter input queue berbeda-beda sepenuhnya untuk tiap karakter. Taruh satu nilai default global, dan hanya karakter yang bobotnya sangat berbeda (tipe bos raksasa, dsb.) yang di-override. Kalau nilai queue dua puluh karakter dikelola terpisah-pisah, mana yang merupakan perbedaan yang diniatkan dan mana yang merupakan kesalahan menjadi tak terbedakan.

Terakhir, ada satu hal lagi yang perlu ditandai. Sampai sini kita hanya menangani edge sebagai "ada/tidak ada," tetapi meskipun edge-nya ada, bagaimana sebenarnya perpindahan dari satu node ke node berikutnya terjadi adalah keputusan lain lagi. Cara menyambungkan antarkombo punya tiga percabangan inti, dan karena di luar kedalaman buku ini, hal itu tidak saya tangani dengan kode; namun kalau tidak disebutkan, spesifikasi jadi tergambar separuh saja.

• Cancel notify: mulai titik mana animasi saat ini diputus dan input berikutnya diterima. Window edge di atas (window: [10, 21]) justru merupakan representasi notify ini. Kalau notify dimajukan, kombo jadi lebih cepat (sebelum pukulan selesai sudah ke berikutnya); kalau dimundurkan, tiap pukulan terasa lebih berat. Artinya nilai awal window bukan sekadar angka, melainkan keputusan rasa: "akankah pukulan ini ditampilkan sampai habis, atau cepat dilewatkan ke berikutnya."
• Anim blending: mencampur dua node secara mulus saat berpindah. Dari pose akhir heavy ke pose awal launch diinterpolasi selama beberapa frame. Sambungannya halus dan alami, tetapi pada segmen blending mudah muncul celah deteksi pukulan dan "rasa terputus" jadi hilang.
• Frame skip (lewati frame): tanpa blending, frame sisa animasi saat ini dilewati dan node berikutnya langsung dimulai. Sambungannya gesit dan reaksinya cepat, tetapi pose bisa terlihat patah-patah. "Rasa cancel" pada fighting game dan action game umumnya yang ini.

Ketiganya membuat rasa main game berlawanan persis meskipun edge-nya sama. Pada tahap spesifikasi, hanya keberadaan edge dan window yang ditentukan; cara menyambungkan (blending vs frame skip) biasanya ditentukan bersama animator pada tahap build. Hanya saja, kalau di spesifikasi disisakan satu baris field seperti transition: blend / transition: skip lebih dulu, maka pada tahap build tidak perlu bertanya lagi "edge ini diputuskan disambung bagaimana, ya." Cara menyambungkan adalah sumbu ketiga tersembunyi dari graf kombo.

4.3.7 Verifikasi Build Adalah Pekerjaan Tersendiri (Pratinjau 4.4)

Semua verifikasi sampai sini terjadi di atas spesifikasi. Enumerasi jalur, simulasi DPS, deteksi kontradiksi — semuanya menyasar YAML. Tetapi nilai frame pada spesifikasi adalah nilai intensi desainer, bukan nilai pengukuran build. Panjang sebenarnya montage yang dibuat animator, frame saat notify pada build benar-benar terpicu, window saat input queue benar-benar bekerja di engine — ini harus diukur dengan men-capture build.

Mengekstraksi secara otomatis 5 sinyal (frame terjadinya pukulan, recovery, cancel window, input queue, hitstop) dari video build punya tingkat implementasi yang tinggi, dan secara realistis yang paling dapat diandalkan adalah telemetri di dalam game — biarkan di dalam build dicetak log "aksi ini menerima input ini pada frame ini," lalu log itu diadu dengan spesifikasi (perbandingan metode capture lihat 4.4). Loop pengaduan inilah tema 4.4. Kalau window yang menurut spesifikasi [12, 24] ternyata terukur [14, 26] pada build, maka spesifikasi dikoreksi mengikuti pengukuran build.

4.3.8 Kesalahan Umum dan Cara Menghindarinya

Poin-Poin Penting

• Karena kombo bukan garis lurus melainkan graf, jalur dienumerasi oleh kode, bukan oleh manusia.
• Cancel adalah tuas yang menambah jalur, input queue adalah sepatu yang membuat jalur bisa dijalani.
• Meskipun edge-nya sama, cara menyambungkan (cancel notify·anim blending·frame skip) membuat rasa main berlawanan persis.
• Verifikasi di atas spesifikasi dan verifikasi di atas build adalah pekerjaan yang berbeda, dan untuk yang kedua telemetri adalah pilihan yang realistis.

Coba Sendiri — Mini Pipeline Enumerasi Jalur Kombo

Ini adalah prosedur minimal yang bisa Anda ikuti dengan tangan. Cukup ada Python dan pyyaml.

setup. Buat satu folder kerja dan taruh di dalamnya file spesifikasi dan dua skrip.

combo-mini/
  warrior_basic_chain.yaml   # spesifikasi dari 4.3.2
  enumerate_paths.py         # enumerator DFS dari 4.3.4
  simulate_dps.py            # simulator dari 4.3.5

Setelah pip install pyyaml, tempelkan YAML dari 4.3.2 apa adanya ke dalam file spesifikasi.

prompt. Tahap mengubah aturan bahasa alami menjadi spesifikasi serahkan pada AI. Pakai prompt dari 4.3.3 apa adanya, tapi pastikan menyertakan batasan terakhir.

Untuk nilai frame yang tidak aku berikan, jangan kamu tentukan sendiri, biarkan kosong sebagai TODO.
Edge cancel ditandai dengan type: cancel, dan bagian yang ambigu pisahkan sebagai pertanyaan tersendiri.

Dua baris ini mencegah pemalsuan angka dan penilaian sembarang oleh AI. Pada spesifikasi yang keluar, daftar TODO dan pertanyaan diisi oleh manusia.

verify. Kalau spesifikasi sudah selesai, verifikasi dua kali.

python enumerate_paths.py warrior_basic_chain.yaml   # semua jalur + keluaran kontradiksi
python simulate_dps.py    warrior_basic_chain.yaml   # tabel DPS per jalur

Pada keluaran enumerasi, periksa (1) apakah jalur siklik tidak bertambah tak berujung, (2) apakah tidak ada dangling edge yang menunjuk ke node yang tidak terdefinisi. Pada keluaran DPS, lihat apakah selisih antarjalur berada dalam rentang yang diniatkan. Kalau selisihnya besar, perbaiki frame/damage pada spesifikasi lalu jalankan lagi.

Versi Ringkas Solo

Kalau tidak ada waktu untuk membuat alat terpisah, selesaikan penulisan spesifikasi dan enumerasi jalur dalam satu percakapan AI saja. Berikan aturan bahasa alami, lalu masukkan ke dalam satu prompt: "Ubah menjadi spesifikasi kombo YAML, lalu mulai dari node awal daftarkan seluruh jalur yang mungkin secara depth-first hingga tuntas, dan untuk siklus putuskan agar hanya berputar sekali. Kalau ada edge yang menunjuk ke node yang tidak terdefinisi, tandai." AI akan melakukan penyusunan spesifikasi, enumerasi, dan deteksi kontradiksi sekaligus. Untuk simulasi DPS, kalau damage node diberikan sekalian dalam bentuk tabel, terimalah lewat permintaan lanjutan "hitung total damage dan frame tiap jalur lalu berikan dalam bentuk tabel." Presisinya memang menurun, tapi tetap memandang jauh lebih ke depan dibanding papan tulis. Intinya tidak berubah — jangan bentangkan kombo di dalam kepala, tampilkan dengan mengenumerasinya.

4.4 Simulasi dan Verifikasi Pertarungan dengan Bantuan AI

Build #234 dari TF Pertarungan baru saja masuk. Ini build pertama yang menyentuh skill baru skill_thunder. Di dokumen spesifikasi tertulis hit timing 150ms. Saya memasukkan input. Ujung jari saya berkata: lambat. Jelas lambat. Saya memanggil rekan A di sebelah. "Ini agak terasa melayang, ya?" Rekan A mencoba beberapa kali. "Hmm… kayaknya iya juga." Kami berdua sama-sama tidak yakin. Spesifikasi bilang 150, tapi tangan bersikeras sekitar 200. Siapa yang benar? Pertarungan antara ujung jari dan kertas. Di build berikutnya pun seseorang akan kembali berkata "secara feel sih oke," dan dengan satu kalimat itu, satu build lagi lewat begitu saja.

Tujuan bab ini adalah mengakhiri pertarungan itu. Kalau ujung jari berkata 200, kita tunjukkan dengan angka apakah memang benar 200. Lalu, sebelum build masuk, kita ingin tahu lebih dulu — hanya dengan melihat spesifikasi — bahwa "skill ini DPS-nya 30% lebih tinggi dari target." Bahkan di masa ketika saya menangani pertarungan sebuah MMORPG AAA yang digarap 200 orang sejak awal, rasa buntu saat feel dan angka tidak cocok itu sama saja. Yang berubah hanyalah: kini ada alat di tangan untuk menyimpulkan ketidakcocokan itu dengan angka.

Kalau 4.2 dan 4.3 membahas bagaimana menuliskan spesifikasi pertarungan, maka 4.4 membahas apakah spesifikasi itu bekerja sesuai maksud. Verifikasi punya dua sumbu. Satu adalah simulasi yang memverifikasi hanya dengan perhitungan tanpa build, satunya lagi adalah analisis tangkapan (capture) yang menarik nilai pengukuran dari video build sungguhan. Saat kedua sumbu ini terikat dalam satu siklus, putaran kerja desain pertarungan menyusut dari hitungan hari menjadi hitungan jam.

Kalau boleh menyampaikan kesimpulan lebih dulu, inti bab ini adalah menjajarkan angka yang tertulis di spesifikasi (150ms) dengan angka yang diukur dari build (220ms), lalu membaca selisihnya (4.4.5). Subbab-subbab di depan (simulator, enumerasi kombo) cukup dibaca sebagai tahap persiapan yang membuat pembandingan itu menjadi mungkin.

4.4.1 Biaya Menunggu Build

Apa yang terjadi ketika seorang Game Designer pertarungan ingin memverifikasi satu skill baru?

Designer menulis spesifikasi. Programmer memasukkan data, artist menempelkan motion dan efek, build berjalan, QA berputar satu kali, dan barulah setelah itu designer menyentuhnya sendiri. Kalau cepat dua hari, biasanya tiga sampai empat hari. Kalau di ujung siklus baru ketahuan "DPS terlalu tinggi," temuan itu menjadi perintah untuk kembali ke titik awal. Tiga sampai empat hari sekali lagi.

Simulasi adalah alat yang memberi jawaban di tahap pertama siklus ini. Kita menghitung hanya dengan spesifikasi. Kalau jawabannya buruk, perbaiki spesifikasi dan hitung ulang. Sebelum masuk ke tahap mahal bernama build, spesifikasinya sendiri tersaring sekali. Sama seperti memasukkan model mobil ke terowongan angin (wind tunnel) terlebih dahulu. Sebelum mobil sungguhan naik ke jalan, rancangan yang meragukan gugur di atas meja.

Tentu saja terowongan angin tidak memprediksi jalan 100%. Karena itulah dibutuhkan sumbu kedua, yaitu analisis tangkapan. Kalau simulasi adalah jawaban ideal, maka tangkapan adalah jawaban yang benar-benar terjadi di build. Menjajarkan keduanya dan membaca selisihnya — itulah keseluruhan bab ini.

4.4.2 simulate_dps — Simulator yang Bisa Dijalankan

Dengan pseudo-code yang abstrak, tidak ada yang bisa diverifikasi. Karena itu kita buat kode yang benar-benar berjalan sejak awal. Berikut adalah kerangka inti simulate_dps.py yang saya pakai di TF Pertarungan, yang sudah saya rekonstruksi untuk dimuat di buku setelah membuang data perusahaan. Berjalan hanya dengan pustaka standar Python, tanpa dependensi (untuk berkas lengkap lihat bagian "Coba Sendiri").

Inputnya sederhana. Satu skill adalah sebuah dataclass yang memiliki damage, cast_sec (waktu pendudukan saat cast), cooldown_sec, dan resource_cost, sementara karakter memiliki total resource, jumlah pemulihan per detik, daftar skill, dan rotasi prioritas. Badan utama yang berjalan di atasnya hanyalah aturan greedy sederhana: "di setiap saat, gunakan skill berprioritas tertinggi di antara skill yang dapat dipakai." Tujuannya adalah menangkap batas atas ideal — yang tidak lebih pintar maupun lebih bodoh dari pemain sungguhan. Kalau kita cuplik bagian yang menjadi tulang punggungnya saja, kira-kira begini.

# Buat timeline dengan tick 0.05 detik. Jika tidak sedang cast, gunakan skill pertama yang dapat dipakai sesuai urutan prioritas.
while t < duration_sec:
    resource = min(char.max_resource, resource + char.resource_regen * tick)
    for name in cooldowns:
        cooldowns[name] = max(0.0, cooldowns[name] - tick)
    if t >= busy_until:                     # tunggu jika motion cast belum selesai
        for name in char.rotation:          # urutan prioritas
            s = skill_by_name[name]
            if cooldowns[name] <= 0 and resource >= s.resource_cost:
                total_damage += s.damage
                resource -= s.resource_cost
                cooldowns[name] = s.cooldown_sec
                busy_until = t + s.cast_sec  # skill berikutnya tidak bisa hingga saat ini
                break
    t += tick
# …(untuk definisi dataclass, input warrior, dan loop output, lihat kode lengkap di "Coba Sendiri")

Menempatkan skill_thunder (damage 420, cast 0.9s, cooldown 6s) sebagai prioritas pertama pada warrior, dengan skill_dash dan basic_1 di belakangnya, lalu menjalankannya selama 20 detik (python simulate_dps.py), menghasilkan:

Rata-rata DPS: 261.0
  t=  0.0s  skill_thunder  resource=60
  t=  0.9s  skill_dash     resource=47
  t=  1.3s  basic_1        resource=50
  t=  1.6s  basic_1        resource=53
  t=  1.9s  basic_1        resource=55
  ...

Apa makna nilai ini? Bahwa tanpa build, dalam waktu kurang dari 1 detik, kita tahu fakta bahwa batas atas DPS ideal warrior kira-kira 261. Kalau target DPS-nya 180, maka spesifikasi ini berlebih sebesar +45%. Tanpa perlu menunggu build, kita bisa langsung menyentuh damage atau cooldown_sec sekarang juga.

Keterbatasannya pun saya tulis dengan jujur. Simulator ini tidak mencerminkan kesalahan input pemain, celah akibat pergerakan dan dodge, maupun gangguan dari musuh. Karena itu nilai pengukuran selalu keluar lebih tinggi daripada build sungguhan. Ini bukan bug, melainkan justru definisi simulator itu sendiri sebagai batas atas. Selisih dengan pengukuran nyata akan ditambal dengan tangkapan di 4.4.5.

Catatan Pemanfaatan AI. Kerangka di atas memang saya susun sendiri, tetapi ketika menambahkan model resource baru (misalnya struktur ketika gauge amarah terisi saat menerima damage), saya meminta kepada Claude dengan mengutip kode yang sudah ada, seperti "Tambahkan aturan amarah +5 saat terkena serangan ke simulate_dps ini. Di dalam loop tick, sebagai variabel terpisah dari pemulihan resource yang sudah ada." Kalau Anda meminta untuk menghasilkan seluruh simulator dari kertas kosong, yang keluar adalah kode yang tidak bisa diverifikasi. Tulang punggung dipegang manusia, AI menumbuhkan cabangnya.

4.4.3 Enumerasi Otomatis Jalur Kombo

Hanya dengan satu angka DPS itu tidak cukup. Untuk memverifikasi "kombo mana yang dimaksudkan sebagai kombo utama," kita harus membentangkan seluruh jalur yang mungkin. Kalau menggambar pohon dengan tangan, kepala sudah meledak di 7\~8 node. Membentangkan jalur tanpa ada yang terlewat adalah hal yang dilakukan mesin jauh lebih baik daripada manusia — asalkan kita memintanya menghasilkan dalam bentuk yang bisa ditelusuri ulang oleh manusia.

Berikut adalah kode yang menerima graf kombo, menyebutkan semua jalur, dan mengurutkannya berdasarkan DPS. combo_graph adalah catatan dalam bentuk adjacency list tentang "dari aksi tertentu bisa di-cancel ke aksi apa," yang diekstrak langsung dari spesifikasi state machine di 4.3. Intinya adalah generator all_paths yang membentangkan secara rekursif hingga ujung buntu.

# enumerate_combos.py — bentangkan semua jalur dari graf kombo dan urutkan berdasarkan DPS
combo_graph = {"start": ["A"], "A": ["B", "D"], "B": ["C", "E"], "D": ["C"], "C": [], "E": []}
action_stats = {  # (damage, durasi dalam detik)
    "A": (300, 0.8), "B": (450, 1.0), "C": (450, 1.2), "D": (600, 1.4), "E": (200, 0.6),
}

def all_paths(node="start", path=None):
    path = (path or [])
    nexts = combo_graph.get(node, [])
    if not nexts:                       # ujung buntu = kombo yang utuh
        yield [n for n in path if n in action_stats]
        return
    for nxt in nexts:
        yield from all_paths(nxt, path + [nxt])

results = []
for p in all_paths():
    dmg = sum(action_stats[a][0] for a in p)
    dur = sum(action_stats[a][1] for a in p)
    results.append((p, dmg, round(dur, 1), round(dmg / dur, 1)))

for p, dmg, dur, dps in sorted(results, key=lambda r: -r[3]):
    print(f"{' → '.join(p):<18} {dmg:>5} dmg  {dur:>4}s  DPS {dps}")

Hasil eksekusi:

A → D → C            1350    3.4s  DPS 397.1
A → B → C            1200    3.0s  DPS 400.0
A → B → E             950    2.4s  DPS 395.8

Sinyal yang harus dibaca Game Designer di sini bukanlah sekadar peringkat satu. Bahwa DPS ketiga jalur itu berhimpitan di kisaran 396\~400 — ini adalah sinyal bahwa "kombo mana pun yang dipakai efisiensinya mirip, sehingga tidak ada identitas kombo utama." Kalau maksudnya adalah "A→D→C harus menjadi kombo utama berisiko tinggi-imbalan tinggi," maka damage D harus dinaikkan atau waktunya dikurangi agar DPS-nya naik satu tingkat. Kini giliran kembali ke spesifikasi.

Di posisi tempat enumerasi otomatis ini menggantikan perhitungan manual, sekalipun node kombo bertambah menjadi 20, manusia cukup membaca tabel yang sudah terurut.

4.4.4 Analisis Tangkapan Build — Metode Realistisnya adalah telemetry

Kini sumbu kedua. Tahap mengukur apa yang sebenarnya terjadi di build. Orang sering membayangkan "AI menonton video build lalu menganalisisnya secara otomatis," tetapi di sini kita membagi cabangnya dengan jujur. Ada tiga jalan untuk memperoleh nilai pengukuran, dan biaya serta akurasi ketiganya sangat berbeda.

Opsi A (analisis piksel video) terdengar menarik. Gambarannya adalah mengekstrak lima sinyal secara otomatis dari layar — indikator input, perubahan motion karakter, frame pertama efek, gelombang suara, dan UI angka damage. Tetapi kalau benar-benar dibuat, galat ±1\~2 frame menjadi lapisan dasar karena noise kompresi frame, UI yang menghalangi, dan motion blur. Pada 60fps, 1 frame kira-kira 16.7ms. Dalam verifikasi yang menghitung hit timing dalam satuan ms, noise ±33ms itu fatal. Kesulitan implementasinya sangat tinggi, dan akurasinya tidak sebanding dengan upaya itu.

Karena itu jawaban realistisnya adalah opsi C, log telemetry dalam game. Engine sudah tahu secara internal dengan tepat waktu penerimaan input, waktu terpicunya animation notify, waktu spawn VFX, dan waktu penerapan damage. Daripada menyimpulkan waktu itu dari piksel, cukup buat agar ia mencetaknya dalam satu baris log. Alih-alih memulihkan 100ms dari piksel, kita menyalin apa adanya 100ms yang sudah diketahui engine.

// Tambah satu baris di kode pemrosesan aksi pertarungan (pseudo-contoh UE C++)
// Panggil logger yang sama pada titik penerimaan input / penerapan damage
CombatTelemetry::Log("input",  SkillName, GetWorld()->GetTimeSeconds());
CombatTelemetry::Log("hit",    SkillName, GetWorld()->GetTimeSeconds());

Logger mencatat baris demi baris dalam format JSON Lines.

{"event":"input","skill":"skill_thunder","t":12.340}
{"event":"hit",  "skill":"skill_thunder","t":12.560}
{"event":"input","skill":"basic_3","t":14.100}
{"event":"hit",  "skill":"basic_3","t":14.166}

Selisih waktu antara input dan hit itulah hit timing yang terukur. 12.560 − 12.340 = 0.220 detik = 220ms. Ini bukan ±33ms dari analisis piksel, melainkan nilai apa adanya dari waktu engine. Mengambil log ini lalu membandingkannya dengan spesifikasi adalah isi subbab berikutnya.

4.4.5 Worked Transcript: Spesifikasi 150ms vs Pengukuran 220ms

Kini kita kumpulkan kedua sumbu dalam satu tempat. Spesifikasi menjanjikan 150ms, dan telemetry mengukur 220ms. +70ms. Ujung jari benar. Saya menelusuri sampai tuntas bersama AI proses mempersempit penyebab selisih ini. Tanpa meringkasnya, saya muat apa adanya bahkan adegan ketika AI di awal salah arah.

Prompt

Spesifikasi hit timing-nya 150ms tetapi pengukurannya 220ms. Saya menempelkan log di bawah dan bertanya dengan panjang sewajarnya yang mungkin benar-benar diketik manusia. Permintaan singkat yang maksudnya jelas lebih baik daripada formalitas yang bertele-tele — satu baris yang meminta mencantumkan metode verifikasi dan satu baris larangan memutuskan secara mutlak adalah tulang punggung prompt ini.

Hit timing skill_thunder di spesifikasi 150ms tetapi terukur 220ms, melampaui +70ms. Dari telemetry di bawah, pisahkan kemungkinan penyebabnya dan tuliskan juga log mana yang memastikan/menyingkirkan masing-masing. Jangan memutuskan secara mutlak; jika tidak pasti tandai sebagai 'belum terverifikasi'. // "metode verifikasi juga" dan "larangan memutuskan mutlak" adalah dua maksud inti. Formalitas lainnya boleh dihilangkan, hasilnya tetap sama.

{"event":"input","skill":"skill_thunder","t":12.340}
{"event":"anim_start","skill":"skill_thunder","clip":"cast_thunder","t":12.340}
{"event":"anim_notify","skill":"skill_thunder","notify":"HitWindow","t":12.560}
{"event":"hit","skill":"skill_thunder","t":12.560}

Menurut spesifikasi, notify HitWindow dari cast_thunder ada di titik 0.150s.

Keluaran Mentah Claude (tahap 1 — sebelum verifikasi, termasuk salah tebak)

Saya memperkirakan empat hal berikut sebagai penyebab kelebihan +70ms.

1. Latensi jaringan. Mungkin 70ms tertambah saat input bolak-balik ke server. Kalau ini build multiplayer, periksa RTT.
2. Penurunan frame rate. Kalau build berjalan di 30fps, 1 frame adalah 33ms, sehingga timing notify dibulatkan ke batas frame dan keterlambatan menumpuk.
3. Perubahan panjang motion casting. Klip cast_thunder mungkin menjadi lebih panjang dari spesifikasi sehingga notify HitWindow tergeser ke belakang.
4. Keterlambatan input buffer. Antrean input mungkin diproses telat satu tick.

Penyebab yang paling mungkin adalah nomor 1, latensi jaringan. 70ms adalah rentang RTT yang khas.

Verifikasi dan Penolakan oleh Manusia

Di sini saya berhenti dan membaca lagi log-nya. Perkiraan prioritas pertama AI (jaringan) sudah tersingkir oleh log ini. input dan anim_start tercatat pada waktu yang persis sama, 12.340. Artinya motion langsung dimulai pada saat input masuk, dan tidak ada celah bagi perjalanan bolak-balik jaringan untuk menyusup. Nomor 1 salah.

Nomor 2 (frame rate) juga lemah. Kalau 30fps, seharusnya terlihat ketidakrataan dalam satuan 33ms, tetapi input→hit tepat 0.220 dengan rapi. Ini bukan pembulatan batas frame, melainkan berbau posisi tetap di dalam klip.

Petunjuk yang menentukan ada di tempat lain. Waktu anim_notify adalah +0.220 dari basis anim_start. Spesifikasi bilang HitWindow harus ada pada 0.150 setelah klip mulai, tetapi pada klip sungguhan ia terkunci di titik 0.220. Artinya klip itu sendiri dibuat berbeda dari spesifikasi, atau posisi notify dipindahkan dari 0.150 ke 0.220. Penyebabnya bukan jaringan maupun frame rate, melainkan nomor 3, data motion/notify. AI memang memasukkan kandidat jawaban yang benar di antara empat kemungkinan, tetapi memberi peringkat secara terbalik.

Prompt Permintaan Ulang

Saya melempar lagi dengan mengisi sendiri dasar penyingkiran dengan tangan. Tanpa perlu menjelaskan panjang, saya hanya mematok singkat apa yang sudah disingkirkan dan fakta yang tersisa.

Singkirkan jaringan dan frame rate. (Dasar: input=anim_start pada waktu sama sehingga tidak ada keterlambatan input→motion / input→hit konsisten 0.220 tanpa noise frame.) Fakta yang tersisa: anim_notify pada anim_start +0.220, spesifikasi +0.150. Persempit penyebab hanya dengan fakta ini, dan tuliskan apa yang harus diminta ke programmer dan animator dalam satuan tindakan. // Intinya "dalam satuan tindakan" — buat agar berakhir bukan dengan dugaan melainkan dengan siapa diminta apa.

Keluaran Mentah Claude (tahap 2)

Dengan dasar yang diberikan, penyebab dipersempit menjadi notify HitWindow dari klip animasi cast_thunder ditempatkan pada 0.220s, bukan 0.150s. Tersisa dua cabang.

• (a) notify pas di 0.150 tetapi seluruh klip melambat — kalau play rate lebih rendah dari spesifikasi atau panjang klip bertambah, titik 0.150 meregang menjadi 0.220 dalam waktu nyata.
• (b) posisi notify itu sendiri dipindahkan ke 0.220 — panjang klip tetap, tetapi hanya markernya yang bergeser.

Pemeriksaan yang memisahkan kedua cabang: 1. Ke animator: minta nomor frame notify HitWindow cast_thunder dan total jumlah frame klip, serta riwayat perubahan dibandingkan dengan nilai pada saat spesifikasi ditulis. Kalau marker bergeser, berarti (b). 2. Ke programmer: periksa apakah montage play rate skill_thunder adalah 1.0, dan apakah stat attack speed karakter dikalikan ke klip ini. Kalau play rate 0.68 (=0.150/0.220), berarti (a). 3. Ukur sekali lagi jarak anim_start→anim_notify pada attack speed karakter yang berbeda. Kalau jaraknya berubah mengikuti attack speed berarti (a), kalau tetap berarti (b).

Tindakan yang disarankan: kalau terkonfirmasi (b), kembalikan notify ke 0.150 atau perbarui spesifikasi menjadi 0.220 (pilih yang sesuai maksud). Kalau terkonfirmasi (a), periksa logika penerapan play rate.

Keluaran kali ini layak diadopsi. Ia tidak memutuskan dugaan secara mutlak melainkan memisahkannya menjadi dua cabang (a)/(b), dan metode memisahkan setiap cabang dengan data serta siapa harus diminta apa tertulis dalam satuan tindakan. Khususnya pemeriksaan nomor 3 (mengukur ulang dengan mengubah attack speed) adalah cabang penentu yang mudah terlewat oleh manusia. Kalau laporan ini dibawa apa adanya ke rapat, rapat bukan lagi tempat berdebat "apa penyebabnya" melainkan menjadi tempat "memastikan (a) atau (b) dalam 30 menit dan memilih tindakan."

Inti yang ditunjukkan worked transcript ini adalah fakta bahwa AI tidak memberi jawaban benar sejak awal. Keluaran tahap pertama adalah salah tebak yang menempatkan jaringan di peringkat satu. Barulah ketika verifikasi manusia yang membaca log dan menyingkirkan kandidat menyela, analisis menyatu menuju jawaban yang benar. AI membentangkan kandidat secara luas, manusia mempersempitnya. Pembagian kerja inilah metodologi keseluruhan 4.4.

4.4.6 Menyatukan Dua Sumbu ke Satu Siklus — Loop Verifikasi

Kalau simulasi (4.4.2\~4.4.3) dan analisis tangkapan (4.4.4\~4.4.5) berjalan terpisah, itu hanya separuh nilainya. Saat keduanya terikat menjadi satu, terbentuklah loop berikut.

flowchart TD
    A["Penulisan spesifikasi
(Game Designer, format 4.2·4.3)"] --> B["Simulasi
simulate_dps · enumerasi kombo
(otomatis, 1 detik)"]
    B -->|"DPS/kombo janggal"| A
    B -->|"Spesifikasi lolos"| C["Build
(programmer·artist, beberapa hari)"]
    C --> D["Pengumpulan log telemetry
(input·hit·anim_notify)"]
    D --> E["Pembandingan otomatis spesifikasi vs pengukuran
(deteksi selisih seperti 150ms vs 220ms)"]
    E -->|"Item melampaui ambang"| F["Laporan perkiraan penyebab AI
(bentangkan kandidat → manusia persempit)"]
    F --> G["Tinjauan Designer → keputusan tindakan
(perbarui spesifikasi vs perbaiki build)"]
    G --> A
    E -->|"Semua item cocok"| H["Ke skill berikutnya"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,E code;
    class F ai;
    class A,G human;
    class D data;
    class H pass;

Karena simulasi memberi jawaban sebelum build, spesifikasi yang masuk ke build sudah tersaring sekali. Karena itu masalah yang ditemukan setelah build mengerucut sifatnya bukan menjadi "spesifikasi salah" melainkan "spesifikasi dan implementasi tidak cocok." +70ms di 4.4.5 persis kasus yang kedua itu — spesifikasi 150 sudah masuk akal, hanya implementasinya yang meleset menjadi 220. Pembedaan ini menghapus perselisihan soal siapa yang bertanggung jawab di rapat.

Namun loop ini tidak menutupi seluruh konten pertarungan. Wilayah yang feel-nya adalah konten itu sendiri, seperti sajian signature bos utama, tidak bisa direduksi menjadi angka DPS. Simulasi kuat untuk konten berbasis angka, sementara sajian tetap dijawab oleh tinjauan video yang dilihat dengan mata manusia. Loop berputar di sungai angka, dan sungai sajian mengalir terpisah.

4.4.7 Yang Saya Lihat dari Operasional Enam Bulan

Ini adalah pengukuran enam bulan TF Pertarungan sebuah MMORPG yang saya operasikan (Proyek A yang menargetkan feel kontrol setara seri refgame). Angka di bawah adalah nilai pengukuran sungguhan yang disaring dari catatan internal TF, dan saya nyatakan bahwa jumlah build serta waktu adalah nilai yang dibulatkan dalam satuan siklus (bukan satuan menit yang persis, melainkan pengukuran dalam satuan siklus dan setengah hari).

Perubahan yang lebih penting daripada angka adalah sifat rapatnya. Separuh rapat sebelum penerapan adalah "skill ini terlalu kuat" lawan "tidak, sudah pas." Pertarungan ujung jari lawan ujung jari. Setelah penerapan, tempat itu berpindah menjadi "DPS terukur adalah target +12% dan hit timing terukur adalah spesifikasi +70ms. Apakah memperpendek motion, atau menurunkan damage 10%?" Waktu yang dulu dipakai memperdebatkan apa masalahnya berubah menjadi waktu untuk menentukan bagaimana memperbaikinya.

Biaya peralihan ini pun saya tulis dengan jujur. Pekerjaan awal menanam logger telemetry ke seluruh kode pertarungan memakan kira-kira 1\~2 minggu, dan menyeragamkan skema spesifikasi ke semua karakter dan skill memakan tambahan satu kuartal. Pada kuartal pertama, saya menilai cukup kalau salah satu dari simulasi atau telemetry saja yang berjalan. Keduanya baru saling terkait dalam satu loop mulai kuartal kedua.

4.4.8 Kesalahan Umum dan Cara Menghindarinya

Lima hal yang berulang.

Pertama, terlalu memercayai nilai simulasi. Angka 261 dari simulate_dps adalah batas atas, bukan pengukuran nyata. Kalau tidak dibandingkan dengan telemetry, ia selalu menjadi penaksiran berlebih.

Kedua, tidak melakukan pengukuran. Kalau hanya menyimulasikan spesifikasi dan tidak melihat build dengan telemetry, +70ms seperti di 4.4.5 menumpuk diam-diam. Logging telemetry bukan opsi melainkan fasilitas dasar kode pertarungan.

Ketiga, tidak membawa laporan ke rapat. Sekalipun laporan otomatis tersedia, kalau tidak ada di agenda rapat tidak ada yang melihatnya. Masukkan "tabel pembandingan telemetry build kali ini" sebagai item tetap agenda.

Keempat, mengadopsi perkiraan AI tanpa verifikasi. Seperti yang kita lihat di 4.4.5, perkiraan tahap pertama AI adalah salah tebak. AI adalah alat untuk memperluas kandidat, bukan alat untuk menarik kesimpulan. Jangan pernah melewati satu tahap manusia yang menyingkirkan kandidat dengan log.

Kelima, struktur spesifikasi berbeda untuk tiap skill. Kalau cast_sec ditulis cast_time di satu skill dan castMs di skill lain, simulator maupun skrip pembanding akan rusak setiap kali. Paksakan satu skema spesifikasi bersama ke semua skill — inilah prasyarat agar seluruh alat 4.4 berjalan.

Tidak perlu membereskan kelimanya pada kuartal pertama. Walau hanya satu-dua yang mapan, siklus sudah memendek secara kentara. Sisanya akan tertambal dengan sendirinya sambil memutar loop.

4.4.9 Menutup Part 4

Di 4.1\~4.4 kita membahas secara berurutan koordinat, Look & Feel, kombo, dan simulasi desain pertarungan. 4.1 membahas apa yang dilihat Game Designer pertarungan sebagai objek yang dapat diukur, 4.2 membahas bagaimana mengukur dan menyetel hit timing, hitstop, dan sinkronisasi efek, 4.3 membahas bagaimana menuliskan kombo, cancel, dan input queue sebagai state machine, dan 4.4 membahas bagaimana memverifikasi apakah seluruh spesifikasi itu bekerja sesuai maksud — tanpa build maupun di build.

Satu minggu seorang Game Designer pertarungan yang menyelesaikan Part 4 berubah seperti ini. Senin, verifikasi otomatis simulate_dps menempel pada spesifikasi skill baru. Selasa, identitas kombo utama diperiksa lewat enumerasi otomatis jalur kombo. Rabu, saat build masuk, tabel pembandingan telemetry muncul otomatis. Kamis, diskusi berbasis data 30 menit. Jumat, perbaikan spesifikasi siklus berikutnya. Siklus build menyusut dari 3\~4 kali menjadi 1\~2 kali, dan rapat memendek menjadi separuh atau kurang. Abstraksi bernama feel pukulan berpindah menjadi 220ms yang dapat diukur.

Lalu adegan build #234 tadi — terhadap pertanyaan "ini agak terasa melayang, ya?", kini log telemetry yang menjawab menggantikan kita dengan 220ms. Pertarungan antara ujung jari dan kertas sudah berakhir.

Part 5 berikutnya adalah desain naratif. Kita beralih ke contoh penerapan nyata dari struktur NarrativeDocs Layer 0\~4 yang diperkenalkan di 2.3.

Coba Sendiri

setup. 1. Buat seutuhnya simulate_dps.py di bawah apa adanya. Tanpa dependensi, langsung berjalan dengan python simulate_dps.py, dan "Rata-rata DPS: 261.0" dari 4.4.2 akan tereproduksi.

# simulate_dps.py — hitung DPS hanya dengan spesifikasi, tanpa build
from dataclasses import dataclass

@dataclass
class Skill:
    name: str
    damage: float          # damage per satu pukulan
    cast_sec: float        # waktu cast (pendudukan motion) (detik)
    cooldown_sec: float    # waktu tunggu pemakaian ulang (detik)
    resource_cost: float   # konsumsi resource (MP/stamina)

@dataclass
class Character:
    name: str
    max_resource: float
    resource_regen: float  # pemulihan resource per detik
    skills: list           # list[Skill]
    rotation: list          # urutan prioritas (nama skill)

def simulate_dps(char: Character, duration_sec: float, tick=0.05):
    cooldowns = {s.name: 0.0 for s in char.skills}   # sisa cooldown
    skill_by_name = {s.name: s for s in char.skills}
    resource = char.max_resource
    total_damage = 0.0
    busy_until = 0.0          # saat motion cast selesai
    log = []
    t = 0.0
    while t < duration_sec:
        resource = min(char.max_resource, resource + char.resource_regen * tick)
        for name in cooldowns:
            cooldowns[name] = max(0.0, cooldowns[name] - tick)
        if t >= busy_until:   # jika tidak sedang cast, pilih skill berikutnya
            for name in char.rotation:          # urutan prioritas
                s = skill_by_name[name]
                if cooldowns[name] <= 0 and resource >= s.resource_cost:
                    total_damage += s.damage
                    resource -= s.resource_cost
                    cooldowns[name] = s.cooldown_sec
                    busy_until = t + s.cast_sec
                    log.append((round(t, 2), name, resource))
                    break
        t += tick
    return total_damage / duration_sec, log

if __name__ == "__main__":
    warrior = Character(
        name="warrior", max_resource=100, resource_regen=8,
        skills=[
            Skill("skill_thunder", damage=420, cast_sec=0.9, cooldown_sec=6, resource_cost=40),
            Skill("skill_dash",    damage=180, cast_sec=0.4, cooldown_sec=3, resource_cost=20),
            Skill("basic_1",       damage=60,  cast_sec=0.3, cooldown_sec=0, resource_cost=0),
        ],
        rotation=["skill_thunder", "skill_dash", "basic_1"],
    )
    dps, log = simulate_dps(warrior, duration_sec=20)
    print(f"Rata-rata DPS: {dps:.1f}")
    for t, name, res in log[:8]:
        print(f"  t={t:>5}s  {name:<14} resource={res:.0f}")

1. Tambahkan satu baris log telemetry di titik penerimaan input dan penerapan damage pada kode engine pertarungan (4.4.4). Intinya adalah mencetak waktu engine (GetTimeSeconds dll.) apa adanya.

prompt. Pilih satu item dari telemetry build yang tidak cocok dengan spesifikasi, lalu tanyakan ke AI dengan format 4.4.5 — tempelkan cuplikan log, dan pastikan menyertakan "jangan memutuskan dugaan secara mutlak, sertakan metode verifikasi tiap penyebab, dan kalau tidak pasti tandai sebagai belum terverifikasi."

verify. Jangan mengadopsi apa adanya keluaran tahap pertama AI. Baca sendiri log-nya, hapus dengan tangan kandidat yang dapat disingkirkan (seperti penyingkiran jaringan dan frame rate di 4.4.5), lalu minta ulang dengan menambahkan dasar. Kalau laporan akhirnya berakhir dalam satuan tindakan "perkiraan penyebab + siapa diminta apa", bawalah ke rapat.

Versi Ringkas Solo. Kalau memasang logger telemetry ke seluruh kode terasa membebani, cetak saja dua baris input·hit pada satu skill yang ingin Anda verifikasi. simulate_dps pun lihat saja DPS satu skill itu. Jangan memasang seluruh alat; putar dulu satu kali loop dengan satu skill yang paling mencurigakan, lalu perluas.

Poin-Poin Penting

• Simulasi menghitung batas atas ideal spesifikasi sebelum build, menyusutkan verifikasi dari hitungan hari menjadi hitungan jam
• Pengukuran build secara realistis adalah log telemetry, bukan video, dan menyalin apa adanya waktu engine
• AI adalah alat untuk memperluas kandidat penyebab, sementara verifikasi yang mempersempit kandidat dengan log adalah bagian manusia

Bagian 5 · Narrative Design

5.1 Struktur NarrativeDocs Layer 0–4

Begitu saya masuk ke ruang rapat, ada satu nama karakter yang dilingkari merah di papan tulis. Sebuah NPC bernama Kim. Di side quest milik seorang Game Designer, ia adalah "ayah angkat yang memungut dan membesarkan sang protagonis sejak kecil", sementara di bab 3 main quest milik Game Designer lain, ia adalah "mantan rekan yang mengkhianati protagonis lalu pergi". Kedua dokumen sama-sama disetujui sebulan lalu, dan keduanya sudah masuk ke build. Bahkan estimasi biaya rekaman suaranya pun sudah keluar.

Ini bukan salah siapa pun. Kedua Game Designer sudah membaca dokumen worldbuilding dan mengacu pada setelan karakter. Masalahnya, setelan karakter yang sama tersebar di tiga berkas yang berbeda, dan tak seorang pun bisa memastikan mana yang "asli". Dokumen worldbuilding itu satu berkas Word setebal 70 halaman dalam satu gumpalan, dan saat dicari, nama Kim muncul di sebelas tempat. Tidak ada pembeda antara baris mana yang merupakan keputusan dan baris mana yang sekadar catatan.

Setelah rapat hari itu selesai, yang kami putuskan adalah memecah NarrativeDocs menjadi lima lapis. Bab ini adalah kisah tentang kelima lapis itu.

5.1.1 Alasan Memulai dari Bidang yang Paling Abstrak

Ada alasan mengapa pembongkaran Layer per bidang saya buka lebih dulu dari naratif.

Naratif adalah yang paling abstrak. Hal-hal seperti worldbuilding, emosi, dan tone tidak bisa dijatuhkan menjadi angka. Tidak ada satuan yang jelas seperti "jumlah sprite" atau "koefisien damage" sebagaimana pada art atau sistem. Jika bidang seabstrak ini bisa terurai rapi menjadi Layer, maka bidang lain yang lebih konkret pun otomatis terselesaikan dengan pola yang sama. Anggap saja kita melihat dulu apakah ia bekerja di tempat yang paling sulit.

Selain itu, naratif punya antarmuka (interface) paling banyak. Karakter bersentuhan dengan art, quest bersentuhan dengan konten dan level, dialog bersentuhan dengan UX dan lokalisasi, dan reward bersentuhan dengan sistem. Karena ia adalah titik yang paling banyak melintasi antarbidang, nilai dari penyatuan Layer langsung terlihat.

Terakhir, porsi keluaran berupa bahasa alami (natural language) di sini paling tinggi. Karena itu pula ia menjadi bidang tempat bantuan AI bekerja paling besar. Hanya saja, tidak semua game berpusat pada naratif. Untuk genre kasual atau arkade, kedalaman bab ini bisa jadi berlebihan. Meski begitu, kerangka dasarnya sendiri — "memecah dokumen segumpal menjadi Layer lalu mempersempit antarmuka" — bisa dipindahkan apa adanya ke bidang mana pun.

5.1.2 Laci Berlima Sekat

Bentuk NarrativeDocs setelah dipecah menjadi lima lapis adalah sebagai berikut. Visi (L0) berada di atas, build dan QA (L4) berada di bawah, dan lorong yang menghubungkan antarlapis sengaja dibuat sempit.

Jika dipindahkan ke folder, bentuknya seperti berikut. Tiap nama berkas bukan nama yang diabstraksikan untuk buku ini, melainkan nama berkas yang benar-benar ada di folder tersebut.

NarrativeDocs/
├── Layer0_Vision/
│   ├── world_premise.md          (premis worldbuilding — tetap)
│   ├── narrative_pillar.md       (3 pilar emosi)
│   └── tone_manifesto.md         (daftar kosakata tone·terlarang)
├── Layer1_System/
│   ├── faction_system.md
│   ├── reputation_model.md
│   ├── dialogue_branching_rule.md
│   └── lore_consistency_rule.md
├── Layer2_Content/
│   ├── main_quest/               (per bab)
│   ├── side_quest/
│   ├── character_bible/
│   └── lore_codex/
├── Layer3_Data/
│   ├── quest_table.xlsx
│   ├── npc_table.xlsx
│   ├── dialogue_id_table.xlsx
│   └── reward_table.xlsx
└── Layer4_Build_QA/
    ├── narrative_qa_checklist.md
    ├── voice_review_log.md
    └── localization_status.md

Yang penting adalah bahwa kelima lapis tidak dipikul oleh satu orang. Penanggung jawab utama berbeda di tiap lapis, dan hanya lorong di antara lapis yang bersebelahan yang dibakukan. Panah merah pada gambar di atas itulah lorong tersebut. Khususnya lorong antara L2 dan L3 sengaja digambar paling sempit (panah merah tebal), dan alasannya akan terlihat di bagian belakang.

Dengan perumpamaan laci, ini adalah laci berlima sekat. Sekat pertama berisi satu baris worldbuilding yang sama sekali tak boleh dipindah, sekat kedua berisi rulebook, sekat ketiga berisi naskah utama, sekat keempat berisi sheet, dan sekat kelima berisi log tinjauan. Lorong antarsekat sempit, dan di atas lorong terpasang lonceng pemberitahuan perubahan.

5.1.3 L0 — Ditulis Kecil agar Tidak Berubah

L0 tidak berubah. Kalau berubah, berarti identitas game-nya yang berubah. Karena itu volumenya harus kecil. Kecil supaya tidak berubah.

Totalnya sekitar 4.5 halaman. Inilah bobot L0. Kalau menjadi berat, perubahan akan menakutkan, dan kalau menakutkan, lapis-lapis lain mulai memutari L0. Begitu pemutaran dimulai, L0 menjadi dokumen mati.

Kerangka asli narrative_pillar.md bentuknya seperti ini (isinya diabstraksikan).

---
title: Pilar Emosi Naratif
layer: L0
status: locked
last_updated: 2026-05-18
---

## 1. Kerinduan akan yang Telah Hilang
- Pemain kehilangan satu hal di akhir tiap bab.
- Yang hilang tidak akan kembali lagi (hanya lewat kilas balik).

## 2. Konflik antara Kewajiban dan Kebebasan
- Setiap NPC utama memikul dua kewajiban.
- Pilihan pemain hanya bisa menyelamatkan salah satu kewajiban.

## 3. Bobot Sentuhan Kecil
- Kebaikan kecil melahirkan hasil yang lebih besar daripada tindakan kepahlawanan besar.

Ketiga baris pilar inilah yang menentukan arah ratusan halaman di bawahnya. status: locked bukan sekadar label. Salah satu pemeriksaan otomatis di L4 membaca label ini, sehingga apabila dokumen locked diubah dalam sebuah PR, sistem dikonfigurasi agar merge terblokir tanpa persetujuan Lead Naratif.

5.1.4 L1 — Naratif yang Paling Dekat dengan Kode

L1 bisa diubah, tetapi biayanya besar. Sebab ia adalah rulebook. Jika satu baris rulebook berubah, semua konten yang mengikuti aturan itu terdampak.

Kerangka faction_system.md adalah sebagai berikut.

---
title: Sistem Faksi
layer: L1
atoms:
  - faction_relation_matrix
  - faction_membership_rule
  - faction_quest_eligibility
---

## 1. Konsep Faksi
Ada N faksi. Tiap faksi didefinisikan oleh (ideologi, sumber daya, wilayah).

## 2. Relasi Antarfaksi
- relation_matrix.json (-3 bermusuhan ~ +3 beraliansi)
- Pemicu perubahan relasi: keputusan main quest, ambang reputasi

## 3. Aturan Keanggotaan Pemain
- Maksimum 2 keanggotaan serentak (tidak boleh serentak pada relasi bermusuhan)
- Penalti keluar: reputasi -2, faksi sekutu -1

Perhatikan baik-baik daftar atoms: pada frontmatter. Ketiga nama atom ini bukan sekadar catatan, melainkan pengidentifikasi yang dilacak oleh ontologi di Bagian 7 dan peta relasi di Bagian 11. Jika sebuah quest mengacu pada faction_quest_eligibility, maka saat aturan ini berubah, quest tersebut otomatis naik ke daftar terdampak. L1 adalah keluaran naratif yang paling dekat dengan kode game, jadi dikerjakan berpasangan dengan System Designer.

5.1.5 L2 — Lapis Paling Tebal, Tempat Naskah Utama Tinggal

L2 adalah yang paling tebal. Main quest, side quest, character bible, dan lore codex semuanya tinggal di sini. Setelan asli si Kim — yang di ruang rapat tadi berbenturan sebagai "ayah angkat vs rekan pengkhianat" — kini hanya ada sebagai satu berkas di dalam character_bible/. Berkas itulah satu-satunya sumber kebenaran (single source of truth), dan quest hanya mengacu ke sana.

Folder main quest berbentuk seperti berikut.

main_quest/
├── chapter_01_awakening/
│   ├── 00_chapter_overview.md
│   ├── 01_quest_a_call_to_arms.md
│   ├── 02_quest_b_first_choice.md
│   └── ...
├── chapter_02_road/
│   └── ...
└── _TEMPLATES/
    └── quest_template.md

Tiap berkas quest mengikuti format standar atom.

---
title: Saat Mengangkat Senjata
layer: L2
type: main_quest
atoms:
  - quest_chapter_01_awakening_a
related:
  affects: [reputation_model, faction_relation_matrix]
  derives_from: [narrative_pillar, world_premise]
  requires: [character_kim, faction_alpha]
  part_of: chapter_01_awakening
---

## Tahap Progres
1. ...

## Cabang
- Saat memilih opsi A: ...
- Saat memilih opsi B: ...

## Reward (lihat L3)
- reward_table.xlsx → baris quest_001

Intinya ada pada blok related:. Begitu tertulis requires: [character_kim], quest ini sudah menyatakan bahwa ia mengambil setelan Kim dari character_bible, dan tidak lagi mendefinisikan ulang Kim di dalam berkasnya sendiri. Naskah utama naratif diletakkan di L2, sedangkan reward berupa angka diletakkan di sheet L3. Jika keduanya berada dalam satu berkas, setiap kali memperbaiki satu baris sheet kita harus menyentuh naskah utama, dan akibatnya kunci terjemahan jadi melenceng.

5.1.6 L3 — Lapis Tanpa Satu Baris pun Bahasa Alami

L3 adalah sheet dan ID. Tidak ada satu baris pun kalimat bahasa alami yang masuk.

quest_table.xlsx
| quest_id | chapter | type | unlock_level | reward_xp | reward_gold | dialogue_set_id |
|----------|---------|------|--------------|-----------|-------------|-----------------|
| q_001    | ch01    | main | 1            | 500       | 100         | ds_001          |
| q_002    | ch01    | main | 2            | 800       | 150         | ds_002          |

Dialog pun hanya diacu lewat ID. Naskahnya berada terpisah di dialogue_id_table.xlsx, dan dipetakan 1:1 dengan kunci terjemahan. Lorong yang menghubungkan L2 dan L3 cukup hanya satu kolom quest_id. Di sinilah alasan mengapa pada gambar sebelumnya hanya lorong ini yang berupa panah merah tebal. Membuat antarmuka menjadi sempit hingga satu kolom adalah inti dari pemisahan Layer. Kalau lorongnya lebar, kedua sisi jadi terlalu banyak saling mengetahui, dan ketika salah satu sisi diperbaiki, sisi lain ikut rusak.

5.1.7 L4 — Gerbang Rilis

L4 adalah tinjauan dan rilis. Setiap kali konten baru masuk, pemeriksaan otomatis dan manual bekerja. Pemeriksaan otomatis dijalankan dengan skrip. Empat pemeriksaan di bawah adalah lint yang benar-benar terpasang di CI.

Perhatikan bahwa tone_lint.py membaca langsung tone_manifesto.md milik L0. Lapis paling atas (visi yang tetap) dan lapis paling bawah (gerbang rilis) terhubung langsung lewat otomatisasi. Jika kosakata terlarang yang ditulis dalam visi terdeteksi di naskah tepat menjelang rilis, build akan terblokir.

Hal yang tak bisa ditangkap secara otomatis akan dilihat oleh manusia.

Jika batas antara otomatis dan manual jelas, waktu tinjauan menjadi dapat diprediksi. Kita jadi bisa menjawab pertanyaan, "Tinjauan bab ini perlu berapa hari?"

5.1.8 Mencoba Menyuruh AI Mengerjakan Layer — Worked Transcript (rekaman sesi nyata)

Sampai sini adalah strukturnya. Namun tempat struktur ini benar-benar bekerja adalah saat membuat konten baru. Saya pindahkan apa adanya sebuah sesi nyata, ketika saya menyuruh Claude — pada proyek yang lima lapisnya sudah terpasang — mengambil ide side quest sepanjang satu baris lalu menebarkannya ke dalam Layer. Tanpa diringkas, termasuk bagian yang melenceng dan bagian yang ditolak.

Prompt yang dikirim (teks lengkap):

Jangan langgar konteks L0/L1 yang dilampirkan, dan uraikan dengan struktur Layer kita.

[narrative_pillar.md teks lengkap — 3 pilar emosi]
[tone_manifesto.md cuplikan — kosakata terlarang: "takdir", "nubuat", "sang terpilih"]
[character_bible/character_kim.md cuplikan — Kim: ayah angkat yang memungut protagonis,
 pendiam, kalimatnya menggantung, tidak mengutarakan perasaan secara langsung]

Ide: "Side quest singkat di mana Kim menyerahkan benda peninggalan mendiang istrinya kepada pemain."

Tulis berkas quest L2 (termasuk blok related, naskah utama sekitar 200 karakter), baris L3 quest_table dan
dialogue_id, serta pemeriksaan-mandiri pelanggaran tone. Untuk sekarang tulis L2 saja lalu berhenti.

Keluaran mentah Claude (L2):

---
title: Saputangan yang Pudar
layer: L2
type: side_quest
atoms:
  - quest_side_kim_keepsake
related:
  affects: [reputation_model]
  derives_from: [narrative_pillar]
  requires: [character_kim]
  part_of: chapter_02_road
---

## Tahap Progres
1. Kim memanggil pemain dengan tenang. Tidak langsung menyampaikan urusannya seperti biasa.
2. Ia menyodorkan saputangan usang. "Ini… rasanya lebih baik kalau kau yang menyimpannya."
3. Bila pemain bertanya itu apa, Kim malah memandang ke luar jendela alih-alih menjawab.
4. (Pilihan) Menerima / Menolak.

## Cabang
- Menerima: reputasi Kim +1. Di bab berikutnya, 1 kilas balik terkait saputangan terbuka.
- Menolak: Kim mengangguk dan memasukkan kembali saputangan itu. Tidak ada perubahan reputasi.
  Saputangan itu tidak akan pernah muncul lagi.

## Reward (lihat L3)
- reward_table.xlsx → baris quest_side_kim_keepsake

Di sini Claude berhenti, dan menambahkan satu baris.

"Mengacu pada pilar L0 nomor 1 (yang hilang tidak akan kembali lagi), saya membuat saputangan menghilang selamanya jika pemain memilih 'Menolak'. Namun ada satu hal yang perlu dikonfirmasi. Setelan mendiang istri tidak ada dalam cuplikan character_kim.md. Karena saya memasukkannya atas inisiatif sendiri, hal itu bisa berbenturan dengan character bible."

Verifikasi dan penolakan oleh manusia:

Keluaran ini tone-nya tepat. Sikap pendiam Kim, kalimat yang menggantung, dan kebiasaan tidak mengutarakan perasaan secara langsung semuanya hidup. Kosakata terlarang juga tidak ada. Namun pemeriksaan-mandiri terakhir tepat menunjuk pada masalah yang sesungguhnya. Tidak ada satu pun setelan yang menyebut Kim punya mendiang istri. AI menyimpulkan secara alami sosok pasangan yang telah meninggal dari kata "benda peninggalan" — dan ini adalah tindakan menyelipkan diam-diam sebuah fakta baru ke dalam bible. Inilah persis benih dari insiden yang terjadi di ruang rapat di awal bab ini.

Maka saya menolaknya. Saya mengirim permintaan ulang.

Permintaan ulang:

Tone-nya bagus. Tapi "mendiang istri" itu setelan baru yang tidak ada di bible, jadi tidak bisa dipakai.
Masa lalu Kim baru pasti sebatas "meninggalkan sesuatu saat pergi dari kampung halaman". Jangan
tentukan identitas benda peninggalannya, tulis ulang dengan kabur sebatas "sesuatu yang lama
ditinggalkan" saja. Saputangan juga tidak ada di bible, jadi turunkan jadi "secarik kain" saja.

Keluaran setelah permintaan ulang (cuplikan):

2. Ia menyodorkan secarik kain usang. "Dulu… ada satu hal yang kutinggalkan.
   Anggap saja ini ujungnya."
3. Bila pemain bertanya itu apa, Kim malah memandang ke luar jendela alih-alih menjawab.

Kali ini saya menerimanya. Tanpa memaku masa lalu Kim sebagai sesuatu yang baru, ia tetap menyentuh pilar emosi nomor 1 (kehilangan). Apa yang hilang dibiarkan kabur sampai akhir.

Satu sesi ini menunjukkan dua hal. Pertama, jika konteks Layer (pilar L0 + tone L1 + bible L2) disuntikkan dengan tepat, AI mencocokkan tone secara mengagumkan baiknya. Kedua, ketika menemui ruang kosong, AI mengisinya dengan sesuatu yang terdengar masuk akal. Saat isian itu berupa fakta baru yang tidak ada di bible, yang menangkapnya tetaplah manusia. Karena requires: [character_kim] pada struktur Layer memberi tahu "ke mana harus melihat", verifikator langsung tahu berkas mana yang harus dibandingkan. Seandainya tidak ada struktur, ia akan mengaduk-aduk 70 halaman lagi.

5.1.9 Lonceng Pemberitahuan di Atas Lorong Sempit

Alasan sebenarnya membagi lima lapis adalah untuk mempersempit antarmuka. Dan di tiap antarmuka yang sempit itu dipasang otomatisasi pendeteksi perubahan.

Misalnya, jika diajukan PR yang mengubah "maksimum 2 keanggotaan serentak" menjadi "maksimum 1" pada faction_system.md di L1, maka peta relasi menyisir quest-quest L2 yang mengacu pada faction_quest_eligibility, membuat daftar terdampak, dan daftar itu otomatis dilampirkan ke komentar PR. Orang yang mengubah aturan, alih-alih "menjadwalkan dua-tiga rapat untuk mencari tahu siapa yang terdampak", cukup melihat daftar yang menempel di komentar lalu menuntaskannya dalam rapat 30 menit.

Intinya begini. Kalau hanya Layer yang dibagi tetapi antarmukanya kabur, hasilnya cuma bertambah banyak sekat. Yang esensial adalah otomatisasi antarmuka, bukan pemisahan Layer itu sendiri.

5.1.10 Enam Bulan Operasional, Apa yang Berubah

Ini adalah pengukuran setelah berpindah ke lima lapis dan menjalankannya selama enam bulan. Angka di bawah berbasis catatan operasional tim penulis, tetapi nilai absolutnya hanya saya pindahkan dalam bentuk arah dan rasio (perkiraan penulis·belum terverifikasi). Ada keterbatasan: sebelum pemisahan berbasis ingatan, sesudah pemisahan berbasis pengukuran nyata, jadi ini bukan menakar materi yang sama dua kali.

Yang paling jelas berkurang adalah kelolosan lokalisasi. Karena dialogue_id terikat 1:1 dengan kunci terjemahan di L3 dan dialogue_lint.py mencegah pemetaan yang terlewat, insiden "dialog yang belum diterjemahkan masuk ke build" nyaris lenyap. Memendeknya onboarding juga besar pengaruhnya. Kepada Game Designer baru, alih-alih "baca habis 70 halaman Word", kini saya bisa bilang "hafalkan saja 4.5 halaman L0, lalu untuk quest-mu isi template L2".

Sejujurnya saya tambahkan satu hal: efek ini tidak muncul sekaligus. Pada kuartal pertama hanya satu komentar otomatis yang dipasang, sisanya masih kerja manual. Otomatisasi antarmuka saya tambahkan satu per satu tiap kuartal. Memasang otomatisasi memakan waktu lebih lama daripada membagi Layer.

5.1.11 Alasan yang Lebih Dalam — Jalan Menuju Procedural Generation

Sampai sini adalah alasan permukaan. "Menyatukan bahasa kolaborasi antarbidang." Namun ada satu alasan lagi yang lebih hakiki. Pembongkaran Layer adalah prasyarat yang memungkinkan procedural generation (pembangkitan prosedural). Tesis umum bahwa masing-masing dari lima lapis berpadanan dengan satu peran dalam procedural generation (L0 anchor → L1 rulebook → L2 naskah utama → L3 angka → L4 gerbang), dan bahwa kalau tercampur dalam satu gumpalan, pembangkit tidak bisa menentukan dari mana membaca dan ke mana menulis sehingga runtuh, sudah dibahas utuh di §6.6. Di sini kita hanya melihat bagaimana prasyarat itu benar-benar bekerja di atas lima lapis naratif.

Di atas satu dokumen segumpal 70 halaman, algoritma pembangkit tidak bisa menentukan dari mana membaca dan ke mana menulis. Lima lapis naratif langsung menjadi lima tahap pipeline pembangkitan — L0 anchor, L1 aturan input, L2 tempat naskah utama menumpuk, L3 input simulasi, L4 gerbang verifikasi.

Worked transcript sebelumnya sebenarnya sudah merupakan versi ringkas dari kelima tahap ini. Pilar L0 dan tone L1 disuntikkan sebagai konteks (anchor), naskah utama digenerasi di L2, baris L3 menyusul keluar, dan pemeriksaan-mandiri pelanggaran tone menirukan gerbang verifikasi. Apa yang dikerjakan manusia satu quest pada satu waktu, jika dipindahkan agar generator memproduksi side quest secara massal di atas struktur yang sama, jadilah ia procedural generation.

Jika dibawa lebih jauh, alurnya seperti ini — akumulasi perilaku pemain → perubahan status node BT dunia (Squad tingkat atas) → perubahan angka NPC (reputasi·minat·prioritas) → tag+angka NPC itulah yang menjadi kondisi pemunculan → quest yang cocok muncul dari quest cloud. Quest tidak ditulis lengkap sejak awal, melainkan dibiarkan seperti "awan yang melayang di udara" dengan tag terpasang, dan saat perilaku pemain mengubah angka NPC, quest yang angkanya cocok dengan kondisi pemunculan akan turun dan tampil. Model progresif ini akan dibahas lebih rinci lagi di 5.3 (termasuk diagram alir). Yang ingin ditekankan di sini adalah bahwa seluruh alur ini hanya bekerja di atas pembongkaran lima lapis.

Sebaliknya, tim yang Layer-nya tercampur tidak akan bisa menuju procedural generation. Begitu mencoba, ia runtuh oleh insiden konsistensi. Bayangkan saja insiden Kim yang menjadi ayah angkat sekaligus pengkhianat itu diproduksi secara massal dan otomatis lewat pembangkit.

Hanya saja, ini bukan berarti laci berlima sekat harus lengkap sempurna sejak awal. Pada kuartal pertama, memisahkan satu baris L0 dan satu rulebook L1 saja sudah cukup. Pemisahan dilakukan secara bertahap, antarmuka dibuat sempit.

Terakhir, satu hal tentang penanggalan. Pembongkaran Layer itu sendiri adalah pemisahan yang sudah ada sejak era PCG (Procedural Content Generation, pembangkitan konten prosedural) deterministik. Yang baru adalah bahwa kini LLM menangani naskah utama berbahasa alami, persona, hingga percabangan narasi di atas pemisahan tersebut — pada transcript di atas, tindakan AI menulis dialog dengan mencocokkan tone Kim adalah hal yang mustahil dilakukan dengan tabel aturan lima tahun lalu. Argumen penanggalan ini dibahas lebih lanjut di 5.3.

Di bab berikutnya (5.2) kita akan melihat bagaimana lore_consistency_rule di atas lima lapis ini secara otomatis memverifikasi konsistensi worldbuilding→karakter→quest, yakni checker yang mencegah insiden Kim secara struktural.

Coba Sendiri — Pembongkaran Layer Pertama

Kita asumsikan Anda mulai dari kondisi yang sudah memiliki dokumen worldbuilding segumpal.

setup. Buatlah lima folder kosong di bawah folder NarrativeDocs. Dari Layer0_Vision sampai Layer4_Build_QA. Biarkan dokumen segumpal yang lama apa adanya, lalu dari situ pilih hanya "satu baris yang sama sekali tak berubah" dan pindahkan ke Layer0_Vision/narrative_pillar.md. Masukkan status: locked pada frontmatter. Buat satu berkas ini tidak melebihi 4.5 halaman.

prompt. Saat membuat konten baru, berikan konteks kepada AI dalam urutan ini.

[narrative_pillar.md teks lengkap]
[tone_manifesto.md kosakata terlarang]
[cuplikan berkas character_bible terkait]

Ide: "<ide satu baris>"

Jangan langgar konteks ini, dan mulai tulis dari berkas quest L2. Isi blok related
(requires/derives_from/affects), jangan masukkan setelan baru yang tidak ada di bible,
dan kalau perlu berhentilah lalu bertanya.

verify. Lihat dua hal pada keluaran. (1) Buka berkas yang tertulis di requires: secara nyata, lalu bandingkan apakah AI tidak membuat fakta baru yang tidak ada di sana. (2) Cari kosakata terlarang di dalam naskah utama (otomatis jika ada tone_lint.py, jika tidak ada maka dengan mata). Jika salah satu saja terdeteksi, tolak dan ajukan permintaan ulang sambil menyebut jelas apa yang salah. Penolakan "mendiang istri" pada transcript di atas itulah persis (1).

5.1.12 Versi Ringkas Solo

Jika Anda developer indie yang membuat sendirian tanpa tim, lima lapis bisa terlihat berlebihan. Cukup dua sekat.

Letakkan satu halaman vision.md (gabungan L0+L1), satu folder content/ (L2), dan satu lembar spreadsheet (L3). Untuk QA, alih-alih lapis tersendiri, gantikan dengan kebiasaan menulis satu baris requires: saja pada frontmatter berkas content. Setiap kali menulis quest baru, jika Anda membuka kembali dan membandingkan hanya berkas yang tertulis di requires, Anda bisa mencegah insiden Kim tanpa harus mengaduk-aduk 70 halaman. Intinya bukan jumlah lapis, melainkan kebiasaan "memisahkan satu baris yang sama sekali tak berubah lalu menunjukkannya lebih dulu kepada AI setiap kali". Satu baris itulah anchor konteks, dan baik Anda sendirian maupun tim berukuran menengah, mulailah dari sana.

Poin-Poin Penting

• Jika naratif yang paling abstrak bisa terurai menjadi Layer, bidang lain akan mengikuti dengan pola yang sama.
• L0 harus kecil supaya tidak berubah, dan harus tidak berubah supaya menjadi anchor konteks bagi pembuatan dan tinjauan.
• Yang esensial adalah memasang otomatisasi pada antarmuka yang sempit, bukan membagi Layer.

5.2 Verifikasi Konsistensi: Dunia → Karakter → Quest

Tepat sebelum beta, sebuah laporan bug masuk dari QA. Judulnya: "Sang Raja berbicara dengan bahasa kasar." Isinya singkat. "Pada cutscene pembuka 3.4, K_001 (Raja) berkata kepada pemain 'Hei, tunggu sebentar'. Karakter ini memakai 'engkau' di seluruh 1.1 sampai 3.3."

Ketika saya tanyakan ke penulis naskah, jawabannya tak terduga. "Dialog itu bukan saya yang menulis." Setelah ditelusuri, ternyata seorang penulis lepas (outsource) memasukkannya saat buru-buru mengisi satu baris cabang cutscene. Character bible kami memang memuat voice_profile, tetapi penulis lepas itu belum pernah melihat dokumen tersebut. Aturannya ada di dalam dokumen, tetapi dialognya masuk dari luar dokumen.

Inilah hakikat dari insiden konsistensi. Bukan karena aturannya tidak ada, melainkan karena aturannya tidak ikut sampai ke teks. Dan jika satu baris ini berupa cutscene, masalahnya jadi lebih menakutkan. Cutscene biasanya disertai rekaman pengisi suara. Saat masih berupa teks, sekali perbaiki selesai; tetapi jika ditemukan setelah direkam, akan mengikuti biaya tak dapat dibalik berupa memanggil ulang pengisi suara, merekam ulang, dan mengulang mixing. Tujuan sejati verifikasi konsistensi adalah menangkapnya "sebelum direkam".

Bab ini membahas alur kerja yang menangkap insiden itu dengan rulebook dan pemeriksa (checker), bukan dengan mata manusia. Kita akan melihat — apa adanya, langsung dari produk nyata — bagaimana rulebook lore_consistency_rule menjadi masukan bagi pemeriksa, bagaimana voice_lint mengangkat goyangan nada (tone) sebagai kandidat curiga, dan mengapa khusus putusan akhir harus tetap menjadi ranah manusia sampai akhir.

5.2.1 Di Mana Insiden Konsistensi Bocor

Kalau kita kumpulkan ulasan pengguna dari RPG dan MMORPG yang sudah rilis, insiden konsistensi naratif menyatu ke beberapa pola. Jenisnya tampak berbeda-beda, tetapi penyebabnya hampir selalu sama.

• Kontradiksi dunia (lore): Pada 1.1 "sihir dilarang" → pada 1.3 NPC memakai sihir seolah tak terjadi apa-apa
• Goyangan voice: NPC yang sama berubah gaya bicara dan tingkat hormatnya dari bab ke bab (insiden "raja yang kasar" di depan)
• Konflik garis waktu: NPC yang sudah mati muncul kembali dengan sehat di bagian akhir (sinkronisasi flag kematian terlewat)
• Hadiah dan narasi tak selaras: Secara narasi disebut "pedang anugerah dari Raja", tetapi di data hanya item rongsokan biasa
• Kontradiksi relasi faksi: Tepat setelah menyatakan permusuhan dengan Faksi A, NPC Faksi A justru menyapa dengan ramah

Kelima hal ini tampak seperti lima insiden berbeda, tetapi kalau ditelusuri, semuanya bocor dari titik yang sama. Layer 0 (premis dunia) atau Layer 1 (aturan) berubah, tetapi perubahan itu tidak menyebar sampai ke Layer 2 (teks) dan Layer 3 (sheet data). Aturannya sudah diperbarui, tetapi teksnya masih berhenti di atas aturan yang lama.

Mencoba mencegah ini dengan tinjauan manusia secara manual itu mustahil. Dalam satu bab terjalin 50 NPC, 2,000 baris dialog, dan 30 quest; ketika satu baris aturan diubah, mustahil bagi manusia menelusuri 100% sejauh mana dampaknya merembet. Satu baris yang terlewat tidak tertangkap di tahap tinjauan, lalu tertangkap di kolom ulasan setelah rilis.

Walau begitu, pemeriksaan otomatis pun tidak menjamin 100%. Intinya adalah pembagian peran. Pemeriksaan otomatis dengan cepat mengangkat kandidat curiga, dan putusan dilakukan manusia. Tujuan otomasi adalah mengurangi waktu tinjauan manusia, bukan menghilangkan manusia. Kalau premis ini dikaburkan, semua kegagalan yang akan dibahas di belakang akan mengikuti.

5.2.2 lore_consistency_rule — Rulebook yang Disuapkan ke Pemeriksa

Salah satu dokumen L1 di Proyek A adalah lore_consistency_rule.md. Dokumen ini sekaligus panduan yang dibaca manusia dan masukan yang diurai (parse) oleh pemeriksa. atoms dan affects di frontmatter mengikat kedua peran itu dalam satu tubuh.

---
title: Aturan Konsistensi Lore
layer: L1
atoms:
  - lore_check_world_rule
  - lore_check_character_voice
  - lore_check_timeline
  - lore_check_faction_relation
related:
  derives_from: [world_premise, narrative_pillar]
  affects: [main_quest/*, character_bible/*, dialogue_id_table]
---

## 1. Aturan Dunia (World Rule)
- Dimulai dalam keadaan sihir dilarang → saat sihir dipakai, wajib mencantumkan (waktu, pengguna, justifikasi)
- Dewa dalam keadaan bungkam → dilarang menggambarkan respons langsung (mimpi/penglihatan diizinkan)

## 2. Aturan Voice Karakter
- Wajib merujuk voice_profile masing-masing karakter
- Saat menulis dialog baru, patuhi 5 item voice_profile (kosakata, panjang kalimat, tingkat hormat, ekspresi emosi, ungkapan terlarang)

## 3. Aturan Garis Waktu
- Definisikan status_timeline untuk setiap NPC (hidup / terluka / mati / hilang / berpindah lokasi)
- Periksa otomatis status_timeline pada saat dialog/kemunculan

## 4. Aturan Relasi Faksi
- Catat waktu perubahan faction_relation_matrix
- Dialog setelah perubahan harus mencerminkan relasi yang baru

Satu baris affects mendefinisikan cakupan pemindaian (scan) pemeriksa. Ketika world_premise berubah, pemeriksa menyapu ulang seluruh main_quest/*, character_bible/*, dan dialogue_id_table. Pekerjaan yang dulu ditelusuri manusia di dalam kepala — "dampaknya sampai ke mana?" — kini digantikan oleh graf dependensi yang tertulis di rulebook.

voice_profile adalah aset L2 terpisah yang dirujuk oleh rulebook ini. Profil satu karakter dimasukkan dalam bentuk angka dan enumerasi agar dapat dipakai pemeriksa sebagai patokan perbandingan.

# character_bible/K_001_voice_profile.yaml
character_id: K_001
display_name: Raja
voice_profile:
  vocabulary_register: kuno_formal        # ragam kosakata
  avg_sentence_len: 18                    # panjang kalimat rata-rata (karakter)
  honorific: "engkau"                     # sapaan hormat orang kedua (tetap)
  emotion_expression: tertahan            # tingkat pengungkapan emosi
  forbidden_terms: ["hei", "tunggu sebentar", "wkwk"] # ungkapan terlarang

yaml ini harus ada agar insiden "raja berbicara kasar" menjadi item yang bisa dibandingkan mesin, bukan intuisi manusia. Kalau honorific-nya "engkau" tetapi di dialog muncul "hei", itu bukan opini melainkan kandidat pelanggaran aturan.

5.2.3 Alur Verifikasi Konsistensi

Begitu perubahan terjadi, pemeriksa langsung aktif. Alurnya sebagai berikut.

flowchart TD
    A[Perubahan terjadi: premis L0 / aturan L1 / teks L2] --> B{Pengklasifikasi perubahan}
    B -->|Tersangkut affects aturan mana| C[Panggil pemeriksa terkait]
    C --> D[Pindai teks L2 + sheet L3 dalam cakupan affects]
    D --> E[Daftar kandidat pelanggaran/curiga]
    E --> F[Komentar otomatis dilampirkan ke permintaan perubahan]
    F --> G{Putusan manusia}
    G -->|Pelanggaran sungguhan| H[Perbaiki teks → periksa ulang]
    G -->|Perubahan yang disengaja| I[Perbarui voice_profile / rulebook]
    G -->|Aturan terlalu sensitif| J[Sesuaikan aturannya sendiri]
    H --> K{Apakah masih tahap teks}
    I --> K
    J --> K
    K -->|Ya: dapat dibalik| L[Tinjauan bisa diselesaikan]
    K -->|Tidak: setelah rekaman| M[Tidak dapat dibalik — biaya rekam ulang]
    L -.garis pembatas.-> M

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class B,C,D,F code;
    class G human;
    class A,E data;
    class L pass;
    class M fail;

Percabangan terakhir adalah tulang punggung tersembunyi bab ini. Semua putusan konsistensi harus selesai di tahap teks, yakni tahap yang dapat dibalik. Kalau tinjauan sampai melewati rekaman dan casting, perbaikannya menjadi tidak dapat dibalik. Karena itu, pemeriksa seperti voice_lint dan timeline_lint yang penting bukan berjalan dengan cepat, melainkan berjalan lebih awal. Dialog cutscene harus lolos sekali sebelum masuk antrean rekaman.

Pemeriksanya ada empat jenis, masing-masing berkorespondensi satu lawan satu dengan satu seksi rulebook.

• world_rule_lint.py — Aturan dunia L1 + seluruh teks L2 → kandidat pelanggaran seperti penggunaan sihir, respons dewa, dsb.
• voice_lint.py — voice_profile + dialogue_id_table → dialog yang dicurigai mengalami goyangan voice
• timeline_lint.py — status_timeline NPC + seluruh waktu dialog/kemunculan → konflik seperti NPC mati yang muncul kembali
• faction_lint.py — faction_relation_matrix + nada dialog → dialog yang bertentangan dengan relasi

Keempat pemeriksa tidak 100% akurat. Karena itulah nama keluarannya bukan "pelanggaran", melainkan "kandidat curiga".

5.2.4 Worked Transcript (rekaman sesi nyata): Menjalankan voice_lint Satu Putaran

Kalimat abstrak "ada pemeriksa" tak memberi rasa nyata. Mari kita jalankan sekali sungguhan. Berikut masukan yang mereproduksi insiden "raja berbicara kasar" tadi.

setup — Ambil dua baris dialog yang akan diperiksa dari dialogue_id_table.

dialogue_id_204  speaker=K_001  text="Hei, tunggu sebentar. Kamu bicara duluan."
dialogue_id_217  speaker=K_007  text="...sialan, gagal lagi. Ulang dari awal."

prompt — Pemeriksanya sendiri berjalan berbasis aturan (ekspresi reguler, perbandingan panjang, pencocokan kata terlarang). AI hanya ditempatkan di posisi menjelaskan "kenapa dicurigai" dalam bahasa alami yang bisa dibaca penulis naskah. Prompt LLM lengkap pada tahap pemeriksaan adalah sebagai berikut.

Ini kandidat curiga yang diangkat voice_lint. Jangan beri putusan,
cukup jelaskan dalam 1~2 kalimat saja item voice_profile mana yang sepertinya
dilanggar tiap kandidat, beserta alasannya.
Jangan menyimpulkan "melanggar/tidak melanggar", cukup sampai "dicurigai ~".

[voice_profile]
K_001: honorific="engkau", avg_sentence_len=18, forbidden=["hei","tunggu sebentar"]
K_007: forbidden=["sialan"]

[kandidat curiga]
- dialogue_id_204 (K_001): "Hei, tunggu sebentar. Kamu bicara duluan."
- dialogue_id_217 (K_007): "...sialan, gagal lagi. Ulang dari awal."

Keluaran mentah Claude (disalin apa adanya, tanpa ringkasan atau penyuntingan)

[dialogue_id_204 / K_001]
Dialog ini dicurigai bertentangan dengan item honorific. voice_profile menetapkan
sapaan hormat orang kedua sebagai "engkau", tetapi dialog ini memakai "kamu"
dan sapaan hormatnya sendiri tidak tampak. Selain itu, "hei" dan "tunggu sebentar"
dari forbidden_terms keduanya muncul, sehingga dicurigai menyimpang dari ragam
kosakata (kuno_formal). Terhadap patokan panjang kalimat rata-rata 18 karakter
tidak tampak langsung melanggar, tetapi nada bicaranya sendiri yang menjadi kasual
dicurigai sebagai sinyal pelanggaran.

[dialogue_id_217 / K_007]
"sialan" dari forbidden_terms dipakai apa adanya, sehingga dicurigai melanggar item
ungkapan terlarang. Namun item emotion_expression milik K_007 (cendekiawan) tidak
disediakan, sehingga sulit menilai hanya dari informasi ini apakah ungkapan ini
merupakan luapan emosi yang disengaja atau sekadar penyimpangan. Putusan memerlukan
tinjauan penulis naskah.

Pada keluaran ini ada dua kejujuran yang sengaja kami biarkan. Pertama, pada 204, AI berkata "panjang kalimat rata-rata tidak tampak langsung melanggar" — ia tidak memaksakan item yang bukan pelanggaran sebagai pelanggaran. Kedua, pada 217, AI berkata "item emotion_expression tidak disediakan sehingga sulit dinilai" — ia mengakui kekurangan informasi dan menyerahkan putusan kepada manusia. Seandainya AI mendorong semua kecurigaan menjadi "pelanggaran pasti", itu justru pemeriksa yang lebih berbahaya.

verify — Penulis naskah menerima komentar ini apa adanya dari permintaan perubahan. Putusan dilakukan penulis naskah.

• 204: Pelanggaran sungguhan. Dialog yang dimasukkan penulis lepas tanpa melihat voice_profile → perbaiki teks, periksa ulang
• 217: Pelanggaran yang disengaja. Dialog luapan emosi 3.4 saat K_007 runtuh → tambahkan flag emotion_peak_exception ke voice_profile, dan daftarkan 217 sebagai pengecualian

Kedua kandidat diangkat oleh pemeriksa yang sama, tetapi akhirnya berlawanan. Yang satu memperbaiki teks, yang satu memperbaiki aturan. Bahwa mesin tidak bisa melakukan percabangan ini secara otomatis adalah inti dari subbab berikutnya.

5.2.5 Mengapa Putusan adalah Ranah Manusia

Ada tiga alasan mengapa pemeriksa hanya mengangkat sampai kecurigaan dan menyerahkan putusan.

Pertama, ada pelanggaran yang disengaja. Di bab tempat karakter runtuh atau berubah, voice memang sengaja digoyangkan. 217 di atas adalah contohnya. Pemeriksa bertipe penolakan otomatis akan menghadang maksud pengarahan (directing) penulis naskah.

Kedua, aturannya sendiri berevolusi. Kalau jenis kecurigaan yang sama terus-menerus diputus sebagai "perubahan yang disengaja", itu sinyal bahwa aturan gagal mengikuti kenyataan. Hasil pemeriksaan bukan hanya membuat teks diperbaiki, melainkan juga membuat rulebook diperbaiki.

Ketiga, karakter dan faksi baru memerlukan masa belajar. NPC baru yang voice_profile-nya baru terisi dua-tiga item adalah hal wajar kalau banyak memunculkan kecurigaan. Kalau di masa ini kita pasang penolakan otomatis, penulis naskah akan menganggap pemeriksa sebagai musuh.

Batas antara pemeriksaan otomatis dan putusan manusia harus jelas agar pemeriksa bertahan hidup. Kalau dibuat bertipe penolakan otomatis, dalam sebulan para penulis naskah akan bilang "matikan saja ini". Sama seperti memasang sensor otomatis yang terlalu peka di pintu masuk kantor: setiap ada orang lewat, pintunya menutup, sampai akhirnya seseorang mencopot sensornya. Pemeriksa harus menjadi perangkat yang memberi tahu "ada yang lewat di sini", bukan perangkat yang menutup pintu.

Saya tambahkan satu catatan. Prinsip bahwa tinjauan harus selesai di tahap teks (garis pembatas pada flowchart di depan) juga berlaku sama pada putusan manusia. Putusan "pelanggaran yang disengaja" oleh penulis naskah pun harus selesai sebelum rekaman. Pembatalan setelah rekaman berubah dari masalah pemeriksa menjadi masalah biaya proses (gambaran utuh batas dapat-dibalik/tidak-dapat-dibalik ada di 5.4.5).

5.2.6 Pengukuran — Sebelum dan Sesudah 6 Bulan

Di Proyek A, kami memperkenalkan 4 jenis pemeriksa secara bertahap dan mengukur selama 6 bulan. Berikut berbasis log hasil pengukuran nyata, tetapi dipindahkan dalam arah dan rasio alih-alih nilai absolut (pengukuran internal, bukan perkiraan penulis).

• Waktu tinjauan untuk 1 bab: sebelum diperkenalkan sekitar 5 hari → setelah diperkenalkan sekitar 2 hari (separuh atau kurang)
• Insiden konsistensi yang ditemukan setelah rilis: 3\~5 kasus per bab → 0\~1 kasus
• Kecepatan output bab per penulis naskah: 4 minggu → 2.5 minggu
• Frekuensi pembaruan rulebook (L1): 1\~2 kali per kuartal → 1\~2 kali per bulan

Item terakhir paling menarik. Kalau ada pemeriksa, mengubah aturan sesering apa pun tetap aman. Begitu satu baris aturan diubah, dampaknya otomatis terlihat, sehingga rasa takut akan perubahan berkurang dan aturan berevolusi lebih cepat. Efek sejati dari alat konsistensi lebih dekat ke "jadi bisa mengubah aturan tanpa takut" daripada ke "mengurangi insiden".

Hanya saja, angka di atas adalah angka pada saat 4 jenis pemeriksa semuanya beroperasi. Yang lebih penting, di awal pengenalan, voice_lint saja sudah memberi efek yang kasatmata. Tidak perlu menyalakan keempat jenis sekaligus sejak awal.

5.2.7 Di Mana Menempatkan AI

Untuk badan pemeriksa otomatis, berbasis aturan lebih efisien. Kepercayaan menumpuk ketika masukan yang sama menghasilkan keluaran yang sama, dan LLM bersifat non-deterministik sehingga tidak cocok di posisi itu. AI masuk ke empat posisi lain.

• Deteksi kandidat pelanggaran aturan → aturan (ekspresi reguler, kata kunci, panjang, pemeriksaan struktur). Bukan LLM
• Penjelasan alasan kandidat curiga → LLM. Penjelasan bahasa alami "kenapa dicurigai" yang kita lihat di worked transcript di atas
• Pembuatan draf dialog alternatif → LLM. Draf untuk ditinjau penulis naskah; finalisasi oleh penulis naskah
• Usulan kandidat pembaruan otomatis voice_profile → LLM. Mengekstrak pola dari teks puluhan bab dan menyajikan usulan penguatan item

Aturan itu cepat dan deterministik, sedangkan LLM kuat dalam penjelasan dan pembuatan. Kalau peran keduanya dicampur, keduanya rusak. Kalau pemeriksaan diserahkan ke LLM, akan terjadi dialog yang sama kemarin lolos hari ini tersangkut; kalau penjelasan diserahkan ke ekspresi reguler, yang keluar hanyalah bahasa mesin "pelanggaran item honorific".

5.2.8 Urutan Pengenalan dan Kegagalan yang Umum

Kalau membuat keempat jenis pemeriksa sejak awal, beban datang lebih dulu daripada efek. Urutan yang disarankan adalah dari yang paling murah dan paling besar efeknya.

1. Standardisasi 5 item voice_profile (sekitar 1 bulan) — Tetapkan dulu format character_bible. Ini lebih dahulu daripada pemeriksa
2. Versi minimal voice_lint (sekitar 1 minggu) — Hanya pencocokan kosakata terlarang. Menghalangi satu kata saja sudah mengurangi insiden SNS pascarilis sebanyak 1\~2 kasus per kuartal
3. timeline_lint (1\~2 minggu) — Pemeriksaan flag kematian. Hanya dengan menangkap NPC mati yang muncul kembali pun sudah terasa besar
4. world_rule_lint + faction_lint (1\~2 bulan) — Dua jenis sisanya
5. Bantuan LLM (tambahan 1\~2 bulan) — Mengintegrasikan penjelasan dan pembuatan draf

Saya tegaskan bahwa tahap 2 (voice_lint) saja sudah memberi efek besar. Insiden "raja yang kasar" di depan persis jenis yang tertangkap hanya dengan tahap ini.

Kegagalan yang berulang dalam proses pengenalan pun hampir sudah pasti.

• Membuatnya bertipe penolakan otomatis → kembalikan ke struktur kandidat curiga + putusan manusia
• Rulebook dioperasikan terpisah dari penulis naskah → jadikan kesepakatan penulis naskah wajib untuk mengubah rulebook, dan beri penulis naskah kemampuan meminta perubahan rulebook
• voice_profile sekadar formalitas → isi penuh 5 item dengan 1 karakter dulu, baru perluas
• Tidak tahu di mana hasil pemeriksaan berada → wajibkan pelampiran otomatis ke komentar permintaan perubahan
• Menyuruh LLM melakukan pemeriksaan itu sendiri → pemeriksaan dengan aturan, hanya penjelasan dengan LLM
• Meninjau setelah rekaman → tinjauan selesai di tahap teks. Jangan melewati rentang yang dapat dibalik

Item terakhir lebih mahal daripada semua item di atas. Kegagalan lain kehilangan waktu, tetapi kegagalan ini kehilangan jadwal pengisi suara.

Pada bab berikutnya (5.3) kita membahas alur menulis teks naratif dengan bantuan AI alih-alih pemeriksa. Kita akan melihat cara menyuntikkan nada L0 dan aturan L1 sebagai konteks, sehingga AI menghasilkan jawaban dunia kita, bukan jawaban yang umum.

Poin-Poin Penting

• Insiden konsistensi terjadi bukan karena aturannya tidak ada, melainkan karena aturannya tidak menyebar sampai ke teks.
• Pemeriksa harus hanya mengangkat sampai kecurigaan dan putusan dilakukan manusia, agar pemeriksa tidak dibuang.
• Semua tinjauan konsistensi harus selesai di tahap teks (dapat dibalik) sebelum rekaman.

Pratinjau Bab Berikutnya

• 5.3. Penulisan Naratif Berbantuan AI — Penyuntikan konteks nada L0 dan aturan L1

Coba Sendiri

setup — Pilih 1 karakter dari character_bible dan isi penuh 5 item voice_profile (ragam kosakata, panjang kalimat rata-rata, sapaan hormat, ekspresi emosi, ungkapan terlarang) dalam bentuk yaml. Ambil 10 baris dialog lama dari karakter yang sama dari dialogue_id_table dan kumpulkan dalam satu berkas.

prompt — Pakai apa adanya prompt bantuan pemeriksaan dari worked transcript di atas. Intinya dua batasan. "Jangan memberi putusan" dan "katakan hanya sampai dicurigai \~". Lampirkan voice_profile yaml dan 10 baris dialog pada masukan.

verify — Putuskan sendiri satu per satu baris kandidat curiga yang dikeluarkan. Kalau pelanggaran sungguhan perbaiki teks, kalau perubahan yang disengaja tambahkan flag pengecualian ke voice_profile. Periksa juga apakah AI memaksakan "item yang bukan pelanggaran" sebagai pelanggaran, dan apakah ia mengakui "kekurangan informasi". Kalau AI menyimpulkan semua item sebagai pelanggaran, perkuat batasan "jangan memberi putusan" pada prompt.

Versi Ringkas Solo

Kalau Anda pengembang solo tanpa 4 jenis pemeriksa maupun rulebook, Anda bisa mencapai efek yang sama hanya dengan satu prompt, tanpa badan pemeriksa. Cukup pelihara voice_profile yaml per karakter dengan tangan, dan setiap kali menulis dialog baru, lampirkan yaml karakter terkait + dialog baru ke prompt bantuan di atas untuk menerima "kandidat curiga". Memang tak ada otomasi, tetapi struktur intinya — putusan oleh manusia, AI memberi penjelasan — tetap hidup sama persis. Cukup patuhi satu baris saja — lewati tinjauan ini satu kali sebelum menyerahkannya ke rekaman atau sintesis suara. Prinsip tidak melewati tahap yang dapat dibalik tak ada hubungannya dengan ukuran tim.

5.3 Penulisan Naratif dengan Bantuan AI

Hari itu saya sedang menyusun dialog pertama untuk sebuah NPC sampingan baru. Ke dalam jendela obrolan yang kosong saya ketik, "Buatkan 5 dialog untuk NPC pandai besi desa." Lima detik kemudian muncul di layar, "Wahai pahlawan, percayakanlah senjatamu kepadaku." Kalimat itu bukan sekadar terasa pernah saya lihat di suatu tempat — saya bahkan seolah tahu persis di mana saya pernah melihatnya. Jika prompt yang sama saya masukkan ke game lain dari tim lain, jawabannya pun pasti sama persis. Yang saya sadari saat itu bukanlah bahwa modelnya lemah, melainkan bahwa saya sama sekali tidak memberi tahu model apa pun tentang game kami.

AI piawai menulis kalimat fantasi yang umum. Namun, AI tidak bisa menulis kalimat dunia kita. Perbedaannya cuma satu: injeksi konteks. Jika tone L0 dan rule L1 dikirim bersama pada setiap permintaan, satu baris yang dikeluarkan AI berubah dari "kalimat yang terasa pernah dilihat di suatu tempat" menjadi "kalimat game ini." Bab ini membahas praktik mengoperasikan injeksi itu dalam empat lapisan, dan di akhir menyoroti penerapan progresif yang mengangkat prinsip yang sama ke skala simulasi dunia (Behavior Tree dunia (BehaviorTree, pohon perilaku) + awan quest) sebagai garis terdepan RnD.

5.3.1 Apa yang Terjadi Ketika Konteks Kosong

Di bidang naratif, bantuan AI adalah area yang paling cepat diadopsi dan paling cepat kehilangan kepercayaan. Sebabnya, pola kegagalannya hampir selalu sama.

Jika Anda lempar "5 dialog pembuka quest," yang kembali adalah 5 jenis fantasi umum yang diawali dengan "Wahai pahlawan, desa kami ini...". Jika Anda minta "Tolong perbaiki dialog karakter ini," voice-nya jadi rata sehingga semua NPC menyatu ke gaya bicara yang mirip-mirip. Jika Anda minta "Tuliskan sinopsis Bab 1," yang keluar adalah nilai rata-rata dari sinopsis-sinopsis RPG yang pernah dilihat.

Masalahnya bukan pada model, melainkan pada konteks yang kosong. Model mengeluarkan rata-rata dari data pelatihannya. Jika Anda tidak menginginkan rata-rata, Anda harus memberi petunjuk yang menjauhkannya dari rata-rata. Tema bab ini adalah bagaimana membuat dan menginjeksikan petunjuk itu.

Pada proyek MMORPG yang saya kelola (selanjutnya disebut Proyek A), bantuan AI naratif menumpuk empat lapisan konteks secara berurutan. Struktur yang di 5.1 menguraikan NarrativeDocs menjadi Layer 0\~4 itu, di sini dipakai ulang persis sebagai unit injeksi.

Tidak setiap kali keempat lapisan dimasukkan semua. Hanya lapisan yang diperlukan yang dikeluarkan sesuai jenis tugas. Untuk draf dialog berikutnya dari satu karakter, cukup A + B (tone saja) + D (10 baris dialog terakhir karakter itu). Untuk sinopsis quest sampingan baru, ditambahkan C (rule struktur quest). Untuk 4 opsi hasil percabangan, C (rule percabangan) + D (seluruh teks tepat sebelum percabangan) menjadi lebih berat. Ibarat memilih lembar persona, satu baris worldview, halaman rulebook, dan seikat teks berdekatan dari laci dokumen di atas meja, lalu mengirimnya sesuai ukuran tugas.

5.3.2 Satu Worked Transcript (rekaman sesi nyata) — Dialog Emosional Pertama K_007

Alih-alih menjelaskan secara abstrak, saya akan mengikuti satu permintaan nyata sampai tuntas. Tugasnya adalah menyusun 3 opsi dialog untuk adegan di mana karakter yang sama (NPC bertipe sarjana, ID internal K_007) untuk pertama kalinya harus menunjukkan emosi. Saya mulai dari prompt selengkapnya.

Prompt yang dikirim (Layer A + B (tone) + D + instruksi tugas + format keluaran):

[SISTEM]
Kamu penulis naratif Proyek A. Jangan pakai klise RPG seperti "pahlawan" atau "sang terpilih",
ikuti tone gaya bicara dari dialog terakhir di bawah persis seperti itu. Jangan mengarang latar yang tidak kamu ketahui,
jawab saja "Tidak bisa ditentukan dari konteks". Kamu cuma membuat draf, keputusan ada di tanganku.

[Tone L0 — kutipan tone_manifesto]
Emosi dunia ini adalah pengendalian diri. Tokoh tidak mudah mengucapkan perasaannya.
Emosi muncul bukan sebagai ledakan, melainkan sebagai retakan. Elipsis dan kalimat pendek.

[Referensi — 5 dialog terakhir K_007 (urut waktu, apa adanya)]
1. "...itu pun baru pertama kali saya dengar."
2. "Ada catatannya? Kalau tidak ada, kita harus meragukannya."
3. "Jangan bergerak sampai semuanya pasti."
4. "Sekian pendapat saya."
5. "...Maaf. Apa saya terlalu dingin tadi?"

[Situasi]
NPC rekan kembali dalam keadaan terluka. Untuk pertama kalinya sang sarjana harus menunjukkan emosi.

Cukup 3 opsi saja, masing-masing maksimal 25 karakter. Bubuhkan label di akhir tiap opsi (tipe reaksi: marah/sedih/menyangkal),
dan hilangkan penjelasan atau kata pembuka.

Keluaran mentah Claude (apa adanya, tanpa ringkasan atau penyuntingan):

1. "...kenapa kamu pikul itu sendirian. Bodoh sekali." (tipe reaksi: sedih)
2. "Mestinya kulihat catatannya. Aku, aku terlewat." (tipe reaksi: menyangkal)
3. "Tidak apa-apa. Semua baik-baik saja. Jadi berhenti—" (tipe reaksi: menyangkal)

Yang penting adalah tidak berhenti di sini. Penulis membaca ketiga opsi dan memverifikasinya. Opsi 1 tone-nya pas. Retakan yang ditunjukkan "...Maaf" pada dialog terakhir nomor 5 dilanjutkan oleh opsi 1 lewat satu kata, "Bodoh sekali." Ini kandidat untuk dipakai. Opsi 2, gagapnya "Aku, aku terlewat" sedikit menyimpang dari pengendalian diri sang sarjana. Ditahan. Opsi 3 labelnya salah. Mengulang "Tidak apa-apa" itu bukan menyangkal melainkan lebih dekat ke menghindar, padahal di voice_profile kita tidak ada pola sang sarjana memproses emosi dengan menghindar. Ditolak.

Permintaan ulang (dikirim kembali dengan alasan penolakan dijelaskan):

Opsi 3 ditolak. Pengulangan "Tidak apa-apa" bukan pola sarjana ini. Dia memproses emosi
bukan sebagai penghindaran, melainkan sebagai 'menyalahkan diri atas kegagalan memverifikasi fakta'. Opsi 1 akan kupakai.
Untuk posisi opsi 2 dan 3, beri lagi dua opsi yang nuansanya berbeda dari opsi 1. Tanpa gagap, maksimal 25 karakter.

Keluaran kedua Claude:

2. "Catatan tidak berbohong. Akulah yang tak melihatnya." (tipe reaksi: menyalahkan diri)
3. "...Duduklah. Lukanya dulu. Bicara nanti." (tipe reaksi: sedih)

Kali ini keduanya lolos. Opsi 2 memakai ulang "catatan", kosakata inti sang sarjana (dialog terakhir nomor 2 "Ada catatannya?"), sebagai medium menyalahkan diri; opsi 3 lewat bentuk perintah yang terkendali menunjukkan pola sang sarjana menekan emosi menjadi tindakan. Yang akhirnya dipakai adalah opsi 1 + opsi 2 + opsi 3. Ketiga baris ini, setelah lolos pemeriksaan otomatis voice_lint dari 5.2, dimasukkan ke teks L2 dan menerima dialogue_id di L3.

Dalam satu transcript ini terkandung segala isi bab ini. Injeksi tone (L0) menyelamatkan opsi 1, teks berdekatan apa adanya (L2) membuat kosakata "catatan" milik sang sarjana dipakai ulang pada permintaan ulang, pemaksaan format keluaran mencegah obrolan basa-basi, dan gerbang penolakan penulis menyaring label keliru pada opsi 3. AI tidak menentukan satu baris pun secara final.

5.3.3 Layer A — System Prompt, Satu Baris Menentukan Segalanya

Inilah definisi persona yang menjadi alas paling atas. Ditetapkan sekali dan hampir tidak diubah. Blok sistem pada transcript di atas adalah wujud nyatanya. Dari kelima baris, baris terakhir ("Penulisan draf, keputusan ada di penulis") yang paling penting. Jika baris ini hilang, AI dengan percaya diri menyodorkan kalimat yang berpura-pura "final", dan penulis pun bukan memeriksa melainkan menilai. Lalu baris ketiga ("Jangan membuat latar yang tidak diketahui, jawab tidak bisa ditentukan") adalah yang kedua terpenting. Tanpa baris ini, model mengisi ruang kosong dengan kebohongan yang masuk akal. Dalam naratif, kebohongan yang masuk akal akan kembali beberapa hari kemudian sebagai benturan lore.

5.3.4 Layer B — Posisi Visi L0 dan Caching

L0 berukuran kecil (sekitar 4.5 bab menurut acuan 5.1). Hampir selalu bisa diinjeksikan seluruhnya tiap kali. Berdasarkan perkiraan dengan acuan bahasa Korea, world_premise.md sekitar 2,500 token, narrative_pillar.md sekitar 1,500 token, tone_manifesto.md sekitar 3,000 token, totalnya sekitar 7,000 token. (Angka-angka ini adalah perkiraan penulis dan belum terverifikasi. Nilainya berbeda tergantung tokenizer dan revisi dokumen.)

Mengirim 7,000 token baru pada setiap permintaan akan menumpuk biaya. Karena itu kita pasang prompt caching. Ini fitur yang didukung baik oleh Anthropic maupun OpenAI, dan saat cache hit biaya token masukan turun drastis. Intinya adalah memisahkan yang berubah dari yang tidak berubah di dalam pesan.

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},
    {"role": "user", "content": [
        {"type": "text", "text": L0_FULL,      "cache_control": {"type": "ephemeral"}},
        {"type": "text", "text": L1_SELECTED,  "cache_control": {"type": "ephemeral"}},
        {"type": "text", "text": L2_ADJACENT},   # berubah tiap kali — tidak di-cache
        {"type": "text", "text": TASK_INSTRUCTION},  # berubah tiap kali
    ]},
]

L0 dan L1 yang dipasangi cache_control adalah target cache, sedangkan teks berdekatan L2 dan instruksi tugas berubah tiap kali sehingga tidak di-cache. Selalu mengumpulkan blok cache di bagian depan pesan adalah yang menentukan tingkat hit. Jika blok yang berubah terselip di depan, semua cache setelahnya menjadi tidak valid. Mengacaukan urutan ini adalah penyebab paling umum mengapa biaya tidak turun meski caching sudah diaktifkan.

Rincian angka tingkat cache hit dan penghematan biaya dibahas di bab Part 22 (biaya). Di sini cukup mengingat prinsip "dorong yang berubah ke belakang".

5.3.5 Layer C — Jangan Memasukkan Rule L1 Seutuhnya

Rulebook L1 berukuran besar, sehingga jika dimasukkan semua konteks akan meledak, dan yang lebih buruk, model justru kehilangan inti. Pilih hanya rule yang relevan dengan tugas, itu pun cuma bagian _summary-nya.

Saat menyusun hasil percabangan main quest, pilih dialogue_branching_rule dan faction_relation_matrix. Untuk dialog NPC baru, voice_profile dan tone_manifesto NPC yang bersangkutan. Untuk entri baru kamus lore, lore_consistency_rule dan world_premise. Untuk kerangka quest sampingan, quest_template dan reputation_model. Pemilihan dilakukan langsung oleh manusia atau diekstrak otomatis dengan menelusuri graf wikilink (Part 7), dan saat ekstraksi otomatis, recall diutamakan di atas precision. Sebab kerugian satu rule terlewat jauh lebih besar daripada kerugian satu rule berlebih masuk.

Alih-alih memasukkan seluruh isi rulebook, taruh bagian _summary di kepala file rulebook dan injeksikan hanya itu.

---
title: Rule Percabangan
layer: L1
---

## _summary
- Percabangan hanya terjadi di akhir bab
- Percabangan 2~3 opsi. Dilarang 4 opsi atau lebih
- Pilihan percabangan memengaruhi reputasi +/-1, percabangan akhir +/-3
- Semua hasil percabangan harus menunjukkan hasilnya dalam 24 jam
- Percabangan tidak dapat dibalik (UI yang menyarankan pemisahan save ditampilkan)

## 1. Rule titik waktu terjadinya percabangan
(Penjelasan rinci, untuk acuan operator — tidak diinjeksikan ke LLM)
...

5 baris _summary lebih efektif bagi kualitas keluaran LLM daripada 50 baris isi. Model lebih patuh pada aturan yang pendek dan tegas. Penjelasan panjang memecah perhatian model, dan perhatian yang terpecah kembali sebagai pelanggaran aturan.

5.3.6 Layer D — Teks Berdekatan Jangan Diringkas

Dialog langsung sebelumnya, quest berdekatan, sinopsis bab yang sama. Ini konteks dengan fluktuasi terbesar. Untuk dialog baru karakter yang sama, masukkan 10 baris dialog terakhir karakter itu menurut urutan waktu; untuk quest pertengahan bab, masukkan sinopsis bab dan ringkasan 1 baris quest-quest di bab yang sama; untuk akhir hasil percabangan, masukkan seluruh teks tepat sebelum percabangan dan teks pilihan. Jika dimasukkan terlalu banyak, LLM mengeluarkan rata-rata; jika terlalu sedikit, keluaran jadi tergeneralisasi. Titik optimalnya berada di antara 1,500\~3,000 token (menurut pengamatan penulis, belum terverifikasi).

Satu aturan inti. Teks berdekatan dimasukkan apa adanya tanpa diolah atau diringkas. Pada transcript di atas, karena 5 baris dialog terakhir sang sarjana dimasukkan tanpa disentuh, model bisa menangkap persis kata "catatan" pada tahap permintaan ulang dan memakainya kembali sebagai medium menyalahkan diri. Andai kelima baris itu diringkas menjadi "Sang sarjana itu cermat dan dingin" lalu dimasukkan, seluruh pilihan halus penulis akan lenyap dan model kembali lagi ke rata-rata. Meringkas bukan mengurangi informasi, melainkan menghapus keputusan yang sudah diambil penulis.

5.3.7 Alur Kerja Tinjauan Penulis — Memakai Tingkat Pembuangan sebagai Metrik

Keluaran AI selalu draf. Tinjauan melewati gerbang yang sudah ditetapkan.

flowchart TD
    A[N keluaran AI] --> B[Tahap 1: voice_lint otomatis
5.2]
    B --> C[Tahap 2: pemilihan·penyuntingan oleh satu penulis
sekitar 15 menit]
    C --> D{Ada yang dipakai?}
    D -->|Ada| E[Tahap 3: kesepakatan lead narrative
jika perlu]
    D -->|0 dipakai = semua dibuang| F[Minta ulang atau tulis sendiri]
    E --> G[Dimasukkan ke teks L2
+ terbitkan dialogue_id L3]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class B code;
    class A ai;
    class C,D,E human;
    class G pass;
    class F fail;

Kasus penulis memilih 0 dari N opsi (semua dibuang) pun normal. Sebagaimana opsi 3 ditolak pada transcript di atas, penolakan bukanlah kegagalan melainkan bukti bahwa gerbang bekerja. Karena itu tingkat pembuangan diukur per penulis dan per karakter, lalu dijadikan metrik kualitas injeksi konteks.

Tingkat pembuangan 0\~20% berarti operasi stabil dengan konteks yang memadai, jadi biarkan apa adanya. 20\~50% adalah rentang operasi umum, jadi cukup dipantau. Jika naik ke 50\~80%, periksa ulang apakah pemilihan rule L1 ada yang terlewat. Jika melewati 80%, itu bukan masalah rule individual melainkan system prompt atau persona itu sendiri yang menyimpang, jadi tulis ulang Layer A. Tingkat pembuangan dihimpun per penulis seminggu sekali dan dibagikan dalam retrospektif.

Namun, tingkat pembuangan bukan metrik mutlak. Karakter yang berubah cepat (misalnya titik balik di mana untuk pertama kalinya menunjukkan emosi, seperti K_007 pada transcript di atas) wajar saja punya tingkat pembuangan tinggi. Angka adalah awal percakapan, bukan vonis.

5.3.8 Keamanan — Bagaimana Mencegah Kebocoran Konteks

L0\~L1 adalah IP inti game. Jika mengirimkannya apa adanya ke API LLM eksternal terasa membebani, pilihan pun bercabang. Memakai API eksternal apa adanya dengan kontrak tanpa-pelatihan adalah cara tercepat, tetapi butuh tinjauan hukum. Cara mengganti nama perusahaan dan nama diri menjadi placeholder lalu mengirimnya menambah biaya pemrosesan dan merusak kealamian. Self-hosting (model terbuka) aman bagi data tetapi beban kualitas dan operasinya besar. Hibrida yang menaruh L0 di internal dan hanya mengirim draf ke luar rumit dalam pengoperasiannya.

Proyek A milik penulis memakai cara pertama (API eksternal + kontrak tanpa-pelatihan). Cara kedua pernah dicoba lalu ditinggalkan. Sebab penggantian placeholder meratakan teks menjadi bentuk "Sarjana ○○ dari Kerajaan ○○ berbicara tentang ○○" dan meruntuhkan kualitas keluaran. Anonimisasi yang mematikan kualitas adalah trade-off yang berulang di sepanjang buku ini (lihat bab anonimisasi Part 1). Dalam naratif, kerusakan itu terutama besar. Sebab nama diri itu sendiri adalah tone.

5.3.9 Kegagalan Umum dan Penanganannya

Jika hanya melempar instruksi tugas tanpa system prompt, yang keluar rata-rata. Pasang persona dan pantangan lebih dulu. Jika menginjeksikan L0 seluruhnya tiap kali tanpa memakai caching, biaya bocor. Kumpulkan blok cache ke depan. Jika memasukkan rulebook L1 seutuhnya, model kehilangan inti. Ambil hanya bagian _summary. Jika memasukkan teks berdekatan yang diringkas, pilihan penulis terhapus. Kutip apa adanya. Jika tidak menetapkan format keluaran, sebagian besar respons diawali dengan "Berikut 3 kandidat:", dan menyusul pula insiden penulis salah mengira kata pembuka itu sebagai isi teks. Tentukan jumlah, panjang, dan label secara eksplisit. Jika keluaran AI dipakai sebagai final, gerbang tinjauan runtuh. Selalu loloskan melalui gerbang penulis. Jika tingkat pembuangan tidak diukur, kesehatan alat bergantung pada kesan manusia. Himpun secara mingguan dan bagikan dalam retrospektif.

5.3.10 Dari Penerapan Konservatif ke Penerapan Progresif

Sejauh ini adalah penerapan konservatif. Penulis menginjeksikan konteks dengan saksama, dan AI hanya membuat draf baris demi baris. Unitnya adalah tugas kecil seperti "3 opsi dialog berikutnya karakter ini" atau "sinopsis quest ini". Stabil, tetapi punya keterbatasan pada skala produksi massal dan responsivitas dinamis.

Di sini saya tegaskan dulu satu hal. Procedural generation, simulasi dunia, dan quest dinamis adalah visi yang sudah digambar para Game Designer di atas kertas sejak 20\~30 tahun lalu. PCG berbasis rulebook deterministik menangani area numerik seperti ruang dungeon, opsi senjata, dan distribusi spawn, tetapi belum menyentuh teks bahasa alami, persona karakter, percabangan naratif, dan dialog NPC. Sebagian besar perancangan, boleh dibilang, tetap tertahan di atas kertas. Kemajuan LLM dan model gambar pada 2024\~2026 membawa area itu ke posisi yang bisa diimplementasikan. Makna inti dari kemajuan AI bukanlah skor model, melainkan terbukanya kelayakan realisasi atas perancangan yang lama tertahan di kertas. Hanya saja, terbukanya kemungkinan dan menetapnya menjadi sistem yang dapat dioperasikan adalah dua persoalan yang berbeda.

Penguraian Layer Adalah Prasyarat Procedural Generation

Penguraian Layer 0\~4 di 5.1 bukan sekadar penataan, melainkan prasyarat procedural generation. Bagaimana kelima lapisan masing-masing berpadanan dengan tahapan tertentu pipeline pembangkitan (L0 jangkar → rulebook L1 → teks L2 → numerik L3 → gerbang L4) sudah dibahas di §6.6 dan 5.1.11. Intinya satu — di atas dokumen yang menggumpal jadi satu, generator tidak bisa menentukan dari mana harus membaca dan ke mana harus menulis, konteks mengabur karena tak tahu di mana L0 berada, dan L1·L2 berbenturan dalam satu file sehingga lini produksi runtuh. Penguraian Layer ada lebih dulu, dan di atasnya procedural generation bekerja. Di sini, prasyarat itu diterapkan pada tahap produksi massal bantuan AI naratif.

Kerangka Penerapan Progresif — Awan Quest

Tiga elemen terikat menjadi satu. Pertama, NPC Persona dibangkitkan secara prosedural. NPC utama adalah tangan penulis, tetapi NPC sampingan diproduksi massal oleh pipeline generator·Squad dari 6.2\~6.3. Tiap Persona dibubuhi tag (profesi·faksi·kecenderungan·peran) bersama voice_profile. Kedua, Behavior Tree dunia menempati posisi di atas Squad. Jika Squad mengikat perilaku satu kelompok NPC di sebuah area perburuan, Behavior Tree dunia di atasnya menerima nilai akumulasi perilaku pemain dan memperbarui status seluruh dunia. Faksi mana yang dibantu pemain, wilayah mana yang sering dikunjungi, keputusan apa yang diambil — semua itu mengguncang status node Behavior Tree dunia, dan node yang terguncang terpantul ke nilai (reputasi·minat·prioritas) NPC dalam jangkauan pengaruhnya. Ketiga, quest mengikuti model awan. Semua quest selain main quest dibangkitkan secara prosedural, lalu melayang-layang sambil membawa tag (siapa·di mana·kenapa·kapan) dan kondisi pemunculan. Tidak ada quest yang terpaku pada NPC tertentu.

Pemunculan melalui lima tahap.

flowchart TD
    P[1. Akumulasi perilaku pemain
dukungan faksi·kunjungan wilayah·keputusan] --> W[2. Perubahan status node Behavior Tree dunia
pembaruan status dunia di atas Squad]
    W --> N[3. Perubahan nilai NPC
reputasi·minat·prioritas]
    N --> M[4. Tag NPC + nilai == kondisi pemunculan
pembangkitan kunci pencocokan]
    M --> Q[5. Pemunculan quest yang cocok
dari awan quest]
    Q -.->|ditampilkan setelah lolos gerbang penulis| PL[Muncul ke pemain]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class M code;
    class P,W,N,Q data;
    class PL pass;

Dengan perumpamaan, quest bukan terselip di rak perpustakaan melainkan awan yang melayang-layang di udara. Ketika NPC mencapai suatu status tertentu, awan yang cocok untuknya turun dan tergenggam di tangan. Dalam struktur ini, AI bukan asisten yang menulis satu baris melainkan menangani tiga hal sekaligus. Teks bahasa alami (deskripsi·dialog) Persona dan quest yang dibangkitkan secara prosedural, perubahan kosakata saat status Behavior Tree dunia terpantul ke NPC (mempertahankan voice_profile yang sama tetapi topiknya berubah mengikuti status dunia), dan pengklasifikasi kecurigaan pada tahap verifikasi (bolehkah quest ini muncul pada NPC ini).

Batas Tak Dapat Dibalik — Tinjauan Harus Selesai di Tahap Teks

Dalam penerapan progresif pun, batas dapat-dibalik/tak-dapat-dibalik (5.4.5) tetap hidup. Jika dialog quest yang muncul dari awan mengalir ke pipeline suara tanpa lolos tinjauan, ia tidak bisa dikembalikan dengan rollback kode. Karena itu, menaruh semua gerbang tinjauan (voice_lint, pengklasifikasi kecurigaan, gerbang penulis) di depan batas tak-dapat-dibalik adalah pengaman penerapan progresif. Karena produksi massal otomatis bertambah, gerbang ini harus lebih kokoh daripada di penerapan konservatif.

Di Mana Berhenti, dan Mengapa Tidak Berhenti

Buku ini tidak membahas bentuk paripurna penerapan progresif. Itu setara dengan satu buku tersendiri, dan prasyarat infrastruktur berbeda di tiap perusahaan dan proyek. Cukup ingat dua hal. Pertama, tim yang tidak bisa melakukan penerapan konservatif juga tidak akan bisa penerapan progresif. Jika gerbang tinjauan tidak berjalan di penerapan konservatif, awan akan mengamuk di penerapan progresif. Agar operasi bertahan hidup, harus tersedia bersama-sama: infrastruktur procedural generation, alat definisi·pengujian node Behavior Tree dunia, klasifikasi kecurigaan otomatis quest yang muncul + gerbang penulis, pelacakan serentak tingkat pemunculan·tingkat pembuangan·kepuasan pemain, serta penarikan·penggantian otomatis quest yang muncul keliru. Jika satu dari lima ini terlewat, ia dibuang dalam satu kuartal. Sebab insiden konsistensi membludak dan tinjauan manusia tak mampu menyusul.

Berikutnya, penerapan progresif bukan alat untuk menambah produksi massal, melainkan alat untuk menambah responsivitas dinamis. Jika hanya mengincar produksi massal, rata-rata RPG umum akan memenuhi seisi awan, dan pemain bertemu dunia yang "tampak lebih beragam tetapi lebih kosong". Meski begitu, jalur ini tidak melulu berbahaya. Area ini adalah garis terdepan RnD perancangan game. Di titik tempat procedural generation, simulasi, dan LLM bertemu, peluang munculnya bentuk game yang benar-benar baru paling tinggi. Walau jarang langsung diterapkan di perusahaan saat ini, ia layak ditengok sebagai salah satu arah untuk 5\~10 tahun ke depan.

5.3.11 Mengikuti Satu Bab Sampai Tuntas

Berikut prosedur untuk mereproduksi persis penerapan konservatif bab ini.

setup. Gabungkan tiga file L0 (world_premise.md·narrative_pillar.md·tone_manifesto.md) menjadi satu teks dan tampung dalam variabel L0_FULL. Tulislah system prompt persis seperti lima baris pada transcript di atas, tetapi jangan menghilangkan baris terakhir ("Penulisan draf, keputusan ada di penulis"). Kumpulkan 10 baris dialog terakhir karakter yang dialognya akan disusun sebagai teks apa adanya.

prompt. Susunlah pesan dalam urutan [SISTEM] → [Tone L0] → [Referensi: dialog terakhir apa adanya] → [Situasi] → [format keluaran]. Pada format keluaran, wajib nyatakan secara eksplisit "tepat N opsi / jumlah karakter maksimum tiap opsi / label / selain itu sama sekali dilarang". Pasang cache_control hanya pada L0 dan L1, dan dorong blok yang berubah ke belakang pesan.

verify. Verifikasilah N opsi yang diterima baris demi baris. Periksa apakah tone berlanjut dengan dialog terakhir, apakah label cocok dengan reaksi sebenarnya, dan apakah pola yang tidak dipakai karakter kita (menghindar·gagap, dll.) terselip masuk. Untuk opsi yang akan ditolak, mintalah ulang dengan menyatakan alasannya. 0 opsi dipakai pun normal, dan catatlah sebagai tingkat pembuangan. Hanya opsi yang lolos yang dilewatkan voice_lint, dimasukkan ke L2, dan diterbitkan dialogue_id-nya di L3.

Versi Ringkas Solo. Meski tanpa API, caching, dan voice_lint, intinya tetap sama. Cukup satu jendela obrolan ChatGPT/Claude. Setiap kali tempel 5\~10 baris dialog terakhir karakter di paling depan, selalu bubuhkan 3 baris format keluaran, dan untuk jawaban yang akan ditolak, tuliskan alasannya lalu minta ulang. Sebagai ganti caching, jika Anda mempertahankan thread percakapan yang sama, konteks sebelumnya tetap tertinggal apa adanya. Untuk tingkat pembuangan, cukup hitung dengan tangan di selembar kertas seperti "minggu ini dipakai 12 / total 30". Walau alatnya kecil, kerangka berupa injeksi empat lapisan dan gerbang tinjauan bekerja sama persisnya bagi penulis solo.

Poin-Poin Penting

• Jika satu lapisan saja terlewat dari empat lapisan konteks (sistem·L0·L1·teks berdekatan), keluaran menyatu ke rata-rata
• Caching hidup dari pemisahan yang mendorong L0·L1 yang tidak berubah ke depan dan menunda teks yang berubah ke belakang
• Gerbang tinjauan dan tingkat pembuangan harus bekerja agar penerapan progresif (awan quest) pun tidak mengamuk

Pratinjau Bab Berikutnya

• 5.4. Konsistensi Dialog·Voice — mengekstrak·memperbarui voice_profile dengan AI dan meninjau voice

5.4 Konsistensi Dialog dan Voice

Bilik rekaman. Sutradara mengenakan headphone, mengangkat tangan untuk memberi aba-aba. Pengisi suara membacakan dialog seorang NPC ilmuwan. "Wah, ini benar-benar luar biasa." Tangan sutradara berhenti. Sepanjang lima bab, karakter ini belum pernah sekali pun memakai seruan "wah". Ia adalah ilmuwan yang tidak pernah mengucapkan kata kasar maupun seruan modern, dan selalu menggantung ujung kalimatnya hingga akhir. Namun di naskah, baris itu tertulis apa adanya.

Di sini dua biaya muncul sekaligus. Pertama, kalau baris itu diperbaiki, pengisi suara harus membacanya ulang. Honor pengisi suara dan waktu studio sudah berjalan seperti jam yang berdetak. Kedua, yang lebih menakutkan adalah ketika sutradara gagal menangkap baris itu dan melewatkannya. Begitu rekaman selesai dan berkas audio masuk ke build, ilmuwan itu akan berbicara seperti itu selamanya di dalam game. Audio yang sudah direkam tidak bisa dibatalkan dengan satu baris perbaikan seperti teks. Kita harus menjadwalkan ulang pengisi suara yang sama, dalam kondisi yang sama, di bilik yang sama.

Bab ini membahas garis putus-putus di depan bilik itu. Di atas garis putus-putus adalah teks, sehingga bisa diperbaiki tanpa batas; di bawah garis putus-putus adalah audio, sehingga tidak bisa diperbaiki. Semua tinjauan dialog harus selesai di atas garis putus-putus. Untuk itu, "orang ini berbicara seperti ini" untuk setiap karakter harus tercatat sebagai berkas, bukan sekadar di dalam kepala, dan setiap kali dialog baru diunggah, ia harus otomatis diadu dengan berkas tersebut. Berkas itu kita sebut voice_profile, dan alat pencocoknya kita sebut voice_lint.

5.4.1 Tempat di Mana Voice Goyah

Di antara insiden konsistensi naratif, yang paling sering meledak adalah goyahnya voice karakter. Baru setelah rilis, masuk laporan, "kenapa cara bicara NPC ini tiba-tiba berubah?" Penyebabnya hampir selalu sama.

Ketika penulis berganti, NPC yang sama menjadi orang yang berbeda. Meski penulisnya tidak berganti, setelah enam bulan berlalu ia sendiri lupa nada tokohnya. Ketika menulis dialog baru tanpa membuka kembali dialog karakter itu sebelumnya, konteksnya terputus. Kalau aturan voice hanya ada di kepala penulis dan tidak terdokumentasikan, ia tidak tersampaikan ke orang berikutnya. Dan penyebab kelima yang paling pesat bertambah dalam dua tahun terakhir — kalau kita melempar ke LLM "buatkan dialog NPC ini" tanpa informasi karakter, AI mengembalikan dialog yang rata-rata dan aman, sehingga menjadi bukan suara siapa-siapa (suara tak bertuan).

Yang kelima adalah efek samping dari adopsi AI. Injeksi konteks pada bab sebelumnya (5.3) adalah resepnya, tetapi kalau konteks yang akan diinjeksikan itu sendiri rapuh, tidak ada yang bisa diinjeksikan. Konteks itulah yang disebut voice_profile. Bab ini menelusuri satu siklus: membuat berkas tersebut, memeriksanya secara otomatis, dan mengakhirinya di depan bilik rekaman.

5.4.2 voice_profile — Suara yang Dikunci dengan Lima Butir

Di Proyek A, setiap NPC memiliki voice_profile dengan lima butir. Ranah kosakata (kelompok kata yang sering dipakai / kelompok kata yang sama sekali tak dipakai), panjang kalimat (rata-rata dan maksimum jumlah karakter), sistem penghormatan (kata ganti orang pertama dan kedua, proporsi bahasa hormat, sebutan), ekspresi emosi (cara mana di antara langsung, tak langsung, atau ditahan), dan ungkapan tabu (kata atau frasa yang sama sekali tak dipakai). Kelima butir harus disertai contoh konkret. Kalau hanya ada deskripsi abstrak seperti "ilmuwan yang serius", setiap orang membacanya secara berbeda. Penulis berikutnya akan membayangkan ilmuwan itu menurut caranya sendiri.

Format profil sesungguhnya dari NPC ilmuwan K_007 adalah seperti ini. Berkas inilah yang menjadi masukan bagi voice_lint.

---
title: K_007 voice_profile ilmuwan
layer: L1
character_id: K_007
atoms:
  - voice_profile_k_007
related:
  derives_from: [character_bible/k_007.md]
  affects: [dialogue_id_table (semua dialog K_007)]
---

## 1. Ranah Kosakata
- Sering: "catatan", "dasar", "situasi", "perkiraan", "data", "kasus"
- Sama sekali tak dipakai: "perasaan", "firasat", "takdir", "kehendak dewa", "suara hati"

## 2. Panjang Kalimat
- Rata-rata: 18 karakter
- Maksimum: 35 karakter (lebih dari itu dipecah jadi dua kalimat)
- Sering terputus pendek: "...bukan begitu." "Mulai dari catatan."

## 3. Sistem Penghormatan
- Orang pertama: "saya"
- Orang kedua: utamakan jabatan (Komandan, Panglima). Nama hanya setelah menjadi akrab.
- Bahasa hormat 100% (kecuali adegan kilas balik)
- Hampir tak ada seruan. Kalaupun ada, "...ah."

## 4. Ekspresi Emosi
- Nyaris tak ada ekspresi langsung (marah, gembira)
- Diungkapkan lewat keheningan dan ujung kalimat yang digantung ("...kalau memang begitu.")
- Kesedihan: dihindari dengan mengalihkan topik ("...mari bicara hal lain.")

## 5. Ungkapan Tabu
- Segala kata kasar
- Seruan modern "wah", "astaga", "luar biasa"
- Dua atau lebih kata serapan Han berjumlah tiga suku kata atau lebih dalam satu kalimat
- Kosakata mistis seperti "takdir", "ramalan"

Inti dari format ini adalah bahwa pada setiap tempat yang abstrak melekat baris contoh. Bukan "menahan emosi", melainkan dialog nyata "...kalau memang begitu." yang melekat. Dengan begitu penulis berikutnya, penerjemah, maupun voice_lint melihat tolok ukur yang sama. Kalau kita melihat ulang lima butir tersebut dengan mata penerjemahan dan lokalisasi, mereka terbagi menjadi dua jenis. Atribut bergantung pada bahasa (bentuk permukaan dari ranah kosakata, panjang kalimat, dan sistem penghormatan) harus ditetapkan ulang untuk setiap bahasa yang diterjemahkan, sedangkan atribut tak bergantung pada bahasa (sikap seperti apakah emosi ditahan atau diungkapkan langsung, apa yang tetap tak diucapkan sampai akhir) harus tetap terjaga ke dalam bahasa apa pun ia dipindahkan. Kalau pembedaan ini ikut diserahkan saat memberikan pekerjaan lokalisasi, kita bisa mencegah penerjemah hanya mengganti kosakata permukaan tetapi sampai menggoyahkan sikap karakter.

5.4.3 Worked Transcript: Menimba profile dari Naskah Utama

Kalau dari awal kita menulis 50 NPC × 5 butir = 250 berkas dari nol, hasilnya mengalir ke arah abstrak. Kalau kita menulis "karakter ini adalah ilmuwan yang dingin" tanpa satu baris pun dari naskah, tak seorang pun tahu seperti apa dinginnya itu. Maka kita balik urutannya. Hanya 5–7 NPC utama yang ditulis penuh sejak awal, sedangkan sisanya diekstraksi-balik profile-nya dari dialog setelah 20–30 baris dialog naskah terkumpul.

Berikut adalah worked transcript (rekaman sesi nyata) sesungguhnya, ketika draf profile ditarik setelah 25 baris dialog K_007 terkumpul. Tidak diringkas, dan tempat di mana AI keliru pun dibiarkan apa adanya.

[Prompt lengkap yang dilemparkan penulis]

Berikut 25 baris dialog karakter K_007.

1. "Mari mulai dari catatan."
2. "...situasinya tidak cocok."
3. "Itu hanya perkiraan. Tidak ada dasarnya."
4. "Kasus itu pun saya ketahui."
5. "...bukan begitu. Datanya berbeda."
   (... nomor 6~23 dikutip seluruhnya tanpa dipotong ...)
24. "...kalau memang begitu, saya mundur."
25. "Mari bicara hal lain."

Dari sini tariklah lima hal berikut: kosakata yang sering dipakai (hanya yang
benar-benar muncul), panjang kalimat rata-rata, pola penghormatan dan sebutan,
cara ekspresi emosi, dan ranah ungkapan yang sama sekali tak dipakai.
Untuk tiap butir, kutip 2~3 baris dialog sebagai dasar dengan nomornya, dan
jangan menulis kesan subjektif seperti "serius" atau "dingin".

[Keluaran mentah Claude — tidak dipoles]

1. Kosakata yang sering dipakai
   - "catatan" (no. 1), "situasi" (no. 2), "perkiraan/dasar" (no. 3),
     "kasus" (no. 4), "data" (no. 5)
   → Terpusat pada nomina kategori fakta dan bukti.

2. Panjang kalimat rata-rata
   - Rata-rata 25 baris sekitar 14.6 karakter. Terpanjang 21 karakter (no. 24).
   → Didominasi kalimat tunggal yang pendek.

3. Penghormatan dan sebutan
   - Orang pertama "saya" (no. 3, 24). Akhiran "-습니다/-요" bahasa hormat.
   - Sebutan orang kedua tidak muncul dalam 25 baris ini.
     → Pola sebutan tak bisa dipastikan hanya dari sampel ini. (Perlu konfirmasi penulis)

4. Ekspresi emosi
   - Tidak ada kata emosi langsung. Penolakan ditangani dengan "saya mundur" (no. 24),
     kesedihan/penghindaran dengan pengalihan topik "mari bicara hal lain" (no. 25).
   → Tipe ditahan dan tak langsung.

5. Ranah yang sama sekali tak dipakai
   - Seruan, kata kasar, dan kosakata mistis semuanya tak muncul.
   ※ Namun, "tak muncul" tidak menjamin "tabu".
      Karena sampel hanya 25 baris dan sedikit, bisa jadi ketidakmunculan yang kebetulan.

Di sini ada dua hal yang harus dicatat. Pertama, AI berhenti pada butir nomor 3. Ia sendiri menarik batas dengan mengatakan "tak bisa dipastikan hanya dari sampel ini". Karena sebutan tak muncul dalam 25 baris, ia tidak berspekulasi — inilah keluaran yang jujur. Seandainya AI mengisinya dengan "orang kedua diperkirakan 'Komandan'", itu adalah halusinasi, dan kalau masuk ke profile, itu kontaminasi. Kedua, pada butir nomor 5 AI sendiri menambahkan penyangkalan. "Tak muncul ≠ tabu" adalah peringatan inti. Tidak munculnya seruan dalam 25 baris bisa saja kebetulan.

[Verifikasi dan penolakan penulis]

Penulis menerima butir nomor 1, 2, dan 4. Untuk sebutan di nomor 3, ia membuka character_bible lalu mengisi secara manual "utamakan Komandan, nama setelah akrab" — manusia mengisi tempat yang dikosongkan AI. Untuk nomor 5, sesuai peringatan AI, ia tidak langsung menaikkan "tak muncul" menjadi "tabu". Alih-alih, dengan menimbang dari setelan karakter, penulis hanya memastikan "seruan modern, kata kasar, dan mistisisme" sebagai tabu, sedangkan kosakata lain yang tak muncul diberi status ditahan dulu.

[Permintaan ulang penulis]

"takdir", "ramalan" akan saya pastikan sebagai tabu. Tariklah 10 lagi kosakata mistis
yang maknanya tumpang tindih. Tapi karena K_007 sebagai ilmuwan bisa saja mengutipnya
dalam konteks pembantahan/kritik, tampilkan juga kasus pengecualian itu dalam satu baris.

Permintaan ulang terakhir inilah yang penting. Kalau tabu diperluas secara mekanis, sampai dialog yang sah pun ikut terhalang — seperti "ilmuwan yang mengkritik takhayul sambil berkata 'takdir apaan'". Maka untuk tabu, kita ikut mendefinisikan konteks pengecualiannya. AI memperluas kandidat, penulis menarik garis batasnya. Baru setelah memutar satu putaran ini, voice_profile_k_007 ditetapkan dan dikunci di L1.

Dengan memaksakan kutipan dasar ("kutip dengan nomor") dan melarang adjektiva subjektif ("dilarang 'serius'"), halusinasi AI berkurang dan tercipta permukaan yang bisa diverifikasi penulis. profile bukan ditulis AI, melainkan AI yang menghamparkan draf dan penulis yang menguncinya.

5.4.4 voice_lint — Pencocokan Otomatis untuk Setiap Dialog Baru

Kalau voice_profile tersedia sebagai berkas, pencocokan otomatis menjadi mungkin setiap kali dialog baru diunggah. Di antara lima pemeriksaan, yang efeknya besar di lapangan ada dua: pencocokan kosakata tabu (apakah kosakata tersangkut di daftar tabu) dan pelanggaran ranah kosakata (apakah masuk ke kelompok kata yang sama sekali tak dipakai). Penyimpangan panjang kalimat, hilangnya penghormatan, dan rasio kosakata yang sering dipakai banyak menimbulkan positif palsu (false positive), jadi dipakai sebagai pelengkap saja. Kalau kita sampai menangkap semua hal seperti satu baris adegan kilas balik yang menggoyahkan panjang rata-rata, penulis akan mati rasa terhadap peringatan.

voice_lint menerima kumpulan dialog baru per bab lalu mengeluarkan laporan seperti ini.

Hasil voice_lint (ch04 dialog baru 32 baris, profile=voice_profile_k_007)
─────────────────────────────────────────────
[Pelanggaran] dialogue_id_412 — K_007
  Isi: "Wah, ini benar-benar luar biasa!"
  Alasan: kosakata tabu "wah", "luar biasa" (profile §5)
  → Perlu tinjauan penulis

[Mencurigakan] dialogue_id_421 — K_007
  Isi: "Takdir itu sulit untuk diterima."
  Alasan: ranah kosakata tabu "takdir" (profile §5)
        Namun, mungkin pengecualian 'konteks pembantahan/kritik' — penilaian penulis
  → Perlu tinjauan penulis

[Normal] 30 dialog
─────────────────────────────────────────────
Ringkasan: pelanggaran 1 / mencurigakan 1 / normal 30

Pelanggaran ditandai merah, yang mencurigakan ditandai kuning. Keduanya harus melewati penilaian penulis untuk lolos. Di sini ada satu prinsip mutlak — voice_lint tidak menolak secara otomatis (perpanjangan dari prinsip 5.2). Lihat dialogue_id_421 di atas. "Takdir" memang tabu, tetapi kalau dalam konteks ilmuwan yang membantah takhayul, ia bisa jadi kutipan yang sah. Penilaian itu tak bisa dilakukan alat. lint bertipe penolakan otomatis akan menghalangi semua tempat yang lembut ini, sampai merampas kesempatan penulis untuk memoles nada. lint adalah senter yang menyorot titik-titik yang mencurigakan, bukan gembok yang mengunci pintu.

5.4.5 Gerbang Tinjauan — Garis Putus-Putus antara Dapat Dibalik dan Tidak Dapat Dibalik

Tulang punggung bab ini adalah satu lembar diagram berikut. Selama satu baris dialog berangkat dari tangan penulis hingga sampai ke mulut pengisi suara, gerbang tinjauan terhampar di setiap tahap. Dan di tengah-tengah alur itu ada garis putus-putus yang tebal.

flowchart TD
    A["Penulis menulis naskah (L2)"] --> B["voice_lint otomatis
laporan pelanggaran·mencurigakan"]
    B --> C["Penulis tinjauan mandiri (15 menit)"]
    C --> D["Lead naratif tinjauan sampel
sampel 10% per bab"]
    D --> E["Penerbitan dialogue_id L3
+ pemetaan kunci terjemahan"]
    E --> F["Tinjauan terjemahan·lokalisasi"]

    F -.->|"━━━ Batas dapat dibalik / tidak dapat dibalik ━━━
Di atas garis ini teks, dapat direvisi tanpa batas
Di bawah garis ini audio, tidak dapat direvisi"| G

    G["Casting VA"] --> H["Rekaman dubbing (final·tidak dapat dibalik)"]
    H --> I["Penerapan audio ke build"]

    classDef reversible fill:#e8f4ea,stroke:#3a7d44,stroke-width:1px,color:#1b3a22;
    classDef irreversible fill:#f7e3e3,stroke:#b23b3b,stroke-width:2px,color:#5a1414;
    class A,B,C,D,E,F reversible;
    class G,H,I irreversible;

Hijau adalah tahap dapat dibalik, merah adalah tahap tidak dapat dibalik. Di atas garis putus-putus (hijau) semuanya teks. Kalau satu baris dialog tidak berkenan, cukup perbaiki dengan papan ketik. Biayanya hanya beberapa menit penulis. Di bawah garis putus-putus (merah) adalah audio. Begitu pengisi suara membaca baris itu di bilik dan audionya masuk ke build, dialog itu terkunci sebagai aset. Untuk memperbaikinya, kita harus menjadwalkan ulang pengisi suara yang sama dalam kondisi yang sama di studio yang sama, dan honor pengisi suara, studio, serta waktu sutradara kembali habis persis seperti pertama kali. Kalau jadwalnya ketat, sesi tambahan dengan pengisi suara yang sama bahkan kadang tak bisa dijadwalkan sama sekali.

Maka satu aturan tunggal menguasai seluruh alur kerja — semua gerbang tinjauan selesai di atas garis putus-putus. Rekaman bukan tahap tinjauan. Ia adalah tahap mengunci hasil yang tinjauannya sudah selesai sebagai aset. Kalau di bawah garis putus-putus muncul keraguan "dialog ini aneh", itu bukan tempat untuk meninjau lagi, melainkan sinyal bahwa tinjauan di tahap atas terlewatkan. Senter harus menyorot tuntas di atas garis putus-putus. Bilik bukan tempat yang boleh gelap, melainkan tempat yang tidak boleh gelap.

Di tengah-tengah diagram, tinjauan sampel lead ditetapkan sebesar "sampel 10% per bab". Rasio ini adalah titik keseimbangan antara waktu tinjauan dan akurasi (angka operasional penulis, perkiraan belum terverifikasi). Kalau diturunkan di bawah 5%, insiden bocor; kalau dinaikkan di atas 20%, satu orang lead menjadi penghambat. Karena lint sudah menyaring pelanggaran dan yang mencurigakan terlebih dahulu, sampel ditarik dari bagian yang lolos lint — mata manusia berfokus pada kesalahan konteks yang tak bisa ditangkap alat (misalnya, kutipan "takdir" yang tampak sah ternyata adalah keruntuhan karakter).

5.4.6 Karakter Berubah — Manajemen Versi profile

Kalau karakter berbicara sama persis hingga akhir, plot menjadi mandek. Kalau ilmuwan yang mengalami kematian rekannya berbicara dengan nada yang persis sama seperti sebelumnya, justru itu palsu. Kalau perubahannya disengaja, voice_profile pun ikut dinaikkan versinya.

---
character_id: K_007
voice_profile_versions:
  - v1: ch01~ch05 (awal — emosi ditahan, ilmuwan berkalimat pendek)
  - v2: ch06~ch10 (setelah kematian rekan — frekuensi ekspresi emosi meningkat)
  - v3: ch11~ (setelah pencerahan — muncul gaya bicara langsung)
---

Setiap versi memiliki berkas profile tersendiri, dan voice_lint melihat nomor bab dari dialog yang diperiksa lalu memilih versi mana yang akan diterapkan. Kalau aturan "emosi ditahan" dari v1 diterapkan pada dialog ch07, semua dialog perubahan yang sebenarnya wajar akan muncul sebagai mencurigakan. Perubahan bukan bug, melainkan rancangan.

Sinyal untuk menaikkan versi ada tiga. Kalau penulis dengan sengaja menggoyahkan nada, ia mengusulkan versi baru dan menyepakatinya dengan lead. Kalau jumlah kasus mencurigakan dari voice_lint pada satu karakter terus bertambah, itu adalah sinyal bahwa penulis secara tak sadar sedang menggeser nada — bahwa saatnya pembaruan versi telah tiba. Kalau peristiwa perubahan (kematian, pencerahan, pengkhianatan) ditambahkan ke character_bible, muncul alert pembaruan profile. Namun, kalau satu karakter berubah pada setiap bab, konsistensi runtuh, jadi jumlah versi yang realistis adalah 2–4 per karakter.

[Penanda arah — kalau kita melihat antarkarakter melalui ruang voice (untuk saat ini masih terlalu dini)] Kalau voice_lint menjaga konsistensi 'di dalam satu karakter' lewat aturan, maka 'ruang voice' — yang menyematkan (embedding) kumpulan dialog nyata tiap karakter (seluruh dialog yang diucapkan satu karakter) sebagai satu titik — melihat apakah jarak 'antarkarakter' sudah cukup terbentang. Kalau titik-titik itu saling menggumpal mendekat, itu menjadi nilai ukur langsung dari penyeragaman dan konvergensi voice yang ditunjuk §5.3.1 dan §5.4.1. Hanya saja, jangan mengunci ambang jarak sebagai angka mutlak, dan bacalah hanya sebagai penanda arah 'sedang menggumpal'; ini bukan gerbang penilaian yang menggantikan voice_lint (gagasan ini berada di tempat yang sama dengan kompresi vektor dimensi pada §8.2.7, dan intuisi konsepnya telah diuraikan sebagai satu lembar peta di Lampiran M — ini bukan resep, melainkan penanda arah).

5.4.7 Unit Konsistensi yang Bertambah karena Multibahasa dan VA

Kalau dialog diterjemahkan ke banyak bahasa dan voice pengisi suara dilekatkan, unit yang dikelola bertambah berlipat ganda. Satu baris bahasa Korea bercabang ke bahasa Inggris dan bahasa Asia Tenggara, dan masing-masing diberi nada.

Tempat yang paling sering bocor dalam konsistensi terjemahan adalah ungkapan yang sama diterjemahkan berbeda di setiap bab (ditangkap dengan pemeriksaan konsistensi memori terjemahan). Diikuti oleh tidak terpantulnya voice_profile karakter ke dalam terjemahan (dilekatkan panduan terjemahan tersendiri per karakter), dan tidak terdaftarnya kosakata baru di glosarium (lint glosarium). Panduan terjemahan dibangkitkan secara otomatis dari voice_profile — "karakter ini gaya formal 100%, tanpa seruan, kosakata mistis tabu" dilekatkan secara otomatis di kepala lembar instruksi terjemahan. Saat penerjemah memindahkan ilmuwan itu ke bahasa Inggris, ia melihat batas yang sama.

Tinjauan VA (Voice Actor, pengisi suara) adalah tinjauan tahap teks yang masih dapat dibalik yang terakhir, tepat sebelum menyentuh bawah garis putus-putus. Konsistensi nada (intensitas ekspresi marah dan sedih) ditinjau sutradara dan tim naratif, akurasi pelafalan (nama diri) oleh penanggung jawab glosarium, serta tarikan napas dan jeda (instruksi seperti "sering terputus pendek" pada profile) oleh sutradara. Hasil tinjauan dicatat sebagai lolos atau ditolak di voice_review_log.md (L4), dan dirujuk saat casting karakter berikutnya.

Penolakan diselesaikan sebisa mungkin tepat sebelum casting dan rekaman. Kesalahan naskah yang ditemukan di dalam bilik meruntuhkan sesi hari itu sepenuhnya dan menggoyahkan hingga jadwal sesi berikutnya. Namun, menunda rekaman sambil mematikan tinjauan bukanlah jawabannya. Kalau tinjauan sering tersumbat tepat sebelum bilik, itu berarti alur kerja tahap atas (penulis, lead) yang terlambat, bukan masalah jadwal rekaman.

5.4.8 Pengukuran dan Biaya selama 6 Bulan

Di Proyek A, sebelum dan sesudah penerapan voice_profile + voice_lint ditelusuri selama 6 bulan. Jumlah absolutnya adalah perkiraan penulis (belum terverifikasi); cukup percayai arah dan rasionya saja.

Baris yang paling bermakna adalah jumlah NPC yang dikelola 1 penulis. Sekitar 2.5 kali bukan berarti kita mengurangi penulis, melainkan penulis yang sama bisa menambah keragaman NPC per bab. Dunia menjadi lebih ramai.

Kalau kita lihat struktur biayanya, biaya operasional jauh lebih kecil daripada biaya penerapan. Penulisan voice_profile memakan 2 minggu penulis untuk 7 karakter utama, alat voice_lint memakan 1\~2 minggu pengembangan dengan pemeliharaan 1 hari per bulan. Di sisi operasional, per bab ada tinjauan mandiri penulis 15 menit, tinjauan sampel lead sekitar 2 jam (sampel 10%), dan pembaruan profile pada bab perubahan sebesar 1\~2 hari per karakter. Biaya operasional harus kecil agar sistem bisa bertahan. Alat yang berat operasionalnya akan diam-diam ditinggalkan dalam satu kuartal.

5.4.9 Kegagalan yang Umum

Coba Sendiri — Satu Siklus voice_lint

Ketika dialog bab baru diunggah, ini adalah prosedur minimum untuk memutar satu putaran dengan satu profile.

setup 1. Bukalah voice_profile_<id>.md dari karakter sasaran. Kalau belum ada, kumpulkan 20–30 baris dialog naskah. 2. Siapkan dialog baru sebagai kumpulan teks polos berformat id / karakter / isi.

prompt

Ini voice_profile K_007 §5 (ungkapan tabu).
[tempelkan daftar tabu]

Dialog baru ch04 sebanyak 32 baris.
[tempelkan dalam format id / isi]

Klasifikasikan tiap dialog sebagai [Pelanggaran] (langsung memuat kosakata tabu) /
[Mencurigakan] (menyentuh ranah tabu tapi mungkin konteks pengecualian) / [Normal].
[Pelanggaran]·[Mencurigakan] tampilkan id·isi·alasan dalam tabel. Penilaian saya yang
lakukan, jadi jangan menolak secara otomatis.

verify 1. Lihat [Pelanggaran] lebih dulu. Kalau jelas, perbaiki teksnya (gratis karena di atas garis putus-putus). 2. [Mencurigakan] dinilai berdasarkan konteks. Kalau kutipannya sah, loloskan; kalau tidak, perbaiki. 3. Dari bagian yang lolos, kirim 10% sebagai sampel ke lead untuk sekali lagi menyaring kesalahan konteks. 4. Hanya setelah semua penilaian selesai, terbitkan dialogue_id dan teruskan ke antrean rekaman. Di depan bilik, tidak ada lagi pemeriksaan.

Versi Ringkas Solo — Kalau Anda pengembang solo yang tak bisa membuat alat, tulislah voice_profile hanya satu butir §5 (ungkapan tabu) per karakter. Setiap kali menulis dialog baru, lekatkan daftar tabu itu di kepala prompt lalu suruh AI "tandai hanya baris yang tersangkut di daftar ini". Tanpa alat, dengan satu baris prompt Anda mendapat 80% dari lint. Sebelum menyerahkan ke rekaman (atau TTS), cukup loloskan sekali ini saja, maka garis putus-putus di depan bilik tetap terjaga.

Poin-Poin Penting

• Di antara lima penyebab goyahnya voice, penyeragaman oleh AI yang paling pesat bertambah, dan resepnya bukan konteks yang rapuh, melainkan voice_profile yang memuat contoh.
• voice_lint hanya menandai pelanggaran dan yang mencurigakan, sedangkan penolakan dilakukan manusia, dan pada tabu didefinisikan pula konteks pengecualian.
• Semua tinjauan diakhiri di atas garis putus-putus di depan bilik rekaman — audio di bawah garis putus-putus tidak bisa dibatalkan seperti teks.

Pratinjau Bab Berikutnya

• 6.1. Pembangkitan Konten Prosedural dan AI — Di Mana Mereka Bertemu

Bagian 6 · Content Design

6.1 Pembangkitan Konten Prosedural dan AI — Satu Sel tempat Dua Sumbu Berpotongan

Rapat perencanaan Senin pagi. Di papan tulis tertulis satu baris. "1,000 side quest sampai rilis." Seseorang menekan-nekan kalkulator. Kalau satu penulis menghabiskan satu hari untuk satu quest, itu butuh 4 tahun. Bahkan kalau lima orang dikerahkan, hampir genap 1 tahun. Udara di ruangan jadi berat. Saya yang sudah 24 tahun duduk di ruangan ini tahu bahwa di hadapan angka itu orang selalu terbelah ke dua arah yang sama. Satu pihak berkata "kurangi saja volumenya", pihak lain berkata "cetak saja dengan alat". Dan hampir selalu keputusannya adalah keduanya.

Pembangkitan konten prosedural (Procedural Content Generation, selanjutnya disebut PCG) adalah jawaban lama dari pihak "cetak saja dengan alat" itu. Penataan ruang dungeon, kombinasi opsi senjata, dan pool spawn musuh sudah diotomatiskan dengan rulebook dan tabel probabilitas sejak 20 tahun lalu. Yang baru bukanlah PCG itu sendiri, melainkan kenyataan bahwa LLM dan model generatif kini menempati posisi tempat bahasa alami, gambar, dan narasi masuk.

Namun yang ingin saya katakan dalam buku ini bukanlah "tempelkan AI ke PCG". Itu dilakukan siapa saja. Persoalannya adalah di mana Anda menempelkannya. Jika Anda mengambil satu bongkah konten, lalu tidak memakukan ke satu sel pada intensitas otomasi mana dan pada lapisan struktur mana ia bertemu, jadilah keadaan di mana alat ada tetapi tempatnya tidak ada. Bab ini melihat cara menggambar satu sel itu sebagai koordinat, dan bagaimana satu potong konten benar-benar berputar satu kali melewati pipeline di atas sel itu.

6.1.1 Tempat di Mana PCG Berhenti Bergerak

PCG tradisional kuat dalam determinisme. Input yang sama menghasilkan output yang sama, dan verifikasi dimungkinkan. Itulah sebabnya graf ruang dungeon, prefix·suffix opsi senjata, dan distribusi spawn musuh mapan sejak dini. "Pedang Api +5" sudah keluar secara otomatis bahkan 20 tahun lalu.

Persoalannya selalu ada di tempat berikutnya. Ruang sudah ditata, tetapi nama, penampilan, dan latar belakang singkat NPC di dalam ruang itu tetap tinggal di tangan penulis. "Pedang Api +5" keluar, tetapi satu baris "pedang terakhir yang hilang dari sang raja" tidak keluar. Sekalipun quest generator mengambil kombinasi tujuan dan imbalan, "mengapa mengerjakan quest ini" tetap ditulis manusia.

Pada game berskala besar, tempat ini selalu menjadi bottleneck. Rasio antara area yang dapat diproduksi massal dan area yang membutuhkan tangan manusia kira-kira 4 berbanding 6, dan 6 bagian tangan manusia itu memakan sebagian besar jadwal. Sekalipun lini produksi massal membuat 4 bagian dengan cepat, jika 6 bagian tidak menyusul, seluruh siklus terkunci pada kecepatan itu.

Tempat masuknya LLM dan model gambar persis di situ. Cakupan yang dapat diproduksi massal meluas hingga ke area bahasa alami, narasi, dan visual yang tidak bisa ditangani rulebook. Meski begitu, menyerahkan tempat itu bulat-bulat ke AI bukanlah jawabannya. AI mengeluarkan jawaban yang sedikit berbeda setiap kali, dan ketika konteksnya kosong, ia memuntahkan rata-rata RPG generik. Karena itu, dibutuhkan desain titik penggabungan. Titik penggabungan didefinisikan oleh dua sumbu koordinat.

6.1.2 Sumbu Pertama: Intensitas Otomasi (L0–L3)

Sumbu vertikal adalah dengan rasio berapa Anda mencampur manusia, rulebook, dan AI. Di sebuah pengembang MMORPG tempat saya bekerja (selanjutnya 'Proyek A'), pencampuran ini dipotong menjadi empat tingkat.

L0 — Sepenuhnya manual. Semua huruf dan keputusan keluar dari tangan manusia. Teks utama main quest, dialog karakter signature, ending percabangan. Tempat di mana konsistensi dan kedalaman narasi langsung terkait dengan identitas game.

L1 — Otomasi rulebook. Tempat PCG tradisional. Algoritma deterministik seperti rulebook, tabel probabilitas, dan BSP membuat output, dan manusia hanya meninjau. Penataan ruang dungeon, kombinasi opsi senjata, dan spawn musuh adalah yang representatif.

L2 — Rulebook + bantuan AI. Rulebook menyusun kerangka dan AI mengisi detail. Sinopsis side quest, nama dan latar belakang singkat NPC biasa, teks pengantar area perburuan. Manusia hanya bertanggung jawab atas metadata input dan gerbang tinjauan terakhir.

L3 — AI lebih dulu + tinjauan manusia. AI membuat teks utama dan manusia hanya masuk untuk meninjau. Menggiurkan, tetapi risiko non-determinisme, halusinasi, dan kerusakan konsistensi semuanya berkumpul di sini.

Intinya adalah L2. Ia menggabungkan stabilitas L1 dengan daya produksi massal L3, dan menutup kelemahan kedua area itu dengan verification gate. Godaan untuk segera menerapkan L3 memang besar, tetapi saya sudah beberapa kali melihat kasus di mana beban tinjauan meledak sehingga L3 dibuang dalam satu-dua kuartal. Jika 70 dari 100 naik sebagai item yang meragukan, itu lebih mahal daripada manusia menulis 100 dari awal.

6.1.3 Sumbu Kedua: Struktur Layer (L0–L4)

Hanya dengan memegang sumbu vertikal, lini produksi massal tidak akan berjalan. Konten itu sendiri harus terurai menjadi lapisan agar muncul tempat bagi otomasi untuk masuk. Inilah penguraian Layer yang dibahas di Bagian 5, dan ini adalah sumbu horizontal di bidang konten. Penjelasan umum bahwa kelima lapisan masing-masing berkorespondensi dengan satu peran pembangkitan prosedural (anchor·rulebook·teks utama·angka·gerbang) sudah dibahas di §2.3.6, dan di sini kita masukkan langsung ke lini produksi massal konten. Layer 0 visi adalah anchor nada dan dunia (disuntikkan setiap kali membangkitkan), Layer 1 sistem adalah rulebook pembangkitan (aturan·tabel probabilitas·sistem tag), Layer 2 konten adalah tempat teks utama di mana hasil pembangkitan menumpuk (side quest·latar belakang NPC·teks pengantar kota), Layer 3 data adalah angka·ID·relasi (imbalan·spawn·kurva), dan Layer 4 build·QA adalah verification gate (lint·pemeriksaan konsistensi·tinjauan penulis).

Kedua sumbu ini adalah cerita yang berbeda. Sumbu vertikal berbicara tentang "seberapa banyak manusia menyentuhnya", sumbu horizontal tentang "bagian mana dari konten". Namun keduanya baru bermakna lewat perkalian. Hanya ketika satu potong konten dipakukan ke titik potong kedua sumbu, yakni satu sel, barulah ditentukan "siapa, di bagian mana, dan bagaimana membuatnya".

6.1.4 Dua Sumbu dalam Satu Lembar — Matriks Otomasi × Layer

Kita tumpuk kedua sumbu yang sejauh ini diurai dengan tulisan menjadi satu lembar kisi. Horizontal adalah Layer konten, vertikal adalah intensitas otomasi. Label di tiap sel adalah konten yang sebenarnya menempati sel itu di Proyek A. Makin pekat warna selnya, makin dekat ia ke pusat gravitasi lini produksi massal.

Kisi inilah inti bab ini. Penilaian yang tadinya berserakan dalam tulisan seperti "main itu L0", "side itu L2", "imbalan itu rulebook" kini berkumpul ke satu koordinat. Ketika konten baru naik jadi agenda di rapat, satu pertanyaan "ini sel yang mana" sudah cukup. Begitu selnya ditentukan, koordinat vertikal sel itu memberi tahu siapa yang menyentuh, dan koordinat horizontalnya memberi tahu bagian mana.

Saat membaca kisi ini, dua hal menarik perhatian. Pertama, pusat gravitasi (sel pekat) ada di baris L2 × kolom Layer 2. Kerangka side quest·latar belakang NPC ada di tempat itu. Itulah jantung lini produksi massal. Kedua, satu konten tidak hanya berada di satu sel. Teks utama (Layer 2) side quest ada di sel L2, tetapi angka imbalannya (Layer 3) turun ke sel L1. Sekalipun quest yang sama, tiap bagian tinggal di sel yang berbeda. Inilah alasan kedua sumbu dipisahkan.

6.1.5 Mini-Pipeline yang Berputar di Atas Satu Sel

Di atas sel pusat gravitasi — baris L2 × kolom Layer 2, kerangka side quest — kita lihat satu potong konten benar-benar berputar satu kali. Alurnya seperti berikut.

flowchart TD
    A["Injeksi visi Layer 0
(anchor nada: desa bergaya Timur)"] --> B["Rulebook Layer 1
(membangkitkan kerangka slot tujuan·imbalan)"]
    B --> C["Bantuan AI L2
(mengisi motif NPC·latar satu baris)"]
    C --> D{"Gerbang tinjauan Layer 4
(lint nada·konsistensi)"}
    D -->|lolos| E["Penetapan data Layer 3
(angka imbalan dihitung rulebook)"]
    D -->|ditolak| B
    E --> F["Penerapan ke build"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D code;
    class C ai;
    class E data;
    class F pass;

Kita ikuti alur ini sekali sebagai worked transcript (rekaman sesi nyata). Anggap kita membuat satu quest tugas remeh di desa pedesaan.

Tahap 1 — Rulebook Layer 1 mengambil kerangka. Rulebook bersifat deterministik. Ia keluar dengan hanya mengisi slot.

[Kerangka quest — keluaran rulebook]
Wilayah: desa_3
Peran pemberi tugas: tukang ramuan
Tipe tujuan: pengumpulan (bahan obat x6)
Faktor pengganggu: spawn serigala (malam)
Slot imbalan: { gold: ?, exp: ?, item: arit pemetik }

Tahap 2 — Kita meminta detail ke AI. Teks lengkap prompt-nya seperti ini. (Visi Layer 0 dimasukkan lebih dulu sebagai konteks.)

Kamu adalah penulis quest sebuah MMORPG berlatar desa pedesaan fantasi Timur. Anchor nada: "sederhana tetapi diliputi takhayul dan ketakutan, suasana kampung". Terima kerangka di bawah, lalu tuliskan satu baris motif pemberi tugas, nama NPC, dan dua kalimat teks permintaan yang terlihat oleh pemain. Jangan sekali-kali membuat angka imbalan (sistem yang menentukannya). Keluaran berupa JSON. Kerangka: { wilayah: desa_3, pemberi tugas: tukang ramuan, tujuan: kumpulkan 6 bahan obat, pengganggu: serigala malam, item imbalan: arit pemetik }

Tahap 3 — Keluaran mentah (raw output) dari Claude. (Disalin apa adanya tanpa diringkas.)

{
  "npc_name": "Bibi Samwol",
  "motive": "Setiap malam lolongan serigala merusak kebun ramuannya, hingga ia tak berani pergi mencabut bahan obat terakhir.",
  "quest_text": "Kalau malam tiba, serigala-serigala mengobrak-abrik kebun ramuan. Aku takut sampai kaki tak bisa melangkah, jadi tolong cabutkan saja enam akar bahan obat di kaki bukit untukku.",
  "reward": { "gold": 120, "exp": 300 }
}

Ada yang harus kita berhenti dan cermati di sini. AI membuat dan memasukkan field reward padahal tidak disuruh. Ini persis menunjukkan mengapa sumbu 1 dan sumbu 2 harus dipisahkan. Angka imbalan (Layer 3) adalah tempat rulebook L1, bukan tempat AI (L2). Kalau itu diserahkan ke AI, angkanya goyah setiap pemanggilan dan kurva imbalan runtuh.

Tahap 4 — Verifikasi·penolakan manusia. Peninjau melakukan dua hal. (1) Menghapus field reward — ini sel yang harus diisi rulebook. (2) Memeriksa nada. "Bibi Samwol", satu baris motif, dan dua kalimat teks permintaan cocok dengan nada desa pedesaan. Lolos. Seandainya AI memasukkan kata di luar dunia seperti "permintaan dari guild penyihir", di sini ia ditolak dan dikembalikan ke tahap kerangka.

Tahap 5 — Penetapan data Layer 3. Slot imbalan yang dihapus diisi ulang oleh rulebook. Ini rumus deterministik yang terikat pada level wilayah dan tingkat kesulitan tujuan. gold: 85, exp: 240. Yang masuk adalah nilai yang sesuai kurva, bukan 120·300 yang dimuntahkan AI secara sembarang.

Satu putaran ini adalah siklus standar sel pusat gravitasi. Rulebook membuat kerangka, AI menempelkan daging, manusia menjadi gerbang, rulebook lagi yang menetapkan angka. Seluruh 1,000 konten berputar mengikuti siklus ini. Karena selnya sudah ditentukan, setiap kali tidak perlu lagi memperdebatkan "siapa yang membuat ini".

6.1.6 Lima Pertanyaan yang Diajukan saat Menentukan Sel

Untuk memutuskan di sel mana dari kisi sebuah konten baru ditempatkan, lima pertanyaan membantu. Jika setiap kali agenda produksi massal naik di rapat Anda mencatatnya dan menjawabnya bersama, konsistensi penempatan sel akan mapan dalam satu kuartal.

Satu, seberapa besar beban produksi massal. Apakah dibutuhkan N buah sampai rilis. Jika N melampaui 100, baris L0 hampir mustahil.

Dua, seberapa besar tuntutan konsistensi. Jika konsistensi antarkonten adalah inti pengalaman, gerbang tinjauan (Layer 4) harus kuat; jika keragaman yang menjadi inti, ada ruang untuk naik ke baris lebih atas.

Tiga, apakah non-determinisme dapat ditoleransi. Apakah ini area di mana hasil yang sedikit berbeda setiap kali menciptakan kekayaan, atau area di mana hasil yang sama adalah inti kepercayaan.

Empat, berapa biaya tinjauan. Apakah 5 menit atau 30 menit per konten itulah yang menentukan panjang siklus operasional.

Lima, berapa biaya ketika terjadi insiden. Apakah pembuangan·penulisan ulang bebas dilakukan, atau sekali keluar langsung berujung insiden bagi pengguna.

Jika Anda melemparkan lima ini ke side quest, jawabannya berkumpul ke satu arah. Lebih dari 1,000 (L0 mustahil), konsistensi lebih rendah daripada main, non-determinisme ditoleransi, tinjauan 5–10 menit, biaya insiden rendah (bisa dibuang per item). Karena kelima jawaban berkumpul, sel baris L2 × Layer 2 menjadi wajar. Jika lima yang sama dilemparkan ke main quest, jawabannya berkumpul ke arah sebaliknya. 50 buah, konsistensi·kedalaman narasi tertinggi, non-determinisme tidak diizinkan, biaya tinjauan besar, biaya insiden sangat besar — itu sel L0.

6.1.7 Empat Jebakan yang Umum

Sekalipun kisi sudah digambar, jebakan yang menjerat serupa. Empat hal berulang.

Pertama, kasus memulai dari baris L3. Jika berangkat dengan harapan "AI akan mengurus 100 buah sendiri", tinjauan meledak. Mapankan dulu sel L1, naik ke L2, dan L3 hanya pada sebagian dengan hati-hati. Pada mini-pipeline di atas, satu gerakan ketika manusia menghapus field imbalan itu menunjukkan secara kecil mengapa baris L3 berbahaya.

Kedua, kasus mendelegasikan bulat-bulat ke AI tanpa rulebook. "Buatkan 100 side quest" memanggil rata-rata RPG generik. Rulebook Layer 1 harus menyusun kerangka lebih dulu dan AI menempelkan daging di atasnya, barulah keluar konten game kita. Menulis satu rulebook adalah pekerjaan yang paling makan tenaga dan paling tidak menarik dalam PCG, tetapi jika ini dilewati, seluruh produksi massal di atasnya merosot ke nilai rata-rata.

Ketiga, kasus gerbang tinjauan (Layer 4) kosong. Jika keluaran AI otomatis diterapkan ke build, insiden konsistensi langsung terjadi. Di sel mana pun, gerbang manusia wajib ada.

Keempat, kasus menentukan alat hanya dengan melihat biaya. Biaya LLM API turun setiap kuartal, tetapi biaya insiden konsistensi tidak turun. Keputusan alat dilihat dengan menambahkan jumlah waktu konsistensi·tinjauan ke biaya API.

6.1.8 Pengukuran — Enam Bulan setelah Pindah ke Sel Pusat Gravitasi

Di Proyek A, setelah memindahkan side quest dari sel L0 ke sel L2, saya mengukur selama enam bulan. Di antara angka berikut, nilai absolutnya adalah perkiraan penulis (belum terverifikasi), sedangkan arah dan rasio perubahanlah yang teramati dalam pengukuran nyata.

Tingkat pembuangan naik ke 20%, tetapi karena kecepatan produksi massal 6–8 kali lipat, throughput bersih naik 4–5 kali lipat. Insiden konsistensi sedikit naik menjadi 5–8 kasus per kuartal, tetapi dengan penguatan verification gate dan rulebook, ia kembali ke rentang normal dalam satu kuartal.

Perubahan terbesar bukanlah angka melainkan manusia. Mula-mula para penulis merasa menjadi "peninjau produksi massal" sehingga kepuasan turun dari 8 ke 6. Untuk memulihkannya, saya menyisipkan kebijakan yang secara eksplisit menjamin waktu penulis pada main quest dan side quest signature (1–2 per kota). Saya memakukan agar lini produksi massal bukan menyedot waktu penulis, melainkan menjadi alat yang mengembalikan waktu itu ke main. Enam bulan kemudian kepuasan kembali ke 7.

Satu hal yang dapat diambil dari pengukuran ini. Keputusan memindahkan sel harus diikuti bersamaan oleh throughput·distribusi waktu penulis·kepuasan. Jika hanya melihat throughput, produksi massal berhasil tetapi manusianya pergi.

6.1.9 Penguraian Layer Dulu, PCG di Atasnya

Tesis umum bahwa penguraian Layer adalah prasyarat pembangkitan prosedural ada di §2.3.6. Di sini kita hanya melihat bagaimana hal itu tampak di atas kisi PCG. Pada tim yang sumbu horizontalnya (Layer 0–4) kabur, tidak ada satu sel pun yang dapat berjalan stabil. Jika tidak tahu di mana letak visi Layer 0, anchor nada tiap generator kosong sehingga keluar rata-rata RPG generik; jika rulebook Layer 1 dan teks utama Layer 2 tercampur dalam satu file, ketika memperbaiki satu baris aturan harus ikut menyentuh puluhan tempat di teks utama; dan jika data Layer 3 dimasukkan ke dalam teks utama, satu kali penyesuaian kurva imbalan membuat penulis menghabiskan 1 minggu — inilah alasan imbalan dilepas sebagai slot terpisah pada mini-pipeline di atas.

Karena itu, yang harus diperiksa sebelum menerapkan PCG bukanlah pemilihan alat, melainkan apakah sumbu horizontal sudah terurai. Pada tim yang kelima lapisannya sudah lengkap, biaya menempelkan L1 generator adalah satu kuartal seorang penulis. Pada tim yang kelima lapisannya tercampur, penerapan yang sama akan dibuang dalam dua kuartal karena insiden konsistensi.

Kelima sel tidak perlu sempurna sejak awal. Pisahkan secara bertahap, antarmuka secukupnya saja. Pada kuartal pertama, melepas satu baris nada Layer 0 dan satu rulebook Layer 1 saja sudah membuka tempat bagi generator untuk masuk. Itu bukan berarti boleh ditunda tanpa batas. Jika teks utama Layer 2 dan data Layer 3 tetap menjadi satu bongkah sampai akhir, alat konkret pada bab berikutnya pun tidak akan menemukan tempatnya.

6.1.10 Pratinjau Bab Berikutnya

Pada bab berikutnya kita membedah satu alat konkret yang menempati sel pusat gravitasi kisi ini. Itu adalah proj_city_hunting_generator yang memproduksi massal area perburuan tiap kota. Kita lihat bagaimana metadata input·kerangka rulebook·teks utama AI·verification gate terikat menjadi satu siklus, dan bagaimana mini-pipeline bab ini membesar pada skala alat nyata.

Poin-Poin Penting

• Intensitas otomasi (vertikal L0–L3) dan struktur Layer (horizontal 0–4) baru bermakna lewat perkalian.
• Pusat gravitasi lini produksi massal adalah sel baris L2 × Layer 2, yakni kerangka side quest.
• Penguraian sumbu horizontal lebih dulu, dan PCG hanya berjalan pada satu sel di atasnya.

Coba Sendiri — Menaikkan Satu Konten ke Satu Sel

setup. Pilihlah satu jenis konten kandidat produksi massal (misalnya: side quest). Lepaskan satu baris nada Layer 0 dan kerangka rulebook Layer 1 (definisi slot) sebagai file terpisah. Slot angka imbalan biarkan kosong di sisi rulebook.

prompt. Setelah memasukkan visi sebagai konteks, berikan kerangkanya, lalu tegaskan "jangan buat angka imbalan, keluaran berupa JSON". Anda cukup memvariasikan prompt Tahap 2 di atas apa adanya.

verify. Lihatlah tiga hal. (1) Jika AI memasukkan field imbalan secara sembarang, hapuslah (L3 adalah tempat rulebook). (2) Jika ada kata di luar dunia, tolak ke tahap kerangka. (3) Hanya bagian yang lolos yang diisi angka imbalannya oleh rulebook lalu dimasukkan ke build.

Versi Ringkas Solo. Tanpa tim pun bisa. Buatlah sendiri satu rulebook (5 slot) dan satu baris nada saja sebagai file teks. Coba putar 10 quest dengan siklus di atas, dan hitung berapa yang Anda tolak pada tinjauan. Jika tingkat penolakan melampaui 30%, berarti selnya salah — rapatkan kerangka rulebook lebih jauh atau turun satu baris (L1) lalu lihat ulang. Jika tingkat penolakan stabil, itulah sinyal bahwa sel itu bekerja pada skala Anda.

6.2 city_hunting_generator — Membuat 30 Kota dalam 4 Minggu

Pembaca utama: Game Designer MMORPG yang bertanggung jawab atas produksi konten massal (tim skala menengah, 10–50 orang) Versi ringkas untuk pembaca solo/hobi: §6.2.10 "Versi Ringkas Solo"

Saya masih ingat perhitungan di hari pertama saat menerima jadwal yang menyatakan bahwa 30 kota harus siap sebelum rilis. Satu kota terdiri atas teks pengantar 5–10 baris, 3–5 area perburuan, 5–10 NPC dan 2–3 side quest per area perburuan, 1–3 jenis item khas, serta 1 boss kota. Membentuk satu kota dengan tangan memakan waktu 1–2 minggu. Untuk 30 kota, itu berarti satu penulis menghabiskan enam bulan penuh hanya untuk kota.

Tetapi enam bulan itu tidak ada. Waktu penulis sudah terikat pada main quest dan karakter signature, sementara 30 kota harus dikerjakan paralel dengan pekerjaan itu. Dorongan pertama, "Bukankah cukup minta AI membuat 30 kota saja?", langsung runtuh. Kalau diserahkan utuh, yang keluar adalah 30 desa fantasi yang saling mirip. Bab ini melihat bagaimana alat city_hunting_generator — yang saya buat sebagai pengganti dorongan itu — mengikat empat tahap (input, rulebook, AI, dan verifikasi) menjadi satu siklus, lalu melihat apa yang benar-benar dihasilkan dan apa yang dibuang ketika siklus itu dijalankan sungguh-sungguh sampai tuntas sekali.

Catatan Operasional Nyata Penulis city_hunting_generator dalam bab ini adalah versi anonim dari alat nyata yang saya operasikan di folder R&D perusahaan. Nama berkas, struktur kode, dan item verifikasi saya pindahkan setia dari alat aslinya, sementara nama kota (seperti silvermark) dan istilah khas perusahaan diganti untuk keperluan buku. Teks keluaran adalah rekonstruksi dari sesi yang nyata.

6.2.1 Manusia Hanya Mengerjakan Metadata dan Tinjauan Akhir

Alur menyeluruh alat ini terdiri atas empat tahap. Intinya, tahap 1 dan 3 bersifat deterministik (rulebook) dan hanya tahap 2 yang AI. Ketika rulebook menjaga kerangka dan verifikasi dari kedua sisi, maka meskipun AI yang terjepit di tengah memberi jawaban yang sedikit berbeda setiap kali, konsistensi antarkota tidak goyah. Manusia hanya masuk pada input pertama (metadata) dan gerbang terakhir (tinjauan).

flowchart TB
    A["Input: metadata kota yaml
(manusia 15–20 menit/kota)
lore_seeds 3 buah · forbidden_names dilampirkan otomatis"]
    A --> B["Tahap 1 deterministik: rules.py
generate_skeleton()
jumlah area perburuan·distribusi musuh·kurva reward·boss"]
    B --> C["Tahap 2 AI: 3 jenis prompt
L0 caching visi + injeksi rule L1
+ teks kota tetangga L2
→ teks pengantar·NPC·side quest"]
    C --> D{"Tahap 3 deterministik: lint
nama ganda·kata terlarang·voice
·panjang·rentang reward"}
    D -->|alert pelanggaran| E["Tahap 4 gerbang tinjauan penulis
(5–10 menit/kota)
keputusan buang·regenerasi"]
    E -->|permintaan ulang| C
    E -->|lolos| F["Diterapkan ke build"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D code;
    class C ai;
    class A,E human;
    class F pass;

Dalam gambar ini, tempat yang tersentuh tangan manusia hanya ada dua. Di paling atas, tempat memasukkan satu halaman metadata secara bersih; di paling bawah, tempat membuat keputusan ihwal nada dan narasi yang tak bisa ditangkap lint. Di antara keduanya, pembuatan kerangka yang membosankan dan produksi teks massal dijalankan oleh rulebook dan AI. Rancangan yang menentukan ialah: meskipun lint (tahap 3) menemukan pelanggaran, ia tidak membuang otomatis, melainkan hanya menaikkan alert ke gerbang penulis (tahap 4). Alasannya akan kita lihat di §6.2.5.

6.2.2 Input — Satu Halaman Metadata Kota

Penulis menulis satu halaman metadata per kota. Waktu pengerjaan 15–20 menit. Singkat, tetapi satu halaman ini adalah seluruh input bagi tiga tahap berikutnya.

# city_021_silvermark.meta.yaml
city_id: city_021_silvermark
region: west
climate: cold_arid
dominant_faction: scholar_guild
cultural_tone: scholarly_strict
level_range: [25, 30]
lore_seeds:
  - Merupakan pusat segel sihir 100 tahun lalu
  - Pertanda pertama melemahnya segel teramati di kota ini
  - Lokasi markas guild kaum cendekia
neighbors: [city_018, city_023]
# forbidden_names: (dilampirkan otomatis oleh skrip — tidak perlu input penulis)

Slot yang paling penting adalah lore_seeds. Tiga sampai lima peristiwa inti menentukan identitas kota. Kalau terlalu sedikit, AI memuntahkan kota fantasi umum; kalau terlalu banyak, peristiwa-peristiwanya saling bertentangan. Berdasarkan pengalaman saya, tiga buah adalah yang paling stabil.

forbidden_names tidak diisi penulis. Skrip membaca daftar nama kota dan karakter yang sudah ada, lalu melampirkannya otomatis ke metadata. Sebab, ketika 30 kota × rata-rata 50 NPC menumpuk, memeriksa duplikasi 1,500 nama dengan kepala manusia adalah hal yang mustahil. Tidak perlu menulis "buatkan agar tidak tumpang tindih dengan NPC kota lain" dengan tangan setiap kali.

6.2.3 Tahap 1 Rulebook — Menyusun Kerangka Secara Deterministik

Rulebook menerima metadata dan membuat kerangka struktur kota. Kodenya sederhana.

# city_hunting_generator/rules.py (kerangka)
def generate_skeleton(meta):
    region_rules = REGION_RULES[meta.region]
    hg_count = region_rules.hunting_grounds_range.sample()
    enemy_dist = ENEMY_RULES[meta.climate][meta.dominant_faction]

    skeleton = {
        "hunting_grounds": [
            {
                "id": f"{meta.city_id}_hg_{i}",
                "level": meta.level_range[0] + i,
                "enemy_types": enemy_dist.sample(k=3),
                "reward_curve": calc_reward(meta.level_range[0] + i),
                "npc_count": region_rules.npc_per_hg,
                "sidequest_count": region_rules.sidequest_per_hg,
            }
            for i in range(hg_count)
        ],
        "boss": {
            "id": f"{meta.city_id}_boss",
            "level": meta.level_range[1] + 2,
            "pattern": BOSS_PATTERNS[meta.region],
        },
    }
    return skeleton

Hasilnya deterministik. Memasukkan metadata yang sama akan menghasilkan kerangka yang sama. Apakah kurva reward berada dalam rentang standar per region·level, dan apakah distribusi musuh sesuai rule climate·faction, dijamin oleh kode, dan pengujian regresi pun menangkapnya. Tahap ini sama sekali tidak diserahkan ke AI. Sebab, jika AI menarik angka kurva reward yang berbeda setiap panggilan, balance antarkota langsung goyah saat itu juga.

Jika metadata silvermark dimasukkan, rules.py mengembalikan kerangka kosong berupa 4 area perburuan (city_021_silvermark_hg_0\~hg_3), 6 slot NPC dan 3 slot side quest di tiap area perburuan, serta 1 boss level 32. Itu adalah tabel sel-sel yang harus diisi, yang belum punya nama maupun teks. Mengisi sel-sel itu adalah tugas tahap 2 AI.

6.2.4 Tahap 2 AI — Pembuatan Teks Bahasa Alami

Setelah rulebook membuat kerangka, AI mengisi teks bahasa alami di atasnya. Teks pengantar kota, nama·penampilan·latar singkat NPC, sinopsis side quest, serta flavor text item khas keluar di sini.

Pola pemanggilannya persis struktur empat lapis injeksi konteks. Visi L0 (world_premise + tone_manifesto) di-caching, rule L1 (city_naming_rule + region_west_lore) diinjeksikan secara selektif, teks tetangga L2 (daftar nama NPC kota lain) ditambahkan, lalu di akhir instruksi pekerjaan dilekatkan. Prompt teks pengantar kota berbentuk sedemikian rupa sehingga bisa langsung disalin dan dipakai.

[Konteks L0] world_premise + narrative_pillar + tone_manifesto  (caching)
[Konteks L1] city_naming_rule, region_west_lore
[Input] city_021_silvermark.meta.yaml + lore_seeds 3 buah

Tuliskan teks pengantar kota ini dalam 6–8 baris. Lebur ketiga lore_seeds secara
alami, dan buang klise RPG seperti "desa yang damai". Buat nadanya cendekia dan
ketat, tahan sentimen. Hanya teks isinya, tanpa kata pengantar maupun penjelasan.

Pola yang sama berulang persis pada produksi NPC dan pemanggilan side quest. Bedanya hanya pada konteks dan format keluaran. Pada pemanggilan NPC masuk slot forbidden_names (larangan nama NPC ganda dengan kota lain), dan pada pemanggilan side quest masuk batasan "pilih NPC pemberi tugas dari NPC yang dibuat di atas".

Lalu, apa yang sebenarnya keluar? Mari kita jalankan sampai tuntas sekali.

6.2.5 Satu Siklus sampai Tuntas — Keluaran, Verifikasi, Pembuangan

Kalau hanya ditulis secara abstrak "AI mengisi teks", kita tidak tahu apa sebenarnya yang dimuntahkan alat ini. Mari kita ikuti satu siklus kota silvermark, dari input hingga pembuangan, sampai tuntas sekali.

[Keluaran Tahap 2 AI — Teks Pengantar Kota] (rekonstruksi sesi nyata)

Silvermark adalah kota segel. Seratus tahun lalu, tujuh cendekiawan mendirikan lingkaran segel di bawah tanah ini untuk menahan luapan mana dari barat, dan kota itu tumbuh dengan menumpuk batu satu per satu di atas lingkaran tersebut. Menara lonceng markas guild kaum cendekia adalah observatorium untuk membaca denyut segel, bukan menara puncak yang menjulang ke arah dewa. Tiga tahun terakhir, satu baris berulang tercatat dalam rekaman pengamatan: "Denyutnya mendingin." Pertanda pertama melemahnya segel pertama kali bergetar bukan di tempat lain mana pun, melainkan di panel instrumen kota inilah. Para cendekiawan di jalan tidak mengucapkannya dengan suara keras. Hanya saja, kian bertambah hari-hari ketika api di menara lonceng tak padam sepanjang malam.

Di sini ketiga lore_seeds (pusat segel·pertanda pertama melemahnya·markas guild kaum cendekia) semuanya termuat dalam teks, tidak ada klise seperti "desa damai yang menyambut petualang", dan nada scholarly_strict (menahan sentimen, kosakata pengamatan·rekaman) terjaga. Beginilah rupa keluaran yang layak lolos.

Berikutnya, siklus yang sama mengisi 3 dari 6 slot NPC di area perburuan hg_0.

[Keluaran Tahap 2 AI — 3 NPC] (rekonstruksi sesi nyata)

1) Doren Vale — Asisten pengamatan menara lonceng. Usia 50-an, kaca pembesar kuningan terpasang permanen di satu mata. Sudah 30 tahun mengerjakan pencatatan getaran halus denyut segel. Pendiam, dan hanya berbicara lewat angka. "Hari ini 12.4. Kemarin 12.1. Sedang naik. Bukan pertanda baik."

2) Mira Kost — Pustakawan arsip guild. Usia 30-an, noda tinta tak hilang dari jarinya. Ia menjaga rancangan asli lingkaran segel, tetapi justru meyakini bahwa para cendekiawan yang sanggup membaca cetak biru itu sudah mati semua. Sangat waspada terhadap orang luar.

3) Grem — Penjaga perapian di bawah menara lonceng. Tak diketahui asal-usulnya, usianya tak jelas. Satu-satunya tugasnya adalah menjaga agar api menara lonceng tak padam, dan kepada siapa pun yang bertanya soal segel ia hanya menjawab, "Lihat saja apinya." (Ditandai ambigu — dilaporkan sendiri oleh AI)

Perhatikan bahwa pada NPC ketiga, 'Grem', AI sendiri melekatkan tanda ambigu. Prompt yang baik membuat AI bisa mengatakan, "Yang ini saya tidak yakin." Sekarang lint tahap 3 menghantam kumpulan keluaran ini.

[Keluaran Lint Tahap 3] (format nyata)

[PASS] Pemeriksaan panjang: teks pengantar 7 baris (standar 6–8)
[PASS] Rentang reward: reward_curve hg_0~hg_3 dalam rentang standar
[WARN] Nama ganda: "Mira Kost" — marga (Kost/Veldt) berbeda dari "Mira Veldt"
       di city_014_riverhold, tetapi nama depan (Mira) sama. Bentrok dekat forbidden_names.
[PASS] Kosakata terlarang: 0 pelanggaran tone_manifesto
[WARN] Konsistensi voice: dialog "Grem" voice_lint reliabilitas 0.62 (di bawah ambang 0.70)

Lint menangkap 2 pelanggaran, tetapi tidak ada satu pun yang dibuang secara otomatis. Ia hanya menaikkannya ke gerbang penulis sebagai WARN. Inilah inti rancangan yang sudah saya beri tahu di §6.2.1. Kalau pemeriksa diberi pula wewenang menolak otomatis, dalam satu-dua bulan saja para penulis akan menurunkan sakelar itu. Sebab mesin akan ikut membunuh variasi yang sebenarnya disengaja, dan bahkan kesempatan bagi penulis untuk menimbang sendiri batas itu pun terampas. Maka, pekerjaan menyaring kandidat yang mencurigakan diserahkan ke mesin, tetapi keputusan akhir untuk menghidupkan atau membuang kandidat itu tetap ditinggalkan di tangan manusia.

[Tinjauan Penulis Tahap 4 — Penilaian dan Pembuangan]

Penulis menangani 2 alert seperti ini.

• Mira Kost → Dipertahankan. Meski namanya sama dengan Mira Veldt di riverhold, kotanya berbeda, marganya berbeda, dan tak ada kemungkinan muncul bersamaan. Lolos sebagai variasi yang disengaja. (Namun, soal apakah rule forbidden_names akan diubah dari "nama depan + marga sama persis" menjadi "bentrok nama depan saja pun WARN" dicatat sebagai perkara terpisah.)
• Grem → Dibuang. Reliabilitas voice_lint yang rendah adalah sinyalnya. Setelah dibaca ulang, karakter penjaga perapian yang berkata "Lihat saja apinya" tidak selaras dengan nada kota scholarly_strict. Kalau NPC di kota yang dikuasai guild kaum cendekia tergelincir ke nada mistik, identitas kota jadi kabur. Dibuang lalu diminta ulang.

Setelah penulis memutuskan pembuangan, satu putaran permintaan ulang berjalan. "Buang slot Grem. Buat ulang NPC penjaga perapian yang sesuai nada guild kaum cendekia (pengamatan·rekaman·ketat) di area perburuan yang sama. Kosakata mistik dilarang." AI menjawab kembali dengan seorang tua yang mencatat suhu perapian menara lonceng, yang bahkan melihat api sebagai data, dan keluaran itu lolos dengan voice_lint 0.81. Satu siklus input → kerangka → teks → verifikasi → pembuangan → regenerasi tertutup di sini.

Satu putaran ini adalah standar Show bagi keseluruhan buku ini. Tanpa sekali pun melihat sampai tuntas apa yang dimuntahkan alat, apa yang tersangkut, dan apa yang dibunuh manusia, kalimat "diproduksi massal dengan AI" itu kosong belaka.

6.2.6 Tingkat Pembuangan Bukan Kegagalan Alat, melainkan Sinyal Gerbang

Pada siklus di atas, 1 NPC dibuang. Dilihat dari satu kota secara keseluruhan, pembuangan menumpuk lebih banyak. Waktu tinjauan rata-rata 5–10 menit per kota, tingkat pembuangan sekitar 20% untuk NPC dan sekitar 33% untuk side quest.

Saya nyatakan secara jujur dasar penghitungan rasio ini. Tingkat pembuangan adalah nilai yang dihitung saat saya sendiri meninjau 5 kota — termasuk silvermark — pada awal penerapan. NPC: dari 30 yang ditinjau, 6 dibuang (20%); side quest: dari 15 yang ditinjau, 5 dibuang (33%). Karena sampelnya kecil, yaitu 5 kota, lebih tepat dibaca sebagai nilai arah pada taraf "satu dari lima, satu dari tiga", bukan rasio populasi yang presisi. Rasio kumulatif setelah meninjau seluruh 30 kota bisa jadi lebih rendah dari ini, atau bisa pula lebih tinggi tergantung sifat area perburuannya.

Yang penting, tingkat pembuangan 0% bukanlah tujuan. Pembuangan 0% justru mendekati sinyal bahwa tinjauan berjalan secara formalitas. Ketika satu dari lima NPC dibuang karena nadanya tak cocok, dan satu dari tiga side quest diregenerasi karena tak menempel pada lore_seeds, di situlah gerbang tinjauan benar-benar bekerja.

6.2.7 Pengukuran — 30 Kota dalam 4–5 Minggu

Saya membandingkan sebelum dan sesudah penerapan alat. Nilai waktu di bawah adalah rata-rata aktual dari kota-kota awal termasuk silvermark, sedangkan kolom "sebelum penerapan" adalah perkiraan penulis pada masa kerja tangan sebelum alat ada. Tidak ada angka yang diolah-olah.

Kalau hanya melihat tabel, semuanya cuma soal angka, tetapi efek sebenarnya muncul dari kolom lain. Saat waktu penulis yang nyaris terikat pada produksi massal kota terbebaskan, satu penulis bisa meningkatkan keluaran main quest per kuartal secara signifikan (kelipatan persisnya berbeda tiap kuartal, jadi tidak saya pastikan — arahnya adalah "keluaran main jelas meningkat"). Alat produksi massal bekerja bukan sebagai alat yang menyerap waktu penulis, melainkan yang membebaskannya (peringatan §6.1.8 — bahwa alat akan ditolak jika penulis merasa dirinya berubah jadi "mesin pemeriksa" — berlaku persis di sini).

6.2.8 Konten yang Tidak Masuk ke generator

Sekalipun cakupan otomasi makin lebar, hal-hal berikut tetap diletakkan di luar alat.

Fakta bahwa sesuatu bisa diproduksi massal tidak boleh otomatis berlanjut menjadi keputusan bahwa ia harus diproduksi massal. Seperti yang kita lihat pada siklus silvermark, alat memproduksi hingga 5 dari 6 NPC dengan baik. Namun satu NPC signature yang memikul ketegangan inti kota itu — 'segelnya mendingin' — dibentuk langsung oleh penulis. Ketika batas otomasi jelas, alat produksi massal justru menjadi alat yang menjaga ranah inti tersebut.

6.2.9 Lima Kegagalan yang Umum

Yang kelima paling sering terlewat. Agar penulis dengan senang hati membuat penilaian seperti membuang Grem di silvermark, penulis harus punya sisa waktu untuk membentuk langsung, bukan sekadar meninjau produksi massal. Kalau hanya throughput yang diukur dan pengukuran waktu penulis dihilangkan, alat akan sukses di atas KPI tetapi orangnya pergi.

6.2.10 Coba Sendiri — Satu Langkah yang Bisa Dilakukan Hari Ini

Versi Ringkas Solo: Anda tidak perlu kode rulebook. Pilih satu kota·daerah dari game Anda sendiri (atau game favorit Anda), tulis metadata berformat §6.2.2 dengan tangan (3 lore_seeds adalah intinya), lalu salin langsung prompt teks pengantar dari §6.2.4 dan jalankan sekali. Coba pilih sendiri satu NPC yang nadanya tak cocok dari hasilnya, dan bantah dengan "NPC ini tak selaras dengan nada kota, buang dan ulang"; maka Anda akan merasakan dengan tubuh, gerbang tinjauan itu kumpulan penilaian macam apa.

Kalau Anda bertim, mulailah dengan satu langkah berikut. Buat dulu satu lembar format yaml metadata dan skrip pelampiran otomatis forbidden_names. Kerangka rulebook (generate_skeleton) dan lint menyusul setelahnya. Dengan hanya dua hal — format input dan pemeriksaan nama ganda — Anda sudah bisa lebih dulu mencegah dua kegagalan umum yang membuat produksi massal teks AI runtuh jadi "30 desa yang mirip".

6.2.11 Pratinjau Bab Berikutnya

Pada 6.3 saya membahas pipeline NPC Persona/Squad. Jika generator di 6.2 memproduksi massal NPC seperti Doren·Mira secara individual, maka Persona/Squad mengikat NPC-NPC itu dalam satuan kelompok. Itu adalah cara membuat lima NPC dari satu area perburuan bekerja sebagai sebuah masyarakat kecil, bukan sekadar himpunan boneka yang saling tak berkaitan.

Poin-Poin Penting

• Tahap 1·3 adalah rulebook (deterministik), hanya tahap 2 yang AI — manusia hanya pada input dan gerbang tinjauan.
• Keluaran·verifikasi·pembuangan harus dilihat sampai tuntas sekali agar "produksi massal AI" tidak kosong.
• Tingkat pembuangan 20·33% bukan kegagalan alat, melainkan sinyal bahwa gerbang bekerja.

Pratinjau Bab Berikutnya

• 6.3. Pipeline NPC Persona/Squad

6.3 Persona dan Squad NPC — Dari Museum Boneka Menjadi Masyarakat Kecil

Pembaca utama: Game Designer MMORPG yang bertanggung jawab atas konten NPC dan area perburuan (tim berukuran menengah, 10\~50 orang) Versi ringkas untuk pembaca solo/hobi: §6.3.10 "Versi Ringkas Solo"

Saya punya satu kenangan dari hari ketika saya memakai generator dari 6.2 untuk memproduksi lima NPC sekaligus di satu area perburuan, lalu menampilkannya di dalam game. Nama, penampilan, dan latar belakang singkat semuanya terisi, dan saya menempatkannya hanya dengan menandai koordinat. Namun begitu saya berjalan-jalan di area perburuan itu, anehnya area itu terasa mati. Kelima orang berada di ruang yang sama, tetapi tidak satu kali pun mereka saling menyebut. Dua orang berdiri bertumpuk di atas batu yang sama. Seseorang seharusnya berperan sebagai pedagang, tetapi kelimanya adalah cendekiawan. Doren maupun Mira secara individu adalah NPC yang baik-baik saja, tetapi begitu disatukan, mereka hanya menjadi sekumpulan boneka.

Inilah kondisi museum boneka. NPC individu semuanya sudah dibuat, tetapi sebagai kelompok mereka tidak hidup. Bab ini membahas pipeline yang menyatukan kelima orang itu menjadi sebuah masyarakat kecil. Dekomposisi intinya adalah Persona dan Squad. Jika diibaratkan dengan kantor, Persona adalah kartu nama pribadi setiap karyawan, dan Squad adalah bagan organisasi satu tim. Menumpuk 50 kartu nama tanpa bagan organisasi tidak membuat perusahaan berjalan. Dan tulang punggung bab ini adalah tahap terakhir, yaitu titik di mana kita memverifikasi sampai akhir satu siklus bersama AI apakah kelompok yang telah disatukan itu "berbicara dan bergerak seperti orang-orang yang saling mengenal".

Catatan Operasional Nyata Penulis Pipeline Squad pada bab ini adalah hasil anonimisasi dari alat NPC Persona/Squad yang penulis operasikan di folder R&D perusahaan. Struktur yaml, item verifikasi, dan ambang voice_lint dipindahkan dengan setia dari alat yang sebenarnya, sedangkan nama kota dan NPC diganti untuk keperluan buku, sama seperti pada 6.2. Isi keluaran adalah rekonstruksi dari sesi yang sebenarnya.

6.3.1 Persona adalah Kartu Nama, Squad adalah Bagan Organisasi

Persona adalah identitas setiap NPC individu. Ia memuat nama, penampilan, voice_profile, dan peran. Yang dibuat oleh generator dari 6.2 adalah Persona. Doren Vale dan Mira Kost masing-masing adalah satu Persona.

Squad adalah unit yang menyatukan Persona-Persona itu menjadi sebuah kelompok. Ia mendefinisikan bagaimana lima orang di satu area perburuan terdistribusi dalam berbagai peran, hubungan apa yang ada di antara mereka, dan bagaimana mereka bergerak.

Jika keduanya tidak dipisahkan, dua hal akan tersumbat sekaligus. Jika hanya Persona yang diproduksi massal, jadilah museum boneka; jika kita mencoba membuat Squad lebih dulu, tidak ada Persona untuk diisi. Dengan memisahkannya, operasi setiap unit menjadi sederhana. Namun pemisahan bukan berarti pemutusan. Intinya adalah memasang jalur reuse dan verifikasi di antara kedua unit itu, dan inilah inti bab ini.

Dekomposisi Persona→Squad ini bukan sekadar penataan, melainkan membuka jalan untuk pergi lebih jauh. Hanya jika kelompok NPC sudah diformalkan ke dalam peran, hubungan, dan angka, kita nantinya bisa sampai pada reaktivitas dinamis di mana keadaan dunia (akumulasi tindakan pemain) menggoyang angka NPC, dan angka itu menjadi syarat kemunculan quest. Bab ini hanya menyentuh pintu masuk penerapan progresif itu; secara langsung, ia hanya membahas sampai "produksi massal konservatif yang ditinjau manusia".

6.3.2 Input — Metadata Squad Satu Halaman

Kerangka Squad dimulai dari satu halaman metadata per area perburuan. Ini adalah pemikiran yang sama dengan metadata kota dari 6.2. Manusia hanya menetapkan distribusi peran dan maksud hubungan, sedangkan pekerjaan mengisinya dilakukan oleh rulebook (buku aturan) dan AI.

# city_021_hg_3.squad.yaml
squad_id: city_021_hg_3_squad
hunting_ground: city_021_silvermark_hg_3
type: hunting_ground_residents
size: 5
roles:
  - role: quest_giver
    count: 1
    voice_traits: [authoritative, scholarly]
  - role: lore_keeper
    count: 1
    voice_traits: [scholarly, withdrawn]
  - role: merchant
    count: 1
    voice_traits: [practical, dry]
  - role: bystander
    count: 2
    voice_traits: [varied]
relationships:
  - between: [quest_giver, lore_keeper]
    type: mentor_and_former_student
  - between: [merchant, bystander_1]
    type: regular_customer
movement_pattern: stationary_with_shifts

Slot yang paling penting adalah relationships. Jika hubungannya 0, kelima orang akan tetap menjadi orang asing sampai akhir. Jika hubungannya terlalu banyak (5 orang dengan 5 hubungan atau lebih), pengguna jadi punya terlalu banyak yang harus diingat sehingga justru tenggelam. Menurut pengalaman penulis, 2\~3 hubungan inti untuk Squad beranggotakan 5 orang adalah yang paling stabil. voice_traits adalah perangkat untuk memastikan kelima orang memiliki suara yang berbeda satu sama lain. Jika kelimanya diisi scholarly, ia akan tertangkap oleh perataan voice (voice leveling) pada tahap verifikasi.

6.3.3 Tahap 1 dan 2 — Kerangka Rulebook dan Pengisian Persona

Rulebook terlebih dahulu menetapkan standar kerangka Squad. Nilai default untuk ukuran, distribusi peran, kepadatan hubungan, dan pola pergerakan per region·type area perburuan sudah dimasukkan ke dalam kode.

# npc_squad/templates.py (cuplikan)
SQUAD_TEMPLATES = {
    ("west", "hunting_ground_residents"): {
        "size_range": (4, 6),
        "role_distribution": {
            "quest_giver": 1,
            "merchant": 1,
            "lore_keeper": (0, 1),
            "bystander": (1, 3),
        },
        "relationship_density": 2,        # jumlah hubungan yang disarankan
        "movement_pattern": "stationary_with_shifts",
    },
    ("east", "outpost_squad"): {
        "size_range": (3, 4),
        "role_distribution": {
            "commander": 1,
            "scout": 1,
            "support": (1, 2),
        },
        "relationship_density": 1,
        "movement_pattern": "patrol_loop",
    },
}

Tahap ini bersifat deterministik. Insiden di mana Squad penduduk wilayah barat berisi lima quest_giver saja secara teknis tidak mungkin terjadi pada level kode. Jika distribusi peran keluar dari aturan, ia tersumbat di tempat itu juga.

Berikutnya, kita mengisi Persona ke setiap slot. Ada tiga jalan. Jika ada Persona yang cocok di pool, gunakan kembali (bobot kemunculan +1); jika tidak ada, buat baru dengan generator dari 6.2; dan jika ia tokoh inti quest utama, penulis menuliskannya sendiri. Squad hg_3 silvermark mengisi quest_giver dan lore_keeper dengan Mira dan Doren yang sudah diproduksi massal di 6.2, lalu menarik merchant dan 2 bystander secara baru. Sampai di sini, prosesnya sama dengan siklus generator dari 6.2. Pekerjaan sejati bab ini ada di tahap berikutnya, yaitu titik di mana kita memverifikasi apakah kelompok yang disatukan benar-benar berfungsi seperti sebuah kelompok.

6.3.4 Satu Siklus Sampai Akhir — Verifikasi Penguatan Hubungan·Alur Pergerakan·Konsistensi

Jika kita hanya menulis secara abstrak "AI memperkuat hubungan", kita tidak akan tahu apa yang dikeluarkan pipeline ini. Mari kita ikuti satu siklus akhir dari satu Squad hg_3 silvermark sampai tuntas — dari pembangkitan teks hubungan hingga pembuangan dan permintaan ulang.

Tahap 3 — Penguatan Hubungan oleh AI

Tag hubungan (mentor_and_former_student) yang dimasukkan ke kerangka Squad bersifat abstrak sehingga tidak terlihat di dalam game. Mengubah ini menjadi deskripsi satu baris lalu menanamkannya ke dalam dialog dan event NPC adalah tahap 3. Prompt-nya berbentuk yang bisa disalin dan dipakai apa adanya.

[Konteks L0] world_premise + tone_manifesto  (caching)
[Konteks L1] city_021_silvermark.lore (didominasi guild cendekiawan, scholarly_strict)
[Persona 1] quest_giver — Mira Kost, pustakawan arsip guild, usia 30-an, noda tinta
[Persona 2] lore_keeper — Doren Vale, asisten observasi menara lonceng, usia 50-an, hanya bicara dengan angka
[Tag hubungan] mentor_and_former_student

Deskripsikan hubungan kedua orang ini (mentor–mantan murid) dalam 1~2 baris saja
sebagai latar untuk dipakai pada dialog game. Doren dengan angka, Mira dengan dokumen —
agar kedua gaya bicara tidak bertabrakan. Tonnya gaya cendekiawan yang ketat,
buang misteri atau klise seperti "sahabat lama". Hanya isi pokoknya saja.

[Keluaran AI Tahap 3 — Hubungan Satu Baris] (rekonstruksi sesi nyata)

20 tahun lalu Doren mengajari Mira notasi catatan observasi rajah penyegelan. Kini posisinya terbalik: angka yang diukur Doren disalin oleh Mira ke buku besar arsip. Setiap Selasa, keduanya berdebat singkat soal satu kolom di mana nilai observasi tidak cocok dengan buku besar.

Keluaran ini bagus. mentor_and_former_student sudah dikonkretkan, "angka" milik Doren dan "dokumen" milik Mira disatukan tanpa benturan dalam satu adegan (menyalin angka ke buku besar), dan ton scholarly_strict tetap terjaga. Prompt yang sama diulang untuk hubungan regular_customer antara merchant–bystander_1.

Tahap 4 — Sintesis Alur Pergerakan

Jika NPC berdiri di satu tempat sepanjang hari, ia kembali menjadi boneka. Rulebook mengisi pola pergerakan. stationary berarti diam di satu tempat (penjaga·bos), stationary_with_shifts berarti perubahan posisi halus setiap 8 jam (umum), routine_loop berbasis jadwal (penduduk), dan event_driven hanya bergerak saat trigger (NPC quest). Ini bersifat deterministik sehingga tidak memanggil AI.

Tahap 5 — lint Konsistensi Squad (gerbang pipeline ini)

Sekarang kita memeriksa apakah kelima orang yang telah disatukan benar-benar berfungsi seperti sebuah kelompok. Jika lint dari 6.2 melihat NPC individu, maka lint ini melihat konsistensi kelompok.

[Keluaran lint Squad Tahap 5] (format nyata)

[PASS] Distribusi peran: quest_giver 1 · lore_keeper 1 · merchant 1 · bystander 2 (aturan terpenuhi)
[PASS] Kepadatan hubungan: 2 buah (disarankan 2, terpenuhi)
[WARN] Keragaman voice: kelompok scholarly 3/5 — quest_giver·lore_keeper·bystander_2
       memiliki cosine similarity voice_profile 0.83 (melebihi ambang 0.80). Risiko perataan.
[WARN] Tabrakan alur pergerakan: pada rentang 14:00~16:00 koordinat merchant·bystander_1 tumpang tindih dalam radius 1.5m
[FAIL] Eksposur hubungan: 2 hubungan terdefinisi, tetapi tidak ada satu pun penyebutan anggota lain di dialog 5 orang (0 buah).
       Hubungan hanya ada di data — visibilitas dalam game 0.

lint menangkap tiga kasus. Ketiganya tidak dibuang otomatis, melainkan dinaikkan ke gerbang — desain yang sama dengan §6.2.5, yaitu kandidat yang mencurigakan dipilih oleh mesin tetapi keputusan untuk membunuh atau membiarkannya hidup ditentukan oleh manusia.

[Tinjauan Penulis Tahap 6 — Putusan dan Pembuangan]

Penulis menangani ketiga alert ini sebagai berikut.

• Perataan voice (WARN) → Buang bystander_2. Bahkan di kota cendekiawan sekalipun, jika kelima orang semuanya bergaya bicara cendekiawan, area perburuan jadi monoton. Minta regenerasi bystander_2 menjadi pekerja serabutan bergaya practical, dry. (Fakta bahwa quest_giver·lore_keeper keduanya cendekiawan adalah identitas kota, jadi dipertahankan.)
• Tabrakan alur pergerakan (WARN) → Koreksi aturan. Geser offset awal shift merchant menjadi +2 jam untuk menghilangkan tumpang tindih pukul 14:00. Hanya parameter pergerakan yang disesuaikan, tanpa pemanggilan AI.
• Eksposur hubungan 0 (FAIL) → Yang paling penting. Jika dua hubungan sudah didefinisikan tetapi tidak pernah sekali pun terlihat di dalam game, maka data itu adalah data mati. Penulis memutuskan memilih 1 hubungan inti (Doren–Mira) untuk ditanamkan ke dalam dialog.

Dua dari tiga kasus ditutup dengan aturan dan regenerasi, dan FAIL terakhir adalah inti pipeline ini. Penulis meminta tambahan satu baris cabang dialog Doren.

Selipkan satu baris saja pada dialog Doren yang membocorkan hubungannya dengan Mira secara samar.
Jangan bergaya penjelasan, tapi sebagai keterangan sampingan. Ton gaya cendekiawan, satu baris dialog saja.

[Keluaran Permintaan Ulang]

"Cetak biru itu ada di arsip. Tanyakan pada Mira. ...20 tahun lalu akulah yang mengajarinya cara membaca, sekarang malah terbalik."

Pada saat satu baris ini masuk, hubungan kedua NPC berpindah dari sheet data ke layar game. Satu siklus dari input (metadata Squad) → kerangka → pengisian Persona → penguatan hubungan → alur pergerakan → verifikasi konsistensi → keputusan pembuangan·eksposur ditutup di sini.

Satu putaran ini adalah kriteria Show bab ini. Kalimat "NPC sudah disatukan menjadi masyarakat lewat Squad" akan hampa jika kita belum pernah satu kali pun menyaksikan adegan di mana manusia menutup FAIL eksposur hubungan 0 dengan satu baris dialog.

6.3.5 Alur Lengkap Persona→Squad

Saya muat siklus di atas dalam satu gambar. Intinya adalah tahap 1·2·4·5 bersifat deterministik (rulebook·lint) dan hanya tahap 3 yang AI, serta tangan manusia hanya menyentuh input paling atas dan gerbang paling bawah.

flowchart TB
    P["Pool Persona
(hasil generator 6.2)
Doren·Mira·..."] --> FILL
    A["Input: Metadata Squad
(manusia 10~15 menit/area perburuan)
distribusi peran · maksud 2~3 hubungan"]
    A --> B["Tahap 1 deterministik: templates.py
standar distribusi peran·kepadatan hubungan·alur pergerakan"]
    B --> FILL["Tahap 2: pengisian Persona
reuse / generator / penulis langsung"]
    FILL --> C["Tahap 3 AI: penguatan hubungan satu baris
caching L0 + pemeriksaan tabrakan voice_traits"]
    C --> D["Tahap 4 deterministik: sintesis alur pergerakan
shift·routine·event_driven"]
    D --> E{"Tahap 5 deterministik: lint Squad
distribusi peran·keragaman voice
·tabrakan pergerakan·eksposur hubungan"}
    E -->|"alert"| F["Tahap 6 gerbang tinjauan penulis
(5~10 menit/area perburuan)
keputusan pembuangan·koreksi aturan·eksposur hubungan"]
    F -->|"permintaan ulang"| C
    F -->|"lolos"| G["pemberlakuan ke build"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D,E code;
    class C ai;
    class A,F human;
    class P data;
    class G pass;

Tempat yang disentuh tangan manusia hanya dua. Tempat paling atas untuk menetapkan maksud peran·hubungan, dan tempat paling bawah untuk memutuskan ton·narasi yang tidak bisa ditangkap lint. Di antara keduanya, kerangka·alur pergerakan·verifikasi dijalankan oleh rulebook, dan isi pokok hubungan oleh AI.

6.3.6 Tiga Perangkat untuk Membuat Hubungan Terlihat di Game

Item eksposur hubungan pada lint tahap 5 paling sering FAIL. Karena hubungan hanya hidup di data. Ada tiga perangkat untuk menarik hubungan ke dalam game.

Pertama, kutipan dialog. Seperti dialog Doren di §6.3.4, NPC menyebut anggota lain dalam satu baris. Paling murah dan paling besar efeknya.

Kedua, persilangan alur pergerakan. Adegan Doren dan Mira berada bersama di arsip setiap Selasa diamati di dalam game. Jika pengguna melihatnya secara kebetulan, ia akan sadar "apakah kedua orang itu ada kaitannya". Jika alur pergerakan tahap 4 dan hubungan cocok, ini muncul secara alami.

Ketiga, syarat percabangan. Jika permintaan quest_giver ditolak, afinitas lore_keeper ikut turun. Perangkat ketiga inilah pintu masuk penerapan progresif yang disebut di §6.3.1 — titik di mana hubungan mulai memengaruhi keadaan game, melampaui sekadar deskripsi.

Tidak perlu memakai ketiga perangkat. Pada Squad beranggotakan 5 orang, bahkan jika hanya 2\~3 hubungan inti yang diekspos lewat perangkat pertama·kedua, rasa yang dirasakan dari area perburuan sudah berubah besar. Jika berlebihan, pengguna jadi punya banyak yang harus diingat. Penulis memilih hubungan mana yang akan diekspos pada tahap tinjauan dan menyelipkannya, sedangkan sisanya dibiarkan hanya sebagai data.

6.3.7 Pengukuran — Secara Jujur

Saya membandingkan sebelum dan sesudah pengenalan alat. Saya tidak memakai angka olahan. Waktu dan rasio adalah nilai yang saya hitung dengan meninjau langsung beberapa area perburuan awal termasuk silvermark, dan kolom "sebelum pengenalan" adalah perkiraan penulis dari masa kerja manual.

Karena sampelnya kecil, hanya beberapa area perburuan, tepat untuk membacanya sebagai nilai arah, bukan rasio populasi yang presisi. Perubahan terbesar tidak termuat dalam tabel. Karena FAIL eksposur hubungan pada lint memaksakan ke penulis "area perburuan ini, satu pun hubungan tidak terlihat", maka produk massal yang dirilis sebagai museum boneka berkurang secara struktural. Bahwa pembuangan 0% dan eksposur 0 bukanlah tujuan (§6.2.6) juga berlaku sama di sini. Squad menyerap sebagian besar pekerjaan menyatukan, tetapi tetap harus ada waktu tersisa bagi penulis untuk mengukir sendiri bagian inti seperti satu baris dialog terakhir Doren.

6.3.8 Pool Persona — Jika Tokoh yang Sama Muncul di Beberapa Kota

Jika Squad sudah stabil, operasi yang otomatis menyusul adalah pool Persona. Persona yang sama bisa tampil di beberapa kota. NPC anggota guild cendekiawan yang berpapasan di tiga atau empat kota justru terasa alami. Dunia tidak terlihat sempit, melainkan terlihat terhubung.

persona_pool:
  - id: persona_doren_vale
    voice_traits: [terse, numeric]
    appearance_count: 3
    appearance_cities: [city_021, city_018, city_023]
    signature: false
  - id: persona_mira_kost
    voice_traits: [scholarly, withdrawn]
    appearance_count: 2
    signature: false

Rasio reuse memiliki rentang yang sehat.

Namun jika satu NPC dimunculkan di terlalu banyak kota, jadilah "orang ini muncul lagi". Maksimal kota tempat satu Persona tampil dibatasi pada 5 tempat. Ruang bos dan tokoh signature dilarang di-reuse (signature: true). Mulai dari kemunculan kedua Persona yang sama, variasi visual (pencahayaan·properti) diberlakukan secara wajib. Rentang 30\~50% ini bukan angka presisi melainkan panduan operasional — harus dikoreksi sesuai skala tim·game.

[Penanda Arah — Jika Melihat Pool Persona sebagai Distribusi (Masih Terlalu Dini)] Bagi tim yang pool-nya membesar hingga ratusan NPC, ada satu arah yang lebih maju selangkah — sebuah penanda arah pada posisi yang sama dengan subbab 'vektor dimensi' di §8.2.7 (bukan resep — untuk intuisi konsepnya lihat Lampiran M). voice_lint di §6.3.4 sudah melihat "kedekatan" lewat cosine similarity dua Persona (nilai seperti 0.83). Jika embedding yang sama dinaikkan ke seluruh pool, kebosanan bisa didiagnosis bukan dari kesan penulis melainkan dari kepadatan distribusi — kondisi "gaya bicara cendekiawan berkerumun di satu sudut" terlihat sebagai kepadatan titik di area itu. Maka, alih-alih menandai "satu lagi cendekiawan serupa" di area kepadatan rendah, terbuka jalan untuk mengisi keragaman dengan variasi hasil interpolasi antara dua Persona yang berdekatan. Namun ada dua hal yang perlu diperhatikan dalam tarikan napas yang sama. Persona yang ditarik lewat interpolasi mudah menjadi 'nilai tengah yang mati', yaitu campuran canggung dua NPC, sehingga pada akhirnya manusia harus menghidupkan kembali voice-nya. Dan rasio kebosanan di atas (30\~50%) bukan nilai presisi melainkan panduan operasional, sehingga begitu ia dikonversi menjadi jarak embedding, ada risiko kelonggaran itu menyamar seolah-olah presisi — nilai jarak adalah sinyal yang membantu putusan penulis, bukan putusan itu sendiri.

6.3.9 Enam Kegagalan yang Umum

Yang keempat paling sering terlewat. Pekerjaan mendefinisikan hubungan dan pekerjaan membuat hubungan terlihat di game adalah pekerjaan yang berbeda, dan tanpa pemeriksaan, hampir selalu yang kedua yang tertinggal. Seandainya di hg_3 silvermark lint tidak memaksakan eksposur hubungan 0 sebagai FAIL, maka Doren dan Mira hanya akan menjadi hubungan guru–murid di sheet data saja.

6.3.10 Coba Sendiri — Satu Langkah yang Bisa Anda Lakukan Hari Ini

Versi Ringkas Solo: Anda tidak perlu rulebook maupun lint. Pilihlah 3\~5 NPC yang ada di satu tempat dalam game Anda sendiri (atau game favorit Anda), lalu tuliskan dengan tangan peran dan 2 hubungan dalam format §6.3.2. Setelah itu, tempelkan apa adanya prompt penguatan hubungan dari §6.3.4 untuk menerima deskripsi satu baris, dan terakhir tanyakan langsung — "Di mana hubungan ini terlihat dalam dialog game saat ini?" Jika tidak ada satu tempat pun, itulah persis FAIL eksposur hubungan 0 dari lint. Jika Anda menyelipkan satu baris tentang anggota lain ke dalam dialog satu NPC dan menutup FAIL itu dengan tangan, Anda akan memahami secara langsung pekerjaan apa yang ditangkap verifikasi Squad.

Jika Anda dalam tim, mulailah dengan satu langkah berikut. Buat dulu satu lembar format yaml metadata Squad, dan satu baris pemeriksaan eksposur hubungan dari lint tahap 5 (grep apakah nama·peran anggota lain muncul pada teks dialog setiap NPC). Pemeriksaan distribusi peran dan pemeriksaan tabrakan alur pergerakan menyusul kemudian. Bahkan dengan hanya satu pemeriksaan eksposur hubungan, Anda lebih dulu mencegah kegagalan paling umum di mana area perburuan hasil produksi massal dirilis sebagai museum boneka.

Jika diringkas menjadi setup → prompt → verify — setup: Definisikan peran·hubungan pada yaml metadata Squad dan tetapkan kerangka dengan templates.py. prompt: Terima satu baris hubungan dalam format §6.3.4 sambil mewajibkan larangan tabrakan voice_traits dan larangan klise. verify: Jalankan lint tahap 5 untuk memeriksa FAIL eksposur hubungan, lalu tanamkan 1 hubungan inti ke dialog dan tutup sendiri.

Poin-Poin Penting

• Persona adalah kartu nama, Squad adalah bagan organisasi — hanya dengan memisahkan, museum boneka menjadi masyarakat.
• Anda harus melihat verifikasi penguatan hubungan·alur pergerakan·konsistensi sampai akhir satu kali agar "sudah disatukan menjadi masyarakat" tidak hampa.
• Manusia yang menutup FAIL eksposur hubungan 0 dengan satu baris dialog adalah jantung pipeline ini.

Pratinjau Bab Berikutnya

• 6.4 Workflow Produksi Massal Konten — Menyatukan pembuatan Persona·Squad·kota ke dalam siklus 1 minggu

6.4 Alur Kerja Produksi Konten — Merangkai Beberapa Generator dalam Satu Lini

Pada minggu yang sama saat saya selesai membuat ketiga alat itu, dalam satu sesi saya menjalankan generator kota, lalu generator NPC, lalu generator item. Ketiganya bekerja dengan baik secara terpisah. Kota menghasilkan 7 tempat, NPC menghasilkan 110 orang, dan senjata menghasilkan 60 buah. Namun beberapa hari kemudian, saat duduk untuk meninjau, saya baru sadar bahwa saya telah menginjak jebakan yang sama sebanyak tiga kali.

Kota port_harman dibuat sebagai "desa nelayan yang runtuh", tetapi persona NPC yang ditempatkan di kota itu adalah "pedagang kaya dari pelabuhan dagang yang makmur". Ini terjadi karena generator kota dan generator NPC melihat lore_seeds yang berbeda. Generator senjata menaruh senjata legendaris level 40 di toko, padahal level yang disarankan untuk kota itu adalah 12–18. Ketiga alat itu masing-masing benar; mereka salah karena tidak dirangkai.

Bab ini bukan cerita tentang membuat satu alat. Ini adalah cerita operasional tentang merangkai generator kota dari 6.2, NPC Squad dari 6.3, dan generator item menjadi satu lini produksi. Kalau ada tiga alat, jebakannya pun bukan tiga — jebakan baru muncul di celah di antara alat-alat itu.

6.4.1 Sudut Pandang Lini Produksi

Jika generator kota, NPC, dan item dijalankan terpisah, keluaran tiap alat tidak cocok dengan masukan alat lain. Solusinya bukan membuat alat lebih pintar, melainkan mengunci metadata bersama satu kali di hulu, lalu menyusun alat-alat itu berbaris di bawahnya. Kalau generator kota di 6.2 bab 2 adalah contoh teladan untuk satu alat tunggal, bab ini adalah pekerjaan menurunkan alat itu menjadi satu stasiun dalam sebuah lini.

Seluruh lini mengalir seperti ini.

flowchart TD
    SEED[Senin: sheet lore_seeds
region·climate·faction·level_range]:::human
    SEED --> CITY[Selasa: generator kota
kerangka rulebook L1 + isi AI L2]
    CITY -->|city_manifest.json| NPC[Selasa: generator NPC
mewarisi lore kota]
    CITY -->|level_range| ITEM[Selasa: generator item
mewarisi rentang level·faksi]
    NPC -->|persona_pool| SQUAD[Selasa: penempatan Squad]
    ITEM --> SQUAD
    SQUAD --> LINT[Rabu: lint terpadu
konsistensi lintas generator]
    LINT -->|alert| REVIEW1[Rabu: tinjauan ke-1
penulis sendiri]
    REVIEW1 --> REVIEW2[Kamis: sampel ke-2
lead naratif]
    REVIEW2 --> BUILD[Jumat: terapkan ke build
+ siapkan seed minggu depan]
    BUILD -.umpan balik.-> SEED

    classDef human fill:#fde68a,stroke:#b45309,color:#000;

Intinya adalah panah bernama city_manifest.json. Saat generator kota membuat sebuah kota, ia menjatuhkan identitas kota itu (apakah desa nelayan yang runtuh atau pelabuhan dagang yang makmur) sebagai manifest, dan generator NPC serta generator item menerima manifest itu sebagai masukan. Jebakan yang saya injak waktu itu terjadi karena panah ini tidak ada. Merangkai alat berarti menyisipkan satu baris kontrak ini di antara alat-alat.

6.4.2 Satu Baris Kontrak yang Merangkai Alat — manifest

Berikut bentuk nyata dari city_manifest.json yang dikeluarkan generator kota setiap kali ia membuat satu kota. File inilah yang menjadi masukan bagi generator NPC dan item.

{
  "city_id": "port_harman",
  "display_name": "Pelabuhan Harman",
  "lore_seeds": ["desa nelayan yang runtuh", "gema dagang masa lalu", "kekurangan garam"],
  "region": "pesisir selatan",
  "dominant_faction": "Serikat Nelayan",
  "level_range": [12, 18],
  "tone": "kemunduran·keuletan",
  "forbidden_names": ["Haran", "Harmen"],
  "neighbors": ["salt_marsh", "old_pier"]
}

Generator NPC mewarisi lore_seeds dan tone untuk membuat "orang-orang ulet dari desa nelayan yang runtuh". Generator item mewarisi level_range sehingga hanya menaruh senjata level 12–18. forbidden_names adalah nama yang sudah dipakai kota tetangga, jadi keduanya menghindarinya. Ketiga alat membaca satu lembar kontrak yang sama.

Saat membuat manifest ini, berikut prompt yang saya berikan kepada Claude. Karena ini adalah satu panggilan terpenting yang merangkai hulu lini produksi, saya kutipkan utuh apa adanya.

Kamu adalah penulis manifest untuk generator kota MMORPG. Terimalah metadata penulis di bawah ini dan hasilkan city_manifest.json.

Masukan penulis: - city_id: port_harman - lore_seeds: desa nelayan yang runtuh, gema dagang masa lalu, kekurangan garam - region: pesisir selatan - level_range: 12-18

Aturan: 1. dominant_faction disimpulkan dari lore_seeds, tetapi tidak boleh sama dengan faksi kota tetangga (salt_marsh, old_pier). Faksi kota tetangga adalah [Koperasi Ladang Garam, Sindikat Penyelundup]. 2. Pada forbidden_names, masukkan NPC/nama tempat yang sudah dipakai kota di sekitarnya. Daftar yang disediakan: [Haran, Harmen]. 3. tone maksimal dua kata. Jangan bertentangan dengan lore_seeds. 4. Tandai dengan jelas mana nilai yang kamu tebak dan mana yang dinyatakan eksplisit oleh penulis.

Berikut keluaran mentah dari Claude. Saya kutipkan apa adanya tanpa meringkas. Ia melanggar aturan di satu tempat.

{
  "city_id": "port_harman",
  "display_name": "Pelabuhan Harman",
  "lore_seeds": ["desa nelayan yang runtuh", "gema dagang masa lalu", "kekurangan garam"],
  "region": "pesisir selatan",
  "dominant_faction": "Sindikat Penyelundup",   // ← penyimpulan: kekurangan garam + dagang masa lalu = penyelundupan
  "level_range": [12, 18],
  "tone": "kemunduran·ketamakan",
  "forbidden_names": ["Haran", "Harmen"],
  "neighbors": ["salt_marsh", "old_pier"]
}

(Nilai yang disimpulkan: dominant_faction, tone, display_name / Dinyatakan penulis: sisanya) Perhatian: saya memilih dominant_faction sebagai "Sindikat Penyelundup", tetapi pada Aturan 1 kota tetangga old_pier sudah memakai "Sindikat Penyelundup". Ini melanggar aturan. Sebagai alternatif, saya mengusulkan "Serikat Nelayan".

Yang penting di sini adalah AI melaporkan sendiri pelanggaran aturannya. "Sindikat Penyelundup" memang penyimpulan yang menarik jika dilihat dari lore_seeds (kekurangan garam·dagang masa lalu), tetapi pada tingkat lini, itu adalah konflik. Kota tetangga sudah menjadi sindikat penyelundup. Saya menerima usulan AI dan mengubah dominant_faction menjadi "Serikat Nelayan" dan tone menjadi "kemunduran·keuletan". "Ketamakan" adalah kata yang muncul dari premis penyelundup, jadi tidak cocok dengan serikat nelayan.

Satu putaran verifikasi·penolakan·penugasan ulang ini menjaga hulu lini. Jika manifest salah, maka 110 NPC dan 60 senjata di bawahnya semuanya dibuat di atas premis yang salah. Menghabiskan 5 menit di hulu menghemat 3 jam di hilir.

6.4.3 Lint Terpadu — Memeriksa Celah di Antara Alat

Lint dari satu generator tunggal hanya melihat keluarannya sendiri. Lint kota memeriksa apakah kota mematuhi rulebook, dan lint NPC memeriksa apakah persona menjaga konsistensi voice. Tetapi jebakan yang saya injak di awal ada bukan di dalam tiap alat, melainkan di antara alat. Karena itu, lini membutuhkan satu lapis lagi di atas lint tunggal. Itulah lint terpadu yang membaca kota·NPC·item bersama-sama dan memeriksanya secara silang.

Berikut item-item yang benar-benar ditangkap lint terpadu.

Berikut sebagian keluaran nyata saat menjalankan lint terpadu ini. Tidak ada pembuangan otomatis. Ia hanya memunculkan alert agar manusia yang memutuskan.

[lint terpadu] pemeriksaan lini port_harman — 3 alert

ALERT-1 (keselarasan lore) port_harman
  city.lore_seeds = ["desa nelayan yang runtuh", ...]
  npc[merchant_04].persona = "pedagang kaya dari pelabuhan dagang yang makmur"
  → Mungkin bertentangan. Perlu konfirmasi apakah ini variasi yang disengaja.

ALERT-2 (keselarasan rentang level) port_harman
  city.level_range = [12,18]
  item[blade_legend_07].required_level = 40
  → Melampaui rentang level yang disarankan sebesar 28. Tinjau ulang penempatan di toko.

ALERT-3 (duplikasi nama) — info
  npc[fisher_02].name = "Haran"
  city.forbidden_names = ["Haran", ...]
  → Bertentangan dengan forbidden_names. Disarankan membuat ulang nama NPC.

Melihat ALERT-1, saya sempat berpikir sejenak. Tidak mutlak salah jika NPC adalah "pedagang kaya dari pelabuhan dagang yang makmur". Jika kotanya adalah dulu makmur lalu kini runtuh, maka "pedagang yang dulu kaya, kini miskin" justru narasi yang bagus. Karena itu saya memutuskan ALERT-1 bukan sebagai pembuangan, melainkan sebagai "variasi yang disengaja", lalu meminta satu baris koreksi persona NPC menjadi "pedagang tua yang berpegang pada jejak pelabuhan dagang yang dulu makmur". ALERT-2 jelas merupakan kecelakaan, jadi saya buang senjatanya. ALERT-3 hanya saya buat ulang namanya.

Bukan lint otomatis yang mencegah kecelakaan. Lint otomatis menyeret kecelakaan itu ke depan mata manusia, dan manusialah yang memutuskan. Inilah inti dari L2 (rulebook + bantuan AI) yang saya sebut di 6.1. AI membuat kerangka dan alert, lalu manusia membuat keputusan akhir. Memilah hal "yang tampak salah tetapi merupakan narasi bagus" seperti ALERT-1 adalah sesuatu yang tidak bisa dilakukan rulebook.

6.4.4 Menjalankan Lini dalam Siklus 1 Minggu

Setelah alat dirangkai, dibutuhkan ritme. Lini paling stabil jika berputar dalam satuan 1 minggu. Seminggu cukup pendek agar tinjauan tidak meledak, dan cukup panjang agar umpan balik tidak terlalu lambat. Ia pas dengan satu kotak di kalender meja saya.

Selasa adalah jantung lini. Saat generator kota menjatuhkan manifest, generator NPC menerimanya, generator item menerimanya, dan Squad bahkan menempatkannya. Rantai ini berputar di latar belakang tanpa intervensi penulis. Selama itu, penulis menulis main quest (L0, sepenuhnya manual). Imbalan sejati dari merangkai alat ada di sini. Jika alat-alat terpisah, penulis harus turun tangan tiga kali pada hari Selasa, tetapi jika dirangkai, ia tidak turun tangan sekali pun.

Satu penulis tunggal memproduksi 5–7 kota dalam seminggu, lengkap dengan NPC·senjata yang menyertainya. Empat minggu berarti 20–28 kota. Target 30 kota tercapai dalam 6 minggu.

6.4.5 Kesehatan Lini — Empat Indikator yang Dipantau Tiap Minggu

Sehat atau tidaknya lini dilihat dari angka, bukan kesan. Berikut empat indikator yang dikumpulkan otomatis tiap minggu.

Indikator yang paling khas lini adalah yang kedua, jumlah konflik lintas generator. Saat hanya memakai satu alat tunggal, angka ini tidak ada. Jika angka ini tiba-tiba melampaui 10, itu bukan berarti satu alat rusak, melainkan kontrak antar alat (manifest) yang pecah. Biasanya ini meledak ketika skema manifest generator kota diubah tetapi generator NPC masih membaca skema lama. Tanpa indikator ini, kecelakaan tersebut tidak akan terlihat sampai rilis.

Keempat indikator dikumpulkan tiap minggu dan dibawa ke retrospektif kuartalan. Jika trennya memburuk, jumlah kota yang diproduksi minggu berikutnya dikurangi dari 5–7 menjadi 3–5 dan penyebabnya ditelusuri.

6.4.6 Tiga Kecelakaan yang Meruntuhkan Lini

Merangkai beberapa alat memunculkan kecelakaan yang tidak ada pada alat tunggal. Saya catat tiga yang sering saya temui.

Pertama, kecelakaan ketidakcocokan kontrak. Sebuah field baru ditambahkan ke manifest generator kota, tetapi generator NPC tidak mengenal field itu. Indikator konflik silang melonjak. Saat alat dikembangkan terpisah, mudah sekali hanya satu sisi yang ter-update. Penanggulangannya adalah menaruh field version pada skema manifest, dan membuat generator hilir langsung memunculkan alert saat versi tidak cocok. Bukan mendesak manusia, melainkan menegakkan kontrak.

Kedua, kecelakaan pencemaran hulu. Jika manifest dibuat dengan premis yang salah (seperti "Sindikat Penyelundup" di §6.4.2), maka semua yang di bawahnya tercemar. Tingkat pembuangan tinjauan manusia melebihi 30%, tetapi saat dilihat, kualitas tiap NPC secara individual baik-baik saja. Individualnya baik, tetapi premisnya yang salah. Penanggulangannya adalah menaruh satu tinjauan lagi pada tahap pembuatan manifest. Daripada meninjau 110 keluaran hilir, tinjaulah 1 keluaran hulu.

Ketiga, kecelakaan drift model. LLM ter-update otomatis sehingga karakteristik keluaran berubah. Ketiga generator kota·NPC·item bergoyang serentak. Periksa perubahan dalam 1 minggu terakhir, analisis 5 sampel yang dibuang, lalu sesuaikan prompt atau konteks. Konfirmasi pemulihan setelah memantau selama 1 minggu.

Penanggulangan ketiga kecelakaan ini sama. Jangan menyalahkan manusia, perkuat kontraknya. Jika penyebabnya adalah penulis hanya menulis satu baris lore_seeds, alih-alih berkata "tulislah tiga baris", tambahkan pemeriksaan paksa ke lint manifest. Itu bukan berarti tanggung jawab manusia menjadi 0. Terlepas dari penguatan sistem, pola kecelakaan dibagikan dalam retrospektif.

6.4.7 Ke Mana Waktu Penulis Pergi

Tujuan sejati merangkai lini bukan untuk menghilangkan penulis, melainkan agar penulis bisa fokus pada karya khasnya. Berikut saya gambarkan dalam satu lembar bagaimana waktu penulis tercerai-berai saat alat terpisah, dan bagaimana ia terkumpul setelah dirangkai.

80% waktu penulis terkumpul pada main quest dan karya khas. Tetapi pembagian ini tidak terjaga dengan sendirinya. Saat lini diterapkan, ada kecenderungan waktu penulis mengalir habis ke tinjauan. Karena itu, saya mengukur pembagian waktu tiap bulan, dan jika main quest jatuh di bawah 50%, saya mengurangi jumlah kota produksi untuk memulihkan waktu main quest. Pembagian waktu harus dijaga sebagai kebijakan.

6.4.8 Memperluas Lini ke Konten Lain

Setelah lini kota·NPC·item stabil, kerangka yang sama diperluas ke dungeon·ensiklopedia·event live. Intinya adalah tidak membuat pola baru. Godaan "dungeon berbeda dari kota, jadi pakai struktur lain" selalu datang. Tetapi kerangka lini (manifest bersama → rantai generator → lint terpadu → tinjauan manusia) tetap sama persis. Yang diganti hanya format metadata masukan dan rulebook domain.

Untuk dungeon, field seperti boss_pattern·encounter_flow ditambahkan ke dungeon_manifest.json, dan aturan domain seperti jalur gerak bos ditambahkan satu baris ke lint terpadu. Kerangkanya sama, hanya aturannya yang berbeda. Jika kerangka yang sama dipertahankan, penulis tidak perlu mempelajari alat baru lagi, dan infrastruktur lint terpadu dipakai ulang apa adanya. Namun ini bukan berarti mengabaikan kekhasan domain. Dungeon jelas membutuhkan aturan jalur gerak yang tidak ada di kota.

6.4.9 Hasil Pengoperasian 6 Bulan

Berikut hasil mengoperasikan lini terpadu ini selama 6 bulan di proyek saya, dibandingkan dengan periode saat generator kota·NPC·item dijalankan terpisah. Angka absolut di bawah bukan agregasi yang akurat, melainkan perkiraan penulis (belum terverifikasi), sedangkan arah dan rasionya mengikuti kecenderungan hasil pengukuran nyata.

Perubahan terpenting ada di baris terakhir. Saat alat terpisah, tinjauan hulu 0 dan tinjauan hilir 3 jam. Setelah merangkai lini dan meninjau manifest di hulu, 5 menit di hulu menghapus 2 jam di hilir. Karena kecelakaan tidak lagi bocor di celah antar alat, kecelakaan konsistensi setelah rilis pun turun dari 8–12 menjadi 2–4 per kuartal.

Dan trade-off-nya menjadi eksplisit. Dulu, perdebatan abstrak "produksi massal itu berbahaya" berputar setiap kuartal. Sekarang, keputusan dibuat di atas perbandingan konkret "konflik -8 / main quest +5".

6.4.10 Tujuh Kegagalan yang Umum

1) Menjalankan alat terpisah tanpa merangkainya. Jebakan muncul bukan di dalam alat, melainkan di antara alat.

2) Menghubungkan generator tanpa manifest. Tanpa kontrak bersama, hilir akan menyimpang dari hulu.

3) Mengganti lint terpadu dengan lint tunggal. Lint tunggal tidak bisa melihat konflik silang.

4) Memampatkan siklus dari 5 hari menjadi 3 hari. 5 hari adalah margin keamanan tinjauan.

5) Meninjau hilir tanpa meninjau hulu (manifest). Lihatlah 1 keluaran hulu, bukan 110 keluaran hilir.

6) Membebankan kecelakaan hanya sebagai tanggung jawab manusia. Penguatan kontrak·otomasi aturan adalah jawabannya.

7) "Tidak memakai" lini setelah memilikinya. Memaksakan siklus 1 minggu sama pentingnya dengan alatnya sendiri.

Coba Sendiri

setup. Siapkan generator kota (6.2) dan generator NPC (6.3). Tetapkan satu skema city_manifest.json yang akan dibagi keduanya. Field minimalnya adalah lore_seeds·region·faction·level_range·forbidden_names·tone·version.

prompt. Gunakan persis prompt penulis manifest dari isi bab di atas. Intinya adalah dua aturan terakhir. "Jangan sama dengan faksi kota tetangga" (mencegah konflik silang) dan "tandai dengan jelas nilai yang ditebak dan yang dinyatakan" (kemungkinan untuk ditinjau). Saat membuat kota, jatuhkan manifest, dan hubungkan agar generator NPC·item menerima manifest itu sebagai masukan.

verify. Jalankan lint terpadu satu kali. Ia memeriksa silang empat hal: keselarasan lore·keselarasan rentang level·konflik faksi·duplikasi nama. Jika alert muncul, jangan langsung membuang otomatis, biarkan manusia yang memutuskan. Memilah hal "yang tampak salah tetapi merupakan narasi bagus" (pedagang tua dari pelabuhan dagang yang runtuh) adalah bagian manusia.

Versi Ringkas Solo. Meskipun alat hanya dua, kota dan NPC, lini tetap terbentuk. Cukup tulis lore_seeds·level_range·forbidden_names tiap kota dalam satu lembar spreadsheet, lalu tempelkan utuh baris itu ke prompt generator NPC — itu sudah berperan sebagai manifest. Lint terpadu pun bisa mencegah jebakan itu meskipun hanya berisi satu baris keselarasan lore kota-NPC. Tanpa infrastruktur megah, satu prinsip "menyisipkan satu baris kontrak di antara alat" sudah cukup untuk memulai sebuah lini.

Poin-Poin Penting

• Jebakan muncul bukan di dalam alat, melainkan di antara alat; rangkailah celah itu dengan manifest
• Lint terpadu bukan alat pembuang, melainkan alat yang menyeret kecelakaan ke depan mata manusia
• Tinjauan hulu 5 menit menghapus tinjauan hilir 2 jam; cegahlah dari atas

Bagian 7 · Desain Level

7.1 Menguasai Desain Level Prosedural

Pintu keluar ruang nomor 47 di sebuah dungeon tertutup rapat. Build lolos, QA juga lolos. Tangkapan layar seorang pengguna yang berdiri menatap dinding tepat sebelum ruang bos muncul di komunitas pada hari ketiga setelah game live. Ruang itu dibuat dengan menyalin sebuah ruang yang dirancang manual dua patch sebelumnya, dan dalam proses penyalinan itu satu koridor timur hanya menyisakan visualnya tanpa informasi koneksi apa pun. Tidak ada seorang pun yang memverifikasinya. Tidak ada alat untuk memverifikasinya.

Bab ini adalah cerita tentang membangun sebuah struktur yang membuat insiden seperti itu otomatis tercegah pada tahap build. Intinya bukan pada keterampilan tangan menggambar ruang, melainkan pada cara mengoperasikan data yang menempel pada ruang itu sebagai aturan (rule).

Ruang kerja desain level lebih mirip ruang gambar teknik (drafting room). Setiap lembar gambar lahir dari tangan manusia, tetapi konsistensi, penggunaan ulang, dan verifikasi antargambar ditentukan oleh aturan pengelolaan lemari arsip gambar itu. Membuat satu dungeon dengan tangan bisa dilakukan siapa saja. Mengoperasikan 100 dungeon dengan kurva kesulitan yang konsisten dan graf tanpa jalan buntu bukanlah soal keterampilan tangan, melainkan soal sistem.

Pada Proyek A tempat saya bekerja sebagai Design Director (MMORPG yang menargetkan pasar domestik + Asia Tenggara, tim berskala menengah (10\~50 orang), mengutamakan mobile), nama sistem ini adalah satu dokumen bernama Procedural_Level_Design_Master. Bab ini membahas apa yang diintegrasikan dokumen itu, sampai mana AI ikut campur tangan, dan di mana ia berhenti. Pengalaman saya memimpin desain sebuah RPG roguelite mobile yang dungeon-nya dibangkitkan ulang setiap run, dan mengoperasikan ruang prosedural sebagai aturan, menjadi landasan bab ini.

7.1.1 Dua Cabang — Membangun Ruang, atau Mengoperasikan Metadata Ruang?

Otomatisasi level bercabang ke dua arah. Yang satu adalah membangkitkan ruang itu sendiri secara prosedural. Procedural Content Generation (PCG) tradisional seperti pembagian BSP (Binary Space Partitioning, teknik klasik yang membelah ruang secara rekursif menjadi dua untuk menempatkan ruang), wave function collapse, dan drunken walk grid termasuk di sini. Yang satunya lagi adalah mengoperasikan metadata ruang — tag ruang, konektivitas, label kesulitan, slot event.

PCG tradisional kuat di arah pertama. Pada genre yang menjadikan "peta baru setiap permainan" sebagai inti gameplay seperti roguelike atau sandbox, arah pertama adalah jawabannya. Tetapi MMORPG berbeda. Pengguna menjelajahi dungeon yang sama berpuluh-puluh kali. Cukup sering hingga jalurnya hafal di luar kepala. Karena itu dungeon harus berupa ruang tetap yang dipoles dengan tangan, dan tempat masuknya otomatisasi bukanlah ruang itu sendiri, melainkan metadata yang membuat ruang itu dapat dioperasikan.

Mengapa metadata adalah tulang punggung operasional menjadi jelas bila dilihat per keluaran kerja.

Dungeon tanpa metadata bisa di-build, tetapi tidak bisa dioperasikan. Sama seperti perpustakaan yang penuh buku tetapi tanpa indeks. Inilah alasan bab ini berfokus pada "pengoperasian metadata ruang".

7.1.2 Apa yang Diintegrasikan Dokumen Master

Procedural_Level_Design_Master mengikat empat standar dalam satu dokumen: format metadata ruang, kamus tag ruang, aturan konektivitas, dan checklist verifikasi. Mari kita lihat dulu apa yang terjadi ketika keempatnya tercerai-berai. Bila lima desainer masing-masing merujuk format dari file yang berbeda, ada yang menulis field type sebagai combat, ada yang menulis Combat, dan ada yang menulis battle_room. Pencarian rusak, statistik rusak, dan akhirnya otomatisasi rusak.

Keempat standar ini, bila ditata berdasarkan Layer, posisinya masing-masing menjadi jelas. Format·kamus·aturan ada di rulebook yang menguasai pembangkitan (L1), bagian utama ruang yang sudah dibangkitkan ada di konten (L2), nilai sheet ada di data (L3), dan verifikasi ada di gerbang build·QA (L4).

Mengatakan bahwa dokumen master mengintegrasikan empat standar bukan berarti "menjejalkan semua isi ke dalam satu file", melainkan "mengumpulkan aturan di posisi L1". Karena itulah otomatisasi yang akan muncul nanti bisa ditumpangkan di atas batas Layer (apa yang terjadi bila pemisahan ini runtuh dibahas di 7.1.11).

7.1.3 Format Metadata Ruang — Titik Input tempat Otomatisasi Menempel

Satu ruang mengikuti format berikut. Format inilah antarmuka input bagi otomatisasi.

room_id: dungeon_021_room_07
dungeon: dungeon_021_silvermark_library
type: combat_room          # combat / puzzle / lore / safe / boss
size: medium               # small / medium / large
difficulty_label: hard_for_level_28
tags: [scholar_theme, vertical_layout, water_hazard]
connections:
  - target_room: dungeon_021_room_06
    type: door
    direction: south
  - target_room: dungeon_021_room_08
    type: passage
    direction: east
event_slots:
  - slot: enemy_spawn_1
    constraints: [scholar_enemy, level_28]
  - slot: lore_object_1
    constraints: [scholar_lore]
movement_complexity: 4     # 1~5
estimated_clear_time_sec: 90
art_pack: scholar_library_v2

Setiap field memiliki satu atau lebih konsumen otomatisasi. type dipakai untuk statistik kumpulan dungeon dan perhitungan kesulitan, tags untuk pencarian·penggunaan ulang·pemetaan art set, connections untuk verifikasi graf (pemeriksaan jalan buntu), dan event_slots untuk penempatan otomatis quest·bos. Field yang tidak punya konsumen tidak dimasukkan ke format. Sebab ia hanya menambah biaya input tanpa memberi nilai.

7.1.4 Kamus Tag Ruang — Kecil dan Ortogonal

Tag adalah kunci pencarian metadata. Bila berkembang biak tak terbatas, pencarian rusak. Bila ada 200 label tertempel pada laci, mustahil menemukan apa ada di mana. Karena itu dikelola dengan 5 kategori × sekitar 6 enum per kategori, totalnya sekitar 30.

Tag pada satu ruang tidak melebihi 5. Normalnya 3\~4. Untuk menambahkan tag baru, ia harus melewati gerbang empat tahap. Harus menjadi kandidat pakai pada 5 ruang atau lebih per patch, tidak bisa diekspresikan dengan kombinasi tag yang ada, pemanfaatannya untuk pencarian·pemetaan art set harus jelas, dan tetap dipakai pada 5 ruang bahkan setelah 1 bulan beroperasi. Syarat terakhir adalah intinya. Bila tag yang dibuat sementara dipakai sekali lalu dibuang, kamus menjadi tercemar.

7.1.5 Pipeline Level Prosedural — Dari Rulebook hingga Verifikasi

Bagaimana standar-standar sejauh ini terhubung menjadi satu alur, garis penghubung itulah kerangka yang ditopang bab ini. Ini adalah pipeline yang dimulai dari rulebook, melewati variasi berbantuan AI, dan berakhir dengan verifikasi guardrail.

flowchart TD
    A["L0 Visi — Konsep dungeon·niat pacing"] --> B["L1 Rulebook\nKamus tag · Aturan konektivitas · Aturan slot"]
    B --> C["Penataan kerangka ruang\nKerja manual desainer + editor"]
    C --> D["Ekstraksi metadata otomatis\nroom_id · connections · type · size"]
    D --> E["Variasi berbantuan AI\nEkstraksi tags · usulan pemetaan art_pack"]
    E --> F{"Pemeriksaan paksa kamus\nTag di luar kamus?"}
    F -->|Di luar kamus| E
    F -->|Lolos| G["Tinjauan desainer\nFinalisasi tags · difficulty_label"]
    G --> H["L4 Verifikasi graf\nKeterjangkauan · jalan buntu · siklus · percabangan"]
    H -->|Pelanggaran| C
    H -->|Lolos| I["Verifikasi kurva kesulitan\nPenjumlahan label kesulitan ruang"]
    I --> J["Gerbang keselarasan art set"]
    J -->|Lolos| K["Build — Registrasi kumpulan dungeon"]
    J -->|Tidak selaras| E

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D,F,H,I,J code;
    class E ai;
    class C,G human;
    class K pass;

Saya tegaskan tiga sifat pipeline ini. Pertama, rulebook (L1) berada di hulu dari seluruh pembangkitan. Kedua, AI hanya bervariasi di dalam kamus yang didefinisikan rulebook — gerbang F mengembalikan keluaran di luar kamus. Ketiga, verifikasi (H·I·J) terpasang sebagai gerbang tepat sebelum build, sehingga pelanggaran dicegah oleh kode, bukan bergantung pada kewaspadaan manusia. Insiden ruang nomor 47 terjadi karena gerbang H tidak ada.

7.1.6 Aturan Konektivitas — Guardrail yang Diverifikasi dengan Graf

Field connections pada meta ruang menjadikan seluruh dungeon satu graf berarah. Begitu menjadi graf, verifikasi menjadi otomatis.

Skrip pengukurannya berbentuk seperti berikut. Ini adalah wrapper tipis yang melapisi kosakata dungeon di atas algoritma graf standar (jalur terpanjang·rata-rata derajat keluar·hitungan loop·jalur terpendek).

# level_graph_metrics.py
def measure(dungeon):
    graph = build_graph(dungeon.rooms)
    return {
        "depth":            longest_path_length(graph),
        "branching_factor": avg_out_degree(graph),
        "loop_count":       count_loops(graph),
        "dead_ends":        count_dead_ends(graph),
        "boss_reachability": shortest_path(graph.start, graph.boss),
    }

Lima metrik dikeluarkan dalam bentuk yang dapat dibandingkan dengan dungeon lain. Dipakai sebagai metrik keragaman kumpulan dungeon. Namun, metrik yang beragam tidak berarti dungeon itu menyenangkan. Metrik dipakai untuk mencegah insiden, bukan untuk menjamin keseruan. Jalan buntu 0 buah tidak menjamin keseruan. Keseruan lahir dari insight desainer, dan verifikasi graf hanya menjadi alas yang menopang agar insight itu tidak terkubur oleh insiden.

7.1.7 Worked Transcript (rekaman sesi nyata) — Menyerahkan Ekstraksi tags ke AI, Menolaknya, dan Memintanya Ulang

Bagian yang paling sering ingin dilepas tangan oleh manusia dalam otomatisasi adalah input tags. Memberi tag pada 100 ruang itu membosankan, dan kalau hanya melihat tangkapan layar ruang, manusia pun bingung. Pekerjaan yang berulang dan kriteria penilaiannya jelas seperti inilah justru tempat yang baik bagi AI untuk menopang draf awal. Subbab ini membentangkan tanpa olahan alur kerja yang benar-benar saya jalankan untuk pekerjaan itu — mulai dari prompt, keluaran AI yang ditolak, hingga permintaan ulang dari manusia.

Prompt pertama:

[Input]
- Tangkapan layar ruang: (terlampir)
- Luas ruang: 18m × 12m, tinggi langit-langit 9m (struktur vertikal 2 lantai)
- Musuh yang ditempatkan: scholar_phantom × 3, water_elemental × 1
- type ruang yang berdekatan: lore_room (barat), combat_room (timur)
- Ada genangan air dangkal di dalam ruang

Pilihkan 3~5 tag yang cocok untuk ruang ini hanya dari kamus di bawah. Jangan membuat tag di luar kamus,
cukup enum tag yang dipisah koma.

[Kamus tag 30 buah]
theme: scholar_theme, ruins_theme, forest_theme, cave_theme,
       crypt_theme, swamp_theme, mechanical_theme, celestial_theme
layout: vertical_layout, horizontal_corridor, open_arena,
        maze_layout, bridge_layout
hazard: water_hazard, fire_hazard, falling_hazard,
        poison_hazard, crush_hazard, dark_hazard
interaction: puzzle_required, lever_activation, key_gate, hidden_passage
narrative: flashback_trigger, dialogue_zone, lore_object_zone,
           ambush_setup, ritual_site, vista_point, rest_anchor

Keluaran pertama Claude (mentah apa adanya):

scholar_theme, vertical_layout, water_hazard, ambush_setup, two_story_layout

Di sini dua masalah langsung tampak. Yang satu adalah two_story_layout merupakan tag yang tidak ada di kamus. Model terseret oleh input "struktur vertikal 2 lantai" dan mengarang kata di luar kamus. Yang lain adalah tag sudah menyentuh batas atas dengan 5 buah, padahal vertical_layout dan two_story_layout tumpang tindih secara makna. Artinya, dua slot terpakai pada kategori layout.

Keputusan penolakan dari manusia. two_story_layout adalah objek penolakan otomatis karena melanggar paksaan kamus (gerbang F pipeline). ambush_setup masih bisa dipertimbangkan dua arah — 3 ekor musuh memang ditempatkan, tetapi tidak jelas apakah pada tangkapan layar itu komposisi penyergapan (ambush), atau sekadar ruang tempur biasa. Ada kemungkinan model menafsirkan secara berlebihan. Karena kedua ruang yang berdekatan adalah lore/combat, dasar untuk pemicu penyergapan naratif lemah. Ditolak.

Permintaan ulang kedua:

two_story_layout tidak ada di kamus dan tumpang tindih dengan vertical_layout. Buang.
ambush_setup juga buang — ada musuh bukan berarti penyergapan.
// (niat: tag narrative hanya saat niat naratif dinyatakan eksplisit, tempur biasa sudah diekspresikan lewat type)
Slot kosong tidak perlu dipaksa diisi. 3~4 buah itu normal. Tolong beri tag ulang.

Keluaran kedua Claude:

scholar_theme, vertical_layout, water_hazard

Kali ini berkurang menjadi 3 buah, semuanya ada di dalam kamus, dan tidak ada duplikasi kategori. Manusia menerima hasil ini. tags: [scholar_theme, vertical_layout, water_hazard] pada format ruang difinalisasi seperti ini.

Pelajaran dari worked transcript ini ada dua baris. Pertama, AI overfit pada satu detail input ("2 lantai") lalu keluar dari kamus — gerbang paksaan kamus harus menangkap ini pada level kode. Kedua, AI cenderung ingin mengisi slot kosong — bila tidak menyatakan eksplisit "tidak perlu dipaksa diisi", ia berusaha memenuhi kelima slot. Kedua kegagalan itu lumrah, dan kedua resep penanganannya harus dipaksakan bukan dari prompt melainkan dari rulebook (kamus + batas atas) agar stabil.

7.1.8 Memproduksi Metadata — Siapa yang Mengisi dan Siapa yang Meninjau

Bila desainer mengisi meta 1 ruang dengan tangan, butuh 5\~10 menit. Untuk 1 dungeon (20\~30 ruang) itu 2\~5 jam, dan untuk 100 dungeon itu 200\~500 jam (perkiraan penulis, belum terverifikasi — batas atas yang dikonversi dari rata-rata waktu input per ruang × jumlah ruang). Bila semuanya diisi dengan tangan, desainer menjadi budak input metadata.

Karena itu subjek pengisian dibagi per area.

Yang difinalisasi desainer dengan tangan kira-kira hanya tinjauan tags dan persetujuan akhir difficulty_label. Sisanya diisi alat dan ditinjau manusia. Tujuan otomatisasi adalah menarik desainer keluar dari input dan mengembalikannya ke penilaian pacing·ruang signature·kebijakan penggunaan ulang.

7.1.9 Penggunaan Ulang Ruang dan Jebakannya

Efek terbesar dari standar master adalah penggunaan ulang ruang. Bila ada 30 ruang yang dapat dicari lewat tag, kita bisa membuat 5\~10 dungeon dengan mengombinasikannya. Tetapi bila rasio penggunaan ulang naik, dungeon menjadi membosankan. Karena itu penggunaan ulang disertai guardrail.

Penggunaan ulang adalah sarana untuk mengurangi biaya, bukan tujuan. Begitu rasio penggunaan ulang itu sendiri dijadikan KPI, pengalaman pengguna menjadi monoton. Pada 0% (semua ruang baru) biaya produksi meledak, dan bila melebihi 70% dungeon-dungeon tidak bisa dibedakan satu sama lain. Dari pengalaman, rentang 30\~40% adalah titik keseimbangan antara biaya dan keragaman (observasi arah, ambang presisinya berbeda-beda per proyek).

7.1.10 Kegagalan Umum dan Resepnya

7.1.11 Penguraian Layer adalah Prasyarat Pembangkitan Level Prosedural

Struktur 7.1.2\~7.1.6 yang sejauh ini saya uraikan dengan rulebook·pembangkitan·verifikasi itu sendiri adalah hasil dari penguraian Layer. Tesis umum bahwa penguraian Layer adalah prasyarat pembangkitan prosedural·otomatisasi (jangkar L0 → rulebook L1 → bagian utama L2 → angka L3 → gerbang L4, bila menjadi satu gumpalan pembangkitan akan runtuh) telah dibahas di §6.6. Di sini saya menerapkannya pada pengoperasian metadata level.

Tanpa pemisahan ini, penataan ruang·BSP·pacing·pemicu naratif tercampur dalam satu file, dan setiap kali memindahkan satu ruang, niat pacing·slot event·graf konektivitas rusak serentak. Ini seperti situasi di mana ruang gambar·gudang material·ruang inspeksi menumpuk di satu meja, sehingga mencabut satu lembar gambar ikut menarik keluar faktur material dan lembar inspeksi. Karena itulah bantuan AI di 7.1.7 bisa berfungsi juga berkat Layer. Room ID·konektivitas diisi dari editor (ekstraksi otomatis L3), tags dari AI (paksaan kamus L1), difficulty_label dari penjumlahan (L3→L4). Otomatisasi ditumpangkan di atas batas Layer; bila ditumpangkan di atas satu gumpalan, dalam patch pertama insiden meledak hingga alat itu sendiri dibuang.

Namun ini bukan berarti sejak awal harus menyiapkan laci lima sekat secara sempurna. Prinsipnya adalah pemisahan bertahap, antarmuka sempit. Pada patch pertama, memisahkan hanya rulebook L1 (kamus tag + aturan konektivitas) dan sheet L3 (sheet meta ruang) saja sudah memberi tempat bagi otomatisasi untuk masuk. Niat pacing L0 dan gerbang verifikasi L4 diisi sambil melewati patch demi patch. Standar harus diseragamkan agar tercipta tempat bagi otomatisasi untuk masuk, dan semakin banyak otomatisasi masuk, semakin desainer berfokus pada penilaian pacing·signature·penggunaan ulang alih-alih kerja manual satu ruang.

Poin-Poin Penting

• Tempat baru otomatisasi level bukan pada ruang itu sendiri, melainkan pada pengoperasian metadata ruang.
• Verifikasi harus dipasang sebagai gerbang build, bukan kewaspadaan manusia, agar insiden tidak bocor ke live.
• Variasi AI hanya diizinkan di dalam kamus yang didefinisikan rulebook, dan keluaran di luar kamus ditolak oleh kode.

Coba Sendiri

setup. Pilih satu dungeon, lalu buat sheet YAML yang per ruang hanya memiliki empat field room_id · type · connections · tags. Untuk tag, kunci dulu kamus berisi sekitar 30 enum dalam 5 kategori di selembar kertas.

prompt. Masukkan tangkapan layar ruang + luas + jenis musuh + type ruang yang berdekatan, lalu minta dengan "pilih hanya 3\~5 tag dari kamus ini, dilarang tag di luar kamus, jangan isi slot kosong" (persis prompt 7.1.7).

verify. (1) Bila ada tag di luar kamus pada keluaran AI, tolak dan minta ulang. (2) Buat graf dengan connections lalu periksa keterjangkauan awal→bos dan jalan buntu — bila muncul satu saja pelanggaran, tandai ruang itu sebagai tidak dapat di-build.

Versi Ringkas Solo

Bila Anda developer solo tanpa infrastruktur alat, mulailah dokumen master sebagai satu lembar markdown. 30 baris kamus tag, 5 baris aturan konektivitas, 5 baris checklist verifikasi sudah cukup. Untuk verifikasi graf, bila ruang 10 buah atau kurang, menggambar panah di atas kertas dan memeriksa jalan buntu saja dengan mata sudah menghasilkan 80% dari efeknya. Intinya bukan alat, melainkan kebiasaan itu sendiri yaitu "melekatkan data pada ruang, dan memeriksa data itu dengan aturan". Alat ditambahkan ketika jumlah ruang melewati 50 dan memeriksanya dengan tangan menjadi berat.

Pratinjau Bab Berikutnya

• 7.2 Editor BehaviorTree — Mengoperasikan pohon perilaku AI, area yang berdekatan dengan level, berbasis rulebook·metadata

7.2 Editor BehaviorTree — Worked Transcript Saat Manusia dan AI Bersama-sama Menyunting dan Memverifikasi BT json

Seekor penyihir magang menempel pada pemain sambil mengayunkan pedang. NPC itu saya rancang sebagai caster sihir jarak jauh. HP-nya setipis kertas dan dalam jarak dekat cukup satu pukulan untuk mati, tetapi makhluk itu sama sekali tidak berniat menjaga jarak. Tidak ada satu pun error di log build. Saat saya buka kembali BehaviorTree-nya di editor pun, simpul-simpulnya terhubung dengan rapi. Setelah satu jam menatapnya, saya menemukan penyebabnya. Kondisi jarak pada cabang mundur (retreat) ternyata terisi 0.5, bukan 5. Seharusnya ia kabur saat musuh masuk ke dalam jarak 5 meter, tetapi cabang mundur baru aktif kalau musuh sudah dalam jarak 0.5 meter — artinya nyaris menempel.

Hanya satu angka. Di editor simpul grafis, angka itu baru terlihat kalau panel di dalam simpul dibuka, dan tidak tercatat di riwayat perubahan. Tidak ada cara melacak siapa mengubah nilai itu dan kapan. Sejak hari itu, Proyek A saya mulai menangani BehaviorTree bukan sebagai grafis, melainkan sebagai json. Bab ini adalah catatan satu siklus saat manusia dan AI bersama-sama menyunting json itu, lalu mesin memverifikasinya secara otomatis.

7.2.1 Titik di Mana BT (BehaviorTree, pohon perilaku) Lepas dari Genggaman

BehaviorTree adalah struktur baku de facto untuk mendefinisikan pertempuran, pergerakan, dan reaksi NPC musuh. Selektor (selector) mencoba cabang sesuai urutan prioritas, sedangkan sekuens (sequence) merangkai kondisi dan aksi secara berurutan. Strukturnya sendiri sederhana. Masalahnya ada pada skala.

Di Proyek A saya, BT satu NPC musuh terdiri atas sekitar 50\~200 simpul, dan NPC yang dioperasikan melampaui 100 ekor. Dikalikan, total simpul BT menjadi puluhan ribu satuan. Pada skala ini, akan tiba saatnya manusia tidak lagi mampu menjawab pertanyaan "Kalau pola mundur ini saya ubah, NPC mana saja yang terpengaruh?" Ini seperti ada seratus buku catatan terbuka di atas meja, dan saat satu baris di buku pertama diperbaiki, Anda harus menelusuri dengan mata bagian mana di sembilan puluh sembilan buku sisanya yang ikut merembet.

Saat beralih dari BT grafis ke json, ada empat hal yang saya tuntut.

Editor BT bawaan pada engine game komersial mudah diintegrasikan dan kuat dalam debugging visual. Hanya saja, BT itu cenderung disimpan sebagai aset biner (binary), sehingga diff teks dan pelacakan dampak perubahan menjadi lemah. Karena Proyek A saya mengasumsikan game live dengan lebih dari 100 BT yang dioperasikan, saya memilih untuk mengembangkan sendiri format BT json terpisah beserta editornya. Mari kita perjelas. Ini bukan jawaban yang tepat untuk semua tim. Kalau BT yang dioperasikan di bawah 50 ekor, memakai editor bawaan engine apa adanya hampir selalu lebih murah. Pembenaran pengembangan sendiri akan dibahas lagi di akhir bab ini.

7.2.2 BT json — Perilaku Satu Musuh dalam Bentuk Teks

Pertama, kita lihat dulu bentuk hasilnya. Di bawah ini adalah sebagian BT NPC tipe pendukung jarak jauh dari guild sarjana. Intinya ada dua. Karena semua perilaku berbentuk teks, git bisa melacaknya per baris; dan pola umum dikutip lewat subtree_ref.

{
  "bt_id": "bt_scholar_archer_v3",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "ranged", "support"],
  "description": "Tipe pendukung jarak jauh guild sarjana. Jaga jarak + utamakan mundur.",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.3},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "kite_pattern",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 5},
          {"type": "action", "fn": "move_away", "param": {"distance": 8}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_ranged_attack_pattern"}
    ]
  }
}

Kalau pohon ini dibentangkan menjadi gambar, strukturnya adalah selektor yang mencoba tiga cabang dari atas. Perhatikan bahwa bug di bagian pembuka — apakah param dari enemy_in_close_range itu 5 atau 0.5 — di dalam json menjadi satu baris yang langsung terlihat sekilas.

flowchart TD
    R["selector
(prioritas dari atas)"]
    R --> A["sequence: low_hp_retreat"]
    R --> B["sequence: kite_pattern"]
    R --> C["subtree_ref:
subtree_ranged_attack_pattern"]
    A --> A1["condition: hp_below 0.3"]
    A --> A2["subtree_ref:
subtree_retreat_to_ally"]
    B --> B1["condition: enemy_in_close_range 5"]
    B --> B2["action: move_away dist=8"]

    style C fill:#e8f0fe,stroke:#4285f4
    style A2 fill:#e8f0fe,stroke:#4285f4
    style B1 fill:#fce8e6,stroke:#ea4335

enemy_in_close_range 5 yang diwarnai merah itulah simpul yang menyita waktu satu jam di bagian pembuka. Di dalam json, ia terjaring dalam sekali code review.

7.2.3 Pustaka subtree — Kutipan, Bukan Salin-Tempel

Pada perilaku lebih dari 100 musuh, ada bongkahan yang berulang. Hal-hal seperti "mundur ke belakang sekutu", "mundur ke balik perlindungan", "pola serangan jarak jauh". Kalau ini disalin ke tiap BT, maka untuk memperbaiki satu logika mundur saja, Anda harus mencari dan memperbaikinya secara manual di seratus tempat. Karena itu, pola umum dipisahkan ke berkas subtree tersendiri dan cukup dikutip lewat subtree_ref.

subtree_library/
├── retreat_patterns/
│   ├── subtree_retreat_to_ally.json
│   ├── subtree_retreat_to_cover.json
│   └── subtree_retreat_random.json
├── attack_patterns/
│   ├── subtree_ranged_attack_pattern.json
│   ├── subtree_melee_combo.json
│   └── subtree_aoe_attack.json
└── reaction_patterns/
    ├── subtree_react_to_ally_death.json
    └── subtree_react_to_player_taunt.json

Dengan menatanya seperti ini, pertanyaan "Kalau subtree ini saya perbaiki, siapa yang terpengaruh?" menjadi keluaran skrip, bukan tebakan manusia. Pelacak dampaknya sederhana. Ia membuka semua BT, lalu mengumpulkan bt_id dari BT yang mengutip subtree bersangkutan.

# bt_impact_tracker.py
import json, glob

def has_subtree_ref(node, target_id):
    if isinstance(node, dict):
        if node.get("type") == "subtree_ref" and node.get("id") == target_id:
            return True
        for child in node.get("children", []):
            if has_subtree_ref(child, target_id):
                return True
    return False

def find_affected_bts(subtree_id):
    affected = []
    for bt_file in glob.glob("bts/*.json"):
        bt = json.load(open(bt_file, encoding="utf-8"))
        if has_subtree_ref(bt["root"], subtree_id):
            affected.append(bt["bt_id"])
    return affected

# Penggunaan
affected = find_affected_bts("subtree_ranged_attack_pattern")
# → ["bt_scholar_archer_v3", "bt_ranger_v2", "bt_sniper_v1", ...]

Di Proyek A saya, fungsi ini saya ikatkan ke tahap permintaan perubahan (Pull Request). Saat seseorang menyentuh berkas subtree, daftar BT yang terpengaruh otomatis terlampir sebagai komentar PR. Sebelum merge, peninjau (reviewer) sudah melihat fakta bahwa "satu baris pola mundur diperbaiki, tetapi 12 musuh jarak jauh semuanya ikut berubah".

7.2.4 Worked Transcript — Satu Siklus Saat AI Menulis Draf BT Baru

Mulai dari sini adalah bagian yang paling berbobot di bab ini. Saya menyerahkan draf BT NPC musuh baru "penyihir magang" kepada AI, lalu memindahkan apa adanya — tanpa dipoles — satu siklus saat manusia memverifikasi, menolak, dan meminta ulang keluaran itu. Ada alasan mengapa saya tidak meringkasnya agar mulus. Sebab seluruh isi yang ingin disampaikan bab ini terletak pada apa yang salah pada keluaran pertama AI dan bagaimana salahnya — tekstur dari kegagalan itu.

Step 1 — Prompt yang Diberikan Manusia (lengkap)

[Konsep NPC musuh]
Penyihir magang dari guild sarjana. HP rendah dan damage sihir tinggi.
Utamakan menghindari jarak dekat. Mundur ke belakang sekutu lalu serang dengan sihir.

[category] ranged_combatant

[BT acuan] bt_scholar_archer_v3
(Struktur serupa. Hanya saja serangan panah diganti dengan serangan sihir)

[enum fungsi yang terdefinisi]
condition: hp_below, enemy_in_close_range, ally_nearby, mana_below
action: move_away, cast_spell, retreat, wait
subtree_ref id (daftar yang bisa dipakai):
- subtree_retreat_to_ally
- subtree_ranged_attack_pattern   # Berbasis panah. Bukan untuk sihir
- subtree_magic_attack_pattern

Susun saja json simpul root BT dengan konsep ini. Pakai subtree_ref semaksimal mungkin dan simpul langsung seminimal mungkin,
fungsi hanya dari dalam enum di atas. Jangan tambahkan perilaku yang tidak ada di konsep. Hanya json tanpa penjelasan.

Step 2 — Keluaran Pertama Claude (apa adanya tanpa olahan)

{
  "bt_id": "bt_scholar_apprentice_v1",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "magic", "fragile"],
  "description": "Penyihir magang guild sarjana. Hindari jarak dekat + mundur ke belakang sekutu + serangan sihir.",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.4},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "avoid_melee",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 6},
          {"type": "action", "fn": "move_away", "param": {"distance": 10}}
        ]
      },
      {
        "type": "sequence",
        "name": "mana_recover",
        "children": [
          {"type": "condition", "fn": "mana_below", "param": 0.2},
          {"type": "action", "fn": "wait", "param": {"frames": 120}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_ranged_attack_pattern"}
    ]
  }
}

Step 3 — Verifikasi·Penolakan oleh Manusia

Setelah keluaran diterima, saya jalankan lewat lint (dibahas di subbab berikutnya) lalu membacanya dengan mata. Ada tiga tempat yang terjaring.

1. Cabang terakhir salah. subtree_ranged_attack_pattern adalah pola serangan berbasis panah. Meski di komentar enum sudah saya tulis "Bukan untuk sihir", AI tetap mengambil pola panah yang namanya mirip. Penyihir magang seharusnya memakai subtree_magic_attack_pattern. — Ditolak.

2. Menambahkan perilaku yang tidak ada di konsep. Cabang mana_recover (mana_below → wait 120frame) adalah perilaku yang tidak disebut satu baris pun di konsep. Padahal di prompt sudah saya tegaskan "dilarang menambahkan perilaku yang tidak ditentukan", tetapi tampaknya AI menilai "karena ini penyihir, mengelola mana itu wajar" lalu menyisipkannya. Terdengar masuk akal, tetapi melanggar spesifikasi. — Ditolak.

3. Ambang mundur mencurigakan. hp_below 0.4 memulai mundur lebih cepat ketimbang BT acuan (0.3). Memang benar penyihir magang lebih lemah, jadi bisa jadi ini disengaja. Hanya saja AI tidak pernah memberi alasannya, jadi ini urusan yang harus diputuskan desainer. — Ditangguhkan, konfirmasi desainer.

Step 4 — Permintaan Ulang oleh Manusia

Perbaiki tiga tempat saja. subtree_ranged_attack_pattern pada cabang terakhir itu pola panah, jadi
ganti dengan subtree_magic_attack_pattern, lalu cabang mana_recover tidak ada di konsep jadi hapus seutuhnya,
hp_below 0.4 kembalikan ke nilai BT acuan (0.3) — kalau ada alasan memakai 0.4, tulis satu baris di description.
Sisanya biarkan apa adanya, hanya json.

Step 5 — Keluaran Kedua Claude (versi revisi)

{
  "bt_id": "bt_scholar_apprentice_v1",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "magic", "fragile"],
  "description": "Penyihir magang guild sarjana. Hindari jarak dekat + mundur ke belakang sekutu + serangan sihir. HP rendah sehingga ambang mundur dijaga 0.3 (sama dengan archer).",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.3},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "avoid_melee",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 6},
          {"type": "action", "fn": "move_away", "param": {"distance": 10}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_magic_attack_pattern"}
    ]
  }
}

Keluaran kedua lolos lint, dan dalam tinjauan desainer, jarak 6 pada avoid_melee diturunkan satu takik menjadi 5 agar selaras dengan archer, lalu diteruskan ke gerbang simulasi. Pelajaran di sini jelas. AI mengisi kerangka BT dengan cepat, tetapi hampir setiap kali melakukan dua kesalahan: "menarik subtree salah yang namanya mirip" dan "menyisipkan perilaku tambahan yang terdengar masuk akal tanpa spesifikasi". Dua kesalahan ini hanya terjaring oleh mata manusia dan gerbang lint. Karena itu, keluaran AI adalah draf, bukan final.

7.2.5 Lint Otomatis — Mesin Menangkap Lebih Dulu Apa yang Terlewat Manusia

BT berkaitan langsung dengan pengalaman pengguna. Kalau insiden musuh yang tidak kabur padahal sudah di depan mata ikut terbawa rilis, itu akan kembali sebagai skor ulasan. Karena itu, sebelum merge, mesin memeriksanya lebih dulu.

Item terakhir adalah keunikan lint ini. Kalau lima BT yang terkelompok sebagai ranged_combatant yang sama memiliki rata-rata waktu respons simulasi yang melebar jauh, itu sinyal bahwa seseorang merusak balance satu ekor tanpa disadari. Ini adalah perkakas yang menangkap "suasana" yang tidak bisa dijaring pemeriksaan statis, melalui statistik.

Setelah lint statis adalah verifikasi simulasi. BT dijalankan 1,000 kali di simulator tanpa build game sungguhan untuk menarik statistiknya.

Tanpa membuat build, dalam 5\~10 menit kita bisa melihat "apakah BT ini terlalu cepat mati" atau "apakah ia hanya mengulang satu perilaku saja". Kalau muncul sinyal anomali, json diperbaiki lalu simulasi dijalankan ulang. Berkurangnya siklus ini dari satuan hari menjadi satuan menit adalah keuntungan nyata dari pen-json-an.

flowchart LR
    P["Manusia/AI
menyunting BT json"] --> L{"lint statis"}
    L -->|blokir| P
    L -->|lolos| R["tinjauan desainer"]
    R -->|tolak| P
    R -->|setujui| S{"simulasi 1,000 kali"}
    S -->|sinyal anomali| P
    S -->|normal| M["merge + terapkan ke build"]
    style L fill:#fef7e0,stroke:#fbbc04
    style S fill:#fef7e0,stroke:#fbbc04
    style M fill:#e6f4ea,stroke:#34a853

7.2.6 Pengukuran — Apa yang Berkurang

Saya sajikan kondisi sebelum dan sesudah penerapan di Proyek A saya dalam bentuk tabel. Angka absolut berubah tergantung ukuran tim·genre game, jadi ini adalah perkiraan penulis (belum terverifikasi). Hanya saja, arah dan rasionya persis seperti yang saya amati dalam operasi nyata.

Yang paling bermakna adalah dua baris terakhir bergerak bersamaan. Biasanya, mengurangi jumlah orang akan menurunkan kualitas. Di sini, seiring jumlah desainer berkurang, insiden pun ikut berkurang. Sebab dampak perubahan dan verifikasi yang dulu dilacak manusia secara manual kini diemban mesin. Nilai otomasi terletak pada "berkurang sekaligus membaik" ini, bukan sekadar "menjadi lebih cepat".

7.2.7 Mengembangkan Sendiri, atau Meminjam

Kalau setelah membaca bab ini Anda menyimpulkan "ayo kita juga buat editor BT json", itu merepotkan. Proyek A saya memilih mengembangkan sendiri karena kondisi-kondisi tertentu kebetulan cocok semuanya.

Alasan Proyek A memilih opsi nomor 3 ada empat.

• Pelacakan diff·git adalah keharusan — BT bawaan adalah aset biner, sehingga insiden "satu angka" di bagian pembuka tidak bisa dilacak.
• Kutipan subtree dan pelacakan dampak otomatis adalah inti operasi — ini fitur yang lemah pada perkakas BT standar.
• Verifikasi simulasi perlu dijalankan di runtime yang terpisah dari build.
• Penulisan berbantuan AI menjadi prasyarat — basis teks (json) jauh lebih bersahabat dengan large language model (LLM, Large Language Model).

Biaya pengembangan 1\~2 bulan. Investasi ini baru kembali kalau BT yang dioperasikan mencapai 100\~300 ekor dan periode operasi game-nya panjang. Pada skala 30\~50 ekor, investasinya tidak balik. Artinya, return on investment (ROI, Return On Investment) dari pengembangan sendiri baru muncul kalau skala dan periode operasi sama-sama terjamin. Kalau tim Anda kecil, lebih tepat mengambil dari bab ini hanya prinsip-prinsipnya saja — "disimpan sebagai json", "dikutip lewat subtree", "keluaran AI dilewatkan ke gerbang lint+tinjauan" — sementara perkakasnya ditumpangkan pada editor bawaan atau pustaka eksternal.

7.2.8 Kegagalan yang Umum

Poin-Poin Penting

• BT harus disimpan sebagai json agar insiden "satu angka" tercatat di git diff dan terlacak.
• Kutipan subtree dan pelacakan dampak otomatis mencegah neraka salin-tempel pada operasi 100 ekor.
• AI mengisi kerangka BT dengan cepat, tetapi kutipan yang salah dan perilaku di luar spesifikasi ditangkap manusia.

Coba Sendiri

Berikut siklus minimum yang bisa dicoba tim kecil hari ini.

setup — Tuliskan sendiri BT satu NPC musuh yang sedang dioperasikan ke dalam json (bt_id, category, tags, root). Pisahkan satu bongkahan pola mundur·serangan umum ke subtree_library/ lalu kutip lewat subtree_ref.

prompt — Serahkan satu musuh baru yang serupa kepada AI. Anda cukup memakai apa adanya kerangka prompt dari worked transcript di atas (konsep + category + BT acuan + enum fungsi yang bisa dipakai + "dilarang menambahkan perilaku yang tidak ditentukan" + "hanya json").

verify — Lewatkan keluaran AI ke tiga gerbang ini sebelum merge: (1) lint yang menyaring fungsi di luar enum·subtree yang tidak ada, (2) mata manusia, (3) simulasi atau verifikasi singkat in-game. Pastikan apakah AI menyisipkan "subtree salah yang namanya mirip" dan "perilaku di luar spesifikasi yang terdengar masuk akal".

Versi Ringkas Solo

Kalau Anda tidak punya kapasitas membuat editor, perkakas yang Anda butuhkan cukup editor teks dan git, plus satu bt_impact_tracker.py sepanjang 30 baris. Ekspor sekali BT yang Anda susun di editor bawaan menjadi json lalu unggah ke git, dan pisahkan hanya subtree ke berkas tersendiri lalu kutip. Kalau skrip pelacak dampak Anda ikatkan ke commit hook, bahkan seorang diri pun Anda bisa melihat "kalau pola mundur ini saya perbaiki, musuh mana yang berubah" sebagai keluaran, bukan tebakan. Hanya dengan satu kebiasaan ini, "satu jam demi satu angka" di bagian pembuka menyusut menjadi satu baris code review.

Pratinjau Bab Berikutnya

• 7.3 Pustaka Pola Dungeon·Field — Menggabungkan metadata room dengan pola subtree untuk mengikat level menjadi satuan operasi.

7.3 Pustaka Pola Dungeon dan Field

Di sebuah sesi peninjauan dungeon, seorang Level Designer baru menampilkan satu dungeon buatannya di layar. Koridor sempit, musuh cepat yang mengejar dari belakang, keputusan menghindar di titik percabangan. Itu dungeon yang dibuat dengan baik. Masalahnya, dungeon itu sedikit berbeda — secara halus — dari sebelas dungeon lain yang sudah pernah kami buat. Kecepatan kejar musuh, waktu jebakan meledak, momen munculnya percabangan. Tidak ada satu pun yang sama. Sang desainer baru yakin ia telah membuat sebuah pengalaman bernama sama, yaitu "dungeon kejar-kejaran", tetapi sensasi yang diterima pengguna berbeda-beda di setiap dungeon.

Keputusan kami hari itu sederhana. Mari kita definisikan pengalaman "kejar koridor" satu kali secara tepat, lalu kita kunci definisi itu jadi aturan. Lain kali, ketika seseorang membuat dungeon kejar-kejaran, ia tidak menyusunnya dari awal, melainkan memanggil definisi yang sudah dibakukan itu. Inilah awal mula pustaka pola.

Jika room adalah unit ruang dan BehaviorTree adalah unit perilaku, maka pola adalah unit operasional yang mengikat ruang, perilaku, dan peristiwa menjadi satu. Ketika satu pola dipakai ulang di beberapa dungeon, beban produksi massal berkurang, dan yang lebih penting, pengalaman yang diterima pengguna menjadi konsisten antardungeon.

7.3.1 Pola sebagai Unit Operasional

Bayangkan resep dalam buku masak; perumpamaan itu tepat. Satu lembar resep memuat bahan, urutan memasak, besar api, dan foto hasil jadi, semuanya bersama-sama. Meski restorannya berganti, mengikuti resep yang sama akan menghasilkan rasa yang sama. Namun setiap restoran tetap diizinkan sedikit variasi. Pola pun begitu. Ruang (room), perilaku (BT subtree), peristiwa (event), hasil (aturan hadiah dan tingkat kesulitan), serta penjelasan maksud desainer masuk dalam satu kesatuan.

Begitu satu pola didefinisikan, pengalaman yang sama dapat dibuat secara konsisten di setiap dungeon. Sebagaimana satu resep yang sudah terverifikasi menghasilkan rasa yang sama di berbagai restoran. Hanya saja, meski resepnya sama, setiap restoran tetap diberi sedikit variasi. Cara mengelola variasi inilah yang menjadi separuh dari pengelolaan pola. Di situlah letak overrides yang akan dibahas nanti.

7.3.2 Alur Penggabungan Pola

Inti pustaka pola adalah: pola dikunci jadi aturan dalam rulebook (buku aturan), lalu digabungkan untuk menghasilkan dungeon. Desainer tidak menyusun dungeon dari layar kosong, melainkan memilih dan menempatkan pola yang sudah terverifikasi serta hanya memvariasikan sebagiannya.

flowchart TD
    A[Amati momen pengalaman baik dalam game] --> B[Uraikan jadi ruang·NPC·event]
    B --> C[Petakan ke template room·subtree]
    C --> D{Lolos simulasi + uji pengguna?}
    D -- Tidak --> B
    D -- Ya --> E[Daftarkan pola ke pustaka
usage_count = 0]
    E --> F[(Pustaka pola
5 kategori · 30–50 buah)]
    F --> G[Desain dungeon: panggil instans pola]
    G --> H[Penempatan placement + variasi overrides]
    H --> I{Rasio variasi 20% atau kurang?}
    I -- Ya --> J[Dungeon selesai
pola usage_count +1]
    I -- Tidak --> K[Tinjau pemisahan jadi pola terpisah]
    K --> B
    J --> L[Lacak dampak pola
satu pola diubah → dungeon pemakai dihitung otomatis]
    L --> F

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class L code;
    class F data;
    class J pass;

Separuh kiri alur ini (amati→uraikan→petakan→verifikasi→daftarkan) adalah proses membuat pola, sedangkan separuh kanan (panggil→tempatkan·variasi→selesai→lacak) adalah proses mengonsumsi pola. Pekerjaan membuat jarang terjadi, pekerjaan mengonsumsi sering terjadi. Bila pustaka dikelola dengan baik, ketidaksimetrisan ini berbuah efisiensi produksi massal.

7.3.3 Lima Kategori Dasar

Proyek A milik penulis berjenis Action RPG, sehingga pola diklasifikasikan ke dalam lima kategori. Klasifikasi ini bergantung pada genre. Jika game-nya horor, bobot penyergapan dan beat naratif akan berbeda; jika game-nya puzzle, pertarungan yang memanfaatkan lingkungan akan menjadi pusatnya. Jangan menganggap klasifikasi itu sendiri sebagai sesuatu yang mutlak; tentukan dulu apa pengalaman inti game Anda, baru susun kategorinya.

Di dalam lima kategori, jumlah pola dipertahankan kira-kira antara tiga puluh hingga lima puluh buah. Angka ini ada alasannya. Bila pola melewati seratus buah, desainer tidak bisa lagi menyimpan seluruh pustaka di kepalanya. Begitu titik itu tercapai, pustaka berubah menjadi gudang yang butuh waktu untuk dicari, dan desainer lebih memilih menyusun yang baru. Begitu pustaka mulai diabaikan, tujuan awalnya — konsistensi — runtuh. Karena itu, mengelola batas atas jumlah pola secara sadar sama pentingnya dengan merancang kategorinya.

7.3.4 Format untuk Mengunci Pola jadi Aturan

Satu pola dibakukan dalam satu lembar berkas YAML. Berikut adalah bentuk yang benar-benar dipakai di Proyek A, yang telah dianonimkan. Nama aset milik perusahaan dan nomor dungeon ditutupi, tetapi struktur field dan cara pengoperasiannya tetap apa adanya.

---
pattern_id: pattern_corridor_pursuit_v2
category: pursuit
description: Musuh cepat mengejar dari belakang di koridor sempit, pemain mengambil keputusan menghindar di titik percabangan
tags: [horizontal_corridor, scholar_theme_compatible]
rooms:
  - room_template: corridor_long
    size: medium
    connections_required: 2
  - room_template: junction_3way
    size: small
    connections_required: 3
npc_behaviors:
  - subtree_ref: subtree_aggressive_chase
    count: 2
  - subtree_ref: subtree_ranged_support
    count: 1
events:
  - type: trap_activation
    trigger: room_1_midpoint
  - type: enemy_spawn
    trigger: room_1_entry
difficulty_modifier: 1.2   # beban 1.2 kali lipat dibanding room biasa
reward_modifier: 1.3
clear_time_estimate_sec: 60
art_pack_compatible: [scholar_library, generic_dungeon]
narrative_slots:
  - slot: dialogue_during_chase
    constraints: [short_dialogue, fear_emotion]
usage_count: 12            # dipakai di 12 dungeon
last_modified: 2026-05-18
deprecated: false
---

Berkas ini secara bersamaan mendefinisikan satu bagian dari masing-masing dua belas dungeon. Bobot satu baris usage_count: 12 berasal dari situ. Artinya, mengubah pola ini berarti dua belas dungeon terkena dampaknya sekaligus, sehingga menyentuh berkas pola punya bobot yang berbeda dari sekadar memperbaiki satu room.

Referensi seperti subtree_aggressive_chase atau subtree_ranged_support menunjuk langsung ke subtree yang didefinisikan di editor BehaviorTree pada 7.2. Intinya, pola tidak memuat BT secara langsung, melainkan hanya merujuknya. Ketika BT diperbaiki, semua pola yang merujuk BT tersebut otomatis ikut diperbarui. Ruang (template room) dan perilaku (subtree) dikelola di pustaka masing-masing, sementara pola hanya berperan sebagai tabel penggabung yang menjalin keduanya. Nilai seperti clear_time_estimate_sec atau difficulty_modifier hanyalah nilai operasional di lingkungan penulis, bukan konstanta universal. Anda harus mengisinya dengan mengukur langsung lewat simulasi dan uji pengguna game Anda sendiri.

7.3.5 Menginstansiasi Pola ke dalam Dungeon

Saat mendesain dungeon, pola tidak disusun dari awal. Pola dipanggil dari pustaka, ditentukan letaknya, lalu bagian yang ingin dibuat berbeda khusus di dungeon ini ditimpa dengan overrides.

---
dungeon_id: dungeon_021_silvermark_library
pattern_instances:
  - instance: corridor_pursuit_1
    pattern_id: pattern_corridor_pursuit_v2
    placement:
      - room_id: dungeon_021_room_03
        as: corridor_long
      - room_id: dungeon_021_room_04
        as: junction_3way
    overrides:
      - field: npc_behaviors.0.subtree_ref
        value: subtree_scholar_chase   # varian bertema sarjana
      - field: events.0.trigger
        value: room_1_2nd_third         # penyetelan halus posisi pemicu
---

Di sini dungeon 021 memakai pola "kejar koridor" apa adanya, tetapi mengganti musuh pengejar dari musuh biasa menjadi varian bertema sarjana, serta memindahkan posisi jebakan meledak dari tengah koridor sedikit ke belakang. 80% pola tetap apa adanya, hanya 20% yang divariasikan.

Rasio ini punya dasar dari pengalaman operasional. Bila variasinya terlalu sedikit (mendekati 0%), dungeon-dungeon terasa membosankan seperti saling menjiplak. Bila variasinya terlalu banyak (melewati 50%), itu sudah bukan lagi pola yang sama. Anda mengira memanggil pola yang sama, padahal pengalaman nyatanya benar-benar berbeda — kembali persis ke situasi dungeon yang dibawa desainer baru itu. Karena itu kami menetapkan aturan operasional. Bila overrides satu instans melewati separuh field pola, itu bukan variasi, melainkan sinyal pola baru. Sudah waktunya memisahkannya menjadi pola terpisah.

7.3.6 Bila Satu Baris Diubah, di Mana Saja yang Goyah

Mengubah pattern_corridor_pursuit_v2 akan berdampak pada dua belas dungeon. Jika manusia melacaknya dengan tangan, pasti ada satu-dua yang terlewat. Karena itu kami menyiapkan alat kecil yang otomatis menyisir hubungan antara pola dan dungeon.

# pattern_impact.py
import json
from glob import glob

def find_dungeons_using(pattern_id):
    affected = []
    for d in glob("dungeons/*.json"):
        dungeon = json.load(open(d, encoding="utf-8"))
        for inst in dungeon.get("pattern_instances", []):
            if inst["pattern_id"] == pattern_id:
                affected.append({
                    "dungeon": dungeon["dungeon_id"],
                    "instance": inst["instance"],
                    "has_overrides": bool(inst.get("overrides")),
                })
    return affected

Inti dari daftar yang dikembalikan fungsi ini adalah flag has_overrides. Dungeon tanpa overrides memakai pola apa adanya, sehingga aman untuk diperbarui otomatis. Dungeon dengan overrides membutuhkan tinjauan manusia tambahan, karena variasi khas dungeon itu bisa berbenturan dengan perubahan pola.

Alih-alih manusia merasakan bobot perubahan satu per satu, alat ini melaporkan dalam 5 menit bahwa "perubahan kali ini berdampak pada 12 dungeon, 4 di antaranya punya variasi sehingga perlu ditinjau langsung". Nilai sebenarnya dari alat ini adalah mengurangi rasa takut untuk mengubah pola. Bila cakupan dampak tidak terlihat, desainer enggan mengubah pola sama sekali, dan pustaka pun menjadi air yang tergenang.

7.3.7 Bagaimana Pola Lahir, dan di Mana Tempat AI

Di sini saya akan menghadapi langsung pertanyaan yang paling sering saya terima. "Bukankah penulisan pola juga bisa diserahkan ke AI?"

Jawabannya jelas. Tidak bisa. Menulis satu pola bertumpu pada wawasan (insight) desainer sebagai tulang punggungnya. Apa itu pengalaman kejar yang baik, mengapa titik percabangan harus di situ, mengapa jebakan harus meledak di titik 2/3 dan bukan di tengah koridor agar ketegangannya hidup — ini adalah penilaian orang yang langsung menyentuh game dan melihat reaksi pengguna. Jika AI disuruh menyusun pola dari awal, semua pola akan berkonvergensi ke bentuk yang aman dan rata-rata. Pustaka akan penuh dengan "pola yang tidak salah", tetapi "pola yang berkesan" menghilang.

Bukan berarti AI tidak punya peran. Dari lima tahap penulisan pola, di dua tempat AI menjadi pembantu yang andal.

Tahap 3 adalah inti bantuan AI. Ketika desainer menulis draf "musuh cepat mengejar dari belakang di koridor sempit", menyuruh manusia menyisir sendiri puluhan template room dan pustaka subtree yang sudah menumpuk untuk menemukan mana yang cocok dengan maksud itu sangatlah tidak efisien. Di sinilah AI disuruh merekomendasikan kandidat pemetaan. Berikut adalah prompt yang benar-benar dipakai, dalam bentuk yang telah dianonimkan.

[Masukan]
- draf yaml pola dari desainer (terlampir di bawah)
- pustaka template room (daftar nama + tag + ukuran)
- pustaka subtree (daftar nama + ringkasan perilaku)

Pilihkan dan rekomendasikan template room serta subtree dari pustaka untuk mewujudkan pola ini.
Masing-masing 2–3 buah, sertakan skor kecocokan 1–5 dan satu baris alasan berdasarkan tag·ukuran.
Jangan mengarang yang tidak ada di pustaka, hanya rekomendasikan; jika semuanya 3 ke bawah, nyatakan bahwa perlu penulisan baru.

Keluaran yang benar-benar dikembalikan Claude untuk prompt ini adalah sebagai berikut. Agar terlihat apa adanya di mana ia ragu dan di mana ia menegaskan, saya menyalinnya tanpa menyunting satu huruf pun.

Kandidat template room:
1. corridor_long  (kecocokan 5)
   Alasan: tag horizontal_corridor cocok, size medium sesuai maksud "koridor sempit".
2. corridor_narrow_short  (kecocokan 3)
   Alasan: memang sempit, tetapi panjangnya pendek sehingga sulit mengamankan jarak kejar. Ruang untuk menempatkan percabangan kurang.
3. hall_wide  (kecocokan 1)
   Alasan: aula lebar justru berlawanan dengan maksud "koridor sempit". Tekanan kejar tidak terasa.

Kandidat subtree:
1. subtree_aggressive_chase  (kecocokan 5)
   Alasan: perilaku kejar dari belakang terdefinisi, ada bobot kecepatan gerak.
2. subtree_ranged_support  (kecocokan 3)
   Alasan: bukan kejar itu sendiri, tetapi bisa ditempatkan 1 unit sebagai bantuan tekanan.
3. subtree_patrol_basic  (kecocokan 2)
   Alasan: perilaku patroli tidak sesuai dengan maksud kejar. Tidak ada node peralihan ke kejar setelah pemicu.

Template room titik percabangan (junction):
Saya tidak menemukan item di pustaka yang sekaligus memenuhi syarat percabangan 3way + ukuran small.
junction_3way paling mendekati, tetapi tag size-nya kosong sehingga
kecocokan tidak dapat dipastikan. Diperlukan konfirmasi desainer.

Paragraf terakhir adalah bagian paling berharga dari keluaran ini. AI berkata "tidak yakin" mengenai template room titik percabangan, dan tidak mengarang jawaban yang tidak ada. Setelah menerima laporan ini, desainer menemukan fakta bahwa tag size junction_3way memang kosong, lalu ia mengisi metadata itu terlebih dahulu. Seandainya AI mengabaikan tag kosong dan memberi kecocokan 5, desainer akan menerimanya begitu saja dengan kepercayaan yang keliru.

Inilah bentuk yang benar dari bantuan AI. AI membentangkan kandidat dan menandai ketidakpastian, sementara pilihan dan tanggung jawab tetap di tangan desainer. Bila hasil pemetaan menunjukkan kecocokan yang semuanya rendah, barulah muncul pekerjaan terpisah untuk menulis template baru, dan penulisan itu kembali menjadi pekerjaan manusia.

[Penanda Arah — Bila pola dipadatkan jadi 'vektor pengalaman' (masih terlalu dini)] Mohon dibaca bukan sebagai resep, melainkan sebagai tren riset. §7.3.1 sudah menyebut pola sebagai 'resep'. Satu pola mendekati nilai koordinat yang merupakan satu kesatuan dari meta room·subtree perilaku·event·difficulty/reward_modifier·clear_time. Bila kesatuan ini dipadatkan menjadi 'vektor pengalaman', maka ketika kecocokannya semuanya rendah, alih-alih menyisir alur penulisan baru di atas satu per satu, kita bisa menemukan area kosong di ruang padat itu, dan penilaian deprecated di §7.3.8 pun dapat diperkuat dengan jarak koordinat untuk duplikasi yang berdekatan. Namun ada tiga catatan yang menyertainya. Sebagaimana disebut di §7.3.4, difficulty/reward_modifier adalah nilai operasional penulis sehingga skala sumbunya berbeda di tiap game dan ruang padat itu tidak bisa dipindahkan apa adanya; interpolasi hanya sampai pada 'penanda' kotak kosong, bukan 'pembangkitan' pola; dan menyusun pola yang sebenarnya di atas penanda itu tetap tidak melampaui prinsip subbab ini, bahwa wawasan desainer adalah tulang punggungnya. Gagasan ini berada di tempat yang sama dengan pemadatan vektor dimensi di §8.2.7, dan intuisi konsepnya ada di Lampiran M — saya tinggalkan sebagai area yang akan ditengok tim dengan fondasi yang cukup beberapa tahun kemudian.

7.3.8 Memangkas Pola yang Tidak Dipakai

Pustaka lebih sulit dikosongkan daripada diisi. Setelah beroperasi sekitar satu tahun, menumpuk pola yang dibuat tetapi nyaris tidak terpakai. Bila dibiarkan, biaya pencarian di pustaka meningkat, dan desainer harus menyisir hingga ke pilihan-pilihan mati saat memilih pola. Karena itu, secara berkala dipangkas.

Intinya, pembuangan bukanlah penghapusan. Dungeon-dungeon yang sudah memakai pola itu dibiarkan apa adanya. Sebab menyentuh dungeon yang sedang berjalan di layanan live lebih berisiko daripada menghalangi pola baru. deprecated: true hanyalah penanda yang berarti "jangan dipakai lagi mulai sekarang", bukan perintah untuk menghapus masa lalu.

Sebagaimana kita mengeluarkan dan merapikan alat yang tak terpakai di laci meja satu kali setiap kuartal, pustaka pun dijadwalkan untuk dipangkas satu kali per kuartal. Tanpa jadwal ini, pustaka hanya membengkak ke satu arah, dan pada suatu titik menjadi gudang yang diabaikan desainer.

7.3.9 Mengukur Efek secara Jujur

Berikut adalah perubahan yang diamati selama satu tahun mengoperasikan pustaka pola di Proyek A milik penulis. Nilai waktu pada tabel di bawah adalah perkiraan penulis (belum terverifikasi); yang benar-benar teramati hanyalah arah dan rasio relatifnya.

Perubahan yang paling berkesan adalah baris kedua dari bawah, yaitu onboarding desainer baru. Pustaka pola tanpa sengaja berperan sebagai buku ajar desain. Karena desainer baru kini bisa membaca dan memahami "begini cara membuat pengalaman kejar di game ini" dari satu lembar berkas pola, waktu senior duduk di sebelahnya untuk menjelaskan berkurang drastis. Masalah dungeon yang berbeda-beda yang dibawa desainer baru pada awalnya, ternyata teratasi oleh pustaka itu sendiri.

Angka "rata-rata dungeon pemakai per 1 pola sekitar 8" berarti pola yang sama dipakai ulang delapan kali, dan inilah ukuran jujur efisiensi produksi massal. Hanya saja, nilai 8 ini bergantung pada skala dungeon dan rancangan pola game penulis. Pada game dengan jumlah dungeon sedikit atau yang menuntut konsep berbeda setiap kali, nilai ini akan jauh lebih kecil.

7.3.10 Keputusan untuk Tidak Membangun Pustaka

Terakhir, agar jujur, saya harus menyampaikan cerita yang membalik seluruh bab ini. Pustaka pola bukanlah obat segala penyakit. Jelas ada lingkungan di mana biaya membangun dan mengoperasikan pustaka tidak terbayar kembali.

ROI (Return on Investment, efek dibanding investasi) pustaka terbayar kembali ketika tiga kondisi terpenuhi bersama-sama: ada Live Ops, desainernya tiga orang atau lebih, dan jumlah dungeon melewati dua puluh. Di sinilah alasan mengapa MMORPG dengan Live Ops menjadi sasaran penerapan yang khas. Bila proyek Anda tersangkut di salah satu baris tabel di atas, berhentilah dan pikirkan ulang sebelum membangun pustaka. Alat hanya bernilai ketika ada masalah, dan bagi proyek berisi lima dungeon, pustaka pola lebih besar biayanya daripada masalahnya.

7.3.11 Kegagalan Umum dan Resepnya

Baris kedua dan baris keempat tabel ini yang paling sering menjegal. Jika pelacakan dampak tidak diotomatiskan, desainer takut mengubah pola sehingga pustaka mengeras; jika penulisan didelegasikan ke AI, pustaka berkonvergensi ke rata-rata. Kedua kegagalan ini sama-sama membunuh nyawa pustaka, yaitu "pakai ulang pengalaman yang terverifikasi".

7.3.12 Menutup Bagian 7

Bagian 7 menumpuk bidang level dalam tiga lapisan. Di 7.1 ditegakkan standar metadata room, tag, dan konektivitas (ruang); di 7.2 dibahas editor BehaviorTree berbasis JSON, subtree, dan simulasi (perilaku); dan di bab ini kita sampai pada pustaka pola yang mengikat keduanya bersama event untuk dipakai ulang (unit operasional). Dari pengelolaan yang menangani ruang dan perilaku secara terpisah, masalah di mana keputusan pada posisi yang sama goyah dalam bentuk berbeda setiap minggu, lalu diselesaikan dengan mengunci jadi aturan sebuah kesatuan bernama pola — itulah benang merah seluruh Bagian 7.

Alur ini terjalin tepat dengan desain integrasi Layer. Visi berupa tone ruang seluruh game berada di atas, di bawahnya ada sistem berupa aturan pembangkitan level dan aturan BT, room·BT·pustaka pola membentuk lapisan konten, instans dungeon dan statistik penggunaan pola menumpuk sebagai data, serta lint·simulasi·telemetri pengguna memverifikasinya pada tahap build·QA. Pustaka pola adalah tulang punggung lapisan konten di antara lima lapisan ini, sekaligus mata rantai yang ke atas mengikuti aturan sistem dan ke bawah menghasilkan statistik data.

Poin-Poin Penting

• Pola adalah unit operasional yang mengikat ruang·perilaku·event; bila ketiganya ditangani terpisah, pengalaman yang sama goyah berbeda setiap minggu
• 80% pakai ulang + 20% variasi adalah rasio yang dianjurkan; bila variasi melewati separuh, itu sinyal pola baru
• Penulisan pola adalah tempat wawasan desainer, dan AI hanya sampai pada rekomendasi kandidat pemetaan dan bantuan simulasi

Pratinjau Bab Berikutnya

• 8.1 Operasional CombatBalance · CombatFormula — pemisahan dua dokumen dalam desain balancing

Coba Sendiri — Mengunci Satu Pola Kejar jadi Aturan

setup

1. Buatlah dua direktori, patterns/ dan dungeons/, di folder kerja Anda.
2. Siapkan daftar nama template room dan daftar nama subtree, masing-masing dalam berkas berisi satu nama per baris. (Jika belum punya pustaka, Anda boleh mulai dengan 5 nama fiktif untuk masing-masing.)
3. Simpan pattern_impact.py dari isi di atas apa adanya.

prompt

Desainer menulis sendiri draf yaml pola (bagian ini adalah jatah manusia). Setelah itu, serahkan hanya pemetaan kepada AI. Pakai prompt pemetaan dari isi bab apa adanya, tetapi lampirkan draf Anda sendiri dan kedua daftar pustaka pada masukan. Jangan sampai melewatkan dua baris batasan inti.

- Jangan mengarang template baru yang tidak ada di pustaka. Hanya rekomendasikan.
- Jika skor kecocokan semuanya 3 ke bawah, nyatakan secara eksplisit bahwa perlu penulisan baru.

verify

1. Periksa baris per baris apakah AI tidak mengarang nama template yang tidak ada di pustaka.
2. Lihat apakah skor kecocokan disertai alasan berdasarkan tag·ukuran. Jangan percayai skor tanpa alasan.
3. Setelah menginstansiasi pola ke 2 dungeon atau lebih, jalankan find_dungeons_using("pattern_...") untuk memastikan kedua dungeon itu terjaring dengan tepat.

Versi Ringkas Solo

Jika Anda membuat game kecil sendirian, sistem pustaka itu berlebihan. Sebagai gantinya, cukup pilih satu segmen dungeon yang paling Anda sukai dan tuliskan pengalamannya dalam satu lembar yaml. Saat membuat dungeon berikutnya, buka satu lembar itu, salin, lalu ubah hanya 20%-nya. Esensi pustaka pola — pakai ulang pengalaman yang terverifikasi — bekerja bahkan dari satu lembar berkas. Bila skalanya membesar, barulah Anda menambahkan kategori dan alat pelacakan saat itu.

Bagian 8 · Balance Design

8.1 Formula Balans Tempur — Tempat Rulebook bernama Determinisme

Tujuan pembelajaran bab ini (tingkat kesulitan 🟡 praktis · prasyarat: aritmetika dasar·perhitungan tabel): Anda akan mampu memisahkan balans tempur menjadi tempat untuk formula dan tempat untuk angka, lalu—dengan berpijak pada dua sifat yaitu determinisme dan keterlacakan—membedakan sampai sejauh mana sesuatu boleh diserahkan kepada AI dan dari titik mana manusia harus menguncinya sebagai rulebook.

Pukul dua dini hari, muncul notifikasi bahwa tingkat bertahan hidup (survival rate) job tanker di server live menyentuh 89%. Tidak ada tanker yang gagal menghabisi bos sampai akhir, dan terlalu banyak tanker yang tidak mati. Untuk mencari jejak tangan seseorang yang pernah mengutak-atik ini, saya membuka sheet data. Tampak satu baris koefisien pertahanan. DEF / (DEF + 1000). Di mana pun pada sheet itu tidak tertulis kapan, oleh tangan siapa, dan atas dasar apa angka 1000 ini turun dari 1200 menjadi 1000. Mulailah pelacakan yang baru selesai setelah saya menyisir log chat, menyisir riwayat build, dan akhirnya harus sampai pada ingatan seorang balancer yang sudah resign tiga tahun lalu.

Adegan ini dialami siapa pun yang pernah mengoperasikan balans tempur, setidaknya sekali. Dan penyebab sebenarnya dari adegan ini bukanlah bahwa angka 1000 itu salah. Penyebabnya adalah bahwa angka itu hidup di tempat formula, sedangkan riwayat perubahan formula itu tidak ada di mana pun. Formula balans tempur adalah area yang paling harus deterministik di dalam game, dan area yang paling harus dapat dilacak. Mengapa kedua sifat inilah yang menjadi alasan AI tidak boleh dimasukkan ke tempat ini—itulah tulang punggung bab ini.

Satu baris untuk pembaca non-teknis. Tak masalah jika z-score, simulasi, dan kurva di bagian ini terasa asing. Satu hal yang perlu Anda bawa pulang adalah ini — "Aturan (formula) yang harus selalu menghasilkan keluaran sama untuk masukan sama tidak boleh diserahkan kepada AI." Penilaian yang memisahkan tempat yang membutuhkan determinisme dari tempat yang membutuhkan eksplorasi ini dapat dipindahkan apa adanya ke semua pekerjaan yang menangani 'aturan yang tidak boleh salah'—seperti regulasi akuntansi, logika penyelesaian (settlement), atau klausul kontrak. Rumus matematikanya sendiri boleh Anda baca pelan-pelan mulai dari 8.1.2.

8.1.1 Formula Adalah Rulebook

Setelah cukup lama menggeluti desain game, ada dua jenis dokumen yang terasa di tangan. Dokumen yang sering berubah, dan dokumen yang nyaris tak pernah berubah. Dalam balans tempur, sisi yang nyaris tak pernah berubah adalah formula. "Bagaimana damage dihitung" disentuh satu-dua kali per kuartal, sedangkan "berapa attack power karakter ini" disentuh lima-enam kali per pekan. Jika dua aliran dengan frekuensi berbeda ini diikat dalam satu berkas, lembar kertas yang jarang dibuka-tutup akan robek oleh tangan yang sering membuka-tutup.

Pada Proyek A yang saya kelola, balans tempur dipisahkan ke dua tempat. Tempat untuk formula (di sini saya menyebutnya CombatFormula) dan tempat untuk angka (CombatBalance). Saya kutip apa adanya satu baris yang hidup di tempat formula.

final_damage = base_damage × dmg_multiplier × (1 − defense_factor) × variation

  base_damage    = skill_base × ATK × skill_coeff
  defense_factor = DEF / (DEF + 1000)
  variation      = uniform(0.95, 1.05)

Formula ini adalah rulebook. Bayangkan saja buku aturan sebuah board game. Buku aturan menulis "bergerak sebanyak mata dadu yang muncul setelah dilempar", bukan "kalau ronde ini sedang beruntung, boleh maju sedikit lebih jauh". Masukan sama selalu menghasilkan keluaran sama. Inilah determinisme. Jika Anda memasukkan attack power 180, defense 80, skill coefficient 2.1, maka kapan pun, di mana pun, dan berapa kali pun dihitung, damage yang keluar harus sama. Andai masukan sama menghasilkan keluaran berbeda, itu bukan alat balans, melainkan mesin judi.

Satu sifat bernama determinisme inilah alasan pertama mengapa AI tidak boleh dimasukkan ke tempat ini. Akan saya bahas lagi sebentar lagi. Mari lebih dulu kita lihat bagaimana seharusnya sebuah formula berwujud agar layak disebut rulebook.

Area inti formula tempur tidak berhenti pada satu baris damage. Setidaknya tiga baris hidup sebagai satu kesatuan.

# Damage
final_damage = base_damage × dmg_multiplier × (1 − defense_factor) × variation

# Critical
crit_damage  = final_damage × crit_multiplier
crit_chance  = base_crit + (LUK × 0.1)            # batas atas 50%

# Pemulihan
heal         = base_heal × healing_power × (1 − sickness_factor)

Ada alasan mengapa ketiga baris ini ditulis sebagai blok kode, bukan sebagai bahasa alami. Bahasa alami menyisakan ruang interpretasi. Kalimat "semakin tinggi defense, semakin berkurang damage" tidak menyebutkan apakah pengurangannya linear, apakah berkurva, atau di mana berhenti. DEF / (DEF + 1000) hanya terbaca satu cara. Tugas rulebook adalah menjadikan ruang interpretasi nol.

8.1.2 Kurva Menentukan Determinisme

Seluruh filosofi balans game ini tertanam dalam satu baris koefisien pertahanan DEF / (DEF + 1000). Jika baris ini digambar sebagai grafik, akan terlihat mengapa demikian. Sumbu horizontal adalah defense, sumbu vertikal adalah rasio pengurangan damage yang diterima.

Kurva ini menempel perlahan pada asimtot (asymptote). Pada defense 1000 ia memangkas damage tepat menjadi setengah, dan setelah itu, sekeras apa pun dinaikkan, ia tak pernah menyentuh 100%. Bahwa kekebalan total mustahil—itu tertanam dalam satu baris ini. Andai kurva ini linear seperti garis putus-putus abu-abu, maka pada defense 1000 damage akan tertahan seluruhnya, dan di atasnya akan melewati ke area yang tidak masuk akal yaitu damage negatif (makin dipukul makin pulih HP-nya). Itulah sebabnya bentuk linear tidak diadopsi.

Mari kita kembali ke insiden pukul dua dini hari di sini. Misalkan seseorang menaikkan angka 1000 ini menjadi 1200. Seluruh kurva tergeser ke kanan. Karena dengan defense yang sama damage yang tertahan menjadi lebih sedikit, tanker di seluruh game melemah dan damage per jam dari dealer meningkat. Satu konstanta dalam formula mengguncang seluruh game. Skala dampaknya berbeda dengan mengubah satu angka (attack power suatu karakter). Perbedaan inilah alasan formula dan angka harus diletakkan di tempat berbeda, dan alasan perubahan formula wajib selalu disertai riwayat.

8.1.3 Perubahan Formula Selalu Disertai Riwayat

Alasan pelacakan pukul dua dini hari menjadi neraka hanya satu: karena tidak ada riwayat perubahan. Pada Proyek A, perubahan formula bukanlah pekerjaan memperbaiki satu baris kode, melainkan pekerjaan mencatat satu keputusan. Di samping formula selalu mengikuti sebuah dokumen terpisah bernama CombatFormula_Decisions, dan di sana ditulis seperti ini.

## Keputusan D17 (2026-04-22)
- Perubahan: defense_factor dari DEF/(DEF+1000) → DEF/(DEF+1500)
- Alasan: pada segmen level tinggi (LV40+), survival rate tanker 89% (pengukuran live). Penyebab pertarungan bos jadi berlarut-larut.
- Percobaan 1: simulasi dengan 800 → angka kematian tanker melonjak, banyak yang wipe dalam 1 menit setelah masuk bos → rollback
- Percobaan 2: simulasi dengan 1200 → survival rate 75% → cukup baik tapi lebih tinggi dari target (60~70%)
- Percobaan 3: 1500 diadopsi → survival rate simulasi 65% (dalam rentang target)
- atom terdampak: combat_defense_formula, combat_tank_class_balance
- Pengukuran pascaterap (1 pekan): survival rate live 67% (dibanding prediksi simulasi 65%, +2%, dalam rentang)

Satu catatan ini menjawab "mengapa jadi begini" enam bulan kemudian. Yang lebih penting adalah tertinggalnya percobaan 1 dan percobaan 2. Jika tercatat mengapa 800 tidak berhasil dan mengapa 1200 tidak diadopsi, orang berikutnya tidak akan mengulangi kesalahan yang sama. Saat seorang balancer baru bergabung, satu kesatuan log keputusan ini menjadi materi onboarding terbaik.

Ada satu hal yang perlu saya tunjukkan dengan jujur di sini. Angka simulasi percobaan 1·2·3 di atas (angka kematian, survival rate 75%, 65%) adalah perkiraan penulis (belum terverifikasi) yang dipakai untuk memperlihatkan alur operasional. Setiap game nyata punya kurva maupun rentang target yang berbeda. Namun struktur bahwa "perubahan disertai percobaan, percobaan disertai dasar simulasi, dan setelah adopsi disertai pengukuran pascaterap" adalah apa adanya dari operasional nyata. Dalam struktur ini, jika satu kolom saja kosong, kolom yang kosong itu akan kembali sebagai pelacakan pukul dua dini hari.

Jika tiga tempat—formula, angka, dan riwayat—dilihat sekaligus, bentuknya seperti ini.

8.1.4 Alur Nyata Saat Sebuah Formula Berubah

Sekarang mari kita telusuri dari awal bagaimana D17 diputuskan. Inilah cara sebuah rulebook deterministik bergerak dalam praktik.

flowchart TD
    A["Pengukuran live
Terdeteksi survival rate tanker 89%"] --> B["Hipotesis penyebab
Koefisien pertahanan 1000 overproteksi di akhir game"]
    B --> C["Definisi kandidat perubahan
1500 / 1200 / 800"]
    C --> D["Damage Simulator
Eksekusi deterministik 1,000 kali per kandidat"]
    D --> E["Laporan hasil
survival rate·rata-rata durasi tempur·win rate"]
    E --> F{"Penilaian balancer
Dalam rentang target 60~70%?"}
    F -->|"800: angka kematian melonjak"| G["Ditolak → log percobaan 1"]
    F -->|"1200: 75%, agak tinggi"| H["Ditahan → log percobaan 2"]
    F -->|"1500: 65%, dalam rentang"| I["Diadopsi → keputusan D17"]
    I --> J["Diterapkan ke build (tidak dapat dibalik)"]
    J --> K["Pengukuran pascaterap live 1 pekan kemudian
67%, +2% dibanding prediksi"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class D code;
    class B,C,F human;
    class A,E,K data;
    class I pass;
    class G fail;

Dalam alur ini Anda harus melihat dengan tepat peran simulator. Damage Simulator menjalankan ketiga kandidat masing-masing 1,000 kali. Di sini, 1,000 kali bukanlah mengulang masukan yang sama sebanyak 1,000 kali. Karena adanya bilangan acak ±5% bernama variation = uniform(0.95, 1.05) di dalam formula, ditambah bilangan acak lain yaitu peluang critical, maka hasil tiap pertandingan berbeda-beda. Dengan menjalankan 1,000 pertandingan, kita melihat distribusinya. Kita melihat rata-rata survival rate, kasus terburuk, dan sebaran durasi tempur.

Penting bahwa simulator itu sendiri harus deterministik. Jika diberi seed acak yang sama, 1,000 pertandingan harus dapat direproduksi tanpa meleset satu titik pun. Hanya dengan begitu, satu baris D17 yang menyebut "dengan 1500 keluar 65%" dapat direproduksi persis dan diverifikasi enam bulan kemudian. Jika simulator menghasilkan hasil berbeda tiap kali, log keputusan menjadi sebuah kebohongan.

Pertama kali saya membuat damage simulator ini adalah tahun 2008. Saat itu ia berupa makro Excel, dan kini di Proyek A ia dienkapsulasi sebagai skill balance-sim. Selama 18 tahun cangkang alatnya berubah, tetapi rulebook yang ada di dalamnya tak pernah sekali pun bersifat probabilistik. Inilah intinya.

8.1.5 Mengapa AI Mutlak Dilarang pada Kurva Reward dan Formula

Sekarang kita sampai pada hal yang paling ingin disampaikan bab ini. Di saat AI masuk ke hampir semua tempat dalam desain game, ada satu tempat yang mutlak tidak boleh dimasuki. Itulah inti determinisme bernama formula tempur dan kurva reward.

LLM pada hakikatnya bersifat probabilistik. Untuk pertanyaan yang sama, ia menjawab sedikit berbeda setiap kali. Itulah sumber kekuatannya menghasilkan tulisan dan ide yang baik, tetapi fatal bagi tempat rulebook. Jika "berapa damage yang diterima karakter dengan defense 80?" dibuat dijawab oleh LLM, hari ini ia bisa menjawab 92, besok 94. Sama saja seperti buku aturan board game yang maknanya berubah setiap kali halaman dibalik.

Kurva reward lebih berbahaya lagi. "Experience yang dibutuhkan saat naik dari level 30 ke 31" sekali ditetapkan langsung mengatur kecepatan progres ratusan ribu orang secara serempak. Cukup masuk gelombang ±2% saja di sini, sebagian pengguna akan naik lebih lambat dari orang di sebelahnya meskipun berburu hal yang sama. Keadilan runtuh. Determinisme adalah sinonim dari keadilan. Itulah sebabnya kurva reward ditetapkan manusia dengan tangan, dimasukkan ke sheet, dan tak pernah lagi diserahkan kepada peluang.

Bukan berarti AI harus diusir dari seluruh area balans. Batasnya yang menjadi inti.

Garisnya jelas. AI hanya hidup di luar inti determinisme. Sisi dalam yang menghitung dan menyimulasi adalah rulebook, sedangkan sisi luar yang menganalisis, mengusulkan, dan menuangkannya ke tulisan adalah tempat AI. Sekali garis ini dilewati, masukan sama mulai menghasilkan hasil berbeda, dan sejak saat itu alat balans kehilangan kepercayaan.

Batas ini berstruktur sama persis dengan sistem ekonomi yang akan kita lihat di 8.2. Pada ekonomi pun, formula produksi·konsumsi sumber daya adalah determinisme, dan deteksi pola inflasi adalah tempat AI. Seluruh bidang balans bergerak dengan kerangka yang sama.

8.1.6 Selangkah Lebih Jauh — Penerapan Progresif Mengajukan Kandidat lewat z-score

Sampai sekarang ini adalah penerapan konservatif di mana manusia membuat kandidat dan simulasi memverifikasinya. Jika melangkah satu langkah lebih jauh, pekerjaan membuat kandidat pun dapat digantikan oleh alat. Hanya saja, rulebook tetap milik manusia dan determinisme.

Titik berangkatnya adalah deteksi pola anomali. Dari hasil simulasi 1,000 pertandingan, kita lihat distribusi win rate·survival rate per karakter, lalu mengukur dengan z-score seberapa banyak ia menyimpang dari rata-rata sebesar berapa kali standar deviasi. Karakter dengan z melampaui 2 ditandai otomatis sebagai "di luar rentang normal". Tanker pukul dua dini hari pun pasti tertangkap oleh deteksi ini.

Agar deteksi berlanjut menjadi pengajuan kandidat, dibutuhkan dua hal lagi. Pertama adalah definisi ruang perubahan. Sediakan kolom seperti tunable_range pada sheet CombatBalance untuk menyatakan "angka ini boleh diutak-atik dalam rentang mana". Kedua adalah paralelisasi simulasi. Untuk menjalankan 10 kandidat × 1,000 pertandingan = 10,000 pertandingan dalam waktu gerbang build, dibutuhkan infrastruktur paralel.

Jika ketiga hal ini (deteksi z-score · definisi ruang perubahan · paralelisasi simulasi) terpenuhi, keputusan yang tersisa di tangan balancer menyempit menjadi satu hal saja: "kandidat mana yang akan diadopsi". Membuat kandidat dari nol dan memilih satu dari lima punya beban yang berbeda. Di sini pun, yang disentuh AI hanyalah pengajuan kandidat dan interpretasi laporan; operasi di sisi dalam simulasi dan keputusan adopsi adalah tempat determinisme dan manusia.

Terakhir mari kita tunjuk reversibilitas. Baik mengubah sheet maupun menjalankan simulasi sama-sama dapat dibalik sehingga bisa diurungkan sepuasnya. Satu-satunya tempat yang tidak dapat dibalik adalah penerapan ke build. Angka yang sudah keluar ke live, begitu dilihat pengguna, tertinggal sebagai reaksi komunitas, sehingga jejaknya tidak terhapus meski di-rollback. Itulah sebabnya semua tinjauan diselesaikan tepat sebelum penerapan ke build, pada tahap yang masih dapat dibalik.

Coba Sendiri — Menangani Satu Perubahan Formula dengan Aman

setup. Buatlah dokumen CombatFormula yang memisahkan formula tempur dari penjelasan bahasa alami dan menuliskannya hanya sebagai blok kode, serta di sampingnya dokumen log CombatFormula_Decisions yang kosong. Angka dipisahkan ke sheet terpisah (CombatBalance).

prompt. Gunakan AI hanya untuk analisis·draf, bukan untuk perubahan formula. Misalnya, berikan CSV hasil simulasi lalu minta seperti ini.

Dari hasil simulasi 1,000 kali yang terlampir, hitung z-score win rate per karakter,
dan rangkum karakter dengan z>2 dalam bentuk tabel. Untuk tiap karakter,
perkirakan angka mana (attack power/defense/skill coefficient) yang paling mungkin
menjadi penyebab anomali, beserta dasarnya. Jangan memperbaiki angkanya sendiri —
cukup ajukan kandidat saja.

verify. Jangan percaya begitu saja kandidat yang dikeluarkan AI. Masukkan angka kandidat langsung ke sheet CombatBalance, lalu dengan Damage Simulator (atau balance-sim) berikan seed yang sama dan jalankan ulang 1,000 kali. Pastikan dua hal. (1) Apakah hasil simulasi masuk ke rentang target. (2) Apakah dengan menjalankan sekali lagi dengan seed yang sama, ia tereproduksi tanpa meleset satu titik pun. Jika keduanya lolos, adopsi, dan segera setelah diadopsi tuliskan alasan·percobaan (termasuk kandidat yang ditolak)·nilai prediksi ke _Decisions. Satu pekan setelah penerapan ke build, lampirkan nilai pengukuran live ke log itu.

Versi Ringkas Solo

Bahkan bagi pengembang solo yang tak punya tim maupun simulator, kerangkanya bekerja persis sama. Catat formula sebagai blok kode di komentar kode atau pada satu lembar .md terpisah, lalu di paling bawah berkas itu letakkan ## Riwayat Perubahan. Setiap kali Anda mengubah satu saja konstanta formula, tulis satu baris berisi tanggal·alasan·nilai sebelum diubah. Simulator cukup berupa loop Python 30 baris. Dengan mengunci seed acak, memasukkan angka karakter ke formula, menjalankan 1,000 kali, dan sekadar mencetak rata-rata win rate saja, Anda sudah beranjak dari "diubah berdasarkan firasat" menjadi "diubah berdasarkan dasar". Gunakan AI hanya untuk membaca CSV keluaran itu dan meringkas "karakter mana yang janggal". Hanya pekerjaan menyuruh LLM menghitung satu baris formula sajalah yang, terlepas dari skalanya, jangan Anda lakukan.

Poin-Poin Penting

• Formula tempur adalah rulebook yang menghasilkan keluaran sama untuk masukan sama, dan begitu determinisme itu runtuh, alat balans berubah menjadi mesin judi.
• Perubahan formula wajib selalu disertai riwayat keputusan yang memuat alasan·percobaan·pengukuran pascaterap, agar dapat menjawab "mengapa jadi begini" enam bulan kemudian.
• AI hanya hidup di luar inti determinisme (deteksi anomali·pengajuan kandidat·laporan), dan tak pernah masuk ke perhitungan formula maupun kurva reward.

8.2 Memodelkan Ekonomi dengan Machinations — Menangkap Inflasi lewat Simulasi, Bukan Rapat

Pembaca utama: System Designer / balance designer yang bertanggung jawab atas ekonomi live di MMORPG (tim skala menengah, 10\~50 orang) Versi ringkas untuk pembaca solo/hobi: §8.2.10 "Versi Ringkas Solo"

Yang pertama kali memberi tahu saya bahwa gold mulai bocor bukanlah tagihan, melainkan pasar lelang (Auction House). Pada bulan kedua setelah rilis, harga batu penguat (enhancement stone) diam-diam naik, dan sebulan kemudian sudah berlipat dua. Saya menjadwalkan rapat untuk mencari penyebabnya, tetapi yang keluar dari ruang rapat semuanya hanyalah "perasaan". Ada yang bilang imbalan dungeon baru terlalu besar, ada yang bilang itu karena efisiensi lokasi berburu meningkat, ada yang bilang sekadar karena jumlah pemain level tinggi bertambah. Semuanya terdengar masuk akal, dan justru karena itu tidak ada satu pun keputusan yang diambil. Kami menghabiskan satu jam membakar dugaan, lalu berakhir dengan "ya sudah, minggu depan kita lihat datanya lagi".

Masalahnya terletak pada kenyataan bahwa sumber daya bukan hanya satu jenis. Gold, batu penguat, reputasi, kehormatan, dan batu jiwa masing-masing punya source (jalan masuk) dan sink (jalan keluar), dan jalan-jalan itu saling memberi makan. Bos yang menjatuhkan batu penguat juga menjatuhkan gold. Perlengkapan yang dibeli dengan gold membakar batu penguat. Ketika 5 jenis sumber daya terjalin dalam puluhan aliran, kalkulator di kepala bahkan tidak bisa menghitung saldo satu minggu dari satu sumber daya saja secara jujur. Bab ini membahas cara memindahkan jalinan itu ke dalam model node Machinations, lalu meloloskan keputusan perubahan ekonomi bukan lewat tebakan rapat, melainkan lewat gerbang simulasi. Teori umum desain ekonomi sudah cukup dibahas di buku lain, jadi bab ini hanya berfokus pada tempat di mana teori itu dijalankan dengan alur kerja AI.

Catatan Operasional Nyata dari Penulis Kasus dalam bab ini adalah versi yang dianonimkan dari dokumen pilot ekonomi (Economy_Machinations_Pilot) yang penulis operasikan di folder R&D perusahaan, beserta ruang kerja riset ekonominya. Jenis sumber daya, struktur source/sink, dan 4 tahap Pilot dipindahkan dengan setia dari operasi nyata, sementara nama internal perusahaan dan angka aktual diganti untuk keperluan buku atau ditulis hanya sebagai rasio atau arah. Isi keluaran AI adalah rekonstruksi dari sesi nyata.

8.2.1 Ekonomi Bukan '5 Jenis Sumber Daya', Melainkan 'Puluhan Aliran'

Jika ditulis dalam tabel, sumber daya ekonomi hanya lima baris sehingga terlihat sederhana. Jebakannya bukan pada sumber dayanya, melainkan pada jumlah aliran yang menghubungkan sumber daya itu.

Sumber dayanya 5 jenis, tetapi source dan sink jika digabung berjumlah dua puluh sekian, dan lebih dari itu, antar sumber daya saling dikonversi (pasar lelang yang membeli batu penguat dengan gold adalah sink gold sekaligus source batu penguat). Begitu aliran saling memberi makan, pertanyaan seperti "kalau gold dilepas 5% lebih banyak, harga batu penguat akan jadi bagaimana" tidak bisa terjawab hanya dengan melihat satu sumber daya saja. Inilah titik yang membedakan balance karakter (8.1) dengan balance ekonomi secara menentukan. Balance karakter ditutup dengan satu baris rumus, tetapi ekonomi adalah sistem dinamis yang terakumulasi seiring waktu, sehingga meskipun saldo satu minggu mendekati 0, jika diakumulasi selama 26 minggu, pasar lelang bisa runtuh.

Maka esensi pekerjaan ekonomi bukan "memilih angka dengan baik", melainkan "melihat lewat simulasi bagaimana aliran terakumulasi seiring waktu". Dan pekerjaan menyusun serta merevisi model simulasi itu dengan tangan terasa membosankan, dan setiap kali dikerjakan selalu ada yang terlewat. Pekerjaan draf yang berulang dan mudah terlewat, tetapi peninjauannya harus dipegang erat oleh manusia — pekerjaan dengan tekstur seperti inilah tempat di mana garis pembagian kerja antara AI dan manusia tergambar paling rapi.

Pertama, saya muat di sini kerangka siklus ekonomi yang dibahas bab ini dalam satu gambar.

%%{init: {"flowchart": {"defaultRenderer": "elk"}}}%%
flowchart LR
    subgraph SRC["source (produksi sumber daya)"]
        H["Lokasi Berburu"]
        Q["Quest"]
        B["Bos Dungeon"]
        PVP["PvP/Perang Guild"]
    end
    subgraph POOL["pool (penyimpanan sumber daya)"]
        G(("Gold"))
        S(("Batu Penguat"))
    end
    subgraph SINK["sink (konsumsi sumber daya)"]
        UP["Penguatan Perlengkapan"]
        RP["Perbaikan/Pajak"]
        SH["Toko Faksi/Guild"]
    end
    H --> G
    Q --> G
    B --> S
    PVP --> SH
    G -->|konversi pasar lelang| S
    G --> UP
    S --> UP
    G --> RP
    UP -.->|permintaan batu penguat ↑| S
    G -.->|"jika aliran masuk bersih > aliran keluar bersih
inflasi terakumulasi"| POOL

    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class G,S data;

Garis putus-putus itulah inti bab ini. Sink penguatan menarik naik permintaan batu penguat sehingga mendorong harganya (UP -.-> S), dan ketika aliran masuk bersih gold melampaui aliran keluar bersih, kelebihan itu menumpuk di pool setiap minggu dan terakumulasi sebagai inflasi. Karena melacak dua garis putus-putus ini dengan hitungan tangan mustahil, dibutuhkan model.

8.2.2 Machinations — Alat untuk Memindahkan Ekonomi ke Graf Node

Machinations adalah alat untuk menggambar aliran ekonomi sebagai graf node dan menjalankan simulasi di atasnya. Inilah tempat memindahkan mermaid dari §8.2.1 menjadi model yang benar-benar bisa dijalankan.

Jika memodelkan ekonomi dengan node-node ini lalu menjalankan simulasi 1,000 kali, yang keluar bukan hasil tunggal, melainkan sebuah distribusi. Bentuknya seperti "setelah 26 minggu, median harga gold +X%, untuk pemain 10% teratas +Y%". Namun Machinations bukanlah alat serbaguna, dan pengadopsiannya sendiri adalah sebuah biaya.

Maka Machinations bukan alat yang diadopsi tanpa syarat. Ia sepadan dengan biayanya ketika tiga kondisi bertumpuk: 5 jenis sumber daya atau lebih + aliran konversi sumber daya + Live Ops (operasional game). Ekonomi sederhana dengan 2\~3 jenis sumber daya cukup ditangani Excel, dan dalam kasus itu, mengadopsi Machinations membuat beban operasional tiba lebih dulu daripada manfaatnya.

8.2.3 [Worked Transcript] Membuat Draf Model Sumber Daya Tunggal Gold dengan AI

Dengan penjelasan alat saja, kita tidak tahu apa yang sebenarnya dikeluarkannya. Saya akan mengikuti satu siklus pemindahan satu gold menjadi model Machinations sampai tuntas, dari prompt masukan hingga penolakan oleh manusia. Prompt masukan bisa langsung disalin dan dipakai, dan keluarannya adalah rekonstruksi dari sesi nyata.

Langkah 1 — Masukan: Aliran Gold dalam Tabel yang Bisa Dibaca Mesin

Pertama, ekstrak source dan sink gold dari sheet data lalu jadikan tabel. Ini bukan menulis baru, melainkan mengekstrak.

# gold_flows.yaml — aliran sumber daya tunggal gold (kutipan dari sheet data saat ini)
resource: gold
sources:
  - id: hunting        # drop di lokasi berburu
    trigger: per_kill
    note: kurva drop per rentang level mengikuti aturan reward_curve
  - id: quest_reward   # imbalan quest
    trigger: per_complete
  - id: market_sell    # penjualan di pasar lelang
    trigger: per_trade
sinks:
  - id: gear_buy       # beli perlengkapan
  - id: enhance        # biaya penguatan
  - id: repair         # perbaikan
  - id: tax            # pajak pasar lelang (sink sekaligus inti penarikan kembali gold)
# distribusi perilaku pemain (jumlah berburu per jam, tingkat penyelesaian quest) masih kosong → buat agar AI menandai jika berasumsi

Langkah 2 — Prompt: Suruh Membuat Model, tetapi Paksa Asumsi dan Format

gold_flows.yaml terlampir berisi 3 source dan 4 sink dari sumber daya tunggal gold.
Buatlah draf spesifikasi node untuk memindahkan ini ke model Machinations.

Aturan:
1) Klasifikasikan tiap aliran berdasarkan jenis node (Source/Drain/Pool/Converter).
2) Usulkan rumus 'laju aliran ekspektasi per 1 pemain dengan basis 1 minggu' untuk
   tiap node, tetapi jika diperlukan asumsi perilaku pemain (jumlah berburu per jam,
   tingkat penyelesaian quest, dll.), nyatakan asumsi itu pada baris terpisah sebagai
   '★asumsi'. Jangan sembunyikan asumsi di dalam isi.
3) Pisahkan total aliran masuk source dan total aliran keluar sink, lalu hitung saldo
   bersih (net) 1 minggu.
4) Cerminkan bahwa pajak pasar lelang (tax) adalah satu-satunya sink yang menghapus gold
   secara permanen dari ekonomi, dan bedakan bahwa sink lain (penguatan, perbaikan) hanya
   memindahkan gold ke NPC, bukan penarikan kembali.
5) Asumsi yang 'tidak kamu yakini' tandai secara terpisah dengan ★ dan serahkan pada
   keputusan manusia.

Format keluaran: tabel (node | jenis | rumus laju 1 minggu | asumsi | tingkat keyakinan).
Dilarang menambah penjelasan lain.

Dalam prompt ini, yang justru ditulis panjang bukanlah instruksi untuk membuat model, melainkan aturan tentang di mana dan bagaimana asumsi harus ditulis. Dalam pemodelan ekonomi, jika AI dibiarkan bebas, ia akan memuntahkan angka yang terdengar masuk akal sambil menyembunyikan asumsinya. Akibatnya, meski modelnya salah, kita tidak bisa menunjuk di mana letak salahnya. Menarik asumsi perilaku pemain keluar dari isi dan mendudukkannya pada baris terpisah — di situlah seluruh bobot permintaan ini bertumpu. Asumsi harus terlihat agar bisa diverifikasi.

Langkah 3 — Keluaran Claude (rekonstruksi, kutipan)

| node          | jenis     | rumus laju 1 minggu                                      | asumsi                       | keyakinan |
|---------------|-----------|---------------------------------------------------------|------------------------------|-----------|
| hunting       | Source    | bunuh/jam × drop rata-rata × jam main mingguan           | ★15h/minggu, 80 bunuh/jam    | sedang    |
| quest_reward  | Source    | jumlah quest harian × imbalan × 7 × tingkat penyelesaian | ★tingkat penyelesaian 0.7    | sedang    |
| market_sell   | Source    | (perpindahan antarpemain — bukan kenaikan bersih)        | kontribusi 0 ke ekonomi bersih | tinggi  |
| gear_buy      | Drain     | frekuensi beli × harga rata-rata                         | ★1.2 kali/minggu             | rendah    |
| enhance       | Drain     | percobaan penguatan × biaya per kali                     | ★8 kali/minggu               | sedang    |
| repair        | Drain     | waktu berburu × tingkat perbaikan                        |                              | tinggi    |
| tax           | Drain     | nilai transaksi × tarif (★satu-satunya sink penarikan permanen) | ★tarif 5%             | tinggi    |
| ── net        | net       | Σsource − Σsink ≈ +(positif dengan basis aktivitas menengah) | jika asumsi di atas dijumlah | ★rendah |

★Peringatan asumsi: market_sell adalah perpindahan gold antarpemain (pemain↔pemain) sehingga
berkontribusi 0 pada total ekonomi. Menambahkannya sebagai source akan menghitung inflasi
secara ganda. Perlu penanganan terpisah dalam model.
★Hal yang tidak diyakini: frekuensi gear_buy (1.2 kali/minggu) adalah tebakan. Tanpa telemetry
pembelian nyata, sink bisa diestimasi terlalu rendah/tinggi → perlu keputusan manusia.

Yang paling berharga dari keluaran ini bukanlah tabelnya, melainkan dua baris paling bawah, "★Peringatan asumsi" dan "★Hal yang tidak diyakini". AI melaporkan sendiri kelemahan modelnya di dua tempat. Prompt yang baik membuat AI mengatakan "asumsi ini tidak bisa saya percaya".

Langkah 4 — Verifikasi dan Penolakan (Tempat Manusia)

Keluaran ini tidak boleh langsung dimasukkan ke model. Salah satu dari dua ★ yang dilaporkan AI ternyata cacat yang benar-benar merusak model.

market_sell (penjualan di pasar lelang) awalnya diklasifikasikan AI sebagai Source. Padahal penjualan di pasar lelang adalah perpindahan gold pemain A ke pemain B, bukan gold yang baru tercipta di dalam ekonomi. Menambahkan ini ke aliran masuk source akan menghitung inflasi secara ganda. AI memang menandainya sendiri lewat ★Peringatan asumsi, tetapi di isi tabel ia tetap membiarkannya di kolom Source — sebuah keluaran yang hanya separuh benar: dilaporkan, tetapi tidak dikeluarkan dari model. Ini juga sekaligus cacat data dari pihak manusia, karena di yaml masukan sifat market_sell (perpindahan antarpemain vs penciptaan baru) tidak dinyatakan.

Maka saya meminta ulang.

market_sell adalah perpindahan gold antarpemain (pemain↔pemain) sehingga bukan source bagi
total ekonomi (perbaikan kelalaian masukan). Keluarkan node ini dari penjumlahan source, dan
sebagai gantinya cerminkan dalam model hanya sebagai 'pajak pasar lelang (tax) yang menarik
kembali sebagian dari nilai perpindahan secara permanen sebagai sink'. Hitung ulang saldo
bersih, dan tunjukkan dalam satu baris dampak pengeluaran market_sell terhadap net.

AI menjawab ulang dengan model yang mengeluarkan market_sell dari source dan menyisakan hanya pajak sebagai sink. Hasilnya, saldo bersih (net) menjadi lebih rendah dari estimasi awal — terungkap bahwa ketika penjualan di pasar lelang salah dimasukkan sebagai source, kita sedang menaksir inflasi secara berlebihan. Satu kali putaran bolak-balik inilah intinya. Jika manusia menyusunnya sendiri dengan tangan dari awal, butuh setengah hari dan sulit menangkap sendiri kesalahan klasifikasi node, tetapi dengan draf AI + paksaan "nyatakan asumsi" + satu kali penolakan, prosesnya selesai dalam waktu kurang dari satu jam, dan berkat struktur di mana manusia memutuskan ★ yang dilaporkan AI, cacat seperti penghitungan ganda tertangkap sebelum masuk ke model (perkiraan penulis — waktu yang dihemat berbeda-beda menurut tim dan jumlah sumber daya, jadi lebih tepat dibaca sebagai perbedaan struktur antara "dari awal dengan tangan" dan "draf + tinjauan" ketimbang sebagai nilai absolut).

8.2.4 Satu Sumber Daya pada Satu Waktu — Diperkenalkan lewat 4 Tahap Pilot

Selesainya satu model gold tidak berarti kita boleh memodelkan seluruh sumber daya sekaligus. Operasi penulis pun tidak memasukkan keseluruhan sekaligus. Saya menempuh 4 tahap yang dimulai dari sumber daya tunggal, melewati verifikasi dan koreksi, lalu memperluas.

Verifikasi perbandingan di tahap 2 adalah jantung dari 4 tahap ini. Jika simulasi dan kenyataan melenceng, yang salah bukan game-nya, melainkan model-nya. Membuat keputusan dengan model yang melenceng akan mengembalikan keputusan itu sebagai insiden di live. Maka perluasan (tahap 4) selalu dilakukan hanya setelah lolos verifikasi tahap 2 dan 3. Jika urutan ini rusak, yakni melewati verifikasi sumber daya tunggal dan memasukkan 5 jenis sekaligus, kita bahkan tidak bisa memisahkan dan menunjuk model sumber daya mana yang salah.

8.2.5 Gerbang Simulasi — Memasang Penghalang pada Keputusan Perubahan Ekonomi

Begitu model lolos verifikasi, kini di depan setiap keputusan perubahan yang berdampak pada ekonomi kita pasang gerbang simulasi. Inilah tempat mengubah keputusan yang dulu diloloskan lewat "perasaan" di rapat menjadi keputusan yang lolos lewat simulasi.

Untuk melihat bagaimana gerbang ini benar-benar bekerja, saya akan meloloskan satu keputusan di atas model gold yang sudah diverifikasi di §8.2.3.

[Gerbang Simulasi — Keputusan Imbalan Event] (rekonstruksi format nyata)

[Usulan Perubahan]   Event akhir pekan: imbalan login harian +500 gold
[Gerbang]            penambahan source baru → simulasi wajib
[Hasil Simulasi 1000 kali]
  - Saldo bersih gold 1 minggu: +6,900 → +10,400 (+50%)
  - Setelah akumulasi 26 minggu, median harga gold ~+28% (peringatan inflasi: melampaui ±10%)
  - Pemain aktif 10% teratas: ~+41% (deviasi segmen besar)
[Putusan]            FAIL — melampaui rentang stabil (±10%/jangka panjang)
[Usulan Koreksi]     Pasangkan sink bersamaan pada source event: toko khusus event (penarikan kembali gold)
                     simulasi ulang → akumulasi 26 minggu +9% (PASS)

Nilai gerbang ini ada pada dua baris terakhir. Seandainya keputusan "ayo kita lepas imbalan +500" adalah tebakan rapat, keputusan itu akan lolos dengan "sepertinya tidak apa-apa". Gerbang simulasi mengonversi keputusan itu menjadi inflasi +28% pada 26 minggu lalu menunjukkannya, dan bahkan memaksa koreksi berupa kalau mau menambah source, pasang sink bersamanya. Memutuskan perubahan ekonomi bukan lewat tebakan, melainkan lewat lolos/gagal simulasi — inilah keseluruhan dari gerbang ini.

Di sini saya tunjuk satu jebakan yang sering terjadi. Deviasi segmen. Meskipun +28% dengan basis pemain aktivitas menengah, untuk 10% teratas angkanya +41%. Karena lapisan pemain yang paling banyak menghasilkan gold-lah yang paling cepat mengakumulasi inflasi, simulasi tidak boleh hanya melihat rata-rata, melainkan harus dijalankan per segmen. Jika hanya melihat rata-rata, kita melewatkan keruntuhan harga yang dipicu pemain aktivitas tinggi.

8.2.6 Model Berevolusi Setiap Bulan lewat Telemetry Setelah Rilis

Agar gerbang simulasi dipercaya, model tidak boleh melenceng dari game yang sebenarnya. Karena game berubah setiap minggu, model pun harus dikoreksi mengikutinya. Setelah rilis, model diperiksa dengan telemetry nyata setiap bulan (pada periode dengan sedikit perubahan, setiap kuartal).

Siklus koreksi model (bulanan)
─────────────────────────────────
1. Ekstrak telemetry pemain nyata sebanyak 1 bulan (agregasi aliran per sumber daya)
2. Hitung laju aliran source·sink terukur per segmen (aktivitas rendah/menengah/tinggi)
3. Bandingkan dengan simulasi Machinations per item
4. Item dengan galat >15% = sesuaikan parameter model (★asumsi item itu ternyata salah)
5. Setelah penyesuaian, simulasi ulang → gunakan sebagai model acuan gerbang bulan berikutnya

Intinya nomor 4. Item dengan galat besar adalah sinyal bahwa "asumsi yang tidak diyakini" yang dilaporkan AI dengan ★ di §8.2.3 ternyata melenceng dari kenyataan. Misalnya, jika frekuensi gear_buy yang ditebak AI (1.2 kali/minggu) ternyata terukur 2 kali/minggu, asumsi itu diganti dengan nilai telemetry. Jika koreksi ini dihentikan, model perlahan menjauh dari game, dan suatu kuartal gerbang simulasi akan menyebabkan insiden "diloloskan, tetapi nyatanya inflasi datang". Pada saat itu, kepercayaan terhadap simulasi itu sendiri runtuh belakangan. Koreksi bukanlah pekerjaan sampingan operasional, melainkan siklus reguler yang membuat gerbang tetap hidup.

8.2.7 Penerapan Progresif — Deteksi Pola Anomali·Ruang Perubahan·Paralelisasi Simulasi

Sampai di sini adalah 'penerapan konservatif' dari pemodelan ekonomi. Manusia mengusulkan perubahan, memverifikasinya dengan model, dan memutuskan berdasarkan hasil. Jika maju satu langkah, tiga sumbu penerapan progresif yang kita lihat di 8.1.6 — deteksi z-score · pendefinisian ruang perubahan · paralelisasi simulasi — terbuka secara sama persis di atas infrastruktur ekonomi ini juga.

Pertama, deteksi pola anomali. Alih-alih manusia melakukan perbandingan galat dari siklus koreksi bulanan (§8.2.6) dengan mata, kode lebih dulu memilih dan mengangkat item yang deviasi model-terukurnya melampaui ambang. Kita tahu harga batu penguat berlipat dua bukan dengan melihat pasar lelang, melainkan sebuah alert "laju aliran source batu penguat menyimpang +30% dari model" tiba sebelum rapat.

Kedua, pendefinisian ruang perubahan. Bukan dikotomi "lepas/jangan lepas imbalan +500", melainkan jika kita mendefinisikan rentang imbalan (0\~+1000) dan rentang sink bersamaan sebagai ruang perubahan, kita bisa menjelajahi kombinasi yang memenuhi inflasi ±10% di dalam ruang itu. Manusia menentukan "dari mana sampai mana", dan penjelajahan kombinasi optimal di dalamnya diotomatiskan.

Ketiga, paralelisasi simulasi. Alih-alih menjalankan satu usulan perubahan 1,000 kali, jalankan puluhan kandidat di dalam ruang perubahan secara paralel masing-masing 1,000 kali, lalu bandingkan distribusinya sekaligus. Tempat yang dulu memperdebatkan satu usulan demi satu di ruang rapat berubah menjadi perbandingan hasil simulasi dari matriks kandidat.

Gagasan bersamanya adalah memindahkan tempat di mana manusia dulu mengusulkan perubahan menjadi tempat di mana kode menjelajahi ruang perubahan. Namun, ini adalah cerita setelah penerapan konservatif (§8.2.3\~8.2.6) berjalan stabil dan model terverifikasi dengan telemetry. Jika menjelajahi ruang perubahan secara otomatis dengan model yang belum diverifikasi, model yang salah akan menyodorkan nilai optimal yang salah dengan penuh percaya diri.

[Penerapan Radikal — Mengompresi Ekonomi Menjadi 'Vektor Dimensi' untuk Dijelajahi] (masih terlalu dini)

Ini adalah wilayah yang melangkah satu kaki lebih jauh dari penerapan progresif. Mohon dibaca sebagai tren riset, bukan sebagai pernyataan pasti (jika vektor dimensi·embedding baru pertama kali Anda dengar, akan lebih mudah membaca bagian di bawah ini setelah melihat lebih dulu satu 'peta' di Lampiran M — kelima 'rambu arah' buku ini semuanya berputar di atas gambar itu). Model ekonomi yang sudah sampai di sini adalah sistem berkompleksitas tinggi dengan 5 jenis sumber daya yang terjalin dalam puluhan aliran, dan penjelajahan ruang perubahan di §8.2.7 pun pada akhirnya adalah cara menangkap puluhan aliran itu satu per satu sebagai parameter lalu menjalankannya. Gagasan radikalnya adalah mengompresi kompleksitas itu sendiri menjadi vektor dimensi, lalu mencari solusi di atas ruang terkompresi itu.

Satu analogi yang tampak jauh menjadi petunjuk. Resep masakan, yang lazim dianggap wilayah kualitatif dan sulit dipegang, dalam sebuah riset (Epicure — Radzikowski·Chen, 2026, arXiv:2605.22391 · demo epicure.kaikaku.ai) disaring dari 4,14 juta resep dari 11 sumber menjadi 1,790 jenis bahan standar, lalu hubungan antarbahan dikompresi menjadi vektor ratusan dimensi. Intinya, objek kualitatif bernama "rasa" pun, jika hubungan antarbahan dikonversi menjadi koordinat, membuat resep yang serupa berkumpul berdekatan di ruang vektor, dan di antaranya bisa diinterpolasi untuk menjelajahi kombinasi baru — Epicure pun menunjukkan penjelajahan interpolasi yang memutar satu bahan ke arah suatu wilayah masakan tertentu di ruang terkompresi ini untuk mencari bahan padanannya.

Prinsip ekonomi pun sama. Jika kita merepresentasikan keadaan ekonomi sebagai vektor yang menempatkan source·sink·aliran konversi masing-masing sebagai satu dimensi, maka "ekonomi yang stabil dalam inflasi ±10%" tertangkap sebagai satu wilayah di ruang itu. Lalu, alih-alih meloloskan usulan perubahan ke simulasi satu per satu, terbuka jalan untuk menjelajahi solusi secara langsung di dalam/dekat wilayah stabil itu. Inilah kemungkinan bahwa simulasi paralel §8.2.7 yang dulu menjalankan kandidat satu per satu untuk dibandingkan dapat dipersempit menjadi satu kali penjelajahan di atas ruang terkompresi.

Mengapa "masih terlalu dini"? Pertama, pekerjaan menentukan apa yang dijadikan dimensi (aliran mana yang independen dan mana yang dependen) itu sendiri adalah teka-teki domain yang sulit. Kedua, kompresi pada hakikatnya adalah membuang informasi, sehingga insiden live bisa meledak pada dimensi yang dibuang. Ketiga, semua ini hanya bermakna ketika verifikasi telemetry penerapan konservatif (§8.2.6) sudah kokoh — jika model sebelum kompresi sudah melenceng dari game, kompresi hanya akan mengompresi galat itu dengan rapi pula. Maka bagian ini bukanlah resep, melainkan rambu arah. Yang harus dilakukan sekarang adalah menjalankan penerapan konservatif secara jujur, sementara vektor dimensi dibiarkan sebagai wilayah riset yang baru akan ditengok beberapa tahun lagi oleh tim yang sudah cukup menumpuk fondasinya.

8.2.8 Pengukuran — Tempat di Mana Rapat Berubah Menjadi Simulasi

Saya membandingkan kondisi sebelum dan sesudah pengadopsian alat. Waktu dan frekuensi di bawah memuat arah yang dirasakan dari operasi tahap awal pengadopsian, jadi alih-alih dibaca sebagai nilai absolut yang presisi, lebih tepat dibaca dari ke arah mana ia bergerak.

Makna baris terakhir lebih besar daripada angka-angka di tabel. Berkurangnya frekuensi rapat terjadi karena simulasi menggantikan perdebatan. Ketika "menurut saya sepertinya inflasi akan datang pada batu penguat" berubah menjadi "hasil simulasi +28% pada 26 minggu", tempat yang dulu memperdebatkan tebakan selama satu jam berakhir sebagai berbagi hasil selama 5 menit. Ini persis di tempat yang sama dengan konsep yang dikunci jadi aturan dalam retrospektif sistem penulis (atom automation_signal_value_over_time_savings — nilai otomasi bukanlah penghematan waktu, melainkan pemaparan sinyal). Hasil sejati dari gerbang simulasi bukanlah waktu yang dihemat, melainkan membuat angka menempati tempat yang dulu ditempati tebakan di rapat.

Namun satu hal saya letakkan dengan jujur. "1\~2 kasus → 0\~1 kasus per kuartal" di tabel bukanlah nilai pengukuran presisi, melainkan arah yang dirasakan dari operasi. Karena hitungan insiden inflasi berubah-ubah tergantung definisi (harga ±berapa % dianggap insiden), lebih tepat dibaca sebagai perubahan struktur "bergeser dari ketahuan belakangan menjadi dicegah lebih awal" ketimbang sebagai jumlah absolut.

8.2.9 Kegagalan yang Umum

Yang kedua paling sering terlewat. Seperti penghitungan ganda pasar lelang yang kita lihat di §8.2.3, AI memuntahkan model yang terdengar masuk akal dengan percaya diri, tetapi kelemahan asumsinya sendiri hanya ia laporkan dengan ★ sementara cacatnya ia tinggalkan di dalam isi. Jika manusia tidak memutuskan ★ itu, model yang salah akan lolos dan semua keputusan simulasi di atasnya ikut salah.

8.2.10 Coba Sendiri — Satu Langkah yang Bisa Dilakukan Hari Ini

Versi Ringkas Solo: Tidak perlu Machinations maupun telemetry. Pilihlah satu sumber daya dari game Anda sendiri (atau game yang Anda sukai), tulis source·sink-nya di kertas, lalu tempelkan apa adanya prompt dari §8.2.3 untuk menerima draf model saldo bersih 1 minggu. Jika Anda memilih satu asumsi yang dinyatakan AI dengan ★ lalu membantahnya dengan "asumsi ini tidak bisa saya percaya, ajukan dasarnya lagi", Anda akan merasakan secara langsung bahwa model ekonomi itu adalah seikat asumsi-asumsi — dan bagaimana kesimpulannya bisa terbalik kalau satu asumsi itu salah.

Jika Anda dalam tim, mulailah dengan satu langkah berikut. Bukan seluruh sumber daya, melainkan pilih satu sumber daya yang paling bermasalah (biasanya gold atau batu penguat), susun lebih dulu hanya model sumber daya tunggal dari §8.2.3, lalu lewatkan satu jenis keputusan perubahan ekonomi (misalnya imbalan event) melalui gerbang simulasi dari §8.2.5. Hanya dengan satu sumber daya + satu jenis keputusan pun, Anda bisa mengubah tempat yang dulu memperdebatkan tebakan di rapat menjadi satu baris angka.

Jika diringkas menjadi setup → prompt → verify — setup: ekstrak source·sink dari satu sumber daya bermasalah ke dalam yaml. prompt: terima draf model node dalam format §8.2.3, tetapi paksa agar asumsi perilaku pemain dinyatakan dengan ★. verify: manusia secara langsung menolak·meminta ulang asumsi ★ yang dilaporkan AI dan klasifikasi node (terutama perpindahan antarpemain vs penciptaan baru).

Poin-Poin Penting

• Ekonomi bukan 5 jenis sumber daya, melainkan puluhan aliran yang terakumulasi seiring waktu, sehingga simulasi diperlukan.
• Draf model AI dipaksa untuk menyatakan asumsi, lalu asumsi itu ditolak oleh manusia.
• Perubahan ekonomi diputuskan bukan lewat tebakan rapat, melainkan lewat lolos/gagal gerbang simulasi.

Pratinjau Bab Berikutnya

• 8.3 Damage Simulator (2008\~) — bagaimana alat simulasi berusia 18 tahun didaur ulang di era AI

8.3 Damage Simulator — Hari Ketika DPS Spesifikasi dan Hasil Simulasi Berpisah

Suatu dini hari di tahun 2008, saya berkali-kali memeriksa ulang angka yang sama sebanyak tiga kali di depan satu lembar Excel. Dalam dokumen desain tertulis bahwa damage per detik dari sebuah karakter pedang adalah 847. Namun simulator yang saya jalankan pertama kali hari itu memuntahkan 612 untuk karakter yang sama dengan spesifikasi yang sama. Selisih 27%. Salah satu dari keduanya berbohong, dan saat itu saya belum tahu yang mana yang berbohong.

DPS dalam spesifikasi adalah janji di atas kertas. Hasil aritmetika dari damage satu kali skill dikalikan frekuensi pemicunya. DPS dalam simulator adalah hasil dari benar-benar mengayunkan janji itu sebanyak 1,000 kali. Cooldown saling bertumpang tindih, gerakan cast memakan waktu, dan critical hit tidak meledak sebanyak nilai harapannya — gesekan yang tidak diketahui kertas pun menyusup. Celah 27% inilah justru tempat seorang perancang balance mencari nafkah. Kalau Anda memercayai kertas, Anda akan menangis setelah peluncuran.

Bab ini adalah kisah tentang satu alat itu. Damage Simulator yang saya buat pada 2008 dan tidak pernah saya lepas dari tangan sampai sekarang. Saya akan menelusuri, lewat satu worked transcript (rekaman sesi nyata), bagaimana titik persis di mana spesifikasi dan hasil berpisah itu dilacak, lalu bagaimana 18 tahun kemudian AI saya tempelkan ke pelacakan tersebut.

8.3.1 Mengapa DPS Spesifikasi Selalu Berbohong

Pertama, mari kita bedah jati diri 612 versus 847 itu. Perancang junior yang menulis spesifikasi (selanjutnya disebut anggota tim A) tidak melakukan kesalahan. Ia mengalikan persis seperti yang tertulis di tabel skill.

Perhitungan DPS dalam spesifikasi terlihat seperti ini. Anggaplah sebuah karakter memiliki tiga skill.

Perhitungan spesifikasi anggota tim A berdiri di atas asumsi ideal bahwa "setiap skill digunakan tanpa terlewat begitu cooldown selesai". Tebasan Horizontal memberi 320 setiap 3 detik, Tusukan 540 setiap 6 detik, dan Basic Attack mengisi waktu yang kosong. Secara aritmetika, hasilnya keluar bersih 847. Di atas kertas, karakter itu seolah punya banyak tangan sehingga gerakan cast tidak saling menghalangi.

Alasan simulator menghasilkan 612 hanya satu: karena tangannya cuma satu. Selama mengeluarkan Tusukan yang berdurasi 0.9 detik, walaupun cooldown Tebasan Horizontal sudah pulih, ia tetap tak bisa dipakai. Tabrakan global cooldown ketika gerakan cast saling memakan ini tidak ada dalam spesifikasi. Kertas adalah ruang hampa tanpa gesekan, sedangkan simulasi adalah medan tempur yang penuh gesekan. Kebenaran pertama yang saya pelajari selama 24 tahun mengerjakan pekerjaan ini adalah ini — DPS spesifikasi itu batas atas, bukan nilai terukur. Dan pengguna memainkan game bukan dengan batas atas, melainkan dengan nilai terukur.

8.3.2 Worked Transcript — Mendesak AI Soal Asal-Usul 612

Saya yang di tahun 2008 menambal celah 27% ini secara manual. Saya membaca log simulasi baris demi baris dengan mata, menghitung pada frame mana skill terhalang. Butuh setengah hari. Sekarang, 18 tahun berlalu, saya melempar log yang sama kepada Claude. Berikut adalah transkrip lengkap dari satu sesi yang benar-benar saya jalankan. Tanpa diringkas, dan saya muat apa adanya termasuk percobaan pertama yang melenceng — sebab melencengnya itu adalah separuh dari cara menggunakan alat ini.

Prompt yang saya lempar berbunyi begini.

Yang terlampir adalah sebagian log pertarungan 1,000 tick untuk satu karakter dari Damage Simulator kami (damage_sim/, Python). Menurut spesifikasi, DPS karakter ini adalah 847, tetapi hasil simulasi keluar 612. Cari penyebab gap 27% itu di dalam log. Format log adalah [tick] event skill=SKILL state=STATE. Jangan menebak, sebutkan hanya bukti yang ada di log. Kalau buktinya kurang, katakan bahwa buktinya kurang.

[0.0] cast skill=Tusukan state=START
[0.9] cast skill=Tusukan state=HIT dmg=540
[0.9] cast skill=Tebasan Horizontal state=BLOCKED reason=GCD
[1.5] cast skill=Basic Attack state=HIT dmg=180
[1.9] cast skill=Basic Attack state=BLOCKED reason=GCD
[3.0] cast skill=Tebasan Horizontal state=HIT dmg=320
[3.6] cast skill=Basic Attack state=HIT dmg=180
... (994 lines omitted)
[997.2] cast skill=Tusukan state=HIT dmg=540

Keluaran mentah (raw output) dari Claude berbunyi begini (tidak dipoles).

Fakta yang terkonfirmasi dari log:

1. Event state=BLOCKED reason=GCD muncul berulang kali. Pada [0.9] Tebasan Horizontal, dan pada [1.9] Basic Attack, terhalang oleh GCD (global cooldown).
2. Sebelum cast Tusukan (0.0→0.9, 0.9 detik) selesai, skill lain tidak bisa terpicu. Tampaknya strukturnya membuat cast time menduduki GCD.
3. Karena itu, asumsi dalam spesifikasi yaitu "memicu setiap skill setiap cooldown" menjadi runtuh. Pada praktiknya, gerakan cast saling bertabrakan sehingga sebagian pemicuan terlewat.

Hanya saja, log yang diberikan baru 7 baris dari 1,000 baris. Apakah gap tepat 27% itu bisa dijelaskan hanya dengan tabrakan GCD tidak dapat dipastikan dengan 7 baris ini. Untuk memverifikasi 27%, perlu dihitung total kemunculan event BLOCKED dan total damage yang terlewat akibatnya. Jika Anda memberikan agregat BLOCKED dari seluruh log, saya akan memverifikasinya secara kuantitatif.

Berhentinya di sini itu penting. AI menunjuk penyebabnya, tetapi tidak membuktikan angka 27%, dan ia sendiri menyebutkan batas itu. Di tempat yang seorang perancang-di-atas-kertas akan menutup rapat dengan "Oh, gara-gara GCD ya", alat ini bertahan dengan "dengan 7 baris saya tidak tahu". Saya menilai tuntutan itu wajar — inilah verifikasi manusia. Maka saya menarik agregat BLOCKED dari seluruh log dan melemparkannya lagi.

Ini agregat seluruh 1,000 tick. BLOCKED total 412 kali, di antaranya 388 karena alasan GCD, 24 karena cooldown belum terisi. Estimasi damage yang terlewat akibat BLOCKED, dikonversi ke Tebasan Horizontal, sekitar 19,800. Selama total 1,000 tick pertarungan (= detik), damage harapan menurut spesifikasi adalah 847,000, sedangkan damage kumulatif terukur dari simulasi adalah 612,300. Tinjau ulang gap 27% dengan angka-angka ini.

Keluaran kedua dari Claude.

Saya verifikasi dengan agregat.

• Harapan kumulatif spesifikasi: 847,000
• Terukur kumulatif simulasi: 612,300
• Gap: 234,700 (27.7%)

Komposisi gap ini: - Terlewat langsung akibat tabrakan GCD (388 kali): estimasi sekitar 19,800 itu adalah konversi ke Tebasan Horizontal, tetapi perlu juga ditambahkan biaya peluang dari skill berdamage lebih tinggi yang seharusnya bisa masuk ke slot yang terlewat. Jika slot yang terlewat dikonversi ke damage rata-rata, bagian yang terlewat menjadi lebih besar dari 19,800. - Namun seluruh 234,700 tidak dapat dijelaskan hanya dengan BLOCKED. Interpretasi sisa gap akan berbeda tergantung apakah spesifikasi 847 itu nilai yang "sudah memasukkan nilai harapan critical sebagai rata-rata" atau "nilai dasar tanpa critical". Jika Anda memberi tahu asumsi critical dari spesifikasi 847, saya akan menguraikan sisa gap-nya.

Ia berhenti lagi. Dan lagi-lagi berhenti tepat di tempat yang benar. Bagaimana spesifikasi 847 memperhitungkan critical — ini informasi yang tidak ada di log, dan hanya ada di kepala anggota tim A. AI mengetahui batas data yang dimilikinya. Ketika saya periksa, ternyata spesifikasi 847 adalah nilai yang sudah diratakan dengan memasukkan harapan critical pada peluang 20% dan 1.5x, sedangkan simulasi adalah satu kali ronde di mana jumlah kemunculan critical sesungguhnya keluar lebih rendah dari nilai harapan setelah seed dikunci. Artinya, gap 27% adalah nilai campuran dari tabrakan GCD (struktural, tereproduksi) dan varians critical (statistik, keberuntungan ronde ini saja).

Penguraian inilah kesimpulannya. Bagian tabrakan GCD adalah masalah nyata yang harus diperbaiki lewat desain, sedangkan bagian varians critical adalah noise yang akan lenyap jika seed diganti dan diambil rata-rata 1,000 ronde. Kalau keduanya dicampur lalu diberi buff dengan dalih "karakternya lemah", maka karakter yang sebenarnya baik-baik saja pada rata-rata 1,000 ronde justru jadi terlalu kuat. Yang membuat pembedaan ini — yang tidak diketahui kertas, tidak diketahui satu ronde simulasi, dan tidak diketahui AI sendirian pun — adalah verifikasi manusia yang menyodorkan agregat log dan asumsi tersembunyi dari spesifikasi.

8.3.3 Satu Set Input Menjadi Satu Set Output — Membedah Simulasi

Mari kita bentangkan input dan output alat yang baru saja diintip sesi tadi dalam satu set. Pada akhirnya, simulator adalah fungsi yang jujur. Input yang sama menghasilkan output yang sama. Input berkumpul dari tiga jalur.

flowchart LR
    A["Sheet Data Game
(tabel skill·stat karakter)
read-only"] --> SIM
    B["Skenario yaml
(kondisi tempur·durasi·
komposisi target)"] --> SIM
    C["seed=42
(angka acak dikunci)"] --> SIM
    SIM["Damage Simulator
domain/formulas.py
run_combat() × 1000 tick"]
    SIM --> R1["Damage Kumulatif Terukur
612,300"]
    SIM --> R2["Log BLOCKED
412 kali (GCD 388)"]
    SIM --> R3["Kemunculan Critical
terukur 17.2% vs harapan 20%"]
    R1 --> REP["Laporan markdown
spesifikasi 847 vs simulasi 612
uraian gap: struktur 19% + varians 8%"]
    R2 --> REP
    R3 --> REP

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class SIM code;
    class A,B,C,R1,R2,R3,REP data;

Inti gambar ini adalah bahwa panahnya searah. Sheet data game hanya dibaca oleh simulator. Simulasi tidak pernah mengubah datanya. Aturan yang paling banyak mencegah kecelakaan selama 18 tahun adalah arah satu panah ini. Begitu simulasi mulai menyalin data ke dalam dirinya sendiri, maka pada hari setelah data game berubah, simulasi akan menyimulasikan dunia kemarin. Kalau rapat digelar berdasarkan laporan yang keluar dari situ, seluruh rapat akan berdebat soal dunia kemarin.

Satu set input yang konkret (skenario yaml) terlihat seperti ini.

# scenarios/single_dps_check.yaml
scenario: single_target_dps
duration_ticks: 1000      # asumsi 1 tick = 0.1s, pertarungan 100 detik
seed: 42                  # deterministik — input sama output sama
actor:
  char_id: K_004          # dibaca dari sheet data game
  skill_rotation: optimal # saat tabrakan GCD, prioritaskan damage harapan tertinggi
target:
  defense: 1200
  hp: infinite            # dummy HP tak terbatas untuk mengukur DPS
report:
  compare_to_spec: 847    # masukkan DPS spesifikasi untuk uraian gap otomatis

Dan satu set output (kutipan laporan) seperti ini.

# Damage Simulator Report — K_004 single DPS
input: scenarios/single_dps_check.yaml | seed=42 | data rev. 2026-06-05

## Terhadap Spesifikasi
- DPS spesifikasi:    847   (sudah meratakan harapan critical 20%·1.5x)
- DPS terukur simulasi: 612 (1 ronde seed ini)
- Gap:                -27.7%

## Uraian Gap
- Struktural (tabrakan GCD, tereproduksi):  -19.2%  ← objek tinjauan desain
- Statistik (varians critical, ronde ini):  -8.5%   ← diperkirakan hilang saat rata-rata 1000 ronde

## Verifikasi Reproduksi
- seed=42 dijalankan ulang 3 kali → 612,300 / 612,300 / 612,300 (cocok)
- rata-rata DPS 1000 ronde seed 0~999 → 731 (setelah varians critical dihilangkan)

Lihat baris terakhir. Rata-rata dari menjalankan 1,000 ronde dengan seed 0\~999 adalah 731. Gap 116 (13.7%) antara spesifikasi 847 dan rata-rata 1,000 ronde 731 itulah ukuran dari masalah struktur sungguhan bernama tabrakan GCD. Bukan 612 dari satu ronde, melainkan 731 inilah yang seharusnya menjadi input rapat desain. Bukan 847 di atas kertas, bukan pula 612 dari satu ronde yang sial, tapi 731 yang disepakati 1,000 ronde. Menggenggam angka ini di tangan adalah pekerjaan seorang perancang balance.

8.3.4 Tangan Tahun 2008 dan Tangan Tahun 2026

Alat ini telah hidup 18 tahun, tetapi bukan hidup dengan kode yang sama. Gantungan bajunya saya biarkan tetap, hanya bajunya yang saya ganti lima kali. Gantungan baju itu adalah logika laporan di atas — prosedur melihat spesifikasi dan hasil terukur secara terpisah, menguraikan gap menjadi struktur dan varians, lalu memverifikasi dengan reproduksi. Prosedur ini sama persis kata demi kata, baik di Excel VBA (bahasa makro Excel) tahun 2008 maupun di Python tahun 2026.

Rahasia bertahan melewati lima kali ganti baju terukir dalam struktur folder.

damage_sim/
├── domain/          # gantungan baju — tetap selama 18 tahun
│   ├── formulas.py      # rumus damage·penentuan tabrakan GCD
│   └── metrics.py       # logika uraian gap
├── adapters/        # data game read-only
│   └── excel_reader.py
├── runners/         # baju — diganti setiap kali teknologi berubah
│   └── cli_runner.py
└── reporters/       # baju — format keluaran laporan
    └── markdown_report.py

Kalau teknologinya berubah, hanya runners/ dan reporters/ yang ditulis ulang. Logika uraian gap di domain/ tetap bertahan sebagai aset 18 tahun apa adanya. Rumus penentuan tabrakan GCD yang dulu saya tulis dengan sel Excel pada 2008 kini berjalan di formulas.py dengan hanya signature fungsinya yang berubah. Bahwa memaku sebuah alat ke satu teknologi berarti alat itu menua dan mati bersama teknologi tersebut — itu saya pelajari sambil mengantarkan beberapa alat yang mati.

LLM yang saya tempelkan pada 2025 bukanlah gantungan baju baru, melainkan tangan baru. Seperti yang terlihat di sesi sebelumnya, AI adalah tangan yang membaca log dan menyusun hipotesis, dan pelacakan log yang dulu butuh setengah hari menyusut menjadi beberapa menit. Tetapi gantungan bajunya tidak disentuh — yang memutuskan apakah gap-nya 27% atau berapa persen critical yang meledak tetaplah inti deterministik dengan seed yang dikunci. Pada saat LLM masuk ke posisi itu, pengujian regresi menjadi mustahil dan alatnya pun mati.

8.3.5 Inti Deterministik dan Luarnya — Di Mana Garis Ditarik

Kalau di sebuah alat balance harus ditarik satu garis saja, saya menariknya di batas inti deterministik. Sisi dalam harus menjamin input sama menghasilkan output sama sekuat baja, sedangkan sisi luar boleh saja diisi manusia atau AI yang melontarkan hipotesis dengan bebas.

Sisi dalam (deterministik — AI dilarang): - Rumus damage, penentuan tabrakan GCD, kemunculan critical, agregasi kumulatif. - Dijalankan tiga kali dengan seed=42, harus menghasilkan 612,300 yang sama persis tiga kali. Kalau ini rusak, laporan kemarin dan laporan hari ini tak bisa dibandingkan.

Sisi luar (hipotesis·interpretasi — AI dipersilakan): - Kueri sebab seperti "kenapa win rate kombinasi karakter ini abnormal". - Mencari pola BLOCKED di log, draf laporan bahasa alami, draf skenario yaml.

Worked transcript di depan bergerak persis di atas garis ini. Dari sisi luar, AI dengan cepat menyusun hipotesis "tabrakan GCD adalah penyebabnya". Tetapi angka 27%, angka 612, sampai akhir tetaplah nilai yang dihitung oleh inti deterministik, dan AI menerima nilai itu lalu hanya menafsirkannya. Lalu dua kali ia berhenti dengan "dengan data ini tidak bisa dipastikan" — sambil meminta informasi yang tak bisa diberikan inti deterministik (asumsi critical dari spesifikasi). Berhenti inilah penanda alat yang baik. Yakni tidak mengira hipotesis sebagai diagnosis.

Ada satu hal yang saya akui secara jujur soal angka. Angka-angka konkret di bab ini seperti 847·612·731·412 kali adalah nilai contoh yang saya susun untuk keperluan penjelasan. Namun arah bahwa DPS spesifikasi selalu keluar lebih tinggi dari hasil terukur simulasi, struktur bahwa gap itu terurai menjadi tabrakan struktural dan varians statistik, serta prinsip bahwa pengunci seed adalah prasyarat pengujian regresi — itu semua telah berulang kali saya konfirmasi sambil benar-benar menjalankannya selama 18 tahun sejak 2008. Besaran rasionya berbeda-beda tergantung proyek, tetapi arah dan strukturnya tidak berubah.

Coba Sendiri — Satu Kali Uraian Gap terhadap Spesifikasi

setup. Dari data game, pilih satu karakter dan amankan tabel skill-nya (damage·cooldown·cast time) beserta DPS spesifikasinya. Kalau tidak punya simulator, tulislah skrip minimal yang menjalankan pertarungan target tunggal 1,000 tick. Intinya hanya satu: skrip itu harus bisa menerima seed sebagai argumen dan menguncinya.

prompt. Lemparkan log simulasi (termasuk event BLOCKED) bersama DPS spesifikasinya.

Yang terlampir adalah log pertarungan 1,000 tick dari 1 karakter beserta agregat BLOCKED. DPS spesifikasi adalah [N], tetapi hasil simulasi adalah [M]. Uraikan penyebab gap hanya dengan bukti dari log. Bedakan penyebab struktural (tabrakan yang tereproduksi) dan penyebab statistik (varians ronde ini). Kalau buktinya kurang, katakan bahwa buktinya kurang dan tunjukkan apa lagi yang dibutuhkan.

verify. Verifikasi penyebab struktural yang ditunjuk AI dengan mengganti seed dan mengambil rata-rata 1,000 ronde. Kalau gap masih tersisa pada rata-rata pun, itu masalah struktur sungguhan; kalau lenyap, itu noise varians. Kalau AI berhenti dengan "tidak bisa dipastikan", itu bukan kegagalan melainkan hal yang normal — di tempat ia berhenti, manusia masuk dan mengisi asumsi tersembunyi dari spesifikasi.

Versi Ringkas Solo

Kalau Anda developer solo tanpa simulator maupun ML, Anda bisa menjalankan prosedur yang sama hanya dengan satu lembar Excel dan AI. Tuliskan tabel skill ke sheet, dan buat simulasi 1,000 baris dalam satu kolom yang melempar critical dengan RAND(). Karena seed tidak bisa dikunci, hitung ulang 100 kali dengan F9 dan lihat rata-ratanya secara manual. Lemparkan gap antara rata-rata itu dan DPS spesifikasi ke AI dengan permintaan "tolong pisahkan menjadi penyebab struktur dan penyebab varians". Alatnya boleh kecil, tetapi gantungan baju — uraian gap terhadap spesifikasi, pemisahan struktur dan varians, verifikasi reproduksi — tetap berdiri sama.

Poin-Poin Penting

• DPS spesifikasi adalah batas atas tanpa gesekan, sedangkan nilai terukur yang dialami pengguna dicari oleh simulasi lewat rata-rata 1,000 ronde.
• Gap antara spesifikasi dan simulasi harus dipisahkan menjadi tabrakan struktural dan varians statistik agar masalah desain sungguhan terlihat.
• Sisi dalam inti deterministik melarang AI, sedangkan sisi luar untuk hipotesis·interpretasi menyambut AI sebagai tangan baru.

Pratinjau Bab Berikutnya

• 8.4 Simulasi Balance Berbantuan AI — posisi-posisi yang mengotomatiskan area sekeliling sambil menjaga inti deterministik