Reasons for doing a prof. game in Java?

Newbie & Debugging Questions
#1

Hallo,

say you would aid a small development crew in software-designing a full price PC game. Genre is 3D sim/rts/or-such.
The crew’s graphic artists have experiences with Renderware from former commercial game projects, and they suggest to use this as engine.
The crew’s ~three developers are mostly new to 3D, but used to 2D games in C++. One of them’s fit with non-game-orientated Java.

You would like to suggest to the crew to use Java and an OpenGL based Java 3D engine (like Xith3d). Are there any quotable facts (URLs) to support the choice of Java?

The problem’s: Many of the crew (project lead, graphic artists) don’t know Java and have got many prejudices. Their main “points” are:[] Java is not up to games.
[] Java is not ready for a full blown real time application.
[] With Java you don’t know what problems will occur during dev time, while C++ is robust and well known.
[] Renderware is an industry proven 3D engine, whereas Jogl/Xith3d is (currently) hobby beta.
[*] Publisher won’t like it when you come with a playable demo basing on Java: they won’t handle you seriously.
Personally I think Java would fit perfectly. The dev crew is small, and their productivity gain by using Java would be a big argument.
However, that’s not enough: facts, numbers, etc. should be presented and I don’t have them. I remember Jeff mentioned some enterprise studies which say that the efficiency factor by using Java could be 2 to 10. Could these studies be used for games, too? If so, where to search for them please?

#2

Do they provide any analysis of this? As far as I can see there is nothing to indicate strongly either way at the moment. However, its fairly trivial to say that Java is a flexible efficient language that thus far has been used many different scenarios. I’d guess that these are just as you say prejudice and would cause me to question your developers experience.

These are two perfectly valid concerns. If you’ve not done Java for years then you can’t be sure that you won’t have problems during development. But as a counter exactly how much experience have your developers had in games/3D? Without years of experience other problems may occur in development? Does this stop them developing all together? These are the risks you take in any development.

Renderware is fantastic! Its also expensive. If you want to pay the money go for it. But you’re a small development arn’t you?

Publishers won’t care what technology its in as long as it runs out of the box and they can get it cheap :slight_smile: At the end of the day the publisher cares about the buck and nothing else. Why should you even tell them what its developed in up front? (although I realise this changes from pub to pub).

Java won’t be able to be used in several years if development companies don’t pick it up and try it. However, I totally understand where you collegues are coming from, its a risk… its new, it might be safer to let the big companies who have plenty of cash to take the risks, but isn’t that how the big money is made? Taking risks on things that you think you can make work?

Hope these ramblings help or at least give you something to laugh at :wink:

Kev

#3

[quote]I remember Jeff mentioned some enterprise studies which say that the efficiency factor by using Java could be 2 to 10. Could these studies be used for games, too? If so, where are they?
[/quote]
I’d say the efficiency argument for java is still valid for creating games, although you have to keep in mind that this study assumes the developers know java well and know exactly what they’re doing. Since you mention the minority of developers know java well you have to count in the learning curve.

I think there is still a performance penalty with java if it comes to for example making huge amounts of JNI calls (for openGL). Making efficient use of openGL may minimize this performance penalty but you have to keep it in mind. I remember a thread here concerning this issue: Read about it here: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Tuning;action=display;num=1064909665;start=7#7

#4

No, they just don’t know Java and read the many prejudice in the press. Basically they say: “no-one uses Java in the game industry” so there must be some serious reasons.

[quote]I’d guess that these are just as you say prejudice and would cause me to question your developers experience.
[/quote]
Well, have you ever tried to convince a senior C++ game developer to accept Java? :slight_smile: Prejudice all over the place. The more they’re M$-orientated, the worse.
Similar things apply to graphic artists who’ve been working in the game industry for years (with Renderware, on consoles, etc): all they see all time is C++.
Both groups still think Java is for applets only. I showed them some nice 3d Java stuff but they can’t put it into relation and think “It’s OK for hobby gags but nothing more.”

