企业网站建设

网站建设一条龙服务

Unity3D游戏开发之网络游戏服务器架构设计培训

什么样 通常来说 配置文件

概述: 以及脚本在你的游戏中究竟是占80%还是20%?需要根据需求来看。有没有游戏完全不用脚本?有。有没有游戏滥用脚本?也有。如果你引入脚本的目的是因为策划不会C/C++而你希望策划能自己独立实现更多的游戏功能。你希望策划去写脚本?脚本也是程序,策划写的脚本难道就比程序员写脚本好?还是因为策划工资便宜?策划因为脚本写错了导致大故障还少吗(此处特别以网易的产品举例)?综合权衡下,还是算了吧。问问你一起工作的程序员哥们儿,他们最喜欢什么语言,什么用起来最顺手,就用什么当脚本。注意不光要考虑开发速度快,还要考虑调试方便。

下面咱们开始今天的Unity3D游戏开发技能培训。 咱们专业培养”游戏主程”,挑战20W年薪,初期学习Unity3D培训目标:让U3D初学者更快速的掌握U3D技巧,自行制作修改素材,独立完成2D、3D小规模游戏及网页游戏开发。

今天给大家讲一下如何做一个好的主程

入手

假如,我现在接手一个新项目,我的身份还是主程序。在下属人员一一到位之前,在和制作人以及主策划充分沟通后,我须要先独自思考以下

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++而你希望策划能自己独立实现更多的游戏。你希望策划去写脚本?脚本也是程序,策划写的脚本难道就比程序员写脚本好?还是因为策划工资便宜?策划因为脚本写错了导致大故障还少吗(此处特别以网易的举例)?综合掂量下,还是算了吧。问问你一起工作的程序员哥们儿,他们最什么语言,什么用起来最顺手,就用什么当脚本。注意不光要考虑开发速度快,还要考虑调试方便。

总体来说,操作系统和编程语言的选择,随大流即可。标新立异没什么益处。小地方的实现你玩玩,整体还是要越保守越好。

 

  合肥家教网站  新疆大枣批发   今日推荐免费建站   分类信息   宣城网站建设公司

 

通信

然后说通讯的。服务器和端怎么连接上的?

往最下面看,物理和链路层。有可能是以太网,有可能是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。端在发出申请之后,始终等服务器的答复,假如始终到指定后仍然没收到答复,那么执行timeout逻辑。在第一个申请收到答复(或者timeout)之前,无法发起第二个答复。直到某一天,Sun的程序发现他们须要异步处理一些事情,于是设计了one-way messaging,端在发起申请的时候,只要把这个东西塞到本地的IO队列里,就返回。然而假如socket buffer满了怎么办?还是会等在那里。于是觉得这个还不彻底,于是又做了Non-Blocking Messaging,在kernel的socket buffer前面加了一个用户态的rpc buffer,大多数时候它都是空的,当socket buffer堆满了的时候,再往这里面塞。假如这个buffer也满了怎么办?我觉得无非就三种处理手段:

1、阻塞。假如这么做,就是说本来是套非阻塞的设计然而某些状况下还是会阻塞?那么给用的人解释起来太麻烦用起来也太麻烦。算了。 
2、悄然丢弃。 不是所有的数据都丢。聊天的无所谓,然而交易的就不行。所以须要在音讯类型上加判断。 
3、关闭连接。 最简单粗暴,却也最有效。

在应用two-way messaging的时候,肯定要记住超时,省得像某些傻瓜一样因为一个申请把整个server堵死。然而我觉得timeout设多久完全是个技巧值,太大了没作用,太小了失败的太多。

至少在有一点咱们大松一口气,就是不用担心数据量大到须要多网卡同时分担中断。通常来说网络游戏的流量都是很小的,对玩家来说一个56K的猫或者128K的DSL就够了。假如你的策划给你提了一个很BT的需求导致要消耗大量带宽,那么你最好把这个应用分到独自的tcp 连接上,省得因为它阻塞而导致关键的业务(比如地图音讯)停滞。

我始终想把rpc的实现塞到kernel里。对端的益处是增加了逆向工程的,对服务器的益处是网关很高效。就像LVS那样,前端收完包之后在kernel里处理完然后立刻转出去,不用切换到用户态。而GameServer处理完之后,甚至不用经过网关,直接回复。目的不在于分担网关的压力,而是说降低响应延迟。就算让GameServer承担加密和压缩的计算量,它的CPU也足够用。

不过对于网游,考虑动态扩容为时太早。一般都是新开几组服务器。

 

数据

我在做服务器安装包的时候,分的很清楚:程序、配置文件、数据库。

程序,就是编译好的二进制文件。最好是全静态编译,因为它简单。动态链接的长处以及其它一些高级话题我后面讲,然而通常来说,动态的复杂的结构得不偿失。

配置文件总体来说分为文件和二进制文件(废话)。文件的益处是开发过程中易于调试和修改,最终发布后也易于追踪。二进制文件的益处是小、精巧、不易把信息泄露给外人知道。java的打jar包的技巧算是一个折衷的优势吧?我最看重的是易于调试和修改,所以基本都用文件。而这其中,表现力最强的就是xml,所以基本都是xml。

然而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。如何管理数据要比如何定义数据如何形容数据更难更重要。

很多同事和我的共识都是:要做一款

 

http://m.kvov.com.cn/hf/jzxx41058.html