Hi all,
I have very open and general question I would like to discuss and get as many opinions as possible for direction of one of our Java game book chapters.
The question is, on a per genre basis, how do you see Java’s strenths and weakness fitting that genre?
For example, in the genre of MMORPGs, I would say Java is a great fit 1) because of it’s networking capabilties, 2) because of it’s cross-platform capabilites, 3) because of it’s security. etc…
Any comments? 
Java fits adventure games well because they tend to be asset and logic heavy without the need for tight timings shooters have…
Also consider polymorphic behaviour - easier in Java than C++, and at no extra cost! Much easier to code behaviours into objects for RPG-type games I think, and debugging such systems is made much easier with Reflection.
Turn-based or slow-paced games, like many puzzle games, obviously lend themselves very well to Java. There are many useful parts of the Java APIs that while hard to take full advantage of in a real-time game provide a massive productivity boost if you don’t have to worry about speed so much.
I’m sure many of those smaller (10-20 MB sized) games like on www.realonearcade.com or www.garagegames.com could well be written in Java - even action titles (then with Jogl for example).
Online games, too.
Cellular phone games of all genres are done in Java (J2ME) I see. For example www.thqwireless.com
Probably EA too thinks Java will be good for PC online games of all genres, if you read the article found on the jobs forum: “Develop online games for Electronic Arts” (http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jobs;action=display;num=1067637267)
quote responsibilities: You will be part of a small, focused team that develops multiplayer Java games and their supporting infrastructure, which will be deployed through the EA Online network, including the AOL games channel and pogo.com. (…)
Your work will be enjoyed by millions of people on the stickiest game network on the Internet.
[/quote]
I still think the main advantage for games is dynamic class loading, i can write an engine & editor now, and others can come along and plug their own code in without needing to touch a single line of my engine or editor code.
I guess that also benifits MMO* and adventure games because it makes adding new content a snap.
I think it is important to NOT send the message that Java is only suited to slow-paced games with little action.
You can do a decent action-based game in Java. Alien Flux is an example.
It is important to point out that the techniques must be adapted to the Java environment to deal with GC pauses, and even JITC pauses. But that is more of an issue of learning the proper techniques than it is of the Java platform not being suitable.
So while fast action is not a particular strength for Java it should not discount the use of Java.
Ok… more to the point of the question now…
One type of game that I like to play is the Graphic Adventure. Where you move to place to place in a virtual environment - often represented as simple static pictures, sometimes using pictures mapped to a sphere (Activision marketed this as Z-vision I think) so you could stand in one place and ‘look around’.
Myst is the most popular example, but there have been some other good ones, Zork: Grand Inquisitor, and lots of smaller titles from SegaSoft, RedOrb, Sierra (e.g. Shivers I&II)
Those games would be so easy to code in Java and then they could target PC/Mac/Linux with one shrink-wrapped box… I wish they did do those in Java, so I could play some of the games
I originally bought for my PC on my Mac laptop when I need to waste some time away from home.
I think most strategy/adventure games also fit nicely with Java. Even some of the big hits like Black & White could be done with the new frameworks like LWJGL, JOGL, or Xith3D. The games I mentioned previously could be done with plain old Java 1.3.
The Sim games (“The Sims”, “SimCity”, etc.) seem like good candidates for Java as well. They are complex and would benefit from the better development times and tools available to Java developers. Giving more time to iron out the bugs in the game logic and tune things so they work just right. Those sorts of games must have a significant amount of time spent on bug fixing and tuning I figure.
I think game servers and indie development are the areas where Java really shines. I certainly don’t mean to say that Java can’t be used successfully elsewhere, only that I think it has a hard time matching the competition in most other areas.
Adventure games/children’s games is a market that seems to be held by Director and Flash and I don’t see Java matching the productivity of those solutions yet.
3D RPGs, like Morrowind (and The Sims, even if it isn’t an RPG), seem ideal for Java, but my experience is that Java lacks integration with popular content tools (like Maya) and third-party engines. This gives me the feeling that Java is at a disadvantage against productivity solutions for C++, such as Renderware, Netimmerse, the Havok SDK, DirectMusic (and other sound APIs out there that people here have commented positively on).
The integration with high-profile engines is only important to well-funded developers though, which is why I think Java is a great alternative for indies or others for whom it is cheaper to write the tools than to buy them. Especially since these smaller developers generally don’t have to worry about releasing the games on consoles.
As much as I agree with your comments above this section:
This is a bit weak. Surely the comparison is between C++ and Java, not the libraries that are used by developers. As rendering solutions are written/ported to Java developers discover that its far more productive and practical to work in Java when trying to utilise an engine. As mentioned in a post above the dynamic class loading and reflection make it far easier/quicker to reuse engines.
All that said, it is true to say that things arn’t being ported and maybe SUN could encourage some of the bigger names to consider it. JRenderware would be nice.
Kev
You’re correct that I am not making a strictly language-based comparison. I’m just posting what I believe to be Java’s competitive edge when looking at the whole picture that the different technology choices present to developers.
[quote] All that said, it is true to say that things arn’t being ported and maybe SUN could encourage some of the bigger names to consider it. JRenderware would be nice.
[/quote]
I think Xith3D looks very promising and I don’t know how well it integrates with 3DS (can you export animated and multi-textured/shaded models?) but my experience from Java3D is that one could easily spend a month on just integrating an engine like Xith3D or Java3D with Maya (writing an export plugin, defining a file format, writing a loader etc.). Then if you want physics…
Director offers a pretty powerful solution just by supporting integration with Maya and Havok, but I’d take Java over Lingo any day in a strict language comparison.
Yeah, sorry for jumping on that. Xith3D integrates with 3DS via a loader atm. The loader supports shaded, textured (single not multi) and animation at the moment. Multitexturing wouldn’t be hard to add if I could find it in the file format somewhere
Integration with Maya, wouldn’t you either read Maya native file format or export to one of the existing ones (maybe 3DS?). Having not use Maya I guess I’m not in a position to speculate (but I will anyway). The big advantage of Java is the masse of open source developers hanging around looking for projects to write. I’m sure with time we’ll see engines, integration and probably some funky bits we haven’t thought of yet coming from the Java fold.
Kev
I can’t think of a game I couldn’t do in Java. Right the way from Doom3 down to NetHack, it’s a good choice for any kind of game. It’s got some particular strengths in networking and threading that make it ideally suited to client/server gaming. This is mainly based on the libraries that come with Java of course, and like William says, there are other, very specific gaming libraries that aren’t available in Java – yet. Hurdle #1, access to graphics & sound APIs, is cleared. Hurdle #2, access to data structures from common tools like 3dsmax, LW, Maya et al is being progressively addressed. Hurdle #3, high level APIs, is also being dealt with satisfactorily.
I am not entirely sure of the value of “MMOG” server frameworks purchased off the shelf.
Cas
[quote]I can’t think of a game I couldn’t do in Java. Right the way from Doom3 down to NetHack, it’s a good choice for any kind of game.
[/quote]
It’s really good to hear this from you because you proved with the nice Alienflux that fast action games with Java IS reality.
And Elias will be showing you in a month or 2 that a 3D multiplayer RTS is going to be nice and doable too.
Cas
Ok, to relate my productivity argument to genres: RTS, arcade games, and MMORPGs seem to be good candidates to be written in Java.
The depenency on ready-made engines does not seem to be so big for RTS and arcade games and they are usually not done in Flash or Director, so the productivity benefit inherent in the Java language over C++ really has an opportunity to shine through. The only tricky part is that most RTS games seem to use interactive music, and that’s one highly complex component, so one might want to write a Java wrapper for DirectMusic or some other API to get that functionality right.
The reason I think MMORPGs might be a good genre for Java is that they seem to be complex enough to really make Java’s safety benefits outweigh the benefits of most productivity solutions.
I have played eight big MMORPGs and studied literature on many more during my master’s project to write a quest system for a commercial mobile MMORPG. The only ones that I’ve encountered (or heard of) that were stable from release were Dark Age of Camelot and Earth & Beyond. Dark Age of Camelot was based on the Netimmerse engine and Earth & Beyond probably had a simpler design because it was a space game (no terrain rendering, often very predictable and automatic navigation with waypoints etc.).
The other MMORPGs I have played seem to be based on proprietary engines and their releases were either delayed, really buggy, or both. I bet it is a better deal to write everyting in Java and have two programmers spend a month on writing all the import/export tools than it is to stay in beta a few extra months to chase down the bugs/exploits that Java’s safety features can prevent from ever happening (or at least help track down with stacktraces).
I’m really interested in seeing how the tech will hold up for Magicosm.
Btw, Kevin, I think Maya’s native files are just calls to the Maya API so you really need a plugin or a translator that uses the API. The main difference in features between your 3DS loader and the VRML export that you have in Maya seem to be skeletal animation/skinning though. You can just get vertex animation with Maya through VRML right now. It seems most of our problems would be solved if both apps would just fully support X3D export (including all its animation and multi-texturing extensions) since Xj3D is a very nice loader for that in Java.
[quote]I’m really interested in seeing how the tech will hold up for Magicosm.
[/quote]
cough, ahem
How? You need to be more precise here, because it’s not entirely clear whether you’re talking about the sandbox/SecurityManager stuff, or the implicit bounds-checked memory accesses, or etc…
The release problems had almost nothing to do with the programming language used…MMOG release problems tend to come down to a few core issues:
[]Lack of skilled Programme Managers (people who know how to make large/complex projects work first time)
[]Development mainly done by traditional games developers - i.e. people who know next to nothing about big server development; certainly the evidence so far is that most commercial MMOG’s have complete newbies working on their network code (and even, often, the core server code). I’m not making this up, but I don’t want to name-n-shame because that could be particularly embarassing (it certainly ought to be!).
The industry approach of “hack it iteratively till it goes fast enough” (whose biggest critic is probably Mike Abrash) is well known to be totally inappropriate for distrubuted system design and development. It also tends to be extremely bad for any service-based industry. The games industry has never been a services industry, so it’s not suprising that this approach has worked well historically. But it’s a death-knell for MMOG development.
[*]Not enough people (if any) on the project who know how to optimize distributed systems. Few MMOG’s seem to have a dedicated systems architect; even fewer have ones who appear to understand that, in server development, EVERYTHING is the bottleneck, it’s just that different things will be the bottleneck from second to second. Iterative approaches to improvement often never achieve a working system. You need different approaches.
Obviously you cannot divorce those three entirely from the implementation language. It matters, definitely. But fundamentally the catastrophic problems are caused by the issues above, not by choice of language.
FWLIW, our MMOG middleware uses a java core, but that’s largely for reasons like the ones Cas usually cites for using it in AF - it’s a nicer language to program in - than for anything related to the genre. (and convenient things like the fact that supporting a clustered-server product means your customers can and will have all sorts of extremely expensive and exotic equipment. Java reduces the costs of being able to support on all those platforms)
It even gets frustrating sometimes when people say “Oh, yeah, I guess it makes sense to write that in java because it’s server code isn’t it? And java’s quite good at server code?”. It just misses the point entirely :(.
[quote] How? You need to be more precise here, because it’s not entirely clear whether you’re talking about the sandbox/SecurityManager stuff, or the implicit bounds-checked memory accesses, or etc…
[/quote]
I’m talking about the safety features (bounds checking, fast failures through concurrent modification exceptions etc.), rather than explicit security features, but they are closely related.
Like you write, some fundamental principles of distributed application design are often violated when people who are only experienced with local applications write them. That includes the principle that connected applications have different security demands compared to purely local ones (the worst consequences of violating this principle are probably all the viruses that resulted when Microsoft connected Word to the internet through Outlook). Java should at least get rid of THE most common attack on basicly all kinds of servers, buffer overflow. Shadowbane had a massive, and well-pulicized, hack happen to it shortly after launch (also happened to DAoC and others).
Normal pointer bugs and other problems that don’t cause immediate crashes are also much more difficult to test for in environments that feature thousands of clients. At least Anarchy Online seemed to have a lot these crashing bugs, while many bugs in Star Wars Galaxies seemed to be more of the nature that you mention (the worst ones seemed to involve item dupes/disappearances, i.e. problems with the atomicity of the database interaction).
I agree that Java (and middleware like J2EE) is not a magic bullet to distributed applications, but I think Java definitely has an edge over the alternatives for this particular genre because of the importance of robustness, security, and reducing the amount of testing (I imagine that public MMOG betas are a lot more expensive than single-player game testing).
[quote] cough, ahem
[/quote]
You are a Swede. So the Jantelaw and its accompanying jealousy forbids me from acknowledging that you seem to be working on something really nice
Edit: sorry about many edits, but Hemingway’s “the first draft of anything is ****” applies to my posts too (hopefully you don’t feel that way about the last draft)
[quote]I think it is important to NOT send the message that Java is only suited to slow-paced games with little action.
You can do a decent action-based game in Java. Alien Flux is an example.
[/quote]
Yep, amnd I thpought about that befoer posting, but its true that many of Java’s higher-level features, such as swing, don’t map easilyl into the fastest twitch games but are useful in other types.
So while I don’t think Java is WORSe for twitch game (infact I still think its better then C/C++ in many respects) you can use more of the system “as is” in games that don’t require that tight timing.
That make sense?
Those speed up game implementation (which is one of the reasons I like Java), but IME don’t significantly improve MMOG server quality. E.g. the CCME’s should only occur because you returned
return ((Vector) v).iterator();
where you should have had
return ((Vector) v.clone()).iterator();
If you’re getting them for some other reason then they can point to a fundamental mistake in your concurrent threading model - but frankly if you’ve got a good project manager you should have test cases that discover that very quickly anyway (have a look at Larry Mellon’s presentation on “Automated Testing in TSO” - there’s a link from http://grexengine.com/sections/people/adam/gpg4 if you can’t find it elsewhere).
This kind of thing will be found before release independent of implementation language, so long as you have a decent methodology.
That certainly appears to be the most common general attack, allthough AFAICS it is not the most common attack on MMOG’s. Typically the MMOG attacks are aimed at the client or the client/server trust relationship.
So, a bad game design (from a security POV), like Diablo or Ultima Online - both of which did critical game calculation in the client - has people hacking their clients. In Diablo’s case there was the famous “town-killer” patch, and also various invulnerability cheats IIRC. In UO, it was the lighting calculations - people with a hacked client could see perfectly at night-time in Brittania.
Even without client-side calcs, you can still attack the trust relationship. Aim-bots in Quake are the simplest example here, where you violate the designers’ assumption that the stream of commands coming in comes directly from the quake client, and hasn’t been “improved” in any way.
Even if you get all that right (which thankfully quite a few games do these days - although still not enough!), then people will tend to attempt to spoof other accounts. Who cares about hacking the servers (high profile, likely to get you a lot of unwelcome attention) when you can just steal other people’s passwords, login, drop all their items behind a bush, then login again as yourself and pick them up. On many (most?) MMOG’s, there’s no way they can prove you stole the items.
Presumably we’re talking about client-side here? In which case, your arguments apply equally to any complex game-client, independent of genre (nb I don’t disagree, I’m just trying to keep to the topic :)).
That’s really depressing, given that the people in charge of SWG development knew very very well the problems of duping - and how to avoid them. I’m afraid I haven’t followed SWG’s release at all closely, so I can’t comment :(.
Right, this is the only thing I disagree with. In fact, I’m suspicious that the whole topic is a bit misleading. I can’t actually see any strong argument for using Java for a particular genre AT ALL.
What I can see is very good reasons for using Java to write applications. So long as we go around believing that Java isn’t good enough for writing all (non-console) games then I think we’re shooting ourselves in the feet, from a PR perspective.
Java is not a niche, nor a specialized, programming language. It is not a scripting language (as a few C++ programmers seem to think!). It’s a fully general-purpose systems language with some nice features that make it higher level than C++. It’s also not as mature as C++, and so in some areas has simplified a bit too much, and others not enough (and that’s the kind of thing that 1.4 and 1.5 respectively have been dealing with).
Shrug. IMHO. 