游戏服务器

网络延迟是所有实时同步的游戏都会遇到的问题，下面是关于实时同步问题的一些思考和处理方法。具体的解决方法可能比较特殊，首先这里的服务器并不跑定时器（除了一个游戏结束倒计时的定时器），由前端驱动，延迟的情况下主要是由前端来预测或纠正，服务器辅助，处理和转发，据我的了解好像没什么人这样子搞吧。所以看完如果觉得我这边有考虑不周的，或者有更好的思路，欢迎拍砖 / 交流 首先这是一个两边出兵对攻的游戏，只有2个玩家，而战场上士兵/英雄的数量也不会太多，最多不会超过50个吧，士兵都是有AI的，不被玩家控制。玩家能做的操作很有限，这里只以出兵这个操作为例。在游戏开始的时候，会有一次校时操作，这个后面会说到。 玩家A在Tick1点出兵，播放各种出兵特效之后，Tick1 + Delay = Tick2，在Tick2这个时间才会真正出兵，Delay等于抬手时间，也就是一个允许的延迟时间，并不等于网络延迟，应该理解为一个前摇动画的播放时间，这个时间越长越好，在不影响玩家体验的前提下（例如弄一个士兵生产队列，从出兵指令发出到士兵生产完毕，这可需要不少时间）。 这时候玩家请求服务器，请求的内容包含Tick1 + 出兵指令，服务器收到指令，对服务器而言，这时可能有两种情况，第一种是在Tick2之前收到，第二种是在Tick2之后收到 在Tick2之前收到，服务器可以转发操作，告诉所有的客户端，我们在Tick2出兵

前几天写了 《开源分享 Unity3d客户端与C#分布式服务端游戏框架》 ，受到很多人关注，QQ群几天就加了80多个人。开源这个框架的主要目的也是分享自己设计ET的一些想法，所以我准备写一系列的文章，介绍下自己的思路跟设计，每篇一个主题，这次介绍的是组件设计。 在代码复用和组织数据方面，面向对象可能是大家第一反应。面向对象三大特性继承，封装，多态，在一定程度上能解决不少代码复用，数据复用的问题。不过面向对象不是万能的，它也有极大的缺陷： 1. 数据结构耦合性极强 一旦父类中增加或删除某个字段，可能要影响到所有子类，影响到所有子类相关的逻辑。这显得非常不灵活，在一套复杂的继承体系中，往父类中改变字段会变得越来越麻烦，比方说ABC是D的子类，某天发现需要增加一个AB都有的数据，但是C没有，那么这个数据肯定不好放到父类中，只能将AB抽象出来一个父类E，E继承于D，AB共有的字段加到E中，一旦继承结构发生了变化，可能接口也要改变，比方说之前有个接口传入参数类型是E，当AB不再需要共用的那个字段，那么需要调整继承关系，让AB重新继承D，那么这个接口的传入参数类型需要改成D，其中的逻辑代码很可能也要发生调整。更可怕的是游戏逻辑变化非常复杂，非常频繁，可能今天加了个字段，明天又删掉了，假如每次都要去调整继承结构，这简直就是噩梦。继承结构面对频繁的数据结构调整感觉很无力。 2. 难以热插拔

本文发表于程序员刘宇的个人博客，转载请注明来源，博客园同步更新：https://www.cnblogs.com/xiaohutu/p/12402399.html 这几年做了一些网络同步项目，总结一下帧同步的一些东西。 1. 帧同步基本特点 所有的逻辑行为运算都在客户端进行，客户端保证彼此之间执行结果的一致性。 客户端将自己的所有操作发给服务器，服务器转发。 服务器维持一定的逻辑帧率向客户端发包，每次都带上一间隔的所有客户端发来的操作，如果没有就发空帧，附带上客户端需要执行此包的帧数。 客户端收到帧数据执行这一逻辑帧的行为，否则等待。 2. 同步性的保证 确保需要同步部分逻辑执行次序的一致性，特别关注各种容器的底层结构以及运行过程中对容器的增删改。 确保AI、物理引擎等执行结果的一致性，避免因为使用部分游戏引擎的更新特性，导致一些AI计算的时间次序问题。 确保数学运算在不同cpu上的的一致性，使用定点数或者浮点数截取等方法计算逻辑。 确保随机结果基于次数的一致性，使用次数一致性的随机算法，如梅森旋转算法。 确保客户端数据来源的一致性，存储的静态数据以及读取过程需要特别关注。 3. 逻辑画面分离 抽离开图像执行逻辑和关键帧执行逻辑的循环结构。 逻辑部分可以无画面执行，正确的输出结果。 数据关键帧（即执行AI的关键帧)可以调整，和图像帧的比例也可以调整，图像帧做好动画、位移