[quote]But as a counter exactly how much experience have your developers had in games/3D? Without years of experience other problems may occur in development? Does this stop them developing all together? These are the risks you take in any development.
[/quote]
You’re absolutely right. Developing games does include new techniques more oftenly than in the “normal” business. So the risks are higher. But: No RISC, no fun. :slight_smile: (Acorn’s motto with their RISC ARM CPU.)

[quote]Renderware is fantastic! Its also expensive. If you want to pay the money go for it. But you’re a small development arn’t you?
[/quote]
The 10 000 $ (?) for Renderware will fit to the finance plan I’m told. The problem is: using Renderware will do two things which I don’t like:

  1. I’ve no idea if/how it would be usable from within Java. Or at least I didn’t hear of any Renderware native bindings for Java.
  2. It will tie the crew to PC (and consoles) only, because Renderware isn’t available for Linux and Mac (AFAIK).

[quote]Publishers won’t care what technology its in as long as it runs out of the box and they can get it cheap.
[/quote]
The publishers I’ve dealt with in the past have been a “really bad thing” ™. I’m afraid they’re no real Java fans. In the end they want your “Exe” to envelope it with some silly copy protection.
On the other side, like you say: probably it’s possible not to show them the internals. Insert the demo CD, double click a JAR (sitting next to a JRE) and they won’t even see it’s Java.

[quote]Java won’t be able to be used in several years if development companies don’t pick it up and try it.
[/quote]
That’s the point. One reason why I’m going to try hard to convince them.

[quote]Hope these ramblings help or at least give you something to laugh at :wink:
[/quote]
:slight_smile:
Now all I need is some figures, numbers, etc. Best would be a post-mortem of a professional Java game. :wink:

#5

[quote]I’d say the efficiency argument for java is still valid for creating games, although you have to keep in mind that this study assumes the developers know java well and know exactly what they’re doing. Since you mention the minority of developers know java well you have to count in the learning curve.
[/quote]
That’s true. However since they’re senior devlopers there should be a very small learning curve (one to three months at max) compared to a, say, a two year development cycle: I’m sure the efficiency gain still would be very big.

Also we shoudn’t forget the bug fixing part. It’s such a big topic in usual C++ games, that I dare to say this alone could justify the usage of Java. :slight_smile:
(I can’t remember how many memory and pointer leaks we had to fix in our C++ game: welcome to C++ hell, facing a deadline.)

[quote]I think there is still a performance penalty with java if it comes to for example making huge amounts of JNI calls (for openGL). Making efficient use of openGL may minimize this performance penalty but you have to keep it in mind. I remember a thread here concerning this issue: Read about it here: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Tuning;action=display;num=1064909665;start=7#7
[/quote]
Thanks for the topic hint. I don’t think I would suggest to the crew to use pure metal OpenGL, but a 3d engine basing on that. Xith3d I’ve been using during the last months and I’m amazed by it’s lightness and speed. I’m sure Yuri and David will increase the OpenGL optimization even further (for example like in the way Markus suggested in your mentioned thread).

#6

Knowing practically nothing about RenderWare, but maybe if you would create the java binding to Renderware yourself, you might still benefit from java’s productivity gain. In the end it’s likely just a very small part of the total codebase for the game.

Just a thought…

#7

[quote]Hallo,

say you would aid a small development crew in software-designing a full price PC game. Genre is 3D real time strategy. Design concept is ready, as well as several modeled demo 3D scenes (average 100 000 polygons on-screen at once).
…
The crew’s three developers are mostly new to 3D, but used to 2D games in C++.
…
The problem’s: Many of the crew (project lead, graphic artists) don’t know Java and have got many prejudices.
[/quote]
With my Project Management hat on (which is probably that thing your Producer is wearing, in case you wondered ;P), the first thing to do is look at the project-requirements; it’s not possible to accurately and fairly evaluate the tech you will use until you have a list (possibly quite long) of what it must do, what it mustn’t do, how you intend to use, what you will do with it, etc. You probably already have such a list (or you certainly want one anyway if you don’t!)

Then you can - very easily - produce an “analysis” for each of the possible tech’s (in this case, probably “C++”, “C++ + Python”, “Java”, at a guess…). I would very strongly suggest you include a sensible third alternative - otherwise you are in danger of looking like a java envangelist, and most programmers have a built-in suspicion of evangelists. It can also highlight other differences between C++ and Java that are not so obvious…

