组合设计会更灵活，速度更快。

组合设计会更灵活，速度更快。

例如发送消息处理。  可以在发送函数里检验玩家是否在线。但是这样，如果发送函数被其它也需检测是否在线的函数调用的， 那么是否在线的函数可能就被调用多次，导致效率下降。 所以检验是否在线不应内封在发送消息里， 而是应独立在一单元，例如建立一个专门获得在线玩家数组的功能（例如：然后这个数组做为参数传给发送函数）。

进一步推论。 异常处理和功能模块， 不宜绑定在一起实现， 而是可以分成两个部份， 然后通过应用层进行动态组合。 这样又能保证可靠性，又能提高效率。 STL里就没有做过多的异常处理的设计，异常是由用户来保障的。

 

 

以前都是一种参数间的组合， 而且方法的组合则是一种硬编码式的调用。 而STL提供了一种方法间动态组合的策略，从而缩减了大量方法组合的硬编码，而且提高了灵活度和完全性。

 

如果某些操作可有可无， 或者有了虽然好，但是会增加类的复杂度和降低性能。 那么可以考虑把这些操作“外包”出去， 通过STL类似的方式进行动态组合，生成应用层的功能。 例如说， 某个类的数据要进行硬盘空间的读写， 例如说， 生成怪物时，是否要进行对怪物的死亡监听。

 

 

考虑两种方法：
1，一台消息机， 消息机上传递着各种不同的消息。
2, 一台消息机， 消息机运行各种不同的状态。

如果采用方法1，区分因消息而区分。同时因为有很多消息是大同小异的， 即类型一致的， 在共

用同一消息机的情况， 需在编码期就对这些会类型一致的执行期消息必须进行具体的应用逻辑以

区分(例如不同的数值编码)。问题域和设计域不能获得“直接一致”的映射。

 

技能其实是生成一个“技能NPC”， “技能NPC”通过检测碰撞实现对碰撞对象添加buf.
至于技能NPC怎么去寻路以检测碰撞， 则由NPC内部AI决定。
这样就统一加BUF和伤害的接口了。

 

如果采用方法2， 区分因消息机而区分。消息大同小异的问题可以因为消息机的不同而自动获得

解决。同时针对监听某一个消息的触发， 实现上不用再大家一起并行的监听了， 而是监听层也

有层次关系。问题域和设计域的映射更直接， 可以减少很多由于映射不同的实现问题(例如删除

时的复杂度)。方法2因为消息机是执行期才产生， 没法提前约定好， 异致需在执行期再进行绑

定。

 

 

情节模块会生成若干情节网， 网以“标签结点”为分段点， 用户可以通过库提供的查找功能找出对应的“标签结点”， 然后插入或修改相应需求。  相当于提供一套玩具积木，更依据需求对这套积木进行若干修改。 对于需要传递参数的问题， 可以不直接提供传送接口。 而是写进一个指定的buf上。 当需要获得参数时， 也是通过标签从对应buf上获得所需参数。 另外， 对外若要提供情节网的入口或出口结点， 而是提供一串标签化的控制结点序列。 这些控制结点甚至可以是独立于情节网以外的， 只要有关键性，就对外提供（也就是说标签化控制结点之间是离散的，无序的）。  这与对外提供一个类的功能不一样， 功能是不同类型的。 而标签化的控制结点序列是类型一致的。

 

 

尽量不要做一个试图功能庞大，无所不包的类。多想想这功能是不是这个类必有的， 如果不是必有的，那么可否外包出去成为一个“组合类”的东西。 例如试图给“数据库数据操作类”加一个标签（例如有一个行为序列， 然后想找出头行为和尾行为，这时就有需求想加一个标签）， 但明显行为本身是不应有标志的， 而且没必要每个行为都要打上标志（因为琐碎行为可能很多，而关键行为可能就几个（头，尾，转折点））。   既然不是必要必有， 可以产生一个绑定类， 使用时，把关键行为的实例和标志符绑定在一起成为一新实例。

 

消息与调用的区别：

直接调用就相当于接有线电路， 其模块间的关系是确定的，强耦合的。 好处是清晰可靠， 但担挡不起大规模的线路。  当面临大规模的关系机制时， 修改会看到一堆有线电路错综复杂的捆绑问题，要考虑模块间的影响， 要考虑线路的渠道等枝节问题。 而消息相当于无线广播， 其模块间是弱耦合的。 当面临大规模关系机制时， 渠道和模块间的影响可以不考虑。

 

