寫在前面
首先是日常招募擅長像素藝術(shù)，對主視角模擬經(jīng)營游戲感興趣的小伙伴組隊(duì)。
目前正在等待godot4早日發(fā)布。
最近閱讀了godot官方文檔：最佳實(shí)踐，磨刀不誤砍柴工，在后續(xù)開發(fā)中可以避免許多坑。
團(tuán)隊(duì)成員變動(dòng)
目前我主要負(fù)責(zé)功能實(shí)現(xiàn)和系統(tǒng)文檔審核。
最近新加入一個(gè)策劃伙伴，幫我補(bǔ)充了部分系統(tǒng)的文檔。
之前的美術(shù)伙伴很久沒消息了。
目前依然長期招募能負(fù)責(zé)美術(shù)方面的伙伴。
目前也需要對topdown感興趣，熟悉tilemap可以負(fù)責(zé)游戲關(guān)卡設(shè)計(jì)和制作的小伙伴。
游戲設(shè)計(jì)相關(guān)
方向性設(shè)計(jì)
目前已經(jīng)確定的設(shè)計(jì)：游戲?yàn)榕灾鹘?，主要面向女性玩家。玩家?jīng)營一家甜品店，并努力和小鎮(zhèn)居民搞好關(guān)系。在和居民們的相處中解鎖更多甜品配方和背后的故事。
與常規(guī)牧場經(jīng)營類游戲的主要區(qū)別在于經(jīng)營的目標(biāo)從 農(nóng)作物 變?yōu)?甜品（這似乎是一句廢話），因此帶來的核心玩法的改變：玩家扮演的主人公需要收集訂單、想辦法獲得各類食材制作出某種甜品，送到指定的位置，從而改變NPC的行為和劇情走向。
游戲賣點(diǎn)
- 圍繞女主性格成長（記憶找回）的主線劇情
- 程序生成敘事的支線劇情
- 更活潑的NPC
- 重復(fù)可玩性：帶有隨機(jī)性的情報(bào)系統(tǒng)（目前可透露的不多）
烹飪系統(tǒng)設(shè)計(jì)
烹飪系統(tǒng)作為整個(gè)游戲的玩法核心，我對其的設(shè)計(jì)理念反而非常“簡單”。我希望烹飪本身是簡單高效的。而復(fù)雜的部分在于主角領(lǐng)取訂單、收集食材到最終送貨上門這整個(gè)流程閉環(huán)。因此對于烹飪系統(tǒng)，我追求的簡單步驟就是：
- 放入食材
- 點(diǎn)擊烹飪
- 烹飪進(jìn)度條
- 食材消失，食物出現(xiàn)
- 取走食物
當(dāng)然，你可能注意到烹飪按鈕旁的食譜按鈕，這其實(shí)是一種快捷方式，對于玩家反復(fù)烹飪達(dá)到一定次數(shù)的食譜配方，可以一鍵快捷添加食材。但這是后話了。
基于資源Resource 的組件系統(tǒng)重構(gòu)
因?yàn)榭戳薵odot官網(wǎng)提供的最佳事件，我開始考慮 使用node 來實(shí)現(xiàn)組件的必要性。組件的好處就是易于管理，可以將組件放置在節(jié)點(diǎn)樹中，這也同樣方便調(diào)試。
但實(shí)際上很多node的邏輯和數(shù)據(jù)我們是不需要的，我開始思考使用更底層的類，我考慮到object，最后決定選擇使用resource，值得慶幸的是，這并沒有消耗太多重構(gòu)時(shí)間。
因?yàn)閏omponent 中更多是邏輯實(shí)現(xiàn)，自身并不包括數(shù)據(jù)（這一點(diǎn)與ECS很不同）。component 的數(shù)據(jù)應(yīng)該是從其所屬的entity中獲取的。所以其生命周期可應(yīng)該由其所屬的entity來管理。
這里需要注意的是，godot中的resource是一種“資產(chǎn)”，其在內(nèi)存中是唯一的，這就導(dǎo)致，如果不在entity ready的時(shí)候動(dòng)態(tài)的new resource 的話，會(huì)導(dǎo)致對于resource的數(shù)據(jù)修改影響其他entity的component，這也是我目前沒有找到更好辦法的地方，我現(xiàn)在將所有component都設(shè)置為runtime 動(dòng)態(tài)加載了。我不確定這是否很蠢，如果你知道更理想的方式，請告訴我，感謝。
主角player_character 的狀態(tài)機(jī)
上一期開發(fā)日志我提到了 procedure （流程）的概念，其實(shí)就是一個(gè)全局的狀態(tài)機(jī)，用來管理game state，但我很快發(fā)現(xiàn)，在游戲的main procedure 中依然需要細(xì)分各種狀態(tài)，一個(gè)明確的需求就是游戲中的Inventory_bar （玩家的背包欄）針對背包欄中的道具，在不同狀態(tài)下應(yīng)該有不同的表現(xiàn)，比如，常規(guī)條件下，右鍵道具應(yīng)該是“使用道具”，但當(dāng)主角處于烹飪狀態(tài)下，右鍵道具就變成了添加食材。
這部分我想到多種實(shí)現(xiàn)方式，比如給Inventory_bar 設(shè)置 狀態(tài)機(jī)，或者像我現(xiàn)在做的，給主角設(shè)置狀態(tài)機(jī)。
就像我現(xiàn)在做的，狀態(tài)機(jī)是基于godot的 Node 的，這其中 StateMachine 是通用的，這是一個(gè)自定義節(jié)點(diǎn)。而我們要做的就是自定義各種StateBase的擴(kuò)展腳本。外部只需要和state_machine交互就可以，在state_machine中會(huì)持有當(dāng)前狀態(tài)方便外部調(diào)用，而各種狀態(tài)自身也在初始化時(shí)持有其所屬的stateMachine（盡管也可以通過get_parent()來獲?。?/p>
道具和背包功能重構(gòu)
上一篇開發(fā)日志有講到，我們的道具系統(tǒng)是包括邏輯和表現(xiàn)兩方面。邏輯層和表現(xiàn)層通過事件通信。邏輯層就是各個(gè)實(shí)體上的inventory組件。表現(xiàn)層則分為 itemtile、itemslot和inventorybar三部分組成。
這次是針對表現(xiàn)層的代碼重構(gòu)。原因是烹飪系統(tǒng)需要用到道具槽，并根據(jù)道具槽中的道具匹配食譜來產(chǎn)生食物。
我最開始想法是創(chuàng)建一個(gè)食材槽widget，但在實(shí)際制作過程中發(fā)現(xiàn)這個(gè)所謂食材槽和道具槽功能十分相似，但也有不同，比如道具槽點(diǎn)擊是切換選中狀態(tài)，右鍵點(diǎn)擊是使用道具。道具的拖放邏輯也有所區(qū)別。
然后我意識到這些差異不應(yīng)該是道具槽本身的差異。而應(yīng)該是上層容器的差異。同樣是道具槽，在背包界面、烹飪界面和未來的商店界面都是不同的。
想明白了這一點(diǎn)，就需要對itemslot進(jìn)行重構(gòu)，將其中的處理邏輯移到上層的inventorybar中去實(shí)現(xiàn)。這樣三者的關(guān)系也就清晰了。
itemtile負(fù)責(zé)正確顯示道具信息，僅此而已。
itemslot除了一些必要的屬性外，還需要接受玩家的輸入，包括鼠標(biāo)進(jìn)去退出，點(diǎn)擊的拖拽等。但本身不處理，而是拋出相應(yīng)的signal交給上層處理。
invertorybar或cookerbar則是實(shí)際處理前端邏輯，并且和玩家身上的相應(yīng)組件交互的地方。
寫在最后
3月即將結(jié)束，這月的目標(biāo)就是實(shí)現(xiàn)烹飪系統(tǒng)，并盡可能維護(hù)現(xiàn)有框架代碼，讓其可擴(kuò)展、可維護(hù)。
4月開始制作游戲NPC，主要的功能包括行為樹、對話和任務(wù)系統(tǒng)這些，如果這期間有新的成員加入，也許可以并行完成游戲劇情和關(guān)卡的制作，這方面目前依然停滯不前。
5月應(yīng)該可以進(jìn)入填充資源階段。當(dāng)然，我說的是理想情況下。
最近這段時(shí)間也在幫忙表弟找工作的事情，可能會(huì)稍稍影響進(jìn)度。
加油吧，大家！
我是老李，一個(gè)志在盡快做出這款獨(dú)立游戲的游戲人。
我們下一期開發(fā)日志，再見吧！
