然后他开始写。没有自动补全，没有语法高亮（VC6有，但很基础），没有在线文档。他完全靠记忆，把那些在2028年看来理所当然的设计，翻译成2002年能理解的代码。
第一行：
然后是类定义。他先定义了几个内核类：BattleUnit（战斗单元）、Skill（技能）、Buff（状态）、BattleField（战场）。每个类只有最简单的属性和方法声明，具体实现后面再填。
写到Skill类时，他停住了。技能系统是战斗的内核，但2028年的设计太复杂，有技能前摇、施法时间、弹道、命中判定、伤害计算、效果施加……一套下来，一个技能类可能有几十个属性和方法。在2002年的硬件上，这么重的类，实例化几百个就会卡死。
他必须简化。
他删掉了原本的设计，重新写。这次，一个技能只有五个属性：id、名称、施法时间、冷却时间、效果类型。效果类型是个枚举：直接伤害、持续伤害、治疔、控制、召唤。。控制效果只有两种：定身、沉默，持续固定时间。
简单，但够用。至少对第一个de来说，够用了。
写到Buff类时，又遇到问题。2028年的Buff系统支持多层叠加、持续时间刷新、效果合并、优先级判断。但2002年不能这么搞。他再次简化：Buff不能叠加，同类型后到的复盖先到的。持续时间用帧数计算，每帧检测是否到期。效果只有属性修正（加攻、加防、加减速）和状态附加（定身、沉默）。
他写了一个上午。到中午时，头文档写完了，大概三百行。这只是骨架，但结构清淅，职责分明。
“阿坤，来看一下。”林浩说。
阿坤走过来，站在他身后，看屏幕。他看得很慢，很仔细，有时会停下来，想几秒，然后继续。
“这个BattleField类，”阿坤指着一行代码，“用二维数组存储单元引用，查找效率是O(1)，但内存开销大。如果地图大，会爆内存。”
“地图不会大。”林浩说，“第一个de，战场就100x100格，每个格存一个指针，4字节，总共40KB，可以接受。”
“那单元移动时的碰撞检测呢？还是遍历所有单元？”
“用空间分区。把战场分成10x10的区块，每个单元只和同区块及相邻区块的单元检测碰撞。算法你熟。”
阿坤点头：“四叉树或者网格。我推荐网格，简单，2002年够用。”
“行，那你来实现。”
阿坤回到自己计算机前，开始写空间分区算法。林浩继续写源文档。
下午，他遇到了第一个大难题：事件驱动框架。
2028年的游戏引擎，事件系统是内核。玩家操作、技能释放、伤害触发、状态变化，全都是事件。事件队列、事件监听、事件派发，一套完整的发布-订阅模式。，没有函数对象，没有标准库里的function。要实现事件系统，得用函数指针，或者自己造轮子。
林浩选择了最土但最可靠的办法：用整数类型标识事件，用switch-case分发。每个事件有一个结构体，包含事件类型和一堆union字段。监听者注册回调函数，事件发生时，遍历所有监听者，调用映射的函数。
他写了两个小时，写出了事件系统的雏形。测试时，发现性能有问题：每次事件派发都要遍历所有监听者，如果监听者多，会成为瓶颈。
“用哈希表。”王磊不知什么时候站到了他身后，“事件类型做key，监听者列表做value。查找效率O(1)。”
“但2
“我有现成的。”王磊说，“以前写外挂时攒的代码库，开源链地址哈希表，经过优化，在2002年的机器上跑得飞快。”
“好，拿来用。”
王磊从他的旧硬盘里翻出代码。确实是优化过的哈希表，用了内存池、缓存行对齐、快速哈希函数。林浩集成进去，事件派发的性能提升了五倍。
晚上八点，战斗引擎的内核框架完成了。能跑，但不完整。林浩写了一个简单的测试：创建两个战斗单元，互相攻击。屏幕上，两个象素小人你一拳我一拳，血条减少，直到一个倒下。
很原始，但基础逻辑是通的。
“接下来是网络同步。”林浩说，“王磊，你的UDP可靠传输层怎么样了？”
“搞定了。”王磊说，“基于RUDP（可靠UDP），添加了前向纠错、选择性重传、流量控制。。”
“好，集成进来。”
集成网络层花了三个小时。到晚上十一点，他们终于能在两台计算机之间跑起战斗de了。一台做服务