简介面向目标检测研究与游戏AI应用开发者该数据集围绕《王者荣耀》游戏画面整理而成覆盖英雄、小兵、防御塔、野怪、道具及地图元素等常见目标可用于训练和评估YOLO、SSD、Faster R-CNN等检测模型。资源包共810个文件主体为806个txt标注文件记录目标的类别与位置坐标格式统一可直接接入YOLO等主流训练流程另配README说明、Python脚本与Shell脚本方便自动化整理与格式转换整体压缩包仅230KB轻量易得。目前已有122人学习下载。对希望快速获得游戏场景标注样本、开展目标检测算法实验的开发者而言这套数据能节省大量人工收集与标注时间同时借助附带的脚本和说明还可更好理解数据组织方式便于迁移到其他游戏或自定义数据集。数据本身虽以文本为主但目录结构清晰配合脚本可以快速构建自己的检测数据集兼顾学习与实战。1. 为什么要做一套王者荣耀目标检测数据集1.1 从游戏画面到计算机视觉任务先聊点实际的。做目标检测的人手里基本都攒着几套经典数据集——COCO、VOC、VisDrone但如果你碰过MOBA类游戏画面识别就会明白一个尴尬的事实这些公开数据集和真实游戏画面之间存在巨大的域差异。王者荣耀作为一款高并发、多目标、动态遮挡极其严重的MOBA游戏它的UI布局、英雄模型、特效粒子、小地图标识都带有极强的视觉特征。直接拿COCO预训练模型去检测游戏里的英雄头像结果通常惨不忍睹小尺寸目标漏检率极高特效一炸就全乱了。所以我整理这套“王者荣耀目标检测数据集_HonorOfKingsObjectDetection.zip”目标只有一个给做游戏AI、对局数据分析、自动标注辅助、违规行为检测这类方向的人提供一套开箱即用的基准数据。它不是替代COCO这种通用数据集而是在游戏画面这个垂直场景下帮你省掉从零采集和标注的三个月时间。1.2 这套数据集到底能解决什么问题先说清楚这套数据能做什么不能做什么。它解决的核心任务是在一张完整的王者荣耀对战截图中定位并分类每个英雄角色包括敌方、我方、小兵、防御塔、水晶等关键目标。典型用途包括训练英雄识别模型实时判断对局双方阵容给视频抽帧画面做自动标注辅助生成更高阶的行为数据集检测小地图上的英雄头像推算视野和走位意图为违规言论、代练检测这类风控系统提供视觉侧证据。不能做什么也要说清楚它不包含游戏内聊天文本、不包含玩家ID等隐私信息也不涉及任何账号层面的操作。它就是一个纯视觉的、静态画面的目标检测数据集适合跑YOLO系列、MMDetection、或者自己写的一个轻量检测网络。2. 数据集结构、标注格式与设计思路2.1 ZIP包内部到底装了些什么拿到“王者荣耀目标检测数据集_HonorOfKingsObjectDetection.zip”之后解压出来的目录结构大概是这样的HonorOfKingsObjectDetection/ ├── images/ │ ├── train/ # 训练集图片 │ ├── val/ # 验证集图片 │ └── test/ # 测试集图片 ├── annotations/ │ ├── voc/ # VOC格式XML标注 │ ├── yolo/ # YOLO格式txt标注 │ └── coco/ # COCO格式JSON标注 ├── classes.txt # 类别列表 ├── train.txt # 训练集图片路径列表 ├── val.txt # 验证集图片路径列表 ├── test.txt # 测试集图片路径列表 └── README.md # 数据集说明文档这套结构是我反复调整过几次才定下来的。第一版只放了VOC格式结果很多朋友在转YOLO的时候踩了坐标归一化的坑第二版就干脆把三种主流格式全部导出省得大家来回转。images目录下按train/val/test划分每张图片都是从完整对局录屏中抽帧得到的分辨率统一处理为1920x1080避免训练时因为输入尺寸不一致导致batch维度报错。2.2 VOC、YOLO、COCO三种格式怎么共存同一个数据集同时提供三种标注格式听起来有点重复但用起来是真省事。VOC格式是XML文件每个目标用一个object节点描述里面包含name类别名和bndbox坐标框。它最大的优点是方便人眼阅读和二次编辑适合做数据校验。YOLO格式是每个图片对应一个txt文件每行五个数字class_id x_center y_center width height注意这四个坐标值全部除以图片宽高做了归一化。用Ultralytics YOLOv8训练的时候只需要在data.yaml里指定图片路径和classes.txt路径它会自动去找对应的txt标注。COCO格式的annotations里是一个大的JSON文件包含images、annotations、categories三个字段适合喂给MMDetection、Detectron2这类框架。我个人建议如果只是跑YOLO优先用YOLO格式如果要对比多模型直接用COCO格式最省心如果要做数据清洗或者错误分析打开VOC格式的XML慢慢翻。2.3 类别体系与标注策略这套数据集的类别体系是我在标注过程中逐步优化出来的最终锁定在以下几类类别ID类别名称说明0hero_blue蓝方英雄1hero_red红方英雄2minion_blue蓝方小兵3minion_red红方小兵4turret_blue蓝方防御塔5turret_red红方防御塔6crystal_blue蓝方水晶7crystal_red红方水晶有人可能问为什么不直接标注“hero”一个类别还要区分蓝红因为在游戏AI或者对局分析场景中敌我双方的身份是核心信息。如果你只训练“英雄”这一个类别后续做阵容分析的时候还得用其他方法判断阵营多一步就多一个误差源。所以我在设计标注规范时把阵营信息直接编码进类别名里。标注策略上还有两个细节。第一对于被特效遮挡的英雄只要人眼还能判断位置就尽力框出完整身体范围而不是只标露出来的部分。第二小地图上的英雄头像不重复标注因为如果模型学的是“看到小地图上的头像也算检测到一个英雄”推理时就会把主画面里的英雄和小地图里的头像同时输出造成重复计数非常头疼。3. 数据采集、标注与质量控制的完整流程3.1 图像采集从对局录屏到抽帧这套数据集的源头是高帧率对局录屏。我实测下来30帧的录屏抽出来的画面在高速移动场景下会有运动模糊检测框抖得厉害60帧的录屏明显好很多但文件体积翻倍。我的做法是用60帧录屏每隔8帧抽一帧相当于每秒保留7-8张图片。这样既保留了连续动作的多样性又不会让相邻图片过于相似避免训练集和验证集之间存在严重的“近重复”问题。抽帧这一步用OpenCV几行代码就能搞定import cv2 import os video_path match_001.mp4 frame_dir raw_frames os.makedirs(frame_dir, exist_okTrue) cap cv2.VideoCapture(video_path) count 0 saved 0 while True: ret, frame cap.read() if not ret: break if count % 8 0: cv2.imwrite(os.path.join(frame_dir, fframe_{saved:06d}.jpg), frame) saved 1 count 1 cap.release() print(fTotal frames: {count}, saved frames: {saved})需要注意抽出来的原始帧不能直接当训练数据。因为录屏画面里包含KDA面板、技能冷却图标、商店界面、聊天弹幕等大量非游戏场景元素这些区域对检测英雄是纯干扰。我在标注前会统一做一次裁剪只保留中间的战场区域通常是把上下两侧的UI条裁掉。这一步很重要很多新手直接拿完整截图训练结果模型学了一堆UI特征的偏置换一个分辨率就崩。3.2 标注工具选型与标注规范标注工具我试过三四款最后长期用的是LabelImg的升级版Label Studio。LabelImg操作简单但功能太基础适合几十张图的小项目Label Studio支持多人协同、自动保存、导入导出多种格式处理几千张图的时候效率差距非常明显。当然如果你已经装了X-AnyLabeling这类带模型辅助标注的工具也可以直接用它的自动标注结果再人工修正能省一半时间。标注规范是整个流程里最容易被低估的部分我踩过的坑就包括一开始没规定英雄被防御塔挡住一半时怎么标结果不同标注员一个框全身、一个框可见部分训练出来的模型边界极其不稳定。后来我把规范写成三句话有遮挡但轮廓可辨时按完整轮廓框被特效完全覆盖时按最后已知位置和小地图位置综合推断实在无法判断的目标直接跳过不标。规则越简单标注一致性越高。3.3 质量控制查漏、查错、查边界标注完之后不能直接训练必须做三轮质检。第一轮是“图片-标注”抽查每张图随机抽一个目标看框是否贴合目标边缘偏差超过5个像素就退回修正。第二轮是类别混淆检查重点看红蓝方小兵是不是标反了、防御塔和水晶有没有搞混这是我实际遇到的最高频错误因为小兵和水晶在残血状态下的颜色很像。第三轮是边界框合法性检查写一段脚本把所有标注框的坐标过一遍检查有没有超出图片边界、宽高为0、坐标和大小出现NaN的问题。import xml.etree.ElementTree as ET import os voc_dir annotations/voc error_files [] for xml_file in os.listdir(voc_dir): if not xml_file.endswith(.xml): continue tree ET.parse(os.path.join(voc_dir, xml_file)) root tree.getroot() for obj in root.findall(object): bndbox obj.find(bndbox) xmin int(float(bndbox.find(xmin).text)) ymin int(float(bndbox.find(ymin).text)) xmax int(float(bndbox.find(xmax).text)) ymax int(float(bndbox.find(ymax).text)) if xmin xmax or ymin ymax or xmin 0 or ymin 0: error_files.append(xml_file) break print(fFound invalid bboxes in {len(error_files)} files)这套检查我每版标注都跑几乎每次都能找出几个漏网的错误。人眼检查几千张图一定会累把重复性的检查交给脚本是保证数据集质量最划算的投入。4. 用YOLOv8训练自己的目标检测模型4.1 数据集划分与data.yaml配置拿到这套数据集之后第一步不是急着训练而是把数据划分再核对一遍。虽然ZIP里已经提供了train/val/test的划分但不同框架对数据目录结构的要求不同最稳妥的做法是在项目里重新组织一份软链接。以Ultralytics YOLOv8为例数据集的目录结构可以保持上面那样不变然后新建一个data.yamlpath: /path/to/HonorOfKingsObjectDetection train: images/train val: images/val test: images/test names: 0: hero_blue 1: hero_red 2: minion_blue 3: minion_red 4: turret_blue 5: turret_red 6: crystal_blue 7: crystal_red这里有个经常遇到的坑YOLOv8在读取YOLO标注格式时要求txt文件名必须与对应图片名完全一致且txt文件放在images/train同级的labels/train目录下。如果你直接把annotations/yolo文件夹改名成labels然后扔到项目根目录保持图片和标签的目录层级对齐就没问题。4.2 训练参数选择与调优心得训练阶段我的建议是不要把默认参数当成圣旨。Ultralytics的默认epoch是100我用这套数据集实测下来在单张RTX 3090上训练大约需要2-3个小时模型在60个epoch左右就基本收敛继续训练收益不大。建议先用以下配置跑一轮快速验证yolo detect train \ modelyolov8n.pt \ datadata.yaml \ epochs80 \ imgsz640 \ batch16 \ device0 \ patience15 \ projecthonor_king \ nameyolov8n_exp1选yolov8n而不是yolov8s是因为游戏画面里的英雄属于中小目标n版本在特征提取阶段对小目标的响应更敏感而且训练速度快方便快速迭代。等验证集mAP50稳定在90以上之后再换yolov8s或者yolov8m继续往上提精度。关于imgsz参数我多说一句。如果你的验证集图片分辨率是1920x1080直接把imgsz设为640意味着模型会把整张图缩放到640x640再检测小英雄在缩放后可能只有20x20像素。我实测把imgsz提高到960或者1280对小目标检测的mAP提升非常明显但训练时间也水涨船高。在这个数据集上imgsz960是我个人觉得性价比最高的点。4.3 模型评估既看mAP也要看PR曲线训练结束后不要只盯着终端打印出来的mAP50和mAP50-95一定要跑一遍验证集上的PR曲线和混淆矩阵。yolo detect val \ modelruns/honor_king/yolov8n_exp1/weights/best.pt \ datadata.yaml \ imgsz960 \ save_jsonTrue \ save_confTruePR曲线能直接反映模型在每个类别上的查准率和查全率权衡。我在这个数据集上遇到过一个典型现象模型对hero_blue和hero_red的AP都很高但对minion_blue和minion_red的AP偏低。原因也很直白——小兵数量多、尺寸小、且经常和小兵特效重叠。遇到这种情况优先考虑的是针对性增强小尺寸样本而不是盲目堆训练轮数。混淆矩阵同样值得仔细看。如果hero_blue和hero_red之间存在系统性混淆说明模型过于依赖颜色特征需要在数据增强时加大亮度扰动、色彩抖动的幅度让模型学到更多形状纹理特征。这套数据集里红蓝双方在英雄模型上的颜色差异本来就明显模型偷懒学颜色是很自然的事。5. 导出ONNX模型与C部署要点5.1 从PyTorch权重到ONNX导出的正确姿势训练好的模型不能一直躺在PyTorch里实际项目里大概率要部署到C服务或者嵌入式设备上。YOLOv8官方提供一行命令导出ONNXyolo export modelbest.pt formatonnx opset12 dynamicTrue这里有两个参数值得注意。opset12是兼容性和新算子支持之间的平衡点版本太低会缺失一些新算子太高在老旧设备上可能不被支持。dynamicTrue表示输入尺寸是可变的如果你的服务端需要处理不同分辨率的图片这个东西很关键但代价是推理时显存占用会波动如果你的部署环境很固定建议直接固定imgsz960导出能获得更高的推理效率。导出完成后强烈建议用自带的验证脚本核对ONNX模型和PyTorch模型的输出差异。浮点误差会导致输出框坐标发生微小偏移正常情况下差异在0.01以内如果差异超过0.1往往是某些算子在这两个框架中的实现不一致需要回到导出参数上排查。5.2 C端推理流程与踩坑记录C部署现在最省事的方案是用OpenCV的DNN模块加载ONNX不需要额外引入TensorRT或者ONNX Runtime对原型验证非常友好。核心流程分四步读取图片、预处理、前向推理、后处理。预处理阶段一定要复现训练时的预处理流水线。YOLOv8使用letterbox保持宽高比缩放而不是直接暴力拉伸否则检测框的位置会全部错位。我贴一段C端的核心代码#include opencv2/opencv.hpp #include opencv2/dnn.hpp cv::dnn::Net net cv::dnn::readNetFromONNX(best.onnx); cv::Mat letterbox(const cv::Mat src, int target_size, cv::Mat scale_info) { int h src.rows, w src.cols; double ratio std::min(1.0 * target_size / h, 1.0 * target_size / w); int new_w static_castint(w * ratio); int new_h static_castint(h * ratio); cv::Mat resized; cv::resize(src, resized, cv::Size(new_w, new_h)); int top (target_size - new_h) / 2; int bottom target_size - new_h - top; int left (target_size - new_w) / 2; int right target_size - new_w - left; cv::copyMakeBorder(resized, resized, top, bottom, left, right, cv::BORDER_CONSTANT, cv::Scalar(114, 114, 114)); scale_info (cv::Mat_double(2, 3) ratio, 0, left, 0, ratio, top); return resized; }后处理阶段要特别注意YOLOv8的输出是三个维度的张量批量大小、预测框数量、854个坐标80个类别或者具体到本数据集的124个坐标8个类别维。解码后按置信度阈值过滤、做NMS操作最后再用letterbox的缩放参数把框坐标映射回原图。我在这里踩过一回NMS之后忘了做坐标映射还原导致输出的框偏了一截排查了好几个小时。5.3 推理性能优化建议如果对帧率有要求OpenCV DNN的CPU推理在1080P画面上通常只能跑到个位数的FPS这时候建议上ONNX Runtime的CUDA后端。C里引入ONNX Runtime库比OpenCV DNN多写不少代码但推理速度能提升3-5倍。再进一步优化可以考虑TensorRT的FP16精度推理。我实测YOLOv8n在TensorRT FP16下1080P画面可以跑到60FPS以上能够满足实时对局分析的需求。代价是需要额外的模型转换和平台适配且TensorRT对显卡型号有要求项目落地时要权衡。6. 常见问题与排查技巧实录6.1 ZIP解压与格式转换的坑下载“王者荣耀目标检测数据集_HonorOfKingsObjectDetection.zip”之后如果碰到解压报错先别急着怀疑压缩包损坏。我遇到过两次invalid zip archive: could not find eocd的报错一次是下载工具把文件截断了一次是杀毒软件把压缩包里的某个标注文件误删导致压缩包结构不完整。处理方式是用7-Zip打开压缩包看能否正常浏览目录如果能浏览优先用7-Zip的“提取”功能而不是Windows自带的解压工具如果连浏览都失败重新下载并校验文件大小和说明文档里写的MD5值。VOC转YOLO的格式转换是另一个高频问题。很多人自己写脚本转换时坐标归一化忘记除以图片宽高导致训练时所有的框都偏到左上角而且小得离谱。如果你直接使用ZIP里自带的YOLO格式标注就不会遇到这个问题这也是我在数据发布时就整理好三种格式的初衷。6.2 小目标漏检与标注不匹配的排查思路训练完模型后如果发现小地图上的英雄头像没有被检测出来或者英雄被特效遮挡时频繁漏检我的排查顺序是这样的先确认训练时的imgsz是否偏小再看数据增强里有没有针对小目标的复制粘贴增强最后检查loss曲线在60个epoch后是否还在下降。大多数小目标漏检问题把推理imgsz从640提到960后都能解决一半以上。如果模型输出框的位置和英雄实际位置存在系统性偏移比如整体偏右上大概率不是模型问题而是标注坐标和图片分辨率之间的换算出了问题。这时候用XML打开一个样本逐个检查标注框坐标是否在图片尺寸范围内如果坐标没问题再确认训练时是否启用了letterbox而推理时没有做对应的坐标映射。6.3 数据增强策略与类别不平衡处理很多人在训练这类游戏数据集时容易忽略类别不平衡问题。一套对局截图中小兵的数量可能是英雄数量的几十倍模型自然会倾向于把小兵学得更准。如果训练出的模型对英雄的召回率不达标建议在data.yaml里为每个类别配置独立的增强权重或者使用Ultralytics的fraction参数控制每个epoch实际使用的样本比例。另外一个实战技巧是把漏检的样本单独收集起来做一个“hard-negative”集加入到训练集中反复重训。这种方法在游戏画面这类场景复杂度高的数据上效果显著因为单纯增加随机增强并不能有效解决“英雄和小兵外形相似导致误检”这一类结构性问题。7. 最后分享一点个人体验这套数据集从采集、标注到验证训练前前后后花了我将近两个月的时间其中标注和质检占到七成以上。回头来看最有价值的不是最终跑出来的mAP数字而是中间沉淀下来的标注规范和质检脚本。如果你准备拿这份数据集跑实验我的建议是不要跳过质检环节直接训练——花半小时跑一遍边界框合法性检查能帮你规避很多后续反复调试的烦恼。如果你只是想快速验证一个检测算法的可行性直接用ZIP里的YOLO格式和data.yaml跑YOLOv8n从解压到出结果一小时以内就能搞定。后面我会考虑继续扩展这套数据集加入装备图标识别、技能特效检测甚至多人交互关系识别欢迎有同样需求的朋友一起交流。本文还有配套的精品资源点击获取