book_soniced的专栏

一个字：酷！ http://www.gametrailers.com/user-movie/far-cry-2-xbox-360-map-editor/255390

- 所有的图片类资源由一个类管理，包括精灵，动画。gameplay用id来索引资源（无指针，维护简单）- 游戏中的所有网络消息由一个类发送：sendLogin，sendLogout，sendSkill，sendChat。。。（facade，紧凑）- 游戏中的magic类实际上是所有magic的工厂（facade，结构紧凑）- 大量的public变量（自己养成习惯只去读不去写就好）- 大量使用固定长度的基本数组做容器（高效简单）- 极少使用继承、多态、接口（结构简单）- 网络包手动分发

<br />8:28 PM 12/20/2010<br /><br />避免过多与c++类型系统纠缠。。。<br />程序员都很忙，有很多代码要写。。。<br />同理，尽量少于类，继承，封装，多态，模板，宏，打交道。。。

<br />8:43 AM 7/21/2008<br />关于学习<br />    要学习某个优点，首先看看如果你具备这个优点你该怎么做，然后在思想上模拟着做一<br />    遍，以后也经常保持生活和思想上都去这样做，那么你就很容易的学会了它。因为不论<br />    在思想上模拟着做，还是在实际生活中去中，都是为了养成习惯。一旦习惯养成，它自<br />    然而然就成了你的优点了。<br /><br />    要学会幽默，不论在任何场合。因为我认为幽默是改善乏味的人际

<br />3/26/2010<br />对于Onyx这样高度灵活但不稳定的系统，你需要更小心的决定哪些东西需要灵活哪些不需要，否则会给让工程带来方<br />向性混乱。比如带来大量细小但不太需要灵活性的组件。这将带来难维护的问题。。<br /><br /><br />3/25/2010<br />- 在update中有一些工作，只需要做一次以后结果都不会变，那么可以放在初始化里面做<br />- 给游戏加个网络后台控制，还不如加个输入秘技来调试来的简单.但是，网络后台也有好处，他可以把

<br />//19:39 2007-8-21 錦天<br />  <br />  问题分解示意图：<br />  方案1：<br />  1<br />                  问题<br />                    |<br />            +———————+<br />            |              |<br />          子问题1      子问题2<br />               

<br />//2007-2-13<br /><br />  进度特别慢的FIGHTER07，今天先看了下DEMOSTAR2（网友的飞机），然后看了下水晶之约的代码，然后看了下SKYHUNTER，很有感触啊    。<br /><br />  我们现在做游戏，应该把重点放在实现效果上，使用的算法笨拙点无所谓。水晶之约用的算法很简陋，但是解决了很多问题，再看我的SKYHUNTER，稍微有点意思的就是那个脚本机，其他的代简直没意义，地图问题到最后也没有解决，脚本机用在飞机里面的设计一开始就有问题，可是还

<br />14:58 2008-4-25<br />代码级别的重用带来的便利并没有想象中的那么好.在大部分游戏工程里面,引擎作为一个大<br />的块被重用.<br /><br />16:30 2008-4-29<br />在编码之前,必须要完成:目录结构,命名规范,分工等.<br />有个可视化的版本,就算功能相当简单也可以帮助团队解决那种浮空的感觉.<br /><br />11:28 2008-5-22<br />尽早集成，就算只有空壳。头脑清醒，随时检查需求。<br />

<br />9:20 AM 7/15/2010<br />千军易得，一将难求<br /><br />与其分而治之，不如化繁为简(做事的方法)<br /><br />对症下药<br /><br />模式<br /><br />噪音<br /><br />层次<br /><br />统一<br /><br />伟大的工具往往有巧妙的结构<br />（业务逻辑讲求清晰，工具注重使用简单实用和强大）<br /><br />提高代码质量：<br />1 想办法限制C++用户

