一. 检测对象变化的两种基本方式：
学过《微机原理》的人应该都了解这两种方式：轮询（拉）、中断（推）
1. 轮询（拉，pull）
1) 每帧轮询
2) 定时轮询
按业务需求和性能问题选择
2. 中断（推，push，并非硬件中断，而是软件的事件通知方式）
两种模式：
1) 观察者模式
优点：① 扩展性强，事件发起接口不变，只需增加事件类型
② 只通知对某件事有兴趣的对象，不会浪费性能
③ 每种事件对应一种回调函数，对于回调函数，事件参数类型是固定的，MouseMove事件的参数类型肯定是EventMouseMove，不会是EventKeyDown
缺点：① 需要动态维护观察者列表，维护不好可能会通知到不存在的对象
形态A： 独立观察者模式：事件回调列表由每个被观察对象独立维护
① 可能也会附带一个全局回调列表，只是起辅助作用
② CEGUI使用的是这种方式
形态B： 全局观察者模式：事件回调列表由全局消息中心统一维护
① 全局回调列表比较庞大，消息中心的负载可能很大
2) 固定接口广播模式
优点：① 不需要维护观察者列表，从根节点往下广播到整棵树
缺点：① 对某事件不感兴趣的对象也会被通知到，性能稍许有浪费
② 只有树上的节点才能被通知到，所有逻辑对象不一定都在树上
（如果这棵树只代表游戏中各业务流程，那么非业务流程的对象不能被通知到；如果这棵树代表游戏中所有逻辑对象，那么所有对象都能被通知到，但是代价就是这棵树可能有点庞大）
形态A： 特定接口模式：一种事件对应一个发起接口
① 对于每个发起接口，事件参数类型是固定的
② 扩展性较差，增加事件类型需要增加接口
③ 适合于事件类型较少的框架结构
形态B： 统一接口模式：所有事件对应同一个发起接口
① 扩展性强，事件发起接口不变，只需增加事件类型
② 事件发起接口的参数类型是不固定的，响应时需要根据消息类型去判断
形态C： 分组接口模式：类型接近的事件作为一个组，对应同一个发起接口；比如鼠标事件有好几种，这几种事件使用同一个发起接口，但是这个接口不会发起键盘事件，会有另一个接口负责
① 扩展性较强，同一组内事件发起接口不变，只需增加事件类型
② 增加事件组需要增加发起接口
③ 事件发起接口的参数类型是不固定的，响应时需要根据消息类型去判断
两种调用方法：
1) 立即模式：事件立刻处理，保证逻辑顺序，调试链不会断裂，相当于SendMessage
2) 间接模式：事件保存在事件列表中，下次更新处理，不一定能保证逻辑顺序，调试链断裂，相当于PostMessage
轮询的逻辑耦合性强，代码容易变得混乱，C++代码中必须包含目标对象头文件，性能也不一定好，适用于比较简单的程序结构。
中断的逻辑耦合性弱，代码结构相对简单、清晰，C++代码中不需要包含目标对象头文件，只需要包含事件定义的头文件，只在必要的时候触发相应逻辑，性能较好，适用于较复杂和扩展性要求较高的程序结构。
总结：看情况使用，轮询适用于业务需求较少、比较简单的程序结构；
如果业务需求较多，考虑扩展性，中断是比较好的选择；中断的两种方法也可以结合使用。
举例：
主角3分钟无操作后：
1） 头顶名字加上“暂离”字样
2） 聊天信息框显示“你已进入暂离状态”
主角退出暂离状态时：
1） 去掉“暂离”字样
2） 聊天信息框显示“你退出了暂离状态”
解决方案：
使用轮询模式：
1） Character Manager需要不停去查询主角是否进入、退出暂离状态，需要保存主角上一次状态并与当前状态比较，造成轻微硬编码。
2） 暂离不是常态，导致轻微性能浪费
3）不需要为此设计回调列表、不需要维护回调列表，几句if语句就可以处理
使用中断模式：
1）只在必要的时候调用相应逻辑，代码整洁很多，复杂性也降低。
2）需要为这么一个简单的功能设计并维护回调列表，杀鸡用牛刀
如何选择：
如果对主角对象还有若干类似的观察需求，则可以使用中断模式，比如观察主角移动
如果对主角对象仅有这么一个简单需求，则可以选择轮询模式
根本原因：
对象变量当前值是什么是比较容易获取的，但是变量的跃迁一般不太会通知给外部对象，而且业务上对变量的跃迁需求较少，所以设计上容易忽略这方面内容。
二. 对象引用的三种基本方式：
1. 直接引用，直接保存目标对象指针
优点：性能较好；对象不存在了马上就可以知道，因为崩溃了
缺点：对象生命期同步处理不好，会导致野指针，程序崩溃。新手容易犯错
2. 间接引用，保存目标对象句柄/ID，需要引用对象时（向Manager）查询
优点：如果对象不存在，不会导致程序崩溃
缺点：性能较差，每次需要查询取得对象指针
对象不存在了，外部程序可能还不知道，程序不崩溃，但是行为可能不正确，可能造成程序性能轻微浪费
3. 引用计数，直接引用的改进方式
优点：性能较好，即使不能处理好对象生命期，也不会导致野指针
缺点：不能保证很好的掌握对象生命期，有时候就是不想要这个对象了，却不知道谁还保持了对它的引用，容易导致内存被无故占用
总结：看情况选择
三. 参数传递的两种基本方式：
1. 直接引用，直接保存目标对象指针
优点：性能较好，没有复制开销
缺点：逻辑耦合性强，对象生命期同步不好，会导致野指针，程序崩溃
包含了大量不必要的信息，代码容易变得混乱，C++代码中必须包含目标对象头文件，使用目标对象的地方需要了解目标对象的知识
2. 信息复制，定义“传递信息的中间对象”，复制需要的信息
优点：逻辑耦合性弱，只复制需要的信息，即使不能处理好对象生命期，也不会导致野指针
代码结构相对简单、清晰，C++代码中不需要包含目标对象头文件，只需要包含“传递信息中间对象”定义的头文件
缺点：性能较差，稍微有点复制开销，能接受
总结：信息量较少时推荐使用信息复制
举例：
右击NetPlayer弹出操作菜单：私聊、加好友、组队、查看等
这是一个异步操作，先弹出操作菜单，再从菜单上点击按钮，也可能不选择
解决方案：
使用直接引用方式：
1） 显示菜单的代码需要了解NetPlayer对象的知识，需要包含NetPlayer头文件
2） 菜单弹出后点击按钮前，NetPlayer断线或离开视野，如果未被通知到，再点击按钮，程序崩溃
使用信息复制方式：
1） 将菜单显示和按钮操作需要的信息，比如id、name、level等，从NetPlayer指针复制中间结构体，作为菜单的userdata，从而菜单回调函数与NetPlayer对象断开连接
2） 显示菜单的代码不需要包含NetPlayer头文件
3） 即使点击菜单按钮前NetPlayer消失，也不会导致程序崩溃。
使用事件通知（中断模式）
1） NetPlayer消失的时候隐藏操作菜单，就不会导致程序崩溃了
2） 可以跟‘信息复制方式’ 结合使用
四．对象成员变量创建/销毁资源的两种方式：
1）使用构造函数与析构函数
① 构造函数做默认初始化，并创建资源
② 析构函数销毁具体资源，不一定需要将成员变量设置回默认值
③ 构造函数无返回值，不能通过返回值知道资源是否创建成功
④ 适用于含有较少资源的简单对象、或者创建资源不太会失败的对象
2）使用Init/Create与Fini/Destroy函数
① 构造函数做默认初始化，可以将对象先创建出来，占好位置，激活时再调用Init
② Init函数负责具体资源创建，可以有返回值判断资源创建情况
③ Fini函数销毁具体资源，将成员变量设置回默认值，通常该函数可以重入
④ 析构函数中需要调用Fini函数，或者加断言判断资源是否已销毁
⑤ 对象所占用内存不需要重新申请就可以再次使用
⑥ Init时推荐使用do{}while(0)结构：
do{
member1 = create_ member 1()
if (!member1)
break;
member2 = create_ member 2()
if (!member2)
break;
……
}while(0)
五．对象使用前初始化两种方式：
1）谁使用，谁初始化
① 用完以后，成员变量仍然保留了上一次对象状态
② 不能直接拿来用，必须先初始化为默认值
③ 适用于不太含有资源的较简单对象，用完不销毁可能有资源泄露
④ 适用于入口比较统一的程序结构
2）谁使用，用完恢复
① 用完以后，成员变量恢复为默认值，不保留任何对象状态
② 可以直接拿来用，对象成员变量已经是默认值
③ 适用于需要新创建资源的地方，用完时需要销毁资源
④ 适用于出口比较统一的程序结构
总结：UI编程经常使用到，界面打开与关闭时各控件的状态
六．几种基本的容错问题：
1. 重入问题
1) 不可重入：按钮灰态、加断言等方式来保证函数不被重复调用
2) 可重入：按钮使能但是有提示、容错处理来保证函数即使被重复调用也不会产生问题
比如Init函数，资源创建，不能重复调用，资源创建前加断言判断资源指针是否为空
比如Destroy函数，资源销毁，每份资源销毁前加判断指针是否为空，函数可重入
2. 边界问题
1) 内存边界检查
2) 数值边界检查
数值边界问题不一定是有害的，比如::GetTickCount()返回的当前时间与上一帧时间相减，如果当前值超出临界值，相减溢出，结果也是正确的。
3. 子对象间一致性问题
1) 利用信息冗余，减少子对象数量
2) 利用断言判断子对象间的值一致
比如定时器会有个计时用的浮点变量m_fCountTime，和一个表示使能状态的布尔变量m_bEnabled，某些情况下，m_fCountTime <= 0就表示m_bEnabled == false，m_fCountTime > 0就表示m_bEnabled == true，因此两者之间存在信息冗余，m_bEnabled可以被删除掉, 成员函数bool IsEnabled() { return m_bEnabled; }可以改成bool IsEnabled() { return m_fCountTime > 0; }
总结：利用断言检查可能发生错误的地方，比如逻辑是否可以运行到switch的default语句，在有Destroy成员函数的情况下，在析构函数中判断子对象指针是否为空（表示Destroy是否被外部程序调用到并且已经销毁资源）
4. 异步问题
异步编程是业务开发过程中经常遇到的，中间有很多细节要维护好。比如点击登录按钮的时候，网络连接就是个异步过程，在成功连接之前，登录按钮应该是灰态的，不能再次调用connect函数；如果连接失败，按钮应该恢复正常态。又比如刷新排行榜的时候，在网络消息回来之前，排行榜列表是不是应该清空。
七．逻辑状态及其变化的解释
1). 计算机中基本的逻辑状态就是0和1，这个地球人都知道，如图，低电平表示0，高电平表示1，比如一个bool值，false就是0，低电平，true就是非0，通常是1，高电平。
2). 大部分人的问题在于不能理解上升沿和下降沿，其实数电课上都讲过这些概念。上升沿就是电平从0变到1的瞬间，下降沿就是电平从1变到0的瞬间。
当电平从0变到1的瞬间，上升沿是1，其它时候都是0；当电平从1变到0的时候，下降沿是1，其它时候都是0。
举例：
1). 上升沿、下降沿用的最多的地方是输入设备编程，按钮从松开(0)状态，到按下(1)，这一瞬间、这一帧，上升沿为1，之后上升沿马上变为0，虽然按键仍然保持按下(1)。反过来，按键松开的一瞬间、那一帧，下降沿为1，之后下降沿马上变为0。
2). 另外比如上面讲的例子，轮询主角状态变化，主角从非暂离切到暂离的一瞬间，才需要去加上“暂离”字样，并显示提示信息“你已进入暂离状态”，并非需要在主角暂离后的每一帧都显示这个提示信息。主角从暂离切回非暂离状态，那一瞬间，才需要去掉“暂离”字样。
八. 程序出现复杂问题的处理方法：
1). 差异比较法
2). 控制变量法
比如修电脑的时候，用好的电脑上的模块替换问题电脑上的模块，找出问题所在
3). 排除法，屏蔽不相关代码
4). 尝试恢复到一个没问题的版本
5). 更换测试环境
九. 版本出现问题的处理方法：
使用二分法：先恢复到一个老版本，看问题是否正常，不正常就使用更老的版本，正常就二分计算中间版本号，递归使用此方法
十．定位/查找代码的处理方法：
确定代码切入点，污染源查找法，扩散查找
如果量污染太大不能掌控，可能是切入点找的不对
十一. UI编程要点：
1). 键盘快捷操作用的三个基本按键：Esc、Enter、Tab
2). 异步操作状态下，控件使能状态的控制，特别是按钮
辅助工具：cloud，用来模拟网络延迟
3). 控件的输入焦点与选中状态，减少用户操作
4). 文本输入框的初始值、有效字符及最大值控制
5). 界面重新打开时的初始状态
6). 界面关闭时是否要恢复状态
如果你不知道该做些什么，该怎么做，答案很简单：参考标准。什么是标准？比如操作系统，比如暴雪的游戏等，暴雪在细节方面做的很到位的。
举例：比如邮件发送金币，弹出一个输入框，框显示的时候，输入焦点要定位在Editbox上，Editbox初始值0，自动选中文本0。这时候按数字键，文本框中的0直接被替换掉，如果按字母键，应该无响应或者错提示音，不能输入负值；如果输入超出角色身上所有金额，应该限制在最大金额或忽略输入。输入完直接按Enter，接受输入值，对话框消失；不想继续输入或者想取消的时候，直接按Esc键，对话框消失；如果按Tab键，当前焦点应该在Editbox、Ok、Cancel之间按顺序切换，焦点切在Ok上，按回车等同于点击Ok，焦点切在Cancel上，按回车等同于点击Cancel；任何情况下按Esc，都是Esc效果；如果鼠标点击底框，焦点切到底框上，按Esc，也应该相应。
十二．Yes/No对话框与Ok/Cancel对话框的区别
Yes与Ok的操作一般都是一样的，接受某个事情
No跟Cancel有点区别，No代表拒绝，Cancel表示忽略、什么也不做
Yes、No、Ok、Cancel任何一个按钮按了，对话框都应该消失
举例：比如游戏中有人向你发起组队邀请，如果弹出一个Yes/No对话框，点了Yes，接受组队，点了No，会向服务器发送拒绝消息，发起人会收到一个被拒绝的消息；如果弹出一个Ok/Cancel对话框，点了Ok，接受组队，点了Cancel，表示忽略请求，不会向服务器发送拒绝消息，这个邀请就此结束了。
所以还有一类对话框，Yes/No/Cancel都有。
总结：使用的时候，应该考虑清楚当下是使用Yes/No、Ok/Cancel，还是Yes/No/Cancel
十三. 代码Check In的好习惯：
1). 提交之前确定哪些是需要提交的文件，临时文件、不相关的文件统统剔除
2). 提交之前再次比对每个文件修改，确保每一行修改是正确且相关的
3). 按功能、分块提交
如果Commit的时候发现这次修改中涉及到几个功能修改，则分多次提交，每次都是独立的功能；
如果是同一功能但是量比较大，可以把底层支持、业务无关的功能先提交，再提交各业务功能
如果一个文件中涉及到不同功能的修改，则备份文件，恢复不相关的代码行，一次只提交一个功能修改，完了之后再从备份文件中恢复其它修改，如此反复，不要嫌麻烦，确保一次提交中只涉及一个功能块。
总结：1)和2)加起来是两段式提交；这些习惯分别是为了“减少垃圾文件”、“降低出错几率”、“版本出问题后方便定位”
十四. 优化
1). 古话云：过早的优化是万恶之源
2). 过晚的优化会让你极其痛苦
3). 优化应该融入到你的血液当中，时刻想着要设计比较优化、简化的代码和流程
4). 优化也是个不断调整、不断迭代的过程，是个不断修改设计的过程，一次性很难做好
5). 代码优化的四（五）个层级：架构级、（模块级）、算法级、代码级、汇编级
代码级主要是指函数参数、返回值、循环、赋值表达式等。
汇编级太依赖于CPU，不做重点；并行处理的汇编指令(MMX/SSE等)可以作为学习内容。
6). 现在的编译器优化工作都做的很好，我们只需要做适当引导
十五. 游戏程序设计的宗旨：稳定和正确、简洁、高效、可扩展性
1). 稳定和正确是基本条件，没有什么比这更重要，程序宁可运行的慢一点，也要保证稳定和正确，错误的代码运行的再快，也没有意义
2). 简洁的设计容易让人理解，比较直观，通常也会带来高效的副作用
3). 高效的代码绝对能体现一个人编程水平，保证稳定和正确情况下的高效是令人赞赏的；高效有时候跟简洁是对立面，看情况取舍；高效对程序员的素质要求更高，在人力成本较高的情况下，通过提高硬件配置来改善程序运行效率也是可行的
4). 游戏编程策划需求千变万化，你的设计要比策划需求快半步，考虑到策划将来可能会增加的需求，降低代码的修改成本；太先进的可扩展性不一定可取，因为可能用不到，也有可能是通过降低性能来换取的，属于设计过度；可扩展性有时候跟简洁也是对立面。
代码是写给人看的，不是写给机器看的，设计思路一定要简单、直观、易懂、合理，少绕弯，杜绝奇葩思路，文档注释清楚齐全，代码保持整洁，版式清晰，该去的统统去掉。方便同事维护、方便后人维护，潜规则和硬编码尽量少定制，必须有潜规则、硬编码的情况下必须注释清楚，猜测别人的潜规则成本较高、也容易出问题。
十六. 游戏程序设计的若干技巧：
1). 任何计算机问题，都可以通过增加一个间接的中间层来解决
2). 减少模块间耦合（就像设计电路板时减少各组件间的连线）
3). 对象的继承与组合（m*n与m+n），用于防止子类数量爆炸
4). lazy compute和pre compute
5). 查表（通常用于pre compute和提高程序效率、时空互换的典型）
6). 时空互换
7). 层级架构（树、图）vs 平坦架构（数组、链表）
8). 分时复用
9). 分布式
10). ……
PS：现实世界的设计往往都很巧妙，小而简洁的设计中往往包含着大哲学，大道至简，并不一定需要懂得复杂高深的算法才能设计程序，毕竟那些出现的几率很低。比如imageset，把小图片合并成大图片，原先老的显卡上不支持非2的幂的贴图，你一张界面底框即使800x600，也会占用1024x1024的内存，imageset把小图片合成在一起，即利用了原本浪费的内存，又减少了渲染时贴图切换的开销（dx的SetTextureStage），一定程度上还增加了读取磁盘文件的效率，一举三得，非常巧妙。
扫一扫
1032
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
