关于游戏:GolangProtobufPixieJS-开发-Web-多人在线射击游戏原创翻译

5次阅读

共计 5863 个字符，预计需要花费 15 分钟才能阅读完成。

Superstellar 是一款开源的多人 Web 太空游戏，非常适合入门 Golang 游戏服务器开发。

规定很简略：捣毁挪动的物体，不要被其余玩家和小行星杀死 。你领有两种资源 — 生命值(health points) 和能量值(energy points)。每次撞击和与小行星的接触都会让你失去生命值。在射击和应用晋升驱动时会耗费能量值。你杀死的对象越多，你的生命值条就会越长。

游戏分为两个局部：一个地方服务器 (central server) 和一个在每个客户端的浏览器中运行的前端应用程序(a front end app)。

咱们之所以抉择这个我的项目，次要是因为后端局部。咱们心愿它是一个能够同时产生许多事件的中央：游戏模仿 (game simulation)，客户端网络通信(client network communication)，统计信息(statistics)，监督(monitoring) 等等。所有这些都应该并行高效地运行。因而，Go 以并发为导向的办法和轻量级的形式仿佛是实现此工作的现实工具。

前端局部尽管很重要，但并不是咱们的次要关注点。然而，咱们也发现了一些潜在的乏味问题，如如何利用显卡渲染动画或如何做客户端预测，以使游戏运行安稳和良好。最初咱们决定尝试蕴含：JavaScript, webpack 和 PixieJS 的堆栈。

在本文的其余部分中，我将探讨后端局部，而客户端应用程序将留待当前探讨。

Superstellar 是一款多人游戏，所以咱们须要一个逻辑来决定游戏世界的以后状态及其变动。它应该理解所有客户端的动作，并对产生的事件做出最终决定 — 例如，炮弹是否击中目标或两个物体碰撞的后果是什么。咱们不能让客户端这样做，因为可能会产生两个人对是否有人被枪杀的判断不同。更不用说那些想要破解协定并取得非法劣势的歹意玩家了。因而，存储游戏状态并决定其变动的最佳地位是服务器自身。

上面是服务器工作形式的总体概述。它同时运行三种不同类型的动作：

侦听来自客户端的管制输出
运行仿真模仿 (simulation) 以将状态更新到下一个工夫点
向客户端发送以后状态更新

下图显示了飞船的状态和用户输出构造的简化版本。用户能够随时发送音讯，因而能够批改用户输出构造。仿真步骤每 20 毫秒唤醒一次，并执行两个操作。首先，它须要用户输出并更新状态（例如，如果用户启用了推力，则减少加速度）。而后，它获取状态（在 t 时刻）并将其转换为工夫的下一个时刻（t + 1）。整个过程反复进行。

在 Go 中实现这种并行逻辑非常容易 — 多亏了它的并发个性。每个逻辑都在其本人的 goroutine 中运行，并侦听某些通道 (channel)，以便从客户端获取数据或同步到 tickers，以定义模仿步骤(simulations steps) 的速度或将更新发送回客户端。咱们也不用放心并行性 – Go 会主动利用所有可用的 CPU 内核。goroutine 和通道 (channels) 的概念很简略，然而功能强大。

服务器通过 websockets 与客户端通信。因为有了 Gorilla web toolkit，在 Golang 应用 websockets 既简略又牢靠。还有一个原生的 websocket 库，然而它的官网文档说它目前短少一些个性，因而举荐应用 Gorilla。

为了让 websocket 运行，咱们必须编写一个 handler 函数来获取初始的客户端申请，建设 websocket 连贯并创立一个 client 构造体：

superstellar_websocket_handler.go

