unity腳本框架

㈠ unity 大游戲使用什麼框架

關於Unity的架構有如下幾種常用的方式。1.EmptyGO在Hierarchy上創建一個空的GameObject,然後掛上所有與GameObject無關的邏輯控制的腳本。使用GameObject.Find()訪問對象數據。缺點:邏輯代碼散落在各處,不適合大型項目。2.SimpleGameManager所有與GameObject無關的邏輯都放在一個單例中。缺點:單一文件過於龐大。3.ManagerOfManagers。將不同的功能單獨管理。如下:MainManager:作為入口管理器。EventManager:消息管理。GUIManager:圖形視圖管理。AudioManager:音效管理。*PoolManager:go管理（減少動態開辟內存消耗,減少GC）。缺點:(1)不能管理prefabs。(2)沒有進行分類。更好的實現方式是將一個PoolManager分成:若干個SpawnPool。每個SpawnPool分成PrefabPool和PoolManager。PrefabPool負責Prefab的載入和卸載。PoolManager與之前的PoolMananger功能一樣,負責GameObject的Spawn、Despawn和Trim。要注意的是:(1)每個SpawnPool是EmeptyGO。(2)每個PoolManager管理兩個List(Active,Deactive)。講了一堆,最後告訴有一個NB的插件叫PoolManager--。*LevelManager:關卡管理。推薦插件:MadLevelManager。GameManager:游戲管理。

㈡ unity3d 做項目用不用框架 比如 C#中有MVC結構 還有三大框架 這些 用不用啊

mvc是普遍採用的結構，在做unity3d項目中，建議用這樣的結構來。但是又有別於一般的mvc框架，總之就是要規劃好各層的關系。比如說一個做一個界面，就分成顯示腳本、控制腳本、以及數據存儲腳本等。
unity是非常靈活的引擎，採用樹狀層次關系結構，也也導致不能完全照搬傳統的框架結構

㈢ Unity UI框架（一 窗口層級管理）

多個場景會反復出現相同的UI窗體，多個場景反復載入(復用)

各個UI腳本之間的傳值，容易交錯，耦合度高(UI之間不相互聯系，通過消息傳遞)

要手工控制窗體中間的層級關系(使用棧結構保持控制當前所有需要顯示的UI窗體)

多個UI窗體之間相互疊加，容易出現誤操作(對當前窗體遮擋處理)

窗體自動載入管理

語言的國際化

盡量讓框架本身完成與具體業務無關的事務性工作，讓開發人員只需要專注游戲的業務邏輯

開發最簡版

1.窗體自動載入管理

2.緩存UI窗體

3.窗體生命周期管理

UI框架的核心類設計

1.BaseUIForms基礎UI窗體

2.UIManagerUI窗體管理

3.UIType窗體類型

4.SysDefine系統定義類

鏈接：https://pan..com/s/1-PomcmeBh2Up1S3iHWTHqQ

提取碼：41cf

創建一些文件夾把貼圖素材導入MyAtlas

把腳本素材分別放到

然後定義一個UI基類

還有一個UI管理類先列舉出欄位

然後搭設場景

幾個空節點還有UICamera

Canvans設置為按相機照射UIScaleMode調整為寬高比例縮放match一般是0.5或者按高度適配

相機處理設置為正交模式照射層級只有UI還有記得把相機往後拉一點點不然沒有圖片

然後再Nomal下創建這樣的界面記得定好錨點

在Resources保存為預制體到時候動態載入

然後記得把UI相機的這個去掉

然後添加常量名字

在UIManager添加UI創建方法

創建一個

掛給我們的LoginUI預制體

創一個空節點掛上腳本

因為沒設置窗口激活所以是隱藏的

然後UI層級管理的話要用到棧「先進後出」

Stack<T>

類似於收盤子洗盤子羽毛球筒放進去拿出來

還有類似於槍的彈夾

然後UIManager添加方法有些判斷寫反了又改了改

然後是把常量提取出來定義

我又把他的監聽類添加Transform也可以傳遞語法糖改為C#6

UI基類封裝常用方法

提供一個方法類FindAdd的封裝

然後拿去測試

這里定義一些窗口的常量定義

登錄邏輯

人物選擇界面邏輯

㈣ 現實的unity3d開發使用什麼框架

Unity3D引擎採用「添加組件」開發方式，符合人類思維方法。初學者能夠快速理解並掌握開發原理、流程，是最適合學習的開發模式。

①工程(Project)，一個游戲便是一個工程。開發階段對應一個工程目錄(文件夾)，發布後則對應一個可執行文件。工程是游戲資源、邏輯、玩法的集於一身的綜合項目。

