云海航行Q+伟的幻想乡

热爱探索未知事物的coder 、 writer 、watcher and thinker
posts - 16, comments - 6, trackbacks - 0, articles - 0

2012年12月11日

http://www.qiujiawei.cn/blog/2012/12/08/dongfang-1/

posted @ 2012-12-11 13:05 Q+伟 阅读(261) | 评论 (0)编辑 收藏

http://www.qiujiawei.cn/blog/2012/12/06/mc-1/

posted @ 2012-12-11 13:05 Q+伟 阅读(256) | 评论 (0)编辑 收藏

http://www.qiujiawei.cn/blog/2012/11/23/gdc-1/

posted @ 2012-12-11 13:04 Q+伟 阅读(199) | 评论 (0)编辑 收藏

http://www.qiujiawei.cn/blog/2012/11/06/gea-1/

posted @ 2012-12-11 13:04 Q+伟 阅读(233) | 评论 (0)编辑 收藏

http://www.qiujiawei.cn/blog/2012/11/06/gea-2/

posted @ 2012-12-11 13:03 Q+伟 阅读(234) | 评论 (0)编辑 收藏

2012年10月21日

http://voyagingmk.github.com/blog/2012/10/20/work-employex/ 

posted @ 2012-10-21 17:30 Q+伟 阅读(206) | 评论 (0)编辑 收藏

voyagingmk.github.com

posted @ 2012-10-21 16:47 Q+伟 阅读(224) | 评论 (0)编辑 收藏

2012年9月19日


      这两年对我而言,除去一个男子大学生的日常生活(逃课?打游戏?把妹?),最大的事就是遇到一些人并且一起搞了个独立游戏工作室,而后风风火火地做起了单机游戏,完全是跟随己心。因为伙伴表现出来的热情,使我开始燃起了游戏人之魂,心里多了一个方向:制作出具有时代影响力的游戏,给予玩家纯粹的快乐与感动。
      其实这个方向大一的时候就考虑过了的,但这才是梦想行动的开端。
      借助个人的兴趣和毅力和对未来的盼望,还有各位伙伴的努力,工作室先后制作出了《东方千⑨谭》,《缤纷乐豆》,《C盘保卫战》(严格来说不算工作室出品,但开发的主力确实是工作室的三个元老)。虽然这几个作品都没能对游戏行业造成任何冲击,但是这是我的这两年时间,唯一值得拿出来显摆的成就。可以说,我这两年心思都耗在这里了,其他领域没多少作为。
      很可惜的是,今天我告诉你我们工作室散伙了。
      这个结果的产生,不是因为外力或者特别因素(父母反对/没钱没资源/成员失踪了),反而是我们几个元老一手造就的。
      但相信我,这一路走来直到崩盘的前一刻,我们都很用心地在往游戏制作这个方向努力着,甚至还有除了游戏开发之外的事情,创业方法学、团队管理等。
      要说这个解散最大的原因,就是因为我们太较真了,我呢不断地跟自己说,“真要创业,真要成为云海航行的技术总监,你现在的实力远远不够!”,然后就不断地自我进取;我们的leader差不多也是,也是给了自己压力。曾经我们一起去找过一位创业多年的前辈,了解了一堆什么营业额啊、创业证啊等乱七八糟的东西,那个时候才知道创业多么复杂。
      正是因为我们很努力地去研究游戏,才明白自己的实力所处的层次。
      正因为我们越去做一些从没做过的事,才越知道自己真正想要的是什么。