The magic moment is at the end, where you now have a list of advantages and disadvantages for each tech - customized perfectly to your game. Looking at these, it should be easy to see if one is significantly better than the others and NO-ONE CAN ARGUE about it! OK, so they still can, but what tends to happen is that the debates become much more rational and less vague and emotional - because now everyone has simple data to work from.

#8

[quote]Personally I’m sure Java would fit perfectly. The dev crew is small, so their productivity gain by using Java would be a big argument.
[/quote]
Now, if that were how you started a conversation with them, you’d completely lose me instantly. If I were one of your C++ pros, I’d want you to jump straight in with a list of things that might matter to me and how my life would be made better in those respects with Java.

E.g., start with your later statement: “I can’t remember how many memory and pointer leaks we had to fix in our C++ game” and say something like:

"In our last project, we had the following major problems which everyone is agreed endangered the project and should be avoided as a matter of extreme urgency in the next one:

[] Memory leaks
[] …

We also all probably agree that the following worked really well:

[] Object-Oriented design
[] Dynamically loaded data from text files instead of hard coded
[] Compiled language producing high-performance assembly resulting in a fast game
[] …

I’ve been looking at some alternatives, and found:

[] Java:
[list]
[] Is at least as OO as C++, and is syntax-compatible (simplified version of C++ syntax)
[] Avoids almost all memory leaks
[] Can load data from text files just as easily as C++, possibly slightly less code
[*] Runtime performance typically within 10% of C++; sometimes better, usually worse depending on application.

[*] PERL

[] Supports OO, but the syntax is different and some of the more advanced OO concepts (which we like to use) are poor performance or not available
[] Loading data from files and parsing it is MUCH better than Java or C++
[*] …but overall runtime performance is dire.

[/list]

OK, not a great example, but that is a frequently used (and recommended) approach for trying to “sell” an alternative process (as opposed to a product or service). One useful feature in particular is that if it fails then you’re hunch that “java would fit perfectly” was probably not quite right, and so you may have avoided an accidental disaster.

#9

This seems like the most important point to me, Renderware gives you win32, gamecube, ps2 and xbox platforms. Java gives you win32, *nix and mac. Renderware is certainly a more suitable choice for getting a game to as many gamers as possible, but do you have the time and resources to publish on consoles, or will this be pc only?

From what I’ve read renderware has some quirks between platforms, and you might need different art etc. asserts for different ones, but if you’ve got people already experienced with it and aiming for consoles then this sounds like the best choice.

#10

Plus Solaris and other Jogl enabled (Unix) boxes.
I say this because there’s no sales manager aboard. :wink:

[quote]Renderware is certainly a more suitable choice for getting a game to as many gamers as possible, but do you have the time and resources to publish on consoles, or will this be pc only?
[/quote]
Probably the dev crew will “just” do the desktop PC version, however it’s too early to say it for sure.

[quote]From what I’ve read renderware has some quirks between platforms, and you might need different art etc. asserts for different ones
[/quote]
Didn’t know this. Good to learn.

#11

To me instant crossplatform-ness would be a big selling point, as was already mentioned.

OT: Why another rts? Or maybe you guys have an innovative concept. Good luck.

#12

Hi Blah. Thanks for your comprehensive answer.

[quote]to do is look at the project-requirements; it’s not possible to accurately and fairly evaluate the tech you will use until you have a list (possibly quite long) of what it must do, what it mustn’t do, how you intend to use, what you will do with it, etc. You probably already have such a list (or you certainly want one anyway if you don’t!)
[/quote]
Yes, since the tech design is about to be startet we’re going to collect such a list.
The list will also allow me to show how the choice of Java will help us because of its large library. (For example: if you need to optionally load additions from the Internet, load/save Zip files, etc. in C++ you need to use some - commercial? - third party libs. Simply because C++ is just a language, whilst Java is a platform.)

[quote]I would very strongly suggest you include a sensible third alternative (…) It can also highlight other differences between C++ and Java that are not so obvious…
[/quote]
I see the point. However there isn’t a sensible third alternative.

