一场撕逼:UGC游戏平台是否可行?

前几天在QQ上和策划无双展开了一场关于UGC平台的撕逼大战,最终没啥结论,但在撕逼的过程中形成了一些思路,整理出来遂成此文。

一切都是从Roblox开始撕的

Roblox是个啥?是个向玩家提供开发游戏的简易工具,并让玩家可以把自己开发的游戏发布至Roblox平台供其他玩家一起游戏的面向低龄用户平台(主要是小学生)。在这个游戏中凡是大于13岁的玩家年龄统一会显示成13+,并且年龄是和玩家名一样重要的元素并列进行显示,因此可以看出官方对于打造其小学生定位所付出的努力。

能自己做游戏然后上传的平台?很耳熟是吧?

没错,听起来就跟当年《魔兽争霸3》的各种对战平台差不多(当然了现在已经有了官方的魔兽对战平台),或者说像是《星际争霸2》的“地图大厅”、《DOTA2》的“游廊”:一个内容消耗平台或者说社区,大量的内容消耗者消耗着一波创作者所提供的内容,因此本质是一个内容消耗型的UGC平台或者说是社区。

所以从性质上来说,Roblox和橙光、抖音是一样的,但是为啥Roblox上线了这么多年没人听说过呢?

或者说为啥《魔兽争霸3》的对战平台,《星际争霸2》的地图大厅还有《DOTA2》的游廊都凉了呢?

我觉得,这就不得不面对内容消耗型UGC的平台的三个致命问题了:

  1. 创作者为什么来你这个平台?
  2. 用户为什么来你这个平台?
  3. 平台的极限在哪里,或者说盘子有多大?

先有鸡还是先有蛋

先回答问题1还是先回答问题2,这是个特别难以回答的问题,这说白了是个先有鸡还是先有蛋的问题,即到底根本性的服务对象是创作者还是用户。

按我个人的理解,这种UGC平台根本性的服务对象是创作者,其次才是用户。在这种平台的早期,核心用户肯定是创作者社群,并且这个群体中会有很多的大神会成为意见领袖拥有众多粉丝,只有抓住了这一批创作者用户,平台才能有足够优秀的UGC内容,有了内容才有运营的基础,才会存在引爆的可能性。到了平台的后期如果已经进入稳定阶段了,服务对象更是创作者了,甚至可以从创作者这里进行牟利,比如渣浪微博,你懂的。

按这个逻辑来说,B站服务的是up主,《星际争霸2》和《DOTA2》服务的是MODDER,橙光服务的是AVG作者,抖音服务的是……抱歉我不玩抖音所以不知道抖音里面发视频的叫啥,但道理都是一样的。

如果我们把这种平台比喻成一片农场的话,那么创作者群体就是在里面辛勤耕作的农民,而消费者群体则是来消耗农产品的客户。假如我们即不对创作者群体收费,也不向消费者群体收费,那么这一部分成本就必然会转嫁给第三方,比如广告商。假如我们对消费者进行严格的收费,那么就会变成一个订阅制或者说会员制的平台,就像Netflix。假如我们对创作者进行投资,对消费者进行收费,那就变成了传统的出版业。假如我们对创作者进行投资,同时对消费者即允许免费也允许氪金的话,就变成了直播平台和大部分网文平台的模式。各种模式哪个好用,以我个人的水平还是很难判断的,但无论如何,要求客户花钱的模式在中国估计是行不通的,给免费用户解锁大部分的内容是最常见的。

这就是为啥《星际争霸2》凉了的原因,因为他是个付费游戏,不管是创作者还是消费者都需要先掏钱买门票,注定凉凉。

如何吸引创作者,我觉得分两个方面,即这个UGC平台的下限与上限。下限,我指的是参与UGC平台进行创作的门槛有多低;上限指的是UGC平台所能产出的最高品质的内容是在什么水平。下限越低起步越容易,创作者群体数量越多;上限越高平台的质量越高,能吸引来的用户越多,平台的极限越大。

再说回《魔兽争霸3》的例子,其下限并不低,因为学习其编辑器是很难的,没有任何程序基础的人想要入门要花少不少的功夫去学习;其上限在当时来说是很高的,因为可以诞生《DOTA》这种级别的作品,但随着时间的推移,其画面的过时让其上限不断贬低,《DOTA2》出了之后就已经沦为非常小众的平台和工具了。

