生成專屬寶可夢：遊戲內的研究原型

概要

我製作了一個研究原型，根據玩家在遊戲中選擇的六個詞語，生成新的寶可夢物種。幾分鐘後，牠就會出現在草叢中，玩家可以遇見、捕捉並替牠取暱稱。原型會生成外觀、名稱、屬性、種族值、招式，以及將牠整合進遊戲所需的資料。

原型在不中斷遊戲的情況下，串起遊戲內對話、詞語選擇、背景生成、野外遭遇、捕捉與命名。每個生成物種都以既有遊戲系統可使用的形式登錄。

我的重點在生成框架，而非模型本身：先定義維持遊戲平衡與視覺一致性的需求，再讓 AI 在這些界限內探索。我也親自遊玩原型，初步思考僅有「獨一無二」是否就足以讓我對角色產生情感依附。

問題：獨一無二，是否就能產生情感依附？

遊戲讓玩家選擇、培養並命名角色，逐漸將牠視為專屬於自己的存在。但起點仍是開發者準備好的選項。若生成式 AI 讓玩家能從一開始就塑造角色，會產生更強的情感依附嗎？

僅生成一張圖片，不足以探索這個問題。角色必須進入遊戲世界、能被遇見與捕捉，之後還能繼續使用。我設計了兩條玩家參與程度不同的路線：與老先生對話，會在沒有玩家輸入的情況下觸發生成；與老婦人對話，則由玩家選擇六個詞語。第一次交談的對象，決定這次遊玩採用的生成方式。

這個原型並未對情感依附得出結論。它的目的，是將生成內容融入一般遊玩流程，並找出未來可比較的條件。

遊戲流程

以下呈現由玩家引導生成的路線。在 Petalburg Woods 森林中，玩家與老婦人交談，從遊戲既有的 Easy Chat 詞彙中選擇六個詞語。玩家繼續遊玩時，生成工作在背景執行。叫聲提示新物種已準備好；進入草叢便會觸發遭遇，並可用一般操作捕捉。每次生成都包含名稱、屬性、種族值、招式、正反面戰鬥角色圖，以及隊伍圖示。示範影片呈現完整流程。

設計挑戰：讓生成角色能融入遊戲

生成新角色，與讓角色能在遊戲中運作，是不同的挑戰。能力值過高會破壞難度平衡，屬性與招式搭配不當會讓角色難以培養。過度複雜的設計，縮小為 64 × 64 像素的角色圖時，也可能難以辨識。

若固定所有細節，就失去每次生成不同結果的意義。我需要區分哪些元素是遊戲成立的必要條件，哪些則可以變動。

因此，我著重設計可能生成哪些寶可夢的範圍，而非單一角色。由人定義目標、約束、禁止內容與驗證方法，AI 再在框架內提出候選方案。這個可運作的原型，將我以約束驅動的設計方法付諸實作。

方法：定義生成條件

系統要求大型語言模型（LLM）填寫名稱、屬性、種族值、招式、體型與顏色等預定欄位，而非撰寫自由文字。每次回覆都先經驗證器檢查，才會採用。若違反規則，系統會指出具體問題，要求模型重新生成，直到符合需求。

1. 人定義界限。將遊戲平衡、角色圖的清晰度與可接受內容等需求，轉化為明確且可檢查的規則。
2. AI 提出候選方案。模型根據玩家選擇的詞語，為允許的欄位提出數值與內容。
3. 系統依規則檢查輸出。自動檢查數值範圍、招式組合與禁止內容。
4. 只針對違規項目提供回饋。不符合規則的候選方案，會附上原因退回並重新生成。

維持遊戲性的約束。我將種族值總和限制在 280–360，並為各項能力設定上下限。招式從遊戲原始碼中擷取，只允許與物種屬性相同或一般屬性的招式，並排除一擊必殺、自爆、固定傷害與過於強力的招式。驗證器也檢查攻擊招式的數量，以及是否有與自身屬性相符的招式。捕獲率、成長速度等因素固定，以便讓生成差異維持在適合比較的範圍內。

