经验(转)


    大约1年前(07年3月),有了想使用Flash做网页游戏的冲动。于是研究了AS2,经过了解,感觉AS2做网页游戏还是有不少欠缺的。这时又得知了AS3,如获至宝。对于有Java开发经验的程序员,尤其是开发过Java客户端的程序员,AS3真是太合适做游戏开发了。
    后来公司也上了Flash MMORPG的项目,于是就开始学习AS3的语法和库,学习Flex工具。有了Java的经验,这些就很快了。
作为Flash网页游戏,不单单是炫酷效果的展示,用户的交互和逻辑也很多,因此好的游戏一定离不开AS3代码的。 磨刀不误砍柴工,我建议大家在真的动手开发项目之前,把该看的文档都看一遍,顺便写一些测试代码加深理解。建议的文档和理由如下:
        《Adobe Flex Help》。这个就是Flex自带的帮助了,看了这个,就知道如何使用AS3来创建,编写,编译,调试,发布应用程序。使用AS3,哪些东西能做,哪些东西不能做;哪些东西可以直接用现成的,哪些东西需要自己来开发。有些人习惯遇到文字再查帮助,或者GOOGLE,或者到论坛提问。其实提问也是有学问的,你能把问题描述的越准确,就能越快的得到准确的答案。
        《ActionScript 3.0 Cookbook》和《Essential ActionScript 3.0》,AS3的基本语法,常用功能,一些作者的心得。看了这些,很多问题就可以不求人了。看书的时候,那些立刻需要使用的,最好记下来;那些暂时用不到的,知道用的时候去哪里找答案就可以了。
    下面具体说说以我认为开发Flash网络游戏需要掌握的技术吧。
1.显示
  一个游戏离不开显示,AS3已经为开发者提供了一个比较完整的2D显示引擎了。学习这个部分,学习显示列表,学习DisplayObject和DisplayObjectContainer的区别,学习Shape, Sprite, MovieClip, Bitmap这些基本可显示对象的区别。
2.鼠标输入
  交互就离不开用户输入的处理,鼠标是游戏中最常用的输入设备。需要知道只有继承自InteractiveObject的对象才能接收鼠标消息。还要学习如何使用鼠标拖拽,如何判定鼠标消息产生的目标,如何启用,禁用鼠标消息。鼠标坐标的全局和局部的转换。
3.键盘输入
  键盘除了标准UI组件内部会用到,游戏的快捷键等功能也需要用到。
4.位图
  作为游戏开发,可能不是所有的美术素材都是在开发阶段就固定的,或多或少需要在游戏过程中对图形进行一些变换处理。因此需要熟练掌握Bitmap和BitmapData对象。
5.层
  作为MMORPG游戏,不同可视对象之间是有层次关系的。不同层的关系是固定的,比如地面层,人物层,UI层。同一层上的物体重叠时,需要通过修改在显示列表中的相对位置来调整上下关系。
6.UI组件
  按钮,输入框,文本框,下拉框,列表,表格。这些在游戏中都少不了。为了游戏画面的美观和风格一致,通常都需要修改标准组件的皮肤,才能应用到游戏中。
7.资源加载
  大家都知道,传统客户端MMORPG游戏,动辄几百M上G的尺寸,大部分都是媒体资源,我们不可能把这些资源都打到一个SWF文件中,因此需要根据资源的重要程度来决定加载策略。最常用最基本的,程序启动时加载;其他的,可以在游戏过程中动态加载。
8.事件机制
  作为新人,或多或少都会用到addEventListener方法。作为大型系统开发者,一定要知道这个方法背后的IEventDispatcher接口和EventDipatcher类。使用事件机制进行开发,一方面为了降低代码之间的耦合,另外也是方便了多人协作开发。
9.远程通讯
  作为MMORPG的通讯方案,需要考虑效率和安全性。由于服务器端我们很熟悉Java的Socket开发,而且看到了AS3的Socket类,于是毫不犹豫的选择了使用私有协议的通讯方式。作为MMORPG,基于HTTP的协议效率肯定比直接基于TCP的二进制协议低。另外,基于HTTP方式,不太适用于服务器向客户端推消息的情景。AS3的其它通讯方式我了解的不太清楚,不知道是否有在灵活性,安全性,性能方面超越Socket方案的。
10.性能优化
  作为商业游戏,需要考虑到玩家环境的千差万别,因此系统的很多效果都需要有参数可以控制,使得程序能流畅的运行于玩家的机器上。作为Flash网游,需要考虑客户端的内存占用和CPU使用,需要考虑服务器的流量和客户端到服务器的带宽。
11.多线程
  首先,Flash没有多线程,是一个单线程,如果有时候需要实现类似开一个线程进行耗时的复杂计算时,可以将这个计算封装成一个类,提供一个step方法,每掉用一次step,执行若干步计算,手工为代码分配时间片。用这种方法来模拟多线程。
12.高级知识(js/jsfl/swf格式/加扰/虚拟机运行机制)
  作为一款产品,在开发过程中还有很多细节需要考虑。
  比如使用ExternalInterface与JS通讯。Web游戏,离不开网页的,偶尔还是会与网页有些交互的。
  使用JSFL批量生成或者处理Fla项目文件。游戏中大量的资源的格式是类似的,如果完全由人工,需要大量重复劳动。幸好Flash提供了JSFL的扩展,帮我们节约了大量的人工。
  对SWF格式的理解。有些工作,由于JSFL的可编程性比较差,无法完美实现,我们还编写程序直接对SWF文件进行操作。曾经有一个需求,需要四个人花一周时间才能搞定,而且还很容易出错,后来写了JSFL脚本,外加编程直接处理SWF,每次进行类似的工作,只需要一个人几分钟人工,程序跑1个小时就搞定了。
  商业产品发布时,还是要代码加扰的。现在反编译先锋Sothink4/ASV6已经问世,但是AS3加扰的工作还远远落后于反编译的步伐。我们这些Flash开发人员很着急呀。
