2. 關於策劃遊戲¶

上一課我們問了自己一些關於動機的問題。在這一期中我們將介紹一些需要考慮的更多技術問題。在下一課我們將回答這些問題我們的教學遊戲。

請注意，此頁面上的建議只是建議。此外，它們主要針對孤獨的人業餘愛好設計師或在空閒時間開發遊戲的小團隊。

Important

你的首要目標是克服困難並獲得一些東西！即使它是您夢想遊戲的縮小版，缺少許多“必備”功能！

請記住：99.99999% 出色的遊戲創意從未最終轉化為遊戲。尤其是不要上線人們可以真正玩和享受的遊戲。最好將您的遊戲推出並擴充套件它晚於孤立地編碼，直到你精疲力盡、失去興趣或硬碟崩潰。

縮小初始版本的範圍。太低了。
從小規模開始，在首次發布後著眼於稍後的擴充套件。
如果這裡的建議對您來說似乎很無聊或很麻煩，那就按照您的方式去做吧。每個人都不同。
繼續享受_樂趣_。無論哪種方式對你有效，你都必須保持動力。

2.1. 步驟¶

以下是實現您的目標的大致步驟。

規劃
編碼 + 逐步建立技術演示
建構真實的遊戲世界
發布
慶祝

2.2. 規劃¶

您至少需要對您想要建立的內容有一個粗略的瞭解。有些人喜歡做很多計劃，有些人喜歡採取更憑感覺行事的風格。無論如何，雖然做一些計劃總是好的，但這很常見當您建立程式碼原型時，您的計劃會發生變化。所以不要_太_陷入困境細節一目瞭然。

許多未來的遊戲開發者都非常擅長這個過程的“部分”，即定義他們的內容世界是「關於」：主題、世界觀、酷炫的怪物等等。這些事情非常重要。但是不幸的是，它們不足以製作你的遊戲。你需要弄清楚如何實現你的想法 Evennia。

以下是一些幫助您繼續前進的問題。在下一課中，我們將嘗試針對我們的具體情況回答這些問題教學遊戲。當然，您也可以問自己更多的問題。

2.2.1. 行政¶

你的遊戲規則應該由編碼系統還是人類遊戲大師來執行？
你的遊戲中的人員等級是怎樣的？普通的 Evennia 角色就夠了還是你還需要別的東西？
玩家是否應該能夠在頻道上或透過公告板等其他方式發布不符合角色的內容？

2.2.2. 大樓¶

世界將如何建構？傳統上（透過遊戲內的建置指令）或外部（透過batchcmds/code 或直接使用自訂程式碼）？
只有特權建造者才能創造東西，還是普通玩家也應該擁有有限的建造能力？

2.2.3. 系統¶

您的遊戲是基於現有的 RPG 系統還是自己建造？
遊戲機制是什麼？您如何決定某項操作是成功還是失敗？
時間的流動在你的遊戲中重要嗎──白天和黑夜會改變嗎？季節又如何呢？
您想要改變全球天氣還是應該在角色扮演中手動設定天氣？
您想要一個編碼的世界經濟還是隻是一個簡單的以物易物系統？還是根本沒有正規經濟？
你有聲譽、影響力這樣的概念嗎？
你的角色會透過他們的名字還是僅僅透過他們的外表而被認識？

2.2.4. 客房¶

簡單的房間描述是否足夠，或者描述是否應該能夠改變（例如隨著時間的推移，透過光照條件、天氣或季節）？
房間應該有不同的狀態嗎？它可以有氣味、聲音嗎？是否會受到影響戲劇性的天氣、火災還是魔法效果？如果是這樣，這會對房間裡的東西產生什麼影響？或者是這些事情是管理員/遊戲大師應該手動處理的嗎？
房間裡可以藏東西嗎？一個人可以躲在房間裡嗎？房間如何顯示這一點？

2.2.5. 物體/物品¶

你的對像有多少？你想要大量的戰利品清單還是隻是角色扮演道具按需建立？
如果您使用貨幣，每個硬幣是單獨的物件還是您只是儲存銀行帳戶價值？
多個相似的物件是否形成堆疊？在這種情況下如何處理這些堆疊？
物體有重量或體積嗎（所以你不能攜帶無限數量的物體）？
物體可以被破壞嗎？它們可以修復嗎？
你可以用椅子或花打架，還是必須使用特定的「武器」之類的東西？
角色能夠製作新物品嗎？
mobs/NPCs 應該有某種 AI 嗎？
NPCs 和生物是不同的實體嗎？它們有何不同？
應該有NPCs給予任務嗎？如果是這樣，您如何追蹤任務狀態？

2.2.6. 人物¶

