一、能力背景 近年来，国家在医疗挂号、APP注册、快递收寄、客运、运营商等多领域规定，需要用户实名才可办理业务，预计后续也会有越来越多的此类法规。因此，微信参照公安部“互联网+”可信身份认证服务平台标准，依托腾讯公司及微信的生物识别技术，建立微信“实名实人信息校验能力” ，即通过人脸识别+权威源比对，校验用户实名信息和本人操作（简称微信人脸核身）。 目前接口限定主体及行业类目开放公测，提供给资质符合要求的业务方，在合适的业务场景内使用。目前仅支持持二代身份证的大陆居民。 由于人脸核身功能涉及到用户的敏感、隐私信息，因此调用此接口的小程序，需要满足一定的条件。即：小程序的主体以及类目，需要在限定的类目范围内，且与小程序的业务场景一致。开展的业务也需要是国家相关法规、政策规定的需要“实名办理”的相关业务（其他未在范围内的业务，则暂不支持）。 以下为接口接入及开发的详细内容。如开发中遇到任何疑问，可以点击此处通过社区反馈，将有工作人员跟进回复。 文档第四部分【再次获取核验结果api】，有助于提高业务方安全性，请务必接入！ 现阶段微信人脸核验能力，针对小程序，开放的主体类目范围包含： 小程序一级类目 小程序二级类目 小程序三级类目 使用人脸核验接口所需资质 物流服务 收件/派件 / 《快递业务经营许可证》 物流服务 货物运输 / 《道路运输经营许可证》（经营范围需含网络货运） 教育 学历教育（学校） / （2选1）：1、公立学校：由教育行政部门出具的审批设立证明 或 《事业单位法人证书》；2、私立学校：《民办学校办学许可证》与《民办非企业单位登记证书》 医疗 公立医疗机构 / 《医疗机构执业许可证》与《事业单位法人证书》 医疗 互联网医院 / 仅支持公立医疗机构互联网医院（2选1）：1、卫生健康部门的《设置医疗机构批准书》；2、 《医疗机构执业许可证》（范围均需含“互联网诊疗”或名称含“互联网医院”等相关内容 医疗服务 三级私立医疗机构 / 仅支持三级以上私立医疗机构，提供《医疗机构执业许可证》、《营业执照》及《医院等级证书》 政务民生 所有二级类目 / 仅支持政府/事业单位，提供《组织机构代码证》或《统一社会信用代码证》。 金融业 银行 / （2选1）：1、《金融许可证》； 2、《金融机构许可证》。 金融业 信托 / （2选1）：1、《金融许可证》； 2、《金融机构许可证》。 金融业 公募基金 / （4选1）：1、《经营证券期货业务许可证》且业务范围必须包含“基金”；2、《基金托管业务许可证》； 3、《基金销售业务资格证书》；4、《基金管理资格证书》。 金融业 证券/期货 / 《经营证券期货业务许可证》 金融业 保险 / （8选1）：1、《保险公司法人许可证》；2、《经营保险业务许可证》；3、《保险营销服务许可证》；4、《保险中介许可证》；5、《经营保险经纪业务许可证》；6、《经营保险公估业务许可证》或《经营保险公估业务备案》；7、《经营保险资产管理业务许可证》 ；8、《保险兼业代理业务许可证》。 金融业 消费金融 / 银监会核准开业的审批文件与《金融许可证》与《营业执照》。 金融业 非金融机构自营小额贷款 / 仅支持省金融办监管的网络小贷主体，同时提供：1、《小额贷款公司经营许可证》或《小额贷款机构经营许可证》或省金融办批准文件；2、申请主体资质承诺函。 金融业 汽车金融/金融租赁 / 仅支持汽车金融/金融租赁主体，同时提供：1、《营业执照》（公司名称包含“汽车金融” /“金融租赁”；营业范围包含“汽车金融”/“金融租赁”业务）；2、《金融许可证》或银保监会及其派出机构颁发的开业核准批复文件。 交通服务 网约车 快车/专车/其他网约车 （自营性网约车）提供《网络预约出租汽车经营许可证》。（网约车平台）提供与网约车公司的合作协议以及合作网约车公司的《网络预约出租汽车经营许可证》。 交通服务 航司服务 / 提供《公共航空运输企业经营许可证》 交通服务 机场服务 / 提供《民用机场使用许可证》或《运输机场使用许可证》 交通服务 公交/地铁 / 提供公交/地铁/交通卡公司《营业执照》 交通服务 水运 / （船企）提供《水路运输许可证》。（港口）提供《港口经营许可证》 交通服务 骑车 / 仅支持共享单车，提供共享单车公司《营业执照》 交通服务 火车/高铁/动车 / 仅支持铁路局/公司官方，提供铁路局/公司《营业执照》 交通服务 长途汽车 / （2选1）：1、《道路运输经营许可证》（经营范围需含客运）；2、官方指定联网售票平台（授权或协议或公开可查询文件）。 交通服务 租车 / 运营公司提供《备案证明》与对应公司《营业执照》，且营业执照中包含汽车租赁业务 交通服务 高速服务 / 仅支持ETC发行业务，（2选1）：1、事业单位主体，需提供《事业单位法人证书》；2、官方指定的发行单位（一发单位），需提供“官方授权或协议，或公开可查询的文件”； 生活服务 生活缴费 / （供电类）提供《电力业务许可证》与《营业执照》，且《营业执照》且经营范围含供电。（燃气类）提供《燃气经营许可证》与《营业执照》，且《营业执照》且经营范围含供气。（供水类）提供《卫生许可证》与《营业执照》。（供热类）提供《供热经营许可证》与《营业执照》，且《营业执照》且经营范围含供热。 IT科技 基础电信运营商 / （2选1）：1、基础电信运营商：提供《基础电信业务经营许可证》；2、运营商分/子公司：提供营业执照（含相关业务范围）。 IT科技 转售移动通信 / 仅支持虚拟运营商，提供《增值电信业务许可证》（业务种类需含通过转售方式提供移动通信业务） 旅游服务 住宿服务 / 仅支持酒店，提供《酒店业特种行业经营许可证》 旅游服务 旅游管理单位 / 仅支持政府/事业单位，提供《组织机构代码证》或《统一社会信用代码证》 商业服务 公证 / 仅支持公证处，提供《公证处执业许可证》或《事业单位法人证书》 社交 直播 / （2选1）：1、《信息网络传播视听节目许可证》；2、《网络文化经营许可证》(经营范围含网络表演）。 如对以上类目或资质有疑问，可点击参考小程序“非个人主体开放的服务类目”，详细了解小程序开放的服务类目及对应资质。 二、准备接入 （请在小程序发布后，再提交人脸核身接口申请） 满足第一节中描述的类目和主体的小程序，可申请微信人脸核验接口。目前微信人脸核身接口已改为线上自助申请方式，需按照如下图例指引，进行接口申请： 第一步：请通过mp.weixin.qq.com登录小程序账号在后台“功能-人脸核身”的路径，点击开通按钮—— [图片] 第二步：仔细查阅《人脸识别身份信息验证服务条款》后，点击“同意并下一步”—— [图片] 第三步：请正确填写服务信息，并上传该小程序类目下所要求的资质—— [图片] 第四步：请按照业务实际需求填写使用人脸接口的场景和用途—— [图片] 第五步：请完善测试信息和联系人—— [图片] 第六步：提交后请耐心等待1-3个工作日的审核期，审核结果将以站内信通知—— 如申请期间遇到问题，可联系腾讯工作邮箱 wx_city@tencent.com，将会有相关工作人员进一步指引。 三、接口文档： (一)接口描述 名称: wx.startFacialRecognitionVerify(OBJECT) 功能：请求进行基于生物识别的人脸核身 验证方式：在线验证 兼容版本： 一闪：android 微信7.0.22以上版本, iOS 微信7.0.18以上版本 建议在微信官网升级至最新版本 (二)参数说明 1、OBJECT参数说明： 参数 类型 必填 说明 name String 是 姓名 idCardNumber String 是 身份证号码 success Function 否 调用成功回调 fail Function 否 调用失败回调 complete Function 是 调用完成回调（成功或失败都会回调） 2、CALLBACK返回参数 参数 类型 说明 errMsg String 错误信息 errCode Number 错误码 verifyResult String 本次认证结果凭据，第三方可以选择根据这个凭据获取相关信息 注 1：传递用户姓名和身份证有两种方式 业务方没有用户实名信息，用户需要在前端填写身份证和姓名，那么前端直接通过jsapi 调用传递 name 和 idCardNumber。 业务方已经有用户实名信息，后台通过微信提供的 api（详情见文档后面“上传姓名身份证后台 api”）上传用户身份证姓名和身份证，api 返回 user_id_key 作为凭证传给前端，前端再调用 jsapi，用户姓名、身份证信息不需要经过前端，参数只需要传递 userIdKey。Tips：使用该功能需要小程序基础库版本号>=1.9.3。 3、回调结果说明 回调结果请参考以下释义： [图片] [图片] [图片] 4、示例代码 [图片] [图片] (三)上传用户姓名身份证的后台api 1、API说明 1.1说明 业务方上传用户姓名和身份证，获取用户凭证，把凭证给到前端通过 jsapi 调用。 Tips ：使用该功能需要小程序基础库版本号>=1.9.3。 1.2请求URL https://api.weixin.qq.com/cityservice/face/identify/getuseridkey?access_token={ac cess_token} 1.3请求方式 POST 2、请求数据格式 [代码]Json { "name" : “张三”, "id_card_number" : "452122xxxxxxx43215" } [代码] 请求示例 [代码]#!/bin/bash TOKEN='xxxxxxxxxxxx' URL='https://api.weixin.qq.com/cityservice/face/identify/getuseridkey' JSON='{ "name": "张三", "id_card_number": "452344xxxxxxxxxxxxx234"}' curl "${URL}?access_token=${TOKEN}" -d "${JSON}" [代码] 参数说明 json 字段 中文显示 是否必传 name 姓名 是 id_card_number 身份证号码 是 out_seq_no 业务方唯一流水号 否 3、返回数据 参数 类 型 说明 errcode int 错误码 errmsg string 错误信息 user_id_key string 用于后台交互表示用户姓名、身份证的凭证 expires_in uint32 user_id_key 有效期，过期需重新获取 [代码]{ "errcode" : 0, "errmsg" : "ok", "user_id_key" : "id_key_xxxx", "expires_in": 3600 } [代码] 4、后台消息推送 如果业务方传入out_seq_no，核身完成后会通过消息推送回调给业务方的服务器，如果回调业务方失败，会在5s尽力推送，超过5s不再推送。 参数说明 参数 类 型 说明 ToUserName string 小程序原始ID FromUserName string 事件消息openid CreateTime uint32 消息推送时间 MsgType string 消息类型 Event string 事件类型 openid string 核身用户的openid out_seq_no string 业务方唯一流水号 verify_result string 核身返回的加密key（凭据） 返回示例 [代码]{ "ToUserName": "gh_81fxxxxxxxx", "FromUserName": "oRRn15NUibBxxxxxxxxx", "CreateTime": 1703657835, "MsgType": "event", "Event": "face_identify", "openid": "oRRn15NUibBxxxxxxxxx", "out_seq_no": "test1234", "verify_result": "XXIzTtMqCxwOaawoE91-VNGAC3v1j9MP-5fZJxv0fYT4aGezzvYlUb-n6RWQa7XeJpQo0teKj8mGE4ZcRe1JI3GqzADBYORBu613rKjKAFfEXTXw_bu1bs7MnmPOpguS" } [代码] 四、再次获取核验结果api 此接口是前端完成人脸核身后，基于前端返回的凭据，通过后台api再次进行核验结果和身份信息的校验，有助于提高安全性，请务必接入！ 前端获取结果不可信，存在被篡改的风险，为了保障请求结果安全性，请务必对identify_ret、id_card_number_md5、name_utf8_md5字段进行校验！ (一)API说明 1、说明 人脸核身之后，开发者可以根据jsapi返回的verify_result向后台拉取当次认证的结果信息。 2、请求URL https://api.weixin.qq.com/cityservice/face/identify/getinfo?access_token={access_token} 3、请求方式 POST 4、请求格式 json (二)请求数据说明 1、请求 参数 类型 是否必填 描述 verify_result String 是 jsapi返回的加密key（凭据） 2、数据返回 HTTP 头如下 Date: Mon, 06 Feb 2017 08:12:58 GMT Content-Type: application/json; encoding=utf-8 Content-Length: 85 Connection: close json示例 [代码]{ "errcode" : 0, [代码] [代码]"errmsg" : "ok", "identify_ret" : 0, "identify_time" : 1486350357 "validate_data": "8593" [代码] [图片] (三)返回参数说明 1、返回参数 注：errcode和identify_ret同时为0，代表本次认证成功。 参数 类型 描述 errcode int 错误码, 0表示本次api调用成功 errmsg string 本次api调用的错误信息 identify_ret int 人脸核身最终认证结果 identify_time uint32 认证时间 validate_data string 用户读的数字（如是读数字） openid string 用户openid user_id_key string 用于后台交互表示用户姓名、身份证的凭证 finish_time uint32 认证结束时间 id_card_number_md5 string 身份证号的md5（最后一位X为大写） name_utf8_md5 string 姓名MD5 2、错误码对应信息 errcode 备注 84001 非法identity_id 84002 用户信息过期 84003 用户信息不存在 五、小程序辅助接口：检查设备是否支持人脸检测 1、接口名称 接 口 ：wx.checkIsSupportFacialRecognition(OBJECT) 功能：检查设备是否支持人脸检测 2、接口说明和使用 小程序调用该接口，可以检测当前手机设备是否具备支持人脸检测的能力，可与以上接口分开使用，为了用户体验，建议调用后对手机设备不支持的用户做对应功能处理。 3、接口说明和使用 01 OBJECT 参数说明： 参数 类型 是否必填 描述 success Function 否 调用成功回调 fail Function 否 调用失败回调 complete Function 是 调用完成回调（成功或失败都会回调） checkAliveType Number 否 人脸核验的交互方式，默认读数字（见表 2） 表 2：checkAliveType 的值和对应的解释： 参数 解释 2 先检查是否可以屏幕闪烁，不可以则自动为读数字 02 CALLBACK 返回参数 参数 类型 说明 errMsg Boolean 错误信息 errCode Number 错误码 03 回调结果说明 回调类型 ErrCode 说明 sucess 0 支持人脸采集 fail 10001 不支持人脸采集：设备没有前置摄像头 fail 10002 不支持人脸采集：没有下载到必要模型 fail 10003 不支持人脸采集：后台控制不支持 回调结果说明仅对Android生效，iOS不返回errcode。 04 示例代码 [图片] 六、安全性说明 为保障业务可用性以及安全性，请详细研读微信人脸核身接口相关基础说明及安全说明文档：https://docs.qq.com/doc/DTFB0YWFIdGV6amly 备注：如开发中遇到任何疑问，可以点击此处通过社区反馈，将有工作人员跟进回复。 七、案例展示及补充说明 安徽医科大学第二附属医院，微信人脸核验登录： 安徽医科大学第二附属医院，是三级甲等综合医院。其小程序为用户提供挂号、门诊费用、住院费用、检查报告、体检等医疗服务，同时也提供停车、餐饮等便民服务，是医疗小程序中完整的案例。 小程序使用了微信人脸核验能力作为登录的核验。满足医院管理要求，也满足国家对于实名就医的管理规则。 案例实现的截图效果如下： [图片] [图片] 针对近期少数小程序方面反馈的两类问题，也在本课程进行补充说明。 1、本接口的开放范围，即：可支持的主体类目，是否可以扩大？ 说明：基于本接口整体使用范围的评估、相关法规的参考、监管策略的理解执行等，暂时未立刻进行扩大开放范围的工作。 但我们会持续基于不同行业的法规、政策及监管要求等，逐一进行研究考量，以便确认如何扩大开放范围。 2、小程序如果涉及用户本人的生物特征采集，（如本人人脸照片、人脸视频），或涉及采集用户本人生物特征信息并开展人脸核验功能，则存在被驳回的情况？ 说明：近两年“人脸识别”技术在社会上掀起了热潮。人脸识别虽然作为摆脱“中间媒介”或“承载载体”的一种直接技术手段，解决了部分政务、交通、医疗、零售等证明“操作者是本人”的问题，但也因此，引入了新的更大的安全风险。 一是，虚假安全风险。 身份认证领域的安全三因素包括“我知道什么”、“我拥有什么”、“我的特征是什么”，通用的安全做法，是要双因素认证（2FA），人脸识别技术如仅凭“我的特征是什么”这一个因素，则容易被攻破或利用。表象给用户以安全的感觉，但实际并不能达到安全效果。 二是，信息泄漏的风险。 越来越多的组织或个人，在并非必需用户敏感信息、生物特征的情况下，采集并存储此类信息。在信息加密、传输、存储过程中，容易暴漏更多的网络节点，使得此类信息有更大的风险被网络黑客拦截、窃听、窃取，或直接被脱库。 三是，消除风险的难度大。 以往基于“中间媒介”或“承载载体”的方式，如出现丢失、被冒用、恶意盗用等风险，可以通过挂失、更换、使用新载体或新媒介等方式，快速排除一定的风险。C端主动，B端主动，都能解决一部分问题。但人脸识别做为更直接的方式，一旦出现冒用、盗用，受害者将面临更大的财产及人生安全风险，且C端用户更多时候无法主动消除风险。 基于以上问题风险，加之国家出台《网络安全法》、《用户隐私保护条例》等法律法规标准，网信办、公安部、工信部及市场监管总局等四部委发起的app获取隐私整治，结合平台安全、用户敏感隐私信息保护要求及监管，针对部分暂无相关法规或要求，需要采集或生物认证方式进行身份核验的，或以“追热点”或“尝鲜”为目的，采集用户生物特征或进行身份核验的，进行严格审核，必要时不予以支持。

第三方服务商按月按提审表现分配提审限额（quota）的机制上线以来，服务商对提审质量的重视度不断上升，大盘提审合格率也不断提升。为了保障服务商提审效率，携手与服务商共同发展，平台近期将完善quota机制，更科学合理地分配服务商提审额度。 一、提审限额分配机制优化 服务商表现排名，会综合服务商的以下表现进行评价。同时平台考察服务商表现维度更全面（11月在服务商助手小程序的“表现与权益”专区上线） 月quota分配优化前：月quota基于近3月提审单数、服务商表现排名分配月quota分配优化后：月quota基于近6月提审单数、服务商表现排名分配新服务商支持：新第三方服务商每月最少可获得50个quota。*新第三方服务商定义：自上线之日起一年内称之为新第三方服务商 安全：提审质量、线上违规情况、低风险小程序数量、高风险小程序数量等 规模：授权小程序个数、主体个数、月新增小程序个数等 活跃：高活跃小程序个数及占比、不活跃小程序个数及占比 支付：支付金额、笔数、支付活跃小程序个数及占比 体验：体验差小程序个数及占比 [图片] 二、quota自助调额范围优化： 优化前：服务商每次申请临时额度为月初分配提审额度的15%优化后：月初分配的quota作为调额范围的划分标准，具体调整范围如下图：[图片] 特别注意： 服务商在可选范围内按需求自助调额，自助调整次数以及调额范围将基于提审合格率、quota消耗率等服务商表现分配，分配规则如下： 自然年内若存在超过三个月（不含）提审合格率低于80%，将无法申请临时调额quota消耗率作为第三方服务商画像分值的一个重要参考项，请按需进行quota调额申请，若quota消耗率存在超过三个月（不含）低于60%，服务商的画像分值排序将会降低，影响后续审核的优先级以及quota等权益分配。quota消耗率指当月quota使用值/（当月quota分配值+临时申请quota总值）*100% [图片] 平台将持续为服务商提供高效快捷审核服务，若因业务发展等情况存在超额提审需求的服务商还可以通过“小程序服务商助手-我的-咨询反馈”联系人工客服进行申请更多临时额度，客服工作时间：工作日：9:00-12:00,14:00-18:00，特殊时期以平台公告为准。 临时额度人工申请周期为1-3天，请服务商提前规划好提审额度的需求。 微信开放平台运营团队 2020.11.4

项目说明 原生微信小程序全局状态管理工具，轻量，便捷，高性能，响应式。 npm链接 ：https://www.npmjs.com/package/@savage181855/mini-store 安装 [代码]npm i @savage181855/mini-store -S [代码] 快速入门 在[代码]app.js[代码]文件调用全局 api，这一步是必须的！！！ [代码]import { proxyPage, proxyComponent } from "@savage181855/mini-store"; // 代理页面，让页面可以使用状态管理工具 proxyPage(); // 代理页面，让组件可以使用状态管理工具 proxyComponent(); // 这样子就结束了，很简单 [代码] 定义[代码]store.js[代码]文件，模块化管理 [代码]import { defineStore } from "@savage181855/mini-store"; const useStore = defineStore({ state: { count: 0, }, actions: { increment() { this.count++; }, }, }); export default useStore; [代码] [代码]indexA.js[代码]页面 [代码]// 导入定义的 useStore import useStore from "../../store/store"; Page({ // 注意：这里使用 useStore 即可，可以在this.data.store 访问 store useStoreRef: useStore, // 表示需要使用的全局状态，会自动挂载在到当前data里面，自带响应式 mapState: ["count"], // 表示想要映射的全局actions，可以直接在当前页面调用 ，例如：this.increment() mapActions: ["increment"], watch: { count(oldValue, value) { // 可以访问当前页面的实例 this console.debug(this); console.debug(oldValue, value, "count change"); }, }, onIncrement1() { // 不推荐 this.data.store.count++; }, onIncrement2() { this.data.store.patch({ count: this.data.store.count + 1, }); }, onIncrement3() { this.data.store.patch((store) => { store.count++; }); }, onIncrement4() { this.data.store.increment(); }, }); [代码] [代码]indexA.wxml[代码] [代码]<view> <view>indexA</view> <view>{{count}}</view> <button type="primary" bindtap="increment">+1</button> <button type="primary" bindtap="onIncrement1">+1</button> <button type="primary" bindtap="onIncrement2">+1</button> <button type="primary" bindtap="onIncrement3">+1</button> <button type="primary" bindtap="onIncrement4">+1</button> </view> [代码] [代码]indexB.js[代码]页面 [代码]// 导入定义的 useStore import useStore from "../xxxx/store.js"; Page({ // 注意：这里使用 useStore 即可，可以在 this.data.store 访问 store useStoreRef: useStore, // 表示需要使用的全局状态，会自动挂载在到当前data里面，自带响应式 mapState: ["count"], }); [代码] [代码]indexB.wxml[代码] [代码]<view> <view>indexB</view> <view>{{count}}</view> </view> [代码] 全局混入 [代码]app.js[代码]文件 [代码]import { proxyPage, proxyComponent } from "@savage181855/mini-store"; // 这里的配置可以跟页面的配置一样，但是有一些规则 // 'onShow', 'onReady', 'onHide', 'onUnload', 'onPullDownRefresh', 'onReachBottom', // 'onPageScroll', 'onResize', 'onTabItemTap'等方法，全局的和页面会合并，其余的方法，页面会覆盖全局的。 proxyPage({ onLoad() { console.debug("global onLoad"); }, onReady() { console.debug("global onReady"); }, onShow() { console.debug("global onShow"); }, onShareAppMessage() { return { title: "我是标题-- 全局", }; }, }); // 这里的配置可以跟组件的配置一样，但是有一些规则 // 'created','ready','moved','error','lifetimes.created','lifetimes.ready', // 'lifetimes.moved','lifetimes.error','pageLifetimes.show','pageLifetimes.hide', // 'pageLifetimes.resize'等方法，全局的和组件会合并，其余的方法，组件会覆盖全局的。 proxyComponent({ lifetimes: { created() { console.debug("global lifetimes.created"); }, }, }); [代码] 代码片段 https://developers.weixin.qq.com/s/ZO0SX2mr7xDj

嗨！大家好，我是小蚂蚁。 终于要写第三篇教程了，中间拖的时间有点儿长，以至于我的好几位学员等不及已经自己做出来了。这是一件让我感到非常高兴的事情。一位学员从零基础开始学，到最后有一定的能力自己琢磨着把游戏做出来，这是一件不论是对学员来讲，还是对我来讲都是值得骄傲的事情。因为他们已经掌握了自己学习和前进的方法，我认为这种自发的能动性是推动一个人自主学习或者前进的最强大的动力。 好了，接下来让我们来看一下这一节将要学习的内容。 [图片] 如图，在之前的基础上我们要实现将拾取的牌放到下面的插槽中，插槽中如果有三张同样的牌，则将她们消除掉，在这个过程中我们还要根据当前要插入的牌，对其它牌进行位置调整，除此之外，在消除后，也要对插槽中的牌重新进行位置调整。 理论部分 老规矩，我们先来一起搞定理论部分。 [图片] 如图，还是先进行一下数据抽象，每个不同类型的卡牌都可以使用一个数字代替，整个卡槽中的 7 张卡牌，其实就等同于下方的 7 个数字。 接着，我们来看一下将卡牌插入卡槽的几种情况。 第一种情况，如果当前卡槽中没有与它相同的卡牌，那么就可以将这张卡牌放到队伍的最后。 [图片] 第二种情况，如果当前卡槽中有一张与它相同的牌，那么就将这张相同牌的后面的所有的牌（这里只有牌 3）向后移动一个位置，然后把它插入到让出的这个位置上。 [图片] 第三种情况，如果当前卡槽中有两张与它相同的牌，那么就将最后一张相同的牌的后面的所有牌（这里有牌 3 和 牌 1）向后移动一个位置，然后把它插入到让出的这个位置上。 [图片] 这就是这个游戏中可能出现的三种插牌情况了。如何实现一张牌的插入，以及其它的牌的位置调整呢？ [图片] 假设当前卡槽中有四张牌[5,5,3,1]，现在要往里再插入一张“牌5”，整个过程是这样的：依次检查每个位置的牌，如果发现这个位置的牌跟要插入的牌一样，就记录一下这个位置，否则的话则跳过继续检查下一个，直到检查完所有卡槽中的牌为止。 这个过程结束后，那个“标记位置”记录的就是最后一张跟插入卡牌相同的牌的位置，有了这个“标记位置”就相当于我们知道了这张牌要插在哪里了，其实就是“标记位置 + 1”的那个位置上。 那剩余其它牌的位置如何调整呢？只需要判断剩余的牌的位置是否大于“标记位置”，如果大于的话，就将自己的位置增加 1，看起来就像是这样。 [图片] 这就是卡牌的插入和位置调整了，接着我们再来看一下如何判断是否需要消除，其实非常简单，看到这里你应该也能想到的，只需要判断这一串数字里是否有 3 个相邻又相同的数字，有的话，就满足消除条件。 [图片] 如图，就是针对于 5 张卡牌的检查过程，从前往后，依次的取出一张牌，然后看看它后面有没有两张跟它一样的牌，有的话就满足消除条件，没有的话，就接着去检查下一张牌，继续这个过程，直到检查完卡槽中的所有牌。 其实在上图的例子中，我们只需要检查完前三张就可以了，因为到这里就能够判断出当前满足消除条件了，在这个游戏中不可能出现同时满足两个三消的情况，所以第三张牌之后就不需要检查了。 在完成了消除之后，还需要针对剩余的卡牌进行一次位置的调整，根据我们之前讲过的位置调整，想一下消除之后的调整应该怎么处理呢？ [图片] 在进行消除的检查时，我们可以做一个记录，记录就是排在最后面的那一张要消除的牌的位置，有了这个“标记位置”，剩余的牌只需要判断自己的位置是否大于这个“标记位置”，如果大于的话，就将自己向前移动三个位置即可。 实践部分 好了，以上就是所有的理论基础了，接下来，我们就到微信小游戏制作工具中实现一下吧！ [图片] 如图，这里我新增了两个资源，一个是“卡牌槽”用于在下面放置卡牌，另一个是“插槽卡牌”，这个精灵用作卡牌槽中的牌，它跟我们之前创建的“卡牌”精灵类似的地方是，都有 10 个小动物头像造型，而且造型的顺序也都是一样的（为什么要再去创建一个这样的“插槽卡牌”呢？我们稍后会解释）。 [图片] 接着，来看一下新增的几个全局变量。 [图片] 当前卡牌的插入位置：记录新来的牌要插入的位置。 当前卡牌的消除位置：记录最后的那一张要消除的牌的位置。 当前拾取的卡牌类型：记录当前从上方拾取的卡牌的类型。 是否可操作：用于判断是否可操作，在牌进行插入或者消除的过程中，玩家是不能够去操作其它牌的。 需要消除出的卡牌类型：满足消除条件的卡牌的类型。 除此之外，我们还创建了一个新的列表。 插槽牌的类型列表：卡牌槽中的卡牌的类型列表。 除了变量之外，我们还新建了几个通知。 [图片] 几个通知的内容直接根据字面意思理解即可。 接下来，我们来看积木逻辑，首先从上方的要拾取的卡牌开始，先来看“卡牌”精灵上的拾取逻辑。 [图片] 图中红线框出的就是我们在之前的基础上新增的积木块，图中已经有了详细的解释，这里就不再赘述了。 上方卡牌拾取完后，接着看这个被克隆出来的“插槽卡牌”。 先在“插槽卡牌”上创建几个新的局部变量。 [图片] 位置：记录自己当前在卡牌槽中的位置。 类型：记录自己的卡牌类型。 迭代：在循环中用到。 标记位置：记录卡槽中跟自己一样的牌的位置。 是否是新牌：记录自己是否是新牌，刚拾取还没有进入到卡槽中的牌是新牌，进入卡槽之后就不再是新牌。 然后看一下“插槽卡牌”上的克隆积木逻辑。 [图片] [图片] 其中的逻辑循环就是我们在理论中讲到的检查过程，可以对照着之前的图好好的理解一下。 在新卡牌插入卡槽之前，向卡槽中的其它的牌发送了一个调整位置的通知，接着，我们继续来看一下卡槽中的其它的牌是如何调整自己的位置的。 [图片] “当前卡牌的插入位置”这个变量中记录的是新牌插入的位置，卡牌的调整就是将大于等于这个位置的旧牌，全部向后移动一个位置，以此来为新牌腾出一个空位。 新牌被插入卡槽之后，再来看一下消除的计算和处理。我把消除计算的逻辑放在了“卡牌槽”上，来看一下“卡牌槽”这个精灵上。 首先，还是需要创建几个局部变量。 [图片] 迭代1/2: 用于循环遍历。 比对类型：当前检查的卡牌类型。 匹配数量：当前检查的卡牌类型匹配的数量。 接着，来看一下消除计算的积木逻辑。 [图片] [图片] 其中，较难以理解的一个是关于消除的遍历检查，这里用了双重的循环，另一个是关于“标记位置”的设置，为什么“当前卡牌的消除位置”设置的是“迭代2”呢？如果你觉得难以理解，我的建议是可以在纸上画出来一个卡牌队列，列举出一组数字，然后对照着你举出的例子来查看这段积木逻辑。其实，这整个过程你完全可以在一张纸上演绎出来。 最后，我们再来看一下“插槽卡牌”上的消除处理，以及消除后的剩余牌的位置调整。 [图片] 这样这个从插入到消除的功能就完成啦！至于游戏的结束和过关条件如何判断，我们把它放在了上方的“消除处理”积木逻辑的最后。判读条件很简单，如果插槽中的 7 个位置都放满了卡牌，那么游戏就结束了；如果当前的游戏中不再有剩余的牌了，即“卡牌总数”变量等于 0 ，那么就证明玩家消除掉了所有的牌，游戏过关。 最后说一下为什么要再新增加一个“插槽卡牌”，而不是把“插槽卡牌”中的逻辑都放到原来的“卡牌”中，这是一种职责的分离，游戏中的每一个精灵只需要处理自己的职责即可，“卡牌”负责的是主要是堆叠的布局和拾取，拾取之后它的职责就结束了，剩余的如何插入卡槽，如果在卡槽中进行位置调整，如何进行删除等职责将都由“插槽卡牌”来处理。 把不同的职责和功能划分开来，会方便我们做计划或者开发，因为每一部分都只负责处理自己份内的事情，所以你在实现这部分功能的时候，就可以更专注啦！ 最后，我们再预览一下整个游戏吧！ [图片] 这个是教程中示例的小程序码，可以识别体验一下。 [图片] 到这里肯定会有人问了，如何获取示例呀？答案是没有示例的获取方法，如果你想找的是一份类似“羊了个羊”游戏的源码，那么网上已经有开源的源码了，可以自己去搜索。如果你想要的是学习自己动手做一个这样的游戏，那么相信我，最好的方式就是你真的自己动手做一个。 只有你自己动手做出来的游戏才是真正属于你的，否则的话，即使游戏在你手里，它也不属于你。 --- 欢迎关注我的微信公众号【小蚂蚁教你做游戏】，每天学点儿游戏开发知识。 [图片] 也欢迎加小蚂蚁微信(xiaomayi6669)，交个朋友。 [图片] 这里是小蚂蚁的小游戏系列，闲暇之余希望能给你带来片刻的放松和愉悦。无需下载安装，微信扫码可以直接玩啦！ [图片] [图片] [图片] [图片] [图片] [图片] [图片]