没有家的孩子

kurt祭日20年

RIP  

Posted in | | 2 Responses

阿丰哥哥的游戏制作经验谈(二)

想了很久,自上回讲完游戏基础的框架之后应该写点什么,还是觉得很难理出一个比较合适的流程,所以接下来大致就讲一下阿丰哥哥认为比较重要的点。 面向对象与游戏 面向对象可以说是现代程序用的最最最最多的一种开发方法了,由于阿丰哥哥不是一个合格的程序员,所以不会非常专业和准确的描述出有关的概念,也不会在这里教学或是解释,但是为了你未来开发游戏,查看别人的教程或者源码,不至于一知半解,建议没有这方面基础的朋友好好的学习一下,非常非常非常有用。 面向对象程序设计(英语:Object-oriented programming,缩写:OOP)是一种程序设计范型,同时也是一种程序开发的方法。对象指的是类的实例。它将对象作为程序的基本单元,将程序和数据封装其中,以提高软件的重用性、灵活性和扩展性。 面向对象程序设计可以看作一种在程序中包含各种独立而又互相调用的对象的思想,这与传统的思想刚好相反:传统的程序设计主张将程序看作一系列函数的集合,或者直接就是一系列对电脑下达的指令。面向对象程序设计中的每一个对象都应该能够接受数据、处理数据并将数据传达给其它对象,因此它们都可以被看作一个小型的“机器”,即对象。 哦了,上面那一段斜体字是阿丰哥哥去维基百科里面复制出来的,怎么样?能看懂么?说实话大学时代的阿丰哥哥,也上了C语言,C++语言的程序设计课程,但最后只是能够完成老师布置的作业而已,真正的理解面向对象,是阿丰哥哥工作之后,使用FLASH IDE某一天突然顿悟的,真可谓大器晚成也!(唔) 开篇废话有点多,切重点。之所以要提一下面向对象,是因为阿丰哥哥想给大家介绍一下游戏里面活动元素的结构。活动元素,就是指会动的,比如说,主角,敌人,飞行物(子弹),机关,等等等等。这些活动物,我们会用面向对象的思想,把他们归为一种,拥有自身位置信息(坐标)的,拥有需要渲染(动画)的,类(CLASS)。2D的世界里面,我们会把它们叫做SPRITE(精灵),3D的世界里,比如说UNITY3D,我们把它叫做GAME OBJECT(游戏对象)。每一个SPRITE或者GAME OBJECT里面,必定包含了,坐标(一般Sprite里的x,y变量/Game Object里面的transform.position变量),动画(这个比较难举例,因为不同的引擎对应了不同的动画方法)。当然除此之外,还会包含很多其他根据游戏需要而添加的Component(组件)。为什么这样做呢,接下来阿丰哥哥再来给大家说一下传统的2D游戏的渲染方法。 一般2D游戏渲染的流程是? 大家可以想象一下,电脑的屏幕实际上就是一块可以反复擦除的黑板(白板),在阿丰哥哥上一篇游戏怪谈里面提到过的,游戏主循环每循环一次,最后执行的一部,便是渲染。这个渲染,无论你用的是什么引擎,结果必定是,先绘制的部分在底层,后绘制的部分在上层会盖过先绘制的部分。比如说在一个超级玛丽这样的PLATFORMER类型的游戏中,就是先把背景(远景),天空,蓝天先绘制在黑板上,接着绘制近景,就是那些地板,砖块,然后绘制角色,马里奥大叔,吃人花,然后如果还有近景的话就绘制近景。 屏幕大小是有限的,所以我们并不会把整个游戏的世界给渲染到整个屏幕上,超出屏幕的地方,我们该不该渲染呢?(哦对了,插一句,一开始引擎并不会直接在屏幕上面绘制,而是会在内存里面建立一块缓冲区域,在内存缓冲区中预先把需要绘制的东西给处理好,最后再把这需要显示的搬上显示器。)一般说来,超出屏幕外的物体不渲染。我们怎么知道这物体有没有超出屏幕外呢?这就是上一个部分里面的,该物体所包含的位置信息所决定的。某物体在屏幕之外,它仍然可以进行它的AI逻辑处理,它仍然可以决定自己此时此刻应该播放哪一帧动画,但是由于它的坐标在屏幕之外,于是我们在渲染的时候,跳过它,不进行渲染,可以节省很大的开销。(还有一种做法便是物体在屏幕外了就完全冻结,当然还是要根据游戏设计来进行对应的处理。) (在硬件发展的初期,有着许多伟大的程序员,在有限的机能下为了提高画面效果,想出了很多天才的方法,有兴趣的朋友可以再了解一下关于卡马克卷轴,脏矩形算法这些到现在看来还是会有实际意义的文章。) 因为在FLASH时代,阿丰哥哥从使用FLASH里面的元件,到使用位图绘制,都做过游戏,所以对2D的这一套流程可以说是比较熟悉。进入了3D时代,使用了Unity3D,感觉基本上已经告离了渲染管理。虽然渲染机制改变了,但还是会有屏幕外物体剔除渲染的这一类思想存在,只是这些工作,已经交给了引擎自动完成,我们只需要更新物体的位置就行了。引擎的作用,本应该就是这样,解放出游戏设计者的手,让他们把智慧,闪光在游戏设计方面,而不是与底层代码做斗争(当然不排除你未来也许适合做一位伟大的底层架构师,那是另一说了) 来点实际的!让主角动起来! 不少朋友对于制作游戏的第一步,就是跃跃欲试的,想让自己的主角动起来。让我们回想阿丰哥哥上一次说了什么: —–主循环开始——- 接受输入 处理输入(一般是对主角) 处理主角逻辑 处理乱七八糟的逻辑(敌人啊,机关啊,关卡啊) 渲染这一帧的画面 —–主循环结束——- 然后我们对这一段稍微改点颜色和文字 —–主循环开始——- 接受输入 处理输入(对主角) 处理主角逻辑(更新主角位置) 处理乱七八糟的逻辑(敌人啊,机关啊,关卡啊) 渲染这一帧的画面(根据主角的位置渲染主角当前所需要播放的帧) —–主循环结束——- 橙色的部分就是我们只改变主角位置,然后对主角渲染的流程。 在接受处理输入部分,无非就是  如果按下了左,主角的位置向左偏移3个像素;如果按下了右,主角的位置向右偏移3个像素;大概如此的逻辑。 关于角色的移动,一般说来分为三种模式(阿丰哥哥的划分):A,无惯性;B,有惯性;C,仿真式。三种模式根据不同游戏的类型,都会出现,阿丰哥哥并不认为其中存在最好的方案。 A,无惯性。这个模式即是上面几行蓝字的那种逻辑,对于玩家的输入,按一会,就移动一点,按长一点,就移动远一点,移动的速度是固定的。这种模式适用于对于操作要求比较精准的,弹幕游戏,飞行射击游戏,格斗游戏,动作游戏之中。这类游戏中,玩家要求对于主角的控制有着极高的可控性,事实上阿丰哥哥更喜欢这一类的做法,因为可控性最佳。缺点是如果是动作类游戏,角色的动画播放会出现类似滑步的情况。 B,有惯性。这个模式中,玩家的输入,只是改变主角身上的速度变量,而不是直接改变主角的位置。主角由速度控制其移动。当玩家没有输入任何方向时,主角会受到一个与运动方向相反的摩擦力来让其停止。这类模式操控手感一般会根据参数有着不同的操作滞后感。比如说超级马里奥的移动,相信会让人很强烈的感受到惯性的存在,除此之外,大量游戏也会带上一些惯性,只是参数设置不同,而手感不同。实际上大部分游戏移动都会采用这个方式,根据移动速度的不同,播放不同速度或者类型的移动动画(跑,走),也能在某些程度上解决滑步的问题。 C,仿真式。即严格按照角色动画移动步长来移动角色,看上去会很自然,但是可控性不高,阿丰哥哥其实不太喜欢这种模式。早期的波斯王子,DOS神作ANOTHER WORLD,还有现代的一些3D游戏,都是采用这样的模式。 当然也不乏混合式的,比如说鬼泣这类游戏,便是在人物移动中使用B模式,在攻击中使用C模式。 这里宣扬一下阿丰哥哥的游戏观,阿丰哥哥觉得一个游戏的手感,很基本的一个点就是对角色移动的操控感。这个太基本了导致不少做游戏的朋友都没有太把它当回事,要知道一个游戏里面,玩家花时间最多的,就是在基本的移动上了(这句当然是阿丰哥哥瞎编的囧)。基本上要做到,按左就向左,按右就向右,放手就停止,带一点点的惯性(滞后感),抛弃了主角的动画表现,把主角想象成为一个点,它的移动可控性,一定要高。然后才是,调整角色动画,使之能够配合角色的移动速度并且“看起来合理”。 举个自己游戏的例子:《巨人的猎手》主角们移动是A模式;艾伦变身巨人,移动为A模式,攻击的时候为C模式;巨人们移动为A模式,在三连击的时候移动为C模式。 这期大概就先这样,好好构思下下期应该说什么 baking soda for constipation

Posted in | | 7 Responses

阳光什么的依然明媚

一切的一切都只是因为舍不得这些过去 我想给一个我喜欢过的姑娘写歌 给每次一我经历过的事情写歌 写一首悲伤 或者更悲伤的歌 不过喝得再醉也会有醒过来的一天 就好像我现在逃避的生活 总有一天要去面对

Posted in | | Leave a response

噢这真是糟糕的一天

糟糕透了……糟透了……

Posted in | | Leave a response

My first VFX clip <killing myself>

http://www.tudou.com/programs/view/6nCU0UvQRQ4  

Posted in | | 3 Responses