舒克贝塔前台总结-SmartProject-精选（公开课件）.pptVIP

SmartTank SmartProject 如果我有时间重构： SmartProject 结语：十多天的时光过去，收获了不少的经验，同时，看到项目在全体队友的共同努力下逐渐完善，看到每个人在自己掌管的工作上的认真态度和不断追求的信念，就会觉得这些天过的格外充实，就会觉得我们是一个不可分割的集体。 舒克贝塔前台总结-SmartProject 开发者： 量子工作室DWC Asokawu 研发中心基础研发组Seekyao SmartProject 引用代码（SmartTank）： ◆ SmartProject在SmartTank2.0的代码基础上进行开发，主要目的是缩短开发周期。 ◆ SmartTank是Asoka大学时开发的项目。开发环境C# + XNA ◆ SmartTank原本的设计是为人工智能的爱好者提供一个用AI代码来玩坦克的可扩展性平台。 ◆ 它实现了一个较完善的2D图形引擎，像素级碰撞检测，视野计算，场景管理等部分。 SmartProject 设计需求 网络同步部分： 原有代码不具有网络方面的支持 实际游戏规则的编写： 原有代码提供了场景管理的模式。主要工作集中在游戏逻辑相关的部分。 主要挑战 在现有的3万行从未考虑网络问题的代码上添加网络模块。 SmartProject 前台开发进度 网络同步模块概要设计、详细设计（1天） 网络同步部分编码（3天） 前后台相连，在原有规则上调试网络部分（5天） 编写游戏规则逻辑，开发UI界面，综合调试（6天） 网络同步部分设计 原则：主机管理绝大部分场景物体的逻辑，从机管理自己控制的场景物体的逻辑。其中大量利用了C#语言的反射机制。 状态同步： 场景物体类中的任何成员都可以注册为需同步成员，并可 以定制同步频率。 事件同步： 将从机场景物体触发的事件映射到主机的对应虚物体上。 使主机的规则逻辑无需了解网络同步的内部。 物体管理同步： 完全由主机负责物体的创建和删除工作。发送相应消息通 知从机创建虚物体。 自定义信息： 类似于一个消息系统，同步模块的使用者自己决定消息的 发送和解析。 SmartProject SmartProject 第一次做同步逻辑，虽然初始想法很好，但实际用起来发现问题多多。。。 SmartProject 设计时自以为优点： 同步一个变量值只需要在这个量发生改变的位置注册一下就好，C#的反射能力可以根据变量的名称改变变量的值，完全不用关心收包后解析的过程。 实际中引发的问题： 当考虑加入插值的时候：发现原有的结构只能将对各个变量进行独立的同步，而无法将相关联的多个变量进行统一的同步处理。 到后来： 只好实现一个自定义的消息机制。致使同步逻辑在场景物体类和游戏规则类中四处遍布，异常混乱。 接着。。。 SmartProject 发现在同步物体位置的时候简单拉取主机上的位置是存在漏洞的。实际中位置的同步跟碰撞处理及物理更新组件有一定的相关性。直接拉取埋下了隐藏的危险。 由于规则类在主机和从机上均在运行，规则类中关于同步的代码越来越多，很多地方要对主机的情况和从机的情况进行分支处理。代码乱到了一种境界。。 真正把规则抽取出来，规则类不再管理游戏循环。从机上不在创建规则类的实例。 同步模块作为基础模块，在底层悄悄的进行。将物理位置的同步部分独立出来，处理好插值过程，处理好与碰撞检测及物理更新模块的关系。 在场景物体一级实现物体副本管理机制。同步过程对规则类完全透明。