----------------
      老大今年8月份有一天找我聊了一个早上,跟我说了他的很多感受和一些他自己的情况,然后就跟我说,他想解散这个团队。当他说出这个决定的时候,前面的铺垫陈词我都给忘光了,脑海里只剩下一个问号:
   难道就这样结束了?
      此后我花了一个月时间来思考很多东西,我们这个团队、团队里的每一个人、游戏行业现状、如何拯救这个团队、自己的路等,才发现其实我们这个团队,尽管各个人都很有才华实力都不错,但其实算不上很同心,有价值观的问题也有性格不相容的问题。
      元老里有两个超级日系控,我呢属于包容万贯,会喜欢日本的动漫游戏,但也喜欢欧美的东西,所以我通常对某两人经常讨论某某CV最近担任什么角色某部动漫怎么样的深度宅聊,挺反感,3个人走一起都插不进嘴的,后来我就干脆发展到无事不登三宝殿了。这只能算是性格合不太来,没有谁对谁错。
      另外,虽然大家似乎都是认同团队的核心理念,“带给玩家更纯粹的快乐、感动和盼望”,但在实际的做法上,都有点互不认同。我们一个师弟一直跟我提说,”我对做那啥同人游戏一点都没兴趣”。还好后来团队不叫同人游戏社团了,变成独立游戏工作室了,要完全自主设计开发游戏,这样子大家都同意了。但后来,开始做游戏策划的时候,又发生分歧,故事设定被说是中二了,这事貌似搞得很别扭,后来一直谈不妥,我作为做程序的,懂得也不多,只能看着着急。
      挺多烦恼的,各种不容易。
      真要把团队做到和‘顽皮狗’一样的扁平结构,不做框框条条,而又良性发展,太不可思议了。
所以,团队既然成了这个鸟样,确实也该整改或者解散了。
---------------
      直到前两天晚上,我们终于开了一个小会,到场人数不齐,但相谈甚欢。老大一来就提了一串问题,“什么是理想?“,”理想化的理想是不是理想“,围绕这个问题就争执了一个钟:
首先是两个词的定义,”理想“和”理想化“。
假如有一个学生,他每月有1500的零花,然后他说他的理想是买一架250块的单车,算不算理想?
假如有一个运动员四肢健全,他说他想成为刘翔,这是理想吧,但是有一天他瘸了,这个理想还是理想吗?是变成了梦想还是妄想?
      什么叫理想化?理想化是一个动词还是形容词?
      我的理解是,理想是不能脱离实际的,而且要从当事人出发,考虑实现目标的难易程度;而理想化,可以举一个例子来解释,高中物理就会有很多理想化假设,如假设物体间没有任何摩擦、假设不考虑空气阻力。可见理想化这个动词的意思大概就是,忽略妨碍了目标实现的一些因素;理想化应该是一个动词= =。
      理想化和理想都搞清楚之后,考虑一个问题,为什么我们小时候我们家长总说,”娃儿啊,你要有理想啊,要光宗耀祖啊“,邓小平呢说,”希望全国的小朋友,立志做有理想、有道德、有知识、有纪律的人,立志为人民作贡献,为祖国作贡献,为人类作贡献“。
      然而,当我们大学生了,我们跟父母、跟亲人、跟朋友说,”我想读研读博当一名科学家“,”我想创业我想成为李开复“,“我想做游戏,成为宫本茂一样的游戏制作人”,然后他们有一些人会说,“你太理想化了!“。
这样子,他们是希望我们不要理想化地去追逐自己的理想?(这里似乎有些陷阱)
我的最终理解是:
      理想是一个具体的目标,当一个人在考虑这个目标的实现所涉及到的因素、且认为其中的负面因素远远大过正面因素的时候,会判定想完成这个理想的人是理想化了。(注意,下这个判断的人通常不会考虑那个有理想的人的决心,这个关键因素)。客观来说,一个目标的实现确实有很多因素,而一个人,作为人类,只能考虑到其中的一些方面,所以所谓的理想化并不是客观的判断,而是主观的。而具备理想的那个人其实并不该期许,别人告诉他他的理想可不可行,毕竟两个具有不同生活经历的人考虑事情的全面性是不一样的。
      再换个角度讨论,根据当前物理学,物理规则是确定的,一个物体的下一个状态是可以从当前状态推算出来的,理论上。可以判断,世界的未来是已经确定的,并不存在什么改变未来的事。所谓上帝不掷骰子。
但很神奇的是,似乎人类确实拥有改变自己命运的权力,励志的故事也看过不少了,看起来那些成功的人确实是按照自己的想法努力去做,从而获得成功的。
这是个有意思的问题,我之前有一篇博文也讨论过。
      唯物地来说,我们的理想是不是可以实现的,已经在物理规则下保证是确定了的,是或不是。而我们现在对理想的实现的可能性的讨论,就是因为我们并不能全知全能,只能根据我们有限的认识,去做推论或者是猜测。任何人跟你说,你做事太理想化了,你都可以反驳他,”我们都不是上帝,只有上帝才知道我是不是理想化了"。