另外，当需求出现几个功能一致但产生方式和参数不一致的消息时， 其响应端故可针对各种不同的消息做出响应。 但一个更好的方法是， 做一个消息转换器。  这样可以广播空间即可能的职任单一,并减轻响应端的工作量。

 

关于ID， 可以是一种分级ID的形式， 每一级有每一级的ID。而事物的ID就是由这一系列ID加起来的总合为其ID。 例如说地图。 在策划设计阶段需有一个地图方案（或者说地图类）， 此时可以分配的一个设计级I_ID， 这个设计在程序运行时生成的一个地图实例， 再分配一个执行期U_ID, 地图又可能以几张小地图构成，那么再分配一个M_ID.  那么小地图的ID，实质就是{I_ID,U_ID,M_ID}。 针对一些特殊情况， 还可提供从根级ID查找子级ID，或是反之的功能。 特别是根级和子级是一一对应的关系时。

 

 

 

1_a:网络经常面临问题：收到一个请求，　这请求到底是重发请求呢，　还是新指令请求？
1_b:解决方法之一是， 把一条消息异化成两种消息： 初步请求消息， 重发请求消息。
2_a:但这样接收端会有一个新的问题： 当收到重发消息时， 接收端怎样确认是哪条消息？而那条消息又是否做过呢？
2_b:所以需要增加一个记录信息。
3_a:但是增加记录信息又导致记录信息何时保存和何时释放问题?
3_b:解决方法是仿照TCP方式，建立一条链接， 通过链接来区分消息和是否做过。

 

“ 天龙座 流星雨吧，这个月有几十场. ” 其实在天龙座住着一群高等智慧生物，当年就是他们神秘的出现在一个叫地球的行星上， 指引当时的韩国人进化到人猿， 再指引人猿进化到人类的。 这些流星雨实际是他们的由中子引力打造的宇宙飞船进行空间光速曲率驱动留下的轨迹。 他们要去银河系的边缘寻找奥特曼。

高等智慧之所以科技优秀，就因为他们的生理结构在先天上就存在优势。 由于他们长期处理粒子放大器的矿物环境中，他们的交流可以直接通过脑电波沟通，这使他们的沟通和传承准确无比，而且奇异的基因，居然使他们两性结合时， 子孙直接就继承了上一辈的所有知识和智慧。在他们眼中看人类， 就如同人类看鸡和狗一样，充满着高等生物俯视低级生物的眼神。

 

 

/*

在上周日的节目中，一位男嘉宾无意感叹，“现在的女孩子普遍都太现实了，交往的目的性、功利性都比较强。”不料，9号女嘉宾张静的反应却出奇地强烈，“我每次听到男生这么说，都觉得很难接受。女孩子不是现实，她为什么会要求你的物质？是因为你没有给她任何安全感，你所有的行动根本证明不了你能跟她走到底。你自己为什么不去努力，而认为是女人现实呢？因为你可能给她的感受是你不努力、你不上进，可能未来会贫贱，所有的爱情在贫贱面前无处藏身。”话音未落，嘣地一声灭了灯。孟非表情略显不悦，平静地问道，“你觉得男人拿出了什么样的东西女人就有安全感？”张静答道，“要把人生规划真真正正做出来，告诉她你在做什么。”
 
    随后，孟非的情绪开始激动起来，语速也明显加快，“假定我今年28岁，在和一个姑娘谈恋爱。我跟她说我35岁的时候要成为中国最优秀的主持人，我要为这个事努力一辈子。我一直努力、拼命，这是我一辈子奋斗的目标。如果你是那个姑娘，你听完了会有什么反应？”张静回道，“我会转身就走！”听此，孟非忍不住发飙道，“为什么你不理解我这个目标呢？你说我不上进，那我告诉你，我每天都在努力，为了我的目标奋斗，你为什么又不相信我了呢？你要一个男人给你一套房子，这个东西马上就能放在那儿，房产证马上就能给你看，这是个房子。而我告诉你，我在奋斗、在努力，这个东西是看不到的！”节目播出后，网友纷纷对张静的观点表达了不满，同时也是对孟非的发飙大感惊讶，但也都给予了理解。事后，孟非也在微博对自己过于激动的反应表达了歉意，“听人告诉我，节目里有一段话我比较激动。在我这个年纪还会这样，真的挺惭愧。当时我应该表达这个观点，但语气应该再平和一些。抱歉。”

*/     女人多是这样的， 说什么上进的鬼话， 其实钱一放下， 什么事都解决了。   

 

 

