想做一个这样的游戏，大家说可能吗？

[zzxxww]

想做一个这样的游戏，大家说可能吗？
一个网上即时战略游戏，
要求300个人同时玩（同一张地图），每个人至少指挥500个作战单位.

大家说说你们的看法!

[zzxxww]

to zsheng()
可能我不懂得你的行业用语吧，说真的，我没有做过游戏的（我原来是做封包分析的，网络编程可能比较强）。我做出来可能只是这个游戏的底层，华丽的游戏视觉，不是我的工作重点，我只会提供接口，由大家来开发游戏视觉吧!
这个游戏做出来后，图像可能很难看，在因为客户端大部分性能都用去同步运算了（150000个作战单位啊！）

[ensoniq]

>要与300个玩家交互：13*300＝3900字节 即31.2K带宽（3900 *8）。
>服务器网络带宽则需要：31.2K * 300＝9.4M

这里已经错了。首先你发出一个13字节的数据实际的包长度是多少？至少是40字节。亏你也是做过封包分析的。

其次，你暂停你的尝试吧，写个最简单的代码，通过随便哪个ISP的宽带接入，和稍微远些的随意一台机器发送IP包，每秒发送100个试试看，看看能够收到几个。

[zzxxww]

等我做出来再说吧,正在努力开发中...

[zzxxww]

具体设计方法请见:
一种新的网络即时战略游戏设计方法尝试
http://blog.csdn.net/zzxxww/archive/2007/05/07/1598982.aspx

[bigbook2000]

看过，方法很好，支持。

不过如果是Internet公共游戏可能会有问题，所有的状态是在客户端同步的，而我们通常所要面临的问题是，Internet公共网上的传输信息基本上都是值得怀疑的。不管是人为的还是客观的，修改了你的传输信息，就必须花费大量的资源来修正这个错误，保证整个游戏不至于崩溃。

另外，客户端的压力要远远大于服务器端，如果要在客户端实现数量可观的人工智能行为，不是所有机器都能承受的，加上碰到无裁剪的极端的显示现象，我想客户端和服务器的地位恐怕要交换了。

[zzxxww]

to ensoniq
这个游戏这么低的带宽（“三个坐标、一个点击”）都不可以实现，那么现时这么多网络游戏是如何做出来的？

封包分析方向是很多的，做封包分析主要是分析QQ、UC、网络游戏的封包的其质内容，那些包头包尾没有去研究。大哥你可以做出这些软件才可以怀疑我封包分析的资格：
我做过的软件有：QQ群发（全内核）
QQ号码全自动申请（当然验证码也是全自动识别的）
UC群发
三国群英传脱机外挂

[jyk1970]

提起即时战略游戏，
推荐 Chris Taylor 先生早期的《横扫千军》和近期的《最高指挥官》，
他们是相对于他们推出的年代而言的下一代游戏！
在他们面前，星际，红警之类的rts游戏不过是小儿科！！！
《横扫千军》一直被第三爱好者不断改进至今，

另外提醒搂主，每个单位不是一个坐标能够描述的，一个单位对应的3D模型有好多坐标（原地不动，角度不同迎击敌人的炮弹的面积是不同的），而敌人进攻的炮弹又是按实际物理运动轨迹处理的，炮弹也有坐标。。。

当年，俺跟实力相当的朋友们经常一场战役打到2~3个小时（很消耗脑力的）。
如果搂主有兴趣可以去http://bbs.taclub.net/taclub/newTA/加入队战群，去体验每个人带领多于1500个单位的大战役！

相信搂主一定大开眼界！

[zsheng]

居然还好意思说分析IP包，竟然IP通讯的"包头包尾没有去研究"，这就是神，你真神！

[67140170]

深圳软件公司招聘游戏开发程序员
因业务发展需要，需要若干熟悉vc的程序员；

要求：

1、熟悉GDI编程；
2、能用VC开发棋牌类游戏；
3、了解IOCP模型
4、热爱游戏


招聘QQ：67140170（注应聘）

[zzxxww]

to ensoniq() jyk1970()
获益良多啊！

[zzxxww]