但是,也因此说明,我们唯一能做的,就是尽量考虑到实现目标的所有关联因素,并且不断地给自己增加成功的筹码、提升正面因素的比例。另外,还有一件反而成了唯心的东西是必须重视的,那就是信念,实现理想的信念远比大部分的因素都关键。
      除此之外,你跟对你的目标的实现毫无关系的人,阐述你的见解、解释你为什么要这么去做、解释你为何这么有信心,那都是在浪费口舌。
      而我确定,那晚坐在那里的几个人,包括我,都是有理想的。
      而其中有一个人,他的信念是非常强的。
      好了,回到我们工作室的最后一次会议上。在我们都觉得讨论得很累的时候,boss终于说了,
他说,
   "我郑重宣布,
   云海航行从今天开始正式解散。
   不做解释。“
--------------

      对各位支持着我们的兄弟朋友们说声抱歉了,我们是虎头蛇尾了。还有进过我们工作室的每一个人,希望能冷静接受这个决定。可能现在我们难以接受,但总有一天会互相理解的。
      大家也别替我们难过,其实,至始至终,我们每个人对游戏的心都是狂热的,我们的关系没有破裂,我们仍然经常一起打游戏聊游戏,以后呢,我确定,我们都会在游戏行业里发光发热。
      说不定,今日团队的解散,正是多年后云海航行王者归来的一个伏笔。


posted @ 2012-09-19 20:24 Q+伟 阅读(270) | 评论 (0)编辑 收藏

2012年9月6日

本文主题主要是跟unity3D的一个扩展插件NGUI相关,在我这个版本的NGUI中的一个example:
Example 7 - Scroll View (Panel)
演示了如何实现一个可以拖动的panel。步骤就是,在一个普通panel对象添加一个IDraggablePanel组件,进行一些设置后,再在该panel节点下添加一些content,如UISprite,UILabel(可以加多一层UIGrid来自动对齐),这些content对象必须赋予一个组件UIDragPanelContents,和box Collider, 前者是NGUI可拖动面板相关的必要组件,添加即可,不需要设置;后者是用来触发事件的,如果不添加collider,按住这个content(可能是一张图片)会无法进行整个Panel的移动,而我们需要的是,再Panel的裁剪范围里的可见对象,按住它后可以移动整个面板(非常常见的一种功能吧)。

以上功能的实现还是比较容易的,稍微熟悉NGUI的人都可以按这个步骤做出来。但是会出现一个问题,当一个content移出panel裁剪边界后,它仍然处于可响应状态,尽管它已经被裁减、已经隐形了。原因就是,这个content的box collider仍然是active的。虽然看不到该对象,但组件是激活状态的。

 
(绿色框就是box collider,那些出界了的、隐形了的方块仍然是可以被点到的)
NGUI的这个example对此的解决方案是,在这个panel的轴向上的两个端点处,加了两个空的gameobject,并添加box collider,来遮挡本来出界了的content。
 
(2把1给挡住了= =)
这真是尼玛的坑爹啊!!!!

难道要每实现一个draggable panel都要在两端加这么一个玩意?而且这两个box collider可能会挡到其他控件。实在是不可取。 
不考虑NGUI这个坑爹的方法,第一种解决方案是:
panel里的content出界后,disable掉它的box collider。这个方案也有问题,因为有可能一个content面积巨大,尽管它的一大片面积已经移出边界了,但是还有相当一部分面积还在panel里面。这时候我们需要的效果是,按住剩余的可见的那部分,还是可以拖动整个面板的,同时那部分出界的透明的,不可以触发拖动效果。
进一步考虑是,让box collider可以自适应,当content它的一部分出界后,box collider变形,只跟content的可见部分匹配。
这个也许可以实现,但要做很多编码工作,而且可能会影响性能。
博主稍微研究了下draggable panel的相关源代码后,还是觉得这个自适应的扩展脚本很不好编写。

第二种方案:
苦逼了一段时间后,发现其实可以不需要这种所谓自适应的box collider,可以换一种方法实现这种拖动panel功能:
1.保留panel里的各个子对象的UIDrag Panel Contents组件,删除它的box collider组件。 
2.在draggable panel同层次创建一个空的gameobject,给它增加一个box collider,大小和位置,和draggable panel 的大小和位置对应(就是说,这个game object就是该panel的触发框了)
3.关键!在该gameobject添加一个组件:NGUI里的UIForward Events

