问题
I have been looking into game development recently and my first programming language is Java. After playing many stunning games developed in c++ I wondered why Java is not heavily used in the games industry. I looked at jMonkeyEngine 3 and a few other game engine environments but the screenshots I saw are far less stunning. Titles like Need for Speed Hot pursuit form EA and Assassins Creed from ubisoft convey such realism. Why can't Java produce such industry strength games ? Is it the art work?
Java and C# has automatic garbage collection and c++ doesn't. The programmer has to pay closer attention to memory usage to avoud dangling pointers and so on.
Thanks guys.
回答1:
Java and C# has automatic garbage collection and c++ doesn't. The programmer has to pay closer attention to memory usage to avoud dangling pointers and so on.
You yourself have answered your question.
In games programming garbage collection is not an advantage. Even if the performance of Java is more or less in par with C++ for most tasks, and the JIT can even do very aggressive optimizations that beat those that can be done during the static analysis; the garbage collection can make the framerates drop at the worst moment.
Also, for graphics intensive tasks Java is not very appropriate, as there are many things that are considered unsafe by the runtime, and thus are forbidden (like casting pointers to reinterpret data).
Another important matter is the already settled know how in the industry. The inertia of C++ in the games industry is huge. All game developers today know C and C++. Having a large developer pool to hire from lessens one of the management hazards that is key people leaving the company.
But despite that, there have been some successful games with some parts written in Java, like Vampire: The Masquerade - Redemption.
A more recent game like Minecraft is written completely in Java; but it does not feature state of the art graphics, as the emphasis is put more into the dynamic nature of the virtual environment.
And many other games and engines have a runtime that supports a managed (safe automatic memory allocation and collection) scripting language built on top of a high performance rendering and networking platform (written in C/C++), like Unreal Engine for example.
回答2:
Generally everything said here was a reason not to port to Java for game development; was. The gaming industry is currently hitting a paradigm shift. Three things have changed or are currently changing the gaming industry:
- Piracy
- Client-server program models
- Modular-networking program models
A game is not entirely dependent on itself anymore. The key advantages that existed in the former (low level languages) are slowing being out weighed by the advantages that exist within languages such as C# and Java (high level languages). Two crude but undeniable examples are games that work on Facebook, and remote medias such as phones, tablets, etc.
It is important to state that in all two scenarios, all three concerns listed above are dissolved. A game that can not work without a server need not worry about being copy infringed (private hosting through reverse engineering not included). The demand for network dependent games requires a language which can balance out system performance with network performance (usually a stalemate between Java and C/C++, favoring C/C++ strictly due to the abundant of pre-existing libraries). However, a game designed in a modular-networking program module would be impractical to develop in low level languages such as C/C++. A company who would be interested in designing a game in C/C++ for a Modular-networking program model would have to create a virtual machine entirely devoted to that one game, or reprogram/recompile the game a number of times too insane to think. IMO, while it may be too early to state which language be the preferred, I'm putting my bets on Java for three key reasons.
1) The JVM allows Java based applications to run virtually on any platform, whether Apple, Android, Windows 8, or Linux/UNIX derived (virtually supportive on any hardware platform as well).
2) Java uses OpenJL (the OpenGL derivative, which will run on OpenGL as a client - jMonkey is a engine designed in OpenJL). It is important to note that only Microsoft Windows uses DirectX, as good as it may be, it has but one draw back. Virtually every OS that can run games will be capable of rendering in OpenGL and modular design is pushing on this like never before. (Please note, Microsoft is trying to deviate this issue through monopolizing on the distribution of Windows 8).
3) Java supports threading internally within the JVM, which allows it to take full advantage of multi-core processors without the use of any third party library. Currently, this is a handicap for all other languages (especially ones developed for phones).
While the JVM does pose a latency concern, it should be noted that such concerns could be expunged through threading. I also wouldn't be too worried about Windows 8 and the push of Microsoft. Google has a stock share of $720/share, Apple having $526/share, Microsoft being $27 to date. While Apple is likely to be effected by Microsoft's push mainly due to using C#, Google on the other hand is likely to profit from it. Microsoft has never had much lucky when competing against Google and Google/Android heavily uses Java. Angry Birds was originally designed in Java FYI, and ported to C# for the iPhone. If Google/Android enforces standardization, Microsoft will drop like a fly, taking Apple with them.
回答3:
The answer to your question is artwork and financial resources. And originaly Minecreft was developped by one person in java. Whereas tittles as AC or NFS are developped from teams of thousand of people. Compare the resources. Moreover Ubisoft uses custrom game engine. If you are sole developper you should focus on the idea because of the lack of resources. And if you have an idea the garbege collector is unoticable in normal sole developer games. And as a sole developer you should choose the most rapid development technology.
回答4:
I wanted to address just one side topic of this question, but garbage collection is not necessary helpful for creating the low-level, performance-critical aspects of an AAA-type game engine. In fact, avoiding that kind of referencing and collection system for objects is helpful. You want even user-defined types to be contiguous in memory and fit adjacent objects in the cache, etc.
Aside from the performance issues of collecting garbage at periodic intervals and of scattering objects in memory, games can't afford to be leaky with their bulkier resources, and the garbage collector hinders things there. Yes, I just said that GC hinders the ability to avoid leaks.
Garbage collection is not a silver bullet against resource leaks.
As counter-intuitive as it sounds, look at the leakiest apps out there today: the ones where the longer you use them, the more and more the memory usage continues to rise. Typically they're not C or C++ applications. C/C++ applications can be notorious for crashing, but not so much for leaking. Those leaky ones are far more often programmed in languages with garbage collection.
For example, take Flash games. There are many out there, and not just complete amateur software, that use more and more resources and get slower and slower the longer you play the game, forcing you to sometimes restart your browser to get the game fast again. Yet they're coded in ActionScript, a language that has garbage collection.
In theory garbage collection should reduce leaks. In practice, it often eliminates the cheaper and easier-to-fix-and-spot physical leaks (whoops I forgot to delete this string) in exchange for the much more expensive and difficult-to-isolate logical leaks (whoops, the logic of the system causes bulky resources to linger around until the entire game is shut down).
This is because in a GC language, if you want to create shared ownership of a new resource, R, all you have to do is store a handle/reference to it in another object, A. B and C might also store a handle to R, and now R has three owners and will only be freed if all three owners release the reference. The user only sees and works with what A stores, so the game logic involves removing R from A periodically, but references to it linger around in B and C silently which the code forgot to release. In C/C++, the dangling pointer here in B and C can actually be preferable, as it would lead to an immediately detectable and correctable problem during play testing, where the developer running a debugger will very quickly spot and fix the issue. In a GC language, it's extremely difficult to detect and while the program won't crash, it can start leaking big time.
So GC definitely avoids dangling pointers, but if something would have been dangling in C/C++ and wouldn't be dangling in a GC language, then it's a logical resource leak in a GC language and a segfault in C/C++. Put another way, GC exchanges dangling pointers for dangling resources that linger around forever. It exchanges what would be a glaring crash into a silent leak that can be a debugging nightmare to discover (and may even go unnoticed long after releasing the product). So for something like a game which is creating massive, dynamic worlds and graphics and physics objects and so forth and possibly at every frame, logical resource leaks are a big deal.
Garbage collection is best when resource leaks aren't a big deal.
This previous scenario is unfortunately all too common in a large-scale team environment using GC, especially if every programmer is not very cautious of the pitfalls of garbage collection and the strong need for weak references. So GC is not necessarily something to cite as an advantage for making games, unless you're only talking about the highest-level kind of human logic. The lower-level, delicate system logic that has to constantly create and access and destroy resources is generally going to fare better, even in terms of avoiding leaks, without it.
回答5:
It is not entirely true that garbage collection is unused in the gaming industry. Unreal Engine 3 has garbage collection implemented for 'Script' classes. For them, the performance is acceptable when used lightly; the heavy lifting is done by C / C++ code that manages it's own memory.
As fortran said, Java is not really used in the gaming industry because of concerns over speed (Java runs code on a VM, not natively... most of the time) and because there are already a large number of talented game programmers who have written a lot of oft-used code in C and C++. That's not to say you can't make use of Java to make a game, because there are a few Java games out there, but the 'mainstream' gaming industry has invested heavily into a C / C++ backend.
回答6:
fortran and James covered it pretty well already, but one other thing I'd like to mention, which fortran kind of hinted at when talking about inertia, is the gigantic pool of libraries available in C++. Having multiple C++ libraries for almost anything you can possibly think of is a huge reason not to switch to Java. That's not to say that there aren't libraries out there for Java right now, but the C++ ones are already mature and have large communities of experienced devs. Not having to rewrite the same thing you've done 1000x before is a big time-saver.
来源：https://stackoverflow.com/questions/4796605/java-game-engines