想起来就写一点,不定期更新。

定义术语

先定义几个不算特别专业的术语,方便后面的讨论,平时工作中都是这样叫的:

  • 主角玩家
    • 将游戏客户端中玩家自己的角色称之为主角玩家,简称主角,主角由玩家来控制。
  • 第三方玩家
    • 将游戏客户端中玩家自己的角色以外的其他角色称之为第三方玩家,简称第三方,第三方由服务器发送的同步消息来控制。
  • 服务器玩家
    • 家在服务器中对应的对象,有时根据上下文简称为服务器。
继续阅读

本文还未完成!

本文还未完成!

本文还未完成!

本文谈谈IncServer如何管理游戏场景中的对象(玩家、怪物、机关等)及其AOI实现。

为了简化讨论,本文略去了游戏对象类型和patch粒度两个维度,在文章末尾会做一个简单的补充说明。

继续阅读

什么是copy-on-write

Copy-on-write,写时复制,简称COW,是一种资源管理技术。引用维基百科的说明:

写入时复制(英语:Copy-on-write,简称COW)是一种计算机程序设计领域的优化策略。其核心思想是,如果有多个调用者(callers)同时请求相同资源(如内存或磁盘上的数据存储),他们会共同获取相同的指针指向相同的资源,直到某个调用者试图修改资源的内容时,系统才会真正复制一份专用副本(private copy)给该调用者,而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的(transparently)。此作法主要的优点是如果调用者没有修改该资源,就不会有副本(private copy)被建立,因此多个调用者只是读取操作时可以共享同一份资源。

fork()的内存语义

Copy-on-write最贴切的例子就是fork()系统调用了,来看下fork()系统调用的内存语义:

从概念上讲,可以将fork()看作是创建父进程的文本段、数据段、以及堆和栈的拷贝。

实际上,在一些早期的UNIX实现中,这种拷贝确实是按字面意思来执行的:拷贝父进程的内存到swap,创建一个新的进程映像,使swap出来的映像成为子进程,而父进程则保留自己原先的内存。

继续阅读

谨以此系列文章献给过去四年半的自己,又要开始新的征程了。

先跟过去告个别:

接下来是一系列技术文章,工程浩大,先大致列个提纲,有时间就写。

首先剖析一份代码,我不知道该怎么称呼这份代码,我认识它的时候它是一个代号Inception的手游的服务器引擎,源于网易的一个飞行游戏,再往前据说是韩国人的作品,我不管,我叫它IncServer:

再来看IncServer中用到的比较重要的第三方组件:

最后是个人游戏开发沉思录:

IncServer最核心的部分,自然是网络库了。

本文旨在分析IncServer网络库(以下称IncNet)的实现,进以总结一个网络库应当具备的基本功能以及常见做法,为以后手撸一个全新的网络库打下基础。

IncNet的实现依赖:

  • Sockets API
  • I/O Multiplexing(select/poll)
  • epoll API
  • POSIX Threads API(Pthreads)
  • Reactor模式

阅读此文请先对以上知识有所了解。

在此推荐一本书,《The Linux Programming Interface——A Linux and UNIX System Programming Handbook》,简称TLPI,中文译名《Linux系统编程手册》,分上下两册,作者是目前Linux manpage的维护者Michael Kerrisk。
强烈建议阅读英文版,并结合官方勘误表。中译本上册翻译尚可,下册机翻痕迹明显,有多处意思完全相反。至少要中英结合看,感觉译文不对可以看下原文是怎么写的,还感觉不对就去看勘误表。

继续阅读

C#代码:

float fovY = m_Camera.fieldOfView;
float far = m_Camera.farClipPlane;
float height = 2 * Mathf.Tan(fovY * Mathf.Deg2Rad * 0.5f) * far;
float width = height * m_Camera.aspect;

m_Material.SetVector("_FarCorner", new Vector3(width, height, far));

上面的代码主要是求得远裁剪平面的宽、高,以及距离摄像机的距离。都是以摄像机空间的单位为单位的,而不是以像素为单位(Camera.pixelWidth, Camera.pixelHeight)。

shader代码:

float depth = Linear01Depth(tex2D(_CameraDepthTexture, uv).x);
float3 ray = (half3(-0.5f,-0.5f,0) + half3(uv.xy,-1)) * _FarCorner;
float3 viewPos = ray * depth;

tex2D(_CameraDepthTexture, uv).x根据屏幕像素的uv对深度纹理进行采样获取Z buffer,但此时的Z buffer是非线性的,需要调用Linear01Depth将其映射到线性的[0, 1]区间内,0对应摄像机位置,1对应远裁剪平面。

half3(-0.5f,-0.5f,0) + half3(uv.xy,-1)将uv坐标减去0.5,从[0,1]区间映射到了[-0.5,0.5]区间。

乘以_FarCorner得到half3((uv.x - 0.5f) * width, (uv.y - 0.5f) * width, -1 * far),此时x在[-0.5width, 0.5width]区间内,y在[-0.5height, 0.5height]区间内,z是-far。

但以上只是远裁剪平面的情况,实际上每个xy平面的宽高以及对应的z值是随depth线性变化的。所以最后一步乘以depth,获得最终的摄像机空间下的坐标。

我们游戏内的动作都是Generic类型的,并且技能动作使用了{% post_link Unity-Root-Motion Root Motion %}来处理技能位移。

所有模型都有一跟B_Root骨骼(没有蒙皮信息),用作模型导入设置里的Root node。

如果将动作类型改为Humanoid,则由于B_Root的存在,会导致Root Motion无法正常使用,不管Bake Inot Pos与否,动作本身都会有位移,看表现应该是B_Root影响到了Body Transform和Body Orientation的计算:

继续阅读