Why makes games in Java ?

General Discussions
#1

I program in Java since 3 years, and before that I programmed in C++, using pure OpenGL and FMod for the sound.
Then I switched to Java, discovering what are scenegraphes, and then worked with Xith3D and ODE for the physics ( and I planned to use JOAL ).
But I had a reflection recently :

  • JOGL is a java binding of OpenGL -> Why don’t use OpenGL directly ?
  • JOAL is a java binding of OpenAL -> Why don’t use OpenAL directly ?
  • ODEJava is a java binding of ODE -> Why don’t use ODE directly ?
  • I want to use Cal3D, then need to port it or to make JNI code -> Why don’t use Cal3D in C++ ?
  • Xith3D isn’t the unique scenegraph in the world, I could use OpenSG in C++ in place of it.
  • C++ is faster (execution speed)
  • C++ is widely used
  • C++ is much more open source

So please tell me, why make games in Java ?
I’m about to switch from Java to C++, but I want to know your opinion, because it’s a lot of work.

#2

The general reason is that Java is easier / quicker to write code in than C++.

#3

What he said. I get the same results in half the time.

Cas :slight_smile:

#4

I agree, but what a pain to port/do bindings of all librairies.
Wouldn’t it be possible to build a solid, object-oriented, well-designed C++ development platform that makes work easier just like the JDK does ? It isn’t the language in itself that permits to code quickly, it’s all the built-in utility classes that are useful.
For example, one thing I really do like in Java is Swing, I think this GUI system is very well designed, and easy to use, yet a bit slow. But using QT/GTKmm in C++ is that harder ?
Java wasn’t originally made for games and there are aspects of this language that makes making games in Java hard, e.g : no direct hardware access…
In the professionnal world, apart from independant little games studios (like oddlabs), all are using C++. if I want to have a chance to transpose my open-source experience to a real job, isn’t it better to code in C++ ?
Another thing about portability. I like the concept of ByteCode. But as soon as JNI comes in, we are obliged to produce platform-dependant libraries, and that ain’t an advantage anymore.
I prefer Java to C++. But C++ seems to be more suited to make games.

#5
[quote] Wouldn't it be possible to build a solid, object-oriented, well-designed C++ development platform that makes work easier just like the JDK does ? It isn't the language in itself that permits to code quickly, it's all the built-in utility classes that are useful. [/quote] Yes it would be possible. However, it *is* the language that makes it possible to produce games quickly and cheaply. If you were to create this C++ library which handled alot of the utlity stuff for you, you'd still have to cope with C++ code from the user.

C++ is harder to debug than Java.
C++ doesn’t provide any sort of memory management (this can be a good thing for high performance games, but for most its just added hinderence and leads to more oversights and errors)
C++ isn’t as cross platform as Java (as much as many people would like you to believe, ANSI C++ etc)
C++ typing isn’t as strong, to easy to let something merge into another type, allowing accidental design/code errors

Essentially, coding in C++ takes more thought, attention to detail and hence time. While that might make the developer the “Uber Geek of Coding Town” its not what I want to think about while developing a game. I’d rather be focusing on the game idea, mechanics and playability. I’ve programmed C++ for a few years commercially. Its not harder to program in really, it just takes more time.

Note to Readers: I’m really not trying to insult or belittle the C++ games programmers out there :slight_smile: I really don’t want any hate mail :slight_smile:

At the moment, frankly, yes! However, before the time of C++ in games everyone said you had to code in C, and before that you absolutely had to do ASM. I don’t see why a managed languages like Java and C# shouldn’t be next - I guess it depends on what time frame you’re interested in.

Yeah, but thats the really great thing about JNI libraries IMO. The bits that are platform specific are very obvious and tend to be limited to the absolute must haves. Its nice and contained. More to the point, the native libraries needed for games development right now are already made available to you. Mostly, for free!

From what you’ve said, really its not about suitability, its about acceptability - which I think we can all agree is a problem. What games developers should be thinking about is Productivity. How quickly can I take my game concept to game product to mooola? This is why things like Renderware and the Torque game engines are so popular, they get you there faster.

What could be better than having a language design to increased productivity (and doing so very well in alot of places) used for games development?

Kev

#6

And also, with LWJGL, or JOGL, JOAL, and JInput, or even SDLJava, all this tedious work has been done for you. Just get on and write the game and stop blithering over technology!

Cas :slight_smile:

#7