PART 1 概述 本文是关于探索快节奏多人游戏的技术和算法系列的第一篇，因此对多人游戏概念非常熟悉的同学可以随意的跳过这一篇就好啦～因为接下来只是一些介绍性质的讨论。。。 任何类型的游戏开发都是某种挑战，然而在多人游戏中我们还有更多全新的问题函待解决～最最 Interesting 的地方在于其核心问题其实是人类和物理！- - 好吧其实是作弊和地理限制造成的网络延时。。 PART 2 反作弊 所有的一切的起源都是作弊。 作为一个游戏开发者，你一般不会去担心有人在你的单人游戏中去作弊 - 因为他的行为不会给其他人带来影响，一个作弊的玩家可能并不会按你设计的套路去进行游戏，但是游戏是他的，他们有权利去选择怎么去玩。 多人游戏则不同。在任何的有竞争关系的游戏中，一个作弊玩家不仅仅给自己带来了更好的体验，他也毁了其他的玩家的游戏。作为开发者，你可能希望避免出现这样的情况，因为这会让玩家流失。 为了防止作弊，有很多事可以去做，但是最重要最（可能也是唯一有意义的）的事非常简单：不要相信玩家。就做最坏的打算：所有玩家都想要作弊。 PART 3 权威服务器和静默客户端 有一个非常简单的解决方案 - 你将游戏中所有的逻辑都放在你控制的服务器来做，而客户端只是游戏的旁观者，换句话说，你游戏的客户端把输入（按键，命令）发送到服务器，服务器来运行这个游戏，然后你把结果返回给客户端。这就是常说的权威服务器

最近在找工作，本人还是希望回游戏行业的，投了半天抓到一个面试机会，面试题是一个游戏排行榜功能，其中只需要客户端id，分数这两个字段。 我看到这个题的时候心想简单的一批，就没细想可能会出现的一些问题， 查了一下django的文档就开始一把梭，建立一张表，客户端id，分数两个字段。 查询排行榜指定的位次段: select id,score from user_score order by score desc limit %v1%,%v2%; 当然，当时是用django的orm写的 models.score.objects.all().order_by('-score')[rank_begin:rank_end] 问题来了： 问：如何获取到客户端本身的位次？ 当时没用脑子的我想的是取出所有数据，排序后去遍历获得客户端的index 问：当数据量非常大的时候，怎么办？ 答：建索引 然后问了一些mysql相关的知识 果不其然被拒了！！ 现在想想，在查询客户端本身的位次时，我是有客户端的分数的，即我可以通过这个分数，来查出来比当前分数大的有多少客户端，再+1，就是客户端的排名了。 select count(*) from user_score where score >= %score%; 来源： CSDN 作者： yu的宇 链接： https://blog.csdn.net/qq

长文慎入，如何快速开发区块链游戏 译者注： 原文： 初始发行 Enjin整合 初始整合 客户端SDK GUI 客户端SDK API Enjin的API是GraphQL Enjin推荐 使用服务器 排列你的物品并分批发送 存储返回的transactionId 高级发送很棒 确保你允许区块链拥堵 后端v1-PlayFab 供应有限 服务器脚本 后端v1.5 —临时Bandaid 后端v1.5日落—再见PlayFab 后端v2-自定义解决方案 管理小组 编辑项目 待创建区块链项目 Enjin区块链发送队列 Unity 3d游戏引擎 游戏引擎历史 Unity Asset Store的强大功能 Unity编辑器 有兴趣尝试区块链游戏吗？ 遗失的宝藏 译者注： 该文章是独立游戏开发者克里夫·考利写的区块链游戏开发技术文章。没有投资没有团队，他自己一个人成功开发了以太坊区块链第一款真正意义上的ARPG游戏—— 遗失的宝藏 。目前游戏已稳定运营8个月，游戏玩家人数已经超过3700人，玩家道具周交易量在1万人民币左右，月营收在80000 ENJ(人民币50000元)左右。克里夫近期分享了自己从零开发搭建区块链游戏的技术路线。作为一名区块链游戏的粉丝，我见证了 遗失的宝藏 从无到有的过程。为克里夫喝彩之余，感慨为何国内没有游戏开发者能做出如此上等品质的区块链游戏。于是翻译这篇文章

