經過二天的評估後，趁著今天的文章裡來談一下整個遊戲的製作規劃。

這二天花了一些時間看Mirror的範例後，得到了一個結論就是連線遊戲果然是很複雜花時間的。而從這二天的時間利用也大概了解到每天能投入寫文章加上製作連線遊戲的時間而不影響到到日常工作的話最多就是三個小時的時間，這樣的時間長度一個月下來差不多就一百個小時。

一百個小時看起來很多，但從程式碼撰寫(連線部份不熟，要花時間了解)到美術製作(完全新手)，找音樂音效，到將遊戲後台弄到雲端上(DevOp工作，有碰過一些)再加上寫文章。怎麼看時間都很不夠。因此，得到的結論就是把遊戲的範疇弄到最小可執行的地歩。而Mirror裡所提供的Tank範例，就是相當足夠的可以拿來當動作遊戲的基本框架。雖然要額外補不少東西進去，但是個很好的展開點。

接下來的就來談下在如此短的時間內，遊戲的規劃和可能會進行的部份有哪些。

Rule and Gameplay

目前預定的規劃是一個多人可以連入房間的動作射擊遊戲，每個房預定是三、四十個玩家可進入。而房間只要有任一位玩家登入，則會產生出來，之後除非要做維護或更新(老實說可能根本不會有)，則不會關閉。玩家每次進入時都會先選擇沒有滿員的房間，若是房間裡玩家達到了上限，則會再開啓新的房間。

玩家原則上只有一條命，被打爆後就會被踢離該房間，要進入的話則要重新登入後等待配對。若玩家中途不論任何原因離線，都會強制被踢離房間，也就是視同於和被打爆一樣。重新配對是否會回到原先的房間則不一定，看當下的房間數量為主(多半也就是只有一間房)。配對時沒有任何的偏好。

可能會針對玩家的排名做個網頁進行呈現，但這完全看是否有足夠的時間，故此優先度很低，多半是會被捨棄掉。

遊戲客戶端部份，不想要考慮到客戶端的效能調教，故用Windows或Mac版為主(Unity的Standalone，照理說Linux版也算在裡面)。手機部份雖然Unity是跨平台，但有可能會花去不少時間在效能上調整，故不做考慮。

遊戲表現部份，由於自身美術的能力是零，只會有一些或是完全不會有任何的動作。也就是說近戰型的格鬥表現完全不在考慮之內。這也就是為什麼是以射擊為主的動作玩法。美術呈現上，不會畫2D，不考慮，3D建模不但不會，就算會也很花時間，但看到了用Voxel的方式，可以像堆積本一樣進行(和Minecraft應該是不一樣，但分類上是相同的)，故會採用這樣的方式進行美術呈現。

Planned study

Mirror是目前連線上要先掌握的，但它只處理了Client和Game Server的部份。至於登入，大廳等Server，又或是DB等，目前的想法是用其它方式處理掉，而Golang是語言中的首選，服務部份則是傾向用Google Cloud Platform(GCP)。然初步了解後，或許PlayFab也會成為一個很好的切入點(多樣的登入選擇，配對等)。

一但談起了GCP，kubernetes和Doker以及其它有可能相關的技術，就變得又有不少的關聯。這裡就要回顧歷年來的鐵人文章，似乎有不少的鐵人們都有投入這方面的研究，相信在這次的比賽中肯定是要藉助他們的力量才能有效的往前進。

Keep growing the list

目前明確在研究的

• Mirror

將這篇當做索引文，日後再逐漸的更新這次的連線遊戲製作中到研究了哪些技術，用些什麼工具實現。

一百個小時，似乎加了連線後，就變得異常的困難了，希望規劃的小遊戲可以如期完成。