然而橙光就不一样了,其下限非常低——AVG类型的游戏不需要任何代码知识,平台提供了大量的背景、音乐、人物素材,所以随便是谁都可以参与创作。其上限又非常高,因为AVG类型的上限并不依赖于硬技术,美术、音乐,以及最重要的剧本水平都是软实力,因此其存在不断产生爆款的可能性。我个人认为这也是为什么66rpg要从RPGmaker转型去做AVG的原因,正是因为他们看中了其超低的下限和超高的上限,从而放弃了在技术上落后的RPGmaker,完全避开了这一类的短板。

类似的,从这个角度来看抖音的话,其下限非常低,因为只有十几秒的短视频随随便便谁都可以参与创作(微信的视频只有10秒我认为也是这个原因,一旦视频是几十秒甚至几分钟,那么对于一般人来说是很难创作出品质尚可的视频的,会大大打消其创作积极性,提高下限);其上限非常高,因为抖音并不提供专业的视频编辑功能,上面发的视频可以用现有的专业视频创作软件进行创建与发布。这是抖音成功的一个基础条件。

然而,橙光和抖音的区别也是十分明显的,就是橙光受制于AVG这一种游戏类型,因此其平台的极限必然是比不上抖音这种全民级产品的。短视频是目前在移动设备上能够体验的最佳的媒体形式了,受众极其广泛;而AVG这种几十年都没怎么变化过的形式,受众十分有限。橙光目前的做法应该是在想方设法拉网文的用户,但目前结果如何我还不太清楚,但短时间内应该还是没法撼动或者说代替网文这一形式的,因此其平台的极限,可预见的未来内都看不到明显的爆发点或者说突破口。

再说回Robolox

再说回Robolox,其定位为什么是小学生,这个答案就呼之欲出了。他们的创作工具非常简单,因此小学生都能入手,这是其最大的卖点。市面上总是会蹦出来宣称不会写代码也能顺利开发游戏的各种轻量级引擎和编辑器,他们都是在打这一个卖点,而Robolox所更进一步的是它不满足于自己的工具属性,而是想要做平台。

但是,UGC内容的下限和上限在游戏开发这个领域中往往是矛盾的,越易于掌握的工具为了降低其理解难度,其模块化越强,但泛用性或者说专业性也就越差。打个比方,如果说专业的游戏开发引擎Unity可以类比于视频编辑领域的AE或者PR这种软件,那么Robolox大概相当于爱剪辑这种水平的货色。美图秀秀也是一样,作为一款为没有P图技能的人提供快捷P图的工具,其上限必然是低于PS的,因此如果在它的工具属性上想要转成UGC平台就必然面临着所有的内容没有一个能打的情况,甚至像直播平台一样,三俗网红脸满地都是,这是其下限低而上限又不够高的特性所必然导致的结果。

Robolox自己也明白上限太低了,没法跟专业的开发工具所开发出来的内容打,因此他们降低了目标群体的年龄为小学生,这部分用户都没有什么大型游戏的经验,因此对画面烂体验差的游戏的包容度更高,而且比较简单的玩法只要还可以也能够玩的津津有味,因此Robolox在这一块上是非常聪明的。

但是,也因为其限定了群体就在小学生之中,因此永远无法和专业的游戏开发工具相提并论。

那么为什么Unity不搞UGC平台呢?

如果我们按这这个思路继续往下推进,就变成了这样一个问题:为什么Unity不搞这种UGC平台呢?我做个Unity Store上面都是用我Unity开发的游戏,不好吗?Steam上、AppStore上、Google Play上充斥着大量用我Unity做出来的游戏,我为什么不直接把这些玩家都直接攥在手里呢?

答案很简单,因为Unity的下限太高了,不是专业的开发人士压根没法驾驭这种工具。游戏开发是一种下限极高的生产活动,这就导致了游戏开发行业和用户的距离是很远的,很多的游戏玩家压根不知道游戏引擎个啥,什么是网游什么是单机也分不清,更不用说知道不知道Unity是啥了。