绑定参数之类的函数，应该归类到参数转换器上， 但参数转换器不应局限于此， 还应含有通过原有函数取得新参数，再把其接入函数的参数转换器。

 

 

有时会面临有一个不错的战术想法，但对于整个项目已而言则茫无头绪的感觉， 这时可以尝试把相关负责人找出来，一个可运营的方案就开始浮现。
服务器架构顾问：L
主场景： 一个地图形式出现的主菜单列表。 合作伙伴： R。
第一步可以直接用菜单实现， 在搭建基本框架后， 再把这个菜单转为地图式菜单。
(公共空间， 玩家空间， 副本空间(救人类空间，击杀指定怪类空间, 比武招亲类空间,  专项练习类空间等)。 主场景的过渡可能发生遭遇战。)
战斗模块：合作伙伴：C
收费模块： 合作伙伴： 可以考虑B。

 

 

 

 李开复：创业者拿不到VC投资的5大原因

给VC盲目发邮件而不是去找VC信任的人推荐。在VC当中有这么一个共识，“假如一个创业者不能通过我的一个熟人来推荐他自己，假如他连这点资源和头脑都没有，那么他很难成为一名优秀的CEO。”所以不要盲目给VC发邮件，我自己就从来没给这样的一家公司投过钱。

见VC前缺乏准备。在初次见面之前，你应该要对一名投资人仔细研究。他的背景是什么，之前投过哪些公司，这些公司身上有哪些共同的特征，是你在见面的时候需要展示出来以留下一个好印象的?

沟通不够简洁清晰。你必须能够简洁沟通。一开始，你就应该能用一句话把你的公司介绍清楚。然后，你还要能简单地说清楚：整个市场有多大，竞争对手有哪些，公司的差异点在哪，团队有什么特殊之处。

花太多时间谈市场而不是产品和团队。你没必要花很多时间谈市场的总体情况和潜在机会，因为投资人可能比你知道得更清楚;即便不是这样，他也能在你简短的叙述之后做出自己的判断。所以，把你的时间用在介绍产品和团队上面，因为这些才是他不知道的信息。

第一次会面时与VC争辩。在第一次会面时，别试图说服一名投资人她在某一点上是错的。当然，你也没必要向投资人的观点一边倒。另外，假如你在某一点上卡住了，那就移到另一点上。要专注于你的公司的优点。

 李开复表示，第一错“侥幸心态”。创业者堵投资人的门、向投资人群发Email，认为投资人看到邮件就会投资。其实没有这么简单，投资人每天要看数以百计的商业计划书，然后再筛选并做深入调查，不可能让你“侥幸”获胜。

　　第二错：“拍脑子想点子”。不要认为拍脑子想出的点子就会拿到投资，好点子不值钱。

　　第三错：“想问题没有深度”。创业者很浮躁，有个点子，马上就写商业计划书、找投资;但见了面，几个问题下来，创业者就被问倒了。

　　第四错：“堆叠商业模式”。有的创业者喜欢把一系列的“流行商业模式元素”做堆叠，但事实上这让投资人很倒胃口。

　　第五错：“伪需求”。创业者喜欢把周边人群的需求放大。例如“我老婆有这个需求，我朋友有这个需求”。但这些需求是伪需求，不是创业者从真正用户那里问来的。

　　第六错：“过分偏执”。极个别创业者为得到投资，以“我得了绝症，你不来看我，我就不活了”这样的偏执话语威胁。这样的情况，就算投资人来见你，但最终还是要看项目。

　　第七错：“低估创业难度”。创业难，难于上青天。今天即使你得到李开复的投资，进入创新工场孵化，要想成为腾讯、阿里巴巴这样的企业的概率还不及千分之一。

　　第八错：“故作神秘”。创业者把“点子”当商业机密，与投资人谈条件：“先给钱再说点子”。要知道，创业者是靠执行获胜，不是靠秘密的点子。

　　第九错：“不诚信”。创业者“盗窃”他人项目的知识产权。

　　第十错：“描述不清晰，讲话没重点”。投资人希望，创业者能用一句话概述：“项目情况、用户、市场和团队特色。不要浪费彼此时间”

 

 

