简介这是一份面向游戏自动化与计算机视觉学习者的YOLOv5实战项目包聚焦DNF场景下的目标识别与自动操作实现适合具备一定Python基础、希望深入理解YOLOv5工程落地与游戏辅助脚本开发的中高级开发者参考。压缩包共94个文件约27.28MB以32个py源码与34个pyc编译文件为核心辅以8个yaml模型配置、2个pt权重文件、若干xml与png/jpg图像资源以及sh、dockerfile等部署脚本覆盖模型推理、图像抓取、按键模拟、方向移动与技能识别等完整模块。项目内含yolov5s至yolov5x多档模型配置、数据集转换脚本与训练工具目录结构清晰便于按检测、控制、识别三条主线拆解学习。目前已有179人学习下载读者可借此掌握YOLOv5在实时游戏画面中的检测流程、模板匹配与输入模拟的协同方式并参考其模块划分与权重文件快速复现实验环境。1. 从“识别”到“操作”DNF自动脚本到底在自动化什么很多人第一次听到“基于 YOLOv5 识别算法实现的 DNF 自动脚本”脑子里浮现的是“外挂”两个字。但把技术拆开看它本质上是一条视觉感知 → 状态判断 → 输入模拟的闭环流水线和工业质检、游戏内挂机采集在架构上并没有本质区别。YOLOv5 在这里负责的是“看”从屏幕画面里框出怪物、掉落物、NPC、血条、技能冷却图标脚本负责的是“想”和“动”根据框的位置和类别决定按哪个键、往哪走、什么时候放技能。这套方案适合谁一是想学目标检测落地、但苦于没有真实业务场景的开发者——游戏画面天然带标注、反馈快、迭代周期短是练手 YOLOv5 全流程的好素材二是做 RPA 或自动化测试的从业者想了解“视觉驱动输入”这条技术路线怎么搭。需要提前说清楚本文只讨论技术实现路径不鼓励在任何破坏游戏公平性或违反用户协议的环境中使用读者应自行判断合规边界。2. 为什么选 YOLOv5 而不是模板匹配或传统 OCR2.1 模板匹配在动态画面里的三个硬伤早期做 DNF 自动化最直觉的做法是模板匹配截一张怪物图存下来运行时用cv2.matchTemplate在屏幕里找。这个方案在固定分辨率、固定视角、怪物不动的情况下能跑但一进实战就翻车。第一怪物有行走、攻击、受击多套动画帧模板只能覆盖其中一帧换个动作就匹配不上第二技能特效、伤害数字、队友技能会大面积遮挡目标模板匹配的相似度直接掉到阈值以下第三DNF 里同一种怪物在不同地图有不同配色和缩放模板库会膨胀到几百张维护成本极高。OCR 路线则是另一个极端先文字识别再决策。但 DNF 的关键信息大多不是文字而是图标和位置关系——技能冷却是一个转圈遮罩血条是一段颜色比例掉落物是地面上的小图标。用 OCR 去读这些等于用锤子拧螺丝精度和速度都不划算。2.2 YOLOv5 在这个场景下的四个实际优势选 YOLOv5不是因为它最新最强而是它在“小目标 实时 可训练”这个三角里最平衡。具体到 DNF 场景多类别一次输出怪物、掉落、NPC、技能图标可以放在同一个模型里一次推理拿到所有框省去多次前向的开销。对小目标友好YOLOv5 的 PANet 结构对 20×20 像素左右的小图标仍有可用召回掉落物这种小目标不至于全丢。训练成本低几百张标注图、一张消费级显卡几小时就能出一个能用的基线模型迭代快。部署简单导出 ONNX 或 TorchScript 后Python 侧几行代码就能推理和输入模拟库对接顺畅。提示如果你的场景里目标特别小小于 16×16优先考虑 YOLOv5s 而不是 n并在训练时把imgsz提到 960 或 1280比换模型结构更有效。2.3 一条最小可跑的推理链路下面这段代码是整条流水线的“眼睛”负责从屏幕截图里拿到检测框。它不依赖任何游戏特定逻辑可以单独跑通验证。import cv2 import numpy as np import torch # 加载导出的 TorchScript 模型避免依赖训练时的工程目录 model torch.jit.load(dnf_yolov5s.torchscript.pt) model.eval() # 屏幕截图实际项目中用 mss 或 pyautogui这里用占位读取 frame cv2.imread(screen_sample.png) # BGR img cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) # letterbox 到 640保持长宽比灰边填充 114 h, w img.shape[:2] scale 640 / max(h, w) nh, nw int(h * scale), int(w * scale) resized cv2.resize(img, (nw, nh)) canvas np.full((640, 640, 3), 114, dtypenp.uint8) canvas[:nh, :nw] resized # 归一化 NCHW tensor torch.from_numpy(canvas).permute(2, 0, 1).float() / 255.0 tensor tensor.unsqueeze(0) with torch.no_grad(): pred model(tensor)[0] # shape: [N, 5num_classes] # 置信度过滤 NMS conf_thres, iou_thres 0.35, 0.45 pred pred[pred[:, 4] conf_thres] if pred.shape[0] 0: boxes pred[:, :4] scores pred[:, 4] keep torch.ops.torchvision.nms(boxes, scores, iou_thres) dets pred[keep] # 把框映射回原图坐标 for det in dets: x1, y1, x2, y2, conf, cls det.tolist() x1 (x1 - (640 - nw) / 2) / scale y1 (y1 - (640 - nh) / 2) / scale x2 (x2 - (640 - nw) / 2) / scale y2 (y2 - (640 - nh) / 2) / scale print(fclass{int(cls)} conf{conf:.2f} box({x1:.0f},{y1:.0f},{x2:.0f},{y2:.0f}))逻辑说明先做 letterbox 保证输入比例不变这是 YOLOv5 训练和推理一致性的前提跳过这步会导致框位置系统性偏移。conf_thres控制召回与误报的平衡DNF 场景建议从 0.35 起步怪物密集时调到 0.45 减少误框。NMS 的iou_thres用 0.45 是通用起点如果发现同一目标出多个框就降到 0.4。坐标反映射那几行是最容易写错的地方padding 偏移和 scale 必须和前面 letterbox 严格对应否则框会整体偏移几十像素。3. 从零训练一个 DNF 画面检测模型3.1 数据采集与标注的实操细节数据是这套方案里最耗人力、也最决定上限的环节。采集时不要只截“干净画面”要刻意覆盖不同地图背景、技能特效遮挡、怪物重叠、血条满/空、掉落物散落。我一般按“每类目标至少 300 个实例、场景多样性优先于数量”来定采集目标。标注用 LabelImg 或 CVAT类别命名要克制。常见做法是分四类monster、drop、npc、skill_icon。不要一上来把每种怪物单独设类那会让类别数爆炸且样本不均。先按功能分大类等基线跑通再考虑细分。标注时有两个血泪经验一是遮挡目标也要标只要人能判断出是什么就框出来模型需要学会处理遮挡二是边界框贴紧目标不要留大边距DNF 里目标密集松框会让 NMS 阶段互相抑制。3.2 数据集目录结构与 data.yaml 配置YOLOv5 对目录结构有约定照抄即可不要自创。dnf_dataset/ ├── images/ │ ├── train/ # 训练图约 80% │ └── val/ # 验证图约 20% └── labels/ ├── train/ # 与 images/train 同名 .txt └── val/对应的data.yamlpath: ./dnf_dataset train: images/train val: images/val nc: 4 names: [monster, drop, npc, skill_icon]逻辑说明path用相对路径方便整个数据集目录迁移。nc必须和 names 长度一致改类别时两处同步改否则训练时报维度错误。标签 txt 每行格式是class x_center y_center width height全部归一化到 0~1这是 YOLO 系列的硬约定用其他格式标注后要转换。3.3 训练命令与关键参数怎么调python train.py \ --img 640 \ --batch 16 \ --epochs 100 \ --data data.yaml \ --weights yolov5s.pt \ --project runs/dnf \ --name exp1 \ --cache参数说明--img 640是训练分辨率如果小目标召回差就提到 960但显存占用会翻倍--batch要相应降到 8。--weights yolov5s.pt用预训练权重做迁移比从零训练收敛快得多DNF 这种特定域数据尤其明显。--cache把图片缓存到内存小数据集能显著加速但数据集超过内存就别开。--epochs 100是起点看results.csv里 mAP 是否还在涨涨就继续平了就停。训练过程中重点看三个指标metrics/mAP_0.5看整体精度val/box_loss看定位是否收敛metrics/precision和metrics/recall的平衡。如果 recall 高但 precision 低说明误报多回去检查标注里有没有把背景误标成目标。4. 识别结果怎么变成键鼠操作4.1 状态机把检测框翻译成“该做什么”检测框本身没有意义有意义的是“怪物在我左边 200 像素”这个状态。我一般用一个轻量状态机来承接class DNFState: def __init__(self): self.target None # 当前锁定目标 self.last_action 0 # 上次动作时间戳 def decide(self, dets, frame_w, frame_h): # 优先锁定最近的 monster monsters [d for d in dets if d[cls] 0] if monsters: cx frame_w / 2 self.target min(monsters, keylambda d: abs((d[x1]d[x2])/2 - cx)) tx (self.target[x1] self.target[x2]) / 2 if tx cx - 60: return move_left elif tx cx 60: return move_right else: return attack # 没有怪物就看掉落 drops [d for d in dets if d[cls] 1] if drops: return pickup return idle逻辑说明decide只做决策不做动作动作交给输入层这样决策逻辑可以单独测试。cx ± 60是死区避免目标在中心附近时左右抖动。min(..., key...)选离屏幕中心最近的怪物比选最大的更符合“优先打眼前”的直觉。这个状态机很粗糙但它是可运行的基线先跑通再谈优化。4.2 输入模拟的节奏控制与随机化输入层用pydirectinput或pyautogui但直接调keyDown会有一个致命问题动作太规律容易被判定为脚本。常见做法是给每个动作加随机延迟和随机持续时长。import time import random import pydirectinput def do_action(action): key_map { move_left: left, move_right: right, attack: x, pickup: z, } key key_map.get(action) if not key: return # 随机持续 80~160ms模拟人手按键 hold random.uniform(0.08, 0.16) pydirectinput.keyDown(key) time.sleep(hold) pydirectinput.keyUp(key) # 动作间隔随机 50~120ms time.sleep(random.uniform(0.05, 0.12))参数说明hold范围决定移动的“步长”太短角色不动太长会冲过头80~160ms 是实测比较自然的区间。动作间隔不能省连续无间隔按键在游戏里会表现为“卡键”。随机化不是为了对抗检测而是让操作节奏更接近真人减少因固定节奏导致的动作冲突。注意输入模拟的坐标和按键映射依赖具体分辨率换分辨率必须重新标定不要硬编码一套参数到处用。5. 避坑与排查那些让脚本“看起来能跑但实际翻车”的问题5.1 检测框整体偏移几十像素现象模型在验证集上 mAP 正常但实际运行时框总是偏右下或偏左上。原因推理时的 letterbox 参数和训练时不一致或者坐标反映射公式写错。解决把推理时的预处理参数打印出来和训练配置逐项对比重点检查 padding 是(640-nw)/2还是(640-nw)这个除以 2 漏掉就会偏一半 padding。5.2 怪物一多就漏检现象单个怪物检测正常屏幕上出现 5 个以上怪物时部分怪物框消失。原因NMS 的iou_thres设太低密集目标的框互相抑制。解决把iou_thres从 0.45 提到 0.6同时把conf_thres略降先保证召回误报靠后续状态机过滤。5.3 训练 loss 下降但实际效果差现象box_loss一路降但实际跑起来框位置很飘。原因验证集和训练集场景太相似模型过拟合到特定背景。解决采集数据时按地图划分训练/验证集而不是随机划分确保验证集里有训练时没见过的地图背景。5.4 脚本跑十几分钟就“发呆”现象前几分钟正常之后角色站着不动。原因游戏窗口失去焦点截图拿到的是桌面或黑屏检测不到任何目标状态机返回 idle。解决在截图前检查窗口是否在前台用pygetwindow激活窗口同时给状态机加超时连续 N 帧无目标就触发一次“移动”打破僵局。5.5 换分辨率后全部失效现象在 1920×1080 上调好的参数换到 2560×1440 后框全错。原因所有坐标阈值、死区、按键时长都是按像素和比例硬编码的。解决把关键参数改成相对值比如死区用frame_w * 0.05而不是固定 60移动时长按分辨率比例缩放。6. 进阶把推理速度压到 30 FPS 以上的三个手段第一招是模型量化。把训练好的模型导出 ONNX 后做 INT8 量化推理速度通常能提升 1.5~2 倍精度损失在 1~2 个点以内。DNF 这种目标类别少、背景相对固定的场景量化损失完全可以接受。导出命令用export.py --weights best.pt --include onnx --halfFP16 半精度在支持 Tensor Core 的显卡上几乎无损提速。第二招是跳帧推理。不需要每帧都跑模型屏幕画面在 100ms 内的变化通常不足以改变决策。我一般每 3 帧推理一次中间帧复用上一次的检测结果配合状态机的动作持续时间实际体验没有差别但 GPU 占用直接降到三分之一。第三招是裁剪感兴趣区域。DNF 的关键信息集中在屏幕中下部上半部分大多是背景和 UI。把推理区域裁到[0.2h:0.9h, 0.1w:0.9w]输入尺寸不变的情况下等效于提高了目标像素占比小目标召回明显改善同时推理量减少。# ROI 裁剪 跳帧的组合写法 frame_count 0 last_dets [] def infer_with_skip(frame): global frame_count, last_dets frame_count 1 if frame_count % 3 ! 0: return last_dets h, w frame.shape[:2] roi frame[int(h*0.2):int(h*0.9), int(w*0.1):int(w*0.9)] dets run_yolo(roi) # 把 ROI 坐标加回偏移 for d in dets: d[x1] int(w*0.1); d[x2] int(w*0.1) d[y1] int(h*0.2); d[y2] int(h*0.2) last_dets dets return dets逻辑说明frame_count % 3控制跳帧频率3 是实测比较稳的值追求更低延迟可以改成 2。ROI 偏移必须加回否则框位置全错。这个组合在消费级显卡上把端到端延迟压到 20ms 以内是可行的。最后说一个我自己的习惯每次改完参数先在一个固定录屏上回放验证而不是直接进游戏试。录屏回放能复现、能对比、能慢放比在真实环境里靠感觉调参靠谱得多。这套方案值不值得做取决于你是想学视觉落地的完整链路还是只想快速出效果——前者值得后者有更轻的路子。希望帮到你。本文还有配套的精品资源点击获取
