自問自答：
作為交流作的第一個專案，選擇的是 2D 的平臺遊戲作為開始。
Q1：第一個？
A1：是的，因為遊戲類型很多，我想一定有很多人會比較想嘗試自己喜歡的遊戲類型，
所以希望結束一個就開下一個，這樣的方式來進行，所以這是第一個。
Q2：為什麼選擇2D呢？
A2：3D要處理的東西很多喔，不單單多一個軸這麼單純，
由於希望是給讓初心者也能上手的系列，所以從越單純的開始越好。
若是有興趣一邊看文章一邊練習的，請先準備你的 Unity 環境，
我這邊使用的是 Unity 2019.2.16f1 個人版，它是完全免費的。
現在官方教程也有三個月的免費學習計畫，這邊不會把重點放在對 Unity 的鉅細靡遺的講解，
因為網路上已經有很多教學文，甚至官方版的教程也很專業，
所以已經會一點基礎的會更適合，當然也是可以嘗試做中學去認識引擎，比較辛苦而已。
Q3：版本不一樣可以嗎？
A3：其實我在使用的也不是最新版，而是相對穩定的版本，只要不是差異到一兩年，
例如前年的 Unity 5.X 系列，很多 api 都換了，那可能會實作的很辛苦，
例如必須將 image 改回 sprite，text 改回 label，甚至 load scene 的方式， asset bundle都要自己重寫，為了方便用相近一點的版本吧。
Q4：可以提供下載點嗎？
A4：官方的下載網址在這 =>
點我，個人版的是免費的，請安心使用。
前言：
這個交流作，會從比較多的方向去討論，盡量不會全是只有程式面的角度來看。
我個人對於專業的看法是，能將一個技術拿出來用於「創造」。
將一門技術培養至專業是需要時間的，而入門到專業也是有很多階段，
其中一個階段是「看得懂可以改」，而入門到這個階段耗時短是很值得投資的。
要能夠憑空畫出一幅圖，設計一個原創角色，這是專業，是很困難的。
但如果在有人指導的情況下，去幫忙加光影、上網點，這是做得到的。
要獨創一個遊戲玩法，設計一個市面上沒有的系統，這是專業，是很困難的。
但如果有相似的作品可以參考，去將經過玩家驗證的系統寫成企劃，這是做得到的。
要以對程式語言的基礎為底，考量過開發引擎的優劣，去寫遊戲，這是專業，是很困難的。
但如果是將別人整理過，已經打磨過的範本或插件拿來做延伸研究，這是做得到的。
我看公會裡的夥伴，很多都副修超多技能樹的，其實大家都明白這個道理？！
因為專業的精進，與其它技能樹點到「看得懂可以改」的階段彼此是不衝突的。
來跟大家介紹，像這樣的資源對開發者有多方便，我們該怎麼使用，該怎麼去延伸。
本文：
如果你之前有使用過 unity store，下載過一些套件來用，對 .unitypackage 結尾的檔案應該不陌生，然後點兩下就會幫你 import 到專案了。
其實 github 上的 unity 專案也不難匯入的，點開超連結的網頁，不論你是否擁有 github 帳號，
你都能 clone or download 這個專案。下載後解壓縮，你會發現它也有一個 Assets 資料夾，
將 Assets 裡的東西複製一份到你的專案就完成了。
我相信版上很多是 Unity 進階者，是高手。這部分你已經很熟練的話，可以在 github 上搜尋你有興趣主題，下載並整合進你的專案，試著透過巨人的肩膀減少我們開發的時間。
當然，要注意授權條款，維持良好交流。
我在這個步驟，是打開 Unity 建立了一個新的 2D 專案，只有一個 sample 場景，然後匯入這個插件。接著我要帶一點版本管裡跟協作的觀念進來了，若覺得後面太深的可以跳過沒關係，
選用適合你的自己能了解的部分讀懂就好。
然後我希望這個專案是可以跟大家共享的，可以一起協作，所以我將目前的進度丟上了 github，命名為
BahamutJam。在 github 上的多人作業是很有彈性很方便的，不過你
需要申請一個帳號，然後 fork 我的專案；就像我找了個測試員一號做的動作，
fork 完的專案是你的專案，你只需要對你帳號中這一份專案管理即可。
緊接著，我希望透過測試員一號來解釋 fork 出來的專案是怎麼跟原本專案做聯動的。
狀況劇是這樣，測試員一號執行了這一份專案後，他想加些中文註解在某個 Editor 腳本，
所以他修改後並上傳。這時後可以：
安裝，下一步下一步完成後打開，選擇 clone 一份到你本機端方便你與 github 上的版本維護。
在貼上 git repository 時可以選擇兩種方式，ssh 還是 https，若你們今天是一個小團隊的話，
希望能限制讀取這個專案的那些人，那麼你們就比較適合 ssh 且支援 加密金鑰的方式；在此次交流作我是用 https，沒有那個加密金鑰的權限認證。
修改的部分會出現在 unstaged 的地方，決定上傳的檔案按 + 它會跑到 Staged files；同理若選錯了想取消就按 - ，只有在 staged 地方的檔案才會被 Commit 上去，緊接著就是 commit ，但這樣還沒有同步到 github 上的專案，還需要在點 Commit 右邊的右邊那顆 Push，這樣就同步了。
2. 使用指令
另一種方式，其實
git 本身就是使用指令在做分散式管理的，所以當然可以用下指令的方式去做上傳。例如打開你的命令提示字元，輸入 git status 檢查檔案狀態，一樣會發現一個腳本處於異動狀態。
接著，
git commit -m "將一些 editor 腳本上的控制參數中文化"
git push
同樣可以實現剛剛的操作。
我們就可以將這個 push 作為 pull request 同步給原開發人員，
當我今天看到了，測試員一號貼心幫我補上註解，我就可以讓這個 commit 同步更新上去，
共同維護此專案，這樣就是一個協作的流程。( commmits 數變4個了)
上述的操作一定會有些模糊的地方，為何 commit 過後還要 push，不 push 是怎樣的狀態？
stage 區存在的意義是什麼？接下來就用圖，藉由指令的方式作個理解。
版控的部分，只要作到黃底的本機端就可以了，可以達到跟 SVN 小烏龜一樣的效果。
對應 Commit 的 Revert 有在使用版本管理的人應該就不陌生了；若是要走協作，
才有才有遠端那塊，標註紅色是因為這些指令是容易發生衝突的，尤其 Unity 對每一個檔案，
都會產生一個 meta 檔作為辨識，在協同作業時非常絕對肯定會發生衝突的。(笑)
當然指令不會就這麼少，常用的這幾個就很夠了，剩下遇到再來介紹也不遲；另外這是開放的專案，很歡迎隨便下指令作練習，不要擔心太多，把它用壞也沒關係。
P.S. 上述提供的連結皆為官方網站連結，圖片是出自我手，請安心使用。
謝謝您的閱讀，字很多，辛苦了。
今天這篇系列文你可以學習到：
1. Git 與 Github 原理入門
2. 一個搜尋對自己現在專案有用套件並匯入的方法
3. 一份可以共同協作的 2D 平臺遊戲專案
4. 奇怪的知識增加了
創作內容
Unity 交流作 - 2D平臺遊戲(一)
小型專案製程紀錄 (0)
