我正在设计一个小型足球游戏,其中游戏引擎(计算玩家移动等)在服务器上运行,并且渲染和键盘/鼠标处理由客户端完成。对于服务器(Haskell)我想使用
每20分钟左右,客户端应通过HTTP GET向服务器发送键盘和鼠标事件,接收当前游戏状态(JSON编码的球和玩家位置)并渲染它。我正在考虑将SDL基础设施用于游戏循环,输入处理和渲染。
服务器基本上运行两个线程:一个happstack服务器接收HTTP GET,将键盘/鼠标命令放入队列,从第二个队列读取当前游戏状态并回答HTTP GET请求。
第二个线程运行Yampa游戏引擎,如Yampa Arcade paper中所述:游戏引擎尽可能快地计算新一轮(无滴答)并将结果放入渲染队列。
一般问题:这看起来像一个可行的架构吗?
具体问题:如何设计服务器端渲染队列:是否会使用Chan进行此操作?如果游戏引擎的平均速度比客户端的“滴答”快,则队列将变得越来越长。怎么可以用Chan处理?
非常欢迎您的评论!
答案 0 :(得分:6)
你能解释一下游戏本身吗?当我想到一个足球比赛时,我想到一个需要实时反馈的游戏,其中输入应该立即处理,我希望玩家输入信息能够立即通过网络发送。 20毫秒是一个相当大的延迟,我相信当玩家按下钥匙试图移动他/她的角色时,它可能会引起注意,它可能会感觉到某些类型的垃圾收集器所经历的那种生涩的不稳定。
我也不明白你为什么要在这样的游戏中使用HTTP(任何游戏),几乎所有的游戏都使用UDP,我可能会根据你的游戏类型走这条路。 This tutorial看起来非常适合学习这类东西。
我还会质疑您选择的网络数据格式,为什么您需要一种在接收/发送时需要非平凡的解析/格式化的格式?我想,发送大量数据并经常这会增加大量时间。如果我打算使用字符串,我会尝试使用最简单的格式,只需要很少的解析。在我将要处理的相关系统上是一个使用套接字进行通信的多进程实时系统,最初它使用xml字符串作为网络数据格式,并且它非常低效,所有进程都在同一台机器上。 / p>
关于Yampa&服务器端渲染,所以如果我们将游戏环境中的FRP视为实现游戏逻辑和放大器的手段。实体我相信大多数网络游戏都有服务器和服务器。客户实体。通常,可渲染的对象是客户端实体,不可渲染的是服务器实体,我猜一些实体在两者上都有表示。因此,在这种情况下,您可能希望Yampa在服务器和运行中运行。客户端,我会尽量避免与服务器端渲染相关的任何事情。可信对象应该主要坚持客户端我相信。您是否有特定原因需要来自服务器的渲染命令?
答案 1 :(得分:4)
如果您只想提供最新的游戏状态,请不要使用chan或队列,请使用samplevar:http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent-SampleVar.html
答案 2 :(得分:2)