6.2 建立愿景 Vision在线视频

OK那我们下面开始

建立愿景

这是第一步所有游戏项目最重要的一步

就是建立愿景

无论你是做的一个非常非常简单

单人开发者的独立游戏

还是一个

几百上千人的大型项目

都要首先有它

没有它大家可能会各自干各自的

甚至你自己今天和明天干的工作

可能都不是往一个方向走了

愿景是什么呢

愿景是描述游戏最核心最重要的部分

清晰的愿景是

项目成功的保障

但是问题是

什么是愿景本身可能就比较模糊

不是特别清楚

所以呢

这个是很多时候呢

是要靠

迭代 靠项目的进展

它会随着项目进展而变化

然后很多项目呢

很多项目呢

会有一个专门的人

作为Vision Holder

对吧

这个不是一定的

不是百分之百的

就是有些著名的游戏

比如说顽皮狗

他们现在有比较清晰的一个制作人啊

包括小岛秀夫

大家都听说过的游戏制作人

但是也有很多很多游戏

其实大家说不清楚制作人是谁

比如说我参与的Call of Duty

对吧就是使命召唤

它是谁做的呢

很难说清楚

那所以是不是有制作人

是不是有一个人

作为Vision Holder

这个人自己想没想清楚

没有那么重要

愿景是否清晰

在于执行者

关键词是执行者是否清晰

这才是标准

将来如果大家有兴趣

有兴趣进入这个游戏行业的话

参与游戏的制作的话

应该一开始会作为执行者开始

这个时候有的时候

如果大家看到有些团队就是

就是团队和团队的差别

执行者是否清晰

和这个愿景负责人是否清晰

就能看出一些区别

子系统也有愿景对吧

不是说我们只作为

一个整个大游戏

然后我们必须是Creative Director这样的一个职务

我们才在乎愿景

我们做一个很小的东西

它也有愿景

甚至极端地说

每段代码都可以有愿景

但是这个比较夸张

我们怎么传达愿景

我们运用一切手段去传达

不仅仅是项目文档

国内团队很多情况下喜欢

用一种excel或者word

或者是网页

长篇大论的设计文档

几十几百页

来传达它的设计

但是呢

像我们上面说的

执行者是否清晰是标准

如果你写了一万字的长文

没有人看

等于没有因为执行者没有读

所以愿景最重要的存在于执行者的心里

我们应该运用一切手段去传达

我们可以表演

可以写画

举例参考

举例参考国内的公司比较擅长啊

用各种各样的方式来传达

而且尽量传达清晰

那传达完了以后呢

不代表我告诉你了

你就清楚了

很多时候是需要达到结论共识的

这个共识可能与

这个传达者心里想的

和这个执行者心里想的都不太一样

是一个中间点

但是呢

这个共识一般来说是会被

作为最后执行者执行的时候的一个过程

所以这个结论

这个共识才是我们最终最可能在

游戏中看到的状态

当然

实际在落实到工作中还会有变化

还会有不同的情况

OK

那我们现在尝试建立一下我们三消的愿景

那我们按照一个比较标准的一个三消游戏

我们去描述它一下

下落的砖块

然后玩家可能可以去交换砖块的位置

对啊三个同色的砖块连在一起就会消失了

这个其实

如果大家没有玩过三消游戏的话

会觉得这个东西很模糊

说了个啥

是个俄罗斯方块

所以然后可能会有些人说

我来画个流程图

流程图是这样的具体内容

大家不用去细看

有个流程图

但是像我们刚才讲的就是

这些东西都没有那么清晰

能去传达

愿景到底是什么

OK

那我们可能说

那我们看一个例子

看一个别的三消游戏

这下清楚很多对吧

但是我们要做的是它吗

肯定不是它

除非我们是要做换皮

但是

一般来说

我们可能做的就不是它

那我们可以参考它

我们进行尝试描述

比如这个是一个

可能游戏设计人员想传达给程序员的一个

比较清晰的

而且有一定细节的一个文档

他可能会这么讲

说这是一个N乘M尺寸的

布满砖块的板子对吧

然后呢

它定义一下什么叫做三消什么叫Match

三个或以上同色砖块连成一线叫Match

然后形成Match的砖块会消除并加分

然后呢

玩家的操作是玩家可以

交换相邻两砖块的位置来形成Match

这比咱们刚才描述的稍微清晰一点

辅助这个例子

可能就大概的明白

我们想做的是这样一个东西

对吧

最后还有一个消除后的空位

上方的砖块会下落补充

对吧

这个看起来比较清晰了

OK我们懂了对吧

但是

我们刚才说文字可能不如图像清晰

图像可能不如例子清晰

那我们先来看一个例子

看一看想做一个什么样的东西

明确了愿景以后呢

它只是一个比较大的一个picture对吧

这就是我们想做这么一个东西

然后这东西可能不是特别明确

这个时候我们就需要用到分治策略

这个是今天我想讲的一个比较重要的思维方式

计算机里面大家计算机系可能也听说过

也听说过对吧

这个有很多的

这个很多算法呀

很多的就是策略都会应用到这个策略

那

具体什么叫分治策略

就是很简单

将一个大的东西

拆成几个比较小的东西

然后一个一个攻克

作为愿景来说呢

