1. 程式人生 > >Unity 遊戲框架搭建 (七) 減少加班利器-QApp類

Unity 遊戲框架搭建 (七) 減少加班利器-QApp類

本來這周想介紹一些框架中自認為比較好用的小工具的,但是發現很多小工具都依賴一個類----App。
App類的職責:   1.接收的生命週期事件。   2.做為遊戲的入口。   3.一些框架級別的元件初始化。   本文只介紹App的職責2:做為遊戲的入口。 Why?   在我小時候做專案的時候,每次改一點點程式碼(或者不止一點點),要看下結果就要啟動遊戲->Loading介面->點選各種按鈕->跳轉到目標介面看結果或者Log之類的。一天如果10次這種行為會浪費很多時間,如果按照時薪算的話那就是......很多錢(捂嘴)。 流程圖是這樣的:
為什麼會出現這種問題呢?   1.模組間的耦合度太高了。下一個模組要依賴前一個模組的一些資料或者邏輯。   2.或者有可能是這個模組設計得太大了,介面太多,也會發生這種情況。 解決方案:
  針對問題1:在模組的入口提供一個測試的介面,用來寫這個模組的資源載入或者資料初始化的邏輯,...什麼!?...你們專案就一個模組...來來來我們好好聊聊.....   針對問題2:在模組的入口提供一個測試介面,寫跳轉到目標介面的相關程式碼。 流程圖是這樣的:
