做獨遊真的很簡單 | 論如何在兩個月內從零開始上架一款steam遊戲

這篇文章獻給那些想做遊戲但是瞻前顧後、一直猶豫不決遲遲不敢動手的朋友們，願你們能夠放下無謂的自尊和完美主義，享受粗糙、野蠻、笨拙但實用的開發技巧！

隨性而來的嘗試

故事的開始是在4月份，那個時候我跟另外一名獨立遊戲開發者閒聊，聊到引擎的使用，他說想試試Godot，彼時的我還掙扎在《深淵謎影》跟《傳教模擬器》的開發上，並沒有認真思考過這個事情，但是那段對話已經在我心裏埋下了開新坑的種子。

5月份，因爲以上兩個項目中的開發者都有事無法推進，我反而稍微閒下來一些，順便說一下，《深淵謎影》的程序是研究生，要忙畢設，《傳教模擬器》的程序是高中生，要忙高考。我突然就回憶起那次對話，於是冒出來個想法：“要不要乾脆就用Godot做一款新遊戲吧！”

於是5月6號，我開始學習Godot引擎，5月7號開始立項《育苗師》。

說幹就幹

考慮到這個項目的立項初衷是學習Godot，所以做的遊戲不應包含複雜玩法。人性是“欺軟怕硬”的，對問題也一樣，我們害怕處理複雜問題，但是熱衷於解決簡單的小問題，把這個思路放在遊戲設計裏，就要求我們不要在能力不足的情況下開發高難度大體量的遊戲，否則會極大地消磨創作熱情。

於是，我思考了一下玩法簡單的遊戲類型，最終決定做一款掛機遊戲。這類遊戲交互有限，不需要複雜的場景和關卡，沒有敵人和狀態機，甚至不需要像文字冒險那樣寫個百八十萬字，真的是初學者的理想遊戲類型了。

因此，我用一天的時間寫好了基礎的策劃案並製作了原型圖，腦海中的玩法循環跑通後，接下來就是上手在引擎中逐步實現功能了。

不需要複雜的功能，所以案子很簡單

甚至也沒多少界面

引擎的使用

開發一款遊戲簡單來說就那麼幾步：

1、有一個想法
2、把想法整理成設計案
3、準備美術資產
4、功能開發
5、跑測
6、上架
7、運營

再次重申，因爲這個立項的初衷是爲了學習Godot，所以我的主要注意力會放在功能開發上，因此美術資產就沒必要浪費自己的時間精力進行繪製，所以我找了一位美術爸爸幫我出圖@又三（大家可以在小紅書找到他）。

在沒有美術資產的時候，我們怎麼辦呢？難道要一直等到美術提交了素材纔開始功能的開發嗎？當然不是！

只要隨隨便便搞一些臨時素材，就可以進行功能的開發了，等功能沒問題美術資產就位後再進行替換即可，所以美術和程序這兩條腿是可以並行的。

故事的開始是一個盆栽

我的第一步是在引擎中製作一個能夠裝下一個植物並且顯示生長進度的花盆。這裏涉及到了Controller、TextureRect、ProgressBar、Label這幾個節點。在Godot中，所有的遊戲內組件都是以節點進行拼接的，類似Unity的Component，Godot貼心的給不同的節點類型標上不同的顏色和圖標，非常直觀。

像我這樣的掛機遊戲，因爲不涉及到複雜功能，玩家幾乎就是純玩UI，所以我的節點也相當純粹，幾乎只有綠色的Controller類型和子類。（大家如果看過其他Godot開發者的項目，能發現花花綠綠形形色色的節點）

只有綠色也能做遊戲！

當我有了一個小花盆，我就可以複製（生成實例）更多的花盆到主場景裏，這樣做的好處是，只要更改原視小花盆（父類）的狀態，所有其他的小花盆（子類）都可以隨之變更，當我想新增小花盆的功能時，就會提升很多的效率。

初具人形（bu

隨後我加上了計時器和退出遊戲的按鈕。到這一步，我學會了Timer和Button的使用，學會了把節點實例化。

因爲沒有正兒八經學過程序（看過一丟丟Py和Js），我的代碼主要還是由AI幫我寫的，我使用了文心一言和Deepseek，後來才發現Godot有Gemini插件。起初，我以爲靠AI的幫助，做這個小玩法應該問題不大，但很快我就意識到，我低估了掛機遊戲的實現難度。

最大的挑戰在於，AI無法在大量對話後準確記錄之前說過的方案，很可能在幾十次對話後逐漸忘記之前自己設置的變量、實現的邏輯，轉而用新的方案實現同樣的功能。這個時候如果直接貼代碼，就必然會報錯，所以爲了更長久的穩定性，我還是決定自己學一下gdscript。

