围棋游戏逻辑判断在客户端还是服务端好
这个我来说说吧。本人是烂柯围棋网的作者，烂柯围棋所有下棋逻辑都在客户端，这样做有利也有弊，从现在网站的15万盘对弈量来看，利完全大于弊。先说缺点：当对弈双方（含观众）间有数据包丢失时（如某一方的落子消息没有传到另一方），会发生双方棋盘盘面不一致的情况，这时本地的逻辑控制会导致不允许某方落子，此局只能报废。这种情况在烂柯目前的15万盘中，出现过10盘左右，占比0.0067%，当时急于查看日志和分析原因，没有向用户询问他们的网络情况。如果所有逻辑放服务器端，就不会出现这种情况，大不了用户重进一下房间，从服务器获取最新棋谱就行了。再来说优点：速度快。具体是，1）判断能否落子快。对弈时，鼠标在棋盘上每移动一下，都需要向逻辑请求此位置是否能落子，如果逻辑在服务端，请求和响应会有延迟，比上面的缺点更加依赖网速。2）形势判断快。如果逻辑是服务器端，用户点击形势判断后，步骤应该是这样：向服务器请求形势判断、服务器从内存中取出此盘棋棋谱、运算、返回判断结果、前端显示。如果放在本地，则又与网速无关，本地判断完显示。这样即减少了服务器的运算压力，也减少了数据流量。烂柯围棋的形势判断做的不是很好，但响应很快，从点击到显示结果看不到延迟。3）复盘方便。这个就不多说了，所有棋谱都在本地，前进后退、试下、标记等操作都与服务器无关，如有观众，需要将操作同步发向服务器，服务器再转发到观众端。如果是用户查看自己或他人的棋谱，在本地打谱，那就完全与服务器无关，相当于一个客户端软件。另外，如果有一盘棋下到中盘，此时进来一个观众，观众想从头打谱看看进程，这些也完全在本地完成，无需服务器，这几种情况下能明显减服务器开销。4）点目速度快。这个同形势判断。再说一下你提的安全问题，如果你指的客户端是一个编译好的可执行文件，没有此问题。如果你所说的客户端是指浏览器脚本（烂柯围棋即是这种情况），可以对逻辑部分进行混淆再发布。退一步讲，如果用户对脚本做了人为修改，那么出问题也是在他那一端，并不影响其它用户，也不影响你的服务器。欢迎拍砖。
■网友
谢邀。其实怎么做都可以，你担心的都不是什么问题。服务器做逻辑判断当然值得提倡，没你想的那么耗cpu，也没多少时间代价。关键你会不会写出来，能写出来就行了。客户端嘛不做判断也行，大不了服务器打回来再考虑怎么办。不过只要你会写，也是很简单的事情。关于服务器带宽，哪有什么带宽问题，人家带宽都是用来传视频的，你传个棋盘棋子三张图有什么值得考虑的。服务器只管转发而不验证也不是绝对不行，完全依赖客户端也行。当然，这样有被破解的可能，可是大部分用户才懒得破解你的东西。可能用户玩都懒得玩，现实很残酷。记住这句话：过早地优化是万恶之源。先写出来能用再说。---我们的东西，当然是客户端和服务器的验证逻辑都有，js，objective c，unity，android，ruby 。毕竟积累这么久，这么多用户，也该完善了，有的逻辑基本上我就是逐行人工翻译到另一种语言的；不过每次做新产品的时候，也是首先保证服务器的逻辑，客户端的相关代码放在那里，懒得去调用，实在有问题影响用户体验的时候再去调用。
■网友
客户端包含所有或部分的逻辑，以便在用户落子或其他操作时，可以及时快速的做无效性判断及提示，提高用户体验。服务端包含所以操作合法性校验逻辑，防止客户端作弊及保证逻辑完整性。现今的网络环境状态及服务端性能可以轻松解决这些问题。
■网友
据我所知当前主流围棋对弈平台(如弈城，野狐等)的所有版本客户端都包含有完整的游戏逻辑，但服务器验证似乎是必须的。
■网友
为@白起的答案点了赞同，但还是想多说几句。如果题主是想写个玩具的话，最要紧的是开始写……如果是想从事商业软件研发，面向海量用户，而围棋是业务内容之一的话，那么建议系统学习操作系统和分布式系统，掌握“估算”技能。我们不讲过早优化，但也绝不是放任自流再秋后算账，我们讲控制。你担心的这些，都是可以在写代码前就算明白的。当然，估算结论依然还是白起的答案，只是你不再需要问整整这一类的问题了。例外：如果你是写人机对战，要弄个AI的话……你说的这些就都不是重点了
推荐阅读
- 玩游戏花钱最多的有哪些游戏，哪些人
- 侧重业务逻辑的产品需求规格说明书，需要有哪些要点
- 游戏中有哪些让人感动的情节
- 为啥没有纯WAP的手机游戏媒体
- LOL国服第一剑圣开场画面刀光剑影把骑兵砍下马的白发剑客是游戏人物还是动漫人物
- 游戏公司一般咋识别游戏脚本
- 应届生选一个比较大的互联网公司还是一个小但赚钱的游戏公司好
- 求一个2011年左右ios平台的游戏！！！难道就没人玩过
- 网游职业玩家咋赚钱的
- 游戏公司怎样招聘到SEO推广经理?