游空工作室

      现在游戏里流行的脚本有python 和lua ，例如魔兽世界就是用lua脚本来驱动逻辑的。我们为什么用脚本，而不是纯用C++呢？当然，这与团队协作以及工作效率有关。      C++编译速度不佳，当一个项目达到比较庞大的一个规模时，编译的时间往往会让人愤怒了。      于是，python出现了。一些重要的算法实现，图形效果可以在引擎里实现，而一些纯逻辑的算法，则可以在脚本实现。于是便有了客户端引擎和客户端逻辑之分，还有的是客户端UI等等。     另外一个重要的原因是一款游戏的制作时间往往是以

最近负责一款2D客户端场景编辑器的开发工作，获益良多。现在就操作层面跟大家分享一下开发中的几个着重点。        1 事件响应模块：         编辑器的操作极其复杂，如果没有一个清晰的事件分发流程，操作逻辑处理起来苦不堪言。         主要的思路是设定编辑模式，然后在每个编辑模式下再有多个子模式。例如建筑编辑模式，放置建筑子模式等。         每个子模式下都有

最近对外发布了一个游戏更新包，因为是大版本，有问题在所难免。于是，很快就要打一个紧急补丁包出去。           这是之前我开发的一个工具，只对要修改的文件处理，高效快捷。只需更新一个文件，于是叫相关同事在内部RTX上发过来，           接着，更新包打好测试

昨天有同事在讨论群发了一个脚本异常，我一看便知道和我协作的另外一同事的函数写少了一个参数，可能我花几秒钟就可以帮忙改完提交了，但为了尊重 ta 的工作，便在讨论群上回复怎样修改。        但久久不见同事在群里回复，便主动走过去告诉 ta , ta 听了连忙翻群里的聊天记

      其实你自己的真实能力并不重要，重要的是你在别人面前表现出来并被认可的能力。      你在别人眼里的能力才是对你最重要的。      给自己多一份自信。      换一句说，要自信，但不能自大。

<br />       今天因工作需求要用到一个图形库，偏偏这个库却几乎没有中文资料，郁闷之至，大叹自己的英文之穷困潦倒。<br />       一直觉得英文对我们来说不是那么重要，最近越来越感觉到，是应该要恶补恶补了。偶尔写个变量的命名都要查在线翻译，说出来真的贻笑大方。<br />      回头望去，好像自己的英语在高考后就开始退化，直到大三急了下狠心花了一个月恶补过了四级，之后就继续退化了。现在对英语只是有点依稀的感觉了。<br />      嗯，有空看看英语吧。

<br />      我想说的是在工作上的放心。<br />      最近游戏版本有大版本更新，连续几天有相关的更新测试操作，我是负责这一块的，神经一直蹦得紧紧的，晚上睡觉也不敢关手机了，怕有事情要自己去解决。<br />      后来逐渐明朗了。一想到有人可能会咨询自己的相关工作，则提前向相关的同事说明白，而不是等那同事遇到疑惑的再来问，这就往往处于被动境地。<br />      把事情说明白了，则心里就像放了块定心石，安安稳稳的。<br />      这应该属于工作的主动性范畴，有事情自己主动

      前一阵子专负责游戏工具那块时，感觉有点闲，于是便主动要了一些游戏客户端逻辑系统来做做，现在却忙得走不开了。      怎样去评价游戏客户端逻辑这一块呢？说难吧，一看下去好像没啥技术难点，说易吧，三天两头也完成不了，而且这还不是机械性的工作。      游戏客户端逻辑是游戏服务器和UI控件的交互层，主要是组织服务器传输过来的数据，显示在特定的UI控件上。现在客户端逻辑几乎都是在用脚本来处理，为其便利性和易改性。      所谓逻辑，有点像脑海里的思维。做游戏逻辑思维想不活跃都不行。数据就像一条河，

<br />      今天调试一个游戏逻辑系统时发现前两天做的一些功能失效了，诧异不已。后来查了N久，才发现，被同事改了一段代码。而这段代码是在他的模块响应我这边的模块接口。也许是出于好心，也许是为了规划其模块的代码，终究是改了。<br />      我觉得，在处理非自己写的代码上，无论代码好坏，首先要做的是和原代码编写者交流，这样才能弄清代码的来龙去脉，而不是单看表面就轻易下结论。

