分类目录归档:

游戏类型开发难度排序

参加Game Jam做什么游戏?

先了解一下各种游戏类型的开发难度(从简到难)

  1. 赛车竞速
  2. 顶视角射击
  3. 2D平台跳跃
  4. 消除
  5. 2D解密平台跳跃
  6. 3D平台跳跃
  7. 第一人称射击
  8. 日式角色扮演
  9. 格斗
  10. 动作冒险
  11. 欧美角色扮演
  12. 即时战略

排名依据各游戏类型制作出Minimum Viable Product(最小可用产品)的难度。

Game Jam求生手册 – 中文摘要版

the-game-jam-survival-guide-book-cover

Build a game in one crazy weekend and survive to tell the tale!

Game Jam是属于游戏开发者的狂欢节,除了参赛规则外本不应有太多条条框框,这是难得地可以随心所欲做游戏的一段美好时光。但是如果你希望更好地享受Game Jam的乐趣,或是立志在竞赛中有所斩获,《The Game Jam Survival Guide》这本书无疑会为你提供不少智慧的箴言。

书的篇幅不长,依照Game Jam的流程介绍了每个步骤的最佳实践和注意事项,诸多成功Game Jamer的经验访谈穿插其中,最可贵的是通过调查数据揭示出的Game Jam背后的规律,令人信服。

本文是我的读书摘要,书中谈及的重要观点仅是罗列并未展开,适合没时间阅读原著的人快速提高Game Jam幸存能力,其中部分观点对于日常游戏设计开发活动也具有指导意义——特别是独立游戏开发。

Game Jam的收获

统计数据显示,参与者表示Game Jam最大的收获是——乐趣

1. 赛前准备

1.1 别想尝试新工具

1.2 不要忽视家人

  • 提前预告即将到来的周末Jam活动,让大家有心理准备
  • 为了补偿家里人一个周末,在前一周安排一次出游活动
  • 与他们探讨游戏创意
  • 使用他们的创作作为游戏元素(例如儿童画)
  • 邀请他们献声
  • 邀请他们做测试者

1.3 保持正常的作息时间,偶尔外出小憩,正常健康饮食

  • 不充分的睡眠会让你的最后一天精疲力竭。
  • 你只有在身心处于最佳状态时才能最有效的创作以及修正bug。
  • 大量的功能性饮料和熬夜是产出低质量作品的催化剂。

2. 巧用社交媒体助你挑战Game Jam

2.1 向全世界宣布你参赛了,这样碍于面子你就无法逃避完成游戏

2.2 分享你的进度,获得反馈和激励

2.3 帮助他人是获得社交成功的最佳途径
这会助你的参赛作品成为大家热议的焦点

3. 游戏设计&开发计划——大道至简

3.1 前十作品的典型特点

  • 幽默
  • 简单游戏玩法
  • 简单画面
  • 易于上手(简单操控)

3.2 获奖游戏的统计学共性

  • 几乎都是Platformer,而非射击或其他实验性的游戏类型。
    制作简单,玩家上手容易。
  • 大部分画面都是像素风格
    做起来快,不容易做得很烂。而3D画面制作缓慢,而且很容易极其难看。

因此,最有可能获奖的作品是——精美的、色彩丰富的、易于控制的平台跳跃解密类游戏(Puzzle Platformer)

3.3 有些游戏类型先天需要更多的工作量——例如RPG,RTS……

3.4 KISS法则:Keep it simple, stupid
计划制作一个非常非常简单的游戏——简单到你认为一个下午就可以搞定。然后不断完善、打磨它。

  • 简单画面——可以快速制作
  • 简单控制——小于4个按键
  • 最小化游戏机制—— 找到游戏有趣的地方,然后蒸馏提纯,抛弃其他多余的部分
  • 计划创作比你认为你能够完成得更少的内容
  • 计划让游戏能够提前完成(然后你会发现会比预期的时间长)
  • 别用太高级的技术
  • 同样的游戏2D花费的时间是3D的四分之一
  • 制作2D美术素材的时间是3D的十分之一

4. 制作阶段——提纯并打磨游戏的Feel

4.1 游戏作品最关键的几点

  • 角色运动方式
  • 操控
  • 游戏失败方式
  • 游戏胜利方式
  • 游戏体验(Feel)——游戏趣味性的灵魂

把他们做好(有趣的游戏原型)之前不要碰音乐、画面等次要内容。即便你的原画是大师级的,但它们并不好玩。

4.2 再度运用KISS法则:Keep it simple, stupid

