透過 MCP 製作遊戲

以下說明這些工具預期的使用方式。你的助理會直接從伺服器得知其中大部分內容—— 這一頁是寫給你看的，讓你能判斷一次執行是否順利，並在不順利時修正方向。

ⓘ

還沒連接嗎？請先閱讀快速入門：連接你的 AI。完整的工具清單請見工具參考。

連接之後你會得到什麼

你的助理保有自己的模型、自己的上下文，也自行負擔自己的費用。Gamentic 提供的是工具、儲存空間、生成用的硬體、驗證機制，以及 Editor（編輯器）。由於內建的網頁 agent 與外部用戶端連接的是完全相同的端點，所有規則都以相同的方式執行——計量、方案限制、擁有權檢查、封面生成、規範驗證。只有一條套用規則的路徑，沒有享有特權的內部通道。

製作流程

伺服器會把專屬的指示交給 AI，一次正確的執行會依照以下順序進行。

讀取規則——免費
get_convention 會回傳標記規範、你目前啟用的模組設定、價目表以及你的錢包狀態。 get_skill 會回傳知識包；mechanics（機制）與 balance（平衡）為必讀， screens（畫面）則是每款遊戲都必讀；如果有相符的遊戲類型藍圖，應該讀取它，而不是自創機制。
取得遊戲問卷——免費
new_game_brief 會回傳一個表單網址交給你，接著由 wait_for_brief 以長輪詢等待你的回答。需要輪詢好幾次是正常的。
設計角色陣容——依圖像計費
以 concept_art 生成概念圖，在任何程式碼出現之前先交給你確認。
建立外殼——免費
以 create_game 建立一個 60–120 行的 game.html：包含標記區塊、 harness、canvas，以及依相依順序為每個預定的檔案各放一個 script 標籤。回應中會列出尚未存在的檔案。
填入各個檔案——免費
逐一用 write_game_file 寫入每個檔案。最後一個待寫入的檔案完成時，伺服器會執行真正的無頭瀏覽器測試，並回報 runtime: passed 或確切的錯誤。
生成並接上素材——消耗 credits
美術、音效、音樂。如果素材還沒有在遊戲中的任何地方被繪製，每個結果都會附上提示。
自我檢查——免費
用 list_assets 處理所有尚未繪製的美術或尚未播放的音訊，用 playtest_screenshot 查看成果，然後交給你一個編輯器連結。

為什麼外殼優先很重要

先把整個遊戲寫成一個 HTML 字串、事後再拆分，等於把你已經付過錢的程式碼重寫一次。更糟的是，單一檔案的遊戲會碰到天花板：之後的每一次修改，都要把整份原始碼送進上下文視窗，於是 AI 開始弄壞它已經看不到的東西。以外殼優先的方式製作，每次修改只需讀寫幾 KB，而不是幾百 KB。

真正只有一個畫面的小玩具——遠少於 1,500 行、沒有關卡、只有一種敵人——可以用單一次 create_game 建立。只要有多個關卡、多種敵人或劇情模式，就不應該這樣做。

⚠

缺少檔案的外殼就是一片白畫面。只要外殼還有未寫入的檔案，就會跳過執行期檢查，所以在最後一個檔案完成之前，一切都沒有經過驗證。如果你的助理在仍有檔案待寫入時就宣布遊戲已完成，這個說法並沒有經過測試。

編輯：依修改的大小選擇工具

對於既有的遊戲，這是決定迭代速度與成本最重要的單一因素。

修改	做法
只改一個數值	`bake_config`
單一 `src/` 檔案內的行為	`list_game_files` → `read_game_file` → `edit_game_file`——遠比其他方式便宜
外殼裡的東西（標記、script 順序、啟動流程）	`search_game_source` → `edit_game`
新的系統、角色或場景	`write_game_file`，再用 `edit_game` 加上它的 script 標籤
劇情或對白內容	`read_data` / `write_data`——絕對不要用尋找並取代
完整重寫	`update_game`，或分段上傳

★

留意 get_game 是否被當成搜尋工具使用。一旦有了素材，一款遊戲就會有好幾 MB。為了找一個函式而取回整個遊戲，不但很慢，還會把其他所有內容擠出上下文。 list_game_files 與 search_game_source 正是為了避免這種情況而存在。

你會遇到的保護機制

有幾條伺服器端規則是因為真實發生過的事故而設立的。它們偶爾會拒絕你的助理嘗試的操作，而這種拒絕通常是正確的。

