MeteorCat Blog

这部分是当时面试的时候疑似遇到骗技术方案的公司提出的, 虽然那个面试体验很糟糕只想赶快结束话题避免和这种人浪费时间 不过在 Google Ads 这部分确实都快忘记了, 所以后面感觉还是有必要总结下避免后面真的要用的时候忘记怎么开发 目前 Google Ads 是支持 个人(Individual) 和 企业(Business) 两种身份做广告投放, 核心的差别就在于广告类型和权重较低 注意: 一旦锁定了身份是无法做中途切换, 所以一般推荐每个投放账号应该单独创建分开管理(账号违规被封禁避免影响其他) 这里将从 个人 身份出发, 通过推广目前自己的网站页面, 去讲解怎么一步步实现整体的广告数据归因链路功能 官方文档: https://support.google.com/google-ads/answer/6146252 数据归因主要监控以下数据 clicks: 点击次数, google ads 会为每个用户创建唯一标识, 记录唯一用户的广告点击次数 conversion rate: 广告转化率, 转化次数 ÷ 广告带来访问会话数, 衡量广告流量质量 cost per ...

这里是偏小众的发行渠道编译注入方式, 而且主要针对还是桌面平台, 这部分仅作为参考(毕竟太小众了), 目前上架桌面端常见就是以下平台 Windows: 目前比较广的桌面平台, 微软平台基本上目前市场占用率最高, 大部分情况对接该平台即可 Unix: 这部分比较多的就是 Apple 设备平台, 读取程序目录文件存在权限限制(需要注意这类情况) Linux: Linux 更多应用在服务端上, 但是桌面端也有部分受众在使用 这些平台不可避免会出现大量 碎片化 问题, 也就是采用编程语言/编译器/系统权限/跨平台技术等都没有统一规划 所以对于桌面端不推荐采用任意编程语言类库处理, 而是将需要编译注入渠道信息处理成二进制下的签名加密文件 这里推荐的签名 JSON 格式如下 lines12345678910{ // 签名文件自我的哈希数据 "hash": "", // 应用唯一标识 "app_ident": "", // 渠道信息 "channel_ident": &quo ...

如果接触过 游戏联运 和 广告变现 基本上都对 渠道分包 有一定了解, 主要核心就是应用反编译 本质上就是需要给游戏应用提供或者上传一份应用证书签名, 然后方便后台界面触发解包反编译注入对应参数之后再打包成新的渠道包 这里有以下概念需要了解 母包: 开发商输出无渠道参数的原始未签名/测试签名游戏安装包, 也就是等待被解包并重新打包 签名文件 Android: 渠道方提供正式签名 keystore(.jks/.keystore)/别名/密钥密码; 部分自研渠道使用自有统一证书 iOS: 渠道开发者证书/描述文件/推送证书 之所以需要证书, 是因为应用上架/渠道校验/支付唤起/广告 SDK 校验都强制校验签名, 母包分包后必须用新的渠道证书重新签名 反编译/解包: 利用 apktool 或者解压方式修改内部核心配置文件, 将所需参数注入进去 这部分其实更适合有经验客户端来讲解, 但是有时候部分服务端可以简单处理下自定义集成 SDK 库, 从而实现类似效果 环境搭建 java: 目前直接找到 Java11 版本即可, 版本建议 Google 最低要求并也不会太过全新 ...

环境配置 目前我习惯性的开发环境和版本按照以下处理 IDE: Rider 2026.1.3 引擎版本: Godot 4.7.1 代码管理: bitbucket 源代码地址: https://bitbucket.org/meteorgxx/p26/src/sts2-main 目前仅提取杀戮尖塔2的游戏基本骨架, 并且重写一部分功能脚本和业务逻辑 原生杀戮尖塔2当中是采用远程日志上报, 我这里采用 C# 的第三方 Serilog 日志库替代掉 不沿用原来杀戮尖塔2自定义本地化, 采用 Godot 本身的 i18n 处理全球化翻译的问题 官方采用 FMod 音频中心用于对接高级音频设计, 改写由 Godot 内部驱动(杀戮尖塔2团队才是对, 将负责音频设计和程序分离) 内部涉及到 SpineSprite 都没有去解析, 游戏大量采用业界成熟的商业化骨骼动画方案, 商业化部分不会触碰(可能涉及到法律纠纷) 调试环境 Godot 内部已经集成通用的静态方法来识别游戏处于调试环境, 推荐将其通过 C# 的静态扩展写到顶级 Node 对象之中 12345678 ...

Steam 商户: https://partner.steamgames.com 首先需要进入 Steam 商户后台, 这里建议重新用新邮件地址创建 Steam 账号, 避免私人账号影响到游戏商户账号 私人账号有时候发点擦边内容会导致触发 Steam 封禁(懂的都懂), 所以尽可能采用全新账号来专门负责上架游戏处理 目前 Steam 只需要个人角色来上架游戏(企业角色仅针对美国合规上线的企业资格), 其中你需要提供以下资料 $100.00 USD 费用: Steam Direct 费, 达到至少 $1,000.00 USD 之后会返还这笔费用 身份信息: 如果是以个人开发者性质上架的游戏, 则只需要提供法定英文姓名等信息 电话号码: 需要注意 Steam 面向全球化, 所以中国联系电话号码记得加上 86 区号开头, 比如 86131xxxxx 公司形式: 大部分公司指的是美国境内的企业公司, 所以一般填写 Sole Proprietor W-8BEN美国税务: Steam 立足美利坚来做税务处理, 所以全球上架的个人都需要填写这份表格来按照美国报税 多币 ...

这篇专题也是总结工作这么多年的对于广告投放业务的积累, 也是方便后来的开发人员做借鉴处理 首选需要明确目前国内提到的 广告 业务实际上有两种概念(很多人都被混淆起来) Marketing(投放买量): 广点通/巨量等广告平台业务, 主要负责投放平台的广告获取点击和流量转化, 本质是买量获客 Advertising(广告变现): 硬核渠道等广告展示业务, 利用应用内部的广告位展示获取对应收入, 本质是通过曝光流量变现 维度 投放买量 广告变现 资金流向 作为公司主体(我们)付费给广告平台(广点通/巨量) 不同平台下的广告主付费, 公司主体(我们)拉取点击转化用户来赚取广告分成 服务对象 拉新/促活/付费转化 商业化的流量变现 核心指标 消耗/曝光/点击/CTR/CPC/激活成本/ROI 广告填充率/eCPM/广告展示量/广告收入/LTV 对接对象 广告投放平台API 广告聚合/渠道SDK 参考平台 广点通/巨量/GoogleAds等广告平台 Vivo/Huawei/XiaoMi等应用商店(硬核渠道) 所以在很多情况下, 需要结合情况分清楚提 ...

虽然 IDEA 已经帮助配置好 Maven 相关开发环境可以直接运行, 但是在做多人开发的时候建议锁定公用的 Maven 版本 官方文档: https://maven.apache.org/tools/wrapper/index.html Maven Wrapper 用于管理 Maven 版本的工具, 可以确保所有开发者使用相同的 Maven 版本进行开发来避免 Maven 版本不同导致的兼容性问题 锁定 Maven 版本基本只有好处没有坏处, 一般项目正式工程化推荐采用这种方式处理 引入 Maven Wrapper 只需要以下文件(加入代码版本库) mvnw: Unix/Linux/macOS 脚本 mvnw.cmd: Windows 批处理脚本 .mvn/wrapper/maven-wrapper.properties: Maven Wrapper 配置文件 建议的 .gitignore 忽略文件排除掉以下文件 1.mvn/wrapper/maven-wrapper.jar 这里从现有项目出发, 直接引入 Maven Wrapper 支持, 我这边采用命令行 ...

简单聊天室的项目参考 项目文档: https://bitbucket.org/meteorgxx/nova-chat/src/main/README.md 项目代码: https://bitbucket.org/meteorgxx/nova-chat/src/main/java/com/nova/chat/ 从 Actor 来看, 简单 IM 聊天室功能需要注意的要点太多了, 比如用户会话管理、消息路由、房间维护、异常处理等等 基于状态机 Actor 的开发方式虽然屏蔽底层线程池处理, 但是需要自己处理状态机转换逻辑, 所以难度相对较高 因为都是用面向对象的设计实现没接触过 Actor 模式, 所以对 Actor 模式理解的不够深刻, 这里也是围绕 Pekko Actor 模式进行总结 Actor 模式总是和大量 Java 组件设计模式耦合在一起, 所以这篇篇章主要是总结常用开发概念和设计思路 首先要知道的是 Actor 最佳实现是 Erlang 语言, 很多概念都是可以从其中获取出来, 这里说下常见 Actor 维护模式(监督体系) OneForOneStrate ...

项目结构推荐: 游戏代码规范(基于杀戮尖塔2解包)文章查看, 后续 Godot 项目都用该规范 这里需要说明目前游戏对话面板有以下方式呈现 使用原生 UI 通用的组件 图片覆盖重写 UI 自定义组件 实际上如果精力足够且开发周期允许, 建议重写并定制自己的 UI 组件, 因为需要 UI 也要和游戏风格符合 但是 Godot 默认 UI 组件渲染性能都比较好且性能开销比较小, 内部也带有 Theme 更换(但是我个人感觉不太好用) 另外为了方便后续游戏引擎的迁移, 也会考虑直接采用图片材质重新涉及一套自定义 UI 规范, 还有需要手动实现以下效果 文字抖动 逐字显示遮罩打字效果 自定义异形边框形变 文字和边框发光描边 内置 Tween 动画和自定义 Shader 渲染通道 … 这些效果单纯靠系统原生 UI 窗口实现起来比较复杂, 也因此推荐采用自己去切图并编写对应的 UI 组件 UI 排列 目前游戏内 UI 目前主要方式如下 目前大部分游戏都是这样处理, 这里结合比较规范项目来区分