从 GDC 分享中汲取养分

awkwardness

indienova 约我聊一下这个话题(开发者如何最大程度地利用 GDC 分享提高自己的技术水平?),我觉得灰常汗~ 因为我自己都还有一大摞 GDC Talks 等着翻牌子已经很久了。这些自己的存货都还没来得及消化吸收,更遑论为他人提供有效的利用方法——实在汗颜。也正是因为 GDC Vault 的免费内容不少,虽然明知收费的里面有价值的内容更多,也还是几次三番地压抑着自己购买年费会员的冲动。


本文 6000 字左右,阅读时间 15 分钟。BTW, 如果没有细看开头图上的字,现在可以翻上去看一下——比正文有趣得太多,凡是参加过这类会议的同学,都会会心一笑吧~


首先想说一下参加行业会议(包括 GDC)的一个感受:坦白地说,如果觉得经常参与各色的行业会议,就仿佛能从演讲者身上快速获取价值,直接转化到自身的业务水平和技能提高上,那一定是种错觉。这就好像整天刷知乎,仿佛动动手指就能把大V们的见解化为己用,其实是一样的迷思。原因很简单——招式虽可模仿,但若缺乏内功和心法的支撑,一味地追求好的工具和方法,只会变成中看不中用的花架子(这方面我自己有深刻的教训和体会)。所以我们不要学 xx 记者,水平有限,但是跑的比谁都快。

那么内功从哪里来呢?多看书,提高理论水平;多写代码,提高实践水平。简单说,就是“多读多写,知行合一”。在这八个字的基础上,我们就可以来聊一聊从 GDC 这样的技术会议上可以获得的收获了。

分类

以策划/美术/程序的角度来说,最简单快速的甄别手段,自然是一键过滤掉各自职责 (Design/Art/Programming) 之外的演讲,可是这样常会错过有趣的议题。我的个人体会是,想要有效地从行业会议中提取价值,可以从三个值得关注的维度出发:案例 (Stories)、实践 (Practices) 和方法 (Methods/Approaches)。经验上看,这样以性质划分会比原始的按照 Roles (Design/Art/Programming) 分类要有效得多——快速地厘定你想从一场演讲中获得什么,有助于你安排与之相匹配的时间和精力。这里简单地展开一下。

案例 (Stories) 增长见识,开阔视野

最常见的案例类型是一款游戏的 Postmortem,成功案例和失败案例都有。跟自己的项目经历结合起来,会非常有启发。通常的 Postmortem 会有 "What Went Right" 和 "What Went Wrong" 两方面,这里我拿手头上 "Postmortems From Game Developers" 里的 Diablo II 举个例子。

Diablo II 有三个开发小组,每个小组十余人。
- programming
- character art (everything that moves)
- background art (everything that doesn’t move)

这应该是若干年后的 Scrum 的原型了 (项目组织按照 Features 而非 Roles 分组)。

What Went Right

  1. DIABLO II is still DIABLO (在仅保留了 1% >代码和素材,重写了图形引擎,改变了所有的职业和技能的情况下,仍然能让所有玩过的人异口同声地认为这是原汁原味的 Diablo)
    • We used the term “kill/reward” to describe our basic gameplay.
    • DIABLO II retained DIABLO’s randomly generated levels, monsters, and treasure.
    • DIABLO and DIABLO II are easy to play. We used what we call the “Mom test” — could Mom figure this out without reading a manual?
  2. Blizzard’s development process
    • First, we make the game playable as soon as possible in the development process. (The fun part has to be fun)
    • Also, we constantly reevaluate gameplay and features. ("we made two or three games and pared them down to the best one.")
    • Another gigantic reason for our success is our open development process. ("hire people who love games, and we make games that we want to play.")
  3. Character skill tree, QA and Simultaneous worldwide release

d2

"If we like the game we are making—especially if, after two years of playing it, we are not bored to death—the game is clearly going to be a winner." - Blizzard

以下是一些典型的 Postmortem 的案例分享:


GDC 2017 技术选荐合辑 一文中,我首先聊到的 Creating 'League of Legends' Champions: Our Production Framework Revealed 对我而言就属于此类。说到这里要补一句,每个人的发展方向不同,技能侧重点也不同——对有的人来说是 Practices 的内容对另一群人则是 Stories,反过来也一样。像这一场 LOL 的英雄制作,对于制作人,策划,美术和程序,会有不同的侧重和启发(横看成岭侧成峰)。