服务器相关： 1、压测过程中，监控服务器的内存变化。这种方案比较麻烦，但是可实施性比较高，最暴力的一种。 2、自动化，玩家上线后，操作后，然后理论上下线后除了已知的NPC，怪物对象外，不应该有其他对象。 1，关闭gc（可以查找循环引用） 2，凌晨封网，强制玩家下线 3，内存检查，将泄漏，循环引用内容分析 4，开启内网脚本 3，更好的方式其实是对各种对象最计数，统计，快照，然后来分析，呈现可用火焰图 4、引擎泄漏部分，tcmalloc，pprof等 来源： CSDN 作者： 排山和倒海 链接： https://blog.csdn.net/wangqing008/article/details/104064165

每周回顾：深入了解装备与面板计算 查BUG 角色属性异常，在脱去装备的情况下，面板数值仍觉得稍微多点 想起了之前看过很多遍的面板数值计算函数（几千行），然后开始从数值为0的地方开始调试，把有影响的值打出来，发现了有问题的地方。 做服务器还是师傅告诉我的一条原则，客户端发来的不要信，这条要注意。 在游戏里涉及到道具和属性的地方，要想一下客户端发来的消息的各种情况。比如客户端请求学习一个职业技能，服务器就让客户端学习他发来的这个技能，如果客户端将这个技能编号修改，改成别的技能，服务器也让它学的话，就会出问题。如果是道具，则要检查道具是否是服务器配的，以及数量可能溢出的问题。 setupcharbase与calcAll 花了几个星期整理完了setupcharbase里面的各个流程，这里面包含了游戏里所有与攻防血有关的功能部分。整理完这部分后，仅仅是知其然。只知道是有影响，真正公式计算，还是找到装备计算的地方。 calcAll是个大头，都是祖传代码，跟某几个的数值计算流程就要费很大劲，暂时是把基础的计算整理下来了，还是有些细节，由于不熟悉游戏核心玩法（需要深入了解游戏装备的各个数值），还需确认细节部分。 来源： https://www.cnblogs.com/ayaoyao/p/12185340.html

1)笔记 1)H5游戏资源加载的流程 H5游戏,资源最开始是在网络服务器上; 启动H5游戏-->从服务器上,第一个当前场景的依赖的资源,从远程服务器下载下来,并运行; a: 当前没有使用的资源,依然在服务器上; b: 你其它的模块的场景这些资源,也还会在服务器上; H5游戏,预加载: H5: 都有一个启动预加载,还没开始进入游戏场景,先加载;-->微信小游戏/H5 启动加载; 在场景切换的过程中:我们可以有2种方式做到资源预加载: 加载资源比较多的切换,那么这个时候,我们会使用进度条进行处理; 如果加载比较短,我们可加一个等待的方式,来处理,隐藏掉等待; 框架,只有一个场景,每个模块会有自己的资源,资源管理; creator资源加载都是异步的,cc.loader.loadRes("", function(){在回到里面进行处理}) 2)creator cc.loader异步,我们的策略 (1)每个模块自己的 "场景" 的资源的依赖,由自己管理,资源配置表; (2)每个模块,都要有自己的预加载函数来加载我们的资源; (3)在切换的时候,我们要卸载当前模块的资源,如果你希望卸载的话; 资源管理模块,是基于我们的场景模块集合的管理模式： step1：我们会定义一个资源集合包:{场景里面所需要的所有资源} step2: 预加载这个场景资源包 step3:直接进去

游戏服务器设计之任务系统 介绍 任务系统是游戏中最重要的系统之一，本文旨在设计一个轻量清晰的任务系统。通用易扩展是本系统关注的重点。任务系统中当角色的条件满足时，自动触发每一类型的任务，每个任务有其所需的完成条件，当角色完成了指定的操作后，则会触发任务自动完成，任务完成后一般玩家会领取对应的奖励，结束任务，此任务的生命周期结束，如果这个任务有后续任务，那么会自动触发下一个任务，从玩家角度讲，任务是一条故事线，所以经常会说主线、支线任务就是这个原因。 设计 当设计任务时有如下几个重点： 任务需要以线的方式组织，一般都是在每个任务配置中指定下一个任务的id，每个任务线的第一个和最后一个比较特殊，第一个任务必须在角色属性满足条件下自动获得，而最后一个任务因为是故事线的结尾所以不能触发下一个任务，需要保持任务已结束的状态，如果故事线增加了后续任务，那么任务可以继续往下顺延。 任务需要满足条件才能接取，所谓的条件一般都是角色属性，比如角色等级。比如等级10级以上的可接取，为了抽象这个需求，任务可接条件设置两个字段角色属性类型和属性值，这个等级的例子就是等级:10。 任务接取后角色在游戏中做相关的操作，如果跟接取的任务相关，那么任务的进度会自动更新，那么二者是组合产生关联的呢？我们使用事件机制，玩家的游戏行为拆分出一系列的事件类型，用三个字段表示，事件类型，事件对象，事件值，比如打怪