讨论：为何摒弃模型的碰撞体积

天堂御医

shoo6: Re:讨论：为何摒弃模型的碰撞体积

为什么要摒弃呢？

LZ你难道只想想做一个 角色可以穿墙的游戏？

LS你理解错LZ的意思了，他是说摒弃avatar与avatar之间的碰撞检测，不是avatar与场景的碰撞检测
其实这就是个资源开销的问题，对于一个网游来说，如果做了avatar之间碰撞检测，服务器的运算量太大了，然后就是服务器卡等等很差的用户体验，必然得不偿失。
但是单机游戏就比较普遍了，基于AABB包围盒的碰撞检测算法的本地资源开销并不是很大的

FRHusky

做这个碰撞的需求是什么？
这种碰撞说白了只是包围盒碰撞
唯一的区别只是包围盒的紧密程度
如果要写一个适用性强的算法，其服务器代价很高
但你需求明确，这个算法针对性强，诸多条件的限制可以大大加强效率，比如开房间。
然后用分布式服务器架构也能一定程度解决同服在线这方面的问题。
但是如果只是你想法中的
1.        使角色/物件的表现更加真实
这个和碰撞有啥关系？
2.        减少屏幕内的模型刷新压力
同屏用户在线？用建筑阻挡就行，WOW这方面是先驱
3.        拓展出多种玩法（DOTA？冰墙等隔断魔法？）
这种玩法是你最初定的核心玩法么？如果不是，那细细考下
另外要实现冰墙割断用格子就足够了。
如果你要玩家跳上冰墙，还能有其他方面行为，那也需要细细整理需求后针对性的做功能。
4.        用于搭建其他系统（无目标攻击，碰撞判断？）
还是那句话，是核心玩法么？（难道你是FPS？）

unrogue007

很早以前的游戏，大部分都有 人物、怪物、其他物件之间的碰撞关系，但随着时间的检验，证明了并不是越真实的模拟，玩家就会越喜欢，毕竟玩家是来游戏的。
1、玩家与玩家的碰撞：这会造成对NPC或特殊地理位置的长期占据，严重影响游戏的正常秩序；
2、玩家与怪物的碰撞：如果玩家与玩家之间的碰撞都取消了，那么遵从游戏统一性的原则，玩家与怪物的碰撞也应当取消，否则你在游戏中的感觉会非常奇怪。除非，游戏中的某个系统迫切需要玩家与怪物碰撞来支撑；
3、玩家与大型物件的碰撞：这必然是不能取消的；

从策划的角度来看，我们应当尽量减少某个并不实用的功能给玩家在游戏过程中制造不必要的障碍，这会降低玩家的游戏愉快感。

弹你小雀雀

FRHusky: Re:讨论：为何摒弃模型的碰撞体积

做这个碰撞的需求是什么？
这种碰撞说白了只是包围盒碰撞
唯一的区别只是包围盒的紧密程度
如果要写一个...

刚入行一年
越来越发现，如果想学，这行可以学的东西很多
现在我就像在一间黑暗的屋子里寻找和认知她，探究她地板的触感、摆放的家具以及屋子的边界
我还是一个菜鸟，很多东西还处于认知状态，还没有足够的信息足够我去分析创造出一个基于明确核心的新玩法
我发现最后几楼的几个前辈都很有经验（当然没有诋毁前面几楼的意思，只是觉得这几个前辈讲的更加详细）

从前辈的回复里，我了解到‘碰撞体积’确切的称呼应该是“包围盒”
百度以后我也了解到了一些信息
然后又有了点新的胡思乱想（只参与过一般2.5D MMORPG的开发）
想请教想法是否正确
--------------------------------------
1.前面有讲过“开房间”应该是可以大幅度减少服务端的压力（当然“开房间”和bigworld都有各自的优点）

“开房间”减少服务端的压力，是否只是因为减少了地图内的总‘单位’数量从而降低了服务器的峰值计算压力（在某种极端情况下，‘单位’数量过多会互相影响，从而导致计算量呈几何级数增长）

