当前位置: 华文问答 > 游戏

尽量不使用游戏引擎提供的工具来制作游戏是正确的思路吗?

2022-06-02游戏

不请自来。

在游戏行业做了很多年,遇到过很多人,但说一句可能挨喷的话:大多数技术同学,如果没有或多或少介入一个项目的管理工作,都缺乏从项目整体视角看待问题的能力。

很多技术同学都会有类似这样的想法:

  • 我的框架很牛,在某个知名游戏上有过成功验证,我们新项目就要用这个框架
  • Unity的坑很多,我们项目除了它的渲染模块,其他都自己写
  • 第三方插件要么不给源码,要么不想看别人的代码,还是自己造轮子比较放心
  • ……
  • 这些想法,从纯技术的角度来看,都没问题。但是从项目的角度看,却忽略了很多重要的东西:

  • 有多少个项目有那么多预算和时间够折腾这些?
  • 一个经过验证的框架是否适用于其他类型的项目?如果需要改造,能撑到项目被砍吗?
  • 自己造轮子爽是爽,其他岗位的同学是否有这个能力和准备来配合技术的方案?沟通成本有多高?技术方案的友好是否等同于美术/策划友好?
  • 如何确保自己的方案的坑比现成方案的坑少?上线测试数据不好,是玩法/美术/数值不行,还是因为某些莫名其妙的技术原因?现成的方案好歹经过很多项目的验证,有什么问题大家基本都知道。自己写的方案呢,如果自己查不出来问题,怎么办,反正不是技术的锅?
  • ……
  • 为什么会产生这种现象?

    1. 相对于其他岗位,技术的求职和发展是最不依赖项目成功经验的

    很好理解,技术的求职和发展方向大多是围绕技术本身,和参与过哪些成功项目的关系相对其他岗位来说较小。一个项目可能对于其他岗位来说意义是「在我简历上添加多少含金量」,而对于技术更多的则是「让我学到了什么」。所以,技术本能的会讨厌不造轮子搭积木的方案,毕竟这样基本学不到任何东西,完全只是个工具人。项目黄了?无所谓,我学到了新技术,这项目就当练手了。

    2. 目前的技术同学,太把自己当个技术,而不是游戏人

    作为一个游戏人,相对纯技术会有一些不同:

  • 优先考虑功能是否更好玩/能拉营收/活跃,而不是容不容易实现
  • 在项目验证阶段,关注如何快速出demo
  • 方案在技术友好的同时还能做到策划/美术友好
  • 一些「理所应当」的功能(比如全局按钮点击音效),不用等其他人验证,自己顺手就能做好
  • ……
  • 3. 技术在项目中的话语权过重

    但凡challenge技术的人资历不够/态度不够强硬/不怎么懂技术,满足上面两个条件,这件事无论对项目有多好,都无法正常推进。技术岗位先天的壁垒导致很多非技术岗的人在和技术岗的人沟通时会畏畏缩缩,来一句「你行你上」就能把天聊死。

    值得庆幸的是,现在很多新入行的年轻人都多多少少懂一点技术了,甚至有些人在大学期间就一人或一个小团队完成一个独立项目。真遇到技术说「你行你上」的时候,说不定真和张小龙一样,默默回到工位,过会丢给你一段代码,来一句「你看这样行不行」打你脸。

    知乎是一个幸存者偏差相当严重的地方,很多技术大佬在这里指点江山激扬文字,他们可能接触的项目都是公司的拳头产品,动辄两三年的研发周期上千万的预算几百人的团队,考虑的不是项目会不会夭折而是上线后的稳定性。

    但是这样的项目能有几个?更多的是挣扎在资金、时间漩涡中的小公司小团队和能力不够全面的独立开发者们。大佬们的回答都没错,但是看回答的你们好好想想,自己配吗?