MeteorCat Blog

对于国内规范化出海来说, 最推荐还是 Google 打通整套产业链处理, 主要基于以下优点 在香港设置有办事单位, 既保持与国内的连接, 又满足国际化合规要求 大量周边技术栈的成熟(Google Ads/Google Play) 广泛的用户人群, 基本上海外安卓手机都集成对应的谷歌套件 这里将从技术方面来说明和处理，首先必须要有一个 Google 开发者账号起步。 如果要打通 Google 整体链路可能要接触到以下系统: 系统 配置后台 功能 账户要求 OAuth Google Cloud Console 用户 Google 账号登录授权 个人/企业均可 GooglePlay Google Play Console 应用内购买 (IAP)，仅限虚拟商品 个人/企业均可 GooglePay Google Pay 商家中心 网页/应用外支付，收实物商品款 仅企业账户 后续将围绕 GooglePlay IAP 方式来讲解怎么接入 Google 系统完成付费转化 授权机制 应用出海接入 Google 账号体系验证即可, 在 https://console.clo ...

随着 UUID 规范的日渐成熟, 目前已经可以在应用在大量日志库上面作为 主键(PrimaryKey) 使用 之所以考虑到不采用 自增ID(AUTO_INCREMENT) 就是为了方便分布式系统/多库数据合并等场景, 但因为早期规范存在缺陷现在还有一下问题要处理: 早期 UUID(v1/v4) 版本是随机乱序生成, 配合 InnoDB 主键是聚簇索引会导致频繁页分裂和索引碎片 采用字符串存储(CHAR(36)) 空间浪费巨大, 空间多占 2~3 倍会导致索引体积暴涨 UUIDv1 依赖 MAC + 时间, 可能会导致分布式多库合并出现冲突 只有在 UUIDv7 之后才修复以上问题, 目前 MySQL和MariaDB 之类方案可能因为版本导致没办法采用有序的 UUIDv7 目前不推荐直接采用 MySQL/MariaDB 内置的 UUID 类型, 需要为了考虑到兼容性采用 BINARY(16) 用二进制保存节约空间. 那么设计的表结构可能如下处理: 1234567891011121314151617181920# 登录日志# MySQL 版本之后才有 UUID_TO_B ...

这里需要说明, 国内企业出海最好具备以下条件 可以申办下发香港银行卡: 资金都是直接入户到香港银行户头 有时间往返香港处理银行事务: 国内资金审查很严格, 资金异常会冻结账户等待企业代表申诉 可以在香港设立企业证明: 这部分并不是硬性, 不过可以的话一般都是找海外做法人企业代表 能够英语处理海外业务: 海外大部分都是采用信用卡体系, 很多时候需要以英语做工单提交退款事务和账户异常问题等 注: 这部分不含 ODI 备案, 如果要走 ODI 流程对小微企业非常麻烦, 大部分都是采用灰色 ‘个体户’ 如果以上条件都没有任一无法满足则后续不需要关注, 可以说上面都是比较硬性的条件 首先需要注册香港本地公司来财务做帐为银行提供开户方式, 主要处理业务为 “跨境电商零售” 方便香港银行开户 注: 小微企业要谨慎处理大额资金流入, 避免被识别为非法洗钱从而冻结资金(冻结之后须本人赴港申诉) 最后初步处理完成之后会获得以下内容 香港企业证书 香港银行账户 企业邮件地址 这些都是国内企业做海外跨境的基础, 必须确保这部分已经申办下来 邓白氏编码 目前申请的香港公司仅仅是作为香 ...

对接过发行系统的开发会频繁看到 数据归因 这个名词, 简单来说就是投放数据需要溯源分析从而知道获客来源多 以现实例子在抖音推广来说: (广告曝光)需要投入资金购买抖音广告位 (广告展示)需要分析展示效果和频率(这部分可有可无, 有的主要只计算点击率) (广告点击)用户看到广告之后点击推广触发下载跳转落地页等行为, 这种就是获得点击量 (安装激活)用户下载到设备安装完成, 首次启动代表整体链路激活, 这种就是设备激活量 (用户转化)用户启动之后注册/登录账号的时候, 就代表正式转化为我们的用户, 这就是用户转化量 (付费用户)如果用户正式在应用触发付费行为, 那么这就代表该用户为核心付费用户, 也就是购买广告位获得的正向收益 数据归因 所要做的就是跟踪整体链条保证让投入产出比持续健康, 保证收益 就是归因的最终目的 广告位这部分是真金白银投入的, 如果投放的渠道收益差(投入资金但收益低)就要赶快停止或者切换渠道 数据核心指标 CAC = 获取客户的成本 = Customer Acquisition Cost 计算公式: CAC = 总投放费用 ÷ 有效新增 ...

