想去做游戏开发，请问是学U3D好还是UE4好，求大神指点迷津！【u3d吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：3,254贴子：
想去做游戏开发，请问是学U3D好还是UE4好，求大神指点迷津！收藏
一直想去学游戏开发，做了半年前端会javascript，有计算机基础，求大神指点迷津，是学U3D还是UE4~
求大神指点迷津啊！！！！
手游 2a级别 游戏u3d
3a 级别大型游戏果断ue4
ue4的特点就是吃设备性能，你觉得呢
ue4太烧配置了，特效不错
你现在的想法就好比小时候犹豫考清华还是北大好
先从简单的开始呗
u3d中小开发企业工作机会多，UE4大佬企业经验技术要求高。就这样
登录百度帐号学unity3D游戏开发需要什么基础
学unity3D游戏开发需要什么基础
浏览次数：2995
浏览次数：1145
浏览次数：1057
浏览次数：1323
浏览次数：1450
如果你对以下课程意犹未尽，，查看全部课程
HTML5全栈开发
HTML5最新课程
156 人在学
c#编程概述
C#快速入门
简单又好玩
120 人在学
没有账号？
s后重新发送
已有账号？
已有账号？
验证码确认
话题标题：
400-877-8190
登录后反馈92被浏览15,868分享邀请回答5528 条评论分享收藏感谢收起263 条评论分享收藏感谢收起全国切换城市
& &Unity3d游戏开发如何入门？U3D工程师就业前景怎么样？培训学校
Unity3d游戏开发如何入门？U3D工程师就业前景怎么样？培训学校
问题描述：本人做了快一年U3D客户端开发。目前总觉得遇到了瓶颈，不知道该从哪个方面提升自己能力。望各位大牛指点一二。1、深入研究C#，包括CLR之类2、学习图形开发，Opengl和Directx，还有
[db:前缀]Unity3d如何入门？U3D工程师就业前景怎么样？培训学校问题描述：本人做了快一年U3D客户端开发。目前总觉得遇到了瓶颈，不知道该从哪个方面提升自己能力。望各位大牛指点一二。1、深入研究C#，包括CLR之类2、学习图形开发，Opengl和Directx，还有shader等3、提高数学能力，空间几何、线性代数之类4、提高程序开发能力，设计模式、算法等5、学习网络编程，转服务器开发，并学习其他语言6、学习3D建模、绘画、UI设计、游戏策划，提高独立开发能力以上是我能想到的几个方面。我知道每个方面都重要，深入研究都可以有造诣。可是这些方面我都只是略知皮毛，似乎开发个产品也可以，却不能做到随心所欲的使用。而我现在又没有太多业余时间，所以想有个学习计划，对我目前的工作内容，哪些最需要先学习，哪些可以以后慢慢研究。再次希望各位有经验的人士能够指点一二，谢谢。前辈的解答从题主的问题中可以看出题主的一点迷茫，就像一年前的我，我也就比你多一年Unity经验。从一个打工者的角度来跟你探讨一下，也跟大家都探讨一下，不光探讨Unity技术，也探讨一下以后的方向。这里说一下我自己对这个行业的思考。现在Unity流行了，只要会写几行C#代码的人都能进个游戏公司写点逻辑，但真正精通的人不多。我当初C#都没学过，只会Java，都进了个小游戏公司，花了个把月的时间就参与开发了，当然也就是搞点优化，改改BUG，写点逻辑之类。现在越来越多的人用Unity了,我甚至可以预料，未来的几年内Unity会更加流行，说不定会到处是培训机构。到时候会有一大波人涌入这个行业，就像现在的Java开发SSH三大框架之类的。我们面临的问题：Unity入门门槛低，注定以后的Unity从业者会越来越多，竞争会越来越激烈。我刚毕业的时候待过一个比较大的公司，做银行的信贷系统。那时刚开始学java，自己工作之余也看一下书充电，项目经理却跟我说，技术不重要，重要的是实现。后来我才知道，我当时是做一个工厂流水线工人，码农一个，技术确实不重要。公司巴不得我什么都不懂，只会if else，解决逻辑的问题，发一点微薄的薪水就行了。于是我明白了，不想做产线工人，首先要脱离当前层次。要做到公司少了你不行! 这个时候你必须掌握一些门槛高的技术，你才能拔尖。有些技术是靠经验堆积的，比如整个框架的设计，设计模式的运用。我倒觉得这个能力只要你平时留心，掌握它们只是个时间的问题。而有些技术，是要去实打实钻研的，不看透几本英文原版书，不逛遍几个论坛，你永远不能get it。越是难的东西，越能拉开你跟别人的距离。比如学Cg,很多资料都是英文的，像Cg的官方教程The Cg Tutorial，还有这个Cg Programming/Unity，不看这些书，根本入不了门吧。 还有最著名的《Real-Time Rendering》，都是英文的，还需要很多数学知识。像线性代数里的矩阵变换，这些东西虽然大学都有学过，但在这里才真正用上。在开发的过程中遇到问题了，要上网查吧。我跟你打赌，你要是碰到个C#的问题，去stackoverflow分分钟就能查出来（甚至去百度都能查出来）。但要是你碰到个shader上的问题，可就不好查了。Unity里面很多东西都是没资料查的，你只能去论坛里跟人交流，去看源码，去看UnityCG.cginc，去看AutoLight.cginc。总而言之，就是不好弄啊。等你深入的去研究这些的时候，慢慢的你就发现，好像公司里就你在弄这个，别人都不懂。这个时候你就牛逼了啊。以后手机的性能越来越好，高品质的3D手游会越来越多，虽然可能现在国内大部分公司做的手游是2D的，但以后一定会有更多的3D手游涌现。我相信手游拼3D特效的时代马上就要到来了！ 所以我感觉学图形学的东西还是比较有前途的。当然这也跟你自己的爱好有关吧。反正我是觉得，如果以后要跳槽，面试的时候，你拿着一个游戏说，这个游戏框架是你搭的，可能面试的人很难确定，谁知道你这框架搭得好不好。但如果你说这个游戏的所有3D特效和Shader都是你写的，这就一目了然了。Unity3d工程师现状如何？前景如何？整个行业都缺人。我们现在招人的标准已经降到脑子聪明，C#写得还不错，随便用什么引擎什么语言做过一个完整的项目，用过一年unity。人员供给不足导致Unity3D开发者薪资水平普遍较高。根据权威部门统计，在我国，50%的Unity3D开发者工作年限在2年之内，45%的开发者工作年限在2到5年之间，平均薪资超过了14K！总的说来，随着互联网技术及行业需求的发展，U3D的市场需求十分不错。如今Unity3d人才稀缺，并且从业人员的薪资看涨，现在正是踏入这个朝阳领域的最佳时间。如果你是0基础想学习游戏开发，那么我们为你准备了免费训练营U3D开发免费训练营报名中开年第一课，玩转U3D游戏开发，4天免费课程等你来入门高薪游戏开发行业，全程大咖级讲师亲授，为你解析行业发展趋势，就业前景，帮你了解技术，轻松入门，更快一步成为技术大牛！开课时间：3月26日-29日 共4天点击文末“阅读原文”报名学习游戏开发，进入高薪行业！▼相关推荐大学生想做U3D游戏开发，该如何规划学习路径和找工作？学Unity做游戏开发好找工作吗？「入坑答疑」新人如何判断一家游戏公司是否靠谱？新人学Unity3D游戏开发的方向和路径都有什么？Unity开发工作一年，能力应该到达什么水平？如果你想详细学习游戏开发，我为你准备了非常详细的教程和学习资料，在本公众号后台回复「教程」，可直接获取下载地址。《Unity游戏设计与实现-南梦宫》后台回复「设计」下载，《3D数学基础：图形与游戏开发》后台回复「数学」下载《游戏改变世界》后台回复回复「改变」下载《Unity官方案例精讲》后台回复「案例」下载 更多资料、更多问题请后台详聊小新新。注：baidu网盘文件总是被删，我重新生成了链接，你们试试，再不行给我后台留言吧，我也很无奈啊~~Unity3D游戏开发主程，入门游戏开发必备！↑↑长按二维码关注我点击阅读原文报名U3D免费课程温馨提示：如需要了解课程请提交您的联系方式给我们，我们会根据您所在地安排优质机构给您详细介绍，而且学费优惠高达1000元哦！
温馨提示：本文章来自网络并且是机构方发布，请自行核实信息的真实性,建议到机构教学点实地考察后签约合同再缴纳学费，一切法律问题本站不承担哦！如侵权请联系本站(https://www.123px.cn)删除，谢谢! 责任编辑：
相关文章：
热门阅读排行
123培训网动态
培训最新动态
机构最新动态
实力机构展示
周一至周五 09:30 - 18:00Unity3D游戏开发之网络游戏服务器架构设计培训（如何做一名好主程）
狗刨学习网
发布时间: 10:30:28
&&&&& 在我们初期学习目标：让U3D初学者可以更快速的掌握U3D技术，自行制作修改素材，可以独立完成2D、3D小规模游戏及网页游戏开发。后面就应该朝着主程的方面前进
今天给大家讲一下如何做一个好的主程
假如，我现在接手一个新项目，我的身份还是主程序。在下属人员一一到位之前，在和制作人以及主策划充分沟通后，我需要先独自思考以下问题：
1、服务器跑在什么样的操作系统环境下？2、采用哪几种语言开发？主要是什么？3、服务器和客户端以什么样的接口通讯？4、采用哪些第三方的类库？
除了技术背景之外，考虑这些问题的时候一定要充分考虑项目需求和所能拥有的资源。
我觉得，先不要想一组需要几台机器各有什么功能这样的问题，也不要想需要多少个daemon进程。假设就一台服务器，就一个进程，把所需要的资源往最小了考虑，把架构往最简单的方向想，直到发现，&哦，这么做无法满足策划要求的并发量&，再去修改设计方案。
操作系统：越单一越好。虽然FreeBSD的网络性能更好、虽然Solaris非常稳定，但选什么就是什么，最好别混着来。前端是FreeBSD，后端是Solaris，运营的人会苦死。也不要瞧不起用的人，用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也满了怎么办？我觉得无非就三种处理手段：
１、阻塞。如果这么做，就是说本来是套非阻塞的设计但是某些情况下还是会阻塞？那么给用的人解释起来太麻烦用起来也太麻烦。算了。&２、悄然丢弃。 不是所有的数据都可以丢。聊天的无所谓，但是交易的就不行。所以需要在消息类型上加判断。&３、关闭连接。 最简单粗暴，却也最有效。
在使用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。如何管理数据要比如何定义数据如何描述数据更难更重要。
很多同事和我的共识都是：要做一款好游戏，工具很重要。多个项目做完后，外人能看见的最大的积累就是工具和流程。
数据库在游戏中的重要性，是一个很令人玩味的东西。你可以听见很多人告诉你说，我们做游戏根本不需要数据库。是的，像单机游戏那样，在某个目录下创建一个文件，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跑机器人试一试。
总之，东西是活的。没有必要非要怎么着非不能怎么着。检验的标准很简单：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千人在线就行了，配个大内存的机器，还剩下足够多的内存给应用使用。多简单啊！网络游戏中，很多请求都是只需要访问单个角色的数据就够了，反过来说很多数据都可以做成Thread Local的，免去了同步代价。
而Task based thread pool的伸缩性相对来说就好的多，但是并发问题也麻烦一些，况且从rpc请求被unmarshal完到扔到task pool里面又多了一次线程切换，如果换成Leader-Follower那样的模式，少了切换但是模型又更复杂了一些。
如果是单线程的，那么一切都是事件驱动的并且事件的处理都是非阻塞的。那么就得避开数据库读写或者在处理的过程中再产生新的rpc请求，否则非常麻烦。
并发问题的瓶颈往往是在于怎么降低锁冲突上。Task Pool里面的所有线程都在执行Task，但是都在等同一把锁，多悲剧啊。难点在于降低模块耦合、采用适当的排队机制等等。我觉得这里没有什么万金油，降低模块耦合本来就没什么套路可循，而排队机制有很多种，没有最好的，各有利弊。
对于死锁，我的容忍度比以前大了很多。我觉得每台机器每天的死锁数量在10个以内都是可以忍受的，要有死锁检测、打断机制并且重做的时候不会产生副作用。对玩家的感受而言就是突然卡了一下，可是网络不也经常会突然卡一下吗？不频繁就好。
我最钟爱的模式就是&生产者-消费者&模式，万能的利器。例如Task Pool就是基于这样的模式。它的核心东西无非就是一个队列，如果要支持定时，那么就是一个优先队列（deadline time作为优先级）。讲个细节，我面试的时候问了很多面试者，优先队列应该用什么样的数据结构实现，结果都挺让我失望的。
顺便发个牢骚，Sun JDK的executor的实现，BUG太多了。还那么巧，都被我遇上了？
说些杂七杂八的东西吧。我刚入行的时候就一直在问，为什么网游服务器经常要停机维护？为什么经常都是好几个小时？为什么非要分成不同组的服务器并且数据基本不互通？为什么不构造一个大世界把所有玩家放在一起？我现在不问了，这些问题基本都找到了答案。不是技术做不到，而且有很多它以外的东西在左右这些。至少我在尽力不回档这件事情上已经做的比较好了。我想说的就是，入这行就得遵守这行的规矩。如果你是个老手了，根本没必要来看我这一系列的P话。如果你是新手，那么我是在向你介绍现状。策划是甲方，我们是乙方，在尽力满足策划的需求且不会显著增加成本的前提下做有限的创新，这是我给自己定的设计原则。（支付宝刚通知我，我又收到了5块钱的捐赠。谢谢，谢谢大家）如果你是一个受过良好训练的程序员，那么以下基本规则是懂的：1、不要把需要翻译的常量字符串写在代码里2、不要直接在代码中间写498595这样的magic number3、向版本控制系统提交代码的时候应该写注释4、需求是经常变的，并且经常是灾难性的可往往知道是一回事儿，做又是另外一回事。尤其是不要相信策划那张嘴，写成word文档才算数。
和大家分享一些我在版本控制上的经验和教训。
最早接触这个问题，是在sina的时候，由QA部门的同事以及周琦单独专门给我讲jira、svn。当时受益很大。
周琦一再给我强调，在产品生命周期中，源代码版本管理和发布部署是独立的两套东西。源代码版本管理是用subversion这样的东西来做（更早一点我们还在用cvs）。发布部署，一是编译的过程，二是对外推送部署的过程，是一套相对独立的东西。周琦的特色在于他把这二者通过svn hook脚本的方式给自动串起来了。
我一直想要做一套OBS这样的东西找一台服务器专门作build server，可惜一直没时间去写。就自己写了一个脚本（本来是sh的，后来成perl，后来成groovy），它的作用是根据分支名和版本号从subversion下载代码，然后编译，然后放到指定位置。然后通知发布服务器从那里拿东西推到外边。缺点它缺乏并发控制，并且没有UI界面。导致做完之后就成个人专属的了。
为什么每次要选择一个空目录checkout然后编译，而不是在上次的基础上svn up然后编译？这个和Java/Ant有点关系。在写Makefile的时候，尽管可以指定把当前目录下的.cpp文件全部都编译，但是这是不推荐的做法。因为相比于写代码的时间，把代码文件添加到Makefile中的时间可以忽略不计。而我当时给ant写build.xml时，是用**/*.java的方式去匹配，于是把src下的所有能编译的全编译了。可我在编译之前会执行一些脚本用于生成一些代码，某些是单独存放的，但是某些和其它手写的代码放在了一起。所以为了保持最终的jar包干净，宁可牺牲编译的时间。
在提供给QA的测试环境中可以很方便的通过GM指令得到版本号，这个是编译的时候打包工具写进去的。而编译系统务必保证相同版本号的东西每次编译出来都是相同的东西。虽然二进制比对结果可能不一致，但是逻辑功能上是一致的。
对于svn的分支管理，有两种普遍策略：
1、每个人一个单独的分支。做完自己的功能后往主干merge
2、都在主干上工作。需要发版本的时候创建新分支。
前一种需要大家都比较熟悉svn的用法，熟悉版本管理的基本概念。后一种则把所有活堆给一个专门发版本的人。他来创建分支，他来merge（或是谁的功能谁merge）。并且这样的话，绝大多数代码是不需要merge的，所以我根据实际情况选择了后一种。
于是在正在运行的系统中发现bug的时候，立马获取版本号，从那个版本上创建分支并且把分支名喊一声告诉大家，然后找问题，把补丁merge到过去，编译，发布，测试，推到外面。
发版本很累，这件事情在去年秋天上线后，一直到春节，占去了我90%的精力。其中最重要的就是比对功能和bug列表。经常，你分不清楚这到底算是一个bug呢，还是提需求的时候就没说清楚所以这是一个新功能，反正都列一起的。挨个和svn提交记录比对。
部署也是一个很有讲究的过程。我的原则是，先删除老的程序和配置文件，然后复制新的过去，数据库的数据和日志文件保留，审计日志保留。这件事情本来还争论过老的要不要删，可不可以直接覆盖，最终他们答应了我的需求。过程挺曲折的，中间有很多恶心的细节问题，比如NFS的本地cache的问题。
对于数据库，我们能智能的感知数据库结构更改并自动生成升级脚本（天哪，我这算不算泄密）。这居然也是一把双刃剑。优点是减轻了开发人员的工作量，缺点是更改数据库变得太随意，随意的添表添字段导致数据膨胀的厉害。
我的遗憾是没有把上面这些东西和数据编辑器串起来。那么做有点是数值策划调整数据更容易看到真实效果，缺点是也很容易乱来。如果这中间要经过svn，那么太慢太曲折。如果这中间不经过svn，那么鬼知道他们现在测的是什么版本的东西，他经常会发现最终出去的东西跟他当时测的还是不一样，毕竟，是很多人在同一个服务器上测试。很难给他们解释这个事情。
所以我当时还漏了一个东西一直想做但是没做，就是一个很简单的web gui能让所有策划自己启动、停止服务器，自己编译、同步数据。各弄各的，互不干扰。但是吧，策划毕竟是策划，它们缺乏基本的QA知识。他们不明白为什么一个底层功能好好的怎么突然就不好使了（因为上层某处要加新功能，所以底下的代码要重构），他们不明白为了一个bug被改掉之后反复又出现了，甚至对于分支和版本号这个东西，绝大多数策划都理解起来困难。但是整个产品的开发、发布模型就是这样，所以这些概念必须从一开始就沟通好、贯彻好。相比而下，这些倒和美术没什么事儿。
都是些小活儿。
另外我一直在想要不要在配置文件和game server之间套一个gconf这样的东西，外部更改配置，gconf通知listener也就是game server，呃，一个很不成熟的想法。
另外很多人一直想，在不重启进程的情况下，替换掉映像中的某个函数，修BUG。如果这个daemon程序是用C/C++写的，这个时候用dlopen加载一个so，设置一个参数就可以了。如果是JAVA并且用JDWP开了DEBUG，那么too easy。如果没有，那么unload jar/load jar吧。
我一直在构思一个可动态拆卸/替换/装载的架构，一个简单的不像OSGi那么复杂的东西，可是想法一直不大成熟，因为没有找到太简单的方法。我的基本想法是有一个object container，把service抽象成object，service和serivce之间的交互都要去这个object container中通过name lookup的方式得到一个句柄，然后通讯。配置文件不能视成一成不变的，它们也是动态数据的一部分，不能再通过静态的getInstance获得，也必须通过这个object container查找。但是未必是一个global object container，每个module可以有自己的object container。或是module instance持有reference，请求派发给module，module派发给object的时候把需要的reference传给过去，意思就是module就是一个object container，不过不是被lookup，而是主动构造好塞进去。
更多精彩点击
来源:http://www.cnblogs.com/Unity3Dqishituan/p/3989909.html}