一個關於unity3d的系列文章

　　寫在前面

　　想來從事unity3d開發已有三年多一些，尋思着該爲這個奮鬥了這麼久的行業作些少量貢獻，無賴自身水平侷限加上各類拖延症，一直未能實施。

　　該寫什麼？

　　該怎麼寫？

　　不知道本身的能力是否可以撐起夢想，最後是否會太監？

　　也不會作需求分析，本身的文章會否有人問津？

　　更加不知道文章是否書寫正確，不要傳遞了錯誤的信息，誤人技術，徒留一地雞毛。

　　想的多了，作得就少了，越想越沒法下筆，但近日開始接手一個陳舊的項目，看着本身沒法下手的代碼，看着各類解不開的變量關係，才知道，雖然unity3d大大下降了作遊戲的門檻，可是用Unity作項目，仍是不能隨意的來，加上近日瀏覽各類論壇，各類教程都看了一眼，發現教程要否則面對純新手，講解各類API各類組件的用法，要否則就是面對圖形學，講解各類shader。恰恰就是缺乏中間部分，中間那一部分已經熟悉了C#的語法，熟悉了unity的各類API,各個插件，可是殊不知道怎麼去組織代碼，如何讓本身的代碼更加清晰，更加明瞭的人。

　　

　　文章定位

　　上文已經講了，這個系列文章已經定位新手進階，因此高手們就手下留情，若是有熱心腸的前輩願意指點一二固然更好。

　　新手進階是一個痛苦的階段，痛苦程度就和入門階段同樣，充滿了迷茫，看着高手的代碼很簡單，可是本身就是沒法領悟，看過就忘了，不知道他們爲何這麼寫，意義何在。在我看來，寫代碼也是分三個階段。

　　階段一:看山是山，看水是水。這個功能怎麼實現？ 百度一下，按照教程寫了個類，拖拽一下，運行起來測試，哇塞，一次成功！哈哈，成功搞定這個知識點。這麼簡單啊，開心！

　　階段二：看山不是山，看水不是水。明明直接new這個類就行了，爲何還要求繼承個接口，再去另一個類裏面new, 明明public一個變量就行了，爲何必須寫個屬性，爲何這裏抽象了一個類，可是這裏又是抽象的接口？ 爲何明明能夠直接簡單的就搞定了，爲何非要搞這麼多彎彎拐拐？百度一下，哎，大神的理論一堆一堆的，好像也不容易吃透啊。

　　階段三:看山仍是山，看水仍是水。好吧，我自認還處於第二階段，就不擅自寫第三階段的事情了， 有高手能夠留言指點一二 ^_^

　　

　　文章規劃

　　這篇文章既然定位於新手進階，那麼就再也不是小白教程，不會再隨意的寫代碼了，那麼你就須要給你的代碼理定規則，你也須要開始作決定應該引用哪些庫，哪些工具了。

　　第一步：搭建unity通用的工程環境，劃分清晰地目錄結構，引入並測試各類須要用到的庫，理定代碼規範，寫好框架代碼。

　　第二步：實戰講解上一步中書寫的代碼的用法，幫助你們更加清晰地理解總體代碼的意義，實戰項目目前選定 <鬥地主>的遊戲，由於我只有鬥地主的美術資源，就地取材了哈哈。

　　第三步：還沒想好，車道山前必有路，就不耗費腦細胞去思考了，我這懶惰的性格加上滿滿的工做安排，完成前面兩步的時候，就已經不知道何時了，^_^，但願本身能快速完成這個系列吧。

　　在這之間，我會用golang代碼來寫個簡易的服務器，用來完善和測試這個鬥地主的遊戲，老實說吧，服務器沒寫過，golang更沒寫過，如今正在自學中，祈禱可以快速應用過來，完成這個本身一直想完成的東西。

　　順帶會零散記錄一些遊戲中須要用的工具或者算法。

　　

　　寫在最後

胡言亂語了一夜，知道不會有多少人看，其實博客是寫給本身的，婉婉訴來，表達的不過本身所思所想。也但願本身可以熬過這迷茫的日子，祝願本身更祝願你們有一個美好的將來。