②場景(Scene)。通俗的講場景是游戲中的「關卡」。多數情況下，每個關卡都是單獨的場景。例如游戲中的副本、主城、野外都可以是獨立製作的場景;FC紅白機中的《超級瑪麗》等等。

場景可以是功能性的。這種場景不涉及游戲玩法，但可以在其中執行初始化、熱更新等操作。例如很多手游啟動後，會進入「讀條」、「下載資源」狀態，這便是功能性場景。

場景組成了游戲工程。游戲啟動後，必然會進入到某個場景，游戲至少包含一個游戲場景，可有無限多個場景。

③游戲對象(GameObject)。游戲對象只能存在於場景中，只要出現在Scene視圖中的物體都是游戲對象。場景提供了空間，游戲對象是其中的基本元素。例如花草樹木、子彈手雷、人物Boss、按鈕圖片、爆炸特效等等。游戲對象可以表現出千差萬別的樣貌和功能，形態、體積、功能可以完全不同。

④組件(Component)。游戲對象之所以表現出不同的性狀，是因為其身上掛載的組件不同。組件負責游戲對象的具體和細節體現，是游戲對象最基本的功能粒度。例如場景中的「相機」對象，之所以能夠拍攝場景並呈現到Game視圖上，是因為「相機」身上掛載了「Camera」組。「Camera」組件提供了這個過程的全部功能，功能來自組件而非游戲對象。「Camera」組件掛載到任意其它游戲對象上後，該游戲對象同樣會具備「拍攝」功能。

游戲對象可以看作是很多個組件的「容器」。從Inspector面板中，查看掛載了那些組件。

組件本質是類，必須掛載到游戲對象身上才能工作。游戲運行後，由Unity編輯器負責實例化，無需、也不能手動實例化。並非所有類都可以稱之為組件，例如開發者寫的腳本類，必須繼承於MonoBehaviour類，才能掛載到游戲對象身上；Unity自帶的組件，繼承於Component類才能掛載到游戲對象身上。

這樣，就形成了「游戲」->「場景」->「游戲對象」->「組件」的邏輯鏈條，最終，我們通過「組件」來驅動游戲中的物體，組成千千萬萬的邏輯關系，最終實現我們的游戲。

㈤ Unity教程：Unity開發框架

1.什麼是游戲工程？

工程：Project，工程文件是組織項目的基本方式，基本通過文件夾分類來達到合理整合、分類、維護所需要的資源，另外工程只能被開啟在編輯模式下，因此它面向的是編輯者。

2.如何打開與創建工程？

如果是首次安裝Unity3D引擎，通過點擊 Unity3D圖標將會打開一個默認的工程，通過點擊菜單欄的文件（File）下拉菜單框中的New Project、Open Project、Save Project 來新建，打開及保存一個工程。

12.什麼是腳本？

腳本：Script，腳本簡單的地說就是一條條的文字命令，這些文字命令是可以看到的，可 以使用文本編輯器打開查看、編輯，腳本程序在執行時，是由系統的一個編譯器將一條條的翻譯成計算機可識別的指令，並按程序順序執行。

Unity3D引擎所支持的腳本語言有三種，分別是 JavaScript、C#、Boo。這三種語言都簡單 易用，在開源.NET平台、Mono上運行，編譯迅速。

13.簡述場景、資源、游戲對象、組件間的關系

一個游戲工程可以由一個或數個場景組成，場景是由許許多多的游戲對象組成，這其中包括有我們可見的游戲對象，如角色，建築等，以及那些不可見的游戲對象，例如聲音，而組件 正是通過組織相關的資源來賦於這些游戲對象以不同的功能及屬性。

本教程由中國AR網原創，更多基礎教程請關注！

㈥ unity 大游戲使用什麼框架

關於Unity的架構有如下幾種常用的方式。
1.EmptyGO
在Hierarchy上創建一個空的GameObject,然後掛上所有與GameObject無關的邏輯控制的腳本。使用GameObject.Find()訪問對象數據。
缺點:邏輯代碼散落在各處,不適合大型項目。
2.Simple GameManager
所有與GameObject無關的邏輯都放在一個單例中。
缺點:單一文件過於龐大。
3.Manager Of Managers。
將不同的功能單獨管理。如下:
MainManager: 作為入口管理器。
EventManager: 消息管理。
GUIManager: 圖形視圖管理。
AudioManager: 音效管理。
*PoolManager: go管理（減少動態開辟內存消耗,減少GC）。

缺點:
(1)不能管理prefabs。
(2)沒有進行分類。