将愿景分拆为易于实现的模块

当然

是要按个人和工作团队工作习惯对吧

然后这个图希望大家注意

今天在后面会多次出现

然后

这个思路也可以用于分析成品游戏

一会我们看一个例子

今天顺便说一句

今天我用了很多种英文的

这个单词在里面

不是因为装逼

就是因为确实欧美游戏开发

它比较发达

然后呢

所以他们很多词中文里面

在我没有应用到的时候

没有这种翻译不太准确

那比如说Divide and Conquer

今天大家就记一个单词就行了

记住这个词OK

那我们尝试分析一下

超级玛丽对吧

这个大家都比较熟悉

我们尝试分析一下

用分治的策略

我们说看着这张图

大概能拆出这些东西来

但是

假如说我们是要做这个游戏了

那拆成这样以后

可能我们在跟其他的团队成员一起讨论的时候

它就会出现一些问题

比如说

这个分数

分数是不是应该算在主角下面呢

因为你把火球算在主角下面

分数是不是也应该算在主角下面

你只有主角能得分嘛

对不对

还是说他应该算在敌人

因为每个敌人可能得的分不一样

那水管是不是水管

是不是算关卡的一部分

还是算地形的一部分

包括像火球和飞锤

那火球和飞锤可能

这个时候有一个做这个

飞行物的程序员站出来说

它俩应该是一个东西

因为它俩都是我做那个系统用的对吧

这个时候

另外有人说那不对

那金币他是不是也算飞行物

只不过它不会飞不会动

只是漂浮物呢

这些问题呢

没有绝对的答案

然后呢

有一些新团队可能会在这个时候

陷入争吵

这个时候其实没有必要

这个阶段很多这种东西不需要纠结

先往下推进是最重要的

那

我们也会面临类似的问题

所以呢

我们现在先尝试拆解一下我们的三消对吧

大概要素分一下

这个世界板子

砖块计分板菜单

计分板菜单

我们可以先忽略

先看这几个对吧

那世界肯定是整个游戏的容器

它可能有关卡

它可能包含你的玩家的一些什么形象啊

或者是有一些道具

然后呢

板子就是这一关

跟这个具体

比如说第一关

第二关第三关

然后呢

包括它的静态的要素

那砖块呢

就是实际上往下掉的东西

和玩家会去拖动的东西

大概这么一分

那这时候我们也出现了一些矛盾

对吧

砖块所占的这个格子

因为有的时候这个格子“啪”砖块

消除了

剩下一个格子

这格子是啥呢

我们刚才没提

可能是板子的一部分

然后板子和世界算是一起的

还是算是俩

因为假如我们做这个游戏没有关卡

就一关对吧

那它俩是一个东西还是俩东西

然后比如说我们假如有规则

我们说就怎么算赢的这个游戏

是你消除到一定分数还是时间到零

时间到零

什么时候什么时候算赢

这个规则

是由世界管理还是由板子管理

各有各的道理

我们先不定对吧

没关系

这个时候

我们介绍一个新的原则

When in doubt KISS

什么叫KISS呢

Keep It Simple and Stupid保持最简

不确定的东西

我们比如说有方案A 方案B 方案C

然后我们也不知道哪个好

哪个不好

没关系

选一个最简单的

哪个最好做我们先做哪个

因为为什么这样

为什么这样做

这可能尤其我们学计算机的同学可能觉得你这个

没有计划

然后改来改去

然后你又不事先思考未来

可能很多情况下不优化吗

确实是但是呢

不确定性啊

在这个项目上

尤其在玩法开发而不是算法开发

玩法开发算法开发不太一样

玩法开发呢

不是一个纯技术的东西

很多情况下

我们碰到这种不确定性的情况下的时候

如果我们让争论和这种

甚至有的时候团队就会产生一种恐惧感

这种恐惧

来影响我们决策并推进的话

那我们项目可能就推进不完就做不完

那我们知道你的项目做得再好

如果你做不完的话

上不了线的话就等于没做

而且还有另外一点呢

很多时候我们其实不知道

外部环境会怎么变化

到底你现在做的所谓的为未来思考的一些决策

是不是将来能好使

你现在花了两个月做一个东西

然后做完以后第二天

设计改变了东西白做了

这种情况时有发生

所以我们不如保持灵活

保持简单

还有一些类似的业界比较流行的一些概念

对吧

YAGNI-You ain’t gonna need it

If it ain’t broke don‘t fix it

简单翻译两句就是引而不发

就是你提前做了一些准备工作

觉得我将来一定会用到这个什么什么什么

一个小的漂亮的小算法我写到的

但是你现在不用的话

将来很有可能不用

所以这个原则就是说

先别写等你啥时候需要啥时候写

然后呢

忌未雨绸缪

就是有的时候有一个东西

其实好使

但是因为写的不太干净

不太符合

咱们比如说程序的这个开发的这个

我们的理想状态

比如教授看到可能会皱眉

然后我们就想

我把它重构一下

先不要搞

等到它有问题的时候再这么做

我们简化一下

我们用KISS原则

我们简化一下它可以省的全省

该砍的都砍对吧

刚才不是说板子不确定吗

不要它

把他放到世界里

这样比较简单

砖块所占的格子不确定

先放到世界里