@imdong 我的说法只是写单元测试的思路 hint 而已，并不是单元测试的方法论……

当你不知道你写的这坨代码从什么角度写测试时，用我提到的方法来构造一些可递归拆解的 “单元”，拆到你自我感觉足够独立足够单元后，就好对它们进行测试了

实际上在写的时候，肯定要根据实际情况考虑正负分支、边界异常条件什么的。我是觉得到写 assert 的时候自然会多想到一些条件来 assert 的，不用说太细

想象一下 UI 编程。
把 click 看成一个 signal，http 模块把现在文本框的内容 post 出去作为 slot

显然在 button 的 onclick handler 里完全没必要实例化一个 http requester，从某个全局区获取一个 requester 再进行请求则更显怪异。优雅的做法当然是让 click 只作为一个信号灯，我们找一个第三者视角，看到灯亮的时候指使 http 模块发出请求。在第三者的上帝视角里能看到 button 的实例与 http 模块的实例，而 button 和 http 相互并不需要知道对方的实例存在。

这是 qt 框架最基本的事件响应机制。基本上有 signal 这个概念的框架设计理念都是类似的。

@www5070504 对于 #6 提到的场景，如果要做单元测试，那么思路是

1. 前提：确定 receiver 的正确性
2. 把 foo 产生的 value 喂给 receiver，在 receiver 上断言行为符合预期
3. 如果 1 不能确定，递归拆解问题

单测是用来保证设计与实现一致而不是用来保证逻辑正确的

比如设计上这个函数收到 A 应该返回 B，那单测就给它喂个 A 看能不能收到 B

“理论上这个函数应该只能收到 A” 于是 试图测试是不是真的只能收到 A 这种测试不在单元测试范畴内。

b 站搜 “独立+游戏”能搜出来一堆 up

独立游戏的技术栈也和游戏工业完全不一样不可一概而论。

如果你是想做自己的游戏，那技术栈基本上 = 引擎本身+美术技能

搞清楚模型怎么导，动画器怎么用，sprite 怎么划，脚本怎么写，引擎提供哪些 trigger 和 event，有哪些生产力插件，去哪找资源，然后就可以开始了。

独立游戏，个人观点是起码有 70% 的任务要落在美术上，所以在 v2 看到的 “开发游戏” 的帖子我其实都不太看好，尤其是点进去一看都说自己是写代码的。作为美术，one have to:

确定题材对应的美术风格：像素画？、水墨？、lowpoly ？、黑白阴影+光照（ limbo ）？、PBR ？、二次元（三渲二）？、gothic ？、美式卡通？
这以上的每种美术风格都需要不同专业的美术来完成，随便找一个不可能每样都擅长，就跟美术找一个写 php 的说要做游戏一样荒诞。然后你还需要能画概念图 /原画的人、能（如果 3D ）给模型画服饰造型的人、会（如果 2D ）拆背景板 / 拆 tile map / 拆 character 动画帧 / 拆建筑部件 的人、 画模型法线 /高度 /金属度贴图制作材质的人、会用 shader 实现特效或者指导画师如何将原画转成 asserts 的人（ Technical Artist 技美）

以上这些还都只是 独立游戏 必须的美术人，工业级游戏工作室就不在讨论范畴了





可能是我对美术一窍不通所以觉得美术简直是天堑，我连把几层背景板摆一起该摆成啥样子都无法具有概念，是彻底的美术白痴，所以一直不太敢动手。做游戏需要写的那点逻辑代码，寻路、AI 状态机、物理、碰撞、基础光照、p2p 通信，那全都有现成的插件也好组件也好模板也好囊括进引擎的生态圈里了，如果你是写代码的，那你只需要搞会引擎，别的插手不了。如果你是做美术的，那你基本上要做完除了考虑收益和把关卡搭出来逻辑模板套上去之外的一切事务。




哦其实写代码也没有那么不堪，毕竟 DOP 、用 shader 写批量通用计算这样的高级技术不是找个模板就能套的。但可能真没几个独立游戏能做到这程度





美术流程是独立游戏最核心的流程

主题无关。

我只是发现随手打出来的单词很有趣： https://baike.baidu.com/item/hunky/51902148

HDR 的图片格式不多，我也不清楚哪些 Image Viewer 支持渲染真 HDR 图片……但你能用浏览器打开的图片格式基本上色深都只有 8bit 是不可能有 hdr 效果的

起码试试 .hdr 和各种相机的自家 raw 在 ps 里打开才好说

外包群也能这么清新脱俗。。。这才能浪费了

用来开热点为啥非得是手机？

又看了一遍问题

其实完全可以将系统设计成无初始用户，无需硬编码超级用户的样子。但这样的系统初始化时就需要你用其它手段从外部往它的数据库里写一个新用户进去，也就恰恰说明了这个系统是不完备的——这个系统不能只通过系统自己完成所有功能，比如初始化，因此它不完备。

但这种完备性并不是这个系统的必要指标，完全能接受装机时通过另一个程序来生成初始状态，所以这个时候也的确并不需要 root

可以直接用分组来代替前后向断言，基于分组捕获下来的内容来做判断而不要直接用断言匹配全句，这样能最大程度保证兼容性

一句话噎死产品经理：
这个业务逻辑客户根本不会买账


一句话噎死研发：
这实现起来哪里难了来我教你

@xuanbg @exc

#59 说的跟我想表达的很像

但我存在另一个疑问（可能也是 lz 的疑问），为什么自指是必要的，或者什么样的系统是必须能自指的。不知道有没有相关解答

lz 很敏锐啊，一句话说到了一个盲点
个人的感觉，注意是感觉，我并没有很清楚地 get 到我想表达的逻辑线，是：

一个系统如果想完成自我指涉，那么自我指涉这个代词对象就是 root
类似 this-> operation
操作系统需要一个 get_self_user() -> operation

如果一个系统运行完全不需要自指，那自然不会需要 root 和类似的超级权限
但不需要自指的系统是否是完备的，我 get 不到那层逻辑

首先像 #6 说的先把默认构造 / 构造函数带有默认参数 / 编译器选择重载这三者区分开来

Class() 无参默认构造
Class(type param=1) 带有一个参数的构造函数，且这个函数有默认值

定义的时候，这是两个不同的构造函数，这应该不难理解



然后如果一个类同时存在这两个构造函数，当你写下 Class obj 时，编译器会寻找可以满足对象定义语义的构造函数，于是这两个函数都能被找到，于是会产生 ambiguous 。当你写 Class obj(1) 的时候，无参构造不能满足语义，只有第二个构造可以满足，因此无歧义

@ljlljl0 售前就是给客户做方案的。 又重复一次

售前就是给客户做方案的

销售不懂技术，研发没空接触客户，那你说谁来帮客户设计产品落地方案？ 2b 是不可能一套固定标准化流程啥都不用适配的