骑士团Unity3D系列教程培训
Unity3D游戏开发之网络游戏服务器架构设计培训(如何做一名好主程) 今天给大家讲一下如何做一个好的主程 入手 假如，我现在接手一个新项目，我的身份还是主程序。在下属人员一一到位之前，在和制作人以及主策划充分沟通后，我需要先独自思考以下问题： 1、服务器跑在什么样的操作系统环境下？ 2、采用哪几种语言开发？主要是什么？ 3、服务器和客户端以什么样的接口通讯？ 4、采用哪些第三方的类库？ 除了技术背景之外，考虑这些问题的时候一定要充分考虑项目需求和所能拥有的资源。 我觉得，先不要想一组需要几台机器各有什么功能这样的问题，也不要想需要多少个daemon进程。假设就一台服务器，就一个进程，把所需要的资源往最小了考虑，把架构往最简单的方向想，直到发现，“哦，这么做无法满足策划要求的并发量”，再去修改设计方案。 操作系统：越单一越好。虽然FreeBSD的网络性能更好、虽然Solaris非常稳定，但选什么就是什么，最好别混着来。前端是FreeBSD，后端是Solaris，运营的人会苦死。也不要瞧不起用Windows的人，用Windows照样也能支持一组一万人在线，总之，能满足策划需求，好招程序员，运营成本低是要点。不同的操作系统有不同的特性，如果你真的对它们都很熟悉，那么必定能找到一个理由，一个足够充分的理由让你选择A而不是B而不是C。但做决策的时候要注意不要因小失大。 Programming Language：传统来说，基本都是C/C++。但是你也知道，这东西门槛很高，好的C/C++程序员很难招。用Perl/Python/Lua行不行？当然可以。但是纯脚本也不好，通常来说是混合着来。你要明白哪些是关键部分，我是说执行次数最多的地方而不是说元宝，这些必须用性能高的语言实现（比如C/C++比如Java），其它像节日活动这样很久才执行一次的，随便吧。脚本的好处是，可以快速搭原型。所以，尽早的，在你做完基本的地图和战斗模块之后，立马跑机器人测试吞吐量。这时候项目开发进度还不到10%，不行就赶紧改。 此处特别举个例子就是Java GC的问题。既然你要用java，而jvm需要通过执行garbage collection来回收内存，而garbage collection会使整个应用停顿，那你不妨试一试，内存在达到峰值的时候会停多久？策划可以接受吗？如果不可以，你可以采用其它的GC策略再试一试。这个问题应该不是Java独有的。网游和网站应用相比它很注重流畅性。这是你务必需要考虑的。 至于选择什么样的脚本语言，以及脚本在你的游戏中究竟是占80%还是20%？需要根据需求来看。有没有游戏完全不用脚本？有。有没有游戏滥用脚本？也有。如果你引入脚本的目的是因为策划不会C/C++而你希望策划能自己独立实现更多的游戏功能。你希望策划去写脚本？脚本也是程序，策划写的脚本难道就比程序员写脚本好？还是因为策划工资便宜？策划骑士团Unity3D系列教程培训
因为脚本写错了导致大故障还少吗（此处特别以网易的产品举例）？综合权衡下，还是算了吧。问问你一起工作的程序员哥们儿，他们最喜欢什么语言，什么用起来最顺手，就用什么当脚本。注意不光要考虑开发速度快，还要考虑调试方便。 总体来说，操作系统和编程语言的选择，随大流即可。标新立异没什么好处。小地方的实现你可以玩玩，整体还是要越保守越好。 通信 然后说通讯的问题。服务器和客户端怎么连接上的？ 往最下面看，物理和链路层。有可能是以太网，有可能是ADSL，在北京还有很多像歌华宽带这样的采用75欧同轴电缆或者电力线上网的。你不要企图在这一层做什么优化，你要充分考虑的是不同的网络传输媒质网络延迟不一样。更恶心的是你正常的数据包可能会被某些网吧的SB路由器当做P2P数据包给封掉，或是甚至被解析成Wake-On-Lan这样的含义。杨建还会给你讲，什么是MTU，把数据包限制在多大才能尽量让请求在一个包内发完。是的，这些很精细的东西，等咱游戏做的差不多了再慢慢研究。先略过。 往上看，IP层。再往上，你要考虑用TCP还是UDP或是二者混合。UDP的优势是overhead小、延迟低，典型的用例就是《天下贰》，据说是纯UDP。再比如《龙之谷》，据说是有小部分是UDP。负面的一点呢，就是它太过于简单所以用起来太过于复杂。你要是对自己没信心，TCP吧，随大流就好。 往上，采用什么样的应用协议。大多数rpc协议都是既支持TCP又支持UDP的。我所用过的有sun rpc、corba、webservice、json、java RMI以及一些专有协议。如果你有精力，还是自己搞一套吧，网游所用的东西，还是越专有越好，给抓包做外挂的人加一点门槛。这里非常强调的一点，你采用什么样的序列化方式与你采用什么样的网络协议是无关的，你的应用协议和你传输协议应该也是无关的（既支持TCP又支持UDP的）。如果做框架的人把自己限制的太死或者耦合太紧，那么用框架的人会非常痛苦。所以，没必要在此为了性能做过多优化。结构简单清晰是王道。 很多人对网络开发的认识还停留在定义一个struct、memcpy到socket buffer、send，然后一个劲的给别人强调遇到指针怎么办、数组的长度不能超过多少、整个包的长度不能超过多少等等。序列化其实是面向对象程序设计的一个很核心的要素。连glib/gtk/Berkeley DB这些纯C的框架都是基于OOP设计的，所以我觉得您就算是C程序员也没必要排斥它。我讲这个是说，你应当做应用的人尽可能的避免用memcpy/memset这样的方式初始化数据、传送数据。如果你是C程序员，你多提供一些g_object_new这样的函数；如果你是C++程序员，写好你的构造和析构函数；如果你是JAVA程序员还死活不懂OOP，那算了吧，改行吧。 网络这一层有些很精妙的东西，尤其是当你规模扩大需要分布式扩展的时候。你想想看为什么sun rpc需要先去rpcbind询问一次然后才连真正的进程呢？RMI返回的时候为什么需要同时返回IP和端口号呢？web service那么通用，大部分浏览器都支持直接从浏览器调用web service那么为什么主流的方式却是json呢？ sun rpc是所有RPC机制中历史最久的吧？它在设计第一版的时候，每个rpc调用都是由一问一答来组成，称为two-way messaging。客户端在发出请求之后，一直等服务器的答复，骑士团Unity3D系列教程培训
如果一直到指定时间后依然没收到答复，那么执行timeout逻辑。在第一个请求收到答复（或者timeout）之前，无法发起第二个答复。直到某一天，Sun的程序发现他们需要异步处理一些事情，于是设计了one-way messaging，客户端在发起请求的时候，只要把这个东西塞到本地的IO队列里，就返回。但是如果socket buffer满了怎么办？还是会等在那里。于是觉得这个还不彻底，于是又做了Non-Blocking Messaging，在kernel的socket buffer前面加了一个用户态的rpc buffer，大多数时候它都是空的，当socket buffer堆满了的时候，再往这里面塞。如果这个buffer也满了怎么办？我觉得无非就三种处理手段： １、阻塞。如果这么做，就是说本来是套非阻塞的设计但是某些情况下还是会阻塞？那么给用的人解释起来太麻烦用起来也太麻烦。算了。
２、悄然丢弃。 不是所有的数据都可以丢。聊天的无所谓，但是交易的就不行。所以需要在消息类型上加判断。
３、关闭连接。 最简单粗暴，却也最有效。 在使用two-way messaging的时候，一定要记住设置超时，省得像某些傻瓜一样因为一个请求把整个server堵死。但是我觉得timeout设多久完全是个经验值，太大了没作用，太小了失败的太多。 至少在有一点我们可以大松一口气，就是不用担心数据量大到需要多网卡同时分担中断。通常来说网络游戏的流量都是很小的，对玩家来说一个56K的猫或者128K的DSL就够了。如果你的策划给你提了一个很BT的需求导致要耗费大量带宽，那么你最好把这个应用分到单独的tcp 连接上，省得因为它阻塞而导致关键的业务（比如地图消息）停滞。 我一直想把rpc的部分实现塞到kernel里。对客户端的好处是增加了逆向工程的成本，对服务器的好处是网关可以很高效。就像LVS那样，前端收完包之后在kernel里处理完然后立刻转出去，不用切换到用户态。而GameServer处理完之后，甚至不用经过网关，直接回复。目的不在于分担网关的压力，而是说降低响应延迟。就算让GameServer承担部分加密和压缩的计算量，它的CPU也足够用。 不过对于网游，考虑动态扩容为时太早。一般都是新开几组服务器。
数据 我在做服务器安装包的时候，分的很清楚：程序、配置文件、数据库。 程序，就是编译好的二进制文件。最好是全静态编译，因为它简单。动态链接的优点以及其它一些高级话题我后面讲，但是通常来说，动态的复杂的结构得不偿失。 配置文件总体来说可以分为文本文件和二进制文件（废话）。文本文件的好处是开发过程中易于调试和修改，最终发布后也易于追踪问题。二进制文件的好处是小、精巧、不易把信息泄露给外人知道。java的打jar包的技术算是一个折衷的优势吧？我最看重的是易于调试和修改，所以基本都用文本文件。而这其中，表现力最强的就是xml，所以基本都是xml。 骑士团Unity3D系列教程培训
但是xml多了怎么管理就是个问题。我得整理份文档，每个xml都是什么格式，做什么用途的，最好每个xml再写一个xsd。事实是配置文件是随着需求变化最频繁的部分，而换个角度说我之前强调的序列化。所以，正确的思路是这样： 1、程序员分析需求文档，确定需要什么样的对象来表示配置 2、某套序列化框架，它利用某种xml解析库把xml变成内存中的对象 3、策划提供xml 只要这个框架做的好，根本不需要文档或xsd来描述xml。我这里说策划提供xml，那么策划怎么提供xml呢？按照我所看见的策划的习惯，他们最喜欢的是两种方式： 1、对于结构简单的数据，编辑excel表 2、对于结构复杂的（如涉及树、环的），提供专门的编辑工具 对于1，我们可以给excel做plugin,或者做一个工具从excel表导出成xml。对于2，让编辑工具可以导出成xml。但是最终很重要很重要很重要的一点就是要让所有的工具集成在一起，做好版本管理以及跨版本diff和merge。如何管理数据要比如何定义数据如何描述数据更难更重要。 很多同事和我的共识都是：要做一款好游戏，工具很重要。多个项目做完后，外人能看见的最大的积累就是工具和流程。 数据库 数据库在游戏中的重要性，是一个很令人玩味的东西。你可以听见很多人告诉你说，我们做游戏根本不需要数据库。是的，像单机游戏那样，在某个目录下创建一个文件，save/load就行了。这就是我所看到的当今的大型网游的主流做法。 哦，你要反对了。你说你知道某某游戏用的是mysql，某某游戏用的是oracle，等等。是的，你手上的信息可能比我多很多很多倍，但是关键点在于，数据库在整个系统中的角色到底是什么？ 典型的场景是这样：启动一个单独的进程称之为DB Gate。当用户登录的时候，逻辑服务器找DB Gate要数据，DB Gate没有于是就去找后面的Mysql要，然后读过来之后就放在这里，DB Gate就是一个类似于memcached的东西。所以后面无论是用mysql还是oracle还是plain text都可以，但实际上会在其它方面有些细微的差别。 它和网站应用相比，数据更容易做cache，把握好上线和下线这两个点即可，cache的命中率很容易达到4个9或者更高。但是从另一个方面，网络游戏的数据关联逻辑远远比网站复杂，而且对原子性、一致性、隔离性要求更高。现在是你自己来管理cache，于是并发控制就没办法交给数据库来做。 问题一：我不自己做cache，我就直接读写数据库。就像php+mysql那样，中间也不套memcache，行不行？ 我不知道。你可以试一试。 问题二：SQL or NoSQL ? 我还是回答不了。你做个demo跑机器人试一试。 骑士团Unity3D系列教程培训
总之，东西是活的。没有必要非要怎么着非不能怎么着。检验的标准很简单：1、是否完成了策划提出的功能需求 2、效率是否达到了预期目标 对于第一个，QA和策划都会去检查。对于2，跑机器人以及封测期间调优是王道。 对于数据库开发，我还是很强调面向对象那套观点。把数据库里的表映射到对象，把对象抽象成接口，每个模块以接口对外提供服务，不同模块不要直接通过表共享数据。或者，你可以读我的表，但不要写！因为数据的约束条件未必是可以由DBMS完全保证的，某些约束是难以用数据库本身的语言表述的。 数据是网游的核心，网游基本都是数据驱动的，所以数值策划才会这么吃香。 或者换个角度想，DBMS它是什么？ 1、它管理数据。帮助我们高效的读取和修改数据。因为数据的动态性，所以我们需要Btree这样的结构，而不是随便找个TXT追加写。但是换个角度想，网络游戏有什么特点？插入多，但是删除操作极少极少。那么是否可以采用其它的结构呢？顺序重要吗？为什么不用Hash呢？ 2、它负责备份和恢复数据。这基本是任何现代的数据库系统必须提供的基本功能。但是网络游戏又特殊一点，它要求能按指定时间“回档”。时间可以有半小时的误差，但是这个功能必须有。于是数据库能支持增量备份，或者它的备份能支持版本很重要。 3、它使用logging system保证在突然宕机的时候数据依然是完整和一致的。可是如果我们要自己做cache，那么就要求我们在应用层面所做的原子性保证必须在cache中也能体现出来。这些cache要么全刷，要么全不刷。 4、它提供并发功能。拿传统的php+mysql架构来说，为什么同一个应用可以被分布式的部署在多台机器上？魔力就在数据库上。 既然有人轻视数据库，那么也可反其道重视数据库。把90%的逻辑都放在数据库里完成。多招一些熟悉SQL熟悉存储过程的，主要的逻辑都由他们完成。 并发 接着说我在并发上的考虑。 一台机器还是多台机器？单进程还是多进程？单线程还是多线程？等等。 我觉得并发问题是最没章法可循的问题。你可以这么做也可以那么做。网络游戏的重点是在逻辑开发上，而做逻辑开发的人不要关心到底是epoll还是select。总之制定框架的时候需要定好一个规矩：单线程还是多线程、访问哪些数据的时候需要加锁（可能还需要跨进程的加锁）、谁来做load balancer、如果有一台机器宕了怎么办、哪些任务必须要以特定的顺序执行，等等。规矩定下来，一切都顺了。可这个规矩要足够的简单。 如果是多线程，我想过两种模式：Thread per Connection和Task based thread pool。现在机器的内存越来越大了，所以前者的开销是可以忍受的，1000人在线，就算每个线程要被系统占去2M，那么也才2G。而一般的3D游戏做个 3-4千人在线就行了，配个大内存的机器，Unity3d 开发网络游戏全套解决方案
我来起这个头子，主要在公司，现在的项目就是做一个网络游戏，实现双方出兵混战。有独立服务器端的网络游戏我还是第一次尝试，单机的手游到是有了4年的经验。我的想法就是，大家都把自己所学的东西拿出来，在论坛上探讨一个有目的性的主题，把这个主题深化，让更多的新手，包括我，能学到整套的知识。我的目的就是大家共同来维护这个demo，把代码给搞出来，并且是大家可以直接拿来用的一个设计方案。将要探讨的技术点如下：1.服务器连接；2.用户注册3.开设房间4.消息收发其他。。。。。。&&
要评论请先&或者&
这楼我先留用
这些都有了吧，不管是自带的网络还是photon之类的这些都有demo了
强列关注 ，希望能够学习
关注种·····
内容估计要晚点发了，等我把这游戏给搞完
技术是探讨出来的 ！
看来又被水了。。。。。。安全检查中...
请打开浏览器的javascript，然后刷新浏览器
< 浏览器安全检查中...
还剩 5 秒&查看: 2661|回复: 91
Unity3D开发的MMORPG游戏服务器和客户端源码下载
主题帖子积分
Unity3D开发的MMORPG游戏服务器和客户端源码，这个是最近用本站收集的素材做的一个游戏，服务端是用PhotonServer开发，全部解压后900多mb。$ V&&l% f# j9 n&&G. b5 m6 g3 q
1.jpg (72.42 KB, 下载次数: 0)
Unity3D开发的MMORPG游戏服务器和客户端源码
11:00 上传
22.jpg (91.33 KB, 下载次数: 0)
Unity3D开发的MMORPG游戏服务器和客户端源码
11:00 上传
0 _1 `7 a& f, c# S
33.jpg (77.47 KB, 下载次数: 0)
Unity3D开发的MMORPG游戏服务器和客户端源码
11:00 上传
6 ?/ ?# m2 _4 @) Y0 |: A4 A
44.jpg (56.86 KB, 下载次数: 0)
Unity3D开发的MMORPG游戏服务器和客户端源码
11:00 上传
# M# b" B; X# ?8 ^( P+ y, g- M
完整源码下载5 ?+ P2 Z5 ^- ?
游客，如果您要查看本帖隐藏内容请
游戏咖啡屋-最好的游戏编程源码技术网站！1、本主题所有言论和图片纯属会员个人意见，与本论坛立场无关 交流QQ群：
2、本站所有主题由该帖子作者发表，该帖子作者与享有帖子相关版权
4、如本帖侵犯到任何版权问题，请立即告知本站，本站将及时予与删除并致以最深的歉意
哎...今天够累的，签到来了游戏源码下载...
主题帖子积分
金牌会员, 积分 2227, 距离下一级还需 773 积分
金牌会员, 积分 2227, 距离下一级还需 773 积分
看看挺6666666的样子
主题帖子积分
论坛元老, 积分 54522, 距离下一级还需 9945477 积分
论坛元老, 积分 54522, 距离下一级还需 9945477 积分
Unity3D开发的MMORPG游戏服务器和客户端源码下载
主题帖子积分
中级会员, 积分 319, 距离下一级还需 181 积分
中级会员, 积分 319, 距离下一级还需 181 积分
看看挺6666666的样子3 q+ L# W- |3 K: u( t2 J
主题帖子积分
interesting code ......................
主题帖子积分
金牌会员, 积分 1924, 距离下一级还需 1076 积分
金牌会员, 积分 1924, 距离下一级还需 1076 积分
Unity3D开发的MMORPG游戏服务器和客户端源码下载
主题帖子积分
论坛元老, 积分 7967, 距离下一级还需 9992032 积分
论坛元老, 积分 7967, 距离下一级还需 9992032 积分
主题帖子积分
论坛元老, 积分 5676, 距离下一级还需 9994323 积分
论坛元老, 积分 5676, 距离下一级还需 9994323 积分
Unity3D开发的MMORPG游戏服务器和客户端源码下载
主题帖子积分
论坛元老, 积分 10262, 距离下一级还需 9989737 积分
论坛元老, 积分 10262, 距离下一级还需 9989737 积分
顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶顶
哎...今天够累的，签到来了游戏源码下载...
主题帖子积分
论坛元老, 积分 20012, 距离下一级还需 9979987 积分
论坛元老, 积分 20012, 距离下一级还需 9979987 积分
RE: Unity3D开发的MMORPG游戏服务器和客户端源码下载 [修改]
哎...今天够累的，签到来了游戏源码下载...
经常在论坛发帖，且发帖量较大
Powered by