完美状态的达成不是在加无可加的时候,而是减无可减

  • 把一件事最好,而不要把20件事做糟——1个有趣的关卡胜过5个平淡无奇的
  • 让游戏可以直接运行,避免复杂的游戏安装过程
  • 避免过长的介绍,过场特效
  • 不要考虑编写未来可以复用的OOP代码:quick & dirty is fine

4.3 不要按照“最正确”的方式去做,而是选择“最快捷”的方式

4.4 不要因为Bug或其他什么而卡死

4.5 定制色板,限制色板颜色数量
当色板被限制在有限的几个颜色的时候,绝大部分开发者都能收获满意的美术效果——彩虹样的色板是场灾难。

4.7 缺乏音乐音效让游戏的完整性和质量大幅下降
如果实在找不到合适音效,可以自己唱出来。

5. 准备提交

5.1 提前4小时完成游戏,进行Beta测试:调校难度和操控
打磨游戏的Feel,一些小小的测试和调校就可以让你的游戏从平凡变得令人难忘

  • 让玩家可以快速体验到你游戏最好的部分,最好是前15s内
  • 不要漫长的介绍
  • 让游戏比你认为得要简单

5.2 截图请用最精彩的游戏画面,没人想看漂亮的标题画面

5.3 标题首字母是A的游戏更容易被看到

6. 赛后

6.1 Post-Mortem的常见格式

  1. 游戏简介
  2. What went right
  3. What went wrong
  4. 结论
  5. 工具、成员列表,统计数据……

Unity 4.2一些令我欣喜的新特性

Unity 4.2发布带来了一系列或大或小的更新,增加免费Windows 8/Phone的发布选项,增加免费版功能等重要的就不提了,官方的更新页面有大字介绍。大致看了一遍详细的更新列表后,在这里列举一些我感觉不错或期待已久的新特性,由于目前主要做iOS和Webplayer,所以其他的特性没关注:

Platform switching, player building and asset importing can be cancelled now! How cool is that?
节省时间。

Custom GameView resolutions & aspect ratios. Custom settings are saved per project for easy sharing through version control (ProjectSettings/GameViewSizes.asset).
之前在Windows下做竖版iOS应用的时候就特别希望可以自己设置多种屏幕比例,现在有了,而且还可以通过版本库同步。

Preset Libraries: You can now save the following types as presets:

  • Curves in the Curve Editor and Particle System Curve Editor.
  • Gradients in the Gradient Editor.
  • Colors in the Color Picker.
  • Create new libraries either as personal libraries (saved in preferences) or shared libraries (saved in the project folder).

曾经想着自己做一套这个功能,还没做官方的就出来了,实用度极高,特别是对于GUI的管理。

Added a Quad primitive 😉
终于有官方的正方形面片了,做基于3D Mesh的界面最常用的就是Quad,从官方Quad的轴向设定来看,它完全就是为GUI而准备的。

Memory Profiler: Now shows the objects that have references to another loaded object. This can help pinpoint why a given object is in memory.
性能优化的过程可以更透明一些了

Texture importer now has “Alpha is Transparency” setting, which does color dilation to fix edge artifacts on semitransparent textures. It is enabled by default for GUI textures.
终于不用在Photoshop里做dilation了,设计师提交的透明背景GUI稿终于可以直接用了。

iOS: Added CrashReporter API for crash detection and extraction (requires Unity Pro).
可以更好的处理崩溃错误并且进行汇报和检测了,游戏崩溃真的是让玩家感觉非常沮丧和无助的体验。

iOS: Now you can setup iOS PlayerSettings, texture import overrides and build iOS AssetBundles from Windows Editor. Building an actual iOS player still requires Mac OS X & Xcode.
对于“Windows开发+Mac发布”的开发者是一大福音啊。

Editor: Add MeshRenderer component dependency for TextMesh component.
本来就该有的东西,现在加进来可以通过脚本对TextMesh做更多操作了。

Font colors are now applied as vertex colors, instead of by setting the color on the material. This makes it work better with <color> markup tags in rich text strings. The color property in the font importer has been removed, and instead there are now color properties on the GUIText and TextMesh components to let you set the color of text objects per instance instead of per font.
再也不用复制一堆不同Tint Color的字体材质了(看着心烦,关键是无法Dynamic Batching),也不用依靠Rich Text Tag(<color></color>)来为文字设置颜色了(手写tag繁琐无法维护),随意通过Color Picker控制颜色,而且不破坏Dynamic Batching!其实本该如此。

短时间游戏开发指南

英文原文名称是:#1GAM: How to Succeed at Making One Game a Month,作者McFunkypants拥有20多年的游戏开发经验,也是OneGameAMonth活动的发起人和组织者。

