取水楼BLOG

更换了主题之后连一篇文章都没有发过. 不知道是自己早已忘却了以前的感觉,还是不给自己时间.

这是一个伪技术帖.

做过flash开发的同学自然避免不了和Event打交到. 从简单的click到复杂的数据交互,甚至一些框架化结构化都离不开他. 虽说AS3里面提供的事件模型已经好很多了,但有时候仍然嫌他不够好用. 尤其是集中在只能针对字符串类型的事件. 不知道大家有没有遇到过事件名冲突的问题. 虽然这都算不上一个技术问题,但调试起来确实很费劲.

至少在使用signals的时候就不会出现这样的问题. 当然这个并不是为了解决这个问题.  signals让事件不再基于字符串而是基于具体的Class.

这是一个轻量级的事件框架也是Robert Penner提供一种新颖的思想. 用起来感觉也不错,提供不少实用的api. 如removeAll()这样的方法. 但是我还是觉得得看情况选择. 虽然没有看源码但可以预见里面基本上应该是个观察者列表.  那么操作的时候会不会有效率问题?  就好像Hack同学说的, 如果框架里面有很多来自Event, 又全部都是static type, 甚至连冒泡都不被需要的时候,那么这个就非常必要了.

曾几何时碰到过某考题

var dom;

for (var i = 0; i < 6; i++){

  dom = document.getElementById("rect"+i);

  dom.addEventListener("click", function(){ alert(i)});

}

好吧,很显然无论click哪个dom都会输出6. 问题也很简洁怎么解决这问题. 当时没往闭包那想.

dom.addEventListener("click",(function(){

function ff (f) {

var ffv = f;

function av () {

alert(ffv);

}

return av

}

return ff(i);

})());

胡乱写了一下,其实就是这么回事. 说来说去不过就是个作用域的问题. 今天身体不舒服,  随便写一下. 应该还能再简单些.

记得昨天为了解决某个头疼的问题,把许些个代码翻来覆去来一一对应其关系.  对于最后找到关系所在点喜悦,以至解决的畅快感还记忆犹新的时候. 一个结构的问题突兀的来到面前.

对于结构,对于封装. 关键时刻注意力全部都在问题上的时候,这些东西大概早就被我抛到九霄云外. 于是一心只想解决问题的我对于code,没有做反思. 今天提及此问题的时候,明明都是显而易见的东西,当时却一个都没有记起来.

难以理解,是难以理解吧? 果然还只是人类阿, 我还差得远呢.

 这是一个非常基础的问题. 在平时工作中就算是再小的项目里面也会涉及到类型转换. 方法大致也就是类似

  ClassName( instance );  instance as ClassName;

就类型转换而言没什么区别,在我看来也就是报错或是返回null的区别而已.

有的时候用得习惯了,动不动就会吧Int(),Object()这样的玩意拿来转. 别的还好, Array的时候请一定要注意. 这些个东西其实是全局函数,文档上写得很清楚的.

就如同事发我的代码

var a:Object;

a = [1,2];

Array(a).length;

(a as Array).length;

结果显然是输出1,2. 原因就是Array(a); 这个不是说类型转换, 是新建了一个Array. 所以

Array(a)[0].length 这个时候就是2.

各中道理文档上很详细的说. 别出现这种bug, 会让人很郁闷的.

 先上个链接 http://progit.org/book/zh/ 多个平台的安装,使用教程. 已经非常非常全面了.就如链接所显示,是中文的.

大概说一下. Git是一个版本控制工具, 说到这个第一时间想到的就是Svn. 没错,Svn确实是团队开发当中常用的工具. 他们有什么不同呢? Git是一个本地代码库. 他是不需要网络完全在本机运行的一个版本控制工具. 

试想,在开发某一个功能的时候, 这样就可以在一个稳定版本上面切出一个分支, 开发到一半,这时候突然来了一个紧急需求or需要立即修改的Bug. 这样仅仅是切到那个稳定版本,然后修改好那个Bug,如此而已. 然后继续开发新功能,最后再merge到主版本上然后提交到Svn. 怎么样,是不是很方便?

说了优点自然也有缺点. 第一需要去学习Git究竟如何使用,这是有成本的. 然后就是比如我,切出来一个分支来开发功能,但是这个功能搁浅了,开始做其他的功能. 这样经过了一段时间之后, 再回来做这个功能,这时候会发现,这个版本的代码实在是太老,merge的时候全都是冲突. 哎. 也就算是美中不足吧.如果有什么解决方案,还望赐教.

ok,大概就是这么多, 有需求有兴趣或是蛋疼的朋友可以玩一下.

这是连月经帖都不是的长久以来的帖子. 虽然最近身体不适,但是事情却还是不依不饶的一件接一件过来. 有人时候让人心烦意乱.

前端开发工程师,我喜欢这个职位的名称. 这此之前一直都没有去面过这个职位. 总的来说还是对javascript要求比较多.初步试试了一下,情况并不理想.某些方面的知识很不到位.