有时侯会面临未来不知数据会有多少变数的问题，　而把所以变数一次性全部写上，　或者在面临变数时，不断修改类源码以扩充新的数据记录显然不是一个好方法．　这时侯，可以采用索引＋绑定方式解决：　类源码的数据只有一个用于区分事物的uid(索引用), 然后在后续的模块中，需要扩展新的数据，则对这个uid进行各类绑定．　这样，新增的数据需求不会修改到旧有的数据需求．

 

 

在企业管理方面：我觉得执行力是很重要的， 而在执行力的贯彻力量上，要重视“培养标兵，发挥标兵”的作用。管理不是光谈， 管理是要用血汗换来的。 当今社会谁都不是傻子，想通过投机取功获得管理上的成功， 是不长久的， 不治本的。 毛泽东就提过“标兵的力量是无穷的”。

 

 

在做情节网时曾面临一个矛盾，到底要不要把所有消息的产生和触发都做成插件呢，如果全做，好像在使用方式上，可以达到一致，而且灵活．　后来windows端口给了我参考和启发，其实还是不全做的好．　像端口，一部份是约定好系统用的，　另一部份才是给用户．　约定好系统用的，是一些经见的，甚至是必有的，　这些能减少用户的工作量．

 

 

 

容器消息机,插件:地图类，　人物类.

互动绑定类(ＬＵＡ):触发器,回调,消息.

 

容器消息机:

静态场景: 触发开启容器信息. -> 触发初始化信息 ->触发结束信息 ->触发解放信息

(开启和初始化不聚成一个模块,是为了以防有交互初始化操作的模块问题)

动态场景(人员):触发登陆消息 ->操作消息 ->触发登出消息.

 

服务器采用天梯的房间人数形式,由玩家自主选择空房间还是挤房间,房间有最大人数限制,每个场景服即一个房间.故可采用单线程且服务器压力人为均横.

 

 

虽然对有些事很不满意, 但该做的必须完成, 这是职责所在!  太阳终于升起, 脸被烤得炽热. 你终于喝酒了,极目四顾,山长水远.

 

副本的解放可以通过当副本总人数为零时,产生一个退出导致空人数消息,监听该消息已决定是否解放.

 

--布局将会配置一个AI集群服,当NPC进行AI操作时,例如寻路,攻击,防守这些时, NPC会将当前信息生成一个快照,发送到AI集群服.
--AI集群服会以并发的方式进行处理,然后将结果发回服务器,服务器只针对结果的可行性进行验证(不验证有效性).
--可行即执行,不可行重新生成快照并要求重新处理.

 

--串行产生问题, 并发处理问题, 串行使用结果.  虽然在首尾的串行仍然导致等待时间, 但中间针对快照的并行处理实现预处理的效果, 带来了效率的提高
--实现内容: 针对需求指令产生"获得执行结果"队列. 每个"获得执行结果"队员需接收到结果并验证可行时才可出队.否则原地产生新快照,重新等待.
--快照不是由服务器发出,而是AI集群服在处理时,主动获得的快照.
--最简单的情况,服务器先循环,用一个随机数决定将接收指令放进队列,还是进行队列处理.队员放进队列后,就等待出队消息的触发.而不是循环检验让其出队.
--结果处理后,先将结果放入指定buf,然后产生一个出队消息.服务器收到出队消息后就一直出,直到不能出.

 

目前LUA里用得最多的就是NPC和触发器的操作, 完成NPC模块, 就相当于完成了大半个游戏世界.
而实现NPC的核心,实际还是实现触发器.
用LUA实现一个NPC的AI触发器.

 

 

两个问题:
1, 实现容器.
2, 实现AI状态机.

 

 

整个服务器的内核交流会仅由两种ID构成, 实体ID, 事件ID.  相关细节处理会由上层再去进化细化.

NPC_PAR_IID = 1
NPC_SKILL_IID = 2
NPC_AI_IID = 3

NPC_UID
Bind_Par(NPC_UID, NPC_PAR_IID , par_iid)
Bind_SKILL(NPC_UID, NPC_SKILL_IID , skill_iid)
Bind_AI(NPC_UID, NPC_AI_IID, ai_iid)

绑定器的好处:
1, 使数据的传输量减少.
2, 使子数据的处理功能复用性提高, 例如NPC和物品都可共用一个头像处理类.

 

 

