@forcecharlie 此话怎讲？一般情况下，某个 Compilation Unit (.c/cpp) 所 include 的 header 应该算是其依赖吧，那么这些 header 中再次引入的其他 header 算不算呢？如果先改动了 header 再改动 cpp（这样 cpp 的时间戳是最新的），是否会触发编译呢？

@twor2 对于我来说，VSCode 是我在非 Windows 平台下编辑 TypeScript 和 C# 的好工具。

其自身我认为足够易用。需要注意的是 VSCode 截止到现在，官方都没有提供扩展的手段（貌似连换个配色都不行）。这实际上也断了折腾的念想。另一方面由于某些特殊原因，我需要给那些只知道 VS 甚至 VC 的小白提供一款轻量、现代的支持 TypeScript 的工具，这个时间点上 VSCode 正好不请自来。

至于 node，我直观上觉得 Atom 玩儿转的话其实没什么必要使用 VSCode。至于 Windows，我并没有在 Windows 上使用过 VSCode，VSCode 在功能性上没法和 VS 比，本体又是基于 Web 技术，效率其实并没有多高，但是 VS 也很重量，我不知道该怎么评价。

我个人倾向于@mljack 的观点。我最近恰好被这个问题坑得很惨（因为库和客户程序都是 Xcode 下类似的配置编译，所以并没有对齐问题，但是细节上有出入）。

我并不是非常熟悉调试的那一套理论（尤其是 VS 下面调试），我认为楼主可以尝试探索周围的成员变量地址，看看到哪里的时候两边的 offset 是一致的。

从截图中可以注意到：

`(*((qte.exe!cocos2d::Scene*)(&(*((qte.exe!MainGameScene*)(scene))))))._navMesh`，使用的应该是客户程序的偏移量。

`&(scene)->_navMesh` 貌似使用的是 dll 里的偏移量。这个调试信息有没有保存我并不清楚，是不是跟图中现在貌似正处于 dll 中代码的 context 下也不清楚。

@billwang 那，国外的情况呢？

另外我想问一下楼主 Chromium 的代码看着怎样？

我自从玩过 V8 发现文档蛋疼的一比代码也比较乱之后从此对 Google 的开源由粉转黑。

@loading 某种程度上确实有必要，我前段时间一直断断续续在做一个工程，把 Apple 的 WebKit 版本库的某一版本快照撸下来然后自己做 client，用途是到游戏里面做 UI。

Apple 这个 WebCore 编译完之后有 50M（参见 OS X 中的 framework 大小），这个大小能顶两个游戏引擎了。并且源码中 GTK、EFL、iOS 等 port 对我来说并没有什么卵用，我希望尽可能去除或替换其中 platform-specific 的东西，并且收回其线程和事件循环的控制权。并且我也并不需要其中的一些冗余和实验性功能，但是却要保留 SVG、CSS3 等必要功能。

大小倒不是最主要的，其实对我来说与其想办法精简 WebKit，不如在 asset 的压缩上面多下功夫，但是它现在看上去真的不像是一个“轻量”“可嵌入”的东西。EA 之前做过类似的事情，但是有平台限制，并且是已经是好几年前的版本了，WebKit 一直在做重构，EA 的代码放到现在大概只有参考价值了。

@erichuang1994 我这开百度云，贴吧，新浪微博和若干国内网站速度都蛋疼的一比。

平常 Outlook，GitHub，V2EX，Google 搜索之类的倒是挺爽快。

@erichuang1994 在 VPS 上直接下载，CloudFlare 拉回来，收工。

@lilydjwg 我每次寒假回去插电写代码晚上断电看电影没感觉啊

也许是本来就是北方人习惯了吧... 我同学去北京回来的感受：被电惨了

@bramblex 看你在哪里工作。

如果是纯 tty 或者 ssh，multiplexer 是神器。
如果是 CLI 和 GUI 结合，那么 multiplexer 的作用可能并没有那么大。

另外 tmux 也可以分屏。

@neoblackcap Dart 这个东西据说本来就不适合“编译到 JavaScript”这种用法。

实际上当涉及到类似 JavaScript 的东西的时候，我也是选择 TypeScript。

@smithtel 他们都没某党精，这种事情天朝上能给我们争取最大利益，说不定还能小坑他们一把。

@xionghengheng 尝试撸过，坑了。

具体情况要具体分析。

比如“是不是比参加高考 然后考上一个重本学校更难” 这个得看你在什么地方，上的什么高中hhh

有人说要做游戏引擎，你得先去做游戏。有点道理，因为绝大多数游戏引擎，就是把某类游戏中最常见的东西造成轮子给你用，这一点类似“设计模式”，不去看设计模式的实例，没有在实际中用过设计模式，是很难说理解了设计模式的。

而且游戏引擎同样也是十分工程化的东西，完整的游戏引擎涉及到十分广泛的知识面和巨大的工作量（刚看了一堆UE4半懂不懂头疼死了...），大概就是说为什么“难”

现在有些人一说游戏引擎就是用了什么什么技术，有什么什么硬件滋瓷，渲染上面多么多么吊，造成这个现象背后因素比较复杂，但是游戏引擎所包含的绝不止图形一个部分，在我这 Rendering 仅仅是一般情况下的必要条件之一而已（“一般情况”的对立面如文字冒险游戏）。比如如果就是图个好玩，那么拉个 SFML 过来搞渲染照样能行。
多提两句，SFML 这个东西声称跨平台，跨语言，虽然我仅仅在 Win/Mac 下用 C++ 玩过，但是不得不说确实符合其 “Simple” 的名字。有一些硬伤（有时是不可忽视不可忍受的），但是拿它做最基本的图形轮子算是够了。
另一种观点就比较“互联网”，大概是随着手游和页游的兴起而出现的，就是说游戏引擎要获得市场，就得易用、还要跨各种电脑手机 Web 甚至 Console 平台，然后整一个编辑器傻子都能做游戏，当然产品基本也就一般打飞机游戏的格局，这种游戏拼创意，拼营销。但是终究会被某些单机党和主机党鄙视。
这是两个极端。

说白了不过是不同人口味不同，追求不同，目标市场也不同。
而如果自己要搞的话，道理也是差不多，你的游戏引擎（假设真的要自己撸一个出来的话）定位是什么样子的游戏？各方面的要求大概是怎样的？场景是 2D 还是 3D 的？要不要物理？如果有的话，那是 2D 还是 3D 的？目标平台是什么？场景大概多大？扩展性要求多高？AI 要做哪些内容？

我觉得首要解决的还是这些需求问题。至于剩下的技术，要在特定的方面啃个半吊子，还是很容易的。

只会用别人的物理引擎然后每次都被坑惨的渣渣路过...

Polymer 感觉确实有坑... 特别是推开官方组件库从头重做的...

@meteor2013 我不是做 iOS/Mac 的，所以不知道，不好意思。

表示很反感一说“游戏引擎”上来就说“图形引擎”的。

@lyf 据说 Rust 现在已经比较稳定了？