課程是在B站上隨便搜的，《Godot100集教程》Up主有口音，但是整體來說不影響觀感，其中對於信號的部分講解跟最新的Godot4版本好像有些出入，大家自己判斷一下。

用二倍速迅速過了一下我需要的板塊，隨後我就開始重新寫遊戲腳本了，這樣主動權在自己，AI負責提供細分功能的實現邏輯，我再去根據實際情況決定採納還是調整。就這樣，5月10號的時候，我開始了現有代碼的重構，把已有的邏輯用自己的方式重新寫了一遍，大大提升了自己對gdscript的理解。

到5月13號的時候，基本的點擊種子選擇、隨時間積累進度、不同進度切換圖片這些功能就都差不多了。

是陽光，我使用了陽光！

爲了進一步測試不同類型種子的不同生長階段，我一晚上準備了全部135個作物的臨時素材，那個時候想的是先把引用邏輯都寫好，以後可以直接替換素材了，所以吭喫癟肚畫圖寫邏輯，完全沒想到就在半個月後，我學會了使用Luban進行轉表，之前的圖片引用邏輯全部白寫了……

所有類型作物的美術臨時素材

代碼並沒有想象中那麼難

在大致掌握了gdscript的情況下，其實主要就是知道一些執行順序啦，生命週期啦，常見的邏輯判定啦，條件判定啦，就夠用了。

知道_ready()裏放一些初始化的東西（不用_init()也沒關係），知道_process()裏是每幀執行的動作，知道==是等於，!=是不等於，知道String、int、float之類的數據類型，其實到這裏爲止已經可以完成非常多的基礎功能了。

那個時候我還不知道Autoload可以自動加載一些全局性的腳本，所以有些跨場景的功能就死活都實現不了，但是問問AI其實也就都知道了，包括讓我非常頭大的Signal傳遞，其實也有很多替代方案。

回想一下我曾經對程序的印象是：可以用優雅的代碼實現複雜的功能。所以認爲學不會那些漂亮高效的實現邏輯就等於不會程序。

但是事實上，我們這些小卡拉米做一些簡單的功能壓根用不上那些高級的語法和代碼優化，我在剛開始寫代碼的時候，判斷全部用if else，特別蠢，但是不會因此卡進度。

請叫我elif的神

你能想象到我敲了幾百條elif嗎？讓那些編程的大佬看到可能會笑我一年吧，但是隻要程序能跑，玩家纔不care你的實現邏輯是不是優美是不是簡潔，所以代碼羞恥這種東西，我們一定一定要摒棄掉。

不管多蠢的實現邏輯，只要能跑，就是勝利！！！

包括如果不會用程序生成節點，那就在編輯器裏手動創建，笨一點、效率低一點都沒有關係，能滿足需求就行了，等我們過十天半個月再回頭看，可能就知道如何用更高效的方式實現同樣的功能了，到那個時候，再優化也不遲。

慢慢就會更多的東西了

比如關於郵件的生成，這部分的腳本相比我剛開始學代碼就“高級"很多，我知道如何用代碼生成一個新的節點、如何設置節點的屬性（大小、位置、顏色、主題）、如何接收信號，如果這些東西不用程序進行生成，那我們就老老實實在檢查器裏添加就好了。

再一點是，新手程序很容易遇到各種bug但是不知道怎麼修，或者更絕望一些，不知道是哪裏出了問題，也不會打斷點。這個時候就直接祭出大殺器：print()。

不知道哪裏出了問題，print就對了

只要不嫌麻煩，每一句代碼中間都print就對了，看着自己的log可以非常直觀地感受到進度在哪裏，是不是符合預期。如果你這麼做了，恭喜你，你掌握了小黃鴨調試法。

Godot的log輸出面板很好用，包括棧追蹤、顯存查看、調試器等，一開始不會看沒關係，給自己一些時間，每天多熟悉熟悉，很快就掌握了。

調試器真的很好用

對於腳本的學習，我就一句話:

瞎JB寫，能跑就行，蠢一點也沒關係，沒人會笑話你！

轉表工具提效

程序的基礎框架差不多之後，我面臨一個內容完善的問題。因爲我的遊戲有劇情，雖然不多，但是也涉及到幾千字的文本。

因爲我之前是正兒八經幹過策劃的，所以我知道常用的辦法就是設計配置表，通過轉表導入數據到引擎中。給沒有這方面經驗的朋友簡單介紹一下配表的實現邏輯：

先說問題吧，雖然所有的引擎都有地方讓使用者手動輸入文本，但通過這種方式無疑是低效且高風險的。萬一之後改劇情了，就需要在引擎中找到對應的節點然後修改，特別麻煩。

