游戏开发论坛

 找回密码
 立即注册
搜索
查看: 5292|回复: 0

《种子净化之旅》业余开发经验与心得分享

[复制链接]

1万

主题

1万

帖子

3万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
32069
发表于 2016-2-5 11:12:34 | 显示全部楼层 |阅读模式
133325fo6yfwwyy5ovvd1o.png

  文/kamikami

  前段时间游资网分享报道了一个独立游戏团队《种子-净化地球之旅》的创作故事,今天,开发团队为我们带来了游戏开发的经验和心得:

  会开发游戏不等于会做游戏,会做游戏更不等于能创业。一开始我们并不是抱着想创业赚大钱开始业余做游戏的,只是有闲工夫不做白不做,基本当成课外兴趣小组,能赚点外快买买游戏就太好了。

  交代一下背景。我们三个人不完全在同一个公司,美术F的上班时间比较苦逼,朝十晚十大小周,J和K是夫妻档,公司非常人性化,上班时间弹性比较大,而且提供各种学习的机会和资源,相比一般上班族要幸运得多。基本上做游戏的时间为晚上十点到凌晨两三点左右,周末基本也都砸在游戏上。没有时间休息娱乐很容易心态爆炸,隔三差五的还是要放松一下吃顿饭看个电影玩玩游戏什么的,换换脑子。创业者可就不一样了,是一群全身心投入的殉道者,比我们要苦逼无数倍。

  做什么级别和类型的游戏,肯定要先分析自己的资源和能力和优劣势。像我们这样,一个场景美术和一个程序,没有策划和动画,毫无“诗和远方”的一群死宅,显然得回避一下需要大量角色动画和特效、数值模型复杂、需要表现剧情的游戏,可以考虑的游戏其实很有限,有关卡设计的小游戏已经是极限了。

  以下来自成员自述,希望对各位有帮助。

  一、关于计划&设计

  基本工具:

  QQ群      日常讨论和想法分享。

  worktile    制定任务清单 标明负责人、截止日期和优先级。

  百度网盘    上传游戏相关设计文档和美术资源。

  SVN       程序和关卡设计经常需要双线程作业,合并任务。

  一开始并没有什么卵计划,就是谁弄好了一些东西告诉其他人,然后看情况继续弄,懒癌犯了的时候就想……你们太监们不急我皇上急什么?每个人都有惰性和侥幸心理,今天好累我看完这集电视剧……诶?都在玩游戏,那我今天淘宝吧。 一个个只想冲排位,能做完才怪。

  玩到一定程度人就会陷入大好年华一事无成的巨大恐惧中,必须有个人出来制订计划和管理项目进度了。洗心革面,写文档,做示意图,策划并不是想几个点子玩过一些游戏就可以拍脑袋瞎指挥,逻辑实现层面的东西完全是一点不懂,和Joker在功能上总是吵的夫妻不和,和Fang的沟通也不是很积极,意思传达有很多不明确的地方也就任其自由发展不管不问。躺在床上,绞尽脑汁想出几个元素,梦里编关卡,憋出十个关卡,赶紧发给美术和程序,然后继续憋后面章节的元素。

  每个周末争取大家碰次面,看着引擎里的画面,商量各种细节——章节地图如何表现?要不要有三星通关啊?角色形象不够显眼最后要重做啊!道具真的有人会买么?这下雨角度能不能再偏2°?有些小细节看上去特别简单,然而最终它会是那个样子可是经过了来来回回的交流。第二章做的时间最长,因为元素最多,但是同时也觉得这一章最有意思,做第三章时间变得很赶,Joker强烈表示不许再加复杂功能,所以基本都是前面功能的美术变形。

  到了最后阶段,简直和打仗一样,每个人的任务清单下面都有看起来无穷无尽的任务。任务列表分为“周目标”“设计”“程序”“美术”“音乐音效”“市场”“已完成”几个条目。有时候完成一个任务会发现后面又增加了四五个带着自己头像的小标签,内心极度崩溃。

  内测时也不知道测试游戏是个什么流程,要测些啥,传说中的那些高大上数据也不知道怎么分析,从朋友那知道了Testflight,提交了苹果内测,两周后提交了苹果公测,一大堆繁琐的提交程序,没想到很快就通过!!收到邮件激动地奔走相告,邀请一群亲朋好友来帮忙测试,收到各种喜忧参半的反馈,一堆bug,一堆建议,晚上整理好之后把一个个修改任务写到worktile中相关人员的名字下面,不可能修改的尽善尽美,能力和时间范围内能改的都改了。

  苹果提交上线是个痛苦的过程,本地化、排行榜、截图格式、视频尺寸、上传环境各种坑……一定要好好看官方手册提前做好准备,弄了一个通宵终于成功提交,接下来就是等等等,三天后突然收到苹果邮件通知已上架,开心的不能自已。

  心得:

  1、如果不是资深游戏内行,一开始做游戏练手,最好选择游戏机制简单的,有多简单就看你几句话能把游戏玩法说清楚。可以把更多的精力放在去思考如何让游戏在表现上更加有趣或者体验更加独特,比如同样是节奏游戏玩法可以千差万别,可以做成劲舞团也可以做成《啪嗒砰》,避免洋洋洒洒做一堆东西结果玩起来一点乐趣都没有,我们就在这上面吃了鳖。

  2、做游戏很大程度上能体现出制作者的性格,因为多多少少都能透露出制作者的知识结构或者爱好品味,如果想做出真正“创新”的游戏就要提高自己的见识和脑洞,想做出特别有“内涵”的游戏就要提高自己的思想深度,想做出能感动人的剧情就要提高自己的文学修养和叙事水平…一个自己本身就很无趣或者无知的人是做不出有趣或感染人的牛逼游戏的→_→

  3、关于别人的建议。如何听取别人的建议是个技术活,什么都听自己就会变得迷茫,什么都不听就闭门造车,起码在成为大神之前你不能说出“老子做老子的游戏你们别逼逼”这种话。要学会从别人的建议里提炼出真实感受,再针对感受去想合适的解决方案,交流的时候也重在提问“这里你有什么感觉?”而不要问“你对此有什么建议?”,越是小白的玩家越是经常会说出有用的信息,反而越是“高级”玩家越是爱班门弄斧提出“专业”的意见却不见得正确。

  4、界定是“设计问题”还是“美术问题”。有一次因为一个UI的问题和Joker大吵一架,我觉得这是一个关于操作体验的问题,他觉得是一个美术表现的问题,不该我来决定。抛开该由谁决定,重点是到底哪样游戏体验更好,这种争论没有什么意义纯属浪费时间,有时候还不如直接做出来看效果快。

  5、测试的时候花时间做了一些调查问卷,用微信就可以分享和提交,很方便。这些问卷起到了一些作用,让我们比较有条理地总结各方面的反馈,方便在最后完善阶段拿出来对照着再思考和了解,需要完善的功能需要记录下来排列优先级,改动太大可能会造成巨大bug,存在让游戏完全运行不下去风险的功能只能靠后排列。

  二、关于程序

  1、想好了再做

  最初只是想做一个游戏走一遍上架的流程,积累一些经验。Fang开始说做一个游戏,把角色移动到终点,一关就结束。当时我就知道关卡设计才是这个游戏的乐趣所在,所以不断向他强调关卡设计的重要性,但是他说没问题,我来弄几个示意图就好。虽然很不安但想着只是想把游戏上架,就算无聊就无聊吧就这么答应了。结果应验了我人生中犯下最经典也是屡教不改的错:开始觉得担心但是没想太多就接着做,然后这个没想好的问题之后就一定会爆发而且会把我菊花炸烂(以前主要是程序上犯这个问题,这次设计上也炸了)。

  一天之内我就实现了第一个原型,角色会像屏幕点击的位置移动,当时还做了一个弹簧,如果角色碰到会使角色像镜面反射一样的运动。但是玩起来实在太无聊了,游戏的品质到了一个我完全不能接受的无聊的程度……必须得找一个人来设计关卡。因为这个问题我一度的搁置这个项目好几个月。最后我老婆变成了这个人。

  2、交流

  程序整体由我一个人做,和在公司两个程序一起做有鲜明的比较,交流的效率真的是天差地别!我认为主要有以下两方面原因:

  1) 思路不同:每个程序应该都遇到过这个问题,同一个需求的实现方法通常会大于两种,就算只有两种不同的方案,两个程序刚好想到同样的解决方案的概率只有1/4,更别说大于两种了。这就造成了在解决方案层面的争执,显然一个人做不会有这种问题。

  2) 表达能力和理解能力:我和我们主程的合作在交流上有很大的阻力,具体原因不方便说。但是就算是表达能力和理解能力超群的两个人交流肯定也比不上一个人(这概率太小了),毕竟交流这东西就像是A把脑子里想的东西(数字信号)表达出来(转换成模拟信号),B把A表达的东西(模拟信号)理解到脑子里(转换成数字信号)。每次转化率必然<100%。流失的越多,之后造成的问题也越多。

  3、迭代式开发

  每章的内容是流水线式的制作,也就是第一章想好了后,策划告诉我,然后我做第一章,她继续想第二章。其实这个过程相当蛋疼,软件工程中需求是完整的情况下失败的项目都一堆一堆的。这居然还是个变化需求……也许这就是游戏开发比其他软件开发特殊的地方吧~当时我在每一章的制作过程中都很仔细的考虑设计模式和扩展性的问题,然而结果是然并卵。之后我仔细反省了一下其实是由于以下几个原因:

  1)一章就那么多关,那几个可交互对象。拓展的可能性其实不大

  2)需求变化的可能性非常大,如果有一个基类有很多子类的通用行为,万一一个子类的行为需要改而且和之前抽象的基类行为无法统一的时候,那就会导致大片的重构…所以最好的方法我认为就是如果策划不是程序,千万别太早抽象基类的行为,绝对不要傲慢到认为自己可以考虑到别人想到的所有变化。

  3)制作过程中程序真的需要很积极的和策划交流,告诉他们那些做起来容易:有些新功能我写个子类加一句代码就搞定了。有些新功能可以直接让我跳楼。与其不停的实现新的功能,不如多交流在有限的时间内以最小的代价来更多的增加游戏的趣味性。

  4)制作过程中程序也需要积极的和美术交流,因为很多效果Fang不知道实现起来是否容易,性能和体积上是否允许。我们游戏中的很多粒子特效其实是我做的,但是Fang要站在我旁边看着我调。虽然增加了一些工作,但是让我们的游戏视觉效果看起来更好了。我认为效果和可行性中间往往存在这一个平衡点,像是全局光线追踪和UE4的光照算法。效果(我看来)大概差了10%~20%,但是性能上的提高是好几个数量级。但是大部分的美术和程序之间的交流不到位所以这个平衡难以找到。我想这就是为什么能做出特别的美术风格的游戏厂商并不多的原因吧。

  4、为什么不用瀑布式模型

  开始我认为理想情况下应该直接以瀑布型模型来开发游戏,但是写程序写的越久越发现这不可能,因为游戏一定需要做出来看到底好不好玩,所以需要原型,只有确定了原型之后才有能继续进行,而且每个元素在制作过程中都需要不断测试,不可能开始就有游戏的所有需求让我画好UML再做。我只能说如果想做一个好玩的游戏,瀑布式模型我认为行不通。起码我没见过游戏制作人可以在游戏做出来之前就确定这样一定好玩,就按文档做。

  5、本地化

  Unity的Text其实做起本地化非常容易,只要有一个带有通知机制的单例和一个配置文件,再给Text挂一个Listener很轻松就搞定了。我们主要是大概能写的语言就那么3种,要不然肯定所有语言都一起做了。主要有以下几个小收获:

  1.字体可以使用FontCreator将体积从12M左右减小到1M左右(常用字都在前面,从最后一个你认识的字开始后面都可以删了~)

  2.Unity载入字体Asset是OnDemand的,如果有动画,第一个引用字体的对象Render的时候会出现Performance Peak。解决办法有两个:把第一个引用字体的对象在Start中disable掉;把字体加入Preload Asset中。

  6、移动平台开发

  iOS和Android我都没做过本地开发,基本有问题就Google了。好在Unity在5.3中提供了集成的IAP让我赶上了,不过还是发现了几个坑,仅分享给像我这种没搞过平台开发的菜逼:

  1. iOS的Texture Compression简直惨绝人寰,质量丢失太多,尤其是Alpha。相比起DXT简直LOW爆了…偏偏单独打包Alpha目前只有安卓有(我用的是Unity 5.3.1)。最后我好不容易Pack好的Square Atlas又全改成ARGB,现在我一想起来蛋还是隐隐作痛。

  2. iOS中的不可消耗商品必须要恢复购买按钮(之前有个应用是因为这个原因被拒,当时我是优化了操作不想让玩家多点一下自动帮他恢复,但是这样苹果不允许实在不解)。对于这份傲慢我也只能默默的再骂苹果几句。相比谷歌的自由度高了很多,能不能消耗完全由开发者决定。

  3. Unity对于Google Play的IAP真的是一点文档都没有,对于我这种没有开发经验的人异常痛苦。最后在网上终于找到了一份DOC文档搞定了,Unity这把真的把我坑到家……文档上传到百度云,有需要请随意下载

  4. Play Games(0.9.27a)和Admob(2.3.1)的Unity插件是有冲突的,放在一起无法直接编译通过,需要做以下步骤:

  1) 不要复制google-play-services_lib文件夹

  2) 复制android-sdk/extras/google/m2repository/com/google/android/gms/play-services-ads/8.4.0 到 /Plugins/Android.

  3) 删除Plugins/Android/GoogleMobileAdsPlugin/AndroidManifest.xml中的activity android:name="com.google.android.gms.ads.AdActivity" android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize"

  4) 如果你也使用的Unity的IAP,还需要删除Plugins/Android/GoogleMobileAdsPlugin/lib/in-app-billing-service-aidl.jar

  以上我弄完就可以编译通过了,但是广告内容暂时没测,不知道会不会有什么问题。以上资料都来自于Google Play Games Unity Plugin的官方GITHUB中的ISSUE。具体的原因可上这里找找。

  5. 为了减少Drawcall,我把大部分散的图片都Pack到了一张Atlas中,Atlas的尺寸和Sprite的部署都需要注意。Atlas尺寸过大虽然可以有效减少Drawcall但是太吃内存,因为载入了根本不需要渲染的Texture。尽量把会同时出现的Sprites Pack到一起才有意义。否则Drawcall的数量减少会不明显(为了Pack成Square POT的Atlas我还专门写了个小工具,非常简单大家有兴趣可以自己试试,懒得写就Email我我给你发过去,实在写的太简陋不好意思拿出来)

  6. 没必要盲目优化。这个游戏的Drawcall数量在UI界面大概在15左右,关卡内在30-40左右。大部分的机器运行基本不太可能有什么问题,其实之前没PACK过也Drawcall也没破百,其实这部分工作我认为真的是纯积累经验了,效果并不大,因为玩家几乎是感受不到差异的,除非是设备非常惨的用户。

  三、关于美术

  毕业之前一直都执着于做纯艺 ,对游戏的美术概念非常模糊。当时最常见的就是页游网游上各种炫酷仙侠修真之类的原画。于是本能的把游戏的美术和艺术生硬的切割开了。

  随着在游戏行业见识增长,接触到一些风格独特的独立游戏,  发现并非我想的那样只有仙侠才会受欢迎。 接触到《纪念碑谷》时心里仿佛遭受了一记重拳,在我看来它是把艺术与游戏结合的一种里程碑式的尝试(见识浅薄,如果有其他欢迎介绍推荐)。艺术是可以横向发展, 相对游戏美术来说只是呈现的方式不一样罢了。游戏绘制同样可以是自我情绪的宣泄,同样能表达自我,一点都不冲突。这样的思路可能在画风上给予更多的视角,无意中产生了一种新的画面效果或绘画方式,这就是属于自己的干货。

  做游戏时不会一拿到文件就开始画素材,快速画好大量的草图,将界面中的场景、文字、图片布局等等配合程序的原型,结合游戏玩法在心里有了一个全面清晰的概念和感觉之后,再去细致的绘制每一张图每一个素材, 在开发游戏项目中这样做的好处非常多,为了游戏好玩往往在中途无法避免设计频繁修改,当游戏跑起来确定好了整体感觉,心里更清楚的知道了该在哪里可以添砖加瓦,最后再精雕细磨,加细节、加特效、 丰富画面。

  最后寄语

  团队合作的模式有很多种,需要花时间找到最适合自己成员的合作方式。要么做好团队建设,相互之间建立起信任、默契、尊重、鼓励,众人划桨开大船,有分歧没结论就直接做出来看,别你看不上我的点子我看不上你的设计,我嫌你理解能力差你嫌我工作效率低,负面情绪爆表相互充满怨气,这么下去项目不是草草了事就是要坑。还有一种就是团队中有“大神”,能力资历都足以让其他人信服,他交代什么其他人就做什么,这样高效的方式也能出不错的东西。

  《种子净化之旅》之前设置0.99美元,朋友说太贵了居然要六块钱,坚决不买!(不是亲生的朋友……)名称和关键词设置也有问题,原本设想游戏就叫《种子》,结果apps tore搜不出来,后来研究了一下貌似名字如果是使用频率太高的单个单词就没法搜出来,现在游戏改名为《种子净化之旅》可以成功搜索到了!如果对我们后续的进展或者我们的游戏有兴趣请继续关注我们。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2024-12-22 14:26

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表