更好的實現方式是將一個PoolManager分成:
若干個 SpawnPool。
每個SpawnPool分成PrefabPool和PoolManager。
PrefabPool負責Prefab的載入和卸載。
PoolManager與之前的PoolMananger功能一樣,負責GameObject的Spawn、Despawn和Trim。
要注意的是:
(1)每個SpawnPool是EmeptyGO。
(2)每個PoolManager管理兩個List (Active,Deactive)。

講了一堆,最後告訴有一個NB的插件叫Pool Manager- -。
*LevelManager: 關卡管理。
推薦插件:MadLevelManager。

GameManager: 游戲管理。

㈦ unity如何架構一個游戲

似乎在國內游戲行業所有的新技術出來，都會被首先問到這個問題。這也難怪，在國內做游戲開發就等於做網游開發，這是我們現在的主流。然而這些新技術的發源地恰巧又是以console game為主流，它們或多或少都帶有為console game服務的色彩。這個矛盾一直存在著，就像這個問題一直存在一樣。從大的方面看，Unity，UE這些引擎都屬於泛用型游戲引擎，基本的設計思想和架構都是大同小異。我們可以看一下這些泛用型引擎都可以解決什麼問題。圖形渲染至少在現階段，圖形渲染仍然是最重要的部分，也是唯一能夠看到的部分，所以大家都會拿這個來衡量引擎的優劣。引擎廠商也最喜歡拿這個部分來誇耀它們的引擎如何如何的NB。現在已經不是quake的時代了，圖形渲染技術方面已經沒有什麼秘密，使用的理論性的東西大部分還是以前的理論，只是為了使用顯卡硬體加速和現在的圖形介面(D3D,OpenGL)而做一些特殊的調整。在GPU Gems和Shader X系列講的都是這些細節的技術。場景的管理和可見性判斷還是那些octree，bsp/pvs，bsp/portal或者它們的變種，頂多加入了硬體支持的occlusion query（有些更專業一些，嵌入了第三方的可見性判斷方案)。基本的動畫系統都是skeleton+morph，加上各種動畫融合方法和IK支持。粒子系統各個引擎幾乎一樣（能有什麼本質區別呢）。渲染效率的優化上除了與可見性判斷有關系，就是那些通用的優化方法：盡量減少渲染狀態的切換，按照shader排序渲染，多線程渲染支持。都支持後期處理(hdr, ssao...)。燈光和材質系統，在表現上可能是差別最大的。Unity的材質系統需要自己手寫shader，而UE是通過連接圖形化的shader表達式節點自動生成shader。這似乎很高級，但是如果會連接這些節點，我想已經距離會寫shader不遠了，怎麼能指望我們的美術同志們會用呢。效率方面，這些引擎都不會有什麼本質的區別，包括作為純圖形引擎的Ogre也不例外。真正擔負大量計算工作的是顯卡，引擎所做的工作無非就是讓顯卡盡量不做無用功。也不要認為一個很好的視覺效果和引擎有多麼大的關系，也許他就是一個shader的工作而已。真正好的視覺效果是靠好的美術做出來的。物理模擬PhysX最早想推自己的PPU，也就是物理加速卡，將物理計算硬體化，但後來沒有成功。被NVidia收購後，就將物理加速的重心移到了GPU上。現在PhysX與GPU結合的很緊密，可以真正實現大規模的物理效果。這也使得它成為所有商業引擎，乃至自己開發游戲引擎的不二之選。物理模擬的各種效果，比如剛體鉸接，布料運算，流體運動學等等，都是物理引擎支持的功能，游戲引擎只是將這些功能整合到自己的架構中而已。所以對於物理模擬這方面，所有的引擎應該也都支持的差不多，不會有什麼本質區別。游戲基礎架構和腳本擴展在這些引擎上面製作游戲，主要方法就是依靠引擎提供的基礎游戲架構(場景，游戲對象，資源對象...)，使用腳本加入自定義的游戲邏輯功能。這個基礎架構的思想都是從最早的quake引擎來的，功能上都是大同小異，只是實現上有所差別。Unity使用的是.net平台，UE使用的是私有的UnrealScript。網路通信都有為區域網多人游戲設計的網路通信功能。在實現上，基本上都是基於UDP，建立自己的一套網路協議，支持保證和非保證消息，支持游戲對象的狀態復制和RPC調用。雖然稱其為區域網通信，並不代表不能通過internet連線。一般可以通過外部的配對伺服器或者dedicate server實現internet互聯。這種網路模式與MMO游戲有著很大的區別。首先，這種模式雖然在概念上也是C/S結構，但是並沒有像MMO這樣明確的區分client和server。在這種網路模式上一般構建的都是聯機游戲，就是其中一個人建立游戲伺服器(自己也是client)，其他人連進來開始游戲。其次，這種網路模式沒有為大規模在線提供任何的專門的支持，一般支持人數都在64個以下。如果使用這種網路通信功能來做單機+連線游戲，還是非常的方便的。如果要用來做MMO游戲，這種網路通信功能不可能有任何的幫助，需要完全自己重新建立。所以一般都會拿這些引擎來製作MMO的客戶端。這點就是我所說的最具有console game色彩的部分。綜上所述，泛用型引擎如果用來做console game，那基本上可以滿足所有技術上的要求了。如果用來做MMO，除了作為客戶端引擎，來滿足客戶端的通用技術需求外，別指望更多了。MMO是一個比較龐大的工程，除了客戶端，還有很多技術工作需要自己去完成。回到題目，Unity在MMO製作上相對於其他引擎到底有哪些優勢呢？Dot NetMMO客戶端經常需要添加一些額外的功能，比如自定義的與game server的socket通信，網路消息的整編解編，web訪問，xml解析等等。對於UE來說，由於整個開發環境都是構建在自己引擎的基礎上並使用私有的腳本開發，除非引擎自己支持這些功能(C++支持)，否則沒有辦法僅從腳本層進行擴展。而Unity不同，它整個構建在.net平台上，可以極大地從.net平台的各種支持庫中獲得幫助。需要的功能基本上用.net都可以直接搞定。UnrealScript再強大，也沒有辦法和一個成熟的.net平台媲美。資源管理資源管理可能是MMO客戶端最特殊的需求了。MMO客戶端所使用的資源數量與傳統的游戲不在一個數量級上，並且隨著更新和維護，資源數量還會不斷的上漲。為了不使你的客戶端因為沒有可用的內存或顯存而掛掉，動態的資源調度和管理是必須的。Unity和UE在資源管理的基本概念上都是一致的，就是基於一個場景進行資源管理，場景作為資源引用的根節點，所有被引用到的資源都會在場景載入時被載入，切換場景是使用垃圾回收機制，釋放沒有被引用到的資源。對於單機游戲，這個方法很適合，開發者甚至都感受不到資源是如何被裝載和卸載的。而對於MMO來說就不行了，可能需要根據游戲邏輯細粒度的進行資源裝載卸載工作。Unity提供了場景和資源包(AssetBundle)的動態載入和卸載功能，為高層的手動資源管理提供了可能性。編輯器擴展在剛開始接觸Unity時，它的這種奇怪的IMGUI模式令我很困惑。後來慢慢發現，雖然這套gui並不是非常適合作為游戲界面框架，但是用它來開發自定義編輯器真是再方便不過了。Unity本身的Editor也是全部構建在這套GUI之上的，在Unity中製作一個自定義編輯器幾乎可以是1~2個小時的工作。多平台支持這個似乎不用多說了，是Unity主打的優點。支持的平台非常廣泛，各個平台的構建工作流非常順暢，還可以自定義構建腳本。

