做java游戏服务端开发有前途吗？

最近刚跳槽，到新公司已经干了有两周时间了，这两周时间是过得比较充实的，因为这家新公司是个小公司，以前以单机开发为主，服务器方面我一个人，做两个游戏的服务器开发工作，当然，一个很简单，另一个就相对复杂点，简单的那个是个弱联网游戏，服务器只需要做好数据存档和登录支付验证就好了，而另一个，则是相对复杂的slg游戏，我感觉这是又一款cok，而公司目前并不打算再招服务器了，所以估计这个项目我会一个人干到明年吧，等第一款上线赚钱了，可能会再招服务器。老实说，面试的时候，我就觉得这份工作对我而言是一个挑战，而当我清楚的了解了公司状况之后，我依然决定接受这个挑战。

说说我之前的经历吧，大四的时候，学校安排来北京培训java（培训没什么丢脸的，出来找工作我也用的真学历真背景，不像某峰互联），之后我去了培训机构推荐的公司实习，那个时候，工资2k，然而工作也干得很开心，跟着前辈学到了不少东西，当时是做微信公众号开发的，我跟着前辈做微信后台开发，当时使用SpringMVC+MyBatis框架，刚接触的时候，我自己学了挺久才弄明白，后来弄明白之后想想，其实挺简单，对于逻辑开发的程序员来说，你只需要弄懂工作流程就好了，页面怎么跳转，跳转怎么传值，数据怎么处理，这些足够了，当然我是个不满足的人，我会去弄明白，为什么用这个框架、为什么不用别的、用这个有什么好处、如果让我自己来做这个后台、我会怎么搭建？带着这些问题，我会试着自己搭建一下后台框架（虽然前期大部分是复制粘贴）。除了框架部分，微信高级接口也是我研究的重点，我会去官方文档看看微信是怎么接入的，然后研究研究前辈的代码是怎么写的，所谓的干一行爱一行大概就是这样吧，当时我觉得，微信开发，是很有前途的，而我们公司用的框架，也是最先进的（后来看来，确实这个框架组合是当前最流行的框架，而当时，微信公众号也确实是当时互联网行业的一个风口，微信后来把h5带起来了，导致现在一个好的h5前端都是供不应求的，薪资很高）。

说了这么多，为什么后来又转行做游戏了呢？其实是这样的，当时在第一家公司，我的上级打算跳槽走了，带走整个下面的技术，而不带实习生，有那么一两个月，实习生就一直闲着没事做，对于我来说，这样过着就太无聊了，我喜欢挑战，于是我投简历，重新找了份实习工作，在一个游戏公司做java服务器开发，公司挺大的，几年前凭借一款slg页游称霸游戏行业（什么游戏我就不说了，说了就知道什么公司了），后来游戏行业往手游发展，这款slg也出了手游版，这一款游戏，几乎支撑了整个公司，再加上后来出的几款手游，公司发展挺好的，我所实习的部门做的是一款mmorpg手游，从实习做到了转正，做了近一年了，然而这款rpg手游的数据却不是太好，第一次封测次日留存23，第二次26（现在这家公司的游戏能达到80多次日留存），七日就更不用说了，而我也能感觉到，作为一款mmo游戏，玩家之间的交互实在太少，从头玩下来，我觉得这是一款单机，失去了mmo的本质，在项目组准备进行第三次封测的时候，我选择了离开，原因很多，不仅仅因为游戏数据不好，也有一些个人原因吧，不过说实话，是这家公司带我走进了游戏行业，我很感谢，我觉得游戏行业是一个非常有前景的行业，甚至比之前我认为最好的微信开发还要好，游戏行业非常暴利，在这家公司工作就能感受到，策划文档中，充满了挖坑预留的计费点，这一块可以正常玩儿，但你如果充钱，你就比别人牛逼。网络游戏，最重要的，就是控制好平民玩家跟普通玩家的占比以及游戏平衡（当意识到公司的游戏如此处心积虑想要坑钱的时候，我突然明白为什么公司的游戏大多被腾讯代理了，为什么腾讯控股，原来如此，没钱玩儿你，哈哈）。由此也可以看出，游戏的商业化，已经把游戏公司带入了一个固定的模式——无条件坑钱，我觉得已经失去了游戏的本质，我看过一本书，叫《游戏人生》（当时在cocos2014年开发者大会上买的。觉得挺值的），书已经送人了，但内容我看了一大半，从游戏的产生，到玩家的心理，到为什么需要游戏，这本书都诠释的热别好（我觉得游戏策划都应该看看这本书，做良心游戏，拒绝一味坑钱）。啊，突然发现这一段说的有点偏了，说到底，我也只是做游戏服务器开发的，我也改变不了游戏行业，我只要做好我做的。其实大的游戏公司，就应该走这种商业化路线，凭借几款长生命周期的游戏，支撑公司流水。

从转行做游戏之后，我倒是觉得，游戏开发比web开发有趣多了，当然技术上也比web难多了，之前发过一篇讨论，web开发何和游戏开发的区别，

，我把我的答案再粘贴一遍（实际上是别人要求我上他的号去回答的，于是我就自己回答了我自己的问题）：

1从第三方支持来说，web后台有很多成熟的第三方框架，开发者不需要关心底层控制器跳转的实现，只需要一个或几个配置文件，就能完成核心控制器的部分，而开发者只需要关注web自身的业务逻辑，将逻辑与框架融合即可，使用框架一方面简化控制层代码，一方面很好的实现了业务逻辑的分层。而游戏后台开发中，因为各种游戏的需求差异性很大，从网络层，到业务逻辑层，各方面都必须根据自己游戏需求搭建适合自己的框架，因此很难有一些通用的东西能提炼出来一款成熟的框架，游戏后台开发基本上需要自己搭建适合自己的框架。

2从业务逻辑层面来说，web后台基本上逻辑都是大同小异的，或许这一套系统，稍微改改，另一套系统就能用，而游戏就不同了，每个游戏都有自己的特色，根据策划的不同需求而实现不同的逻辑，不过也会有一些通用的模块，但整体上差异性还是很大的。

3从数据持久化来说，web的数据基本上是很规整的，表与表之间关系很明确，并且以后也不会有太大的变化，而游戏中的数据多种多样，随着开服之后，数据的变化也是多种多样，甚至传统的关系型数据库根本无法满足游戏数据持久化的需求，游戏中有很多状态和数据是需要服务器来保存的，我个人认为，在游戏开发中，nosql比关系型数据库更实用。

4从通信层来说，web中的用户都是一个个独立的个体，而游戏中是多人在线的一个游戏世界，在这个游戏世界中，玩家与玩家之间需要进行交互，这就需要服务器实时的向所有在线玩家进行消息广播，这一点很损耗服务器性能的，在这方面，游戏后台要比web做更多的处理，游戏服务器是一个IO密集的服务器类型。

以上便是我当时的答案，或许我的见解尚浅，毕竟我做游戏不到一年，不过对于后台开发这块，我还是有一点话语权的，从实习游戏开发开始，我便经历了一个转换的过程，几乎又是一个从零开始的学习过程，从mina框架到protobuffer，这些东西，我相信web开发很少接触（mina作为网络通信框架，web中几乎只有http通信，protobuffer作为通信协议，web最多用json，其实二者形式上差别不大，但数据大小千差万别）。而游戏的逻辑，也是比web复杂得多，不得不说，web后台成熟的第三方框架是做的真的很好。

经历了上家公司的洗礼，我想我对游戏后台开发有了足够的了解，于是我找到了我现在这家公司，这家公司目前只有我一个服务器后台，做两款游戏，一款是塔防类，准备由单机改成弱联网，服务器存档，并做登录支付验证，另一款，是比较庞大的slg手游，是准备带领公司走上巅峰的项目，说一款slg带领一个公司走上巅峰一点儿不为过，我上家公司就是这样的，凭借一款《xxxx》（哈哈，名字不透露），走上人生巅峰。我之所以接受这份工作，是因为我接受挑战，从底层写起，从架构写起，这是作为一年工作经验的我想都不敢想的，不过这是一个挑战自我，证明自我的机会，我愿意接受这个挑战，人生总会有很多爬坑的时候，但爬过了坑，就真的是人生巅峰了。我接受这个工作的另一个原因，就是公司发展确实不错，以前做的单机，都是很火的（虽然我认为我自己一个人也能做，我也是学过cocos的），而现在公司也准确的把握了游戏行业的风口——slg，coc和cok的成功案例就能证明一切，mmorpg也不一定能做起来了，moba倒是有可能，但你要跟lol做不到80%的相似，我估计没人愿意在手机玩儿moba，slg或许是性价比最高的了。这么有挑战的工作，还要从架构写起，这样的挑战，我喜欢！

说说互联网业的书吧，我认为这个行业的书，分为两种，理论型的和技术型的，所谓理论型，就是长篇大论互联网发展，行业模式等，而技术型，就是类似技术的工具书，是从技能入手的书，这两种书，我家里都有，但我发现买了之后，我很少有时间看，下班没多少时间，北京上班，大多数时间都浪费在地铁上了，上班时间，看看理论型的吧，觉得_嗦，浪费时间（后来我发现，做这行，除了会技术，你还是需要去看看牛人眼中的互联网的，你需要透过前辈的眼光看世界，不要做IT民工，要做互联网从业者），看看技术型的吧，让别人看见了感觉你太low，所以我大多数时间还是能在网上down到pdf就在电脑看，down不到百度谷歌我要研究的技术，毕竟从事这行，还是用电脑学技术好点，主要是电脑看久了眼睛会疲惫，偶尔看看纸质的书也不错的。而以前面试的时候，面试官经常问，除了大学课本，你还看什么书啊？（如果是你们，恰巧又没看什么书，你们怎么说？），我一般会说，我会自学其他技术，如cocos2dx，然后买一些技术指南之类的书看。我觉得这已经算最大夸张化了，因为大学我真的很少看书，我记忆中就看过一本C++技术类的，一本C#的，一本Android，还有其他几本是什么都不大记得了，大学毕竟十几层的图书馆，除了英语四六级的时候进去复习，其他时间感觉都浪费了这十几层的图书馆。

说说成长过程中遇到的问题吧，如果遇到我解决不了的，以前是先自己百度谷歌，看看有没有办法解决，不行就问老大，而现在，先百度谷歌，看有没有办法解决，没办法在百度谷歌，实在不行还要看框架源码如何实现，上国外论坛看外国友人如何解决，问题总能解决的，总会有办法的。当我开始学习写架构的时候，我会开始关心游戏的网络层使用什么框架，mina还是netty，数据怎么存储mysql还是mongo，是否需要缓存redis存什么，memcached存什么，缓存什么数据，数据传输用什么协议，json还是protobuffer，怎么写效率高，最高支持多少并发等等，我想这些都是我现在需要考虑的问题，当然这些都需要根据游戏具体的需求来决定的，最终服务器能否高效稳定的运行，都是取决于我的架构是否高效稳定，所以这个过程我要不断学习，不断吸取别人的经验。刚到新公司的时候，我才体会到，自己写代码其实也是一种挑战，整个后端我自己一个人实现，代码是否规范，数据如何存储，都是我说了算，我想我的代码不仅要高效，还要让别人看得懂，后来的人能接着我的代码继续写下去。

最后说说Java的题外话，语言之争，从未停过，为什么有人拥护Java，有人拥护PHP，有人喜欢C#，有人喜欢C++，各个语言各有各的优势，业余时间，我也了解了不少其他语言，go，nodejs我都有了解，我觉得go的语言层面支持协程并发以及nodejs的异步，都是很适合游戏服务器的，我特别看好nodejs，异步io真的是对游戏服务器很好的特性，并且加入对原声js支持的mongo模块也是很方便的（上面我有说到，我相信nosql是很适合存储游戏数据的）。说到游戏行业，我认为h5游戏的发展也是越来越快了，上次白鹭的h5开发者生态大会我去了，白鹭的一整套工作流程，以及webvr，真的很令人兴奋（第一轮抽奖我还抽了一个暴风魔镜，哈哈！），另外，大会的模特挺漂亮，哈哈！2015年，互联网行业也略呈下降趋势了，不少创业公司面临倒闭，泡沫经济破灭，因为很多老板抓不住当前经济形势，以为不管是啥，有个app就是创业了，其实全然不知一款app后面有多少运营模式、盈利模式，就像一句讽刺的话，“我有个绝壁好的idea，可以颠覆bat，什么都不缺，就缺个程序员了，等等，千万别告诉马云！”，哈哈，听到这句话，当时我就笑了，估计好多倒闭的创业公司老板都这么想的吧，他们并不能抓住用户真正的需求，只有抓住用户真正的需求，才会抓住用户的心，真正活下来的，才是用户真正需要的，然而，相对来说，游戏行业更是复杂多变，或许今天玩家喜欢这种游戏，明天玩家就喜欢另一种游戏了，就像我们永远也想不到，flappybird、围住神经病猫这类的游戏竟然能活起来，愚公移山竟然也能让h5游戏变为付费的可能。就像一句话，“只要站在风口上，猪也能飞起来！”，只要抓住了玩家此时此刻真正想要的，产品就一定能做起来。

1、精通C++、STL及各种设计模式,熟悉各种数据结构和算法；

2、熟悉3D图形学原理，3D图形的常用技术,有较强的数学功底,有Shader编写经验；

3、有UE3、Gamebryo、Unity3D等一些游戏引擎使用经验。

游戏客户端，游戏库客户使用端，相对于游戏服务端的另一端，服务端是为游戏数据库服务的，而客户端就是游戏数据使用端。几乎现在任何游戏都有其客户端，用来连接服务端而为玩家服务。

服务端是为客户端服务的，服务的内容诸如向客户端提供资源，保存客户端数据。是实现游戏特色化的重要途径，也是最直接可以通过游戏表现出来的技术，比如要修改某个NPC的参数，重加载后，在游戏内立刻体现出来。

随着游戏市场的兴起，特别是网页游戏、手机游戏的崛起，对游戏开发技术的需求越来越多。网络游戏开发是一个庞大的体系，总体来说是客户端与服务器端。客户端是玩家接触的游戏图像显示端，服务器是处理游戏运行中的各种数据，由于一台服务器要支持众多玩家的请求，所以服务器的性能高低决定了同一个游戏的用户数量。

主要原因是：

1Java是跨平台的，方便部署；

2Java是安全的高级语言，可以提高开发效率；

3Java是面向对象的，代码可以重用；

4Java的分布式应用

　 基于JNDI的应用开发

　JNDI（The Java Naming and Directory Interface Java命名和目录接口）是一组在Java应用中访问命名和目录服务的API 命名服务将名称和对象联系起来 使得我们可以用名称访问对象 目录服务是一种命名服务 在这种服务里 对象不但有名称 还有属性

　命名或目录服务使你可以集中存储共有信息 这一点在网络应用中是重要的 因为这使得这样的应用更协调 更容易管理 例如 可以将打印机设置存储在目录服务中 以便被与打印机有关的应用使用

　本文用代码示例的方式给出了一个快速教程 使你可以开始使用JNDI 它

　l 提供了JNDI概述 l 描述了JNDI的特点 l 体验了一下用JNDI开发应用 l 表明了如何利用JNDI访问LDAP服务器 例如 Sun ONE 目录服务器 l 表明了如何利用JNDI访问J EE服务 l 提供了示例代码 你可以将其改编为自己的应用

　 JNDI概述

　我们大家每天都不知不觉地使用了命名服务 例如 当你在web浏览器输入URL 时 DNS（Domain Name System 域名系统）将这个符号URL名转换成通讯标识（IP地址） 命名系统中的对象可以是DNS记录中的名称 应用服务器中的EJB组件（Enterprise JavaBeans Component） LDAP（Ligheight Directory Access Protocol）中的用户Profile

　目录服务是命名服务的自然扩展 两者之间的关键差别是目录服务中对象可以有属性（例如 用户有email地址） 而命名服务中对象没有属性 因此 在目录服务中 你可以根据属性搜索对象 JNDI允许你访问文件系统中的文件 定位远程RMI注册的对象 访问象LDAP这样的目录服务 定位网络上的EJB组件

　对于象LDAP 客户端 应用launcher 类浏览器 网络管理实用程序 甚至地址薄这样的应用来说 JNDI是一个很好的选择

　 JNDI架构

　JNDI架构提供了一组标准的独立于命名系统的API 这些API构建在与命名系统有关的驱动之上 这一层有助于将应用与实际数据源分离 因此不管应用访问的是LDAP RMI DNS 还是其他的目录服务 换句话说 JNDI独立于目录服务的具体实现 只要你有目录的服务提供接口（或驱动） 你就可以使用目录 如图 所示 图 JNDI架构

　关于JNDI要注意的重要一点是 它提供了应用编程接口（application programming interface API）和服务提供者接口（service provider interface SPI） 这一点的真正含义是 要让你的应用与命名服务或目录服务交互 必须有这个服务的JNDI服务提供者 这正是JNDI SPI发挥作用的地方 服务提供者基本上是一组类 这些类为各种具体的命名和目录服务实现了JNDI接口？很象JDBC驱动为各种具体的数据库系统实现了JDBC接口一样 作为一个应用开发者 你不必操心JNDI SPI 你只需要确认你要使用的每一个命名或目录服务都有服务提供者

　 J SE和JNDI

　Java SDK 及以上的版本包含了JNDI 对于JDK 和 也有一个标准的扩展 Java SDK x的最新版本包括了几个增强和下面的命名/目录服务提供者

　l LDAP（Ligheight Directory Access Protocol）服务提供者 l CORBA COS（Common Object Request Broker Architecture Common Object Services）命名服务提供者 l RMI（Java Remote Method Invocation）注册服务提供者 l DNS（Domain Name System）服务提供者

　 更多的服务提供者

　可以在如下网址找到可以下载的服务提供者列表

　特别有意思的或许是如下网址提供的Windows 注册表JNDI服务提供者 这个服务提供者使你可以访问Windows XP/ /NT/Me/ x的windows注册表

　也可以在如下网址下载JNDI/LDAP Booster Pack 这个Booster Pack包含了对流行的LDAP控制的支持和扩展 它代替了与LDAP 服务提供者捆绑在一起的booster pack 关于控制和扩展的更多信息可以在如下网站看到 另一个有趣的服务提供者是Sun的支持DSML v （Directory Service Markup Language 目录服务标记语言）的服务提供者 DSML的目的是在目录服务和XML之间架起一座桥梁

　 JNDI API

　JNDI API由 个包组成

　l Javax naming 包含了访问命名服务的类和接口 例如 它定义了Context接口 这是命名服务执行查询的入口 l Javax naming directory 对命名包的扩充 提供了访问目录服务的类和接口 例如 它为属性增加了新的类 提供了表示目录上下文的DirContext接口 定义了检查和更新目录对象的属性的方法 l Javax naming event 提供了对访问命名和目录服务时的时间通知的支持 例如 定义了NamingEvent类 这个类用来表示命名/目录服务产生的事件 定义了侦听NamingEvents的NamingListener接口 l Javax naming ldap 这个包提供了对LDAP 版本 扩充的操作和控制的支持 通用包javax naming directory没有包含这些操作和控制 l Javax naming spi 这个包提供了一个方法 通过javax naming和有关包动态增加对访问命名和目录服务的支持 这个包是为有兴趣创建服务提供者的开发者提供的

　 JNDI 上下文

　正如在前面提到的 命名服务将名称和对象联系起来 这种联系称之为绑定（binding） 一组这样的绑定称之为上下文（context） 上下文提供了解析（即返回对象的查找操作） 其他操作包括 名称的绑定和取消绑定 列出绑定的名称 注意到一个上下文对象的名称可以绑定到有同样的命名约定的另一个上下文对象 这称之为子上下文 例如 如果UNIX中目录/home是一个上下文 那么相对于这个目录的子目录就是子上下文？例如 /home/guests中guests就是home的子上下文 在JNDI中 上下文用接口javax naming Context表示 这个接口是与命名服务交互的关键接口 在Context（或稍后讨论的

　DirContext）接口中的每一个命名方法都有两种重载形式

　l Lookup（String name） 接受串名 l Lookup（javax naming Name） 接受结构名 例如 CompositeName（跨越了多个命名系统的名称）或CompondName（单个命名系统中的名称） 它们都实现了Name接口 Compound name的一个例子是 cn=mydir cn=Q Mahmoud ou=People posite name的一个例子是 cn=mydir cn=Q Mahmoud ou=People/myfiles/max txt（这里 myfiles/max txt是表示第二部分的文件名） Javax naming InitialContext是实现了Context接口的类 用这个类作为命名服务的入口 为了创建InitialContext对象 构造器以java util Hashtable或者是其子类（例如 Properties）的形式设置一组属性 下面给出了一个例子

　Hashtable env = new Hashtable（） // select a service provider factory env put（Context INITIAL_CONTEXT_FACTORY sun jndi fscontext RefFSContext ） // create the initial context Context contxt = new InitialContext（env）

　INITIAL_CONTEXT_FACTORY指定了JNDI服务提供者中工厂类（factory class）的名称 Factory负责为其服务创建适当的InitialContext对象 在上面的代码片断中 为文件系统服务提供者指定了工厂类 表 给出了所支持的服务提供者的工厂类 要注意的是文件系统服务提供者的工厂类需要从Sun公司单独下载 J SE x没有包含这些类

　表 上下文INITIAL_CONTEXT_FACTORY的值 Name Service Provider Factory File System sun jndi fscontext RefFSContextFactory LDAP sun jndi ldap LdapCtxFactory RMI sun jndi rmi registry RegistryContextFactory CORBA snaming CNCtxFactory DNS sun jndi dns DnsContextFactory

lishixinzhi/Article/program/Java/hx/201311/26774

首先，我得说明的是，目前市场上新人很难去做pc游戏开发，要么是做页游要么是手游。

页游不清楚我就不说了，手游里面，客户端主要就是c2d和u3d。

如果你想做客户端，那么你可以转学u3d，因为它使用的语言是csharp，这个语言和java相似。网上unity的教程也很多，你随便找一下就有了。

再说说手游服务器，其实我入行服务器还是挺巧合的，当初本来是打算做客户端的，都入职了，因为招不到服务器，就让我转服务器了。。

服务器的教程，我至今也没找到，而且也找不到系统的教程。

开源的服务器框架也只熟悉kbengine和scut。其中一个是cpp做底层python做开发的，一个是csharp做开发。而且scut已经两年没有更新了，应该是死掉了。

所以，想要学服务器开发，得碰点运气。

java服务器目前主流框架技术有网络层netty或mina，数据协议protobuf，数据库mysql，缓存数据库redis，jdbc一般是mybaits或者jpa，项目管理maven，设计层面spring

然后还需要熟悉多线程，linux的基本操作，git或者svn。

差不多了，这些都有个大致的了解，会用，应该就能找到工作了。

后面再深入需要学习的也挺多的，到时候你再根据业务需求自己琢磨着学吧。

使用身份验证机制。在接口调用时，要求客户端提供用户名和密码进行身份验证，在服务器端对用户名和密码进行校验，验证通过后才允许调用接口，这样即可在不告诉他人的情况下一个人用。Java是一门面向对象编程语言，1990年代初由詹姆斯·高斯林等人开发出Java语言的雏形，最初被命名为Oak。