我應該首先在文字模式下發展我的遊戲理念嗎？

Question

我最近想出了一個模擬/策略遊戲的想法。我一直在紙上寫出很多關於遊戲機制的想法，以及一些基本類和對象的工作。 （我正在使用XNA在C＃中編寫此代碼）。

但有一件事對我來說顯然是很明顯的，那就是我不是一名圖形藝術家，現在試圖獲得任何圖形化程序令我感到沮喪。想到的一個想法是首先嚐試讓整個遊戲在文本控制檯上運行。我記得花了數百小時玩Zork和Hack，我的大部分遊戲元素想法都不需要實時精靈動畫。

所以我在這裏向社區提出的問題是，我應該試着保持對概念的熱情，重點是讓它僅僅在文本基模式下工作，然後重新組合，給它一個漂亮的圖形界面？

OR

滑車在同一時間我試圖衝出我的想法的圖形界面山？

在寫這個問題的過程中，我想我自己回答了這個問題，但我很想聽到人們的想法。

Answer 1

我覺得你有正確的想法根據你對遊戲的描述。如果你分開你的顧慮，那麼你可以首先實現很多業務邏輯。把它看作是一個MVC應用程序。你可以讓你的觀點稍後實施;只需提供一個與您的業務邏輯交互的圖層，即您的視圖可以使用的圖層。

通過這種方式，無論您的視圖是什麼（基於文本或圖形）。您只需將元數據傳遞給視圖，視圖將決定如何呈現它。

所以我會說你的想法很好。從業務邏輯和基於文本的視圖開始。通過這種方式，您可以充實概念和想法，並決定傳遞給視圖的數據類型。請記住一件事 - 您必須在極其小心在這個階段而不是讓假設有關視圖泄漏到您的業務層。所以你應該把你的業務層和相關接口編碼到視圖中，就好像你有不知道視圖將會是什麼樣子。我的意思是，由於你是從一個基於文本的界面開始的，因此不要做出與你的特定實現相關的編碼決定。

將所有內容充實完畢後，您就可以開始學習圖形並慢慢啓動圖形圖層。

當然，這種方法（MVC）可能不適用於所有情況，特別是當您的視圖對時間要求很高時。欲瞭解更多的信息，看看這些Stackoverflow的問題：

• Is the MVC design pattern used in commercial computer games。
• Best practices when Designing iPhone Game with MVC
• Game framework architecture - view components or MVC

我只是想明確的是，我不主張爲你的遊戲MVC模式 - 我只是想強調關注的分離，這樣很容易讓你在不做重大重構的情況下交換視圖。

Answer 2

如果我是你，我會先創建一個基於文本的命令行界面。然後，如果你決定製作一個真正的GUI，你可以讓GUI自動執行命令行遊戲，所以你不必編寫遊戲邏輯兩次。許多工具將使用這種方法。例如，有人會創建一個命令行碎片整理工具，然後有人會爲該工具創建一個GUI「包裝器」。 Sort of like what Nethack did.

Answer 3

製作一個用戶界面。保持圖形簡單（Paint）並關注可用性。然後以開源方式發佈你的遊戲，並且其他人將創建漂亮的圖形和酷炫的用戶界面。

Answer 4

我的建議：現在幾乎沒有軟件可以單手操作。

嘗試勾勒出您的想法，張貼在某個地方，找到更多有興趣的人，組裝一個組，並讓您的手變髒。

如果你的想法真的很好，你會發現更多的團隊成員可以填補你在其他領域缺乏專業知識的需求。

您可以嘗試在網絡上找人，開始像開源項目一樣，或者您可以嘗試找到投資者，這可以爲您的企業注入資金，並且您可以聘請專業人員。

Answer 5

遊戲是一個複雜的項目，可以分爲多個隔間。這些可能是實際的模塊（例如，GUI渲染器或通信管理器），或者它們可能更理論或邏輯，例如「遊戲設計」。

雖然所有這些部分一起工作（最好是協調一致）以展現真實的遊戲，但他們中的每一個人也都是獨立的。因此，將征服劃分爲一個很好的方向。如果您對自己的想法充滿信心，那麼請務必儘可能以最簡單的方式實施，這可能是一個控制檯應用程序。

但是，您確實需要記住，雖然您可以通過分別開發每個模塊來開始開始，但最終您需要考慮這些部件如何一起工作。這將固有地影響您的模塊設計。例如，您可能會發現您的遊戲邏輯運行的非常好，但您無法讓用戶真正按照UI進行某個步驟。可玩性是遊戲最重要的特徵之一，你的用戶界面甚至可能會決定一些遊戲邏輯。這個概念與用戶界面與邏輯分離的黃金法則相矛盾 - 但正如我所說的那樣，遊戲是複雜的，對於最終產品，你經常會發現自己正在彎曲一些規則。遊戲與其他項目不同 - 可擴展性不是問題。可維護性很重要，但如果您需要額外的CPU汁液，將會被犧牲......等等。