主題

2022 GGJ台北-工程師累不雷遊戲開發紀錄 Part.2

發條 | 2022-01-28 17:50:33 | 巴幣 6 | 人氣 427

上一篇講述了雛形的開發過程
以下為後續的開發紀錄

========2022/1/22========

早上9點多到GGJ現場
著手開發現有雛形的內容
由於11點要發表，因此對於系統上沒有做太大的改動
首先把美術的概念角色圖加入
為了表現兩邊的玩家正在打程式
因此做了一個程式碼生成系統
當玩家呼叫此功能的時候，會將指定的Text顯示隨機挑選的字串內容

玩家完成一組QTE後，就會將Text中的內容推到上方的程式碼Text中(如下圖的綠色字串)
設定好程式碼內容(我是隨便從目前現有程式碼複製幾個)之後，就能有以下效果

接著隨便去網路上找一張蟲蟲圖片，讓玩家打錯的時候會生成在指定位置

這樣大致上就完成了概念發表用的雛型內容

之前的文章也有提到這個隨便弄出來的蟲蟲機制變成了後來遊戲的主要內容(=w=)

結束概念發表後，我們開始討論遊戲的後續機制與修改
首先我們在試玩雛形的時候發現WASD比上下左右還要困難，原因是分辨文字內容還需要一點時間
因此把兩邊的圖片都改成上下左右

接著是對決方式，本來計畫改成兩邊的QTE是相同的，時限之內玩家要完成QTE

不過實際完成後發現如果比較會玩的人，會常常需要等另一位完成
除了影響遊戲節奏，也難以區別工程師(玩家)的好壞

(有能力的工程師就是要解決更多工作不是嗎)

所以取消了這個方案

然後就是最重要的內容:BUG如何影響遊戲體驗

最初的想法是:

A玩家製造一個BUG後，B玩家要想辦法消除(不消除可能會有負面效果)

BUG的QTE指令會比較困難，但是如果B玩家成功的話可以得到大量分數(作為遊戲結束後的統計積分)

但考量到這樣可能會打亂遊戲節奏，時間也不好掌控

因此經過討論後的結論是:

玩家打錯QTE的時候，不但沒分數，還會製造一個BUG給另一位玩家

而遊戲時間到之後，假如場上還有殘留BUG，則進入Debug(Bonus)時間

Debug時間短，但是在這個時間內可以利用特殊設定的QTE指令消除BUG，成功消除的話會得到較高的分數

這樣的設計，解BUG的玩家不但能挽救對手失去的分數達到目標門檻，還有機會因獲得高分贏過對手

此方法除了可以解決上述節奏與時間的問題

也能順便還原職場上的情況:拯救專案，還可以得到良好評價(後者我好像...沒遇過...)

我們的遊戲流程與機制大概就這樣拍板定案(=w=)

開始動工~

首先我先調整了QTE生成的功能，把此功能移到程式碼生成系統(CodeMaker)中，這樣如果玩法機制有任何變動(例如上述的對決方式)，改動的部分可以減少
另外增加了Debug時間的生成固定QTE功能，如果玩家呼叫此功能就會隨機回傳設定好的QTE內容(用數字標記)

數字的內容對照到QTE種類列表內容(例如:0->上 1->左 2->下 3->右這樣)

接著開始處理遊戲流程的部分:

這邊我設計了一個大概會有的流程列舉(Enum)

除了方便掌握目前遊戲進行到的階段外，也易於之後擴充比較細節的遊戲階段(Ex.開始與結束的時候顯示字幕之類的)

細節的部分其實也沒甚麼特別的，所以我這邊不多做描述(=w=)
完成流程控制後，依照我們企劃的設計，得分的分數是有些微變化的

因此我做了一個分數管控的功能，當玩家得分時，此功能會回傳設定區間的某個數

這邊完成之後，我們的遊戲流程就差不多完成了
然後跟其他的組員介接他們的功能，例如開始與分數結算以及特效顯示(按下按鈕的回饋與音效以及Debug時間光影特效)
另外美術也陸續完成UI以及角色等等的素材可以加入，遊戲離完成的目標不遠了(=w=)

========2022/1/23========

今天是最後一天，由於活動臨時改線上，因此就在家工作(=w=)
對於遊戲主體的部分，由於前一天都完成的差不多
所以我在第三天的大致工作只有修正BUG與增加遊戲開始與結束的跑馬燈(前面提到的列舉就派上用場囉)

然後調整BUG的生成(我是說遊戲中的BUG，不是我的程式w)，讓他堆疊位置有點隨機性，能更快的出現混亂(倒塌)的感覺(=w=)

還有協助組員加入指定的特效與調整等等
組員也完成了開頭、教學以及結算的畫面功能(真CARRY~~~)

另外我們也開始埋一些小玩意到遊戲中
例如上圖的黑板內容
以及有興趣的話可以仔細看看遊戲中生成的程式碼內容(=w=)

然後就上傳遊戲等發表啦

不得不說改成線上活動有點可惜
過去的經驗我都會希望隨機挑現場參加者試玩
尤其是像這樣的對戰遊戲(=w=)
不過疫情影響也沒辦法囉

總之這次就到這邊，感謝閱讀~