《代號-奧羅拉島》 開發(fā)日志 01 技術(shù)選型和基于組件開發(fā)的游戲框架搭建
項目簡介
《奧羅拉島》是我今年開始嘗試制作的獨立游戲檐束。因為我意識到自己很難獨立完成游戲的制作较解，所以我嘗試尋求組隊撩嚼。幸運的是我在B站找到了網(wǎng)友可可捆憎，并且在和她簡單討論之后，確定了項目的大方向“女性向的模擬經(jīng)營養(yǎng)成游戲”迟隅。
我們首先談到的游戲就是《星露谷物語》但骨，但我們希望在其基礎(chǔ)上弱化種田相關(guān)的gameplay，因此我們將主角設(shè)定為一個經(jīng)營著一家甜品店的小姑娘智袭，而其他的一切設(shè)定都是圍繞著甜品的制作和銷售（當(dāng)然奔缠，也少不了可攻略的NPC，這是后話）
由于游戲定位是女性向吼野，因此我盡可能的讓可可同學(xué)來負(fù)責(zé)游戲的美術(shù)風(fēng)格以及很多細(xì)節(jié)的策劃（真不是因為我懶）校哎。
當(dāng)然，在開始合作的首周，我們遭遇了很多困難闷哆，這其中包括對于一些工具的使用腰奋，如果大家感興趣，我會在后續(xù)的開發(fā)日志中和大家更詳細(xì)的聊到阳准。
技術(shù)方案選型
最近我對godot很有好感氛堕，因此這款游戲我們嘗試使用godot開發(fā)。并且一邊開發(fā)一邊等待godot4的發(fā)布
因為涉及到線上協(xié)作野蝇，因此我們選擇了git作為版本控制工具讼稚，代碼托管在國內(nèi)的gitee上（是私有倉庫）。
godot對于tilemap的支持十分有限绕沈，因此我選擇使用tiled作為tilemap的制作工具锐想，因此造成了一些麻煩。這里按下不表乍狐。
當(dāng)然赠摇，對于godot，可以聊的很多浅蚪，包括一些插件的選擇：
首先強推的便是 dialogic這款對話插件藕帜，盡管目前還沒有投入使用，但我早已經(jīng)對其躍躍欲試惜傲。
其次便是狀態(tài)機洽故、行為樹相關(guān)的插件，因為狀態(tài)機較為簡單盗誊，因此我選擇自己實現(xiàn)时甚。
在代碼框架方面，我選擇嘗試用基于組件系統(tǒng)的方式開發(fā)哈踱。這也是這篇開發(fā)日志的重點荒适。
當(dāng)前項目進(jìn)度
在過去的一個月里，我在逐步熟悉godot引擎开镣，是的我在春節(jié)期間就在思考利用godot做點什么刀诬。
在確定了最初的游戲大方向的設(shè)定后我和可可就開始分頭行動了。她開始設(shè)計整個島嶼的布局以及角色邪财，而我則開始制定開發(fā)框架舅列，并開始制作道具系統(tǒng)。
我已經(jīng)接觸過很多優(yōu)秀的游戲引擎和開發(fā)框架卧蜓，比如UE4官方提供的gameplay框架或者unity3D很多優(yōu)秀的第三方框架插件
也許是因為我本身是游戲策劃的緣故，因此我再一開始便思考怎么在做游戲的過程中分離出自己的框架把敞。
當(dāng)然弥奸，脫離業(yè)務(wù)邏輯的框架聽起來就像空中樓閣，因此這個框架我會在之后隨著業(yè)務(wù)邏輯的編寫而持續(xù)優(yōu)化迭代奋早。
幾年前我曾經(jīng)寫過《核心機制設(shè)計》盛霎，這次算是利用godot實踐一遍赠橙，真正做到：理論結(jié)合實際。
近期項目規(guī)劃
在制定好開發(fā)框架后愤炸，道具系統(tǒng)的實現(xiàn)比我預(yù)想的順利很多期揪，這里不介紹具體的開發(fā)細(xì)節(jié)，后續(xù)等整個系統(tǒng)開發(fā)完成我會單獨出一期開發(fā)日志回顧整個過程规个。
我去年在用ue4制作《老李教你穿裝備》系列教程時候就說凤薛，背包系統(tǒng)本質(zhì)上就是維護(hù)一個道具的列表或字典，實現(xiàn)對道具的增刪改查方法诞仓。
待到道具系統(tǒng)制作完成后缤苫，便會開始制作游戲的核心系統(tǒng)——甜品制作，這部分我目前還不知道是什么樣的形式墅拭，要找機會跟可可問清楚活玲。
開發(fā)日志應(yīng)該不會更新十分頻繁，也會穿插分享一些我認(rèn)為不錯的教程和經(jīng)驗谍婉。
后續(xù)還有一些更大膽的想法舒憾，目前還比較模糊，在之后有了更具體的設(shè)計方案再和大家分享穗熬。
簡單的游戲框架
這是最讓我興奮地部分镀迂，作為一個獨立游戲開發(fā)者，在制作游戲前死陆，我首先想到的是對于游戲框架的搭建招拙。
這樣做的核心訴求在于我對于獨立游戲的理解，我認(rèn)為不同于重度的商業(yè)游戲措译，獨立游戲應(yīng)該更短平快别凤，因此我不想再制作下一款游戲時完全重新開始。那么搞清楚哪些東西是可以復(fù)用的就顯得十分關(guān)鍵领虹，而這部分便成為了“框架”规哪。
得益于godot對于單例模式的支持，我抽象出一個Qinstance作為整個游戲的全局框架類塌衰，這個類中維護(hù)著很多有用的manager诉稍，這是典型的manager of managers 模型。
盡管 MOMS 模式遠(yuǎn)遠(yuǎn)談不上優(yōu)雅高級最疆，但好在簡單高效杯巨。
那么，我選擇了哪些manager努酸？
這部分我參考了UE4的Gameplay框架（不可否認(rèn)的是我們都沒辦法擺脫路徑依賴）服爷，我在Qintance中注冊了當(dāng)前的player_character、player_controller和current_ui_form、current_scene等對象的引用仍源，方便在任何地方可以調(diào)用
當(dāng)然心褐，一些經(jīng)典的管理類包括entity_manager、UI_manager 和 datatable_manager等笼踩，也許后續(xù)還會拓展出net_manager以及其他的逗爹。
當(dāng)我以為自己要設(shè)計很多manager時候，我驚奇的發(fā)現(xiàn)事實上godot提供了很多現(xiàn)成的管理類以及設(shè)計模式嚎于，這個我們之后再聊掘而。
當(dāng)這一切完成開始編輯業(yè)務(wù)邏輯時候，便會發(fā)現(xiàn)很多工作簡單多了匾旭。
基于實體組件系統(tǒng)的實現(xiàn)原型
也許你注意到了entity_manager镣屹，這用來管理游戲中所有的entity。
entity是我對于游戲內(nèi)所有對象的交互价涝，可以理解為UE4中的actor
我創(chuàng)建了entity_base腳本女蜈，繼承自node節(jié)點，因此與ue4中的actor有些不同色瘩，entity不包含坐標(biāo)transform信息伪窖。
在最開始我打算將邏輯和表現(xiàn)完全分開。
這部分我參考了《饑荒》的lua腳本居兆。
我開始的構(gòu)想是entity_base和component_base 腳本（兩者都繼承自node）實現(xiàn)最簡單的組件模式覆山。
在繼承component_base的腳本中實現(xiàn)各種邏輯，并使用godot的signal 信號機制實現(xiàn)邏輯的回調(diào)泥栖。
在各種繼承entity_base的entity實體中簇宽，組合這些組件，并根據(jù)自身特性處理組件的回調(diào)函數(shù)吧享。
而邏輯與表現(xiàn)的結(jié)合便是在entity中持有對 邏輯 prefab的引用魏割。
當(dāng)然，作為邏輯層的entity和component全部是運行時動態(tài)增刪的钢颂。
這在邏輯上可行钞它，但我最終沒有采取這樣的辦法。主要原因是我不清楚這樣做的性能如何殊鞭。
我最終采取的是更折中的方式：
我將邏輯和表現(xiàn)層作為一整個scene遭垛，其中表現(xiàn)層作為邏輯層的子節(jié)點樹，取名為inst操灿，但同時也可以手動指定表現(xiàn)層锯仪。
這樣更符合godot引擎整體的設(shè)計。
可能有同學(xué)會疑問為什么不用godot現(xiàn)有的node的設(shè)計趾盐，通過自定義node實現(xiàn)類似component的方式庶喜。
這首先基于解耦的原則幌蚊，我希望邏輯層的代碼盡可能不依賴于引擎，這部分設(shè)計我參考了unity3D中一個著名的框架entitias（同時溃卡，這是一個ECS實現(xiàn)）
另一個原因就是基于面向?qū)ο蟆odot的節(jié)點有一些限制蜒简，比如可移動的對象的根節(jié)點要求是kinematicbody2d的瘸羡，而一些其他的對象則可以使Node2D，這讓我在指定類型時遇到了一些麻煩搓茬。
但現(xiàn)在我將node作為所有entity的基類和根節(jié)點犹赖，并且抽象出entity_base這個類用來管理維護(hù)所有的component和運行時的增刪改查。
簡單來說卷仑，一切都可以由我自己掌握了峻村，這能減少很多由于對游戲引擎不了解導(dǎo)致的焦慮。
實用的游戲管理狀態(tài)機
最后锡凝，我想分享的是一個用來管理全局游戲狀態(tài)的狀態(tài)機粘昨，我稱其為procedure_manager
狀態(tài)機常被用來處理很多基于狀態(tài)的邏輯，特別是處理一些簡單的AI問題窜锯。
但我這里要講的是另一種對于游戲全局狀態(tài)的管理辦法张肾，這個辦法來自于Unity3D引擎一個著名的游戲框架Gameframework（是的，就叫這個名字）感興趣的同學(xué)可以了解一下锚扎，同樣是采用了manager of managers 的方式吞瞪，并且其中讓我印象最深刻的就是這個流程管理器。
和其他manager不同的是驾孔，我將 procedure_manager 做成了一個 scene 并放在游戲 main場景下芍秆。在procedure_manager 的 ready 方法中，它會將自己注冊在 qinstance 單例中翠勉。
這樣做的好處是妖啥，不破壞godot單獨場景可運行的原則。假設(shè)一種場景：
我們游戲會從main場景運行眉菱，然后根據(jù)procedure 加載資源迹栓、讀取配置、然后進(jìn)入開始界面俭缓、加載游戲或者新建游戲克伊。調(diào)試期可以很方便地改變狀態(tài)機來跳過某個流程。
但有時候我們要測試某個單獨的系統(tǒng)华坦，比如某個item_tile的顯示是否正常愿吹，player_character 能否正常移動，這些可以在 單獨的場景中完成的測試惜姐，不應(yīng)該受到流程管理器的影響犁跪。
如果你還沒有接觸過procedure_manager ,我強烈建議在你的下一款游戲中采用這樣的設(shè)計椿息。你會更清楚這樣做的優(yōu)缺點。
寫在最后
以上便是《代號-奧羅拉島》這款游戲的第一期開發(fā)日志坷衍，希望你能喜歡這種形式寝优。
我是老李，一個想在今年制作出第一款獨立游戲的游戲人枫耳。
我們下期開發(fā)日志乏矾，再見！
