Unity 遊戲框架搭建 2019 (二十一、二十二) 第三章簡介&整理前的準備

006tNc79gy1fzfr0vq5iqj30iw0nttbm.jpg

整理前的準備

到目前為止,我們積攢了很多示例了,並且每個示例也都貫徹了最的約定和規則。
在上一篇的小結也說了一個比較新的東西:編程體驗優化。
在之前我們還積攢了一個問題:程式碼重複問題。
我們可是忍住整理的衝動忍了好久了。

所以現在也是時候準備著手整理了。

知識點和問題總結

遺留問題

我們寫列出來之前記錄的第一個問題:

  • 第八個示例與之前的示例程式碼重複,功能重複。

這個問題想想就很好解決,只要刪除掉第八個示例之前的示例就好了。但是怎麼刪和刪完是否會破壞原來的功能?這兩問題要具體看了程式碼才會知道。現在先不看,先把這個問題暫時列出來。

備份

程式碼要在之後的一段時間內要進行大幅度地更改,可能會改出問題來,如果問題比較難以解決就麻煩了。所以我們要給做一個份備份,如果出了問題我們可以通過備份恢復。如何備份其實有很多種,比較常見的是放在 git 伺服器,不過這部分我們還沒有接觸過,所以先備份成文件。就用我們的導出功能導出,把文件進行命名。叫什麼名字呢?這個問題也先列出來:

  • 進行備份,給導出的文件取個名字。

約定和規則總結

首先我們到目前為止 QFramework 目錄結構應該如下圖所示:
006tNc79gy1fzfr2tqw7tj30ma0bu764.jpg
筆者更希望除了除了了這 13 個示例之外,大家自己也收集了一些東西。

之所以目錄的結構是這樣,是因為我們在做每個示例的時候貫徹了我們的約定和規則。

那麼我們的約定和規則現在是什麼呢?

  1. 每個示例在 QFramework 目錄下創建一個文件夾,文件夾的格式是: 數字.示例的功能
  2. 每個示例寫一個腳本,腳本中包含可復用的靜態方法和 MenuItem 方法。
  3. 每寫一個示例進行一次導出,導出的文件名後邊加上日期和時間,這個功能已經在導出功能里內置了。

大概就這些,非常清晰明確。

示例誕生的原因類型

現在呢我們有 13 個示例,每個示例都有它誕生的原因的。但是這些誕生的原因又有點區別,我們逐個進行分析列出。

前七個示例是為了完成導出功能而進行的 Unity、C# API 的練習。因為在初期很多 API 我們是不知道的,大家應該在剛接觸 Unity 的時候都經歷過這一個階段。

而完成導出功能的原因是為了優化我們的知識庫導出體驗,並且打造一個知識庫的使用流程。有了導出功能可以讓我們的知識庫在多個項目之間切換或者在家和公司之間切換,而導出功能中的自動命名功能算是內置了我們的一部分命名規則。命名規則的存在呢是為了解決我們如果有多個文件不知道哪個是最新的問題。

所以前七個示例總結下來是解決了幾個問題:

  1. 新的知識(API)收集,比如時間操作、文件打開、UnityEditor API 收集等。
  2. 內置了部分規則(比如文件命名)。
  3. 完成某個功能(導出功能),並完善。
  4. 導出功能的目的是為了讓知識庫的使用流程更平滑,是為了解決最初的問題。根據解決的問題去收集了 API,並逐步完善的導出功能。
  5. 邏輯復用,比如 MenuItem 復用。

前七個示例大概是這樣。

接下來分析之後的幾個示例:
8. 第八個示例誕生的原因,是為了解決我們的程式碼復用問題,使用 MenuItem 進行復用程式碼限制太多了,所以為此我們使用了 public 關鍵字,並且對前七個示例都進行了一次實踐。在實踐的過程中有逐步摸索出了一點方法設計的方法論。
9. 第九個示例是筆者分享的一個在項目中比較實用的解析度檢測小工具,這種小工具是解決實際的項目問題。
10. 第十個是示例節省了程式碼行數,因為每次為 transform.localPosition.x 賦值太麻煩了,要寫三行程式碼,算是編碼體驗優化吧。
11. 第十一個示例是 Transform 重置功能,寫了一個 Identity 方法,同樣也是編碼體驗優化。
12. 第十二個示例是 一個概率函數,就是 Persent,是一種數學工具,在項目中也會用到,和第九個解析度檢測小工具一樣,算是解決項目實際問題的小工具。
13. 第十三個示例呢是給 GameObject 的 Show 和 Hide 做了一步,原因是筆者剛轉過來的時候不太適應 active 的這種命名,也算是編碼體驗優化。

大概是這些加上前七個總結再進行一次分類總結。

我們的知識庫的每個示例誕生的原因分類:

  1. 知識、API 收集(為了完成導出功能)。
  2. 實現部分規則(命名規則)。
  3. 解決庫本身使用及流程問題(導出功能)。
  4. 邏輯復用(MenuItem 和 public 方法)。
  5. 實踐新接觸的 C# 語法(public 方法)。
  6. 項目實用工具收集。
  7. 編碼體驗優化。

大概就這七個原因,其中 1 和 5 可以歸為一類。2 和 3、4 、6、7可以歸為一類。

如下:

  1. 知識學習&收集
    • API 收集
    • C# 語法實踐
  2. 庫本身的功能
    • 規則實現
    • 使用流程提供及優化
    • 效率提升(編碼體驗、邏輯復用)
    • 項目實用工具收集

OK,總結出了一份非常清晰的分類。大家還記得在第一篇中筆者的關於庫的介紹?
貼出原文如下:

有一個自己的庫,有什麼好處呢?其實好處是非常多的。

從編程角度上:

  • 可以提高自己的編碼效率。
    從學習角度上:
  • 可以積累下來自己所學過的知識。

在第一篇的時候很筆者介紹的很模糊,現在經過以上更具體的分類,大家應該更清楚了吧?

今天的內容就這些。

小結

  1. 要做的事情:
    • 備份:導出文件,並取一個合理的名字。
  2. 遺留問題:
    • 第八個示例與之前的示例程式碼重複,功能重複。
  3. 約定和規則:
    • 每個示例在 QFramework 目錄下創建一個文件夾,文件夾的格式是: 數字.示例的功能
    • 每個示例寫一個腳本,腳本中包含可復用的靜態方法和 MenuItem 方法。
    • 每寫一個示例進行一次導出,導出的文件名後邊加上日期和時間,這個功能已經在導出功能里內置了。
  4. 示例分類:
    1. 知識學習&收集
      • API 收集
      • C# 語法實踐
    2. 庫本身的功能
      • 規則實現
      • 使用流程提供及優化
      • 效率提升(編碼體驗、邏輯復用)
      • 項目實用工具收集

文章就寫到這裡,我們下一篇開始進行整理。

轉載請註明地址:涼鞋的筆記:liangxiegame.com

更多內容