我觉得状态机的实现不是很好,理由:每个状态即是功能的实现者又是结构的组织者.  这就像让一个人是流水线上某个环节的生产者但同时又是整个流水线的管理者一样混乱. 例如, 会产生多个管理者指向同一个地点,这时想摸清整个"逻辑网"就相当难困,更不用说如果想增加或修改状态带来的副作用了.我觉得应该生产归生产, 然后有一个专门的管理者管理全部. 这个逻辑网只有一处拥有,维护和扩展方便.也就是说,还是我设计的"情节网"模式更好用.

其实AI情节网和我做的副本情节网是一致的,只不副本情节网的触发只有点击NPC唯一入口,而AI情节网可以有多个触发入口,同时当某一入口已经引申到其子结点的后续触发时,突然又跳回到另一入口时,要处理是否消除原有触发器的问题.整个服务器,其实可以看做是有一系统触发器构成的:放上一个物品,就是触发器流水线上关联进一堆物品的相关触发器; 放上一个NPC,就是在触发器流水线上关联进一堆NPC的相关触发器...整个服务器,其实就是触发器流水线的管理,而NPC,副本,物品等,不会是一堆触发器的容器.

 

 另外,服务器是不适宜对每个实体生成一个对象的, 这就像设计模式里的谈共享模式的时为每个字符生成一个对象一样, 这会导致生成量相当大的.例如每个角色实体都产生一个附近敌人靠近的触发器，  那么一个服三四千人就马上产生了三四千的触发器对象空间，而这是没必要的。 只要一个抽象层的触发器即可，虽然触发时会有一个查询实体的过程，但是相比三四千的空间来说， 这点开销微乎其微。所以应该采用共享模式,提炼出一些共享操作和数据.

 

 

服务器本质上来说, 其实是一个触发器机器.  

触发器的机制可以采用消息机的方式实现, 另外事件和消息应分开, 同时消息应有自身的消息头,以防复用消息通道时出现矛盾.

 

 

假定场景器直接连用户的通讯规模复杂度是 O(N), 当把其拆分成两个服：对话服，活动服。 对话服主要负责对玩家的消息接收和发送；活动服负责场景内的活动逻辑处理。由于会话是要从活动服通讯到对话服，再由对话服通讯到玩家， 所以通讯规模复杂度增长为O(N+M)，几乎等于没有增长。

但带来以下三个好处：
1， 玩家切换场景， Socket的重链问题的爆发从外网转换到内网的服务器之间， 处理更可控和更快速。

2， 实现消息广播和活动处理的并发， 因为快照的广播和活动处理是不矛盾的，所以可以并发。虽然总的通讯规模增长到O(N+M),但由于演变成两台机器的并发处理，从增长和解决能力之比来看，应该是效率上有提高的。

3， 稳定和健壮性。 从开发上看， 由于外网对话层属于基础功能， 基本上可以做到仅一次性开发，一旦完成即相当稳定；而活动服由于应用需求的增长， 会不断添加新代码， 这导致了不稳定。 但是这种不稳定仅影响活动服，从而增长了整个体系的稳定性。  在天梯打dota时，有一个典型功能“已掉线，天梯进行重链”。  如果说仅有一个服且是单线程，那么这个重链过程必将让整个游戏停顿下来。 但是我们发现天梯的游戏是一直在进行的，重链是你自已的重链。 由此推测，天梯可能就是连对话和活动划分成两个模块的。

 

 

优化小技巧： 用TCP和UDP双线保链接， 因为不同的链接断开原因会涉及到要不要清空BUF的问题, 如是玩家主动断的， 主动断的则清空； 如是网络异常断的则BUF保留以待玩家重连。 UDP心跳在于验证是否主动。 如果一段时间TCP断了， 但还能收到UDP心跳， 则说明只是偶然异常，暂时BUF不要清空。

 

网游服三层： 1， DB层； 2，中心服+登陆服层； 3，场景服+会话服层。

 

在网络通讯时,如何从消息头取出数据的问题上,觉得那种if (sub_cmd_id == XXX) 的方式不是很优雅.  这样看起来像是使用者在无目的探索东西, 而且问题域的思考从浪费在这些技术枝节上了.  所以改换了接口为 get_sub_buf( _sub_cmd_id):  虽然看起来只是接口变了, 但感觉思考方式是不一样的: 使用者变在是针对需求域获得相关东西, 但切近于"只做需求的事"这种思想. 同时排除了不断if导致一些笔误代码的可能.

 

 

