联机游戏开发有感

   这段时间弄网络游戏项目，拿java写后台，as3写前台。这几天联机调试好麻烦哦，又浪费时间。

  今天小昌同学说：“弄个GM命令，自己写消息发给客户端，就可以不连服务器。”这种类型的东西估计很多公司都有用到，以前也想到过。我们这个项目的话最简单的就是直接在前端输入要发的消息，转到网络接收函数那。

  实际上结合哈敏捷开发的话，就先定义前后端的通信协议，数据含义，构造测试数据，然后让前后台网络连通后用测试数据跑网络的消息流程。都不写实际功能，只是收到某消息后，发出对应消息。这个时候调整协议内容。这个步骤完成了的话，就可以让前后端分开开发，由外向内（网络向本机）自上而下的写功能。这个时候就要用到服务器客户端模拟器了，后面简称C/S模拟器或模拟器。简单的包含，能用网络和服务器或客户端相连，向另一端发送定制消息，手动自动有要的。这样就要方便些了，不用互相等，而且有些工作并不是真正依赖于另一端的功能，只依赖于数据。

  然后，我觉得最好把消息的顺序在c/s模拟器上随机，避免消息的顺序依赖性。这可以在很小段时间内，把要发送出去消息顺序打乱。不过现在这种模拟器只能测试本端对消息自身的处理正常与否，所以在后面完成到某个层次的时候还是要把真的两端联机调，由浅到深（测试驱动开发嘛，哈哈）。改变需求的时候，按照之前的，定义协议，构造测试数据。如果对之前的有影响也要修改之前的测试数据。同时要保证之前老得测试数据和新的测试数据都通过才继续开发。

  其实可以用模拟器作为中间层把服务器和客户端连接起来，模拟网络环境，制造网络延迟等东东。不过估计应该有专业做这种网络环境模拟的东西，别个flash player调试器都可以的。这些程序实际运行环境还是在开发初期接触的越早越好，不然等到后面游戏测试的时候再去跑，就搞不赢啰，所以别个说的测试驱动开发好啊，虽然别个只保证对测试数据的正确性，但比那些没覆盖到的测试好啊（数据流啊 哈哈，我还是比较倾向于数据流）。

  然后，为了测试的自动化，可以提升c/s模拟器的自动化程度，可以就拿脚本来处理消息的收发，甚至再高级点就和真的客户端和服务器差不多了，哈哈。其实，多扩展哈就可以弄测试机器人了。不过如果要测试客户端显示相关内容的话，测试机器人最好是在客户端内部的，和正常玩家操作一样，模拟玩家操作。应该可以测试一些显示相关内容。

  不过这种东西，最好支持热加载，如果是脚本驱动的话就热加载代码和数据。我这因为用的java嘛，然后就打算用看clojure来写个简单的模拟器，因为它的repl还是不错的，支持热加载数据和代码滴，嘿嘿。只是其他人用的时候要稍微熟悉些东西估计。我也是想通过这个来熟悉哈clojure。