背景: 我的朋友是开连锁网吧的, 他想让我帮他开发个能在局域网内玩的麻将游戏.
思路: 我想建立一个服务器, 这个服务器能具备以下能力.
1) 能记住多个牌局的当前状态 (因可能局域网内同时有5-10个麻将局, 每个麻将局局4个人, 那一共就是40个人在玩)
2) 每次在一个玩家摸牌后, 自动告诉另外3个玩家, 牌被摸少了一个.
3) 记住被摸的是什么牌
技术要求: 我需要这服务器有 !!! 极高的响应速度 !!! (毕竟我在朋友眼中是技术大咖, 如果开发个程序这么慢, 会被笑爆),
困难与问题:
1) 我没做过服务器的开发, 我只会用C#, 我到底该选用 .net Remoting 还是 WCF 来做?
2) 有没可能做成windows Service的形式, 因为是局域网, win srv 会比上面那2个快吗?
3) 或者有没其他的架构能推荐给我? 原谅我只会c#
28 个解决方案
#1
还是买个现成的游戏吧。做这东西有什么意义?你本身技术水平就不行,做的东西还没有价值,简直是浪费生命。
#2
1.你这游戏根本没必要搞什么服务器架构,写个cs最简单,bs稍微麻烦点,当然非要用wcf这类也可以。
2.楼主要求的游戏结构随便搞个计算机速度都够,更何况是局域网。
3.看1个2
2.楼主要求的游戏结构随便搞个计算机速度都够,更何况是局域网。
3.看1个2
#3
兄弟... 你这样说话我听了很难过
#4
前辈你好, 我就是想搞个cs的啊, 那我把server放在局域网的一个电脑上
让别的client端能连就好
我就这个意思, 做这个不用remoating和wcf吗?
#5
wcf或其它主要用于分布式开发,集中服务,管理资源,而楼主的项目只是简单的游戏数据传输和牌局管理,用wcf之类有点大材小用。而且对于楼主这种几十个用户的棋牌游戏来说,服务器上的代码主要作用是处理客户端发来的逻辑数据,并做逻辑处理运算,再回传给客户端,而其它方面需求很少。因此服务器代码只要做好以上功能即可。等楼主的游戏做大,能发布到互联网上,有成千上万用户时,就有用户管理,游戏附加服务,论坛,积分等等管理时,分布开发利器wcf类开发环境就大有用处了。
#6
那前辈你的意思我听明白了是做个CS程序, 我本来就是要做CS的
我只是说, 这用什么技术好
你说的对, 现在网吧也就几十人用, 可能WCF实在是大材小用
所以我重点现在是速度啊, 我就是我写的麻将程序快点, 稳定点, 所以就问架构.
那现在结论是啥呢, 我用.net remoating 吗? 还是有别的更简单的建议吗?
#7
如果你熟悉 Remoting,那么就用 Remoting。你是否了解 Remoting 中,假设服务器要触发一个事件、客户端要捕获事件,如何编程?(Remoting并不能直接触发事件,需要自己开发一个事件代理类型,才能触发事件)
所谓“保证速度”,首当其冲地就是要求双向以通讯的模式来设计,不是很自然地支持双向。
当你有 40 人同时操作的时候,你至少要满足80人同时使用,才能稳定可用。
另外,在业务逻辑设计上,其实客户端只是显示用。比如说一个人操作的客户端,不可能让次客户端拿到别人的客户端摸了什么牌的信息数据。真正的其它数据都在服务器上,并不传给所有的客户端。那么这套业务逻辑设计其实才是应该占用你最多时间的,而不是用一堆编程技术名词儿来占用你大量时间。
因此假设你确实熟悉 Remoting,那么就用 Remoting。你熟悉他,可能说明他没有那么大的坑。
所谓“保证速度”,首当其冲地就是要求双向以通讯的模式来设计,不是很自然地支持双向。
当你有 40 人同时操作的时候,你至少要满足80人同时使用,才能稳定可用。
另外,在业务逻辑设计上,其实客户端只是显示用。比如说一个人操作的客户端,不可能让次客户端拿到别人的客户端摸了什么牌的信息数据。真正的其它数据都在服务器上,并不传给所有的客户端。那么这套业务逻辑设计其实才是应该占用你最多时间的,而不是用一堆编程技术名词儿来占用你大量时间。
因此假设你确实熟悉 Remoting,那么就用 Remoting。你熟悉他,可能说明他没有那么大的坑。
#8
不是很自然地支持双向 --> 不是很自然地支持双向的通讯机制就不要轻易使用
具体地说,前些年web 时代许多比较初级的“查询web服务器”的简单方式,并不能针对你的这种场景。它们主要是用在办公OA里边做增删改查的web界面,感觉按照教程调用服务器端发布的方法接口就行了,.net 能自动对参数进行序列化是很牛似地,而程序员更加不可能自己来设计和调试通讯代码。过了这么多年,它们的场景也还是那样,主要是做的OA之类的程序,这些程序基本上就是客户端去“录入、查询”,程序员只做界面开发而不做通讯架构设计开发。
对于你的场景,基本上就可以抛开这些,使用天然地是面向c/s的双向通讯(而不是单向查询)的并且比较能够深入到通讯架构的方式,可以避免把一个交互式游戏做成传统OA。
不过 remoting 大致在10年前,就很少人用了。做界面做OA的人去用 .net 的 webservice,而做通讯的人依然是使用 socket 或者直接 http 基本方式,两极分化。那么内部相当复杂的 remoting 维护起来就有些麻烦,遇到调试问题,你可能找不到好的教程、没有社区来讨论。
具体地说,前些年web 时代许多比较初级的“查询web服务器”的简单方式,并不能针对你的这种场景。它们主要是用在办公OA里边做增删改查的web界面,感觉按照教程调用服务器端发布的方法接口就行了,.net 能自动对参数进行序列化是很牛似地,而程序员更加不可能自己来设计和调试通讯代码。过了这么多年,它们的场景也还是那样,主要是做的OA之类的程序,这些程序基本上就是客户端去“录入、查询”,程序员只做界面开发而不做通讯架构设计开发。
对于你的场景,基本上就可以抛开这些,使用天然地是面向c/s的双向通讯(而不是单向查询)的并且比较能够深入到通讯架构的方式,可以避免把一个交互式游戏做成传统OA。
不过 remoting 大致在10年前,就很少人用了。做界面做OA的人去用 .net 的 webservice,而做通讯的人依然是使用 socket 或者直接 http 基本方式,两极分化。那么内部相当复杂的 remoting 维护起来就有些麻烦,遇到调试问题,你可能找不到好的教程、没有社区来讨论。
#9
关于“有没有可能windows service形式”的问题,其实除非你说的服务器是 asp.net 网站,也就是说你要用它来作为动态网页的生成器,否则你当然应该使用 windows service。
我们说服务器开发,就是指 windows service开发。而asp.net 其实是客户端,用来产生网页的。
对于基本的 http 服务(包括WCF服务),windows service 是可以承载的。而windows service当然还承载其它形式服务器。所以这就看你到底是不是特别特别喜欢用 asp.net 网页形式去设计某些东西(就好象有的刚学几个月关系数据库、痴迷于sql语句的的人,连给几万个数据排序,都要写到数据库表,然后排序读取数据)。如果你不是痴迷于什么前端(winform、WPF、asp.net、javascript系列)开发,那么你对于服务器端的设计当然是基于、承载在 windows service 上的 c# 服务器程序。
我们说服务器开发,就是指 windows service开发。而asp.net 其实是客户端,用来产生网页的。
对于基本的 http 服务(包括WCF服务),windows service 是可以承载的。而windows service当然还承载其它形式服务器。所以这就看你到底是不是特别特别喜欢用 asp.net 网页形式去设计某些东西(就好象有的刚学几个月关系数据库、痴迷于sql语句的的人,连给几万个数据排序,都要写到数据库表,然后排序读取数据)。如果你不是痴迷于什么前端(winform、WPF、asp.net、javascript系列)开发,那么你对于服务器端的设计当然是基于、承载在 windows service 上的 c# 服务器程序。
#10
你这网吧没网吗?
谁会去玩你这玩意...QQ游戏支持N种麻将局域网 自己建房也是支持的..
所以我非常统一1#的说法...
别闲的了..有这时间好好工作不好吗?把手里的工作效率提升一下.轻松点 比什么都强..一天净整那些没用的...
谁会去玩你这玩意...QQ游戏支持N种麻将局域网 自己建房也是支持的..
所以我非常统一1#的说法...
别闲的了..有这时间好好工作不好吗?把手里的工作效率提升一下.轻松点 比什么都强..一天净整那些没用的...
#11
如果楼主说的是怎么快速开发的速度,那其实我之前说明也提到过。因为你的需求对于编码要求的重点在于处理客户端发来的抓牌打牌等信息,以及简单的客户信息管理和牌局胜负结果管理,所以服务器除了麻将规则代码外就是上述功能代码了。
那么就简单的一块块说。
客户打牌的信息处理是在麻将规则基础上的判读处理,所以只要规则代码完善,这种判读又需要多少代码呢?答案肯定是很少。
至于牌局胜负和客户信息管理主要在于建立一个数据库,保存好登录信息,id,附加信息,再来个附加表保存牌局id,时间,胜负结果等即可。
综上,楼主的服务器工作主要有:麻将规则制定,数据库制定,socket通讯,数据库操作。客户端工作主要有:socket通讯,界面,登录信息处理。有经验的程序员一看即知,代码工作量普通,而且很多可以拿来主义。
如果非要用某种架构去做的话,上述工作也是必须做的,并不会减少,而且还会多架构设计,特定接口设计等代码。
说了这么多,无非就是一句话,用特定框架也罢,架构也罢,你该做的工作一点也不会减少,反而会多出目前来说无用的工作来。
那么就简单的一块块说。
客户打牌的信息处理是在麻将规则基础上的判读处理,所以只要规则代码完善,这种判读又需要多少代码呢?答案肯定是很少。
至于牌局胜负和客户信息管理主要在于建立一个数据库,保存好登录信息,id,附加信息,再来个附加表保存牌局id,时间,胜负结果等即可。
综上,楼主的服务器工作主要有:麻将规则制定,数据库制定,socket通讯,数据库操作。客户端工作主要有:socket通讯,界面,登录信息处理。有经验的程序员一看即知,代码工作量普通,而且很多可以拿来主义。
如果非要用某种架构去做的话,上述工作也是必须做的,并不会减少,而且还会多架构设计,特定接口设计等代码。
说了这么多,无非就是一句话,用特定框架也罢,架构也罢,你该做的工作一点也不会减少,反而会多出目前来说无用的工作来。
#12
意义何在?网吧有两个人想打麻将的话老板给找人凑一桌?网上有联网的麻将游戏吧,建个桌不就完了,还可以保留牌谱,不管你是熟人打两把还是想赌点啥的都不耽误啊
还是说老师/猪八戒的老板就是这么个要求?我觉得业务逻辑比技术更重要,毕竟你十桌也就四十个人,保证弄齐各种规则不出bug反倒比较麻烦
还是说老师/猪八戒的老板就是这么个要求?我觉得业务逻辑比技术更重要,毕竟你十桌也就四十个人,保证弄齐各种规则不出bug反倒比较麻烦
#13
麻将么和下棋原理差不多吧,你参考着看
https://pan.baidu.com/s/1kUKZnSF
https://pan.baidu.com/s/1kUKZnSF
#14
多谢这个大哥, 码了这么多的字教导我.
看了您的回复我大概知道了, 总结一下就是:
1. 我的程序当然是一个CS架构的程序(我寻求适合我的CS架构的建议)
2. WCF太高大上, 不合适.
3. Remoting属于过时的, 即使不过时, 也更适合OA这种(修改数据库为主的)场景. 而我的场景更像: 在Server端有记录 分析 功能的服务.
4. 您提到web Service, 我在学.net的时候就学过这个, 当时给我的感觉是类似java bean的一个微软方案. 我觉得如果我选择web service, 对我来说应该是可行的方向.
5. 鉴于<4>, 我想问几个问题:
问题1) 我记得web Service当时微软的文档是(跨平台的服务提供方案), 但是我的方向是局域网内的快速响应服务. 这两点有冲突吗,? (毕竟跨平台必然会导致xml对传输数据的封装和解封, 会对性能有一定的影响)
问题2) 我其实懂得怎么开发麻将, 那我能把开发好的单机麻将程序简单地 改 成一个webService+客户端吗? (客户端和服务端的沟通其实很简单, 就3个函数: a. 获得当前桌面所有公开牌信息+3个对手信息的 TableInfo(), b.向服务器请求摸到的下一个牌 GiveMe(), c.以及把丢出去的牌告诉服务器的Out() )
#15
多谢这个大哥, 码了这么多的字教导我.
看了您的回复我大概知道了, 总结一下就是:
1. 我的程序当然是一个CS架构的程序(我寻求适合我的CS架构的建议)
2. WCF太高大上, 不合适.
3. Remoting属于过时的, 即使不过时, 也更适合OA这种(修改数据库为主的)场景. 而我的场景更像: 在Server端有记录 分析 功能的服务.
4. 您提到web Service, 我在学.net的时候就学过这个, 当时给我的感觉是类似java bean的一个微软方案. 我觉得如果我选择web service, 对我来说应该是可行的方向.
5. 鉴于<4>, 我想问几个问题:
问题1) 我记得web Service当时微软的文档是(跨平台的服务提供方案), 但是我的方向是局域网内的快速响应服务. 这两点有冲突吗,? (毕竟跨平台必然会导致xml对传输数据的封装和解封, 会对性能有一定的影响)
问题2) 我其实懂得怎么开发麻将程序, 那我能把开发好的单机麻将程序简单地 改 成一个webService+客户端吗? (客户端其实很简单, 就3个函数: a. 获得当前桌面所有公开牌信息+3个对手信息的 TableInfo(), b.向服务器请求摸到的下一个牌 GiveMe(), c.以及把丢出去的牌告诉服务器的Out() )
#16
感谢. 感谢. 感谢.
重要事情说3次
#17
几十个人 局域网 就能让你扯上快速响应这样的词?这和拓海开着86在秋明山下坡 你担心他下坡速度有什么区别。。。
你先能做一个单击版本再继续吧 还有你的UI 你总得有一副麻将的图像吧 一个麻将桌的图像吧 还有一些游戏中的特效 杠或者自摸的时候。等这些都搞定了 那么 这个程序若是把出牌什么的动作换成网络传递过来 那么勉强可以做一个服务器 然UI在客户端上显示 再加上一对逻辑就差不多了
你先能做一个单击版本再继续吧 还有你的UI 你总得有一副麻将的图像吧 一个麻将桌的图像吧 还有一些游戏中的特效 杠或者自摸的时候。等这些都搞定了 那么 这个程序若是把出牌什么的动作换成网络传递过来 那么勉强可以做一个服务器 然UI在客户端上显示 再加上一对逻辑就差不多了
#18
S和c分离的,s一般框架都有好几个服务器,网上不少呢,只是实现起来,你还得包括测试,网络部分更加麻烦,即使代码量少,但是测试都得花个一年半载的,各种逻辑业务,你朋友支撑得起一两年的开发时间?
#19
不如放几张麻将桌。
#20
#21
本质就是网络通讯 和 棋牌业务 。
#22
这种小规模、简单程序,socket最基本的功能都能实现,就增加几十个线程(每链接用户开一个)。
规则判断在客户端,服务端只传递房间号、用户人数、是否开始、出牌数组,发给当前房间用户,用户动作(什么碰胡之类)传递给服务端(每个用户所属的线程)再反馈客户端刷新牌。
这扯得上web Service么?高大上好玩是不?
规则判断在客户端,服务端只传递房间号、用户人数、是否开始、出牌数组,发给当前房间用户,用户动作(什么碰胡之类)传递给服务端(每个用户所属的线程)再反馈客户端刷新牌。
这扯得上web Service么?高大上好玩是不?
#23
用socket比较好,这个做起来还是要耗点时间的,各种逻辑,界面美化,声音效果弄起来太麻烦。
#24
我感觉你这个还是比较简单的,我这个做:服务器加花生壳加客户端通信,你有这方面的开发经验吗?
#25
有没有用过花生壳做内网穿透的经验
#26
有麻将桌谁愿意上网玩麻将啊
#27
建议直接买个九火游戏的麻将吧,个人是开发不了的。
#28
现在很多杂七杂八的,你可以咨询一下balabala72,她有很多成功案例
#1
还是买个现成的游戏吧。做这东西有什么意义?你本身技术水平就不行,做的东西还没有价值,简直是浪费生命。
#2
1.你这游戏根本没必要搞什么服务器架构,写个cs最简单,bs稍微麻烦点,当然非要用wcf这类也可以。
2.楼主要求的游戏结构随便搞个计算机速度都够,更何况是局域网。
3.看1个2
2.楼主要求的游戏结构随便搞个计算机速度都够,更何况是局域网。
3.看1个2
#3
兄弟... 你这样说话我听了很难过
#4
前辈你好, 我就是想搞个cs的啊, 那我把server放在局域网的一个电脑上
让别的client端能连就好
我就这个意思, 做这个不用remoating和wcf吗?
#5
wcf或其它主要用于分布式开发,集中服务,管理资源,而楼主的项目只是简单的游戏数据传输和牌局管理,用wcf之类有点大材小用。而且对于楼主这种几十个用户的棋牌游戏来说,服务器上的代码主要作用是处理客户端发来的逻辑数据,并做逻辑处理运算,再回传给客户端,而其它方面需求很少。因此服务器代码只要做好以上功能即可。等楼主的游戏做大,能发布到互联网上,有成千上万用户时,就有用户管理,游戏附加服务,论坛,积分等等管理时,分布开发利器wcf类开发环境就大有用处了。
#6
那前辈你的意思我听明白了是做个CS程序, 我本来就是要做CS的
我只是说, 这用什么技术好
你说的对, 现在网吧也就几十人用, 可能WCF实在是大材小用
所以我重点现在是速度啊, 我就是我写的麻将程序快点, 稳定点, 所以就问架构.
那现在结论是啥呢, 我用.net remoating 吗? 还是有别的更简单的建议吗?
#7
如果你熟悉 Remoting,那么就用 Remoting。你是否了解 Remoting 中,假设服务器要触发一个事件、客户端要捕获事件,如何编程?(Remoting并不能直接触发事件,需要自己开发一个事件代理类型,才能触发事件)
所谓“保证速度”,首当其冲地就是要求双向以通讯的模式来设计,不是很自然地支持双向。
当你有 40 人同时操作的时候,你至少要满足80人同时使用,才能稳定可用。
另外,在业务逻辑设计上,其实客户端只是显示用。比如说一个人操作的客户端,不可能让次客户端拿到别人的客户端摸了什么牌的信息数据。真正的其它数据都在服务器上,并不传给所有的客户端。那么这套业务逻辑设计其实才是应该占用你最多时间的,而不是用一堆编程技术名词儿来占用你大量时间。
因此假设你确实熟悉 Remoting,那么就用 Remoting。你熟悉他,可能说明他没有那么大的坑。
所谓“保证速度”,首当其冲地就是要求双向以通讯的模式来设计,不是很自然地支持双向。
当你有 40 人同时操作的时候,你至少要满足80人同时使用,才能稳定可用。
另外,在业务逻辑设计上,其实客户端只是显示用。比如说一个人操作的客户端,不可能让次客户端拿到别人的客户端摸了什么牌的信息数据。真正的其它数据都在服务器上,并不传给所有的客户端。那么这套业务逻辑设计其实才是应该占用你最多时间的,而不是用一堆编程技术名词儿来占用你大量时间。
因此假设你确实熟悉 Remoting,那么就用 Remoting。你熟悉他,可能说明他没有那么大的坑。
#8
不是很自然地支持双向 --> 不是很自然地支持双向的通讯机制就不要轻易使用
具体地说,前些年web 时代许多比较初级的“查询web服务器”的简单方式,并不能针对你的这种场景。它们主要是用在办公OA里边做增删改查的web界面,感觉按照教程调用服务器端发布的方法接口就行了,.net 能自动对参数进行序列化是很牛似地,而程序员更加不可能自己来设计和调试通讯代码。过了这么多年,它们的场景也还是那样,主要是做的OA之类的程序,这些程序基本上就是客户端去“录入、查询”,程序员只做界面开发而不做通讯架构设计开发。
对于你的场景,基本上就可以抛开这些,使用天然地是面向c/s的双向通讯(而不是单向查询)的并且比较能够深入到通讯架构的方式,可以避免把一个交互式游戏做成传统OA。
不过 remoting 大致在10年前,就很少人用了。做界面做OA的人去用 .net 的 webservice,而做通讯的人依然是使用 socket 或者直接 http 基本方式,两极分化。那么内部相当复杂的 remoting 维护起来就有些麻烦,遇到调试问题,你可能找不到好的教程、没有社区来讨论。
具体地说,前些年web 时代许多比较初级的“查询web服务器”的简单方式,并不能针对你的这种场景。它们主要是用在办公OA里边做增删改查的web界面,感觉按照教程调用服务器端发布的方法接口就行了,.net 能自动对参数进行序列化是很牛似地,而程序员更加不可能自己来设计和调试通讯代码。过了这么多年,它们的场景也还是那样,主要是做的OA之类的程序,这些程序基本上就是客户端去“录入、查询”,程序员只做界面开发而不做通讯架构设计开发。
对于你的场景,基本上就可以抛开这些,使用天然地是面向c/s的双向通讯(而不是单向查询)的并且比较能够深入到通讯架构的方式,可以避免把一个交互式游戏做成传统OA。
不过 remoting 大致在10年前,就很少人用了。做界面做OA的人去用 .net 的 webservice,而做通讯的人依然是使用 socket 或者直接 http 基本方式,两极分化。那么内部相当复杂的 remoting 维护起来就有些麻烦,遇到调试问题,你可能找不到好的教程、没有社区来讨论。
#9
关于“有没有可能windows service形式”的问题,其实除非你说的服务器是 asp.net 网站,也就是说你要用它来作为动态网页的生成器,否则你当然应该使用 windows service。
我们说服务器开发,就是指 windows service开发。而asp.net 其实是客户端,用来产生网页的。
对于基本的 http 服务(包括WCF服务),windows service 是可以承载的。而windows service当然还承载其它形式服务器。所以这就看你到底是不是特别特别喜欢用 asp.net 网页形式去设计某些东西(就好象有的刚学几个月关系数据库、痴迷于sql语句的的人,连给几万个数据排序,都要写到数据库表,然后排序读取数据)。如果你不是痴迷于什么前端(winform、WPF、asp.net、javascript系列)开发,那么你对于服务器端的设计当然是基于、承载在 windows service 上的 c# 服务器程序。
我们说服务器开发,就是指 windows service开发。而asp.net 其实是客户端,用来产生网页的。
对于基本的 http 服务(包括WCF服务),windows service 是可以承载的。而windows service当然还承载其它形式服务器。所以这就看你到底是不是特别特别喜欢用 asp.net 网页形式去设计某些东西(就好象有的刚学几个月关系数据库、痴迷于sql语句的的人,连给几万个数据排序,都要写到数据库表,然后排序读取数据)。如果你不是痴迷于什么前端(winform、WPF、asp.net、javascript系列)开发,那么你对于服务器端的设计当然是基于、承载在 windows service 上的 c# 服务器程序。
#10
你这网吧没网吗?
谁会去玩你这玩意...QQ游戏支持N种麻将局域网 自己建房也是支持的..
所以我非常统一1#的说法...
别闲的了..有这时间好好工作不好吗?把手里的工作效率提升一下.轻松点 比什么都强..一天净整那些没用的...
谁会去玩你这玩意...QQ游戏支持N种麻将局域网 自己建房也是支持的..
所以我非常统一1#的说法...
别闲的了..有这时间好好工作不好吗?把手里的工作效率提升一下.轻松点 比什么都强..一天净整那些没用的...
#11
如果楼主说的是怎么快速开发的速度,那其实我之前说明也提到过。因为你的需求对于编码要求的重点在于处理客户端发来的抓牌打牌等信息,以及简单的客户信息管理和牌局胜负结果管理,所以服务器除了麻将规则代码外就是上述功能代码了。
那么就简单的一块块说。
客户打牌的信息处理是在麻将规则基础上的判读处理,所以只要规则代码完善,这种判读又需要多少代码呢?答案肯定是很少。
至于牌局胜负和客户信息管理主要在于建立一个数据库,保存好登录信息,id,附加信息,再来个附加表保存牌局id,时间,胜负结果等即可。
综上,楼主的服务器工作主要有:麻将规则制定,数据库制定,socket通讯,数据库操作。客户端工作主要有:socket通讯,界面,登录信息处理。有经验的程序员一看即知,代码工作量普通,而且很多可以拿来主义。
如果非要用某种架构去做的话,上述工作也是必须做的,并不会减少,而且还会多架构设计,特定接口设计等代码。
说了这么多,无非就是一句话,用特定框架也罢,架构也罢,你该做的工作一点也不会减少,反而会多出目前来说无用的工作来。
那么就简单的一块块说。
客户打牌的信息处理是在麻将规则基础上的判读处理,所以只要规则代码完善,这种判读又需要多少代码呢?答案肯定是很少。
至于牌局胜负和客户信息管理主要在于建立一个数据库,保存好登录信息,id,附加信息,再来个附加表保存牌局id,时间,胜负结果等即可。
综上,楼主的服务器工作主要有:麻将规则制定,数据库制定,socket通讯,数据库操作。客户端工作主要有:socket通讯,界面,登录信息处理。有经验的程序员一看即知,代码工作量普通,而且很多可以拿来主义。
如果非要用某种架构去做的话,上述工作也是必须做的,并不会减少,而且还会多架构设计,特定接口设计等代码。
说了这么多,无非就是一句话,用特定框架也罢,架构也罢,你该做的工作一点也不会减少,反而会多出目前来说无用的工作来。
#12
意义何在?网吧有两个人想打麻将的话老板给找人凑一桌?网上有联网的麻将游戏吧,建个桌不就完了,还可以保留牌谱,不管你是熟人打两把还是想赌点啥的都不耽误啊
还是说老师/猪八戒的老板就是这么个要求?我觉得业务逻辑比技术更重要,毕竟你十桌也就四十个人,保证弄齐各种规则不出bug反倒比较麻烦
还是说老师/猪八戒的老板就是这么个要求?我觉得业务逻辑比技术更重要,毕竟你十桌也就四十个人,保证弄齐各种规则不出bug反倒比较麻烦
#13
麻将么和下棋原理差不多吧,你参考着看
https://pan.baidu.com/s/1kUKZnSF
https://pan.baidu.com/s/1kUKZnSF
#14
多谢这个大哥, 码了这么多的字教导我.
看了您的回复我大概知道了, 总结一下就是:
1. 我的程序当然是一个CS架构的程序(我寻求适合我的CS架构的建议)
2. WCF太高大上, 不合适.
3. Remoting属于过时的, 即使不过时, 也更适合OA这种(修改数据库为主的)场景. 而我的场景更像: 在Server端有记录 分析 功能的服务.
4. 您提到web Service, 我在学.net的时候就学过这个, 当时给我的感觉是类似java bean的一个微软方案. 我觉得如果我选择web service, 对我来说应该是可行的方向.
5. 鉴于<4>, 我想问几个问题:
问题1) 我记得web Service当时微软的文档是(跨平台的服务提供方案), 但是我的方向是局域网内的快速响应服务. 这两点有冲突吗,? (毕竟跨平台必然会导致xml对传输数据的封装和解封, 会对性能有一定的影响)
问题2) 我其实懂得怎么开发麻将, 那我能把开发好的单机麻将程序简单地 改 成一个webService+客户端吗? (客户端和服务端的沟通其实很简单, 就3个函数: a. 获得当前桌面所有公开牌信息+3个对手信息的 TableInfo(), b.向服务器请求摸到的下一个牌 GiveMe(), c.以及把丢出去的牌告诉服务器的Out() )
#15
多谢这个大哥, 码了这么多的字教导我.
看了您的回复我大概知道了, 总结一下就是:
1. 我的程序当然是一个CS架构的程序(我寻求适合我的CS架构的建议)
2. WCF太高大上, 不合适.
3. Remoting属于过时的, 即使不过时, 也更适合OA这种(修改数据库为主的)场景. 而我的场景更像: 在Server端有记录 分析 功能的服务.
4. 您提到web Service, 我在学.net的时候就学过这个, 当时给我的感觉是类似java bean的一个微软方案. 我觉得如果我选择web service, 对我来说应该是可行的方向.
5. 鉴于<4>, 我想问几个问题:
问题1) 我记得web Service当时微软的文档是(跨平台的服务提供方案), 但是我的方向是局域网内的快速响应服务. 这两点有冲突吗,? (毕竟跨平台必然会导致xml对传输数据的封装和解封, 会对性能有一定的影响)
问题2) 我其实懂得怎么开发麻将程序, 那我能把开发好的单机麻将程序简单地 改 成一个webService+客户端吗? (客户端其实很简单, 就3个函数: a. 获得当前桌面所有公开牌信息+3个对手信息的 TableInfo(), b.向服务器请求摸到的下一个牌 GiveMe(), c.以及把丢出去的牌告诉服务器的Out() )
#16
感谢. 感谢. 感谢.
重要事情说3次
#17
几十个人 局域网 就能让你扯上快速响应这样的词?这和拓海开着86在秋明山下坡 你担心他下坡速度有什么区别。。。
你先能做一个单击版本再继续吧 还有你的UI 你总得有一副麻将的图像吧 一个麻将桌的图像吧 还有一些游戏中的特效 杠或者自摸的时候。等这些都搞定了 那么 这个程序若是把出牌什么的动作换成网络传递过来 那么勉强可以做一个服务器 然UI在客户端上显示 再加上一对逻辑就差不多了
你先能做一个单击版本再继续吧 还有你的UI 你总得有一副麻将的图像吧 一个麻将桌的图像吧 还有一些游戏中的特效 杠或者自摸的时候。等这些都搞定了 那么 这个程序若是把出牌什么的动作换成网络传递过来 那么勉强可以做一个服务器 然UI在客户端上显示 再加上一对逻辑就差不多了
#18
S和c分离的,s一般框架都有好几个服务器,网上不少呢,只是实现起来,你还得包括测试,网络部分更加麻烦,即使代码量少,但是测试都得花个一年半载的,各种逻辑业务,你朋友支撑得起一两年的开发时间?
#19
不如放几张麻将桌。
#20
#21
本质就是网络通讯 和 棋牌业务 。
#22
这种小规模、简单程序,socket最基本的功能都能实现,就增加几十个线程(每链接用户开一个)。
规则判断在客户端,服务端只传递房间号、用户人数、是否开始、出牌数组,发给当前房间用户,用户动作(什么碰胡之类)传递给服务端(每个用户所属的线程)再反馈客户端刷新牌。
这扯得上web Service么?高大上好玩是不?
规则判断在客户端,服务端只传递房间号、用户人数、是否开始、出牌数组,发给当前房间用户,用户动作(什么碰胡之类)传递给服务端(每个用户所属的线程)再反馈客户端刷新牌。
这扯得上web Service么?高大上好玩是不?
#23
用socket比较好,这个做起来还是要耗点时间的,各种逻辑,界面美化,声音效果弄起来太麻烦。
#24
我感觉你这个还是比较简单的,我这个做:服务器加花生壳加客户端通信,你有这方面的开发经验吗?
#25
有没有用过花生壳做内网穿透的经验
#26
有麻将桌谁愿意上网玩麻将啊
#27
建议直接买个九火游戏的麻将吧,个人是开发不了的。
#28
现在很多杂七杂八的,你可以咨询一下balabala72,她有很多成功案例