便宜VPS网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: 游戏管理。
unity3d 网游服务器端如何选择
如果对楼主有帮助，给个采纳好不，谢谢啦
Photon和KBEngineunity3d是最适用Unity3d游戏开发的两个服务器引擎，但它们还是有区别的，只有清楚地了解区别在哪才能正确使用，下面简单描述下两者的共同点和不同点。
语言
对于大部分的程序员语言简直就是宗教信仰。
Photon使用C#开发，当然使用者也是用C#进行各类游戏功能开发。前后端同种语言，这对使用Unity3d游戏开发也有很大的好处。
KBEngine使用C++开发，逻辑开发是用python，也是很不错很快速的。
开源与收费情况
Photon是Exit Games公司的产品，不开源，有好多种收费模式，官网上可以看到。开发阶段可以用免费的license，后期可以看流量用户活跃度来选择付费模式。后续的支持，似乎是免费的，你可以选择邮件或是到论坛发帖求助，当然是E文。
KBEngine是国人开发，开源免费，但从官网上并没有看到商业使用的案例。有中文论坛，你可以在论坛上向开发者求助。
虽然两者的模式不同，但作为一个Unity3d游戏开发者，我们最希望的其实是把游戏引擎当作一个安全稳定的黑箱。
操作系统
之前说了Photon使用C#开发很自然的，配套的工具也是使用C#，比如最重要的PhotonControl。所以开发环境和生产环境最好都是windows。
虽然在跨平台上有mono，在服务器代码部分是系统无关的，但是不管你信不信，我是不信它的一套窗体工具也能运行在Linux下。反正，官网说法是，开发和生产环境都是用windows。
KBEngine建议开发环境选择Windows，生产环境选择linux。毕竟你总不希望开一组服务器打开9个Console窗体，一不小心把哪个点X了吧～
协议
Photon有自己的序列化反序列化方式，你也可以使用protobuf这类的来做应用层传输协议。
KBEngine在这方面表示不支持自定义协议，它帮你选择了有效的方法来处理，如果你习惯了他规定的方式，会喜欢上的。
看法
在功能上，我毫无疑问地更喜欢KBEngine，脚本化和自动持久化是极富魅力的功能。而Photon几乎没做这方面的功能，可能和老外的观念有关系。就目前我对两者功能的理解看来，Photon其实是个和SuperSocket差不多的东西，而SS是作为轻量级服务器框架存在的，Photon却是说自己是Unity3d游戏引擎，除去提供的MMO示例代码(未解读)，没看到什么游戏引擎的魅力。
现实的unity3d开发使用什么框架
Unity3D引擎采用“添加组件”开发方式，符合人类思维方法。初学者能够快速理解并掌握开发原理、流程，是最适合学习的开发模式。
①工程(Project)，一个游戏便是一个工程。开发阶段对应一个工程目录(文件夹)，发布后则对应一个可执行文件。工程是游戏资源、逻辑、玩法的集于一身的综合项目。
②场景(Scene)。通俗的讲场景是游戏中的“关卡”。多数情况下，每个关卡都是单独的场景。例如游戏中的副本、主城、野外都可以是独立制作的场景;FC红白机中的《超级玛丽》等等。
场景可以是功能性的。这种场景不涉及游戏玩法，但可以在其中执行初始化、热更新等操作。例如很多手游启动后，会进入“读条”、“下载资源”状态，这便是功能性场景。
场景组成了游戏工程。游戏启动后，必然会进入到某个场景，游戏至少包含一个游戏场景，可有无限多个场景。
③游戏对象(GameObject)。游戏对象只能存在于场景中，只要出现在Scene视图中的物体都是游戏对象。场景提供了空间，游戏对象是其中的基本元素。例如花草树木、子弹手雷、人物Boss、按钮图片、爆炸特效等等。游戏对象可以表现出千差万别的样貌和功能，形态、体积、功能可以完全不同。
④组件(Component)。游戏对象之所以表现出不同的性状，是因为其身上挂载的组件不同。组件负责游戏对象的具体和细节体现，是游戏对象最基本的功能粒度。例如场景中的“相机”对象，之所以能够拍摄场景并呈现到Game视图上，是因为“相机”身上挂载了“Camera”组。“Camera”组件提供了这个过程的全部功能，功能来自组件而非游戏对象。“Camera”组件挂载到任意其它游戏对象上后，该游戏对象同样会具备“拍摄”功能。
游戏对象可以看作是很多个组件的“容器”。从Inspector面板中，查看挂载了那些组件。
组件本质是类，必须挂载到游戏对象身上才能工作。游戏运行后，由Unity编辑器负责实例化，无需、也不能手动实例化。并非所有类都可以称之为组件，例如开发者写的脚本类，必须继承于MonoBehaviour类，才能挂载到游戏对象身上；Unity自带的组件，继承于Component类才能挂载到游戏对象身上。
这样，就形成了“游戏”-“场景”-“游戏对象”-“组件”的逻辑链条，最终，我们通过“组件”来驱动游戏中的物体，组成千千万万的逻辑关系，最终实现我们的游戏。