数据库 -> (数据, 缓存机制类)
中心服 -> (管理器, 调试器)
场景服  -> (天时, 地利, 人和) -> 各类活动插件.

 

 

怎么实现因玩家而异的服务界面?
现在的方式是用全局共享的NPC的ID做识别符,若同一个NPC有个别处理需另再做特殊处理.

 

最大的困难：　必须找到服务器相关的对象，以适当的粒度将它们归类，定义类的接口和继承层次，同时建立对象之间的基本关系．　

 

对当前问题有针对性，对未来的问题有通用性．

 

或许更好的作法不是九宫格， 而是创建一个“摄像机”类， 然后依据需求在指定地点安装摄像机。

 

技能和动画原来是采用“约定时间”来实现配合的。
虽然土，但倒是一个好主意。 这样就减少了技能与动画的播放配合的开销（例如细节到帧的相互回调之类的）。 同时开发逻辑简单，最简单的情况，就是没有动画， 画面上所有东西都不动， 然后每到计时器时间到，就产生的一个伤害值。少了细节到帧的配合与监控后， 程序和美工的开发可以完全脱离。程序可以搞个静态的程序，等美工开发完， 直接配合上去即可。

 

 

--一条技能指令过来
--先流经否决状态模块的处理
--再流经数值处理模块的处理

 

先实现一个场景：巨魔在一张地图上攻击月骑

--技能：
1， 依据法术实体类型和触发情况确定被施法对象。
2， 对被施法对象进行相关BUF设置。

 

在做副本时， 也遇到过链的问题， 因为第一个方案就是采用“树”结构实现副本情节的。。。  后来优化了， 采用消息机的方式， 效果还行:)  与链不一样， 采用消息机后， 相关结点不直接进行绑定， 而是大家约定一个共有的信号。从而实现相关结点的弱关联， 当删除结点时， 只要信号不定，是不会有影响的。

 

 

成报：你在《华为的冬天》一文中提到，「庙小一点，方丈减幾个，和尚少一点」才能缩小庞大的机关，你认为这种现象在中共「十八大」後会有甚麽改变吗？

任正非：你问题我答不出来，不是我的羞耻，而是我的伟大。为甚麽呢？我容忍你比我厉害，就是我伟大。

 

 

心胸狭窄或者冲动的人，容易为一些事情而不惜一切代价，从而错过了其它性价比更好的选项，从而导致最后全局总收益的下降．

 

关于Dota一些技能的原理

死灵法大便/娜加蛇/流浪锤：
利用触发器制作傀儡单位 当傀儡追踪到目标单位身上时对其使用死亡缠绕/法力燃烧/风暴之锤（此处傀儡还会对该单位所处圆圈范围内所有非友军使用风暴之锤）。这就是为什么跳刀躲不了这种招的原因


火女受折磨 T：
在圆圈中心制造一个傀儡释放战争践踏


大屁股的坟场缠绕：
圆心处制造两个傀儡
一个为坟场动画 一个为探测器 对所有进入射程的敌人施放丛林守护者的缠绕并记录该单位 本次坟场中不再施放下次缠绕


虚空大：
范围内除虚空的所有单位 每0.01秒被一个傀儡释放一个状态使其动画速率为零


影魔大：
触发器群体减速 并且释放一圈（八个）等级由灵魂数目决定的修正版腐臭蜂群（灵魂最多有30级 每级加影魔两点攻 故此处腐臭蜂群也有修正伤害 猜测每级大概增加10点伤害左右）



圣堂折光/死灵法无光之盾：
可用伪编程语言说明
if伤害值C>(总生命值B-伤害前生命值A)
{
if伤害值C>=伤害前生命值A
设置单位生命值为总生命值B
稍后（接受伤害后）
设置单位生命值为目前生命值（=总生命值B-伤害值C）+伤害值C-(总生命值B-伤害前生命值A)
else
稍后（接受伤害后）
设置单位生命值为目前生命值（=伤害前生命值A-伤害值C）+伤害值C
}
else
设置单位生命值为伤害前生命值A+伤害值C

技能触发时，技能的参数识别码应该是绑定在技能实体上的， 不是玩家身上。以dota为例， 狼人召出小狼后， 狼人自身的小狼等级上涨， 但是已召出的小狼还是原先等级。

 