㈧ unity 4.x 和 5.x 的c#腳本有差別嗎如果有，差別大嗎

框架改了些，4.0x上的c#腳本可以用在5.0x上，但是有些函數、屬性、方法 會提示你已過時，讓你用其它方法替代，不過即使你不修改 大多數情況還是能直接用的。

㈨ unity3D裡面的腳本編寫是什麼樣的原理運行起來是怎麼樣的呢

非常好的問題，這個涉及到引擎的腳本系統，我自己都沒有完全弄清楚。你只需要知道unity腳本是基於組件的，引擎負責管理組件對象的生命周期，因此你在unity腳本中看到的Awake，Start，Update等方法都會由引擎所調用。
而腳本雖然是C#寫的，但是會被mono編譯成IL，然後目前unity可以選擇IL2CPP，也就是說最終代碼被編譯為C++。這樣的好處是mono的runtime是有缺點的，而且JIT本身是影響性能的。而且還有一個很重要的原因是unity本身是C++寫的，直接編譯成C++比較方便的調用引擎內部的函數。

㈩ Unity教程：Unity腳本程序基礎(三）

中國AR網（www.chinaar.com）連續分享了Unity教程，獲得了火熱的反響,今天再次分享教程《Unity教程：Unity腳本程序基礎》

Unity腳本語言：

Unity3D 目前支持三種語言的腳本程序，包括C#、JavaScript、 Boo,在一個游戲中開發者可以使用一種或者同時使用多種語言來實現腳本的控制。

教程由中國AR網資源教程（http://www.chinaar.com/ZYJC/）分享，更多教程進入中國AR網可以看到，有相關問題也可以在文章後面進行評論。