haha, I’m aware of that issue, its something LWJGL Applets also suffered from in the past but was fixed years ago, too bad funorb use their own opengl java binding :).
The reason I think Erlang is an unreasonable choice isn’t because of any technical issues, it is because of risk avoidance. Scaling shared state concurrency is a near intractable nightmare and Erlang’s model (actors/messages) is the only reasonable solution that I’m aware of. The problem is that Erlang is a highly complex functional language that one would have trouble finding a pool programmer capable of properly using it. As an aside, I find it interesting that Blizzard/Activision bought DemonWare back in 2007 and WoW nor any other Activision game (to my knowledge) uses Erlang. My thinking is that you can get the same set of features from other languages with less risk.
WRT: “It can handle a high number of threads” - We’re talking about two different animals here. I was talking about “real” threads at the OS/hardware level, whereas actor/message (et al.) systems use “lightweight threads” (fibers, picothreads, etc).
@Roquen: Exactly, and that’s why I said that serious, high-performance server-side programming is done almost entirely on the JVM. Akka is probably a great substitute for Erlang, and since more and more is moving server-side, I believe Java’s place in game programming will only grow.
@Cas: I have high hopes for JavaFX 2, too, but in retrospect, I’m not sure Sun’s negligence turned out so bad. The fact is that client-side is fragmented, and the only technology in consensus is the committee designed and non-proprietary HTML+Javascript. That’s the way the leading hardware vendors want it. They don’t want WORA. Apple doesn’t want Flash. The Playstation and the Wii don’t want to share games. Differentiated software sells differentiated hardware. No proprietary standard stands a chance. However, the client world is becoming so fragmented, with so many different types of devices, OSs and programming language, that developers simply won’t put up with it for long, and there will probably be one or two victorious software technologies. Should Oracle put itself into this dangerous competition, especially without client hardware of its own? Well, I’m sure people in Oracle are pulling their hairs out in frustration over Sun not inventing Android, but that ship has sailed. What should they do now? It’s a very difficult question. The best result they’re hoping for (and the one which will probably be best for the Java community) is some sort of a favorable settlement with Google over Android, which will allow them, and “standard” Java to put its foot in that door.
Other than that - they should hold on and fortify their position on the server, and do well with JavaFX2 to make up for lost developer mindshare.
It can be elegant to have a thread per connection, and because of Erlangs green threads it makes applying this model more straight forward then with say Java. For example there are many comparisons between various Erlang built web servers and Apache, where the Erlang solution can handle a much higher number numbers of connections before falling over and during that time the amount of data it’s outputting barely drops (unlike Apache). Secondly Facebook uses Erlang for their messaging system specifically because it means they can have millions of threads all waiting for data to come in. Using greenthreads is ideal as most of the time the vast majority of those threads are blocked. In short you don’t have to worry if your number of threads spawns into the millions where as with Java and others you need to apply a solution to deal with that (thread pools, runnable tasks, etc).
I learnt Erlang for my final year project at uni and tbh it took me about a week or two to be able to start building complex system with it. It’s primarily just the pattern matching and single assignment that makes Erlang a functional langauge; it’s really on the edge of the definition and it’s much simpler to learn then proper functional languages like Haskell.
And they are fast on 80’s hardware aka slow cell phones. Do you expect Quake 3 on a 386? My games are much higher performing than yours on BlackBerry, J2ME, and Android phones.
Mono Touch requires Mac OS X (Xcode) and Mono .NET is not really cross-platform, it is noticeably different than Microsoft .NET implementation (look at my identi.ca account, I have given some examples about it), it is not comparable to Java. Lol DirectX is not really useful, OpenGL is better supported especially on embedded platforms, Direct3D Mobile is not very famous.
From my point of view the problem with using Erlang for a game server isn’t the language or the concurrency model, the problem is: are you going to code all the game logic in Erlang too, or do you want to use scripting? What about physics and collision detection (which has to happen on the server to some degree to avoid cheating)? Code all that in Erlang or use pre-existing solutions?
Beyond the mostly trivial (at this point using libraries similar to enet) client server communication, there’s a whole lot more going on in the server. Erlang most likely has ways to integrate with scripting languages but how well supported are they? Implement your own? Check Erlangs string handling ability before setting sail in that ship. Collision detection and even rudimentary physics? Erlang strenght is not speed in numerical computations.
So yeah, there’s a lot more to consider than the concurrency model.
This is such an interesting thread I just thought I’d throw in my 2c worth of rant…
My background is in academics (I teach first and second year computer science). Java is still the dominate language here, mostly because of external pressures during the early 2000. As I have an interest in gaming and I was forced to use Java, I decided to create a simple 3D gaming library in Java for my students (using lwjgl for rendering). Since then, the library has evolved into something rather useful and I am interested in the Java client-side deployment options.
During my research, it seems that Java is indeed very popular in the big shops on the server side, but almost non-existent on the client side until Android comes along.
This is very discouraging and frustrating at times, as I keep running into walls when I tried to create applets that run reliably on all platforms, windows seems to run fine, os x is a pain (their own Java version does not play well with applets), linux is ok but not great. When apple come out with their App store for macs, they outright reject all Java apps, making distribution of Java games on the mac desktop impossible. Android is the new hope for large scale Java deployment but Oracle is now suing Google over it, further hampering the potential of Java.
It seems to me that Oracle should invest into Java technologies (webstart, applet, etc.) instead of litigation.
I would agree with the fact that Oracle MUST improve deployment for client side ( but… but… I must admit that I am really happy that google is suing by someone that have enought power to sue it )
Don’t rely only on applets (especially on Mac, even the Ardor3D team has had some problems with it) and personally my first person shooter (that uses OpenGL but not LWJGL) works quite fine on Linux, Solaris, Mac OS X and Windows, someone succeeded in installing it on AmigaOS (I don’t know how).
I would like them to work together because Android is now a big player but the DVM has worse performances than J2SE For Embedded.