Quirks这个模式. 盒模式大家都是很清楚的,在ie下会有什么样怪异的情况也都知道. 原来是在这个Quirks这个模式下才会出现. 那怎么进入这个模式呢. 我是一头雾水. 最后才知道 dtd这个玩意没有,那是必然会进去的. ie6如果dtd前面有任何字符也是会进入的.

还有一些http头,tcp. 这个确实没学过,也无从谈起. 值得注意的是以前看过一本性能优化的书, 没有实际操作过所以对其中的门路也是模模糊糊的,比如ETag. 呵呵. 有时间好好看看. 

最后说标题. 这个事件.domTree其实在我理解和displayTree是差不多的. 大家都有事件流, 都有捕获,目标,冒泡这些个阶段. 注意ie丫是不支持捕获的. 然后,domElement.onclik和addEventlistener有咩区别呢?提示是0级别和2级别. 想在as3里也就很难在用到诸如

mc.onclik = function

这样的方法了.不解. 原来0级就是把事件分配到元素本身,到那点了,看有没有合适的执行方法,有执行,唔就拉倒. 置于2级就和as3异常相似了.主要还是相同在那所谓的3个阶段.

那怎么代理呢. 如果你有一个list或tree, 如果用0级那种方式,势必会有很多事件产生.多了就会茫茫然消耗内存. 可以利用冒泡这个机制来把处理函数都丢到Container去处理.等于说就是把本来应该自己做的事情交给Container去做. 在Container里面判断是那个element就ok了. 原理大概就是这样.

没在as里具体试过.现在些as对这个移除已经很小心了. 也许在管理代码上有一定帮助,亦或是在如player背包这样的模块中有一定作用?有待测试.

 上午急急忙忙去听了,回来了工作又很多,中午吃饭回来抽了个时间一气呵成的就这么胡乱写了. 我就不瞎贴文章了,贴个链接,Google doc的,可以改.

去看看

 封闭真的彻底结束了,想起来不知不觉就会有好心情( 你看这折磨的 ). 把生活和工作几乎耦合,说实话其实也带来不了多少效率. 来做游戏有这么一段时间了,最开始的天书,这算是比较成功的一款webgame了.可惜对项目本身涉足不深. 帝国才是一直都有在开发的游戏,航海是被中途借调过去的. 经历了这些个项目, 有些想法,说不上什么心得,就是记录,总结一下.

首先,态度和心态很重要. 我说的不是什么盈利,不是什么推广,不是什么一定要得到多大的收入.仅仅是对于开发人员. 最初我觉得,做游戏赚钱不赚钱基本上和技术无关,有没人来玩,游戏吸引不吸引人都是策划他们的事情.哈哈诚然,技术人员大多数时候都是拿到需求,讨论需求,然后设计,最终进入开发阶段. "我只要完成功能就好好了,其他爱谁管谁管"大体就是这样吧. 我们可以换个角度思考这个问题. 作为一个技术人员, 我们实际上是提供了一个平台. 由于这个平台,策划们的idea和美术的创意才能结合到一起,才能正常,顺利的运行并且展现给玩家. 虽然工作性质没有改变,但至少这是一个积极的心态,能使眼界更宽,考虑问题更加周全.

接着是信息构建和层级. 一个游戏的主界面的空间是有限的. 不可能把所有的东西都放在主界面上. 这样无非就是让页面显得混乱,拥挤,让玩家迷惑,不知从何下手.在功能区(类似网站的导航条),应当保证功能的独立性,就帝国而言,以前功能区有个label叫做"工具"的按钮(图已经找不到了) , 它又和 联盟 , 英雄 , 军队这样的按钮放在一起.我第一次看到的时候就想,这玩意到底是干什么的.结果点开了之后弹出一框, 里面又是一排按钮,进入其他功能区,这就相当让人费解了. 

说信息构建就不得不说到层级,如果客户端使用的是flash,我个人觉得这个层级比较容易控制.能把信息分类,合理的控制在某一层里.比如弹出,窗口,面板或是场景切换,优秀的兼容性也是现在大多数webgame采用flash的重要原因之一. 无论是在天书还好是航海,层级都是最先要设计的.把信息都分开来,放在不同的层级里,开发or管理都是方便的. 特别是有战斗切换的,这个尤其重要. 相对传统网页客户端,我觉得控制起来要困难一些. 那时候经验不足. 没有做信息分类,限制层级也显得力不从心. 在帝国这个项目里出现过茫茫然多的 二级窗口把弹出窗口覆盖的情况 . 一个窗口出现了, 技术策划都不清楚这个到底应该是在哪个区域,大家你看看我,我看看你..哎.