实践 (Practices) - 框架/工具/库,经验积累

实践 (Practices) 是对语言,框架,库,工具的设计,运用和改造,典型的例子有这些:

  • (GDC2017) D3D12 Performance Tuning and Debugging with PIX and GPU Validation(如何用新版的 DX12 的 Validation Layer 和 PIX 来诊断流水线)
  • (GDC2017) Surviving Apocalypse on Mainstream Graphics Optimizing DayZ using IntelGPA(如何使用 IntelGPA 来做图形分析和优化)
  • (GDC2017) How GitHub Works with Unity (怎么利用 GitHub 的特性来更有效地管理 Unity 工程)

方法 (Methods/Approaches) - 思路和方法,各类取舍及利弊分析

方法 (Methods/Approaches) 通常是一套抽象的思维模型,一个解决问题的思路,典型的例子有这些:

  • (GDC2017) FrameGraph: Extensible Rendering Architecture in Frostbite (一套具有扩展性的渲染体系)
  • (GDC2017) Data Binding Architectures for Rapid UI Creation in Unity (一套方便美术和程序合作的界面数据绑定方案)

方法和实践的对比

通常而言,实践(尤其是所谓最佳实践 Best Practice)往往是可以直接在手头的工作中复用的第一手经验。而方法则不一定适用,往往需要透彻的思考和深入的理解,然后再针对特定的情境做适用性的改造。

进一步讲,实践是“手头的工具” (hand-toolbox),而方法则是“头脑的工具” (mind-toolbox)。所谓“形而上者谓之道,形而下者谓之器”,从抽象和具象两方面与此二者对应起来。

三分类的用处 :在 Topic Forests 里更有效地提取信息

在短短的五天内,GDC 的演讲超过五百场,而且还需要留出一些时间去逛逛 Expo,现场体验一下不同的游戏,引擎和服务。时间会非常的紧张,没有什么比选择了不合适的议题更让人沮丧了。上面三种分类的最大好处,就是把自己从无数噪音中隔离出来,先默认大家都是角度各异的案例 Stories (听一下纯涨见识),只有非常适合自己需求和段位的 Topic,才值得提升成实践或方法,去细致认真地听和做笔记。

GDC-Tips

排日程的时候尽量优先排实践或方法,没有合适的再穿插着排案例。

Handy Tips

  • 不要错过会后讨论 - 如果觉得一个演讲有价值,那 QA 时别急着赶下一场,不要错过那些真正感兴趣的人留下来的小讨论,听听私下里大家的交谈 (n <-> n) 能获得比台上演讲时 (1 -> n) 多得多的细节
  • 结对复述 - 晚上如无特别的理由,不要把时间都花在 social party 上。尽量找那些跟你选了不同演讲的同事和朋友,跟他们互相复述自己听到的要点,会有两个收获:通过自己的语言来表达,能帮助自己整理和强化吸收到的信息;听别人的复述,可以弥补一些错过课程的遗憾。
  • 装备齐全 - 听课时的合理装备是 iPhone + (Mac Book 或 Surface Book 或 纸笔) 如果只用手机的话,光忙着音频/拍照/笔记来回切换了,有一个笔记本会好很多。其实这种场合下的拍照特别适合用 Google Glass 可以把双手解放出来,但我估计拍摄精度和电池续航都成问题。
  • 快速手动验证 - 维护一个 Test Lab 工程,有助于趁热乎快速地实验各种听到的想法和思路,如果验证有效就能直接转化成自己的技能点。(不动手就是纸上谈兵)

(完)
Gu Lu
2017-04-02


[注]

Comments
Write a Comment
  • 感谢分享!已推荐到《开发者头条》:https://toutiao.io/posts/q4gd8u 欢迎点赞支持!

    欢迎订阅《游戏开发杂货铺》https://toutiao.io/subject/528

  • 感谢分享!已推荐到《开发者头条》:https://toutiao.io/posts/q4gd8u 欢迎点赞支持!

    欢迎订阅《游戏开发杂货铺》https://toutiao.io/subject/528

知识共享许可协议
本作品由Gu Lu创作,采用知识共享Attribution-NonCommercial-NoDerivatives 4.0 国际许可协议进行许可。