在项目正式部署上限的过程当中, 有时候需要用到项目 打包 -> 测试 -> 出包 流程,
这个流程一般是重复且复杂的, 所以就衍生 高效、可靠、可追溯的开发与交付体验 为目标的 流水线 部署流程.
目前 Jenkins 自动化构建流程基本支持前后端项目和容器化处理
推荐采用单独的设备来部署 Jenkins, 因为打包中心可能涉及到修改和暴露很多东西, 所以最好做环境方面隔离.
安装部署
推荐直接 Jenkins官网 去下载 LTS 版本,
虽然我是坚定的 apt 一键安装部署推崇者, 但是基于目前的国内网络原因更新下载速度及其离谱(有时候要更新一整晚);
所以最后不得不直接采用安装包来部署, 还能避免污染 apt 源更新(除非国内以后有镜像部署来加速).
不过这里还提供下 APT 部署流程:
12345678910111213# 安装源证书sudo wget -O /etc/apt/keyrings/jenkins-keyring.asc \https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key# 写入镜像源 e ...
本篇章主要实现多人在线的帧同步流程, 首先是定义客户端和服务端会用到的游戏交互事件 Protobuf:
12345678910111213141516171819202122232425262728293031syntax = "proto3";// 初始化最新的序列帧 - 这个事件是服务端和客户端双向共享, 也就是 Request-Response 响应方式// 其实就是从服务端获取的最新序列帧ID, 然后挂载客户端目前已经执行的序列化帧上等待下个帧运行// 后续需要初始化玩家坐标信息,场景信息也是通过该初始化事件加载; 比如下面声明初始化坐标位置[其实应该定义个 Vec2(x,y) 坐标结构]message InitFrame{ int32 frame = 1; // 后续初始化内容在以下扩充 float x = 2; float y = 3;}// 广播单项 - 玩家引发的发生帧变动// 核心的 frame 字段是帧序列的编号, 需要确保客户端和服务端对发生帧做同步// 当网络丢包重传的时候, 就能明确从那一个帧序列开始丢帧从而采用 ...
记录下海外第三方支付开发的一些关键点, 常见的海外第三方开发推荐按照以下方式处理.
时间戳记录
统一采用 UTC 的时间戳处理, 避免采用服务器地区时间戳导致的跨时区异常, 日常使用的时间戳获取:
Java: System.currentTimeMillis()
Python: round(time.time() * 1000)
.Net: DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()
PHP: round(microtime(true) * 1000)
并且推荐时间戳记录记录在数据库当中采用毫秒级, 可以精确到具体高精度时间.
唯一订单号
这里推荐数据库的订单号类型为 varchar(32) 或者 varchar(64) 且可以设置为数据库表主键, 具体生成时间相关格式订单如下:
12345678910111213141516/** * PHP生成和时间关联尽可能防止碰撞的订单号 * @return string */function order(): string { $microtime = mi ...
这里的Linux打包其实总共分以下几类, 更多是方便内网一键部署的情况:
Debian(.deb) 系列包系统: dpkg -i xxx.deb(安装)|dpkg -r xxx(卸载)
RedHat(.rpm) 系列包系统: rpm -ivh xxx.rpm(安装)|rpm -e xxx.rpm(卸载)
Docker 直接编写 Dockerfile 和 docker-compose 部署
一般来说如果是打包有分为 命令行 和 桌面应用, 这里主要是用于部署服务端所以采用命令行操作
这里需要先采用 debian 打包方式说明, 适用于 Debian|Ubuntu 系列的虚拟环境, 其他因为不常用所以后续再补充.
deb打包
实际上需要按照以下命令来做打包:
12345# 按照文件夹规则放置到其中dpkg -b 文件夹名称 安装包名称# 比如以下方式打包, fusion-gateway 是当前目录下的子目录dpkg -b fusion-gateway fusion-gateway_1.0_amd64.deb
按照以下流程测试打包名为 fusion-gateway 的应用, 该应用基 ...
如果 Chrome 浏览器版本比较新就可以直接让其安装到桌面上作为应用来处理:
无论手机还是桌面浏览器都能将网页安装到桌面从而变成 APP 来使用.
这里实现的方法其实十分简单, 只需要在 html 页面上追加 manifest 声明网页元数据:
123<head> <link rel="manifest" href="manifest.json"></head>
这里的 manifest.json 就是声明 PWA 的 JSON 格式配置文件, 实际上就是相当于调用本地浏览器的 Web 应用入口,
也就是 轻应用 的概念的由来, 无须复杂的桌面|移动端开发来构建的应用.
manifest.json 配置是所有浏览器通用的, 这里提供 Mozilla
的官方说明: Mozilla Manifest
配置的样例如下:
lines123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495 ...
近些年游戏序列化工具不断迭代更新, 比较知名的是 Protobuf|MessagePack 这种序列化,
如果性能要求不高甚至 JSON|XML 这种广泛集成语言也是可以作为游戏数据载体.
但是实际在项目使用当中发现其实 Protobuf 问题也很多, 包括以下问题:
项目引入不可预测的复杂性, 有时候版本可能出现冲突( ProtobufV2 和 ProtobufV3 )
没办法适应性动态处理数据, 结构变动必须要对 proto 文件再编译导入游戏当中
而且对于小众语言来说, 可能根本没有具体实现处理
有的H5游戏上架平台对于底层数据读写功能要求很严格导致可能无法引入
特别是游戏项目, 很多都不采用外网软件库当中的项目引入而是自己内网重写相关功能,
所以对于游戏数据传输其实推荐更加采用原生二进制读写:
基本上是编程语言都支持, 真正跨平台处理, 不需要额外引入别的依赖
序列化过程可以自己动态处理, 不需要编译直接热更
这里采用 Java 语言做示例, 讲解怎么二进制在游戏当中怎么构建和传输.
数据结构
网络传输的数据结构一般常规以下几种:
byte| ...
这里主要采用 MariaDB 作为主要数据库选择, 且内部系统采用 Debian 系的服务器来利用 Apt 进行源安装.
不涉及所有手动编译, 手动编译很多人直接都不写系统脚本让系统托管, 所以尽量能用官方源托管就利用官方源, 当然如果能够自己手动配置本地源更好.
重要: 如果完全不懂系统脚本编写, 切忌不要抄网上所有自己手动编译的教程, 直接 touch 后台托管危害是十分大的.
源安装命令
一般 Linux 发行版都内置了 MariaDB 的系统源仓库, 如果没有的需要配置仓库文件( 这个问题基本集中在 RHEL 系的服务器 ).
这里可以参考官方文档配置: 官方文档
这里直接配置 Debian11 的源( MariaDB 10.7 ):
123sudo apt-get install -y software-properties-common dirmngr apt-transport-httpssudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc&# ...
自签证书内网穿透
这里是基于内网的自签名证书对外开放服务功能, 主要流程:
Linux 定时自动 生成自签证书生成放置于 Nginx 特定目录, 建议每日|每月自动更新证书数据
在生成证书的同时挂载自签证书提供对外服务, 所有服务都必须经由自签证书访问
在生成证书的同时写入到公钥和证书数据到 Redis 之中保存
对外挂起单独 Web 服务提供登录服务用于统一登录授权
用户登录认证之后服务器返回 地址+端口+证书+公钥进行 从而保存到本地挂起 Web 通过自签证书访问服务
用户从登录多个返回授权服务列表可以直接访问到内部自签名服务
具体的请求时序图如下:
这种访问方式可以在外网防止中间人窃取访问数据, 从而保证内部服务的安全可靠性;
这里采用 Python|Bash 脚本处理都行,
另外还需要知道怎么 构建自签名证书.
上面的构建自签证书需要手动输入必要的信息, 这里采用连贯命令直接单行全部编写( 先测试脚本: /etc/nginx/auto.cer.sh ):
12345678910111213141516171819202122232425262728 ...
当时项目提出的具体项目需求, 后续实现之后感觉挺有趣的就把其单独剔除出来总结起来;
具体需求就是商家在我们自己商户平台 注册并绑定当前地址, 然后用户需要在平台检索最近的注册商家.
这里实现方式其实也十分简单, 只需要在注册的时候使用 MySQL|MariaDB 的 Geometry 类型保存位置经纬度.
注意: MySQL版本必须在 5.7 之后才能支持该类型.
Geometry 类型是专门用于空间存储的类型, 具体支持以下细分类型:
Point(110.3 44.0): 点, 保存坐标点位置, 也就是位置标识经纬度
LineString(80.07 23.45, 99.23 34.56): 线, 两个点联系的直线, 用于标识两点直线
Polygon((93.30 35.301 90.332 30.341)): 面, 多点连接采用的多边形面
MultiPoint: 多点, 用于多个点记录, 一般是复杂的多点位置记录
MultiLineString: 多线, 用于多条路线记录, 一般是复杂的多路线记录
MultiPolygon: 多面, 用于多个面对象, 一 ...
这种是游戏服务端当中最常见的碰撞检测游戏寻路方式, 日常AI机器人也十分依赖寻路策略.
静态可以采用 AStar, 而动态则需要 Dstar 的 Dijkstra 处理运算寻路, 移动端游戏尽可能采用静态寻路处理
游戏客户端大部分实现这些插件让其更加易用( Unity的NavMesh ),
但是服务端则缺失这部分功能也就没办法在服务端模拟玩家行走路线从而同步.
AStar寻路实际上是采用 网格(Gird) 的寻路计算, 具体原理就是先把整个地图分解成 Width * Height 多个格子,
然后通过网格周边连线来处理出最短路径, 同时支持标识障碍物绕过计算, 这种过程就是将 平面栅格化.
大部分寻路都是基于这种方式, 只是按照不同算法评估周边格子从而采样路径处理.
注: 在空间寻路当中必须要具有 方向 和 距离 才能形成正确的寻路路径(向量|矢量)
寻路方式按照不同方式计算寻路:
曼哈顿估价法(Manhattan Heuristic)
几何估价法(Euclidean Heuristic)
对角线估价法(Diagonal Heuristic)
对应三种寻路方式 ...
