不再接受任何相关讨论, 亦不接受人身攻击, 谢谢.

@jindian 哪家公司? 开发啥游戏的? 单机还是联网? 手机还是 PC? 怎么说呢, 渲染和物理并不是最大的难点, 如果你愿意, 你完全可以将渲染和物理交给第三方库去做, 效果也会很漂亮. 如果你认为一款游戏的重点在于渲染和物理, 那么, 你应该重新审视一下, 什么是"游戏编程". 难道你觉得好游戏仅仅只是"画面好"吗? 游戏的根本难题在于系统设计以及逻辑设计. 加载资源是否是由单独的线程在做? 如果是的话, 线程有没有 coroutine 化? 有没有将重要数据做进程独立? 自己设计信号通道了吗, 是原子交换(自旋锁)还是互斥量? 你口中所说的"自实现的 STL 库"以及"成熟的服务器架构", 对于很多公司而言, 完全就是一团糟! 只要你写的代码里还有"using namespace std", 那它就不是 STL 安全的. 另外, 很多公司的网络通信模块令人堪忧......

@outfocontrol 我不清楚你们的渲染和物理碰撞是怎么做的, 我看到的方案里, 重新封装第三方库或者 SDK 是比较常见的. 第三方库和 sdk 已经做了很多事情, 但也还有很多事情是要做的, 这些或许是你所认为的"难点". 也有一些人是完全自己设计的物理碰撞和渲染的数学模型(Minecraft?! 我不知道), 例如, 在渲染火焰时, 粘性粒子模型和非粘性粒子模型, 在计算量和表现形式上都有很大的差别, 另一个例子是, 飘动的旗面, 考虑材料的韧性而使用面块模型, 又或者是简单地使用粘性粒子模型, 区别也相当大. 或许你会说, "sdk 已经提供了这样的能力", 有或者是, "这并不在我的考虑范围之内", 那我也可以这样说道: 你并没有真正体会到渲染和碰撞建模的艰难过程, 亦没有理解到, 多数的 SDK/第三方库 /游戏引擎的表现始终不会如你所愿, 因为它们不是根据你的需求而定制的. 仅仅是组合现有的方案, 而不是发明新的方案, 这一点也不难, 只是很麻烦而已. 这是令人失望的, 因此, 我不喜欢游戏行业, 他们总是在用十分古老的技术, 并且依靠重复的人力劳动和计算机硬件性能的提升, 来"创造"出一些一点也没有用的技术.

我不想再讨论关于物理碰撞和渲染之类的话题, 也不想再讨论编写游戏有多少技术含量. 一款游戏始终应该将其设计, 玩法, 娱乐性作为卖点. 至于技术, 游戏行业永远不会诞生出优秀的技术, 游戏行业从来没有开源过一套能在非游戏程序以外使用的代码, 或者说, 甚至从来没有开源出一套通用的程序代码. 大家都知道现代游戏设计离不开 GC, 也离不开信号通道以及多线程优化. 但我们知道, 最优秀的 GC 实际上来自于服务器领域, 最优秀的信号通道来自于操作系统领域, 而多线程优化则来自于网络领域. 甚至, 在游戏中广泛使用的 coroutine 亦是来自于脚本语言.

如果哪一天, 有一套来自于游戏行业的开源代码广受欢迎, 我定会承认: 游戏行业促使了计算机科学的进步和发展; 不然, 我则要说, 游戏行业并不是高智力密集型的, 相反, 它是劳动力密集型的.

没啥用, 我的服务器目前还没出现过内存不够用的情况.

另外你这东西弄得太复杂了, 纯 C 语言实现的或许还会有人试试.

@choury 什么行业?

@kingddc314 哪家公司? 有些所谓的"大牛"代码质量也很差...老师的代码质量怎样, 学生的代码质量也就怎样......应届毕业生工作以后, 一开始接触的几个框架会极大地影响他的代码风格, 某些公司的框架写得烂, 就导致用这些框架的应届毕业生会写很长时间的烂代码...

@jindian @outfocontrol @boyhailong 编写"游戏"和编写"游戏引擎"是两码事......编写游戏的人水平真是不咋地, 大量时间都在 1.弄清楚引擎的文档 2.检测并填上引擎的坑 3.研究自己想要的功能咋实现 这些事情上......所以基本没啥地方需要动脑袋, 能弄清楚引擎就不错了......另外, 3D 渲染 /物理碰撞之类的事情都是显卡在做, 那是写显卡驱动的人编的, 和写游戏的程序员没啥关系......写游戏的程序员基本就是把几个框架给接上去......

当初你们谁想得到, wanda.com 能卖出天价?
一个域名值不值钱, 取决于有多少个整天打游戏的混娱乐圈的房地产富二代.

@kingddc314 多数写游戏的人水平都挺差的...写游戏是 C++里技术含量比较低的一个工种...

在编码的时候, 缩进可以被解释为特殊字符, 也可以被解释为空格, 这要看编辑器...
例如我惯用的 Visual Studio, 在编辑器内缩进会被解释为特殊字符, 复制的时候会被解释为空格...

那要看你是做什么的了. 银联的程序很多都是 C/C++的, 本身设计就比较复杂, 程序也比较重要, 一般来说都不能熬夜, C/C++熬夜会写出很多 BUG.

我觉得, 无论干啥, 写 C/C++都不能熬夜.

@cclishan 哪家公司? 我 11.11 去魔都看个展会...

@arnofeng @fusang @cclishan 怎么都没人加我 QQ...

@cclishan 在哪干活呢?

@Tony042 @cclishan @kylinj @fusang @arnofeng
CSU 的校友认识一下? 还在校内的话, 来不来喝杯咖啡?

以下两位也是校友. 透露个人信息啦! 不要打我!
@oott123 Surface Book 什么时候买?
@JustZht 恭喜获奖, UI 做得挺漂亮.

QQ: MjIyMDU0MTkxMwo= (base64 编码)

@arnofeng 翻了翻你的帖子...

噢, 果然是中南的研究生. 这标题看着就像......本科生里我不认识, 一猜就是研究生.

@fusang 只可能是中南或者湖大...

@tchekai704 在 C++中, 还可以通过抽象类与函数容器来实现跳转表(map), 这是对 if-else 的进一步优化, 因为可以在抽象类中方便地设置日志记录器, 或者 bug 记录器, 这是游戏编程中非常有用的技术. 非算法类的代码中不应该出现多层嵌套 if-else, 也不应该出现连续的 if-else 和 switch, 因为这会把逻辑弄得很复杂, 相反, 应该"分治", 将逻辑分离.

@tchekai704 例如, 一个 2D 游戏中的人物朝向(towards)可以被描述为一个集合{up, left, right, down}, 常见的处理手法为:

if(up == towards) {}
else if(left == towards) {}
else if(right == towards) {}
else if(down == towards) {}
else {}

如果用结构体来优化:

class towards_handle {
enum {up, left, right, down} towards;
void handle(void) { /* do something */ }
};

每个角色都拥有一个 towards_handle 对象, 它的 towards 值必然为{up, left, right, down}其中之一.

towards_handle th;
th.towards = 1; // 1 means up
th.handle();

这样的过程就比 if-else 漂亮许多, 并且可以用派生类来做相应的优化.