List of commercial games using Java?

Business and Project Management Discussions
#41

I think above a certain point (“Big game , eg AA or AAA PC Game”)
choosing Java is an akward choice. -> from the point of a 40 people commercial gamestudio…
As big games mean big budgets that can finance using or writing a high performance 3D gameengine.

I dont see the sense of using a “run anywhere” Virtual Machine then, wich will always burn more resources than
a direct c/c++ implementation.

The advantages of Java dominate in the small / portable / indy games niche.
Not the AAA graphic blenders.

#42

You can add Tribal Trouble to the list.

So… Vampire the Masquerade, Rainbow Six, IL-Sturmovik weren’t AAA games?

I totally disagree with you. I’ve worked with some of the expensive C++ based middleware like Gamebryo and Havoc. That stuff is no better than what you can do in Java. The only thing you have in the C++ world that you don’t have in Java is the huge investment in development chains and middleware. that is the element that provides most resistance to change.

If you read above about the networking solution they tried to use for Rainbow 6 - works brilliantly in Java, sucks to integrate with C++ code. I’ve had the same issue with C++ and Lua for scripting. That’s not a fault of Java that’s a reflection of the fact that existing C++ shops have existing C++ toolchains which they have a huge investment in. There’s a huge element of inertia to get past.

I note that Naughty Dog wrote a number of games in Lisp. That’s a language no more or less suited to writing games than is Java.

This idea that Java cannot be used to write AAA games is a failure of imagination and surrendering to inertia and laziness. If Java had all the middleware and tool chains that C++ has for game development, it would be used for AAA games all the time.

#43

Naughty Dog didn’t write their games in Lisp, they wrote them with GOAL: Game Oriented Assembly Language. GOAL was a scheme dialect that as the name implies worked at a very low bare-metal level, like scheme48’s prescheme and not RxRS. Being scheme though, it had lots of structure for that lent itself to high level macros. The GOAL compiler was written in Common Lisp. From what I’ve read though, they stopped using GOAL after the Jak and Daxter series was finished.

#44

SOMEONE needs to make them! ;D

#45

Added. Thanks!
And I agree with your entire post, too.

#46

The only thing hold Java back from AAA development is that the main cost savings - that is, the speed of actually developing the code - are tiny versus the overall cost of the project.

Also, they are completely and utterly negated by the fact they’d have to throw the lot out to port it to the two major console formats.

The Write Once Run Anywhere thing was a marketing meme that got seriously misinterpreted. It made sense to tools and libraries developers, middleware developers, such as database vendors, Eclipse, component vendors, etc. It meant that you could deploy a single binary and know it’d work the same everywhere. It was never about being able to make, say, a game, and it just run on anything without having to do tons of work for each platform you got it on. It still annoys me to this day how embittered application developers are about the fact that there are still idiosyncrasies between different implementations when the real value of it all - the fact they could write their apps using Eclipse on any OS - passes by unnoticed.

Cas :slight_smile:

#47

We dont even have simple video playback in java yet… =D

#48

Scheme is a LISP dialect! And I never said they were talking bog standard Common LISP and shipping that - the output is targeted to the PlayStation but that’s exactly what a PS specific JVM would do.

As for stopping using GOAL, that’s because the code maintainer left. As an aside - this is the biggest issue with functional languages (and Scheme certainly is FP even if you might hesitate to call CLisp FP) - you get brilliant systems that do exactly what you want that no-one but their author can understand or maintain. This is one of the major reasons that Java has been successful IMO - Java is usually written in a fairly standard and easily understood manner.

#49

The trouble is that for the commercial middleware developers, this is a chicken and egg situation. They don’t see a Java games market therefore they don’t support it therefore the Java games market is handicapped by lack of support. It’s a bit of a vicious cycle.

This is the biggest impediment to AAA Java games - you have to roll it all yourself. C++ programmer have it much easier.

That said, we get multithreading and concurrency out of the box and I think over the years as multi core becomes more common, this will be more of a win (BTW: I know you can do multithreading in C++ - I’ve written multithreaded media programs in C++, the problem is that the solutions tend to be (a) brittle and (b) non portable)

#50

Then I shall make video support in Java + OpenGL (let me learn a bit about OpenGL first :P).

#51

You say lisp, I think lists and hashtables and setf’s and CLOS. Sure GOAL is a lisp dialect, but GOAL and Common Lisp are as different as assembly and Java.