常规开发游戏初期都不需要网络处理, 部分测试开发的时候需要用授权体系来解锁功能, 针对这部分就需要前置网络授权模块 其实这种授权方式很容易被跳过, 只是作为测试的时候上报游玩数据统计而已 这种授权机制好处就是能够构建自己的游戏社区, 能够营造类似于 Steam/WeGame 这类社区来单个账号体系多个游戏共享 而且 GitHub/Bitbucket 等平台都提供规范的 OAuth 体系用于构建应用授权体系, 方便在平台发布并且授权登陆测试游玩游戏 目前 Godot 并没有类似 WebView 之类的内部浏览器渲染功能, 所以没办法直接在游戏弹出浏览器渲染, 需要比较取巧的方法 Godot 是支持 GDNative 集成 ChromiumEmbedded 内置浏览器功能; 但还是那句话, 官方直接集成否则稳定性都不好说 OAuth 授权机制的流程如下, 这里主要对象有三个, 就是 客户端/我们自己服务端/第三方平台 : 在平台创建应用, 主流基本上需要配置并且设置好以下地址: client_id: 对外公开的应用ID client_secret: 自己服务器使用的验证标识, ...

对于一些要求比较高的数据采集流程, 会采用模拟正常浏览器处理方式来避免被风控, 这种技术就是 浏览器模拟/浏览器渲染型爬虫 核心是用真实浏览器内核执行 JS、渲染页面, 完全模拟真人访问行为来绕过风控 比较老牌的就是 Python 的 Selenium 处理, 但如果采用 PHP 做底层采集框架(接口服务)就感觉没必要引入额外的开发语言 而 PHP 之中第三方也是具有这方面组件库, 也就是这篇文章的主角 php-webdriver 利用 php-webdriver 可以实现模拟玩家浏览器行为来采集数据, 并且一步到位来暴露自身 API 服务接口功能 注: 这里采用 PHP 的 Composer 来做包管理功能 环境安装 首先需要知道模拟玩家浏览器行为是需要用到底层浏览器驱动的, 目前底层浏览器驱动有以下方案: ChromeDriver: https://sites.google.com/chromium.org/driver EdgeDriver: https://developer.microsoft.com/en-us/microsoft-edge/tools/we ...

简单处理 显示设置(Display Settings) 之后就是另外 音频设置(Audio Settings) 相关 音频部分就相对来说比较简单, 游戏内部对音乐管理需求不高的话, 直接采用如下配置: 主音量(Master Volume): 全局整体游戏总音量 背景音乐(BGM Volume): 游戏当中涉及到场景/剧情等背景音乐 游戏音效(SFX Volume): 游戏当中释放技能/触发交互的弹出音乐 如果是偏剧情向(GalGame)之类, 那么需要追加人物音量(Voice Volume), 甚至要单独另开配置页面来为每个角色添加音量 音量部分都是采用 0.0~1.0 的浮点数代表百分比处理(0代表静音), 所以不会专门单独定义枚举处理, 处理也就相对显示设置简单 而 Godot 内部会用到的 API 如下所示 API 全路径 方法/属性用途 参数/返回值 核心说明 AudioServer.GetBusIndex(string busName) 通过总线名获取音频总线索引 参数：string（音频总线名，如Master/BGM/SFX）返回值：int ...

游戏当中最底层需要的就是调整系统设置, 这里列举下常见的游戏内部显示设置 如果只需要简单的显示设置, 可以按照如下这种方式设置: 这种就是标准的将所有配置简略合并成单个配置修改, 适用于简单游戏类型(无3D交互和不做手柄操作) 而相对比较复杂的显示设置, 就需要这样来设置: 这种就是相对比较复杂的, 而且会把游戏显卡游戏效果之类单独移动到游戏设置(Game Settings) 游戏设置: 双显卡切换和特效切换(高/中/低), 还有伽马值/阴影/环境光/抗锯齿/帧率上限等高级选项 这里回过头来说下应该实现的 显示设置(Display Settings), 底层用到的系统配置并且都是一次实现后续复用的功能 以最简单的设置来说, 哪怕最简单的游戏差不多多多少少需要实现以下显示设置功能 桌面模式(Display Mode): 设置游戏渲染窗口, 可以按照以下选项来切换(游戏桌面一律不运行鼠标点击拖动调整分辨率) 全屏(Fullscreen): 将界面直接拉伸填充当前主显示器, 需要知道全屏也是可以拉伸分辨率的(高分辨率屏幕设置低分辨率) 窗口化(Windowed): 将窗口默认调 ...

之前定义过 P21 项目作为示例, 这里是从 P21 项目当中扩展出来的项目工程化补充说明 工程化项目当时创建过以下目录作为项目分层: P21Game: 游戏引擎相关 P21Tests: 游戏内部测试单元 P21Utility: 内部扩展通用功能 这个篇章就是基于 P21Utility 这方面展开的, 简单说下为什么有 Utility 层 有时候项目需要用到底层工具库, 比如 Protobuf 序列化、网络、寻路算法 等仅需要纯 C# 的通用功能 这种通用功能只需要 C# 来处理成单独功能库, 那么就不适合放在对外的 P21Game 游戏引擎相关工程之中 并且基于 C# 保证脱离游戏引擎存在, 如果后面迁移到 Unity3d 之类使用 C# 平台还能复用相关代码库 把封装代码塞到 Game 层之中会让游戏工程变得臃肿, 核心游戏逻辑(UI、玩法、节点交互)被这些代码淹没导致后期找 Bug、改功能都会极其繁琐 所以 P21Utility 只做纯 C# 通用功能封装, 对外提供清晰、简洁的 API 从而让 P21Game 只需要 调用 而不用关心底层实现 对于 Ut ...