雖然很low但是勉強解決了問題。
階段的劃分:   資源載入亂七八糟的程式碼和最好能一步跳轉到目標介面的程式碼,需要在出包或者跑完整遊戲流程的時候失效。   如何做到?答案是階段的劃分。 我的框架裡分為如下幾個階段:   1.開發階段: 不斷的編碼->驗證結果->編碼->驗證結果->blablabla。   2.出包/真機階段: 這個階段跑跑完整流程,在真機上跑跑,給QA測測。   3.釋出階段: 上線了,yeah!。 對應的列舉:
[C#] 純文字檢視 複製程式碼 ?
1 2 3 4 public enum AppMode {  Developing, QA, Release }
很明顯,亂七八糟的程式碼是要在開發階段有效,但是在QA或者Release版本中無效的。那麼只要在遊戲的入口處判斷當前在什麼階段就好了。 開始編碼: [C#] 純文字檢視 複製程式碼 ?
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

相關推薦

Unity 遊戲框架搭建 () 減少加班利器-QApp

本來這周想介紹一些框架中自認為比較好用的小工具的,但是發現很多小工具都依賴一個類----App。 App類的職責:   1.接收的生命週期事件。   2.做為遊戲的入口。   3.一些框架級別的元件初始化。   本文只介紹App的職責

Unity 遊戲框架搭建 2019 (十六、十) localPosition 簡化與Transform 重置

在上一篇我們收集了一個 螢幕解析度檢測的一個小工具。今天呢再往下接著探索。 ### 問題 我們今天在接著探索。不管是寫 UI 還是寫 GamePlay,多多少少都需要操作 Transform。 而在筆者剛接觸 Unity 的時候有一個非常不習慣的地方。就是對 transform 的位置、角度、縮放進行賦值。

Unity 遊戲框架搭建 2019 (二十、二十八)棄用的程式碼警告解決&棄用的程式碼刪除

在前兩篇,我們把所有的示例重頭到尾整理了一遍。 當前的狀態如下: 要做的事情: (完成) 備份:匯出檔案,並取一個合理的名字。 遺留問題: (完成) 第八個示例與之前的示例程式碼重複,功能重複。 (完成) 方法所在類的命名有問題。 選單欄顯示順序問題。 棄用的程式碼警告 約定和規則: 每個示例

Unity 遊戲框架搭建:我所理解的框架

進入到遊戲行業後,大家多多少少聽到過 "框架、架構" 等聽起來很"高大上"的詞彙,那麼到底什麼叫做框架?架構又什麼?如何去搭建遊戲框架,又如何去做遊戲的架構呢?本場 Chat 從多個角度剖析“框架、架構”這兩個概念,然後收集遊戲開發中遇到與"框架、架構"相關的問題,並在這裡給

Unity 遊戲框架搭建 (二十三) 重構小工具 Platform

在日常開發中,我們經常遇到或者寫出這樣的程式碼 var sTrAngeNamingVariable = "a variable"; #if UNITY_IOS || UNITY_ANDROID || UNITY_EDITOR sTrAng

涼鞋:我所理解的框架Unity 遊戲框架搭建

前言 架構和框架這些概念聽起來很遙遠,讓很多初學者不明覺厲。會產生“等自己技術牛逼了再去做架構或者搭建框架”這樣的想法。在這裡筆者可以很肯定地告訴大家,初學者是完全可以去做這些事情的。 初識架構和框架 架構和框架是非常接地氣的,離我們其實並不遙遠。 什麼是架構? 架構是一個約定,一個規則,一個大家都懂得遵守

Unity 遊戲框架搭建 2019 (九~十二) 第一章小結&第二章簡介&第八個示例

第一章小結 為了強化教程的重點,會在合適的時候進行總結與快速複習。 第二章 簡介 在第一章我們做了知識庫的準備,從而讓我們更高效地收集示例。 在第二章,我們就用準備好的匯出工具試著收集幾個示例,這些示例中有的是我們後續庫的基礎工具,也有的是在專案中非常實用的小工具,還有一些示例是實踐了在框架搭建方向上非常

Unity 遊戲框架搭建 2019 (十三~十五) 接下來要學什麼?& 第九個示例

在之前的兩篇中,我們使用 public 靜態方法對之前的內容進行了一個抽取,有了 public 靜態方法這個工具,我們的學習行為也發生了一點變化。 在沒使用 public 關鍵字之前呢,每一個示例僅僅是一個知識的記錄作用。而我們用了 public 關鍵字之後,我們可以把知識作為一個可以複用的方法。但是呢,這

Unity 遊戲框架搭建 2019 (十八~二十) 概率函式 & GameObject 顯示、隱藏簡化 & 第二章 小結與快速複習

在筆者剛做專案的時候,遇到了一個需求。第一個專案是一個跑酷遊戲,而跑酷遊戲是需要一條一條跑道拼接成的。每個跑道的長度是固定的,而怪物的出現位置也是在跑道上固定好的。那麼怪物出現的概率決定一部分關卡的難度。 以上有點繞,其實就是,到某一個時刻,怪物是否要出現。而是否要出現是根據概率來決定的。如果一個怪物出現的

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

整理前的準備 到目前為止,我們積攢了很多示例了,並且每個示例也都貫徹了最的約定和規則。 在上一篇的小結也說了一個比較新的東西:程式設計體驗優化。 在之前我們還積攢了一個問題:程式碼重複問題。 我們可是忍住整理的衝動忍了好久了。 所以現在也是時候準備著手整理了。 知識點和問題總結 遺留問題 我們寫列出來之前

Unity 遊戲框架搭建 2019 (二十三、二十四) 備份與版本號&危險的操作

先列出上一篇的總結: 要做的事情: 備份:匯出檔案,並取一個合理的名字。 遺留問題: 第八個示例與之前的示例程式碼重複,功能重複。 約定和規則: 每個示例在 QFramework 目錄下建立一個資料夾,資料夾的格式是: 數字.示例的功能 每個示例寫一個指令碼,指令碼中包含可複用的靜態方法和 M

Unity 遊戲框架搭建 2019 (二十六) 第一輪整理完結

昨天呢我們把第八個示例整理完了。整理之後學習了類的第一作用:方法的集合,還有 Obselete 這個 API。並且在進行整理的時候貫徹了我們新的約定和規則:先確保功能有效,再去做變更和刪除。 今天我們在往下接著整理第九個示例 第九個示例 using UnityEngine; #if UNITY_EDITOR

Unity 遊戲框架搭建 2019 (二十九) 方法所在命名問題誕生的原因

我們在整理階段解決了一些意外的問題。但是這些問題僅僅只是被解決而已,我們並沒有去思考過這些問題是為什麼產生的?以及在以後我們如何去避免這些問題的產生? 方法所在類的命名問題,最後我們通過方法分類解決了,並且學習了類的第一作用:方法的集合。 解決之後導致了大量的棄用程式碼,為了標記棄用程式碼,我們又簡單學習了

Unity 遊戲框架搭建 2019 (三十、三十一) MenuItem 顯示順序問題 & 的提取

在上一篇,我們得出了兩個核心的學習思路: 根據問題去學習,並收集。 主動學習,並思考適用場景。 我們今天解決 MenuItem 顯示順序問題。 目前 MenuItem 顯示如圖所示: 我們來看下 MenuItem 這個屬性構造的定義。 第二個引數是,是否是驗證方法,目前不用理解,官網上預設是 fa

Unity 遊戲框架搭建 2019 (三十二、三十三) 的命名 & 程式碼檔案命名

昨天我們完成了第八個示例的第二個 MenuItem 選單順序的調整。 我們今天再往下接著調整。 我們來看下接下來的 MenuItem 程式碼如下: [MenuItem("QFramework/8.總結之前的方法/3.生成檔名到剪下板")] private static void MenuClicked

# Unity 遊戲框架搭建 2019 (三十四、三十五) 9 ~ 10 示例整理

## 第九個示例 目前程式碼如下: ```cs using UnityEngine; #if UNITY_EDITOR using UnityEditor; #endif namespace QFramework { public class ResolutionCheck { #if UNITY_E

Unity 遊戲框架搭建 2019 (四十二、四十三) MonoBehaviour 簡化 & 定時功能

## MonoBehaviour 簡化 在前兩篇,我們完成了第九個示例。為了完善第九個示例,我們複習了類的繼承,又學習了泛型和 params 關鍵字。 我們已經接觸了類的繼承了。接觸繼承之前,把類僅僅當做是方法的集合,接觸了繼承之後,我們的類還可以使用繼承來解決一些問題。 ## 第十個示例 在 Unit

Unity 遊戲框架搭建 2019 (四十四、四十五) 關於知識庫的小結&獨立的方法和獨立的

在上一篇,我們完成了一個定時功能,並且接觸了 Action 和委託、lambda 表示式這些概念。 到目前為止,我們的庫作為知識收錄這個功能來說,已經非常好用了,由於使用了 partial 關鍵字,所以重複的程式碼少了很多。而作為一個可複用的工具庫來說,勉強能夠應付。 通過 partial 關鍵字,理論上

Unity 遊戲框架搭建 2019 (四十八/四十九) MonoBehaviourSimplify 中的訊息策略完善&關於傳送事件的簡單封裝

## MonoBehaviourSimplify 中的訊息策略完善 在上一篇,筆者說,MonoBehaviourSimplify 中的訊息策略還有一些小問題。我們在這篇試著解決一下。 先貼出來程式碼: ```cs using System; using System.Collections.Generic;

Unity 遊戲框架搭建 2019 (五十、五十一) 訊息機制小結&MonoBehaviourSimplify 是框架

我們花了 5 篇文章學習了訊息機制的方方面面。並且完成了一個簡易訊息機制,之後整合到了我們的 MonoBehaviourSimplify 裡。 現在 MonoBehaviourSimplify 有一點框架的感覺了。因為 MonoBehaviourSimplify 在提供訊息功能的同時,決定了專案指令碼中的互