以前也萌生过类似想法,主要问题是,游戏是共享状态太多,不像web应用那样client链接之间互相独立。用coroutine的方式,resume回来,全局的上下文信息改变,容易出bug。实践中,自写的server都不轻易用coroutine,宁愿写callback,虽繁琐但排查容易一点。不做长连接也没关系(特别是手机游戏),用一个安全可信的client 凭证来标识链接状态即可。
所以关键还是在于,这个游戏的类型是不是强交互的,如果玩家间的交互状态较多,就不适合。如果只是简单的联机, 玩家间交互简单,状态不多,那倒可以,比自己做个server靠谱。
仅仅做个前端的连接管理server倒是可以,链接适合并行,逻辑就很难并行,需要后端进程处理逻辑。
On Monday, April 15, 2013 10:24:49 AM UTC+8, agentzh wrote:
Hello!
2013/4/14 Ken Lam:
> 现在openresty的方式非常的适合Web应用的开发。
> 最近我好奇,openresty能否作为Game Server来使用?
> 类似于传统的Game Server,支持tcp/udp等长连接。然后逻辑处理部分使用lua来
> 操作。客户端/浏览器仍然是使用http协议来数据通信。
> 一点儿胡思乱想,打扰了!
>
我知道的,已经有好几个用户在生产上这么搞了 :)
同时抄送给 openresty 中文邮件列表,建议总是在那里讨论这样的问题,谢谢合作 :)
Best regards,
-agentzh