简介
最近需要做一个辅助项目,控制一个简单的flash游戏,总共有三步:
1. 等待开始。
2. 操作,确认操作成功或失败。
3. 等待结果,重复第1步。
我到网上搜索了一些控制flash的高级方法,如获取传输数据,模仿之与服务器通信,由此代表客户端的操作。思想很简单暴力,但是由于我没有此类的经验,也没有太多时间去研究,故此放弃了此方法。又之前看到别人控制iphone的App使用图片识别的方式,而我又熟悉windows的此类API,所以决定采用图片驱动的方式。
图片驱动带来了一些问题:
1. 图片获取问题。
2. 图片识别的效率问题。
3. 图片识别的内存大小问题。甚至一些图片API的知识壁垒问题。
4. 处理变化的能力,容差问题。
系统预览
首先,循环有三步,就必然有三张图片:(1)开始状态图片,(2)操作状态图片,(3)结果状态图片。当图片匹配上当前状态时,根据状态结果进入下一个状态,当有异常时通知相关人员处理。
系统有4个模块:(1)图片处理模块,(2)动作模块(根据不同状态结果,进行不同动作),(3)状态模块(每张图片代表的状态,以及匹配的动作),(4)框架,循环引擎,根据状态调用不同的动作,及获取图片来驱动状态变化。
我根据这些模块,把各个子动作,子图片,及状态,状态循环由一个json文件描述。
```json
{
"base":"base information"
"facets":[]
"actions":[]
"states":[]
"engine":{
"states":[]
}
}
```
系统实现
由于把所有功能都变成小王国,因此考虑好具体参数,扩展参数就能轻松实现小王国了。这里就具体说一下图片处理模块,及循环引擎的实现
1. 引擎
引擎安装配置文件,不停的获取图片(由facet提供),识别图片(由facet提供),匹配图片(由facet提供),完成动作(由action提供),移动状态,及错误处理。
辅助功能:提供中途暂停(需由不同功能而定,这比较复杂,涉及上下文(context)重构),或者结束。异常处理,比如一个状态上等待时间超过阈值(valve)等。日志的打印。
我使用了一个简单方式,单独建立一个循环线程去驱动,这个线程处于无限循环中,直到外部停止或者满足跳出循环条件。
2. 图片处理
图片处理又分为图片获取,图片识别。
图片获取:Windows最简单的图片获取方式为:
(1)类似Weixin,QQ截图方式,采用Graphics.CopyFromScreen方法获取图片。然后再根据你需要图片的位置,大小copy出你需要的图片。copy出的图片一定是只有你需要的地方,而不是整个屏幕。
(2)采用Win32 API的方式。
获取Window Handle: 直接获取方式(大部分傻瓜式辅助程序):FindWindow, FindWindowEx, EnumWindows, 手动获取方式(程序员使用工具,如Spy++)WindowFromPoint
获取窗口截图:GetDC获取Draw Handle,BitBlt拷贝窗口画面(选择你需要图片的相对位置),
图片处理:如果图片比较规律,可采用特定点的颜色值来确认。如果图片文字较多,可采用OCR识别技术(需要内存,及长时间)。当然也可以采用高手自己造轮子的方式。OCR识别推荐用Tesseract。
我由于flash简单,图片规律,故采用了比较高效暴力的特定点颜色识别来确认。
结语
没有太多详细代码的东西,只是把这个简单系统写下来。一是自己梳理一遍,加深印象,排查潜在bug。二是供有缘人看一看。根据现有情况看:添加到新的浏览器很简单,在网络稳定的情况下,能够长时间稳定的运行。
由于项目原因,无法根据具体情况,来写具体代码的选择,实属无奈。
由于之前没有找到Markdown编辑器选项,导致排版失误。