那这种情况其实并没有减少总的计算量，只不过用更多的模块来分摊了这些计算，降低了服务器的负载压力
但由于需要有更多的模块，实际上服务端的性能并没有得到提升?
--------------------------------------

2.现在暴雪似乎打算大力发展战网平台，是不是因为暴雪在战网中找到了性能与表现的新的平衡点?

不知道战网的实际原理，只是尝试性的通过HF、VS平台上WAR3联网的一些情况做了点推测：
通信方式
①.用户通过点对点通信方式将信息传给主机
（这里的信息指操作指令的信息，譬如'1号玩家在坐标X,Y处点击了A键'）
②.主机接收这些信息，维护统计所有用户的信息是否同步（如果有用户不同步则被踢掉）
③.主机将信息广播给每个联网用户

同步统计
①.主机为每个用户维护一张临时的数据表
②.数据表的内容包含每个英雄（还有小鸡等特殊单位）的经验、等级、属性、技能、装备、金钱等等信息
③.每当这类信息改变时，对比各个用户记录的信息是否同步，如果有人的数据跟大多数人不一样，则被踢掉

--------------------------------------
3.是否可以有一种这样的开房间模式
通信方式
①.所有单位的创建生成由服务端维护、验证和通知
②.用户将‘操作指令信息’广播给所有房间内的用户
③.服务端进行同步统计
④.房间结束后，上报个人信息，服务端进行收益验证，如果满足条件则有收益反之则无


同步统计
①.服务端为每个用户维护一张临时的数据表
②.与2相似，但表格内容根据需要变化
③.服务端收集任何有关收益的信息（譬如单位被摧毁、物品掉落、物品获得）
④.每当这类信息改变时，对比各个用户记录的信息是否同步，如果有人的数据跟大多数

人不一样，则将他踢掉

收益验证
①.开房间期间服务端收集任何有关收益的数据
②.对比统计每个用户的收益（与进入房间时的信息对比）
③.判断总收益是否相等（允许一定误差）
④.如果收益相等，则所有用户（被踢掉的用户除外）获得收益并记录；如果收益不等，分析异常来源（如果可以的话），通知各用户原因，所有用户不得收益

PS：PVP使用另一台独立的服务器处理（不同规则，或者说不同的game server?）

我觉得这样的好处是把大量的计算放到客户端，服务端只是做信任检测
缺点尚看不到【如果想到早就改了，希望没什么大错误丢人~~（当然我脸皮厚）[em11]】
疑问：丢包了怎么办？

FRHusky

楼主应该是策划吧
咱们两个半桶水不到的策划在这聊着架构、算法，实在是……
术业有专攻，如果程序是你的兴趣，那你大可以没事儿去学习了解。
但如果是为了做好游戏、做好策划，那么在日常的工作当中就足够你慢慢的了解了。其他时间，最好还是花在游戏内容的设计上。
国内策划的工作在新人看来非常繁杂，似乎什么都要会，而有经验的策划知道该在何时、何处点到为止。
可以会，但不要越俎代庖（除非万不得已的时候），因为你不够专业。
无论是什么架构、算法，都是为了满足设计者的需求，而设计者是为了满足客户（用户）的需求。
开房间，可以针对性的优化算法。
举个例子，比如开了一个10VS10的房间，此时的目的性非常明确。
敌10，我10。所有的角色在判定是否能被攻击的时候只有敌我之分，这个在进入房间的时候就被标记上了。而在大场景中，你可能要检查很多状态，红名，阵营等等
其次当一个用户的角色释放一个只能攻击对方的范围魔法的时候，检测该范围内的角色，一般都有通用性的算法，但是效率有限。
如果是开房间，很简单，检查对方十个玩家的位置就行，这种算法没啥通用性，但是非常适合当前的模式。
当然，这些只是一些我的理解，程序方面考虑的东西可能更多。但是，这一切的基础在于：策划有明确且详细的需求！
在这个基础上，你可以提供一套你所能想到的方案，也许很白，最多被程序鄙视下（咱们策划脸皮很厚的=。=！）。但是程序会根据你的需求提炼出他们所能想到的设计方案，这才是最关键的。
最后，你跑题真是专业级的……