好吧好吧，又谈到这个问题了，其实早就想写这个博客了，犹豫了好久。在设计游戏的时候我本人是很排斥什么游戏架构设计，mvc什么的，我只想马上动手就把自己的游戏玩法最快的用代码敲出来，还不会出无法挽回的错误，那么下面的步骤可以帮助你构建一个简单的游戏模式架构。
一。首先是数据存储类，如GameManager，UIManager，SoundManager等这些类，这些类是不销毁的，由于这些类为物体组件，用普通的单例模式容易出现实例化的冲突，因此可以首先加载一个数据场景，间隔一段时间后加载第二个正式场景，以后最多的返回也只能返回到第二场景，这样就解决了冲突问题
二。分场景控制类，每个场景中有可能要进行不同的复杂的控制，比如播放个动画，选择角色什么的。比如UI场景，该场景中主要以UI功能为主，设置音量，选择角色什么的，都在该场景中进行，因此可以用个UIScene类的做一些特殊的控制；正式游戏场景，比如在UI场景选择好了敌人，那么现在进入正式打击敌人，冒险什么的，可以建立一个PlayScene场景，该场景用来控制播放个动画次序什么的各种操作。
三。通用类的作用，比如UI控制中物体的隐藏与出现，跳转到另一个场景的操作，销毁物体的操作这些可以用一个GeneralController的集成这些函数，然后作为组件的形式添加到需要的分场景的场景控制的物体上，这一点尤其对UGUI的添加事件很有效。
四。观察者类与数据存储类的静态变量。比如游戏加载后要把当前的语言或者音量设置到相关物体上，那么寻找携带这些数据的Manange类的方式有自带的Find相关类，或者使用数据存储类的instance静态变量，判断该静态变量是否为真，如果为真，那么就说明该类的物体存在，直接调用该静态变量获取到相关需要的数据。
五。为多个物体设置数据。这里涉及到在场景中寻找具有相同标签或者拥有相同组件的物体，这里最好的方式是为每个相同组件的物体添加一个观察者组件，该组件用于当物体生成时，调用相关的管理类，将自己存放到管理类的存储列表中，这样管理类就不用在场景中去寻找这些物体了。
六。对象池。这里并非这篇博客主要内容，只是做个提醒，因为抛开性能问题，上面的的五条对一般游戏来说足够了。对一些长期生成的物体如子弹等最好做成一个对象池，从而提高机器性能。