标签：
场景管理模块需要同时考虑前台和后台
1.对于副本来说，服务器在副本第一次被进入的时候，启动副本进程，所有进入此副本的角色，都会由这个副本进程管理，服务器端只有一份场景寻路数据，人和人之间关闭阻挡，但是角色和场景之间的保留，此场景里的机关呢？这样就是说，客户端会有一个副本的演进过程，从玩家进入场景开始，一个个机关结点触发，到玩家出场景，此副本结束。对于服务器来说，一个玩家进入，触发了一个机关，那么这个信息是存储到这个玩家身上的，所以每个副本都会为进来的每个角色分配数据对象。必然会出现多人同时触发一个机关，如果打开效果开关。那么这里的场景管理的就是数据了。
2.对于开放场景来说，玩家在客户端和服务器都能看到众多的角色，客户端有视锥体裁剪，服务器就没有，但会为每个角色做视野管理，应该是视野范围内，玩家的位置信息会被同步给他视野里的其他对象。
3.从场景设计角度，前后台如何共享数据？后台必然会有一个EntityInstantiate方法，使用它来实例化一个个Instance对象，但这个其实和场景管理没关系，更多的是对象管理服务。那么Scene的职责和功能是什么？为什么要有场景管理，当然了，场景里有哪些东西，哪些物件，当前这个场景的灯光音乐等。
从讲故事来说，皮影戏更合适讲C/S模式的架构， 一个副本就是一场演出，美术拼关组出来的场景是舞台，音乐，灯光等的控制也要放到场景调度里，此副本里的精灵怪也是要配置的，机关也要摆放。后台监控整个过程，走到哪一步终止都是由后台决定。
所以看多了其他游戏的框架，转到这种框架下需要思维上的转变，服务端要连创建都要进行管理。
不要用客户端的思维去想服务器的逻辑，但是由于现在服务器是跑在Unity环境下，因此可以尝试用客户端的思维想想。从概念上来说，地图和场景的关系？一个地图可以跑一个进程的场景
分成两层来看，首先，先不走前后台的思想，而是走从上层往下看，意思就是面向接口进行设计。场景都应该有什么，精灵都应该有什么？独立的组件都有什么，这些都是可以考虑的。交互可以不考虑重点在于接口。游戏世界管理，从一个地方派生，例如 Iworld，从意图上看，实现了整个游戏世界里公共的东西。
场景里会有trigger，玩家碰上这个控制器后，会触发怪物的生成，这应该算是副本里的一种方式。怪物的坐标也需要被编辑出来。
场景里物件的加载机制，是否要分动态加载和整个加载这两种机制呢？首先肯定会有场景物件列表，如果没有动态加载的话？其实不一定，至少这个机制要支持扩展成动态加载。
所以Scene是做成module呢还是service ？
Scene只是一个小功能，这个功能是管理当前场景里静态的，那么动态的呢？里面的怪物的归属关系呢？
数据只是数据，实例化出来的东西会被动态加载或者卸载，所以放在Scene里是比较合适的。SceneModule和其他module平行，还是个公共service，其它module是否都会用到这个module呢。
Scene至少要提供各种LoadScene方法，管理场景里的静态物件？
再进行一次拆分：
IAssetService 属于资源加载层面的内容，所有的资源加载都要通过这个接口来进行
IDataService 属于非显示层面的永久数据文件，即存储在磁盘上的数据，可以认为是被策划编辑出来的数据内容。所有的file都是asset，由IAssetService来加载。
其中会有MapData，即地图数据，存储有monster列表，NPC列表，出生点位置spawnpoint等。
IWorldService属于世界管理器，整个程序在运行过程中都会存在的东西，例如当前场景是什么等。
IEffectService，ISoundService，
精灵设计体系？
标签：
原文地址：http://www.cnblogs.com/designyourdream/p/4546843.html