As for the maintainability of functional languages, it’s mostly because we don’t have degree mills churning out Redundant Arrays Of Inexpensive Developers for those languages. And probably never will, that’s simply the price of working at a different level of theory. I think most FP languages are fine with letting mainstream languages tag along once the FP guys have figured out the hard parts, such as first-class functions, type inference, and about half the compiler optimizations you can think of, such as SSA.

#52

Scheme is Lisp minus a shit-tonne of extra stuff you don’t generally need. In that regard, scheme is more the central core of LISP without all CLISPs endless add-ons. The comparison with assembly and Java is therefore completely off. Scheme is a pure, simple LISP. Assembly is not a pure, simple Java. Have you used Scheme and LISP before, because the comparison you make seems completely off to me.

I don’t buy into your theory that FP people are the only ones breaking all the new ground. OOP has broken plenty of new ground as well (Smalltalk, for example). I see FP and OOP as two approaches to programming which are coming ever closer in what they can express and how they do it (note that C# and soon Java has lambdas, LISP has had CLOS for a while) Scala is a good example of that continuing convergence.

Having actually done a fair bit of LISP programming (including writing my own dialect as a DSL) I’d reaffirm what I said earlier - FP is very powerful but doesn’t tend to be especially maintainable. Like all things, this is a continuum - I find Erlang code to be more readable and maintainable than LISP which I find to be more readable than Haskell or oCaml.

#53

I’m quite familiar with scheme, having tinkered with a number of dialects, including SIOD, S48, Guile, Bigloo, Kawa, Chez, and PLT Scheme (before it became Racket), though I can’t say I’ve written anything serious with any of them. I’m pretty sure there are more scheme implementations than commonly-used scheme apps. GOAL is not an RxRS scheme, nor is everything with sexps a lisp. I think this thread is derailed enough already.

I also never claimed FP broke all the new ground, but that it was more focused on advancing the state of the art rather than enshrining it. The Self folks came up with many of the optimizations that are used in Hotspot, for example.

#54

In the end, all what count is “how do I present my product to the end-user”

I think what held back Java from beeing a common Desktop engine for (smaller) games was simply the problem running a Java Progam.

The enduser mostly cant just doubleclick it like an execuatable. Or at least the developer can not know if the user can do so.
Packaging a private JVM is a solution, but quite ugly and heavy. (my JRE is like 100MB big, not funny when the actual game is like only 14MB…)
Asking the enduser to download Java is much to complicated.
-> Which casual user is spending more than 10 seconds to get the demo of “NeonPackman” started.
Its not like having some issues to get Skyrim running, where users would spend some effort to run it.
…Its just some game, with many other Games as alternatives to switch to.

Java is just hindering itself to be deployed for (casual)end-user applications,
treading normal people like they would and should be System Administrators.

Beeing portable over platforms is not much of an argument for Desktop games, where the actual money is
spend on Windows games. Where Java is complex to assure to get startet…

Since there where easier alternatives, Professional Gamestudios did not bother with Java.

Android on the other Hand shows, that when Java is implemented deeply and no hassle to be used, there are tons
of Java-based games beeing deployed.

Its all about making it easy for the enduser.

#55

Actually on Android the majority of games are being made with the NDK now because the JVM is wretchedly slow.

Cas :slight_smile:

#56

Do you have any source for that?

With libgdx haven’t noticed any slowdowns with dalvik actually it’s quite opposite.
Also devices cpu side don’t have anything to do with performance charasteric becouse all the games without heavy physics are fillrate limited anyway.

Edit: Source for NDK vs java distribution.

#57

Just go have a look at most of the good ones. Angry Birds, Cut the Rope, etc. Everyone’s using the ndk because you need to crank every measly drop of performance out of the phone in order to get the same framerates as on iOS. And of course, nobody uses Java generally in mobile if they want to make money, because all the money’s on iOS, so they write in C++ and port back to Android if they see any financial viability.

That is a broad and sweeping statement and there are obviously exceptions, but they are just that, exceptions.

Cas :slight_smile:

#58

I heard little about NDK, so you use C++ rather java on there?

#59

Basically yes, it’s a pretty crappy cop-out on Google’s part because they haven’t managed to muster the engineering resource to get that VM up to speed (having failed to reach a reasonable negotiation with Oracle over the use of the ARM JDK…). So in order to compete on a level footing with Apple they’d had to allow people to develop games using the NDK in C++. I predict that it’ll be around as a mainstay of Android game development for a couple of years at least, or until the JVM gets about 3-4x faster at any rate.

Cas :slight_smile:

#60

just wanted to note that nearly all BigPoint games are written in Java, http://de.bigpoint.com/.