我：？？？

我就只会点c和java的皮毛，我这样的菜逼拿命去写3d游戏啊？

但当时的我完全没考虑到这其中的困难程度，漫不经心地就将任务领了下来。而且期间我还经历了许多杂七杂八的事情，这项工程基本还没怎么起步。

不过这并不代表我真的什么都没做。自大地领了任务之后就因为太难了而不去动手尝试，我可不是那么烂的人。

按道理来说，要想做3d游戏正常的思路和办法就是用现成的游戏引擎来做，u3d啦，虚幻之类的。但是考虑到u3d要用c来写，unreal引擎要用cpp来写，c我不太熟悉，只是听说语法和java很像，但java我掌握的也不是特别多，而cpp就更不用考虑了。我这种垃圾用u3d或者unreal来做游戏，基本不太现实，毕竟基本功都没掌握。

但是，也并非全无办法。

有一项技术，不用考虑线程问题，又比较灵活，也能做3d的东西，跟java、c、cpp这些重型语言比起来又相对容易一点点。那就是基于opengles规范的webgl技术。这是一门以web前端技术为基础，以h5的canvas画板为核心进行3d绘制的技术，如果是用它的话，独立进行3d开发会相对轻松很多。

刚巧，米奇部长以前跟我科普xss注入式攻击时，教过我一点javascript，我发现这门解释型语言由于弱类型，动态性强，书写起来极为清爽。跟c语言那种繁锁的书写方式比起来，js简直是跟小萝莉一样诱人可爱。而且因为是单线程语言，不用太考虑线程分配——当时的我觉得这门语言实在太香了，就有意识地自己多学了一点。

我自己也没想到，这个几乎是全然当成兴趣而学的技术，居然能在这时候派上用场。

我在学这部分的时候就在想，既然canvas画板能高效地调用gpu的图形渲染，可以避免极耗性能的do作，在canvas中画的东西并不会多生成do素……那如果，如果有一套十分高明的算法的话，canvas是不是也能绘制3d？随后在我尝试开发模拟rac大赛游戏的时候，就猛然回想起当初的想法，于是上网搜索了一下，发现果然有几个为了实现浏览器上的3d效果而衍生出的js库。随后我就开始边学边做游戏。模型我是直接去免费网站上下载的坦克和飞碟的obj模型，现在我已经大体把游戏的样子做好了。

但也仅仅只是“样子”——看起来像那么回事罢了。

最最关键的内部逻辑还没有太多做处理，我甚至连物理环境都没来得及模拟，光是碰撞检测就卡了我好几个星期。

我可以这样说，保守地来讲，如果刨除文字冒险游戏的话，百分之九十以上的游戏，都避不开碰撞检测。毫不夸张地说，我觉得这个比例有可能直接拉到百分之九十九。所以碰撞检测自然有相应成熟的算法……但是很遗憾，网上能提供的算法基本都是其他语言的。webgl是门新技术，有关这门技术的文章并不多。

网上的碰撞检测代码不可能直接复制，我可以去理解他们的思路，回过头来用webgl的方式去实现。

问题就出在这里，我自己始终搞不懂，为什么捋思路时捋得好好的，一到应用就会出bug。

好吧，追根究底，还是我自己太菜。

不过从另一方面来讲，正如我之前说的，这门技术就像一个清新可人的小萝莉。也只能是个小萝莉。

它有它的极限。

最致命的一点便是性能。

webgl是基于前端技术的，而前端技术，是建立在浏览器上的。换句话说，不管你游戏写得再怎么漂亮，也必然要运行在浏览器上，那就会造成两方面的问题。第一，浏览器自身就会占用一部分系统性能，第二，js代码无法直接调用底层接口，无法最大限度地发挥电脑的性能。何况它还是单线程语言，性能定然比不上c、cpp。

我现在是一边写着碰撞检测的代码，一边担心游戏写到后期会因为代码量过大、需要实时渲染的东西过多，而导致浏览器卡死。因为毕竟我自己也在摸索这门技术，从前我并没有写过成品，不清楚它的极限在哪里，自然避免不了盲人摸象。

这也就是我想找米奇给我指点指点的原因。

赵湘怡见我视线飘忽不定，似乎也明白了我的难处，轻笑一声：“天灯，我也没说你做不出来就把你怎么样哦？你只要尽力就好了。”

“但是……”我有点羞愧，“rac大赛的事情几乎都是米奇部长一个人做的，如果我连这点小忙都帮不上……”

“嗯？”米奇眨了眨眼睛，推了一下眼镜，“虽然不知道赵老师给你安排了什么任务……但rac这事儿本来就是我自作主张地提出来的。即便没有帮手我也会自己做下去。如果你们能帮到我，哪怕你们能提供的帮助对我来说很小很小，我也会很感激的哦。天灯，不必有太大的心理压力。”

“米奇说的你也听到了。另外，你不觉得你在挑战一个极为困难的项目的过程中，你自身的能力已经得到了飞速的提升吗？”赵湘怡笑着轻轻弹了我的脑门一下，“即使做不出来我也不会批评你的哦。作为老师，关注的不应该是学生的成果，而是成长。你只要尽你最大的努力去尝试，这就足够了。”