看看v站，这么多二次元。

想成Acfun和Bilibili的举手。。。

show me your code.

@blue7wings 肯定是啦。

@zhonghua 可以啊 联系方式到我邮箱吧， sleepers.tang#gmail.com

很容易返工。
当然那种抄袭的游戏除外。

游戏比较特殊，很多地方需要和美术配合的，如果不事先商量好。

@williamx 我的技能栈应该和你差不多。刚看了你的github。

@laoyuan 你这也太 egg pain 了。竟然直播写代码。。。。

你需要的是磨练自己的心智，现在的我已经修炼到对满屏指纹视而不见的境界了。
+2^10

@cxshun 我用标准指法甚至都不能盲打。

打了10年的星际争霸，也用了超过半年的vim，甚至还花了1个月去学ggtt，现在日常办公也是HHKB。然而并没什么卵用，二指禅就是二指禅 T_T，改变不了。

标准指法真的要酷很多，至少每次看同事打字都这样的。
已经二指禅了15年了，基本上是改不过来了。
以上由搜狗拼音输入法输入，总共的输入时间是55秒。

@itommy - -#，这么多。。

同情web前端程序员，竟然要了解这么多框架- -#。

从"没有进入主线"这一点来讲，先做支线任务打怪练级，到时候主线轻松秒杀BOSS不是更好么。

gamedev

@cho
的确是个问题。对整个游戏产品的外包，国内能做的公司并不多。整个游戏外包行业并不成熟，这也和国内游戏产品互相抄袭可能有一定关系。本人目前在手游行业，就说下手游行业如果要外包，需要哪些工作吧。

先说游戏策划吧，关键在于需求表达清楚（这不是废话吗）。根据游戏类型，游戏策划的文档基本可以套模版写。问题在于就算有模版，也很难只用文字去表达清楚需求，不会写代码的美术不是好策划，要图文并茂才行。说了那么多，其实没什么用。国内游戏基本就是，原创一点点核心玩法，其他成长点抄一套过来，没节操的甚至数值也直接抄，再没节操一点直接反编译，我这里并没有在含沙射影的在说HC。这种前提下，不会有太多创新，所以需求还是明确的（外包给一个团队，抄一个XXX这种多数吧）。先声明并不是说策划没用，no offence，准确的说是国内游戏，对游戏系统策划的要求并不是那么高。扯远了扯远了，说外包，说文档。以前做过索尼的对日外包，文档基本上都是程序员写的，细到astah制作流程图，时序图，类图都有。国内策划虽然有计算机专业出身的，但是并不能写的一手好文档（拿来就能直接写代码的那种文档）。并不是说要求策划文档写到如此专业的程度，但是至少游戏内出现过的“所有名词”都统一这种基本要求，很多策划并不能做到（今天这个东西叫coin，明天叫 gem，后天叫 gold，这种文档你能看懂？今天叫spell，明天叫skill，后天叫skull，当然这是瞎扯）
结论：能有一个原型最好，没有原型文档必须要标准化。

再说美术，可以说美术是游戏开发里面“最稳定”的因素了。除了UI（一会儿单独说），因为一旦游戏风格定了，人设定了。根据质量的要求，原画动作的价格市场上都比较稳定，所以美术外包并不难。

先科普下，一般认为，如果制作人员按照游戏的内容来分类，一部分是做的核心玩法（战斗系统，一般这个系统由主程来写，由于现在大部分手游是短链接，这个功能基本没后端什么事儿，也是比较好外包的部分。所以只要核心玩法定了，这个系统基本不会怎么去改，也不敢去改。PS：个人认为做一个手游最有趣的部分也在这里）。还有一部分就是各种成长点（升级装备，强化装备，培养培养宠物等等，一般工作1年经验的程序员就能胜任了）。 前面也说了，因为策划在产品初期，并不能想好所有的成长点，经常出现这种情况：“国产游戏的一般节奏，XXX游戏上线啦，标杆级产品，有1，2，3，4这些成长点，看起来都能在我现在的游戏里用呢，一拍脑门，程序，美术开会啦，我们0.8版本加1，2，3，4这些功能”。
所以经常出现，“界面推倒了重做，UI风格各种换的尴尬局面。” 而且根据开发的情况，经常会有 UI 各种变的情况。所以并不适合外包 UI（成长点部分的功能。）
结论：除了游戏核心玩法，游戏成长点这里是变化最多的部分，非常不适合外包。

