[讨论]一个游戏结算程序的设计

cyagi

假设要设计这样一个在线多人经营游戏：
1.游戏有一个大地图，显示所有玩家的所有店铺；
2.每个玩家可以开多个店铺，店铺在大地图的位置是玩家自己选择的；
3.玩家可以选择每个店铺出售的商品种类，1种或N种；
4.店铺的收益：在一个结算周期内，随机抽取若干个商品卖出。

问题：结算程序如何设计效率更高，占用服务器资源更低？

如果是在服务器设计一个定时程序，玩家数量多了，势必产生时间的延迟
如果在读取玩家信息和读取店铺信息时结算，又会占用很多服务器资源

各位大虾还有其它什么好办法吗？

kaikai

你期望店铺的总数多大？商品种类n有多大？结算周期多长？
定出了问题的规模才好判断.

cyagi

1万用户，10万店铺，每个店铺最多买50种商品，1个小时结算一次

地图分区，每个区500个店铺，同时显示在屏幕30～50个

hongbo118

个人想法:可以线性的处理,没必要在一个结算周期处理全部的店铺, 可以分成小的结算周期(每帧或每秒)处理100个用户这样子,要根据测试来确定这个粒度,维护一个队列,这样子.

cyagi

LS这样做，不就和定时执行一样喽。我想要的是感觉上是同时结算

kaikai

cyagi: Re:[讨论]一个游戏结算程序的设计

1万用户，10万店铺，每个店铺最多买50种商品，1个小时结算一次

地图分区，每个区500个店铺，同时显示在屏幕30～50个

同时在线玩家如果想对总玩家数量比较小，那么可以优先结算在线玩家当前屏幕的店铺内容。
其他的结算依次顺延。
逻辑上保持所有店铺在同一时间点结算是依靠过滤掉结算时间之后的交易。

假如多次结算没有累积效果，理论上也可以让长期无人光顾的店铺长期不做结算。
只对所有在线用户查询到的店铺做结算检查（判断在上次结算之后到最近一次结算时间点之间是否存在交易记录）

FatTony

这个计算过程可以给客户端程序来做就可以了，把计算的结果传送到服务器。

因为店是玩家开的，各个玩家交易信息和他玩游戏时的信息（如走路）一样，都是自己处理，然后把结果发给服务器。【声明，这是我猜测的，我没有开发经验】

因为我们不可能把我们行动的速度等信息传给服务，让服务器计算下一个游戏循环，我们该在地图的什么位置，这显然是不合理的。而是我们计算好下个位置，然后把位置传给服务器。

同样的，交易情况也是一样。玩家A买了玩家B的店铺的商品X，自然，玩家A处理"买了玩家B商品X"，玩家B处理"卖给玩家A商品X"，然后各自处理相关的信息，并各自把最终结果发给服务器。这样做可以减少服务器的负担，而且也不会太影响客户端的速度。

所以这个如果是纯算法题确实有很多要思考，如果实际情况，显然这是不合理的。

OpenGPU

可以参考IBM给银行系统作的数据库


：〉


-------------------------------------------------------------------------------------------

欢迎访问开源图形处理器体系结构论坛(OpenGPU论坛) http://www.opengpu.org/bbs/

OpenGPU Graphics Open Source community（图形开源社区），聚焦领域(focus domain)包括：
  * GPU Architecture（图形处理器体系结构）
  * Graphics Algorithm（图形算法）
  * GPGPU Programming （面向通用的图形处理器编程）
  * Open Source Rendering Engine（开源渲染器）
  * Open Source GPU Simulator/RTL Implement（开源GPU模拟器

cyagi

OpenGPU: Re:[讨论]一个游戏结算程序的设计

可以参考IBM给银行系统作的数据库


：〉


-----------------------------------------------------...

传说中的“IBM给银行系统作的数据库”在什么地方有呢？