因此Unity的做法就是服务好开发者群体,提供针对开发者群体的教程、社区、各种工具、各种演讲各种活动,这就行了,它们是基本完全不在乎更下游的游戏玩家群体的。

我们可以想一想还有哪些是下限极低上限极高的活动,有可能做成UGC平台。

做饭算一个,下限低上限高盘子又大,下限低到了人人都可以做的地步,但上限高到了米其林三星餐厅那呢。但是这种产品已经有了,比如下厨房,抖音上也不乏这种东西。但是这种产品有一个问题就是你只能看别人做,又吃不到,因此其教人做饭的工具性过强,大家就不怎么在乎其他人的UGC内容了,我只看菜谱不看菜这是最大的问题。

唱歌算一个,下限低上限高盘子又大,人人都能唱歌,上限在帕瓦罗蒂那呢。但这个产品也有了,全民K歌什么的。但这种产品难做在大家唱的歌都不是原创的,而是唱的市面上的歌,市面上的歌你要搞到自己的app或者网站里面就会面临版权问题,那么这种app除了业内几家有音乐版权的大厂子以外也都不用想了。

那就不存在下限低上限高盘子又大的游戏UGC平台吗?

我觉得不存在,原因前面已经说过了,在游戏开发这种高技术生产活动中,下限低与上限高是矛盾的,能走的只有一条路,就是专精服务某一部分用户。橙光选择了开发下限低上限高的AVG品类与对应的用户,Robolox在上限不足的情况下则通过年龄来筛选用户。

被66rpg所抛弃的RPGmaker在日本也是有着固定的一小撮Free Game群体,这我还基本都是从岚少那里看的,日本有个也算不大不小的用RPGmaker做恐怖游戏的圈子,但这个群体还是太小了。Mugen是一个专门做格斗游戏的UGC圈子,同样也是下限很高,圈子太小。和橙光相比,这些都太小太小了。

另外,游戏UGC还存在一个问题就是大部分玩家并没有游戏设计技能,因此就算他们有开发能力,制作出来的游戏的可玩性也不一定有保障,不管是《魔兽争霸3》的地图还是Mugen里面的各种格斗角色,都有相当一部分是胡high性质的,这也是一个问题,不管下限是低是高都是如此,在这种情况下上限要足够高就显得更重要了。

能否产生一个下限极低上限极高盘子又足够大的游戏UGC平台呢?这是一个我还没想明白的问题,大家如果有什么看法的话欢迎留言交流。

版本延误

上周四是要出0329中间版本的时候,在这一天发生了版本延误的问题,导致加班到晚上十二点多才结束。

发生这个问题的表面原因是,原本计划中这一天所出的版本是不包含引擎升级的内容的,而在晚上四五点的时候又决定要在这个版本中加入,而升级引擎的时候又导致某些尚未完成的功能合并代码的时候发生了问题,因此解决引擎升级,以及一些功能合并代码耽误了很久的时间。

有一些原因是客观的。由于这是年后第一次按照新的迭代计划来安排工作,因此在出中间版本和最终版本方面的计划上是第一次经历,在进度安排上经验不太足。第二个问题是这个版本正好还赶上了引擎升级,本身就是一个特殊的版本。第三个问题是当天办公楼的电信宽带还出了问题,导致出包上传速度极其缓慢。第四个问题是这个版本是跨年的版本,中间赶上了长时间的假期,节前有三天时间开发这个版本,因此节后只剩下了一周半,再加上过节请假导致人员不齐,所以这个版本不是以全力进行开发的。

但排除这些因素,还暴露了一个团队上进度安排的问题。在年前的时候就已经完成了引擎升级的工作,但我们在年后回来的进度会上还是一开始决定了这个中间版本不把引擎升级的代码合并进去,且团队成员一直在用老版本引擎的编辑器进行开发,这个安排是不合理的,这种内容赶早不赶晚,应该尽早让团队成员把编辑器的版本都升上去,而不是等到功能都开发完成后再升级引擎。当然,过早的升级编辑器也有风险,很可能导致新功能的开发受到阻碍,因此如何评估这个风险就暴露了另外一个问题:

安排进度的人,对于这个功能的风险评估是不充分的。到底应该尽早升级引擎还是等功能都做完了再升级引擎,事先并没有进行充分的讨论,因此基本可以说是迷迷糊糊的就确定了这个版本不升级引擎,而不升级的理由其实没有仔细想过。