最后来说程序部分。
先说游戏的后端吧，本人在公司里的职位主要是客户端，不过后端也能做一点，讲的不对的地方轻喷。还是先科普，因为网络的原因，端游的长连接并不适合手游，所以大多数手游的服务端基本是一个webapp。技术方案大多是 NGINX + php, OpenResty, apache + php, 数据部分redis/memcached + MySQL，再加一个长连接的聊天服务器，这个选择就更多了，有三方的解决方案，也有自己做的，比如直接用pomelo(Node.js)什么的。服务端做的大多数事情是验证客户端传过来的运算结果和玩家存档。除开三方支付，登陆，聊天这些通用功能。服务端其他的业务逻辑相关的代码，基本都是成长点相关，所以也是属于“需求不稳定”的那一部分。另外根据运营策略（国内一般滚服，海外一般一个大服务器），经常需要做活动，这些外包起来也非常麻烦。
结论：游戏服务端并不适合外包。

再说客户端吧，这个更复杂一点。也是先科普下吧，和做web前端差不多，手游客户端也非常复杂，总结起来就是：1. 开发环境和运行环境很多种（对应web前端就是各种framework和各种浏览器） 2. 开发语言非常多（主流Lua，C++，C#((主要是U3D))，Javascript((算半个主流吧，毕竟H5)) ）3. 再者兼容性和性能，iOS相对简单一点，主要是Android设备类型太多了，各种系统对OpenGL的标准兼容不一样，另外Android设备虽然配置高，但是app运行时的“可用内存”非常不稳定，然而游戏不像一般的app，又对内存（最少还是需要200M+的内存）和性能（至少30fps）非常敏感。所以 “游戏引擎的选择就至关重要！”。市面上主流跨平台U3D, cocos2d-x。还有市场占有并没那么大的libgdx， corona（这个严格说是做app的，做游戏性能并不特别好，简单的游戏可以用）。

好像又扯远了，我为什么要说又呢。说下客户端外包。
先说U3D吧，以U3D为核心开发的游戏，工作流更适合外包。因为U3D制作精良的跨平台编辑器，稍有经验的策划就能做出一个差不多的原型，以此为基础给程序开发，更快的反馈问题和修改，另外U3D的UI部分很稳定，基本都用的NGUI（不像cocos2d-x一个引擎竟然有3套UI框架）？所以对于标准化相对较容易。不足之处在于包稍微偏大（如果是做海外平台，这都不是事儿）。
再说cocos2d-x。cocos2d-x引擎的渲染部分还是很优秀的，除了粒子系统性能糟糕一点，核心渲染系统问题不大。因为借着手游的东风，cocos的发展很快，可能确实是因为太快了，周边工具非常不完善。2D 项目基本还是首选了，因为会的人多，招人方便。然而维护成本并不低，好像又扯远了，继续说外包。个人建议cocos2d-x项目客户端外包最好整包。因为本身引擎是类为单位构建的，并不能以插件的形式改引擎，然而大多数项目有自定义引擎的需求，所以最多引擎和产品不分开，一起改。
结论：游戏的程序外包的确很难，因为是长期维护的事情，并不是一锤子买卖，所以除非是外包对象签订合同的长期合作，不然还是别外包了。

这其实是一篇软文，你们都没看出来吧，233333。
以下是此软文硬广告：
--------------------------------------------------
我们的游戏，www.armorblade.com
现在需要一位有海外经验的运营 ：）。
联系方式：tangyy#armorblade`dot`com

30岁都不老。