9RIA译林军已经翻译了中文版,质量不错,但是因为文章较长,我在此将文章的要点进行了总结,适合不愿意读长文的人或者是作为速查手册。

文中论述的游戏开发方法并不局限于“每月一游戏 OneGameAMonth”,对于短时间、小规模的游戏开发过程都是有指导意义的,它可以简单归纳为下列步骤:

  1. 精简第一版游戏内容
  2. 完成没有任何美术资源的MVP(最小可用原型产品)
  3. 不断迭代开发且每次只专注于一项内容
  4. 尽早发布,频繁发布
  5. 有始有终

我的亲身经历

Ludum Dare #25的时候我使用了类似本文的开发流程:快速完成极为丑陋的原型,然后不断丰富和完善游戏。这使我的整个开发过程显得格外轻松有趣、得心应手,而这个游戏也是我历届参赛作品中完成度最高、内容最丰富的。而那些从画面入手的游戏,虽然开始的时候轻松愉快,但最后总是会在某些方面完成度很低,而且后面的开发过程往往非常紧张仓促、令人焦虑,完全谈不上有趣……

游戏是多样化的,游戏开发者是多样化的,做游戏的方式也是多样化的,没有“最佳路径”,但本文的作者确实结合自己多年的独立游戏开发经验给出了一套不错的方法,在此推荐给大家。

ongameamonth_

现实:绝大多数独立游戏最终以难产告终

客观原因:独立游戏开始容易做完难——初期的激情转瞬即逝,剩下的开发过程往往艰难而枯燥。

主观原因:all-or-nothing开发思路——要么完成,要么一无所获,不给自己留后路,一旦半途而废最终什么也得不到。

解决方法:频繁存档——在通往游戏最终版的过程中设置多个存盘点,每一个存盘点都对应一个可发布的版本。

具体操作流程

1.头脑风暴

头脑风暴是个收集点子的好办法,但是在开始制作前请用下面的方法精简掉99%的点子。

2.两个清单:必不可少 & 锦上添花

作用:精简游戏内容,得出MVP(最小可用原型产品)需求列表

操作方法:通过初选和终选两部对头脑风暴结果进行评分和取舍。

初选,筛选点子的评分依据

  • 原创性
  • 可行性
  • 开发难度
  • 艺术资源需求量(美术&音乐)
  • 感觉它好玩吗?
  • 感觉编程实现它好玩吗?

终选,通过者进入必不可少清单,落选者进入锦上添花清单

  • 没了它游戏就无法运作了
  • 开发相对容易

“必不可少”需求清单 = 最小可用原型产品(Minimum viable product – MVP)
“锦上添花”需求清单 = 2.0版

3. 撰写电梯游说稿

elevator-pitch

作用:进一步精简游戏核心内容,初步检验游戏品质。

操作方法:把MVP的需求清单撰写成一段简短、激动人心的“电梯游说”稿。或者把他想象成游戏包装盒背面的游戏简述,它能否吸引玩家购买?

电梯游说稿举例:

你是一个坏人。有一对恋人想见面。你的任务是使用障碍物把他们隔开,阻止他们相见。这是一个基于A星寻路算法的回合策略游戏。

4.游戏流程故事板

game-story-board

作用:通过故事板数量衡量并精简工作量,模拟试玩,了解美术资源需求

操作方法:电梯游说稿的漫画版,画在一张纸上,别超过10幅图,可以给朋友看看。

要点:出现以下情况可以考虑放弃后续开发:

  • 无穷无尽的故事板——内容过多
  • 看起来不好玩

5.无美术核心玩法游戏原型(MVP)

no-art-game-prototype

作用:检验核心游戏机制。

操作方法:无选关界面,1个关卡,仅包含核心游戏机制

要点:此时别在美术上浪费任何时间,早期美术资源都会在最终版被遗弃。

6.美化MVP(首个存盘点)

pretty-mvp

作用:完成具备核心玩法,画面勉强过得去的版本,从现在起随时可以发布最终版了。

操作方法:加入部分美术资源(可以只是临时性的资源),测试游戏性能

7.不断完善游戏,但每次只专注于一项工作

作用:一步一个脚印向最终版前进

操作方法:从各种角度改进打磨你的游戏——游戏开发最有趣的部分开始了:游戏功能、美术音乐、文字对话……

要点:不要全面出击,每次只专注于一项内容,直至达到一个最低限度的可用状态。

8.多多存档

作用:天有不测风云,人有旦夕祸福,如果明天你因为某种原因无法继续这个游戏的开发,至少你有一个可以发布的近期版本。

