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

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

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

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

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

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

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