标签归档:Ludum Dare

Ludum Dare#28经验总结

总体感受

最痛苦的一次参赛经历,在最后几个小时才拨开云雾见青天。游戏性过得去,创意和动画满意,首次加入人生录音,效果拔群。

做对的地方

1. 没有放弃

开发后期面对着无聊的游戏原型,独自置身黑夜中的我好几次想要放弃,因为觉得游戏没意思、没前途,而且其他参赛者也有不少放弃的……

没放弃,是因为不想为Ludum Dare的参赛记录留下不光彩的一笔,不想让这4个月的等待、家人周末的陪伴与支持,最终只换来遗憾。

做完之后再看游戏,发现也没有之前感觉的那么没意思,而且之后的开发过程也峰回路转,为我带来了莫大的乐趣和成就感。

痛苦的开发经历理论上可以通过优化开发流程来改善(详见后文),但如果没有坚持,也就没有后来我这一切的收获和现在这篇文章了。

2. 首次献声

英雄、僵尸和那句贯穿始终的“CLUB MAN”都是我配音的,过程有趣,效果拔群——特别是CLUB MAN那句有效地为游戏烘托了超级英雄宣传片的感觉。

录音原本一直认为觉得费时费力,现在来看反而能够更快得到合适、高品质的音效。

做错的地方

1. 卡在创意阶段太久

首先值得一提的是,“You only got one”这个主题似乎并不那么适合创新,从博客上的反馈来看因为没有好想法而退出的人大有人在。而我在创意阶段花费了整整一天——面对着纸笔埋头苦想。这不仅严重压缩了游戏开发时间,也严重消磨了我的激情。

我基本已经认定我不是那种创意丰富的人,但我却不能放弃对新颖创意的追求——所以我注定经受苦难。

回顾第一天折磨人的创意过程,我觉得可以从下面两个途径适度加速这个过程:

  • 别老刷博客——开赛初期的一些博文确实对启发灵感很有帮助,但几个小时后充满博客的开发进度文章只能让你焦虑。创意过程需要脑子中塞满东西并进入忘我境界,刷博客只能分散你好不容易聚焦起来的意识。
  • 动手做点东西——空想并不能准确估计创意的好坏,而很多新的可能性会在动手实现的过程中浮现出来。

2. 太晚加入美术和音乐素材

太晚了,实在是太晚了,晚到我几次想放弃本届比赛……

按照之前的经验,我首先完成了能够验证游戏玩法的超级丑陋版游戏原型,然后开始优化操作、制作新关卡、调整游戏玩法……总之在此之后,我一直面对着立方体和球体,从除了视觉和听觉外的一切方面去将游戏推向最终版——直到我烦躁、痛苦、绝望到想要放弃了,因为我觉得这个游戏没意思。

但当场景贴图、角色模型、动画、音效、台词被逐步加入游戏中后,还是那些关卡,那个玩法,但游戏却变得有意思多了,而开发过程也变得趣味盎然起来。

这一经历彻底粉碎我之前的“机制玩法至上论”——所有周边的一切共同作用、相辅相成才能得到好的游戏体验。

在开发过程中,艺术资源也应当随着程序、游戏机制一起迭代开发,并尽早介入进来。至少要看起来像个游戏,做起来才有意思。

Ludum Dare #28 棒槌侠

游戏试玩
Unity工程文件
Ludum Dare作品页面

你是一位生活在和平年代的英雄,人送外号棒槌侠。这个时代已经没有怪物可杀,唯有一只僵尸幸存了下来,你必须善用这只僵尸为自己争取名望和财富。

在这个时代,就连地下城里也布满了监控摄像头,而你打算在这些摄像头下上演砍杀僵尸的大戏,制造出世界上依然充满魔物的假象,证明这个世界依然需要英雄!

你只使用棒槌作为武器,因为它不会对僵尸造成致命的伤害,因此人们都称你为“棒槌侠”!

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. 工具、成员列表,统计数据……

Ludum Dare#27经验总结

每次Ludum Dare结束后都有一些遗憾,句式大多如下:

  • 如果XXX能再完善一些就好了
  • XXX突发状况害我浪费了XX小时

其实每次都会有不够完善的方面,每次也都不可能48小时完全不受干扰火力全开,所以上述这种”经验“也就没必要总结了。捡关键的少说点。

总体感受

开发过程比较惬意,Blender建模很过瘾,对游戏创意比较满意。

做对的地方

  1. 用快速游戏原型来检验创意:我一直热衷于卡在游戏创意环节——这次我是纠结于两个游戏创意:以鹰的视角展现鹰的生活片段;用总计10s的光照走出地牢。在左右为难10分钟后,我用1个小时做了两个游戏原型,然后毫不犹豫的选择了后者。虽然鹰的视觉效果受到好评(19个like),但他的游戏机制并不明确,需要更多游戏设计工作,时间紧张故弃之。
  2. MVP(minimum viable product)优先:我用一天时间获得了丑陋的MVP,用另一天享受轻松惬意的游戏开发乐趣。游戏开发过程中有太多可以让你沉迷的环节(美术、音乐、关卡设计)——不要犹豫,尽管沉迷并享受它们!MVP会保证你始终有一个可以发布的版本。
    ld27-mvp

做错的地方

  1. 将丰富关卡排在了日程表最后:Candle Man的游戏乐趣严重依赖于关卡设计,因此关卡构建模块我早已做好,我的脑子里充满了各种有趣的挑战和陷阱,我觉得构建10个关卡简直易如反掌!于是我一直没有管他直到游戏提交前40分钟。最终我只得到了7个未经调校的关卡,未能达到它本应有的丰富程度。在得到MVP后我赞同“随心所欲”地去逐步完善游戏,但随着Deadline的逼近,还应该加入对“投入产出比”的考量。
    screenshot_ld27_6

游戏开发过程Time Lapse + 游戏演示视频

Candle Man游戏介绍页面

Ludum Dare #27 蜡烛人

游戏简介

一根会走路蜡烛发现自己深处漆黑的神秘地牢之中,好在他可以燃烧自己照亮四周——但火焰只能维持10秒,他必须谨慎使用这来之不易的短暂光明逃离这里!

操作方式

  • 移动:ASDW / 上下左右方向键
  • 跳跃:空格
  • 燃烧蜡烛:空格 / L

游戏试玩
Ludum Dare游戏页面:Win,Mac,Linux版下载+工程源文件下载

短时间游戏开发指南

英文原文名称是:#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版功能列表,发布游戏!

要点:

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