玩家是否可以同時擁有多個活躍角色，或者是否允許他們進行多人遊戲？
角色生成是如何運作的？從一個房間走到另一個房間？選單？
如何實現不同的「階級」或「種族」？它們是不同型別的物件還是您只需根據玩家的需求在基本物件上載入不同的統計資料？
如果角色可以隱藏在房間裡，那麼什麼技能將決定他們是否被發現？
技能樹是什麼樣的？角色可以獲得經驗來提升嗎？透過殺戮敵人？解決任務？透過角色扮演？
玩家角色可以互相攻擊（PvP）嗎？
失敗的懲罰是什麼？永久死亡？快速重生？入獄時間？

MUD 的參與程度比你想像的要多得多，而且這些東西在一個複雜的網路中緊密相連。它很容易變得難以承受，並且很容易想要立即獲得“所有”功能。嘗試確定“製作”遊戲的基本要素，並“僅”首先關注它們釋放。列出一個清單。牢記未來的擴充套件但限制自己。

2.3. 編碼和技術演示¶

這是建立遊戲的“遊戲”部分的實際工作。當您編碼和測試系統時，您應該在此過程中建立一個小“技術演示”。

在進行技術演示展示所有部分之前，盡量避免瘋狂地建立一個巨大的遊戲世界您希望在遊戲的第一個版本中擁有。否則你將面臨必須重做一切的風險再次。

Evennia 努力讓你的程式設計變得更容易，但沒有辦法解決這樣的事實：如果你想要除了基本的聊天室之外，你將必須硬著頭皮編寫你的遊戲（或找到一個願意的編碼員）為你做）。

即使您不會自己編寫任何程式碼，作為設計師，您至少需要了解基本的 Evennia 的範例和元件。建議您閱讀本初學者教學的其餘部分來學習你有什麼可用的工具。

在編碼期間，您回顧一下您在規劃階段想要的東西，並嘗試實施它們。如果您發現事情比您想像的更容易/更困難，請不要羞於更新您的計劃。越早修改問題，解決它們就越容易。

一個好主意是使用_版本控制_線上託管您的程式碼。 Github.com 提供免費的私人儲存庫如今，如果你不想讓全世界知道你的秘密。不僅僅是版本控制讓您的團隊輕鬆協作，這也意味著您的工作始終得到備份。 [版本控制]頁(…/…/…/Coding/Version-Control.md) 將幫助您建立一個具有適當版本控制的健全的開發人員環境。

2.4. 世界大廈¶

到目前為止，我們的資料庫中只有一些技術演示物件。這一步的行為是用更大的主題世界填滿資料庫。太多潛在的開發人員跳入此領域階段太早（跳過編碼甚至規劃階段）。如果你建造的房間怎麼辦現在不包括程式碼增長支援的所有好天氣訊息嗎？或者你儲存的方式資料在幕後發生變化？您的建築工作最多需要一些返工，最糟的情況是您將不得不重做整個事情。如果你建造東西，你可能會做很多不必要的工作沒有先讓底層程式碼系統處於某種合理的形狀，就全部進行了。

因此，在開始建造之前，「遊戲」位元（編碼 + 測試）應該或多或少完整，至少達到初始版本的水平。

確保你自己和你最終的建造者都清楚你想要世界的哪些地方用於您的初始版本。為每個人確定您期望的風格、品質和細節程度。

你的目標不應該是一次完成你的整個世界。你想要的只是足夠的遊戲的「感覺」就出現了。您想要一個最小但功能正常的世界，其中預期的遊戲可以進行測試並大致平衡。您以後隨時可以新增區域。

在建置過程中，您可以對任何自訂建置指令和系統進行免費且廣泛的測試已經做到了這一點。如果建構者和編碼員是不同的人，那麼您也有機會聽聽是否有些事情難以理解或不直觀。確保回覆對此反饋。

2.5. 阿爾法版本¶

如前所述，除非必要，不要過度執著於你的世界。 用巨大的阿爾法把它拿出來 標記並讓人們嘗試！

號召你的阿爾法玩家嘗試一切 - 他們會找到方法來破壞你的遊戲你絕對無法想像。在阿爾法你可能最好去專注於邀請朋友，或許還有其他 MUD 開發者，你可以纏著他們給予適當的幫助回饋和錯誤報告（肯定會有錯誤，沒有辦法解決）。

按照線上設定的快速說明進行操作遊戲線上可見。

如果您還沒有，請確保將您的遊戲釋出到 Evennia 遊戲索引所以人們知道它正在開發中（實際上，甚至索引中允許預阿爾法遊戲，所以不要害羞）！

2.6. 測試版發布/永久測試版¶

一旦 Alpha 階段的情況穩定下來，您就可以轉向 Beta 並讓更多的人加入。許多 MUDs 都在永久測試版，這意味著它們從未被考慮過 “完成”，但只是一遍又一遍地重複規劃、編碼、測試和構建的迴圈功能實現或玩家提出建議。身為遊戲設計師，現在由你決定逐步完善你的願景。

2.7. 恭喜你自己！¶

你值得慶祝，因為此時你已經加入了一小群獨特的人群讓他們的夢想遊戲成為現實！

2.8. 規劃我們的教學遊戲¶

在下一課中，我們將利用這些一般要點並嘗試規劃我們的教學遊戲。