[quote]The magic moment is at the end, where you now have a list of advantages and disadvantages for each tech - customized perfectly to your game.
[/quote]
This sounds well. So the crew can discuss in a better way.

The list is going to become Java centric. Today I see that the things we’ve done in C++ with our last game can be done with Java in the same way, but more efficient from a developer’s point of view. The productivity gain I’ve experienced with Java I’m going to stress in the list. Java is the mature C++ : I know this but have to tell it those crew members who don’t know Java. Not an easy task.

[quote]If I were one of your C++ pros, I’d want you to jump straight in with a list of things that might matter to me and how my life would be made better in those respects with Java.
[/quote]
OK, I’m going to concentrate on this.

[quote]In our last project, we had the following major problems which everyone is agreed endangered the project and should be avoided as a matter of extreme urgency in the next one:
° Memory leaks
° …
[/quote]
Good idea to stress this. I’ll collect more such items. The rest of your list is helpful, too. More good ideas in how to write such a document/presentation.
Thanks again.

#13

Straight C, C#, Blitz Basic, Dark Basic, and Delphi are all very eminently sensible alternatives to Java.

You’d be amazed what Blitz can do in so little time. It beggars belief. It should be seriously considered as it’ll be a tenth the development time of the same game written in Java. It’s RAD for games.

Cas :slight_smile:

#14

[quote]Straight C, C#, Blitz Basic, Dark Basic, and Delphi are all very eminently sensible alternatives to Java.
[/quote]
Delphi I’ve used for a few years, and while I loved it, it’s not suited for full blown games (actually it’s not even suited for complex business applications. Which isn’t Object Pascal’s fault).
C I’ve used for a few years, too, and while I never loved it, it’s in no way an alternative to an OO language like Java or C++ for complex games.

There are people who can program Lightwave in C, and Rollercoaster-Tycoon in Assembler. My mentioned crew and me are no such people. :wink:

[quote]You’d be amazed what Blitz can do in so little time. It beggars belief. It should be seriously considered as it’ll be a tenth the development time of the same game written in Java. It’s RAD for games.
[/quote]
BASIC is nice, I loved it (Acorn’s ARM BASIC was cool). But it’s not serious today. I can’t develop or aid in development of a complex game (~two years development cycle) in a language other than an industry proven, rock solid OO one. Leaves just Java or C++ to me.

I don’t say Blitzbasic is bad or not suited to games.

C# isn’t matured yet. And I don’t trust Microsoft.

I’m pretty off-topic again, I’m afraid. :slight_smile:

#15

I think while Delphi is great, Java does have a performance benefit (except for GUI’s). For example the Z80 emulator (from CottAGE) I wrote was first coded in Delphi, but it was way too slow. Later I rewrote it in C++ which was very fast. Eventually I rewrote it again in Java and while there was a performance penalty it was still fast enough (really lots faster than the Delphi version) and I kind of fell in love with java so I sticked with it.
Also, a friend is a Delphi developer and he often encounters performance problems and sometimes even has to revert to C for performance critical parts.

#16

Well, I think some solid documents/slideshows about the strengths of Java compared to C++, from a “normal” complex application point of view, would do, too.

Are there any? :slight_smile:

#17

We have some sheets that have soem inetresting development time statisics for a bunch of game projects that we handed out at CGDC about 2 years ago. if you’ld liek to meail me a snail mai laddress I suppose I could send you one.

They mean more if you can actually see the projects but at least its some kind of “real numbers.”

#18

[quote]We have some sheets that have soem inetresting development time statisics for a bunch of game projects that we handed out at CGDC about 2 years ago. if you’ld liek to meail me a snail mai laddress I suppose I could send you one.

They mean more if you can actually see the projects but at least its some kind of “real numbers.”
[/quote]
Is there any chance of getting those in digital format (so you can just put it on the web)? I’d like a copy, and I’m sure plenty of others would too…

#19

Preston,

Please e-mail me ASAP and I will provide you with a bunch of information. Also, let’s set up a time to talk.

-ChrisM

#20

Sure, let me see if Kinkos can scan it into as PDF for me.

Might take a few days.