因此以后这些程序独立作业的功能上,还是要加强沟通,完全的评估后作业内容和风险以及和其他功能互相影响的程度,再进行合理的安排。

游戏开发中的多语言文本管理

好久没写博客了,今天趁着还在排魔兽副本的功夫上来写一篇!

由于之前没有经验,这个项目在做的时候,在多语言文本管理这方面做得很差,到了后期字符串基本成了一个无法管理的状态,随便要改点什么字都需要在一个存了所有游戏文本的5000多行的巨大txt中搜索,极其不便;而且有相当多的字符串是已经在游戏中删除掉的废字符串,但却依然停留在文本文档中。所以我想要总结一下经验,参考一些其他游戏的做法,看看能否用更好的方式来解决这个问题。

首先第一个要解决的问题是,如何让程序自动对应不同版本的语言?在设计界面的时候一定要方方面面都把这个考虑进去,否则一定会出问题,比如显示中文刚刚好,显示英文却太长了。不过这不是本文的重点,更多的相关内容可以看这篇文章。我们需要用ID来管理所有文本,比如说我们有个英雄,英雄的ID是100,他的说明文字就可能是hero_100_description之类的。ID的这种命名方式对于程序来说没有意义,不管是hero_100_description还是GameStringS1293IU634EASD,对于程序都可以正常运行,但采用后者会让字符串的可读性相当差,因此最好由策划来手动为所有需要用到的文本ID进行命名——就像美术人员会为所有美术资产命名一样。这种命名的好处还能让你轻易地剔除掉已经不再使用的废字符串。

ID可以按照统一的模块来起名(横向的),也可以按照实际的程序结构来起名(纵向的),个人建议采用后者的方式。假如按照前者的话,我们有可能将所有的UI使用到的文字都写作一样的内容,比如都叫UI_Title_XXX,但实际上游戏并不需要同时加载所有UI的文本,每个界面要用到的都很有限,因此按照程序结构来划分会更科学一些,这需要与游戏程序一同进行设计。不过由于纯文本文件往往都很小,不像美术资产一样会占用大量内存,因此在确保没问题的情况下偷懒一下,在任何地方都加载所有文本也可能可以,这还是需要看程序方面的意见。

ID的名字在允许的情况下,为了可读性,可以起的尽量的长,这需要与程序一同设计。比如,UI_MainMenu_NewGameButton_Normal,就说明了这个文字是用于显示UI的,是在主菜单用到的,是“新游戏”按钮在默认情况下的文字,这种清晰易懂的名字无论是程序在代码中还是策划在文本管理中都会让工作轻松得多。

如果需要制作新内容的时候,策划可以先添加所有需要的文本及其ID,再让程序制作,流程上也会更顺畅一些。如果某个字符串没有填写,则直接在游戏中显示其ID,这样能在游戏中轻易地发现是哪个字符串忘写了。

当某些东西的结构固定时,甚至可以统一、批量地先由程序生成ID,再有策划进行填写——比如英雄有100个,每个英雄都有描述,程序就可以先把hero_001_description到hero_100_description直接做到游戏中——《星际争霸2》就是这么干的。

如果字符串需要换行,建议使用在单个string中加入诸如\n的方法,而不是使用多个string,因为同一句话不同语言显示出来行数往往不一样,如果用多个string的话ID管理会变得相当混乱,很可能中文一共有5000个ID而英文却有5010个ID,具体多了哪10个就是个要命的事情。文本的样式管理应该和程序、美术一同进行设计,尽量把文本的样式也写进string中再由程序解析,比如:

  • <string><c value = “FF0000”>我是一个红色的文本</c></string>
  • <string><b><c value = “FF0000”>我是一个红色加粗的文本</c></b></string>
  • <string><size = 24><b><c value = “FF0000”>我是一个红色加粗的24磅的文本</c></b></size></string>

这样做法的好处是在保留一定可读性的前提下,修改文本样式不再需要程序的协助,能够大大降低开发过程中的沟通成本。实际上这也是《星际争霸2》的做法。