就像這樣

那麼通過配置表的思路是如何實現的呢？

首先我需要設計一張Excel表格，把我可能用到的文本都放進去，比如郵件表我就需要郵件id、郵件名稱、郵件內容。如果涉及到本地化處理，還可以把其他語言的文本也貼進去。

注意看前兩行的字段

之後通過轉表工具將Excel表格的內容轉化成可以被引擎識別的格式，比如轉成csv或者我這裏用到的json。轉表工具我使用的是Luban，官網在這裏大家可以自行去看介紹 | Luban，如果是大廠的話會有自己的定製化轉表工具，這裏不展開了。

轉表之後的數據，看起來像這樣：

excel表的字段變成了參數名

這樣一來我就可以在腳本中通過調用mail_id, name, content等字段快速查找並引用相關的數據，不論是郵件功能，還是RPG遊戲更常見的對話功能，其實都是這麼處理的。在配置表中寫好說話的NPC、對話內容、對話獎勵等等，好的策劃是可以合理設計配置表，以方便程序之後進行簡單的數據引用的。

《本草計劃》我一共設計了3張表，分別是《任務表》、《郵件表》和《作物表》，實際上游戲內引用到的只有後兩張表，對於一個大型商業項目，涉及到的配置表是可以輕鬆突破上千張的。

美術資源合入

隨着功能的開發，又三老師基本按照每週一到兩次的頻率提交美術素材，像剛纔說的，我使用了配置表進行數據導入後，只需要在《作物表》中替換美術素材的路徑即可實現遊戲內的動態調整，非常的方便。

把資源路徑填進來就可以了

因爲預期的開發週期是兩個月，我跟又三老師商量了一下美術的製作週期，原本是要給每個作物畫3張圖的，但是那樣一來開發週期會延後許多，不符合我的期望，因此我們把每個作物的圖片刪減爲兩張，到六月中下旬剛好畫完。

每波10個作物

原本想着又三老師提交的圖是按照作物類型進行區分的，但由於我沒有給美術風格做任何的限制，這導致了一個問題是：美術的圖片非常漂亮，但是不符合遊戲框架下的類型。

在原本的設計中，有一個作物的類型叫“藤蔓類”，我設想的都是細細長長的那種扭曲作物，但是隨着美術資源的提交，符合這種形態的作物少之又少。

這個時候有兩種辦法，一種是讓美術爸爸按照既定的分類重新畫，另一種是策劃調整作物類型的設計。由於這個項目的初衷是學習Godot，所以調整美術資產是完全沒有必要的，更聰明的做法是由我這邊調節作物的分類以適應美術資產。

因此作物類型從“藤蔓類”變成“樹藤類”，可以更多地兼顧又三老師提交的另外一種難以分類的作物。當然，這樣做也導致我不得不把所有的作物全部重新分類整理一遍，增加了海量的額外工作，有利有弊吧。

重新排一遍累死我了

準備上架Steam

當功能基本完成，美術資產也基本就位後，就可以準備Steam的上架了。

我這邊由於有過上架的經驗，所以深知Steam商店也是一個需要大量時間精力進行準備的東西。我在5月31號就已經開始着手steam商店頁的素材準備了，那個時候功能也沒做完、美術資產也沒做完，但是審覈需要時間，所以我直接用臨時素材搞了一套丟上去。

這部分多提交幾次就熟練了

準備好商店頁需要的形象圖、宣傳圖、小宣傳圖、庫資產圖標、社區圖標等，然後準備5張截圖和1個宣傳視頻，就可以提審商店頁了。

這是臨時宣傳圖

商店頁的審覈一般需要3-5天，雖然我已經很熟悉流程了，但還是無法保證可以一次性通過，因此一定要預留足夠多的時間，爲什麼？因爲遊戲想上架需要商店頁開通至少2星期。也就是說如果我希望6月底上架，那麼6月中旬商店頁一定要開，這也是爲什麼我5月底就開始準備商店頁的素材提審了。

只要審覈通過，那麼之後再次替換新的素材就無需重新審覈，所以我在6月底替換新素材的時候就非常舒服。

風格180°大轉變

同理還有遊戲包的審覈，先準備一個能跑的包提交上去進行審覈，即便裏邊很多東西還不夠完善。包體的審覈比商店頁還要慢，並且這裏新踩了一個坑是：如果你在商店頁勾選了遊戲支持雲存檔和成就，那麼提交的包體必須具備這些功能，否則審覈會失敗。好的做法是，先不勾選這些額外的功能，等包體審覈通過之後再加，這樣不會耽誤時間。

我是6月12號開通的商店頁，那個時候都是臨時素材，但這個時候已經可以進行很多後續的宣發工作了。