作者NDark (溺於黑暗)
看板Soft_Job
标题Re: [请益] 想写游戏的话该从哪里下手?
时间Thu Jan 10 00:51:02 2019
※ 引述《neo5277 (I am an agent of chaos)》之铭言：
: 我是从 .NET 起家的
: 之前一直都在写网站跟服务，前端就是angular 跟 传统jquery
: 感觉电商上的流程跟环境都小小的跑了一圈。
: 自己对於打造出一个可用的产品越来越有想要尝试的感觉。
: 多方研究下觉得游戏这块可以说是一个完全体。
: 不管是单机，还是网路营运，在技术上可以说是整合了目前所有我能想像的到的
: 软体技能，以及非软体能力，也因为是从.NET 大概会先从 UNITY开始吧。
先分清楚 你是哪一种
1.喜欢玩游戏
2.喜欢做游戏相关技术
3.喜欢开发游戏
4.希望有一个游戏产业的工作抬头
5.希望能有一个知名游戏的工作抬头
6.希望能在游戏产业讨饭吃
7.希望能在游戏产业站着还能把钱挣了
从问的其他问题看来我觉得 偏向2.
那麽这些问题多半都是电脑图学这门课可以回答.
所以其实去大学旁听就是正解.
以下是碎碎念
最近的体悟是 游戏软体是一个一不小心就很容易做出反智系统(Anti-Pattern)的专案.
以往所认定优秀的软体系统都是在需求稳定的情况下开发.
所以可测试性/可延展性/稳定性等等才随之而来.
在游戏软体传统开发的做法是:
做一个系统,让数值人员填表来扩展.(一行数值代表多一种怪物/多一种武器/多一种道具)
在这个系统开发之始,软体人员必定会问清楚,这个系统的极限(功能)在哪里?
炮弹是直射,雷射,抛物线,是撞击即伤害,还是爆炸後才伤害.
"可是" 系统完成後之後数值人员填表就"不会"超出这些类型范围
也就是说这个系统无法填表填出"让玩家觉得惊讶"的跳脱设计.
也就是说当系统完成或上线後的一个月後,
设计人员说要加"遥控飞机(Drone)"型的武器.
因为原先并没有开这个规格,所以就无法经由填表产生这样的功能.
软体人员抱怨归抱怨.
给出的答案就是下一版版更 把这个类型的武器
再"实作"(从某种程度看来就是 hard-coded) 到 游戏里面.
这件事情(超出原先设计规模)重复几次之後,code就会烂到不行.
因为原先在设计系统的时候没有想到要做成这样.
(同时也因为营运端需求来的通常是ASAP,最好不要更新就能做到.
玩家在论坛上的建议也真的都是最好我点餐完一个礼拜之内就有.
可是瑞凡,苹果审版本最短也都要两到三天)
每次当从这个时间点回头看每次开始做系统时候的规划,就会觉得当时年少太过天真.
所有的游戏引擎制作团队都会讲到一个反智的经验谈:
引擎/函式库 是结果不是原因.
多半都是在专案中先做出这个功能,
然後历经多个专案之後才把这个功能拆出来标准化,成为引擎工具.
衍生出来的一个悖论是:
有了引擎的帮忙,或是当引擎提供了某项功能,
代表成千上万的游戏可以快速实装这个功能,代表军备竞赛的标准又往上推了一层.
有了引擎事情不会变少,时程反而会因此变多,
因为工具加大了效率,要求或标准反而会再提高.导致目标更加远大.
共勉之
--
"May the Balance be with U"(愿平衡与你同在)
游戏设计教学，讨论，分享。欢迎来信。
黑水沟历史文库
https://ndark.wordpress.com/
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 176.205.16.49
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1547052669.A.916.html
1F：推 cheryl89531: 这不限於游戏软体吧，听起来制度差的公司都会发生 01/10 01:12
不是有没有制度.
而是这个到底赚钱重要还是程式码品质重要?
如果前者永远都压倒後者.那麽程式码会越来越歪几乎是100%会发生的事情.
很遗憾的 游戏产业是一种流行. 所以能赶快捞钱的就要赶快实作.
未上线产品 开发周期最好能压在一年之内就有一个产品.
上线产品 的开发周期就是一个月内二十天要连设计开发测试都做完.
2F：推 vn509942: 军备竞赛 01/10 01:16
3F：→ NDark: 玩家会因为惊喜这种情绪而付钱 而不会为了稳定而付钱． 01/10 03:08
4F：→ NDark: 而商用软体通常要稳定 不会求惊喜 01/10 03:09
5F：推 bakedgrass: 蛮不错的分享 01/10 03:39
6F：→ superpai: 这个问题让数值人员写code就解决啦 01/10 04:08
7F：→ neo5277: 这个用oop应该可以解决吧? 01/10 05:47
8F：推 neo5277: 抽象成武器，然後继续分下去就开枝散叶了 01/10 05:49
9F：→ neo5277: 感谢回覆，想做也喜欢玩 01/10 05:49
继承反倒容易产生 "一开始没想到" 的问题
(因为子类别需要的功能,父类别设计的时候并不一定都能想到)
不过继承出现的问题在 2007 年前後陆陆续续被解决.
现在游戏界都推Component-Base. 比较少人推荐用继承写功能了.
[翻译] Evolve Your Hierarchy
https://wp.me/pBAPd-fj
10F：推 ShadowInWind: 推军备竞赛 01/10 09:04
11F：→ stkoso: 现在玩家的胃口不是多几把武器就能满足的 01/10 09:48
12F：→ stkoso: 这种军备竞赛要求的是质变而不是量变 01/10 09:51
13F：→ stkoso: 跟OOP的概念正好背道而驰 01/10 09:51
14F：推 WorkForFree: 推推推 01/10 09:53
15F：→ pttworld: 把引擎的地位想像做web的开源框架就是了 01/10 10:41
16F：推 bakedgrass: 比方说剑三当年增加的轻功就得改写底层 01/10 12:48
17F：推 TAKADO: 所以现在很多3A大厂也开始用Tick-Tock策略，一个工作室专 01/10 14:28
18F：→ TAKADO: 门塞新技术/改引擎，另一个工作室次年沿用，然後改内容跟 01/10 14:28
19F：→ TAKADO: 精炼玩法出新作。例如刺客教条跟极限竞速就满明显的。 01/10 14:28
20F：推 askaleroux: 心有戚戚焉 做完一个系统企划才被雷打到 01/10 14:29
21F：→ NDark: @stkoso 深得我心 01/10 18:35
22F：→ NDark: @superpai 我们连tester 都改code 就知道这 code会变怎样。 01/10 18:37
修改一些写不好的地方.
※ 编辑: NDark (176.205.16.49), 01/10/2019 23:25:21
※ 编辑: NDark (176.205.16.49), 01/10/2019 23:26:08
23F：推 neo5277: 所以再加上interface这样 01/11 01:52
24F：推 SmallpTsai: 这篇值得 M 起来 01/11 14:47
25F：推 jasonwung: 推推 01/11 21:51
26F：推 TurnV: 推推 这篇内文精彩，推文更棒 01/19 12:16
27F：推 mistystream: 完全反应了真实的游戏开发经验 01/28 14:34