送点ＱＱ号，就是 "包头包尾没有去研究 "，就可以开发出ＱＱ号自动申请。就这么神
ＱＱ号－－－－密码
185953957----z11223344
185956016----z11223344
173652544----z11223344
185957919----z11223344
185958545----z11223344
185962355----z11223344
185964267----z11223344
173662236----z11223344
173698173----z11223344
173699767----z11223344
173700530----z11223344
173701945----z11223344
173707566----z11223344
357590041----z11223344
173709447----z11223344
173712173----z11223344
173713029----z11223344
173713540----z11223344
173726107----z11223344
173727036----z11223344
173727774----z11223344
173733644----z11223344
173756597----z11223344
173757979----z11223344
751551457----z11223344
765928895----z11223344
173760106----z11223344
173762320----z11223344
173763712----z11223344
173764625----z11223344
765929055----z11223344
173770843----z11223344
173771755----z11223344
173774871----z11223344
173775701----z11223344
173783464----z11223344
173787247----z11223344
173791239----z11223344
173792153----z11223344
173792836----z11223344
735849930----z11223344
173804883----z11223344
173805807----z11223344
546378580----z11223344
173809610----z11223344
173810455----z11223344
173811467----z11223344
729305484----z11223344
173815080----z11223344
326064262----z12345678
729715520----z11223344
410760547----z11223344
331606627----z11223344
354059591----z11223344
707065768----z11223344
395940147----z11223344
354059953----z11223344
767514343----z11223344
419923852----z11223344
371461673----z11223344
326074901----z11223344
395951358----z11223344
407942407----z11223344
382997324----z11223344
546524586----z11223344
215054535----z11223344
277475365----z11223344
413913840----z11223344
362207691----z11223344
631916293----z11223344
215055190----z11223344
354065645----z11223344
383017004----z11223344
751897908----z11223344
767516685----z11223344

[zzxxww]

to jyk1970()
我的新的设计方法并没有

一种新的网络即时战略游戏设计方法尝试
http://blog.csdn.net/zzxxww/archive/2007/05/07/1598982.aspx

》》》
我设计这个游戏的中心思想是“万佛归一，同步运算”，只要极小的带宽就可能实现了，当然客户端的运算量会相当大

现在来说说我的主要这两个中心思想：

１．万佛归一

虽然地图上有成千上万个作战单位，但玩家指挥产生的真正的信息又有多少？

答案只是：三个坐标，一个点击。(想一想您自己玩星际争霸吧，大部分是划一个方框选中一群，然后攻击)

　　　　　选中作战单位的方框（X1Y1,X2Y2）:

要移动或进攻的地点！X3Y3

所以在300个玩家之间只需要传输“三个坐标，一个点击”(至少大部分这样)

一个坐标可能要两个16位整型（4个字节），那么“三个坐标，一个点击”要12+1个字节

要与300个玩家交互：13*300＝3900字节 即31.2K带宽（3900 *8）。

服务器网络带宽则需要：31.2K * 300＝9.4M

2.同步演绎

客户端只收到其它300个玩家客户端的的指挥性信息（300个“三个坐标，一个点击”），客户端要将这些信息在自已的电脑里演绎成一个激烈的战争！，

问题于300客户端联系只有“三个坐标，一个点击”，如何能只靠这些少量的指挥性信息，300个客户端同步演绎成一个激烈的战争。注意！所有客户端都要演绎成同一个世界，所有元素都是一致的，包括作战单位的坐标、移动方式，作战方式，一切一切，每秒每秒都要演绎一致。

例如:张三在自己的电脑上圈中一群坦克,向李四发动进攻.

张三的客户端会把圈中的方形坐标,与向李四的进攻坐标记录下了,向李四的客户端发送这些信息.

李四的客户端根据这些信息演绎这一进攻过程,同时张三也使用相同的算法演绎这一进攻过程.

如果万一台客户端在一个小的环节出错，就会出现“蝴蝶效应”，在这个客户端里就会天下大乱！

[ensoniq]

那我这样跟你说吧，你的想法本身没有太大的问题，蝴蝶效应的判断也是对的，只不过问题是：
首先，这种做法不是什么独创的东西，很久以前就有很多公司都尝试和实现过了，到前几年就已经在技术上非常成熟了，但实用的应用最多只到4人的casual game，人数更多的话就只能作为一种辅助手段存在。

其次，关于带宽，发送1000个字节，和发送100次10个字节，和发送100次10个字节给100个不同的人都是完全不同的概念。ISP给你声称的带宽，那都是最符合底层协议和路由器最优工作状态的理想带宽，如果你总是发送小包，那些带宽能发挥20%就不错了。

MMOG的客户端不存在这个问题，而服务器端，如果想你的服务器在几千个连接下还正常工作的话，你最好用TCP来让协议栈帮你做些封包合并。

[jyk1970]

搂主：
你好！