維持視覺清晰度的約束。體型從縮小成角色圖後仍容易辨識輪廓的選項中挑選，顏色與特徵的詞彙也受到限制。排除類人特徵、血液、武器與文字。影像生成指令始終包含「只畫一隻生物」「呈現全身」「不要多餘肢體」等條件，以減少生成錯誤。

在一次有記錄的執行中，模型最初提出種族值總和為 380 的方案。驗證器發現違規並要求重新生成，最後得到總和 320 的規格。貢獻在於建立排除超出約束輸出的流程，而不是仰賴偶然成功的結果。

將體驗在遊戲內部完成

玩家只需要遊戲內的對話、詞語選擇與草叢遭遇，不必開啟另一個生成畫面。運算量大的工作由電腦上的 Python 程序執行，透過檔案與遊戲交換資料。mGBA 模擬器中的 Lua 腳本連接兩者，在 AI 處理留在遊戲外部的同時，維持熟悉的操作方式。

1. 生成規格。本機語言模型將六個詞語轉化為物種資料，驗證通過後才使用。
2. 生成視覺素材。影像模型先製作參考插畫，再生成視覺一致的正面與背面角色圖，以及隊伍圖示。
3. 轉換為遊戲資料。影像減色至 15 色，再轉換並壓縮為相容 Game Boy Advance（GBA）的角色圖與調色盤。
4. 整合至正在執行的遊戲。資料寫入預留區域，無須重新啟動遊戲，即可加入新物種。

相同資料也會寫入磁碟，因此重新載入遊戲後，生成物種仍會保留。生成只發生一次，而且無法撤銷。玩家逃跑或戰敗時，寶可夢仍留在世界中；若玩家擊敗牠，牠就不再出現。這種不可逆性，讓「這次遊玩只有一隻」成為體驗的一部分。

在原型中可以確認的事項

我獨立製作這個原型，以檢查技術可行性。它不是完整遊戲，也不是使用者研究。以下區分已驗證、已實作與尚未測試的範圍。

• 已驗證完整流程。我在 mGBA 中確認了遊戲內對話、六詞輸入、背景生成、整合至執行中的遊戲、野外遭遇、捕捉與暱稱輸入的完整流程。
• 已為未來比較實作。我加入兩種入口：無須輸入的被動生成，以及透過詞語選擇引導的生成。對話、遭遇與捕捉都可記錄，供後續比較。
• 已連接既有系統，但尚未長時間遊玩測試。捕捉後升級、學習招式、對戰、存入盒子與存檔後繼續使用，都已整合至既有遊戲系統；但我尚未在長時間遊玩中測試這些功能。
• 後續工作。遊戲中即時生成進化型態的功能尚未實作，也尚未進行多位參與者的情感依附比較研究。

遊玩心得：獨一無二，並未讓我自然產生依附

親自遊玩原型後，我對生成的寶可夢並沒有很強的情感依附。這是我身為開發者的個人感受，不能推廣到其他玩家。不過，它提供了未來比較中值得改變的條件。

有兩個因素值得進一步研究。

• 輸出品質。若外觀與角色設定不夠有吸引力，僅憑「這次遊玩中唯一的一隻」，可能不足以維持情感依附。
• 參與深度。只選擇六個詞語，讓我覺得成果比較像是別人交付給我的，而非我親手創造的。我推測參與感取決於創作過程的品質，例如重新考慮選擇、比較方案、修改細節，以及對結果負責，而非單純增加輸入量。

相比之下，我對 Hanagitsune（花狐狸）很有感情。這個角色是在遊戲自動生成流程之外，經過與多個生成式 AI 工具反覆對話及手動修整而創作的。我比較候選方案、修正細節，持續調整直到滿意。我認為成果品質與反覆創作過程中的投入，都有助於形成這份情感。

這個原型並未回答生成內容是否會產生情感依附，而是將這個廣泛問題轉化為兩個可刻意調整的因素：輸出品質與參與深度。未來研究會在創作中增加選擇、比較與修改的機會，讓輸出達到一致的品質，再比較多位參與者的體驗。

實作

生成管線、限制與驗證框架、針對 GBA 的資料轉換、遊戲端的變更內容，都在 GitHub 儲存庫 公開。