13.算法
  算法对于游戏开发还是很有用的。有时候是效率的提升,有时可能是01的区别。

    就简单说这么多了,真要展开了讲,能写一本书了。这里只是给大家说说个人走过的路,不一定全对,只是希望帮助大家少走一些弯路。

****************************************************************************************

问:

楼主使用什么UI框架呢,我想使用aswing,但是没有深入过,不知道性能和风格定义方不方便。

感觉flash的外部资源加载效率不行,每读取一个文件都有120ms左右的固定开销,只能把图片拼起来。
在浏览器中读取大二进制文件也有些异常,曾经试过把地图数组用ByteArray保存,大概200k,在独立播放器中正常,ie和firefox均异常,换成一张小地图就都正常了,不知道是不是bug。

答:

普通的面板都是自己用Sprite拼的,一些控件,用的标准控件,标准控件是可以直接在flash中修改皮肤的
没有使用特殊的UI框架,不希望引入额外的代码

关于资源的加载,开销是不可避免的。拼图也是比较常用的方法。
二进制我们是通过Socket传输的,没有走Loader
使用Loade加载几兆的swf是肯定没问题

swf在独立的Flash播放器,在IE浏览器,Firefox浏览器中运行时,下载和内存管理等方面是有一些区别。
IE和Firefox异常,经常是由于Flash需要的内存过多,无法及时分配新内存导致。

******************************************************************************************

基本上赞成楼主的看法,我现在开发的flash网游基本上也是这个架构,特别是socket通信方面,还有,我以前也是做java的,来做as3,感觉很亲切。一些设计模式可以很好的延续,唯一感觉有点突兀的是他的事件驱动的异步性。

有一点不太一样,ui组件都是我们自己写的,用flex和aswing都很大,我们还是觉得统一自己写,主要用sprite绘,然后用png拼背景
还有,很多ui组件可以用html来代替的,通过as和js通信,然后用textField的htmlText来制作,这样的组件轻便又灵活。

答:

纯AS3比较好,如果跟JS交互,有的用户会死活无法成功加载JS的
至于UI,其实不在乎大小,aswing还是不错,自带的UI性能问题比较多,基本无法在游戏中直接应用

******************************************************************************************

最近一直在开始mmorpg游戏,感觉用flash开发大型的游戏还是有很多的潜在的bug,
还是做小项目比较好。至少 ...

答:

潜在的BUG一定不是大问题,否则Adobe一定会解决的。做大项目,总要考虑性能规划的,以Flash MMO为例,200M内存,可以支持多大的场景图,80X120位图多少张,这些决定了地图的尺寸,人物动作数量,角色形象数,每个动作每个方向的帧数。游戏素材的规格不是随随便便设置的,至少天书最初的版本是算出来的,才能保证内存稳定在150M~200M,现在很多Flash游戏,动辄内存超过500M,会导致很多用户体验不流畅的。

******************************************************************************************

该用啥用啥,Flash全套的工具基本就是制作2D游戏的利器,几乎可以不用自己开发任何场景编辑器,动作编辑器,UI编辑器了,只需要开发辅助工具、导出工具也是可以满足需求的。

会不会用Flash会影响你发展的高度。知道的越多,才能用得更好。

这个问题要从人眼感觉抖动的原因来分析
第一种情况是常说的屏幕撕裂,就是垂直同步的事情,可以简单理解为显存的数据更新跟屏幕的绘制刷新缺少同步,一次屏幕刷新的结果可能是多次显存更新的片段集合,这种情况只能使用更接近垂直同步的机制来绘制。Flash游戏一般有两种方式,一种是利用Flash的DisplayList,一种是自己完全用Bitmap/BitmapData来绘制,前一种是Flash内置的,支持脏矩形合并,在画面变动不大的情况下,效率很高,第二种方式在Flash 9的年代,对于画面变动大的情况,效率较高,在Flash 10的年代,已经没有明显优势,反而CPU占用更高。天书CPU占用不高,是采用了前一种方式。总之,减少地图面积,使用高效的绘制方案是解决这个问题的有效方法。
第二种情况是因为人眼对于不平滑的变化会感觉不适。这个也有若干方法来改进,比如天书采用的镜头跟随,镜头的变化是独立于人物移动的,镜头的变化速度是平滑的,不会出现瞬间从0变到4,而是0->1->2->3->4逐渐变化的,而且x和y两个方向要分别保持平滑;此外背景图片的对比度也不要太高,太高的对比度变化,会加剧人眼的不适应;移动速度也应该适中,动得太快,也会加剧人眼的不适应。
基本从这几个方面来综合解决,就能改善效果了。
又想地图大,又想人物移动速度快,又想背景对比度高,又想让人眼感觉舒服是不现实的。
有些规格是技术来决定的,而不是美术和策划。

posted @ 2011-05-18 23:09  Do.else  阅读(405)  评论(0编辑  收藏  举报