<br />4:05 PM 5/7/2010<br />- 体会“代码噪音”这个词语。<br />- 遇到问题，首先考虑能不能做个工具来自动解决，这是最高级的方案<br />- 与其分而治之，不如化繁为简: 削除重复，寻求统一。普通的重复必然要削除。更隐蔽的重复，比如模式。程序里面可<br />    能有许多的模式，但是却有相似的功能。统计程序的所有模式，并尽量减少模式的数量<br />- 分模块有时候就像搭电话线，一根线连接彼此，搭好了后就不管你想说啥想传啥都可以。。<br />

<br />2:20 PM 8/6/2008<br />在数据驱动的模型下，大部分数据类型的安全检查可以转移到程序外部的工具中。<br /><br />3:44 PM 8/22/2008<br />对于大型项目，是否管理好了复杂度，是项目是否能够顺利进行的标志。<br /><br />11:18 AM 10/31/2008<br />关于重用：<br />    在Mosaic中，组件的粒度过小，当项目变大时，必然会出现难以管理的困难。在没有遇<br />    到需要重用的时候

<br />(06-10-30)<br /><br /> 学习了irrlicht 引擎的 UI 部分的设计。就这个引擎来说，个人觉得 UI部分设计上虽然有些问题，但是效果还是不错的。于是写了 Panel 类。开始他只是个控件容器，后来添加了拖拽功能，目的很明显，我要通过他来实现窗口。<br /><br /> 所以，以前在事件上的处理部分需要改动。当几个 Panel重叠的时候，会出现输入事件处理上的一些问题，比如同时多个控件感应到输入等。于是当某个控件接收并处理了输入后应该返回一个信息。那么我就这样该

<br />15:40 2009-6-14<br /><br />大型游戏的关键需求：<br /><br />+ 灵活方便的UI界面<br /> ~ 方便的UI开发包<br /> ~ 方便的UI编辑器<br />+ 灵活强大的游戏编辑器<br /> ~ 编辑地图<br /> ~ 编辑游戏演员<br />+ 快速的进入测试<br /> ~ 运行时编辑游戏中的可编辑元素，包括UI，游戏演员，地图等<br /><br />粗略想法：<br /><br />1<br />

<br />11:38 AM 6/12/2010<br />业务层需求<br />- 逻辑清晰：<br />    代码直接反映需求<br />    可以很复杂，但是要易维护<br />- 能快速开发<br />    业务逻辑变动太快    <br />- 避免出现业务层无关的实现细节<br />    严格内聚<br /><br />实现层<br />    工具层<br />        - 使用简单<br />            不能给用户带来

<br />11:58 AM 6/12/2009<br />关于RaymanHD Tracker想到的：<br />    雷曼工程非常大，重新编译一次要花费很长时间。如果测试中出了问题，就要从新打包<br />    发给QC部门，需要更多的时间。这就要求程序的子模块有很高的灵活性。比如，当雷曼<br />    在测试过程中出现丢帧，那么我们可以关闭一些繁重的模块来进行观察，因此要求模块<br />    有很好的可配置性。<br /><br />    Tracker在结果JF

<br />(06-9-21)<br /> 决定把控件渲染的任务交给用户实现，尽量增加扩展性。<br /> 决定使用上个话题的方案一，先做做看。<br /> 必须先把按纽设计好。<br />    <br /> 给每个类注册一个唯一的ID，有了ID，我们可以获取一个类的实例的ID，然后与我们想要的类的ID进行比较，这样就可以从父类向下转换，而不用使用C++的dynatic_cast<>.<br /> <br /> 一些行为先在父类进行设计，比如一个组件关心输入事件，并且子类有不同

c++的资源管理的简单解决方案：根据依赖关系管理资源。在分层架构中，底层的资源被上层使用，当上层使用完成时，底层就可以释放资源了。c++中的shared智能指针也是根据依赖关系来管理资源的一个例子。所以，结构的重要性再次得到证明。采用清晰的分层结构后，资源自然得到合理的管理。