- 文章
- 命令列是糟糕的遊戲開發介質
2010年9月14日 (最後更新: 2010年9月14日)
命令列是糟糕的遊戲開發介質
評分: 4.1/5 (384 票)
在這些論壇上，我經常看到人們詢問如何在命令列中製作遊戲，或者詢問如何在命令列中完成與遊戲製作相關的特定任務。例如清屏、移動游標、更改字型顏色、讓程式“在後臺”執行而不等待使用者輸入等等。
底線是，命令列並非為這類事物設計，您不應該將它用於這些型別的程式。
您可以讓它工作，但最終結果在很多方面都會很糟糕
- 您將不得不編寫 hacky 程式碼，將控制檯 I/O 從其正常功能扭曲成您想要的功能。
- 您必須妥協您的目標，以適應命令列的侷限性。
- 您的程式將無法像其他方式那樣打磨。
- 它將比替代方案困難得多。
我寫這篇文章是為了說服人們在開始製作簡單遊戲時遠離命令列。
在本文中，我將使用 SFML 作為示例（獲取地址：http://www.sfml-dev.org）。我喜歡 SFML，因為它對我來說特別對初學者友好，而且速度非常快，文件齊全，跨平臺，擁有活躍的使用者群，並且正在積極開發中。然而，它並非您的唯一選擇。還有其他庫可用，例如 Allegro 或 SDL。
如果您對遊戲開發感興趣，我建議您獲取 SFML 並開始嘗試。您可能需要一些折騰來安裝和設定它，但這是一個一次性的過程。一旦您掌握了它，您就不必再重複了，並且能夠輕鬆地製作未來的遊戲。這是一個小小的代價。
而且因為對我來說更有趣…我將以問答的形式寫這篇文章！
問）但是圖形很複雜。對於初學者來說，命令列難道不更簡單嗎？
第一個說法是謬論。不，您會驚訝於簡單的圖形庫有多麼容易。有了正確的庫，繪製圖像就像這樣簡單
圖形的難度被嚴重高估了。
問）但是，先從命令列開始，然後將所學的知識應用到圖形上，難道不是更好嗎？
不是。
命令列開發和遊戲開發是完全不同的世界，擁有完全不同的風格。
透過先進行命令列開發，您唯一能學到的是語言基礎知識（什麼是變數、什麼是類、C++ 的規則等）。但這些基礎知識任何目標介質都可以輕鬆學習。命令列只是人們最常接觸到的，因為它也是標準庫唯一支援的。
您從命令列學到的其他東西（如何構建程式流程、如何輪詢和獲取使用者輸入、如何向用戶顯示內容）在遊戲領域幾乎沒有應用。遊戲必須以完全不同的方式進行。您最終將不得不“忘記”命令列教給您的許多東西，並重新學習一種全新的做事方式。所以您最好不要浪費這個步驟。
問）但我不想使用圖形。我只想使用 ASCII 符號和一個簡單的網格風格地圖（用於製作 roguelike 或類似的東西）。命令列會不會更好？
可能不會。如果您使用文字來表示圖形可以表示的內容，那麼使用圖形可能更好（而且同樣容易）。
如果您真的不想使用圖形…例如，如果您喜歡 ASCII 風格…您可以使用圖形庫，然後只繪製 ASCII 符號作為圖形，這樣看起來就像您在列印文字，但實際上並不是。
這聽起來可能很愚蠢，但它提供了許多好處
- 遊戲庫在獲取使用者輸入方面有更合適的方法。
- 遊戲庫還有您可能想要的其他功能，例如背景音樂或音效。
- 遊戲庫沒有命令列相同的限制，例如可以顯示的顏色，以及遊戲執行的解析度。
問）但我只想做一個簡單的基於文字的冒險遊戲，您輸入“向東移動”之類的指令，它會列印描述。命令列會不會更好？
嗯，您可能不應該製作那種遊戲（參見下一個問題）。但是對於那種遊戲…是的。命令列可能會更簡單。只要
- 您確定您不想要任何伴隨圖形。請記住，您可能稍後會改變主意，想要在描述文字上方顯示當前位置的簡單圖片。
- 您不想要任何背景音樂 (BGM)
- 遊戲將等待使用者輸入（它不會“在後臺執行”）
問）你為什麼說我不應該製作基於文字的冒險遊戲？它們有什麼問題？
它們不容易製作。事實上，它們是你可能製作的最難的遊戲之一。
解析文字輸入並理解它的工作本身就很難。再加上基於文字的冒險遊戲中涉及的繁重事件和複雜性，您就得到了一個初學者可能無法處理的專案。
信不信由你，簡單的即時動作遊戲，帶動畫和圖形（例如簡單的 Galaga 或 Space Invaders 克隆），製作起來要容易得多。
初學者想嘗試基於文字的遊戲，因為他們認為它會更容易，因為他們認為圖形很困難。但他們錯了！
問）但我試過了，我不明白動畫，而且我知道如何做命令列。堅持我所知道的難道不是更好嗎？
那是因為您學習的是命令列程式設計而不是遊戲程式設計。請記住，它們是不同的世界，在一個領域有經驗並不一定能為您準備好另一個領域。
如果您已經固執己見，並且真的不想學習新東西，那就算了。做任何讓您覺得最有趣的事情。
但是，如果您發現自己問一些命令列不打算做的事情……請停止。與其學習錯誤的方法，為什麼不學習正確的方法呢？我是說，既然您總是在學習新東西……
總之，這就是我今天要說的。希望我能在出現類似情況的帖子中連結到此文。
底線是，命令列並非為這類事物設計，您不應該將它用於這些型別的程式。
您可以讓它工作，但最終結果在很多方面都會很糟糕
- 您將不得不編寫 hacky 程式碼，將控制檯 I/O 從其正常功能扭曲成您想要的功能。
- 您必須妥協您的目標，以適應命令列的侷限性。
- 您的程式將無法像其他方式那樣打磨。
- 它將比替代方案困難得多。
我寫這篇文章是為了說服人們在開始製作簡單遊戲時遠離命令列。
在本文中，我將使用 SFML 作為示例（獲取地址：http://www.sfml-dev.org）。我喜歡 SFML，因為它對我來說特別對初學者友好，而且速度非常快，文件齊全，跨平臺，擁有活躍的使用者群，並且正在積極開發中。然而，它並非您的唯一選擇。還有其他庫可用，例如 Allegro 或 SDL。
如果您對遊戲開發感興趣，我建議您獲取 SFML 並開始嘗試。您可能需要一些折騰來安裝和設定它，但這是一個一次性的過程。一旦您掌握了它，您就不必再重複了，並且能夠輕鬆地製作未來的遊戲。這是一個小小的代價。
而且因為對我來說更有趣…我將以問答的形式寫這篇文章！
問）但是圖形很複雜。對於初學者來說，命令列難道不更簡單嗎？
第一個說法是謬論。不，您會驚訝於簡單的圖形庫有多麼容易。有了正確的庫，繪製圖像就像這樣簡單
|
|
圖形的難度被嚴重高估了。
問）但是，先從命令列開始，然後將所學的知識應用到圖形上，難道不是更好嗎？
不是。
命令列開發和遊戲開發是完全不同的世界，擁有完全不同的風格。
透過先進行命令列開發，您唯一能學到的是語言基礎知識（什麼是變數、什麼是類、C++ 的規則等）。但這些基礎知識任何目標介質都可以輕鬆學習。命令列只是人們最常接觸到的，因為它也是標準庫唯一支援的。
您從命令列學到的其他東西（如何構建程式流程、如何輪詢和獲取使用者輸入、如何向用戶顯示內容）在遊戲領域幾乎沒有應用。遊戲必須以完全不同的方式進行。您最終將不得不“忘記”命令列教給您的許多東西，並重新學習一種全新的做事方式。所以您最好不要浪費這個步驟。
問）但我不想使用圖形。我只想使用 ASCII 符號和一個簡單的網格風格地圖（用於製作 roguelike 或類似的東西）。命令列會不會更好？
可能不會。如果您使用文字來表示圖形可以表示的內容，那麼使用圖形可能更好（而且同樣容易）。
如果您真的不想使用圖形…例如，如果您喜歡 ASCII 風格…您可以使用圖形庫，然後只繪製 ASCII 符號作為圖形，這樣看起來就像您在列印文字，但實際上並不是。
這聽起來可能很愚蠢，但它提供了許多好處
- 遊戲庫在獲取使用者輸入方面有更合適的方法。
- 遊戲庫還有您可能想要的其他功能，例如背景音樂或音效。
- 遊戲庫沒有命令列相同的限制，例如可以顯示的顏色，以及遊戲執行的解析度。
問）但我只想做一個簡單的基於文字的冒險遊戲，您輸入“向東移動”之類的指令，它會列印描述。命令列會不會更好？
嗯，您可能不應該製作那種遊戲（參見下一個問題）。但是對於那種遊戲…是的。命令列可能會更簡單。只要
- 您確定您不想要任何伴隨圖形。請記住，您可能稍後會改變主意，想要在描述文字上方顯示當前位置的簡單圖片。
- 您不想要任何背景音樂 (BGM)
- 遊戲將等待使用者輸入（它不會“在後臺執行”）
問）你為什麼說我不應該製作基於文字的冒險遊戲？它們有什麼問題？
它們不容易製作。事實上，它們是你可能製作的最難的遊戲之一。
解析文字輸入並理解它的工作本身就很難。再加上基於文字的冒險遊戲中涉及的繁重事件和複雜性，您就得到了一個初學者可能無法處理的專案。
信不信由你，簡單的即時動作遊戲，帶動畫和圖形（例如簡單的 Galaga 或 Space Invaders 克隆），製作起來要容易得多。
初學者想嘗試基於文字的遊戲，因為他們認為它會更容易，因為他們認為圖形很困難。但他們錯了！
問）但我試過了，我不明白動畫，而且我知道如何做命令列。堅持我所知道的難道不是更好嗎？
那是因為您學習的是命令列程式設計而不是遊戲程式設計。請記住，它們是不同的世界，在一個領域有經驗並不一定能為您準備好另一個領域。
如果您已經固執己見，並且真的不想學習新東西，那就算了。做任何讓您覺得最有趣的事情。
但是，如果您發現自己問一些命令列不打算做的事情……請停止。與其學習錯誤的方法，為什麼不學習正確的方法呢？我是說，既然您總是在學習新東西……
總之，這就是我今天要說的。希望我能在出現類似情況的帖子中連結到此文。