handler := func(w http.ResponseWriter, r *http.Request) {conn, err := s.upgrader.Upgrade(w, r, nil)
  
  if err != nil {log.Println(err)
    return
  }

  client := NewClient(conn, … //other attributes)
  client.Listen()}

而后，客户端逻辑仅运行两个循环 – 一个循环进行写入(writing)，一个循环进行读取(reading)。因为它们必须并行运行，所以咱们必须在独自的 goroutine 中运行其中之一。应用语言关键字 go，也非常容易：

superstellar_websocket_listen.go

func (c *Client) Listen() {go c.listenWrite()
  c.listenRead()}

上面是 read 函数的简化版本，作为参考。它只是阻塞 ReadMessage() 调用并期待来自特定客户端的新数据：

superstellar_websocket_listen_loop.go

func (c *Client) listenRead() {
  for {messageType, data, err := c.conn.ReadMessage()

    if err != nil {log.Println(err)
    } else if messageType == websocket.BinaryMessage {// unmarshall and handle the data}
  }
}

如您所见，每个读取或写入循环都在其本人的 goroutine 中运行。因为 goroutines 是语言原生的，并且创立起来很便宜，所以咱们能够很轻松地轻松实现高级别的并发性和并行性。咱们没有测试并发客户端的最大可能数量，然而领有 200 个并发客户端时，服务器运行良好，具备很多备用计算能力。最终在该负载下呈现问题的局部是前端 – 浏览器仿佛并没有赶上渲染所有对象的步调。因而，咱们将玩家人数限度为 50 人。

当咱们建设低级通信机制时，咱们须要抉择单方都将用来替换游戏音讯的协定。事实证明不是那么显著。

咱们的第一抉择是 JSON，因为它在 Golang 和(当然) JavaScript 中运行得很晦涩。它是人类可读的，这将使调试过程更容易。感激 Go 的 struct 标签，咱们能够像这样简略的实现它：

superstellar_json_structs.go

type Spaceship struct {
  Position          *types.Vector `json:"position"`
  Velocity          *types.Vector `json:"velocity"`
  Facing            *types.Vector `json:"facing"`
  AngularVelocity   float64       `json:"thrust"`
}

构造中的每个字段都由援用的 JSON 属性名来形容。这种将构造序列化为 JSON 的形式很简略：

superstellar_json_marshall.go

bytes, err := json.Marshal(spaceship)

然而事实证明，JSON 太大了，咱们通过网络发送了太多数据。起因是 JSON 被序列化为蕴含整个模式的字符串示意模式，以及每个对象的字段名称。此外，每个值也都转换为字符串，因而，一个简略的 4 字节整数能够变成 10 字节长的 “2147483647”（并且应用浮点数会变得更糟）。因为咱们的简略办法假如咱们将所有太空飞船的状态发送给所有客户端，因而这意味着服务器的网络流量会随着客户端数量的减少而成倍增长。

一旦咱们意识到这一点，咱们就切换到 protobuf，这是一个二进制协定，它保留数据，但不保留模式。为了可能正确地对数据进行序列化和反序列化，单方依然须要晓得数据的格局，但这一次他们将其保留在利用程序代码中。Protobuf 附带了本人的 DSL 来定义音讯格局，还有一个编译器，能够将定义翻译成许多编程语言的本地代码(多亏了一个独立的库，能够翻译老本地代码和 JavaScript)。因而，您能够筹备好 struct 以填充数据。

以下是 protobuf 对飞船构造定义的简化版本：

superstellar_spaceship.proto

message Spaceship {
  uint32  id              = 1;
  Point   position        = 2;
  Vector  velocity        = 3;
  double  facing          = 4;
  double  angularVelocity = 5;
  ...
}

上面这个函数将咱们的域对象转换为 protobuf 的两头构造：

superstellar_spaceship_to_proto.go

func (s *Spaceship) ToProto() *pb.Spaceship {
  return &amp;pb.Spaceship {Id: s.Id(),
    Position: s.Position().ToProto(),
    Velocity: s.Velocity().ToProto(),
    Facing: s.Facing(),
    AngularVelocity: s.AngularVelocity(),
    ...
  }
}

最初序列化为原始字节：

superstellar_proto_marshal.go

bytes, err := proto.Marshal(message)

当初，咱们能够简略地通过网络以最小的开销将这些字节发送给客户端。

一开始，咱们试图在每个模仿帧上发送整个世界的状态。这样，客户端只会在接管到服务器音讯时从新绘制屏幕。然而，这种办法导致了大量的网络流量—咱们不得不将游戏中每个对象的细节每秒发送 50 次给所有的客户端，以使动画晦涩。太多的数据了!

然而，咱们很快意识到没有必要发送每一个模仿帧。咱们应该只发送那些产生输出变动或乏味事件 (如碰撞、撞击或用户管制的扭转) 的帧。其余帧能够在客户端依据之前的帧进行预测。所以咱们别无选择，只能教客户如何本人模仿。这意味着咱们须要将模仿逻辑从服务器复制到 JavaScript 客户机代码。侥幸的是，只有根本的挪动逻辑须要从新实现，因为其余更简单的事件会触发即时更新。

一旦咱们这么做了，咱们的网络流量就会显著降落。这样咱们也能够加重网络提早的影响。如果音讯在 Internet 上的某个中央卡住了，每个客户机都能够简略地进行本人的模仿，最终，当数据达到时，赶上并相应地更新模仿的状态。

设计应用程序的代码构造也是一个乏味的例子。在第一种办法中，咱们创立了一个 Go 包，并将所有逻辑放入其中。如果须要用一种新的编程语言创立一个趣味我的项目，大多数人可能都会这么做。然而，随着咱们的代码库越来越大，咱们意识到这不再是一个好主见了。因而，咱们将代码划分为几个包，而没有花太多工夫思考如何正确地做到这一点。它很快就咬了咱们一口（报错）：

$ go build
import cycle not allowed

事实证明，Go 不容许包循环地相互依赖。这实际上是一件坏事，因为它迫使程序员认真思考他们的应用程序的构造。所以，在没有其余抉择的状况下，咱们坐在白板前，写下每一块内容，并想出一个想法，即引入一个独自的模块，在零碎的其余局部之间传递信息。咱们将其称为事件分派器(您也能够将其称为事件总线)。

事件调度程序是一个概念，它容许咱们将服务器上产生的所有事件打包成所谓的事件。例如：客户端连贯 (client joins)、来到(leaves)、发送输出音讯(sends an input message) 或该运行模仿步骤了。在这些状况下，咱们应用dispatcher 创立并触发相应的事件。在另一端，每个构造体都能够将本人注册为侦听器，并理解什么时候产生了乏味的事件。这种办法只会让有问题的包只依赖事件包，而不依赖彼此，这就解决了咱们的循环依赖问题。

上面是一个示例，阐明咱们如何应用事件调度程序来流传模仿更新工夫距离。首先，咱们须要创立一个可能监听事件的构造：

superstellar_eventdisp_create.go

type Updater struct {}

func (updater *Updater) HandleTimeTick(*events.TimeTick) {// do something with the event}

而后咱们须要实例化它，并将它注册到事件调度程序中：

superstellar_eventdisp_time_tick.go

updater := Updater{}
 
eventDispatcher := events.NewEventDispatcher()
eventDispatcher.RegisterTimeTickListener(updater)

当初，咱们须要一些代码来运行 ticker 并触发事件：

superstellar_eventdisp_time_tick_loop.go

for range time.Tick(constants.PhysicsFrameDuration) {event := &events.TimeTick{}
  eventDispatcher.FireTimeTick(event)
}

通过这种形式，咱们能够定义任何事件并注册尽可能多的监听器。事件调度程序在循环中运行，因而咱们须要记住不要将长时间运行的工作放在处理函数中。相同，咱们能够创立一个新的 goroutine，在那里做沉重的计算。

可怜的是，Go 不反对泛型(未来可能会扭转)，所以为了实现许多不同的事件类型，咱们应用了该语言的另一个个性—代码生成。事实证明，这是解决这个问题的一个十分无效的办法，至多在咱们这样规模的我的项目中是这样。

从久远来看，咱们意识到实现事件调度程序是一件很有价值的事件。因为 Go 迫使咱们防止循环依赖，所以咱们在开发的晚期阶段就想到了它。否则咱们可能不会这么做。

实现多人浏览器游戏十分乏味，也是学习 Go 的一种很好的办法。咱们能够应用其最佳性能，例如并发工具，简略性和高性能。因为它的语法相似于动静类型的语言，所以咱们能够疾速编写代码，但又不就义动态类型的安全性。这十分有用，尤其是在像咱们这样编写低级应用程序服务器时。

咱们还理解了在创立实时多人游戏时必须面对的问题。客户端和服务器之间的通信量可能十分大，必须付出很多致力来升高它。您也不会遗记不可避免地会呈现的滞后和网络问题。

最初值得一提的是，创立一个简略的在线游戏也须要大量的工作，无论是在外部实现方面还是在您想使其变得乏味且可玩时。咱们花了无休止的工夫探讨要在游戏中放入哪种武器，资源或其余性能，只是意识到要理论实现须要多少工作。然而，当您尝试做一些对您来说是全新的事件时，即便您设法制作出最小的货色也能给您带来很多满足感。
图片起源：http://www.hp91.cn/ h5 游戏

正文完