Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  List of commercial games using Java?  (Read 34318 times)
0 Members and 1 Guest are viewing this topic.
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #30 - Posted 2010-10-31 03:06:16 »

How about PoxNora? http://poxnora.station.sony.com/index.do

Offline Sinuath

Junior Duke


Medals: 2



« Reply #31 - Posted 2010-12-01 13:05:01 »

it looks like league of legends might incorporate java  Undecided

http://www.riotgames.com/careers/job-openings-0


Hey [you][/you], you should totally check out my boring Site ~ http://davediel.com/chris
Offline tberthel
« Reply #32 - Posted 2011-04-14 14:48:59 »

My ten J2ME/Android games.

Zepto Towers, MiniSpaceWar, ZeptoRacer, MiniSpaceWar Vector, SantasWorldWar, Obama Stimulus, Don’t Lose Your Balls!, Zepto Wars - RTS (Art by Toke Rasmussen), Zepto Tanks - Multiplayer, and Zepto Tanks 3D.

Mine are not that pro but they are for low end Java devices.  Even less than a 99 39 dollar devices can get me 60 fps for new versions of all my 2d games.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline counterp

Senior Duke


Medals: 11



« Reply #33 - Posted 2011-05-11 06:51:44 »

A commercial java game: http://www.wurmonline.com/
Offline Rise

Innocent Bystander





« Reply #34 - Posted 2012-01-21 11:20:25 »

Long live necro threads ... I know, sorry, but I really thought that might be interesting.

You see, in reality I don't see any big commercial game having to do anything with Java at all.

So I found this interesting thread on the Bohemia Interactive Studio (BIS) Forums: http://forums.bistudio.com/showthread.php?t=128800

It talks about a game "Take on Helicopters" by BIS (a helicopter simulator as close as it possibly gets to reality and still being a game which is fun) which will get JVM scripting support in one of it's future patches (the game itself was released last autumn).

So, "Take on Helicopters" isn't that interesting (at least IMHO), but "the other" game franchise by BIS is called "ARMA", a military game simulator. The ARMA series will reach is third installment end of this year (may also slip into next year) and a comment by one of the game developers in the above thread basically confirms it's for ARMA3 too: http://forums.bistudio.com/showthread.php?t=128800#3 .

BIS was long known for their scripting support in their games but used something home-baked called SQF and it was/is quite arcane to use.

So, I hope this post is interesting to other parties also ... cheers.
Offline gouessej
« Reply #35 - Posted 2012-01-21 17:40:00 »

Long live necro threads ... I know, sorry, but I really thought that might be interesting.

You see, in reality I don't see any big commercial game having to do anything with Java at all.
What about Minecraft and Wakfu (the sequel of Dofus created by Ankama Games)?

Offline Cero
« Reply #36 - Posted 2012-01-21 17:50:48 »

What about Minecraft and Wakfu (the sequel of Dofus created by Ankama Games)?

didn't know that about wakfu. very nice, yet another big game.

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #37 - Posted 2012-01-21 17:53:13 »

is necroing such an old thread (from 2004) really needed? the featured games section seems to be a pretty good list.
Offline Damocles
« Reply #38 - Posted 2012-02-09 16:53:31 »

The Android Market has one or two java games...

Offline Cero
« Reply #39 - Posted 2012-02-09 18:00:19 »

The Android Market has one or two java games...

well what I like about this list is that it focuses on big games
you can write small casual games with anything
big games are interesting.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Damocles
« Reply #40 - Posted 2012-02-09 18:19:16 »

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.

Offline kaffiene
« Reply #41 - Posted 2012-02-10 02:07:27 »

You can add Tribal Trouble to the list.

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.

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.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #42 - Posted 2012-02-10 05:34:23 »

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.
Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #43 - Posted 2012-02-10 06:15:25 »

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.
SOMEONE needs to make them! Grin

Offline Preston

Senior Duke


Medals: 4



« Reply #44 - Posted 2012-02-10 09:32:41 »

You can add Tribal Trouble to the list.
Added. Thanks!
And I agree with your entire post, too.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #45 - Posted 2012-02-10 10:13:20 »

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 Smiley

Offline Cero
« Reply #46 - Posted 2012-02-10 15:30:39 »

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.
SOMEONE needs to make them! Grin

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

Offline kaffiene
« Reply #47 - Posted 2012-02-10 22:25:27 »

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.


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.
Offline kaffiene
« Reply #48 - Posted 2012-02-10 22:29:59 »

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.
SOMEONE needs to make them! Grin
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)
Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #49 - Posted 2012-02-10 22:39:23 »

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

Offline sproingie

JGO Kernel


Medals: 202



« Reply #50 - Posted 2012-02-10 22:57:20 »

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.
Offline kaffiene
« Reply #51 - Posted 2012-02-11 03:17:08 »

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.


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.






Offline sproingie

JGO Kernel


Medals: 202



« Reply #52 - Posted 2012-02-11 04:48:23 »

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.
Offline Damocles
« Reply #53 - Posted 2012-02-16 05:05:31 »

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.

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #54 - Posted 2012-02-16 09:27:38 »

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

Cas Smiley

Online pitbuller
« Reply #55 - Posted 2012-02-16 10:09:43 »

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

Cas Smiley

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.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #56 - Posted 2012-02-16 10:30:32 »

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 Smiley

Offline ReBirth
« Reply #57 - Posted 2012-02-16 11:13:03 »

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

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #58 - Posted 2012-02-16 11:36:39 »

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 Smiley

Offline Danny02
« Reply #59 - Posted 2012-02-16 13:09:12 »

just wanted to note that nearly all BigPoint games are written in Java, http://de.bigpoint.com/.
Pages: 1 [2] 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (39 views)
2014-10-17 03:59:02

Norakomi (30 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (28 views)
2014-10-15 16:18:58

TehJavaDev (57 views)
2014-10-14 00:39:48

TehJavaDev (58 views)
2014-10-14 00:35:47

TehJavaDev (48 views)
2014-10-14 00:32:37

BurntPizza (64 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (78 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!