規則	作用
素材遺失防護	任何會讓圖像、音訊或模型數量減少的寫入都會被拒絕，除非呼叫端明確選擇允許。這條規則是在某次編輯把 26 個素材減少到只剩一個之後加入的。
以伺服器素材為準	當 AI 根據過時的副本提交整個檔案的重寫時，素材區塊會逐一依鍵值合併，並以伺服器上的目前版本為準；回應中也會說明保留了哪些——這樣模型就不會試圖把它們「修正」回去。
注入前重新讀取	生成需要幾秒到幾分鐘。工具會在注入之前立即重新讀取遊戲，因此緩慢的任務不會覆蓋你在這段期間做的修改。
全有或全無的編輯	一次編輯在儲存之前，會先經過套用、驗證、語法檢查與素材檢查。任何一步失敗，就代表什麼都沒有改變。
執行期把關	提交的內容會在真正的瀏覽器中執行。有問題的遊戲會被拒絕，而不會被儲存並交給你。

非同步任務

音樂、sprite 動畫、動態 CG、Live2D 骨骼綁定以及所有 3D 工作，都以背景任務執行。工具會立即回傳一個任務 ID；再由 check_job（也註冊為 check_model_3d）輪詢它。中斷的 sprite 任務會從已儲存的狀態接續，而不會再次花費影片 credits。

你會看到你的助理同時啟動好幾個任務，並一起輪詢。這是正確的——它不應該卡在單一個任務上等待。

預算

請把預算當作設計條件，而不是花費計量表：「幫我做一款 5,000 credits 的遊戲」。接上預算模式後，一次好的執行會先為製作範圍估價，告訴你能得到什麼、得不到什麼，並在花費之前先詢問你。之後 budget_status 會依工具分組，回報這款遊戲的帳目，加上尚未綁定任何遊戲的近期花費，以及一項花費速度的判斷。

⚠

在遊戲建立之前生成的概念圖，無法歸屬到該遊戲。設計先行的步驟發生在 create_game 之前，所以那部分花費在 budget_status 中看不到。細心的助理會把它算進計畫裡，並在遊戲建立後，把遊戲 ID 傳給 concept_art。如果一次執行回報「已花費 5,000 / 5,000」，實際數字可能更高。

錢包

get_convention 會回報目前啟用的是哪個錢包，以及每個錢包裡有多少額度。生成只會向目前啟用的錢包扣款，用完就會停止，而不會改扣另一個錢包。如果工具回報錢包已用完，你的助理應該轉告你，並讓你決定—— 用 set_active_wallet 切換錢包是由你決定，而不是由它自行決定。

編輯器請求循環

這個循環讓外部助理成為 Editor 中的一等公民。當你在執行中的遊戲裡圈出某個東西並加以描述，它就會成為一個請求，讓你的助理可以接手處理。

工具	運作方式
`read_edit_requests`	拉取。回傳文字、動作、實體、目前的設定，以及最多兩張以真實圖像形式提供的截圖。
`wait_for_edit_request`	推送。以長輪詢等待約 50 秒並附帶心跳訊號，讓 Editor 可以顯示「有 AI 正在聆聽」。
`finish_edit_request`	完成時必須呼叫。你的備註會即時出現在 Editor 中。

自我改進

開啟「自我學習」模組後，助理會在製作結束時呼叫 submit_feedback，提交一條具體、可重複使用的經驗——一個陷阱與它的解法、一個有效的數值、一個 API 的特殊行為。這些筆記會附加到之後製作時相對應的 get_skill 回應中，讓引擎越用越好。list_learned 會顯示目前累積了哪些內容。

不穩定的連線

一次巨大的 create_game 是所有呼叫中最脆弱的——一旦中斷，整個遊戲都要重新生成。開啟連線不穩模式後，上傳會分成編號的區段，透過 begin_game_upload、 append_game_html 與 commit_game 進行。中斷後重新傳送同一個區段是安全的；如果跳過了某個區段，伺服器會說明它預期收到的是哪一段。

分段上傳只用於初次建立與完整重寫。日常的修改請使用編輯工具。

引導一次執行

這樣說	就能得到
「先讀取規範和相關的 skill。」	機制取自經過驗證的藍圖，而不是憑空自創。免費，而且是效益最高的一句指示。
「花錢之前先估價。」	一份製作範圍與小計，讓你可以核准或刪減。
「以外殼優先的方式製作，每個實體一個檔案。」	一款之後修改起來依然便宜的遊戲。
「每個額外的姿勢都用角色立繪來做。」	從頭到尾都是同一個角色，而不是每張圖都換成不同的人。
「在告訴我完成之前，先檢查 `list_assets`。」	不會有付費生成的美術待在遊戲裡卻看不到。
「不要改數值——把它們開放出來。」	可調參數會放進設定與 schema，讓你可以自己免費調整。

下一步

遊戲規範→

每款遊戲都必須遵循的標記、harness、schema 與套件結構。

工具參考→

全部 66 個工具依類別列出，附上價格與常見陷阱。