Even Sun’s Java libraries are platform dependant. You notice that you have to download a JDK for Windows or a different one for Linux, etc… The code you write will always be portable(Except for JNI). But the JNI stuff in the libraries you use is already taken care of. All you have to do is include the correct distribution.

#8

I’m surprised no-one ever mentions compile time when this discussion (inevitably) comes up. Even huge Java apps only take a few seconds to compile, but with C++ you can easily start getting compile times in the range of five, ten or upwards minutes. I don’t know about anyone else but when I have to wait that long to fix what should be a simple logic bug my productivity goes right down. Yes you can get partial compilation but the majority of C++ versions are either unreliable or don’t save much time (particularly when I change one header file and have to rebuild the world, even when I know most files aren’t affected) - compare and contrast with Eclipse which makes it so I never even have to think of compiling any more. :slight_smile:

When was the last time you heard of someone writing a distributed build tool for Java?

And thats before you’ve even thought about tracking down those inexplicable and seemingly random bugs due to uninitialised variables, array overwrites or stomping about on the stack.

It’s not that these problems are unmanagable, it’s that when I’m doing this for the hell of it I’d rather be spending my time where it counts. :slight_smile:

#9

I don’t understand you - first you start loads of projects in Java (gamma, Williams Adventures, JavaInGames, UI for Xith3d,…) and there are also projects you take part at as developer (e.g. SpaceBomber) and now you want to switch back to c++ ?

#10

I’ve programmed in C++ quite abit… and coming to java is like going on a nice vacation :-)… That you never want to end…

I’ll never go back to writing games in c++ (at least not as a hobbyist programmer…)… so many time wasting and booooring bugs!.. I definitely agree that productivity is easily doubled if not more in java…

And I just hate using separate header and code files… it’s so much nicer with everything contained just in one source file… (not that that is a big selling argument for java… it’s just my personal feelings…)

#11

Good point OT!

I downloaded Open Scene Graph and spent HOURS compiling it. Incredibly slow.

#12

I currently do some things in assembly, however…

A few days ago I tried to compile a some program in C with command line VC2003 tools. First I discovered that .c extension really ment a C program, so no cout. Second I discovered why C, and in fact C++ is so tedious, and I was assine so much so I copied .h file into .c file to simplify my work. Then I screamed where is reasonable documentation, there isn’t any. In addition I had 0 access to the internet, and I remmembered that CDs with at least the crapy MSDN docs are somewhere between 150 CDs with anime. Of course MSDN docs are not reasonable docs, because you need a search feature and hope, to work with them. Then I tried to remember how can a work with printf. Then I discovered " …" + value[sser] will not work. Of course it didn’t give me any error message.
Java is at least consistent with working with strings. It consistently changes it on background into stringbuilder.add(…). Of course C/C++ and it’s lack of error messages, lack of thread abstraction(at least basic and multiplatform), and a several different inconsistent ways how to print a character.

I consider it as much more problematic than an assembly. Majority of my problems are applicabe to C++ as well.

Of course I remember also on a nice few hours long attempt to create a nice file with " 1 1 1 \n 2 2 …" inside. However my brain was off line, I wanted to use a some sofisticated method, and I didn’t looked into documentation. When I had that above problem with C, my brain didn’t went off line.

If you need an another argument against C++, try to reinstal all neccessary programs for development in C++, and documentations. Do it every week.

I also know what could happen when someone somewhere would change definition of a type.

BTW in what library is frandom(), or srandom()? I tried to blast out debian, and was sucesful, and my windoze platform SDK is who knows where.

#13

You can’t really access the hard ware directly any more. (Unles you make a boot up game or use a OS that allows you to. Try to access a different memory location out side your program, A000:0000 for example or a hardware port number or even try calling intturupt 10h in C++)

Easy to do graphics and Easy to read and understand. Thats one reason to do Java game programming.

#14

I’m not into graphics programming, but i began interesting myself in Java after playing Chrome (i still have an image from it as wallpaper). That game (although DirectX 7) still looks good, and i’ve had no speed-problem when playing it.

There is just the question: who still wants to do the “fastest/best looking graphics engine” competition?

I totaly agree on the increased productivity. The Collection’s are a programmers best friends.

#15

Wow there’s a lot of things to answer.

