记一次半吊子逆向工程的…艰难过程
前言
在搞小游戏的过程中需要一些美术资源,从网上购买了一些不是很满意,所以准备对几个精品同类手游下手,捞一手美术资源。
下手
一个某大话私服手游,解压安装包:
1 | ├── AndroidManifest.xml |
记一次半吊子逆向工程的…艰难过程
在搞小游戏的过程中需要一些美术资源,从网上购买了一些不是很满意,所以准备对几个精品同类手游下手,捞一手美术资源。
一个某大话私服手游,解压安装包:
1 | ├── AndroidManifest.xml |
简单实现服务器不停机更新的机制
之前接触过某 moba 游戏,除了其丰富的游戏内容之外,对其服务器更新机制非常好奇。他们的服务器很少进行停机更新,大部分是不停机更新内容。这是如何实现的呢?
服务器更新场景,一般是业务代码迭代或者配置表需要重载。moba 游戏一般是一个服务器承载 1 或多个房间,所以热更新机制有可能是这样一个设计:
先停止接收新的请求,等待处理完已有的战斗后重启
有序重启,防止无服务器可用
当然,实现上肯定不是这么简单。如果按照上面的思路来实现,流程如下:
大部分游戏中都有排行榜的存在,既可以展示玩家分数之间的排名,也可以用于激发玩家的胜负欲。
排行榜的设计思路比较粗暴,谁的分数高谁在前,分数一致谁先达成谁在前。实现方式有多种,这里列举常见的2种:
通过任务定时查询数据库进行排序,然后储存在内存中。优点是逻辑简单,缺点是不能实时排名。
使用zset(有序集合)存储数据,利用score存储不同的指标来实现各种排行榜。优点是能实时查询,缺点是逻辑相对复杂。
优化链表查询效率
链表在操作的时候需要从头节点遍历到目标节点,如果数据量大比较耗时。当链表应用在 AOI 算法(十字链表,双有序链表)时这个效率问题更会凸显,最坏的情况是遍历 x*y*{v}个节点。
常见的 2 种优化方式:
创建 2 个指针同时指向头节点,快指针移动步长大、慢指针移动步长小,查询时通过快慢指针确定目标节点的范围。
链表每固定步长的节点为索引节点,这些索引节点再组成一个索引链表,查询时通过索引链表确定目标节点的范围。
原理类似 ClickHouse 的跳数索引,可以存在多个索引链表。
简单优化下AOI模块
当游戏开启活动让大量玩家聚集在指定地图范围内时,给服务器和客户端带来最直接的麻烦就是:
假设同屏有1000个玩家,那么任意一个玩家移动一次需要同步其他999个玩家。这导致服务器消息数量指数级增长,带宽承受压力极高。
因为同屏人数越多,客户端需要渲染的模型就越多。这样在一些普通的硬件设备下会直接导致卡顿、发热。
除了升级硬件,还可以在以下两个方面进行优化:
一个粗略的任务系统
为了让游戏的内容丰富起来,同时也能辅助构建游戏世界所处的环境和世界观等等,所以准备简单的开发一个任务系统。
e.g.
支线任务 - 砍人买瓜
「前去长安城购买甘甜可口的西瓜」
奖励:载具*1、武器*1
我:“哥们儿,这瓜多少钱一斤呐”
瓜摊老板:“两块钱一斤”
我:“给我挑一个”
瓜摊老板:“行,这个怎么样?”
这瓜保熟吗?]不买了]行为树一般应用于游戏内物体的 AI 决策,以树的形式控制物体接下来的动作。比如: 血量太少 -> 吃药、攻击距离不够 -> 移动等等。
最近在摸索小游戏开发,有一些联机型的功能需要机器人参与,所以需要实现一下游戏 AI。综合一下实现方案基本是以下两种:
FSM 也是最开始采用的方案,实现起来简单粗暴。缺点是整个逻辑非常臃肿很难模块化,后面再对 AI 进行更新和维护比较恶心,很容易因为漏改、错改导致不可用。
行为树是由一系列节点构成的,每个节点对应一个动作,自上而下执行且每个节点都会返回执行状态。
在网络游戏中,通信协议是其中必不可少的组成部分。一个通信协议的大小、结构将与服务器负载及客户端延迟息息相关。
游戏的通信协议,一般需要考虑 2 个部分:
网络传输协议
数据交换格式
tag:
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录(注意不是yilia根目录)执行以下命令:
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置:
jsonContent:
meta: false
pages: false
posts:
title: true
date: true
path: true
text: false
raw: false
content: false
slug: false
updated: false
comments: false
link: false
permalink: false
excerpt: false
categories: false
tags: true