我感觉你的思路方向是正确的，早些年《横扫千军》的联网就是针对局域网的，我猜用的类似你目前的思路，现在联网对战还得先运行vnn（麻烦），而且如果有人网络不好，延迟大，就会出现瞬间移动或打不死等现象！
我想到了一个你忽略的情况：
延迟肯定是存在的，你应该考虑游戏中有一个虚拟的时钟，每一次传输命令必须附加虚拟时间信息，否则你的硬件在强也难以同步演绎。

建议你参考openttd（开源）的联网，这是以服务器为中心的，似乎更科学一些。
还有TASpring（开源）也可以参考。
另外，我推荐的那个对战群里有几个人擅长制作游戏mod，脚本一类的东西

[whoo]

想法很好，但就一个系统来说，还是需要很多专业性的咚咚的。建议楼主还是先研究研究已有的理论知识。

简单的泼点冷水：
这种结构的服务器只是个消息的转发者，充其量也只是个Fake Client，并无仲裁的权利，甚至客户间一旦连接，服务器的角色基本上就可有可无。
缺乏仲裁权的服务器在网游上是不可能被接受的，大家都自说自话，还有什么意思。

举例来说：每个人的网络带宽、响应都不一样（这是必然的）。即使是同时执行的动作，速度慢或者网络慢的电脑，其数据包总是较迟到达其他客户端，而且对于每个客户端，其达到的时机也是不一样的。即使只是10个人同时执行了一个动作，经过各自不同的网络后，每个人收到的其他人的动作的先后顺序都是不一样的，结果每个人都演绎出截然不同的结果，这个游戏还怎么玩？！

其实正常的网络游戏，都会用到这个方法，但是不可能只用它，也不可能把它当成主要的方法。一个能够正常运作的网络游戏，其服务器必然要负责仲裁，也就是必然要负起计算的责任。把计算简单的扔给客户端是不行的。 但是由于网络瓶颈的原因，服务器的仲裁结果可能会比较慢，加上客户端的网络连接(玩过网游的相信都有10k以上PING值的痛苦经历)问题，服务器的仲裁结果很难保证连续。这个时候才会使用楼主提到的方法，在客户端执行计算，以预测的结果来平滑化服务器的缓慢仲裁。
几乎所有的网游都会用到楼主的方法来进行客户端的行为预测演算，但是都会定时的根据服务器的仲裁结果来修正结果。如果你的PING值不好的情况下，你就会经常遇到预测演算和服务器仲裁不一致的情况：例如刚才你明明打死了妖怪，卡了一下，接下来你就直接挂了。又或者你明明跑了很远的路，突然一下子又回到了以前的位置，说不定还正在被怪物围攻。 这就是服务器的仲裁直接修正了你的本机预测结果。

[zsheng]

吓，还这么复杂。搂主不是说过了吗，你们所谓基础知识他不需要，别白费力气了，搞这么复杂，让他自己直接到达他想象的终点更好，哈哈

[flyingakain]

我说说这个游戏吧，这样的游戏，我不会去玩，300个人*500个单位，在一张图中混战，让人受不了，想想就很累~~

把上边的QQ号送给我吧，哈哈

[kennysun]

可以采用服务器阵列

按照地图块划分责权范围

例如10x10区块的地图 每台服务器负责若干块

游戏单位越界切换服务器的技术现在已经很成熟了

至于蝴蝶效应 在游戏中还是不会那么明显的 只需要小规模数据同步就可以了

单位没有靠近自己负责的区块时 此服务器都只需要接受其他服务器的统计数据就可以了 小地图显示的战况可以轮询 不需要完全实时

[kennysun]

其实这样的一张地图理解为一个世界比较合适

或者至少是一个地区 不单单是一块单机那样的地图了

有点类似阵营战 我觉得最需要解决的问题是战时决策的问题 一种有效的统一行动和指挥作战的机制 不然完全混战是没什么意思的

[hediant]

楼主的想法其实是为解决网游开发中固有的瓶颈问题而提出的设想和思考，不管想法在现在看来是否可行都应该鼓励，探讨了才能提供，别人没做的不代表我就做不出来的心是应该支持的。
既然是谈论，在此提醒楼主几个忽略的地方：
1、使用楼主所说的“同步演绎”，时间的同步问题是必须小心加以处理的；
2、楼主自己也注意到了蝴蝶效应，但是从楼主的方案上看不出有什么好的解决办法；
3、重点提醒的是安全性方面的考虑，缺少安全性的考虑只能是个摆设，因为他无法商业化。