So first :
@arne : It’s sure I’m not an excellent programmer (you may say I’m a bad programmer :slight_smile: ) and sometimes I run and make projects and never finish them. However, sometimes I’ve a sudden and temporary intelligence regain and I ask me (and others) questions about : Why I’m doing that ? Why I’m doing that that way ?, and so on… So it wasn’t an announcement. It was a reflexion. I don’t plan to abandonate Gamma yet (but that could become true if no-one’s interested… :frowning: ). And considering all the advantages of Java these kind peoples remembered me, I’m not yet ready to stop to program in Java.

So, the reasonable answer seems to be : “Okay, dude, keep working with Java. You’ll gain performance if you switch to C++, but it’s soooo a pain to code and hardware is so powerful now that’s it’s really not a good idea.”

So now, why don’t make a little reflexion on : “What is lacking in Java to make good games ?”

And I engage you all to follow the discussion on this other discussion thread (I promise you it’ll be interesting…)

#16

[quote]It’s not that these problems are unmanagable, it’s that when I’m doing this for the hell of it I’d rather be spending my time where it counts
[/quote]
That’s it exactly!

#17

From where I am sitting, the tools. LWJGL basically provides everything you need to make it possible to make a proper game. However a lot of utility classes and frameworks are still needed. There are a number of scenegraphs being worked on - but none of them actually make it simpler to make a game - they only help you render it - more or less.

#18

One day I made a GBA emulator in Java (named “Girlfriend Advance”).
I made some changes to enable my GUI to be displayed in some other languages.

I had almost nothing to change in the program to support chinese characters, and the chinese text was displayed at the first try on a chinese computer. The internationalization is easy with Java and show that this language is highly cross-plateform.

Lately I had to do the same with a C++ game that I wrote (I am a professional game developer) … it tooks many weeks just to have the chinese font displayed.

#19

To be fair, the majority of the problems you’re having there are because you’re really using C, just via a C++ compiler. Which brings me nicely on to my next point:

Lots of people (me included) tend to write ‘C with classes’ rather than ‘proper’ C++. Which usually ends up avoiding many of the more powerful features[1] like exceptions, templates and most of the standard library. This usually ends up involving lots of raw array manipulation (which we all know is error prone), very little data structures other than arrays and simple trees (especially when an stl container would be much more applicable) and lots of macro jiggery pokery. Occasionally there’s good reason for this. Largely I’d say there isn’t however.

In the example above, stuff like cout gives you lots of type safety that C’s printf doesn’t give you. And so we get to yet another problem: well written C++ code can be genuinely nice to use (see: most of the stl and boost). Stuff is type safe, does sensible things with overloaded operators and easily customised (like the sorting algos). And you can even get code which doesn’t care (or apparently doesn’t care) about memory and you never worry about memory leaks. All is nice and dandy - until you actually look at the library source. It’s hairy stuff, using lots of language quirks and special-case features. It’s unreadable to most mere mortals, and as such it’d be a pain to maintain.

So, IMHO, C++ either ends up being awkward and error prone, or having a nice interface but being torturous to maintain.

[1] which is ironic, given that most people’s reason to use C++ is ‘power’. Whatever the hell that is. And frustrating, as although they might be quicker at runtime than people give them credit, compile time still suffers.

#20

I don’t quite agree with that. Templates can be an utter shit to work with -> crappy error messages, code bloat, container implementation spread throughout your code.

STL is invaluable (noone should have to write their own container library) but the API to it was written by a drunk braindead encephalitic monkey on a bad hair day and suffering a lack of sleep. It’s seriously screwed. I’ve written container libraries in C and C++ before - I wrote them prior to the STL - and I can attest that one can create perfectly nice OO container code in C++, but the STL sure ain’t it.

And cout ain’t all that great -> c.f. BufferedReader ::readLine in java to istream::getline in c++. Java gives you a string in one line. C++ gives you a char array NOT a std::string, AND you have to tell it how many characters to read per line max, so either you have to write code to handle reading in chunks and inserting into a std::string (checking for EOF and ‘\n’ as you go) to get the equivallent, or you open yourself up to buffer overruns and just convert the char array directly into a std::string and ignore the possibility of long lines.

Fugly.

throw in stuff like no decent stack traces, having to write code to prevent the compiler generating class code you dont want, different coding styles (procedural, OO, generics, faux functional), memory issues, library flavour matching (single, multithreaded, debug vs release versions), the fact that most of the API available to C++ uses char* rather than std::string and C++ starts to look like several layer of silt cobbled in a great big mess.

That said, I like C++ ;o)