aspx/cshtml:前台页面，区别在于编译引擎不同。后者介绍。dll:已编译的程序集。css:样式表。js:脚本文件。mvc3中的配置文件。最常见的有。asax:全局应用文件。ascx:用户控件。母版:母版页。cs/。vb:不常见。当您需要在网站中发布源代码时，会出现其他常见的文件类型，但它们不是必需的，例如:。html:静态页面。xml:xml文件，通常用于保存用户数据。pdb:程序代码调试文件和其他程序定义的文件类型。常用目录:
bin:程序集所在的目录scripts:脚本目录content:css等内容目录(mvc中常见)。
app_code:程序文件目录(*。cs，*。vb)
app_themes:主题目录视图:前台页面目录，mvc中常见:areas目录，mvc中常见。
在unitygames的开发中，我没有t刻意采用mvc框架，因为不像网站开发，模型、视图、控制器在游戏领域还没有明确的定义。原因可能是不同游戏类型的软件架构可以有很大的不同，游戏中的对象之间有大量的交互，所以垂直mvc似乎不是很适合。
但一定程度上需要将代码逻辑分离，这样可以提高代码的可维护性和可重用性。我来说说我自己的一些经历。
假设我们在做一个马里奥:我会对游戏中的人物采用这样的结构。角色管理器，其作用是包含该角色的控制器并提供黑板[1]。控制器，使用可重用的模型来处理这个游戏中角色的某个状态的逻辑。可重用模型是一个虚拟的概念，不是父类。通常这种模型负责一个特定的功能，可以重用，可以看作是游戏引擎的扩展。我将从角色管理器和可重用模型中继承monobehavior，这样我们可以直观地知道这个角色是一个什么样的角色，我们可以使用inspector来调整模型的参数。如何将上述架构应用于马里奥:作为角色管理器，我们可以使用refine状态机或者be。行为树.一个优点是它们都提供了一个"控制器和很自然。比如精化状态机，它的每一个状态都可以看作一个控制器。行为树中的动作节点也可以看作是一个控制器。
在每个控制器中，都会有指向一些可重用模型的指针。比如下图，movestate可以有一个movemotor，专门用于gameobject的移动，而sprite封装了gameobject的性能，比如动画、旋转、位置等等。这些可重复使用的模型通常提供丰富的参数来调整，并可以在不同的游戏中使用。
游戏中的用户输入和消息会临时存储在角色管理器中的黑板上，供角色管理器决定是否需要更换控制器。比如在mario中，我按下左键，向左移动的信息就会被写入fsm的黑板，然后我通过fsms状态转换机制[2]。这样做的好处是，左边的信息可以从输入管理器(图中未显示)或敌方ai管理器(图中未显示)获得。这样，一种类型的fsm(如有空闲、移动、跳转等。)可以用于所有相似的角色，无论是玩家控制的还是ai控制的。
最终在团结会是这样的局面。fsm、sprite和movemotor都是组件，控制器包含在fsm中。虽然上述方案并不严格，但在一定程度上提高了代码的可重用性和可维护性。比如现在我基本都是写movemotor，sprite之类的模型，新项目扔进去就可以用了。将平台游戏中常用的movestate、idlestate、jumpstate等状态进行封装，留下一些可调整的参数，比如状态之间的转换。
[1]黑板本质上是一本字典。[2]原来的fsm会把状态转换直接放在状态中，但这大大降低了状态的可重用性。所以可以尝试用状态的变换作为可调参数。有些可视化fsm的原理也是一样，用连线把两个状态联系起来，然后定义一些变换条。件。