不过笔者认为,《星际争霸2》也有不值得学习的地方,就是其不同语言文本的文件结构。由于该游戏支持相当多的语言,因此他们的做法是把不同的语言文本完全分离在不同的文件中,比如中文文本都存在zhCN中,英文文本都存在enUS中等等,这样的问题就是在两个文件中,我们都要以“ID+String”的方式进行管理,无法确保ID的唯一性。因此相比之下我更倾向于《魔兽世界》插件或者《炉石传说》的结构,将不同语言的文本全都放在同一个文件中,这对于策划以及游戏翻译外包来说是都是相当舒服的事情,下面是例子:

《魔兽世界》插件的多语言(以Decursive为例子):

## Title: Decursive |cffff00ff -Ace3-|r
## Notes: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.
## Notes-frFR: Affichage et guérison des affections avec un système évolué de filtrage et de priorité.
## Notes-deDE: Anzeige und Reinigung von Gebrechen für Solo, Gruppe und Schlachtzug mit erweitertem Filter- und Prioritäten-System.
## Notes-esES: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.
## Notes-esMX: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.
## Notes-koKR: 쏠로, 파티, 공격대를 위한 고급화된 필터링과 시스템 우선권으로 고통들의 표시와 제거를 합니다.
## Notes-ruRU: Отображение и инструменты для развеивания дебаффов для одиночной игры, игры в группе и рейде, с развитой системой фильтрации и приоритетов.
## Notes-zhCN: 当单独、小队和团队时清除有害状态,并可使用高级过滤和优先等级系统。
## Notes-zhTW: 當單獨、小隊和團隊時清除有害狀態,並可使用高級過濾和優先等級系統。
## Notes-ptBR: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.
## Notes-itIT: Afflictions display and cleaning for solo, group and raid with advanced filtering and priority system.

炉石传说的例子:

<Tag name=”FlavorText” enumID=”351″ type=”String”>
<enUS>Hogger is super powerful. If you kill him, it’s because he &lt;i&gt;let&lt;/i&gt; you.</enUS>
<zhTW>霍格非常強。如果你殺死他,那是因為他&lt;i&gt;讓&lt;/i&gt;你殺他。</zhTW>
<zhCN>霍格可是超级厉害的。如果你杀了他,只是因为他让你这么做的。</zhCN>
<ruRU>Дробитель ужасно сильный. Если вы убьете его, то это значит, что он вам &lt;i&gt;поддался&lt;/i&gt;.</ruRU>
<ptBR>Hogger é superpoderoso. Se conseguir matá-lo, foi porque ele &lt;i&gt;deixou&lt;/i&gt;.</ptBR>
<plPL>Wyżer jest supermocny. Jeśli go zabijesz, to tylko dlatego, że ci na to &lt;i&gt;pozwolił&lt;/i&gt;.</plPL>
<koKR>들창코는 정말 강력합니다. 만약 처치했다면, 그가 &lt;i&gt;봐줬기&lt;/i&gt; 때문입니다.</koKR>
<itIT>Boccalarga è potentissimo. Se lo uccidi è solo perché lui te lo ha permesso.</itIT>
<frFR>Lardeur est super fort. Si vous réussissez à le tuer, c’est uniquement parce qu’il vous aura &lt;i&gt;laissé&lt;/i&gt; faire.</frFR>
<esMX>Hogger es muy poderoso. Si lo matas, es porque &lt;i&gt;él&lt;/i&gt; así lo quiso.</esMX>
<esES>Hogger ya se ha cobrado más víctimas que el Cataclismo.</esES>
<deDE>Hogger ist so mächtig, dass Ihr ihn nur töten könnt, wenn er Euch &lt;i&gt;lässt&lt;/i&gt;.</deDE>
</Tag>

不过这种做法也有一个难题,就是如果新加一个语种的话会影响到之前的所有结构,所以无论采取哪种结构,最好都有文本管理工具,而不是直接手写txt。但比起传统而常见的每个语言一个文件其中把所有系统需要的文本都丢进去,我更倾向于按照系统划分文本文件,然后把所有语言的丢进同一个文本中。当然了,这还是要看程序是如何设计的,以及游戏的过程中是否支持切换语言。

如果你有更好的做法,欢迎和我交流经验,我的博客地址是www.maniahero.com!