打dota时， 如果选的是DPS，要学会忍耐， 情况不是太坏的话，甚至要学会隐藏在旁看队友和对方耗到残血。 等对方技能秒不死你， 而你上去可秒死对方时再上。  从人数上好像是 N比M的交换， 但是因为DPS只是缺前期，所以交换后性价比更高。   DPS要的是成长， N_DPS要的是实地。

 

 
另外对方点控较多时， 宜用方阵型队列。 如果对方团控多的话，则宜用尖椎型队列。

 

 

灵活和通用， 指的是它的结构， 不是它的形式或者是具体某个做法。    一个灵活的结构， 不是说针对某个一个问题有一个什么参数， 或者什么接口可以解决。 不是这样的。  这些所谓的解法， 其实都是是一种土鳖作法， 一种野路子。 灵活的结构， 首先要考虑的是所以了解决当前问题外， 还要考对未来的需求增长点能够做出适应。这个结构并不是说你要去为未来的东西实现什么接口或者参数， 不是这样的。  而是说，你需要为未来的问题域留下解空间， 一旦战事发生， 你可以在不改变结构的前提下， 实现对应的解决策略。 注意， 是留下解空间的余地，不是说现在就要你去解决未来的问题。

我一直想从头到尾摸清整个服务器的工作。  其实像iocp，数据库这些具体技术问题， 我虽然不精通， 但我一直没放在心上， 因为这些都是可控范围内的问题， 只要投入足够的时间， 你就会有产出的。 但是服务器最难的一块，不是在这里， 是他的框架结构。
你要找到服务器相关的对象，以适当的粒度将它们归类，定义类的接口和继承层次，同时建立对象之间的基本关系。

如果一旦你对服务器的需求问题域不精通， 你很可能划分出偏差很大的结构， 这会导致你必须不断迭代模型， 以逼近最适合问题域的解模型。  重构代码是一件很花时间的事。 所以为什么做服务器的人特别要求有经验呢， 因为经验会让你特别了解需求域的情况， 从而更准确的划分出对应的结构和其通讯机制。 有时侯，这真的是一种经验之谈， 因为只有吃过亏， 才知道当前解模型的缺点在那。

 

服务器的问题： 1,事物的结构, 2,事物的运动关系.

 
主动技能还好搞， 弄一个技能实体， 检测到碰撞就进行相关属性设置。 但是被动技能怎么弄呢（叠加的问题可以用在玩家身上加个BUF标志解决）？  有三个方案： A： 我加我减（我需要维护一张加减列表）； B， 我加你减（由我启动状态， 你来负责消除状态）； C： 我启发， 你加你减。。。

采用第四方案：　我启发，中立机构加中立机构减(触发器)　　启发和加不作为一个过程的原因是．启发是一个搜索确定对象，而加则是怎么处理的问题，分开更灵活．

 

 

１，系统接口(工具库)；　２，事件机；　３，角色数据；　４，技能定义；　５，技能积木；　６，技能配置表；　７，测试．

 

dota是一门玩偷袭的学问

 

function main()
 --初始化模块
 --循环
 {
  --[[
  if rand()%100 < 40 then
   create_client_event()
  end
  on_time( 可以是产生消息的 )
  --]]
 }
end

 

应对用户使用的功能模块有一个计数功能， 以便统计那些功能是最具广泛性操作的，从而进行优化。

 

如果未来某一天我是程序部的老大，我要做好以下三件事：

1， 建一个内部邮件系统， 工作交流以邮件为主， 这样便于大家记录每天的工作情况。

2， 提倡公开的代码审查机制。 每个人写的代码，会在公共资源上公开，由人点评。

3， 建立标兵机制， 每个规定周期里， 推介本周期的员工里写的最好代码， 并提供奖励。

（我希望能建立起一种做事为主的氛围， 老想直接当管理者，当公务员，不沉下心先做出实事的小资， 果断T）

（有人说培养狼性文化不好，狼会顶住老板的。 我觉得这是两个问题了， 狼的概念都不存在， 谈什么好狼恶狼。 退一步说， 好狼还可以救救公司，羊则必拖垮公司。并且如果老板自已不奋进， 被恶狼顶掉是应得的。 狼性文化的，老板当然必须也有狼的奋进）

 

 

如果有多个地方会进行删除某一对象的操作, 或许可以考虑成大家都不操作, 而是交由一个中间管理机构进行删除, 然后有一个关系绑定工具监听"多个地方"自身的消亡信息.一旦某个地方的关系消息消亡产生,则中间管理机构消除其中心对象的所有关系, 然后对对象进行解放.

