[转]关于Flash网页游戏开发的一些心得与自己理解的解决方案

[url]http://www.eb163.com/club/thread-16483-1-1.html[/url]


鉴于工作经验的限制，目前所能体会到的Flash游戏项目可以有以下的解决方案

1 游戏整个分视图层，数据层，服务层三层结构
1 视图层创建策略
1）需要的时候重新创建，关闭的时候完全卸载（清除引用）
优点：节省内存
缺点：浪费cpu，因为你每次需要这个组件的时候都要重新创建

2）一次性全部创建，关闭的时候只从显示列表移除（并不清除引用）
优点：节省cpu
缺点：浪费内存

2 数据存储策略
1）数据全部放到服务端，每次窗体初始化后通知服务器获取数据，每次视图需要刷新都通知服务器获取数据
优点：处理逻辑简单，客户端功能单一，只负责显示，开发难度相对小
缺点：对服务器压力巨大，当想实现客户端逻辑的时候比较困难，用户体验差

2）数据缓存在客户端，数据变更的时候刷新缓存数据，这样更新视图层的时候
优点：减小服务器压力，可以轻松实现常规客户端逻辑，用户体验好
缺点：增加客户端处理逻辑，客户端开发难度加大，维护缓存数据麻烦

3 视图刷新策略
1）视图层每次通信保留回调函数，服务器操作成功，回调刷新视图
优点：目前还没发现什么优点
缺点：使各层之间耦合度大大增高，项目层次混乱

2）视图层侦听数据变更事件，事件中包含视图层需要的数据，视图层捕获事件，提取数据更新视图
这种方式需要采用第二种视图创建策略
优点：类似观察者模式，耦合度相对较低
缺点：侦听器的选择是一个问题，侦听器管理是个问题，项目结构混乱

3）视图层侦听数据变更事件，数据存储到统一的共享区中，侦听到事件后，根据事件类型到共享缓存区提取自己
需要的数据，刷新视图
优点：不用过多管理事件中携带的数据，同一管理共享缓存区数据
缺点：因为提取共享数据，全局变量的增多导致耦合度增大，侦听器的选择是一个问题，侦听器管理是个问题

4)视图层不采取任何操作，公开视图刷新接口，依赖外界注入数据，这种方式必须采用第二种视图创建策略
优点：耦合度底，项目结构清晰，不必要管理繁琐的侦听器
缺点：如果数据比较多，那么需要的公开接口就比较多，开发比较繁琐


4 对于真个项目推荐的相对好的解决方案
1 视图创建策略采用第二种，因为相对于资源管理来讲，Flash产品对于cpu的要求要比内存高些，因为FLash重绘一直在好用cpu
内存好用在宏观上讲是固定的，而cpu的处理量每时每刻会跟随者渲染的不同而不同，还有一个原因就是，统一创建出来所有视
图组件可以在游戏的整个运行过程中对每一个视图层进行细微粒度的控制，真个项目的所有元素任你操控

2 数据存储策略会采用第二种，因为服务器可以承受的处理压力是有限的，在现有处理器内存资源情况下容纳更多的用户是一款
Flash产品必须做到的，并且游戏的处理逻辑不可能全部放到服务端的，所以就需要客户端参与逻辑处理，而逻辑处理离不开缓存
数据

3 视图刷新策略采用第四种，这种方式使项目耦合度降低，对游戏元素控制更加主动，对于类似游戏这样的项目就是要达到可以
手动操控游戏里的每一个可控元素，并且项目结构清晰

5 综上所述，总结出来的就是一下的解决方案

一次性创建所有的视图元素，数据缓存在客户端，视图刷新依赖外界注入，当然了 这个只是最基本的处理方式，这其中少不了大量管理
器的参与与调节，我的处理策略是 需要一个跟Flash系统相关的 系统管理器 一个跟游戏相关的游戏主管理器，还有跟具体的游戏逻辑直接
相关的场景管理器，地图管理器，用户管理器，命令管理器，战斗管理器等等