BombRoom：一个命令行炸弹游戏
起因
去年五月份参加了一次自强内部的HackDay，有幸跟cc酱组了个小队伍。
当时提出了一个很早就有过的想法————通过命令行的方式来进行游戏。
于是乎我们就开心地做起来了，很快便碰到了问题：游戏通信如何进行？
由于当时我的技术栈里后台框架只有Django一个，于是就拿着以内容管理见长的Django做了一个游戏通信API。
虽然带着满身的BUG，但还是在当时的Hackday里拿了最佳技术奖。
然而在去年十一月打算拿出来重新完善的时候才发现，原来写的东西连一局完整的游戏都没有办法进行下来。
这使我产生了重构的想法(动不动就重构非常非常非常不明智,特别是面对别人的代码的时候)。
于是我打算用更适合简短API和并发高效的Tornado来代替原先的Django，用websocket的通信方式来代替原先的长轮询(long polling)。
由于
HTTP是无状态性的，因此在进行游戏时我们的每一步状态，每一步操作要怎么记录，怎么让后台服务器知道并计算呢。
最简单的方法是采用长轮询的方式进行通讯，顾名思义，就是规律性地去询问后台，现在情况如何了？
每隔5s或10s主动发送一次请求向后台询问游戏状态并显示在前端，是这个游戏进行的最基本的方法。
然而这时产生了新的需求：腾讯蓝鲸跟自强做了一个合作，通过对学生开放蓝鲸平台campus版，鼓励我们在上面提交作品，以此来发掘实习生。
所以我就想着把这个改好了扔上去，说不定能增加实习机会。
问题出就出在蓝鲸平台只能用Django，而Django由于用的是wsgi，所以对异步请求表现很差。不能很好地支持websocket。
架构和通信方式都不用变，那就老老实实地debug吧。
Coding
被pyc缓存坑了好久，更新的代码没有被解释，一直用的旧的pyc文件，导致玄学频现。
由于前端小哥回学校没什么时间，只好自己跑去写js，好在cc酱的代码结构清晰，所以改起来并没有什么困难。
玩
虽然还有一些小问题，但玩是可以玩了，也把修改后的版本放到了蓝鲸上面，期望会有好运吧:)
附上截图:
