为什么java不适合游戏开发？
如果你问我Java适合开发游戏吗？我回答肯定是适合的，JAVA开发效率高，运行效率一般，需要运行效率的地方用c或者cxx写就好了，现在市面大多数游戏都不是单一编程语言开发的，不需要在语言方面纠结太久。
很多人说，运行效率也很重要，但实际上，一般逻辑，你是感受不出差异的，普通逻辑使用j***a或者c#，或者脚本语言等这种开发效率，调试效率高的语言会让你开发更舒服。特别是脚本语言。
c和cxx只在特别需要效率的地方才使用。
j***a开发游戏性能和效率差，开发一些小游戏还可以，j***a面向对象，所有方法都是封装在类里的，要调用方法就得实例类，而游戏主要侧重的是逻辑
对象就像是很多功能的机器，但是我的游戏逻辑只要每台机器的其中一个功能，但要用的话必须把这一整台机器制造出来。这就是面向对象的缺陷吧
而c是面向过程的可以更加灵活地过程逻辑，少去很多多余东西，大大提高性能
j***a的长处就是利用各种现存的类包，达到复用的效果，大大提高开发效率，
当然j***a也可以只针对逻辑来设计类，但那不是j***a的长处，没有多大的意义
百度搜索圈T社区（***.aiquanti***） 免费视频教程
因为j***a中间多出来一个jvm，效率低，游戏实时性很重要。
看一个语言适合开发什么，主要有三点
3.产品的侧重点。
就拿j***a和c++来说，j***a主要用于web开发，但是c++通过cgi也可以写web，而且c++的执行效率甩j***a几条街，但是为什么不用c++写web呢，因为c++的开发web的效率太低，而j***a有各种web方面的框架，开发效率高。
如果产品是游戏，游戏实时性很重要，你玩个游戏反应慢半拍那肯定很恼火。游戏这个产品的实时性就注定了要***用高效率的语言开发，那c,c++自然就跑不掉了。
J***A 可以做游戏服务端的开发，也就是网络游戏的开发，网络游戏的实时性高，对高并发，数据的一致性处理要求较高，并且因为是自身JVM 的垃圾回收机制对服务器的内核性能要求高，会占用一定的***去处理这部分数据，游戏的实时性代表了大量数据会经常被更改替换。
J***A 不是不能做，而是对开发人员的能力要求高！如果能够充分利用J***A 的并发优势，那是可以做到的，并且这已经被有些小公司当做网络游戏服务端的开发语言了。
PC 端，移动端的单机游戏就不用再考虑J***A 了，显然J***A 的2D3D 处理效果没有一些主流的游戏开发语言好！语言具有其使用场景，抓住其优点去利用之，而不是拿它的缺点如何别的语言优点相比！如今J***A 是做服务端开发的不二人选，因为他的帝国大厦已经很完善，开发人员也多！
作为一个多年游戏服务端开发者，我来回答一下这个问题。只要你仔细去招聘网站看，会发现游戏招j***a的非常少（我希望杠精不要抬杠，我说的少，而且非常少，并不是说没有）。那么为什么在其他领域的霸主在游戏行业连喝口汤的资格都没有呢？其实主要有两个原因，而且这两个原因都和程序员最关心的效率有关系，一个是开发效率，一个是运行效率。很遗憾的作为一个不上不下的j***a两个都占不了。
首先是开发效率，在几年前手机游戏开始火爆，游戏公司多，产品相似度高，那么如何能以最快的速度开发完游戏并且上线运营，在快速迭代中试错，降低开发周期就是减少开发成本。在这种环境下，很多脚本语言成了首选，比如nodejs、php甚至还有lua和python（这里多说一句，别看lua语言本身简单，其实lua在游戏领域的使用成本是非常高的，至少在这四种脚本语言中是最高的，因为他只是一个胶水语言，要依附于c/c++，作为游戏周边的库都要自己造轮子或找轮子，同时对于引擎部分来说，对核心开发人员要求也非常高，如果公司没有经验丰富的c/c++程序员，lua基本玩不转）。在这些脚本语言面前，j***a毫无优势。nodejs开箱即用，用js可以前后端一起写（html5的流行让这种情况更是越来越多）。而php上手容易，开发简单，而且像一些用http的弱交互游戏，热更新简直不要太爽，无感知修bug。一些简单的休闲游戏，用这些脚本语言完全可以很快速的完成，就拿之前比较火的刀塔***来说，用这些脚本语言一点压力都没有，还有特别是***类游戏，脚本语言更是首选。
其次再来说说运行效率，在一些密集型计算的游戏中，c++是首选，一些大型游戏，对计算要求很高，业务逻辑复杂的情况下，提升效率就能多容纳在线人数，也是成本的减少。同时对内存要求也高，使用c++可以数着内存写代码（手法过于夸张[捂脸]），对象啥时候[_a***_]，啥时候释放都是程序员说了算，gc消耗不存在的。而j***a生成的都是字节码，代码执行都要经过jvm来跑，这中间的消耗对于那些对性能要求苛刻的程序来说，绝对不能接受。
综合以上两点，j***a处于运行效率和开发效率中间的语言，在游戏这个行业自然是不会受到青睐。