再就是组件,框架这样的东西. 对于帝国来说选用的是jquery这个框架. 说来惭愧,当时对javascript不甚了解.糊里糊涂就用这个了,也没来得及比较. 回过头来看, 选用成熟的框架是可行之举. 可以大大提高开发效率, 风险在于如果出现框架之内的问题就难以入手,修改费劲. 其实碰到这样的问题的机率比较小,一般问题都有多个方法来解决.绕绕也就过去了. 自己开发呢,当然可控性是最高的,没事自己改着玩的都可以,额外的工作量自然也就是它的不足了. 毕竟现在javascript框架多得跟什么似的,有句广告语不是说 "总有一款是适合你的" . actionscript就没什么悬念了,这里框架的meaning和前面的不大相同,这个主要功能是提供合理的OO结构,将代码模块化,解耦化,使应用能够更好的维护和扩展. 虽然官方的,民间的优秀框架不少,但大多数还是选择自己实现为自己游戏定制开发.大体思想对的就好,正乃, 思想在我心中,万变不离其宗(前些日子说是又有什么依赖注入的框架..还没来得及看..人生啊.)

组件嘛,传统网页客户端大多数还是使用DOM,偶尔也有像YUI那样,完全自己实现的一套UI.在游戏里面用的UI并不多,75%几乎都是按钮. 帝国里面按钮全部都是用<a>来定义的(其实我很奇怪为什么要这样), 实在是有需要的就如Tree这样的组件, 但凡是框架都会有各种各样的选择,这个自己写,还是用别人的都是可行的.如果对组件不是很熟悉,其实工作量感觉差不了多少. flash对于组件的要求就要高很多了.自带的组件一般都是不能忍的.除非你用的是flex framework. Aswing是个不错的选择,组件丰富齐全,能够极大的节省开发时间.但是需要一些学习成本, 不是每一个人都用过Aswing并且很熟悉的. 自己写也不错,实际上,天书和航海都是自己写, 可控性只是一方面,甚至我觉得是很小的一方面,在游戏里自己写组件最大的好处在于精简. 前面也说了,游戏里面用到的组件其实并没有多少.有的组件等游戏倒闭了都没出场机会,一辈子做板凳. 这里还是要说一句迷惑大家却又是正确的话: 用什么不用什么,自己写还是使用开源的,都取决于项目本身,根据实际情况而定.

最后嘛说个标准和体验. 标准就只针对帝国了. 有时候真的很不想打开那些个恶心的,看了让人头昏眼花的代码. 都不用验证我就能知道红的肯定是一大片. 上次忘记是谁说的要到手机上试试. 当时心里就想, 你耍吧, 我还想让自己手机的寿命更长一些. 现在也不能追究但是页面为什么会写成这样,css为什么让我修改得这么痛心疾首.  在可能的情况下 能标准一点还是标准一点吧. 如果突然有一天说要支持无线平台,你也许会觉得手机这玩意真是该死,谁发明来着的.

体验就是我们常说常听到人们说的用户体验.这里我就不瞎叽歪什么可用性,自我解释这些东西了.我觉得一款游戏,特别是一款webgame, 流畅是体验的重中之重. 这不仅仅是你页面或是flash加载的速度, 你的代码效率有多高. 是让玩家能顺利的玩下去. 如果让玩家出现 "我现在应该干什么"这样的问题那就不好了.我们应该有个,是应该让玩家有个阶段性的目标,他们为了达到这样的目标才会在游戏里面投入时间投入精力. 任务是个非常好的idea. 就和wow一样,任务能让玩家完成短期的目标,然后到一个新的目标. 问题就在于如何把这个目标清晰的明确的传达给玩家.

好了,先到这里吧. 封闭回来还是没有缓过劲. 写着写着感觉还有遗漏,再补,再补.

 看图片就知道将什么了吧……有兴趣的可以去一下 ,详细点这里 

 话说现在还是在封闭中,心情依旧一般.

记得上周又要做某后台界面, 打开工程,里面全是不认识的代码,一点原来的样子都没有. 看yui都早早的升级到3.x了,由于没有外网,机器上的yui还是依旧杯具的停留在2.6这个版本. 让人看了好是痛心.

又是话说,其实也真就是心血来潮,又想用yui来玩玩. 途中,就开始用完全没用过的一些组件. 例如Calendar , DataTable 这样的东西. 一边看文档一边写,Calendar还好,在使用DataTable的时候我也是如教程上所写 在YAHOO里面定义自己的 namespace , 然后返回一个对象:

{ oDS : , oDT : }

这个 oDS 呢,是 DataSource 的实例 , oDT 当然就是 DataTabl e的实例了. 遇到的问题很白痴,就是到了最后不知道怎么收集 DataTable里面的数据( 现在想起来确实很白痴 ). 也许是太着急了. 也是因为 DataSource 这个名字太引诱人. 看它是和Table一起返回的, 而已实例化Table的时候也是把数据源传到它里面去的. 一心认为从它那里一定能取得我想要的数据. 然后,用for in循环了半天.未果 . 逼不得已自己写了一个数据集来对应表格的操作,得不偿失. 虽然是耍了这么个小手段把问题解决了.

周一,感觉不爽. 这次时间来得稍微多一些, 复又翻文档,胡乱一翻就翻到getRecordSet这个方法.脑袋里顿时轰了一下,靠,以前说用数据集,不都是DataSet 吗.哎. 看来还是封闭久了,脑袋都不灵光. 看见个dataSource就被迷惑了. 惭愧,惭愧.