最大的不同，不是要求“指定对象”解放， 而是报告“自身对象”解放。 这种区别的意义在于， 大家只负责自已的解放工作同时广播解放信号，不用管共享对象的解放工作，从而减少了程序复杂度和工作量。

 

消息机的遍历队列里会有这样的问题： 如果队列的某成员的响应操作就是要删除队列的另一个成员的响应， 这时他操作后就缩减了队列数，但是遍历行为可能还按原先的队列数进行扫描。  解决方法1： 遍历队列不是直接指向源数据，而是源数据的一份拷贝。当删除操作进行时，其操作的是源数据，所以不会对当前拷贝而得的队伍产生影响。同时实现了删除操作在下次遍列时才生效的效果。 解决方法2: 删除是不是真的删除,而是把删除对象记录进相应数据, 等派分前再进行相应真正删除.

(后来想想, 解决方法2很不安全, 在缓存到真正删除的这间期间内, 如果遇上又new了一个监听者, 指针地址又刚好和缓存的一样, 这时就会产生误删.   看来还是只能拷贝最安全)

 

又想物品和NPC有各自的分配,又想他们有全局的分配,解决方法是分两级ID:IID,UID

 

老头说：”当日华山论剑，先是他用黯然销魂掌，破了我的七十二路空明拳；然后我改打降龙十八掌，却不防他伸开右手食指中指， 竟是六脉神剑商阳剑和中冲剑并用，又胜我一筹。可见天下武功彼此克制，武学之道玄之又玄！” 少年听得心驰目眩，正要在问，旁边老太太骂 道：mb玩个石头剪子布都说得这般威风.

 

周立波脱口秀:这么看员工辞职：员工的离职原因林林总总，只有两点最真实：1、钱，没给到位；2、心，委屈了。这些归根到底就一条：干得不爽。员工临走还费尽心思找靠谱的理由，就是为给你留面子，不想说穿你的管理有多烂、他对你已失望透顶。仔细想想，真是人性本善。作为管理者，定要乐于反省。。。

 

UID在分配给对象时， 不要采取完全自动分配的方式，而是可以部分指定UID分配。 这样方便某些情节可以设计针对某个UID进行相关处理（例如不同场景上的相同对话NPC会有不同的处理），又可针对某个类进行相关处理（例如所以商店NPC都是弹出商店窗口）。

 

 

考虑这样一个问题： 要实现一个两个人距离超过规定半径时触发的触发器。
方案1： 开启一个定时器， 不断按一定周期轮询两人距离， 超过触发。
方案2： 监听两人的移动消息， 响应时计算两人距离，超过触发。

初步思考：第一种是轮询，第二种是被动响应， 好像第二种的成本更低。
中步思考：第一种虽然是轮询，但是规律不和玩家人数挂勾； 第二种虽然被动， 但是会导致所有玩家都要发送移动消息（玩家和这个触发器是两个模块， 彼此互不了解对方需求的）。 所以第一种成本低。
最后思考：网游中，移动消息应该是属于基础必须的消息， 所以这个需求里不存在扩展渠道的成本，所以还是第二种成本更低。
综上所述，具体采用那种，还是要实际情况为利， 可能在某个规模内是这个有利，超过了阀值，就是另一个方案有利了。

 

map仅使定义成变量, 内部也是有new的东西的, 所以必须走析构函数的流程. 但是要特别注意一个, 作为接口

的抽象类必须有虚析构函数, 否则一切都不会解放.
以下例子就内存露了:
struct A{ virtual void run() = 0; };   struct B: public A{ void run(){}; map<long, long>

map_test; };
A* pa = new B();
delete pa;
结果B的map没有析构, 被内存露了.

 

使用VS2005开发MFC程序，在给一空间添加事件处理函数时，弹出一个错误提示对话框，说：无法执行添加/移除操作，因为代码元素 "CMyClss "是只读的
解答：把你已经打开的.CPP   .h文件先关掉，然后再添加

 

二代学金融，操纵牛与熊；屌丝学金融，体会啥叫穷。二代学新闻，政府发言人；屌丝学新闻，熬夜累死人。二代学金工，回家当股东；屌丝学金工，怒喝西北风。二代程序员，除非是脑残；屌丝程序员，死时趴键盘。二代学会计，操纵GDP；屌丝学会计，按烂计算器。

 

测试先行!!!   做什么前先想好需要什么, 要测试什么, 能怎么测试. 然后才是具体需求的开发.