項目運(yùn)行時頁面是哪個？Aspx/cshtml:前臺頁面，區(qū)別在于編譯引擎不同。后者介紹。dll:已編譯的程序集。css:樣式表。js:腳本文件。MVC3中的配置文件。最常見的有。asax:全局應(yīng)用文件

項目運(yùn)行時頁面是哪個？

Aspx/cshtml:前臺頁面，區(qū)別在于編譯引擎不同。后者介紹。dll:已編譯的程序集。css:樣式表。js:腳本文件。MVC3中的配置文件。最常見的有。asax:全局應(yīng)用文件。ascx:用戶控件。母版:母版頁。cs/。vb:不常見。當(dāng)您需要在網(wǎng)站中發(fā)布源代碼時，會出現(xiàn)其他常見的文件類型，但它們不是必需的，例如:。html:靜態(tài)頁面。xml:XML文件，通常用于保存用戶數(shù)據(jù)。pdb:程序代碼調(diào)試文件和其他程序定義的文件類型。常用目錄:

Bin:程序集所在的目錄scripts:腳本目錄content:CSS等內(nèi)容目錄(MVC中常見)。

App_Code:程序文件目錄(*。cs，*。vb)

App_Themes:主題目錄視圖:前臺頁面目錄，MVC中常見:Areas目錄，MVC中常見。

如何在Unity中實(shí)現(xiàn)MVC模式？

在Unity games的開發(fā)中，我沒有 t刻意采用MVC框架，因為不像網(wǎng)站開發(fā)，模型、視圖、控制器在游戲領(lǐng)域還沒有明確的定義。原因可能是不同游戲類型的軟件架構(gòu)可以有很大的不同，游戲中的對象之間有大量的交互，所以垂直MVC似乎不是很適合。

但一定程度上需要將代碼邏輯分離，這樣可以提高代碼的可維護(hù)性和可重用性。我來說說我自己的一些經(jīng)歷。

假設(shè)我們在做一個馬里奧:我會對游戲中的人物采用這樣的結(jié)構(gòu)。角色管理器，其作用是包含該角色的控制器并提供黑板[1]。控制器，使用可重用的模型來處理這個游戲中角色的某個狀態(tài)的邏輯?？芍赜媚Ｐ褪且粋€虛擬的概念，不是父類。通常這種模型負(fù)責(zé)一個特定的功能，可以重用，可以看作是游戲引擎的擴(kuò)展。我將從角色管理器和可重用模型中繼承MonoBehavior，這樣我們可以直觀地知道這個角色是一個什么樣的角色，我們可以使用inspector來調(diào)整模型的參數(shù)。如何將上述架構(gòu)應(yīng)用于馬里奧:作為角色管理器，我們可以使用Refine狀態(tài)機(jī)或者Be。行為樹.一個優(yōu)點(diǎn)是它們都提供了一個 "控制器和很自然。比如精化狀態(tài)機(jī)，它的每一個狀態(tài)都可以看作一個控制器。行為樹中的動作節(jié)點(diǎn)也可以看作是一個控制器。

在每個控制器中，都會有指向一些可重用模型的指針。比如下圖，Move State可以有一個Move Motor，專門用于GameObject的移動，而Sprite封裝了GameObject的性能，比如動畫、旋轉(zhuǎn)、位置等等。這些可重復(fù)使用的模型通常提供豐富的參數(shù)來調(diào)整，并可以在不同的游戲中使用。

游戲中的用戶輸入和消息會臨時存儲在角色管理器中的黑板上，供角色管理器決定是否需要更換控制器。比如在Mario中，我按下左鍵，向左移動的信息就會被寫入FSM的黑板，然后我通過FSM s狀態(tài)轉(zhuǎn)換機(jī)制[2]。這樣做的好處是，左邊的信息可以從輸入管理器(圖中未顯示)或敵方AI管理器(圖中未顯示)獲得。這樣，一種類型的FSM(如有空閑、移動、跳轉(zhuǎn)等。)可以用于所有相似的角色，無論是玩家控制的還是AI控制的。

最終在團(tuán)結(jié)會是這樣的局面。FSM、Sprite和MoveMotor都是組件，控制器包含在FSM中。雖然上述方案并不嚴(yán)格，但在一定程度上提高了代碼的可重用性和可維護(hù)性。比如現(xiàn)在我基本都是寫MoveMotor，Sprite之類的模型，新項目扔進(jìn)去就可以用了。將平臺游戲中常用的MoveState、IdleState、JumpState等狀態(tài)進(jìn)行封裝，留下一些可調(diào)整的參數(shù)，比如狀態(tài)之間的轉(zhuǎn)換。

[1]黑板本質(zhì)上是一本字典。[2]原來的FSM會把狀態(tài)轉(zhuǎn)換直接放在狀態(tài)中，但這大大降低了狀態(tài)的可重用性。所以可以嘗試用狀態(tài)的變換作為可調(diào)參數(shù)。有些可視化FSM的原理也是一樣，用連線把兩個狀態(tài)聯(lián)系起來，然后定義一些變換條。件。