MeteorCat Blog

近些年游戏序列化工具不断迭代更新, 比较知名的是 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) 对应三种寻路方式 ...

Nginx 常用来负载均衡, 用来多个服务端反向代理内部服务器组从而获取到内部网络资源对外提供服务, 后续还有些静态资源就需要考虑多地缓存而不走直接后端流量. 常见比如网状反向服务架构, 多个对外服务Nginx同时转发到内网单机情况; 需要缓存内网资源到外部访问服务器本地, 后续资源不走内部服务器. 假设目前内网机已经部署好对外静态资源服务端, 这时候则需要在可以被对外访问得服务器上安装配置 Nginx: 12# 安装好 NGINX 服务sudo apt install -y nginx 之后这里就是假设需求: 目前需要 .mp4|.mkv|.avi|.wmv 这些视频文件十分庞大且占用流量十分多, 所以在对外服务器上需要将内网服务器的资源缓存, 并且后续超时时间设定为 6 个月才重新更新缓存. 这里编写配置来处理这方面设置即可: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263http { ...

虽然 Git 已经满足代码版本托管, 但是对于美术/策划等工作来说没必要搞什么代码托管或者版本管理, 只需要不断推送就行了. 这里基于 debian 系统安装 12345# 安装 subversion 软件sudo apt install -y subversion# 之后创建版本库sudo mkdir /svn && cd /svn 生成版本库 这里多版本库首先定义好子版本库, 以后不断扩展不同版本库: 12345678910111213# 创建子版本库 code sudo mkdir -p /svn/code && cd /svn/code# 生成版本库sudo svnadmin create /svn/code# 没问题就含有以下文件目录:# conf# db# format# hooks# locks# README.txt 这里主要修改配置文件 conf: conf/authz: 权限控制 conf/passwd: 账号密码文件 conf/svnserve.conf: 服务器配置文件 首先修改账号密码文件( conf/pas ...

收集些日常用到的 Shell 脚本 通过PID获取指定应用占用情况 123456789101112131415161718192021222324252627```shell#!/bin/bashread -p "请输入要查询的用户名：" nameecho "------------------------------"n=`cat /etc/passwd | awk -F: '$1~/^'${name}'$/{print}' | wc -l`if [ $n -eq 0 ];thenecho -e "\e[31m该用户不存在！\e[0m"echo "------------------------------"else echo "该用户的用户名：${name}" echo "该用户的UID：$(cat /etc/passwd | awk -F: '$1~/^&#x ...

systemd 系统单元可以利用 @ 后面传递某些变量, 比如: 12sudo systemctl start mysql@slave.service# 可以看到其实内部系统配置文件为 mysql@.service 这种就是 systemd 的模板服务, 用于调用可变的系统服务. 1234[Unit]# 内部采用 %I 获取到外部 xxx@yyy.service 传入 yyy 模板值Description=Temple Service By %IAfter=network.target nss-lookup.target 这里 systemd 内置不少可能需要的变量, 这些模板服务依赖大量系统环境, 所以编写的时候需要在 Description 打印好做好排查: %n: 完整的 Unit 文件名字，包括 .service 后缀名 %N: 完整的 Unit 文件名字，不包括 .service 后缀名 %p: Unit 模板文件名中 @ 符号之前的部分，不包括 @ 符号 %P: Unit 模板文件名中 @ 符号之前的部分，包括 @ 符号 %i: Unit 模板文件名中 ...