操作方法:

  • 安全:频繁备份、使用版本管理系统。
  • 迭代式开发:每次专注于一项工作内容,频繁发布,始终保有一份可以发布的游戏版本。

9.有始有终

ss-pathos

作用:游戏只有被玩家玩到才能体现他的价值。

操作方法:果断地结束游戏开发,将剩余功能移到2.0版功能列表,发布游戏!

要点:

  • 接受不完美——你仍然有机会在后续版本中完善它。
  • 尽早发布,频繁发布——获得玩家反馈,获得更高曝光量

爱上C#的理由 之 implicit隐式转换

写机器能够读懂的代码简单,写人类能够读懂的代码才是真功夫,而C#则提供了诸多优秀的语言特性来帮助你写出更加整洁、易读的代码。今天介绍的是implicit隐式转换

作为例子,我们定义了一个HsbColor结构(struct),它与Color类似,是对于色彩的一种数学表示,只是其色彩空间为HSB,而非Color采用的RGB色彩空间,因此你可以通过HsbColor.s来设置色彩的饱和度。下面这个函数可以调整当前物体材质颜色的饱和度:

可以看出,在创建hsbColor实例的时候,我们在构造函数中传入一个Color类型参数,最后在调整完hsbColor的饱和度后,又通过ToColor()函数将其转换为Color,并给material.color赋值。这段代码并无甚不妥,只是在implicit隐式转换的帮助下,我们可以让它变得更为简洁:

从上面的代码可以看到,我们可以使用Color直接为HsbColor赋值,同样的,我们还可以直接将HsbColor赋值给Color类型参数——这就是数据类型的隐式转换,在HsbColor中我定义了这样两个静态函数:

它们实现了HsbColor到Color之间的隐式转换。

需要注意的一点是,采用implicit隐式转换的一个首要原则是数据转换过程中没有丢失信息(如精度),HSB和RGB属于同一色彩的不同色彩空间表示,满足这一条件。而如果是float至int这类丢失数据精度的转换,我们则应该采用explicit显示转换:A = (A) B,这样可以在编译过程中就提示程序员转换非完全等价。

implicit和explicit属于C#的一个很小的语言特性,介绍的文章也很多在此不再赘述,附上实例中用到的HsbColor脚本,除了提供通过HSB属性定义颜色的功能外,还提供了HsbColor.Lerp函数,使你可以在HSB色彩空间内进行颜色转换,比起RGB空间的Color.Lerp更加符合人眼色彩变化的观感:

爱上C#的理由 之 Extension Method

在Unity3D提供的几种脚本语言中,有很多理由爱上C#,在我心目中Extension Method无疑是其中一个。

在使用Unity3D提供的类库书写脚本时,是否经常有类似这样的抱怨:“为什么就不能为AAA类写一个XXX方法呢?!明明很简单的一件事,现在却需要绕这么多圈子!”例如下面这3行代码:

明明很简单的三件事,但是代码写出来却不怎么简洁明了:

  • 设置X坐标为3
  • 设置等比缩放为(3,3,3)
  • Log一段话

对于Unity开发者,前两行代码估计都写过,而且很可能是需要常常写。第三行的Log代码我使用了string.Format——我喜欢更接近自然语言的Log输出,因为它会让那些调试信息看起来不那么烦人,但是每次都写一遍string.Format和一堆括号确实是又麻烦又冗长。

假如我们换一种写法:

是不是更加易懂而且代码也更加简洁了呢?我给Transform添加了两个梦寐以求”的方法:SetPositionX(float)以及SetUniformLocalScale(float),并且给所有继承自Object的类添加了一个Log(string, args)方法,可以直接传入string.Format的参数。

要实现这样的扩展无需破解Unity的类库,只需要使用C#的Extension Method即可。顾名思义,Extension Method允许你从外部为已有的类添加“扩展方法”——而且无需该类的任何代码。例如上面三个Extension Method的脚本是这样书写的:

从上面的代码不难看出,Extension Method要求必须使用静态类封装,且需要依据这样的格式为方法命名:

这里面this在函数传参中的使用也算是C#中this的一种特殊用法。

虽然Extension Method善加使用可以减少一定的重复工作量,让脚本更加简洁易读,但它也不是万灵药,在书写过于复杂的Extension Method之前也许你需要慎重考虑是否应该为该类增添一个新的接口,而不是“把代码写在外部”。另外struct是无法定义Extension Method的,例如Unity中的Vector3和Color。

最后附上两个我做的Extension Method脚本,分别针对Transform和Debug做了几个扩展方法,相信在看了这两个脚本后,你一定可以自己动手写出那些“梦寐以求”的扩展方法了。

点击下载示例脚本