C# actually is quite good in many ways as well, but
unfortunately its open source counterpart (Mono) leaves
it trailing a little bit behind on operating systems
other than Windows.
This is just an uninformed opinion. Mono is just better for desktop applications and games, in all ways that count.
Performance wise, Mono is much more predictable. The VM starts faster and doesn't need special warmup. If you don't like the VM, you can always compile ahead-of-time. It has stack-allocated values, unsigned integers and if you're inclined you can always come up with your own special 256-bit integers that are still stack allocated.
I wrote lots of data processing scripts this last year and Mono had better performance characteristics than Java. And that's before I tried plugging in Mono.SIMD which totally blew me away.
Writing bindings to C/C++ libraries using P/Invoke is a piece of cake. That's because Mono has richer primitives; in "unsafe" blocks of code you can even have pointers and pointer arithmetic.
For desktop apps you can create native interfaces with GTK+ on Gnome, Windows Forms / WPF on Windows and Cocoa on OS X. I mean, the bindings for GTK and Cocoa are state of the art as far as bindings go and on Windows .NET is just native.
And some people scoff at the idea of building a specific interface for each platform, but I never seen a Java desktop application that I haven't found nauseating. Qt Jambi is the only hope you have for something decent, but kind of sucks on OS X.
So, having written some Java games back in 2002 or so, I can say that Java can be an pretty decent place for writing simple 2d games. That being said, there are lots of more interesting alternatives now that I'm not sure if Java is the way to go.
It isn't a BAD choice, but if I were an indie dev, I would look at something like Torque2D or Torque3D, especially since those give you a nice set of tools as well as a way to move to iPhone and consoles.
Also, if you want to get something off the ground fast, check out Corona from Ansca Mobile or even something like the LOVE 2D engine, between the two you can write your game in Lua, which is an awesome little language to write games in.
There is also the option of HTML5 and JS if one were so inclined. Given that everything seems to support HTML5 and JS now, once hardware catches up in the next 2-3 years, that might be an interesting option for game dev across all platforms.
Oh, and if you are going to do a 3D game, start with a good 3D engine and toolset, otherwise you'll spend all your time building an engine instead of building a game.
>I once heard something that has stuck in my mind ever since: "servers are cheap, programmers are expensive." In other words, you have to carefully choose your battles: at what point is optimization worth a programmer's sanity? Java might not be the fastest language, but it will keep you slightly more sane than C/C++, and is usually worth the slight performance penalty.
But then, why Java? Why not a language that's even more high-level (like Python, Lua, or Haskell)?
This isn't the first time I've seen someone with experience only of a lower level language get all aflutter when they first make a real attempt at using a higher level languages.
At a contracting gig I had, one of the Java guys gave us a talk about Scala. And OH MY GOD SCALA HAS MAPS and OH MY GOD SCALA ALLOWS FUNCTIONAL ITERATION OVER LISTS. It was like his entire relationship to programming had changed, and he had to tell the world.
I felt for the guy - he was clearly pretty excited about this - and it must have been like a breath of fresh air for him. The talk didn't go down that well though, as it was to the Perl team...
Heheh...I have used a number of different languages, from high level, like Python, to very low level, like assembly, and everything in between -- and pretty much messed with every paradigm at one point or another. I will readily concede to not being an expert in any of them. Most of my game programming experience has been performance-focused though (in HLSL/DirectX/C++), but I have worked with high-level languages in other areas. I tend to see a lot of hobbyists fall into this performance trap, and I am only trying to point out the virtues of sacrificing a bit of performance. :) Java and Clojure may not be the best choices, but having tried many languages I am passing them out as a suggestion for consideration.
You can write pretty fast code in Java, so on the JVM you can use Java as your low-level language. With Python, if you want to write fast code (at least with CPython) you have to write a C extension, which requires a certain amount of effort and expertise.
I personally don't know anything about Haskell, but I have heard that it has a very complicated performance model. I.e., it's hard to predict what will be fast and what will be slow, and if something is slow that seems like it ought to be fast, it can be hard to figure out how to fix it. (Since that was one of the major complaints of Haskell users the last time I seriously considered learning Haskell, it might be fixed or mitigated by now.)
Scala can also be slow or unpredictable when using functional idioms, but with Scala you can always revert to Java-style programming to get Java-level performance. The fact that you can do that for a single function or even a single inner loop in a code file that is mostly nice clean functional code is very convenient. One thing I hated about Jython was rewriting entire classes in Java when only a little part was performance-sensitive. Or, equally frustrating, having a Jython class whose associated "little" classes (performance-sensitive callbacks such as renderers) were in a completely different place in the source tree because they were implemented in Java.
1) It is very well established and widely distributed.
2) It is old enough to have been battle-hardened, but new enough to contain some useful paradigms/features. It also has support for higher level languages like Clojure and Scala.
3) It is a good balance between performance and ease of use.
4) It has many libraries and resources.
5) While I am urging to give performance some slack, that does not mean to ignore it completely. Because Java is imperative, it gives programmers slightly better control of their algorithms. Most graphics programmers prefer to work low-level, at least in the core of their engine. Python and similar languages are often integrated into script engines, but rarely used for the core of an engine. I am suggesting Java because it allows programmers to work in at least a somewhat low-level style (the byte code is semi-predictable).
6) It is pretty easy to get started and learn (not necessarily easy to master though).
I chose Clojure because it is Java-compatible, but Scala is probably just as good a choice.
Wow...I did not expect to be picked up on Hacker News, I am honored! I agree that established engines like Unity/UDK are probably your best bet for making commercial games, but I am targeting hobbyists/hackers for the most part, who typically like to build engines the hard (or stupid :p) way, from the ground up.
"First, let's be clear: I am speaking to anyone but console/mobile/AAA developers here."
Well, if you're targeting mobile, and by 'mobile' you include Android, you already have to use Java. You could use Clojure in this case as well, but Clojure in my experience is too inconvenient on Android to be worth it (yet.)
Scala seems to be a little better to work with in this case.
I think he is just referring to iOS. However I have to disagree the author that it's suitable for desktop GUI applications. I hate running Java programs on desktops (may be except Eclipse), as they always take much more resources than they actually needs, while still maintaining ugly interfaces all over different platforms, or would require much more work for the developers to solve issues with incompatibilities over different configurations of Java installs. For GUIs, Java is _still_ (for since Swing was available) not the choice.
If you are writing video games, then you're not likely to be using the built in GUI tools. I agree to an extent about the resources, but games almost always use a lot of resources in my experience.
I was just starting to consider Clojure on Android, too. I really dislike Java. I've tried Mirah, and it's better, but not enough better. Clojure was going to be my next attempt.
What did you dislike about it? App scaffolding? Compiling? Deployment? Use of Java libraries inside Clojure?
It's been a few months since I messed with it so it might not be as bad now, but the main problem for me was that Clojure on Android is slooowwww. This is mainly in terms of startup. You have to include the Clojure runtime with any programs you write with it and this is a substantial overhead on Android. Your binaries will be larger as a result as well. This is because, Clojure as a Lisp, expects the entire language to present all the time. This usually is the killer feature (it's a large part of what makes macros and the dynamic coding associated with Lisp possible) but it's a pain when you have limited resources.
The other issue I ran into was that there were issues in getting Clojure to interact with Android properly. Android requires that you compile your code into classes which means you will have to use :genclass in Clojure and implement a lot of interfaces. This in itself isn't that much of a problem (it will make you code less Lispy but oh well) but when I tried it there were bugs in Clojure which made it impossible for me to do some things on Android that I would have liked. That part of the language runtime is a little immature in my experience.
I wouldn't give up based on my words though. It may have improved since I last tried. If you want to look someplace for info on how to get started, I found that this fellow has a lot to offer: http://www.deepbluelambda.org/programming/clojure/creating-a...
If I were you I would still try it. I'm a little behind on my personal projects but I'm definitely trying Clojure on Andriod this month.
I've seen toy Clojure apps running on Android 2.2 and they took sensibly less than 5-10 seconds to load. I'm mentioning this since parent doesn't specify which Android version he was using, and JIT compiling was only recently introduced in 2.2.
I commented on the linked articles in more depth regarding performance game dev w/ Java. I see someone mentioned libgdx in a comment here which is awesome. Also awesome to see mention of Slick. I'll just mention that I have been working for many years developing a mature component oriented platform for real time app & game dev in Java that spans J2SE & Android utilizing all the language features of Java without sacrificing performance. I am barreling towards initial release. It's called TyphonRT and a little more info is available here: http://www.typhonrt.org/ I'm aiming for an end of summer release and I hope you might want to consider Java (w/ Scala) & TyphonRT for you next project.. :)
If you're considering Java for an OpenGL-based game, I'd recommend looking at LibGDX - you can target the desktop and Android all at the same time. Even if you're only targeting Android, LibGDX speeds up the dev cycle quite a bit, since you don't need to load to the phone as often.
I gave up on Java for games because I couldn't find a way to do vector math that was both clean and efficient. Basically, the options are:
Immutable vectors - loads of temporary heap objects
Mutable vectors - spaghetti data flow
Implicitly grouped primitives - horrible verbosity and repetition
And of course, there's no operator overloading.
There are potential solutions to this that could be implemented at the language level e.g. stack objects or macros that expand to primitives at compile time, but none of the other mature JVM languages seem to do any better at it.
Say what you will about C++, but it lets you write code like this:
vec4 lerp(vec4 a, vec4 b, float s) {
return a + s*(b - a)
}
that compiles to something efficient. With all the vector math that ends up in my game code, I just couldn't live without this.
In case anyone is considering this and wants an additional level of simplicity added to LWJGL, Slick is a great library for easy 2D graphics. http://slick.cokeandcode.com/
Even though this comment is getting down voted, it told me that there is a TL;DR at the bottom. Therefore now I shall click the link and read the original article.
Performance wise, Mono is much more predictable. The VM starts faster and doesn't need special warmup. If you don't like the VM, you can always compile ahead-of-time. It has stack-allocated values, unsigned integers and if you're inclined you can always come up with your own special 256-bit integers that are still stack allocated.
I wrote lots of data processing scripts this last year and Mono had better performance characteristics than Java. And that's before I tried plugging in Mono.SIMD which totally blew me away.
Writing bindings to C/C++ libraries using P/Invoke is a piece of cake. That's because Mono has richer primitives; in "unsafe" blocks of code you can even have pointers and pointer arithmetic.
For desktop apps you can create native interfaces with GTK+ on Gnome, Windows Forms / WPF on Windows and Cocoa on OS X. I mean, the bindings for GTK and Cocoa are state of the art as far as bindings go and on Windows .NET is just native.
And some people scoff at the idea of building a specific interface for each platform, but I never seen a Java desktop application that I haven't found nauseating. Qt Jambi is the only hope you have for something decent, but kind of sucks on OS X.