<br />      今天部门群里发了一则各同事的一周代码量统计，引起一些同事的异议。<br />      其实对于这类事情，往往会一笑而过。大家能力怎样，平时有目共睹，各自的技术水平大家心里都有数。诸如代码量之类的只有增添笑料罢了。<br />      怎样去衡量一个程序员的能力，那只能见仁见智了。我觉得，由每个同事分别评价是一个不错的方式。

      最近开始搞那新版本的游戏启动界面，其中工作量最大的是用树形控件管理服务器列表。之前没接触过，嗯，动力来了。      很快，就掌握了需要用到的制作功能及其操作技巧。      总喜欢去接触之前尚未涉及的东西，也许这就是研究的魅力罢了。对于自己所不熟悉的领域，工作的动力往往倍增。      学海无涯。茫茫的书海，我们往往只能猎其一粟。但，我们要把有限的时间，投入到无穷的学习之中去。

<br />      游戏下个大版本的其中一个内容是对一个系统进行操作简化：几个界面的操作整合在一个界面，操作步骤简化等。我是负责该系统的逻辑流程代码编写。原以为只是UI那边的大改，但回看逻辑模块的旧代码时，发现和UI交互部分过度耦合，独立性过低，很多地方UI那边改了逻辑这边也跟着改。UI的界面整合，导致逻辑也要大改，叫苦不迭。<br />      由此，一个深刻的教训：不要过度依赖自己控制之外的东西。<br />      例如：在引用外部的模块或接口时，如果用到的地方超过两处，则在自己模块编写一个接

      先给定义：新手，刚毕业或临近毕业无工作经验的大学生。熟手，有一两年相关工作经验的程序。      有些公司很喜欢招聘一些新手进公司，即使在与招熟手的代价相差不大的情况下。很大的一个原因在于新手的可塑性及其服从性。      在IT行业，加班是很普遍的，而对于新手来说，尚在学习过程，在加班的过程中可以提高自己的技术以及相关工作能力，对加班的制度不会有太大的抵触。这就给其他的同事起到带头模范作用。作为一个熟手，当你看到其他同事也在加班的情况下，即使心又不愿，也只能听而从之了。      对于这种现象

      今天技术总监在开例会时提到一个测试成本的问题：产品问题被发现的阶段越往后，由此带来的测试成本则是成百成千倍地增加。      先说一下我们现在的游戏测试流程：个人制作--个人简单测试--和同事联调--策划检测--QC测试--测评试玩(内部测试)--开放外网。      在个人测试时发现问题只影响制作者自己，而越往后，影响的人群则是往指数级递增了，由此带来的测试时间耗费则是灾难性的了。      随后技术总监提出了一个要求：在个人测试阶段加入单元测试。即是确保自己的模块在联调时不会出现一些低级的错

      今天听到一同事刚接手一个旧的系统后，就说之前的代码太烂、要重构之类的，不觉哑然失笑。单单粗略的看了看就下结论，这是很不明智的做法。有可能这个系统某些功能确实要这样特殊处理，而不能按正规的设计来编码，也有可能是只有这样设计才是最合适的。      常常听到同事说要对别人的旧代码重构，也许程序员都有排外的思想，看到不是按自己思路走的代码一律看不顺眼，也许等改完后才觉得之前的旧代码才是最合适的，那时才是有苦难言。更有甚者，把就代码改几句就说重构了代码，这就纯属是骗人眼球的了，他会觉得”重构“这词儿怎样

本人不才，姑且以自身资历来分析，如何拥有属于自己的公司。       小弟今年二十有七，虽无八斗之才，尚有浅薄学识。工作四年，仍大事未成。故在将近而立之际，来规划未来数年的路，该如何去铺满。       自工作至今，一直从事游戏研发行业，担当游戏开发工程师一职。说白了,就是写代码的。活到老，学到老，这句话确切应用到程序员身上。学的东西越多，越觉得自己掌握的技术越少。写程序是个入门易，深