前言
想给小游戏做个时装功能,在游戏中一般来说换装分为两种:
-
整体时装
-
局部换装
2D 游戏中一般用到的骨骼动画 Spine 和 DragonBone(龙骨)。这里主要学习一下 Spine 换装的相关实现
想给小游戏做个时装功能,在游戏中一般来说换装分为两种:
整体时装
局部换装
2D 游戏中一般用到的骨骼动画 Spine 和 DragonBone(龙骨)。这里主要学习一下 Spine 换装的相关实现
因为之前设计的系统很粗糙,任务看起来很单调,比如 NPC 名称都是一成不变的,所以进行一些小改动。
思路很简单,预设字典库随机分配名称。
名字组成字典
1 | { |
记一次半吊子逆向工程的…艰难过程
在搞小游戏的过程中需要一些美术资源,从网上购买了一些不是很满意,所以准备对几个精品同类手游下手,捞一手美术资源。
一个某大话私服手游,解压安装包:
1 | ├── AndroidManifest.xml |
简单实现服务器不停机更新的机制
之前接触过某 moba 游戏,除了其丰富的游戏内容之外,对其服务器更新机制非常好奇。他们的服务器很少进行停机更新,大部分是不停机更新内容。这是如何实现的呢?
服务器更新场景,一般是业务代码迭代或者配置表需要重载。moba 游戏一般是一个服务器承载 1 或多个房间,所以热更新机制有可能是这样一个设计:
先停止接收新的请求,等待处理完已有的战斗后重启
有序重启,防止无服务器可用
当然,实现上肯定不是这么简单。如果按照上面的思路来实现,流程如下:
大部分游戏中都有排行榜的存在,既可以展示玩家分数之间的排名,也可以用于激发玩家的胜负欲。
排行榜的设计思路比较粗暴,谁的分数高谁在前,分数一致谁先达成谁在前。实现方式有多种,这里列举常见的2种:
通过任务定时查询数据库进行排序,然后储存在内存中。优点是逻辑简单,缺点是不能实时排名。
使用zset(有序集合)存储数据,利用score存储不同的指标来实现各种排行榜。优点是能实时查询,缺点是逻辑相对复杂。
优化链表查询效率
链表在操作的时候需要从头节点遍历到目标节点,如果数据量大比较耗时。当链表应用在 AOI 算法(十字链表,双有序链表)时这个效率问题更会凸显,最坏的情况是遍历 x*y*{v}个节点。
常见的 2 种优化方式:
创建 2 个指针同时指向头节点,快指针移动步长大、慢指针移动步长小,查询时通过快慢指针确定目标节点的范围。
链表每固定步长的节点为索引节点,这些索引节点再组成一个索引链表,查询时通过索引链表确定目标节点的范围。
原理类似 ClickHouse 的跳数索引,可以存在多个索引链表。
简单优化下AOI模块
当游戏开启活动让大量玩家聚集在指定地图范围内时,给服务器和客户端带来最直接的麻烦就是:
假设同屏有1000个玩家,那么任意一个玩家移动一次需要同步其他999个玩家。这导致服务器消息数量指数级增长,带宽承受压力极高。
因为同屏人数越多,客户端需要渲染的模型就越多。这样在一些普通的硬件设备下会直接导致卡顿、发热。
除了升级硬件,还可以在以下两个方面进行优化:
一个粗略的任务系统
为了让游戏的内容丰富起来,同时也能辅助构建游戏世界所处的环境和世界观等等,所以准备简单的开发一个任务系统。
e.g.
支线任务 - 砍人买瓜
「前去长安城购买甘甜可口的西瓜」
奖励:载具*1、武器*1
我:“哥们儿,这瓜多少钱一斤呐”
瓜摊老板:“两块钱一斤”
我:“给我挑一个”
瓜摊老板:“行,这个怎么样?”
这瓜保熟吗?]不买了]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