Game Flow

今天沒有特別的製作上的進展，但來記錄目前構思的架構。從遊戲開始進行的過程說起

• 登入
• 準備關卡
• 配對
• 遊戲主關卡

登入

登入會利用PlayFab的服務進行，而登入後玩家產生的資料現階段會先放置在PlayFab這。不過PlayFab沒有像Firebase一樣有提供一個NoSQL的DB，還不是很了解它是怎麼設定玩家Custom的資料，希望不會太複雜。

本來想過當玩家資料生成的當下透過Player Stream也就是某些動作的事件流，讓玩家的資料產生在Firebase那。大略看了一下整個過程。大致上要做的事情是在Player生成的事件產生時，透過一個CloudScript或是一個Azure Function來進行。CloudScript是以JavaScript為基礎進行撰寫的，但不能額外使用NPM Module，也就是說所有要用到的Library都要自行取出放在一起，說真的，這更本就不符合現在的後台開發。不過它原來的想法只是單純的撰寫一個簡單的功能，用這樣的寫法去看它到也很合理。

也就是因為CloudScript太過陽春不符合人性，在Microsoft接手後才逐步的調整成合Azure做接合，而現在，事件是可以觸發Azure Function開始。雖然在Azure Function的加持下彈性和能力都大幅度的增加，但複雜度也相對的增加，也就是還要再接合Azure這個服務。雖然會變得更加完善但短時間內實在很難進行。

準備

這裡就會利用玩家在後台的資料進行內容上的呈現。雖然是這樣想的，不過以目前的時間規劃來看，可能也是用簡單的UI呈現來代表。會希望有數值上的呈現，一些玩家道具等，但能否製作出來還是未知數。

配對

配對這裡的想法會是將Game Server放到GCP中的k8s，並利用配對機制將Game Server的ip和配對資料傳回給Client端。配對機制的選用暫時考量的是Open Match，選它的原因是這個專案是Google和Unity合作進行的，或許之後會納入到Unity的開發工具中，且它的文件裡有著詳細的佈署到k8s的說明。但如同之前提到的Concern，自身對於golang不太熟，用Open Match勢必會和golang緊密的連接在一起，這點有些另人擔心。雖然還有一些時間可以研究，但k8s連同golang，不確定能不能在短時間內佈署到GCP裡。

Open Match裡有著不錯的架構圖，對於此遊戲的規劃極具有參考價值

而配對的方式，可能會將配對需求傳到Open Match Fronted，並在Director結束後透過PubNub直接丟出配對成功或是失敗的訊息，也就是說Client端要在要求配對後進行PubNub Subscribe事件的動作。但要如何才能夠監聽到自己配對的訊息而不是其它人配對的訊息。利用Channel可以辦到，利用Player PlayFab Id當做Channel，送配對要求時跟著進入到配對流程，而配對結束這利用此ID當做Channel回送事件。

• How many channels can I use?

好在PubNub Channel沒有數量上限，也沒有開設額外的費用。

遊戲主關卡

遊戲主要的遊玩是放在Game Server這，利用配對機制將其ip回傳給Client後，Client在利用Mirror並給予ip後進行連線。

這個部份今天稍加思考後想到了一個不確定能不能進行的問題。目前Game Server是用Mirror，也就是說Client這也是用Mirror，但其實Client這的Main Scene還加了很多Client特有的物件。而在Client端的Mirror只是其中的一個Sub Scene裡的管理物件。而在Game Server那，它是存在於Main scene裡的管理物件。還沒有做過實驗，不確定這樣雙向不一樣的架構會不會有任何問題，連線上是可行的嗎。

不確定上GCP的時間為何，只能近期利用localhost方式去嘗試。也順便確立Unity專案要怎麼設罝在雙向架構不一樣時比較好進行測試，若是雙向架構不同，開始的Scene就不同，是否要利用Unity Build Script去變更起始Scene等。不試試看真的不知道怎麼運作，又要花一些時間處理才行。

而Mirror動作同步和角色控制部份，還沒有時間處理。連戲的複雜度可真是不容小覷。