设置target为目标draggable panel里的任意一个content对象,事件为onPress onDrag

这样,这个新的外部box collider会接收到点击事件,并调用target的回调函数去处理该事件。出来的效果就是,只要在这个新的box collider内的拖曳事件都会正常地触发。
but,这样还是有问题,就是说当这个panel的各个content对象是可以被点击,触发某类事件的时候(比如是一堆Button),就点不到啦。
所以这个解决方案只能解决content是普通静态对象的时候。比如content是一个或多个UILabel,用来展示一些游戏信息。

第三种方案:
这个方案是应付上文说的content是可点选对象的情况的。为了保留各个content的box collider组件,可以采取分页的方式,即这个draggable panel是分页的,当你拖曳结束的时候,panel会自动适配到某一页,而不会说停留在页与页的中间。这样,只要当触屏事件结束的时候,判断出当前所属的是哪一页,然后把除了该页面外的所有content对象的box collider控件都disable掉,而当前页的就enable, 这样就行了。
另外楼主也扩展了NGUI,实现了一个分页脚本,只需要拖到panel对象就可以自动应用上滑页效果了。不过等把这三种方案实现了,再开源出来。
————————————————
目前博主就做到这个程度,这第二个方案确实解决了一部分问题,目前还是够用的。
等以后发现完美解决方案的时候再更新。

posted @ 2012-09-06 12:54 Q+伟 阅读(3800) | 评论 (0)编辑 收藏

2012年7月24日

这两周在开发的弹幕引擎遇到了一些性能问题:
1.同一时刻创建大量子弹会造成卡屏,跑起来就是一顿一顿的,原因是new一个对象很耗CPU。
2.draw call 和 batch 的问题。

第一个问题可以使用OT自带的对象池功能解决:
1)初始化对象池 PreFabricate(string objectPrototype, int numberOfInstances) 
objectPrototype 对象必须放在OT prefab的子对象Prototypes下。
2)要销毁对象时,必须调用  OT.DestroyObject(xxx),不然对象无法回收到pool中。
3)当要创建新的对象时调用OT.CreateObject(objectPrototype ) ,刚好对象池里有可以使用的闲置对象时,OT就会自动服用该对象。但是要注意一个问题,被复用的对象已经被初始化过一次并运行过了,可能有一些参数必须重置,这个操作OT不可能帮你完成,因为OT不知道哪些参数需要重置。但OT在 CreateObject 方法内有一行代码:
g.SendMessage("StartUp",null,SendMessageOptions.DontRequireReceiver);
意味着OT在给你一个对象之前,让这个对象执行了这个StartUp函数,所以可以在对象的各个component里重写这个函数,必做必要的重置操作。
除了使用OT自带的对象池,还可以使用另外一个插件:PoolManager2,不过这个插件蛮贵的也不提供使用版,有米的就入手一个试试吧。

第二个问题是关于对象材质的问题。
我在一个弹幕demo中想让N个弹幕tween到一个颜色,通过改变OTSprite的tintcolor,结果发现帧率掉得很厉害:
1)弹幕刚生成的时候,Draw Calls只有3次,全部子弹都被batch到一起。

2)第二个操作是改变各个弹幕OTAnimatingSprite的帧图片,发现帧率等没有变化,性能瓶颈不是在切换动画帧上。

3)开始随机tween每一个子弹的tintcolor,发现DrawCall暴增,batched数剩0,帧率掉出翔来了。。


很显然,改变tintcolor会导致不能batch,每一个弹幕自己跑了一次渲染管线,超低效。
下一个操作是把所有子弹tween回同一个颜色,发现参数都恢复了,包括帧率。所以这个tintcolor的改变应该不是给每一个子弹生成了新的材质(Copy On Write写复制这种机制),只是同一次shader不能有不同的外部参数。
这个恢复机制反应出Unity和OT还是很智能的。
这个问题好像没有什么解决方法,最好的办法就是不要像我这样子搞=。=
做移动平台游戏,性能相当重要,这种华丽的效果还是放弃吧。

虽然做了对象池优化,但是帧率还是蛮低,以后加上游戏逻辑、碰撞检测、游戏场景、特效、GUI后,帧率又会降低,
所以性能革命这路子还长呀。

posted @ 2012-07-24 17:06 Q+伟 阅读(3870) | 评论 (1)编辑 收藏