Does really game development on Java suck? Why are we still here?

[longino]

I can't believe some people still claim Visual Studio is any good. Unless VS for .Net is so much better, my experience so far has been miserable. I am working on some C stuff (not C++, remember, they are distinct languages) and it is horrible:

- Eclipses closes blocks automatically. Microsoft seems to think that if you use { or ( you might not want to close it.  ;
- Eclipse formats the comments automatically;
- Eclipse has many templates for generating code, like for, foreach,, sysout, etc. I can't remember the last time I had to manually write a for loop;
- References are marked in a different color when the cursor is on top of it;
- When there's an error or warning the editor marks the line so you don't have to go looking for it or use the "go to the line";
- Most importantly Eclipse gives suggestions for corrections with Ctrl-1, like using an alternative method (like Google "Did you mean?") or creating the code for you;
- Although Visual Studio lets you browse through the code definitions just like Eclipse, in Eclipse I can visualize the definition of a method without having to open the file, by showing it in a box;
- Eclipse gives variable names automatically.

And that's just the beginning. Eclipse helps you alot more with suggestions, templates, code generation, refactoring, etc.

VS doesn't implement the C99 standard, even though it is more than 10 years old. It means that VS doesn't allow you to declare variables in a any part of the code, just at the beginning of the block.

That's the problem Visual Studio is TOO F***ING DUMB. It just stands there and doesn't even let you know that something this stupid is wrong:

1   2

if (i = 0) { }

I mean, WTF! I spent half an hour to find that shit! Seriously, VS sucks HARD.

Besides, why the hell is everything in VS 2 or 3 clicks away!? You know why? Because the UI is horrible. Eclipse has different perspectives so you don't clutter your screen with 1000 options.

In VS if you want to see the stacktrace and the variables you have to click 2 times and keep clicking between them.

Visual Studio is too "clicky". In Eclipse everything seems to be right in front of your face.

People who like VS should be exposed. If I knew VS was this f**king bad I wouldn't even have bothered.

[ra4king]

Hehe I'm not as passionate about it but I agree with longino

[_Al3x]

I find Visual Studio 2008 for C#.NET to be way too "dummy-proof", right away when you press "a" it drops a list of everything that exists in the project that you may write that starts with "a". Most of the time it tells you the right thing, usually you tipe 2 or 3 characters of what you want to write and it's right there, just press enter and it auto-completes.
For the "{" and "(" works pretty good, and the automatic indexation works fine.
There are plenty of things that could be better, but all in all, even if I hate to say it, VS 2008 for C#.NET is pretty good.
But I'd just stick with eclipse + java, beacuse I like them more. I just use VS for fast, small, windows-only apps and for a class at the University.

Eclipse <3

Games published by our own members! Check 'em out!

[princec]

I use Eclipse for Java and VC2010 or sometimes 2008 depending on which one it decides to launch (who knows why) and seriously, VS is 10 years behind Eclipse. In fact it's further behind - I was using Eclipse 10 years ago and it beat VC hands down even back then. Eclipse has strangely not really progressed a lot from its initial brilliance but then it did set itself rather a high bar. Not that the new features it has gained haven't been awesome (like realtime onscreen refactoring and such).

I tried using Eclipse for C/C++ a couple of years ago and it was a bit of a mixed bag. Much of the issue is just how crappily impossible C/C++ is to parse because of the preprocessor monkeying everything about.

Cas

[gimbal]

I tried using Eclipse for C/C++ a couple of years ago and it was a bit of a mixed bag. Much of the issue is just how crappily impossible C/C++ is to parse because of the preprocessor monkeying everything about.

That will be a big part of the problem why VS 2010 still has not nearly the assistance features that any Java based IDE has. There is only so far you can go supporting C++ development on the fly and still keep a pleasant working experience.

Perhaps I should rephrase what I said earlier. IF I had to do C++ development, there would be no other tool I'd use than Visual Studio to do that job. For C++ dev its great (compared to other C++ dev tools).

[Eli Delventhal]

Visual Studio is better than XCode, FYI. There's some good stuff in XCode but it's got way too much bloat and is riddled with productivity-ruining bugs. I agree Eclipse is far better than both.

[matheus23]

Visual Studio is better than XCode, FYI. There's some good stuff in XCode but it's got way too much bloat and is riddled with productivity-ruining bugs. I agree Eclipse is far better than both.

IMO, using Eclipse CDT isn't working as well too. Eclipse itself for programming Java is IDEAL. Theres nothing better than eclipse, but the CDT plugin is crap... I haven't tried MS VS, since I'm using linux. For anyone, who wants to program C++ on linux, these really have to try out Qt Creator. It's the best C++ IDE IMO, even better than Code::Blocks...

[BoBear2681]

I tried using Eclipse for C/C++ a couple of years ago and it was a bit of a mixed bag. Much of the issue is just how crappily impossible C/C++ is to parse because of the preprocessor monkeying everything about.

That will be a big part of the problem why VS 2010 still has not nearly the assistance features that any Java based IDE has. There is only so far you can go supporting C++ development on the fly and still keep a pleasant working experience.

Perhaps I should rephrase what I said earlier. IF I had to do C++ development, there would be no other tool I'd use than Visual Studio to do that job. For C++ dev its great (compared to other C++ dev tools).

So out of curiosity, any opinions on how Eclipse CDT compares to C++ in Visual Studio?  That's more of an apples-to-apples comparison.  I'd guess that MS has an edge since they control all of the C runtime, the compiler, and the IDE, and thus can provide a more robust, integrated solution.

[kaffiene]

Eclipse itself for programming Java is IDEAL. Theres nothing better than eclipse,

Netbeans 

[sproingie]

Eclipse itself for programming Java is IDEAL. Theres nothing better than eclipse,

Netbeans 

IDEA.  Gosh I bet someone will win the argument this time.

Games published by our own members! Check 'em out!

[gimbal]

So out of curiosity, any opinions on how Eclipse CDT compares to C++ in Visual Studio?  That's more of an apples-to-apples comparison.  I'd guess that MS has an edge since they control all of the C runtime, the compiler, and the IDE, and thus can provide a more robust, integrated solution.

Eclipse wasn't built to do C++ development. Of course support has been built in, but its a bit too basic. Netbeans has the same problem there.

Comparable to Visual C++ is Code::Blocks

http://www.codeblocks.org/

Its built on top of GNU tools, Mingw32 on Windows platforms. Its a bit fiddly to setup a project structure perhaps, but that's to be attributed to the language really

[MindOfCorruption97]

Java is a good progamming language to make games. like the first post, most games are breathtaking for their graphics and design. Java game developers aren't that skilled in graphics all the time. Java is a good programming language to develop games, I mean look at runescape and minecraft, even though they used external libraries, it shows that java is still a good programming language to use. It just takes hard word, that's all it needs.

[gimbal]

Java game developers aren't that skilled in graphics all the time.

They shouldn't have to be, that's the comfort zone of graphics designers.

Nobody is knocking the programming language here, the main beef is with the Java runtime and its unfriendliness towards end-users and its difficulty of deployment I've been playing around myself a bit with bundling a runtime with an application (according to my wishes of making it as simple as running a native application); through some efforts I've actually managed to create a little configurable tool that can strip down a JRE in several ways; I've tested it on a Java 6 64 bits JRE and I could take it down from ~100mb to ~28mb, about 14mb when 7-zipped. Not bad!

The only problem with that is that I have to yank out far more than Oracle allows in the rules for runtime bundling, so its no good for commercial stuff :/ The biggest contributor to the size is not the binaries but the rt.jar; for game development purposes I strip out everything that you don't need in a game which includes anything related to XML, JNDI, corba, JDBC, etc. etc. Hopefully, Java 8 with its modularized approach will make that easier to do and at the same time legal to distribute.

[Riven]

What's the main problem with a large download? The datatraffic of the download time for players?

If it's the download time, then all I can say is that your typicial game demo is about 100MB-1GB, dwarfing the LZMA-ed JRE size. Further, average Joe seems to think that a 5MB game simply can't be any good, so even in that way providing a big download is almost an advantage.

If it's datatraffic, well, it's cheaper than you think (about 0.05$/GB max) if you are willing to throw about $50/month at it. It's easy to scale, and if all else fails, use a free-ish CDN, like MegaUpload (ahem...).

[princec]

The old issues of JRE size are simply... irrelevant these days. Times changed. Only an engineer's fascination with unnecessary optimisation causes us to try and "solve" the problem.

Cas

[kappa]

Agreed and with Project Jigsaw being part of Java 8, the core JRE without modules is about 10mb-15mb uncompressed! So yeh JRE size is very much irrelevant these days.

Also consider how much bandwidth is used by your average users these days, typically just the front page of popular websites can be 1mb+ (e.g. a twitter page is about 3mb). Streaming video or watching HD Youtube video has also become common and you can use well over a 100mb of bandwidth without a sweat.

[gimbal]

Agreed and with Project Jigsaw being part of Java 8, the core JRE without modules is about 10mb-15mb uncompressed! So yeh JRE size is very much irrelevant these days.

That's awesome!

My reasons are simple: I create small games, I want to offer a small download package Of all the things I wanted to achieve this was the simplest so I started with it. That becomes increasingly more useful when you want to deliver MANY small games, but then I'd start to think about delivering them in one package. I only spent a few hours on it, don't think I would spend weeks trying to engineer something that is ultimately not so useful in the general cases. I have left the premature optimization phase behind me a looooooong time ago. The more interesting aspect of runtime bundling is that of cross-platform bootstrapping, and that's what I'm taking my time with right now.

Funny discussion anyway, I tend to say the same to people who start to hyperventilate when a program uses more than 1% of their 3GB+ memory. I tend to have to explain that it is the same as having a shed built in your yard and then keeping it empty because you don't like the clutter.

[krasse]

Eclipse/Netbeans are the main reason for me to stay with Java. BUT, there is a lot of enjoyment to just go back to a simple text editor (like Notepad++) and do some JS or AS3. Flashdevelop is nice to work with as well.

Just like a good and solid human relationship needs absence to work, programmers should leave the security of their home language/IDE to fully appreciate it

[Roquen]

WRT: JDK size.  It's also about perception.  Let's say I had an open source library that performed some small task that you need done.  You grab my precompiled jar and it's a few hundred megabytes.  The bulk size of the library will most likely make you predisposed to ignore the implementation.  Hey it's big.  Big means code bloat.  Code bloat means slow and badly written...move on to the next possible solution.  Now my implementation of the desired task might only be a tiny part of the whole library...but that would likely get lost in the noise.

Having a legal means of distributing small footprint runtimes would very much help with perception.

(EDIT: I'm talking about as an embedded scripting language here BTW)

[gimbal]

Well put; I suffer from that same perception myself I must admit. I do Java web dev also using JSF among other tools and I was using Richfaces for a long time to add easy web 2.0 crud to it. But Richfaces 4.X is already minimally about 8-10mb of libraries that needs to be deployed on top of all the rest; a web app with a bit of muscle in it (ORM for example) can easily grow to 30mb only in dependencies and then you're ready to write some code. So I dropped Richfaces in favor of Icefaces, which is under a megabyte and does basically the same, a little less perhaps but it fulfills all my needs. Part of that is because it is a lot less bloated.

I don't know what it is. I just like things to be compact to have faith in it. Seeing how people moan about memory usage and how earth shattering it is when the executable size of utorrent grows above a megabyte (as a truthful example that I can remember), I'm pretty sure lots of people suffer from the same condition.

[Riven]

I was under the impression that this topic was about game deployment, not library deployment. I really don't see the problem of adding 30mb of jars to a game... If you ditch a well proven lib solely because it's too big for your game-download, then you're making an odd decision, IMHO.

[Roquen]

As per usual, the topic has wandered around in all kinds of directions.

Wasn't the original question about Java's perceived lack of success in penetration the game's market?  While at the same time there is a perceived success of languages like LUA.  The reality doesn't really matter.

[gimbal]

I was under the impression that this topic was about game deployment, not library deployment. I really don't see the problem of adding 30mb of jars to a game... If you ditch a well proven lib solely because it's too big for your game-download, then you're making an odd decision, IMHO.

But not necessarily if there is an alternative which is far less bloated, is just as proven and provides the same basic features.  Blegh, its all personal preference anyway, discussing it is basically useless. My apologies for adding noise.

[Riven]

That's indeed a poor argument: if everything is equal except the size, then yes, you'd pick the smallest. We were discussing dropping libraries solely because of their size. As long as you stay under 100mb or so, typical gamers couldn't care less.

[ags1]

I think the problem is deployment - this is the area I dread when it comes to getting my app 'out there'. Deployment is the only special consideration for a Java game - after the game is installed the user couldn't care less what language it was coded in. 10 to 1 they don't even know what Java is, and if they have heard of it they probably think it is JavaScript!

I have done some development of NetBeans modules and Eclipse plugins and these offer a simple way to drag and drop Java code into a deployment environment. If there was traction in the community, we could use the Eclipse OSGI platform to build a game deployer. There would only need to be a single deployment of the game framework (which can update itself) and then deploying a game is as simple as copying the bundle to the right directory.

[sproingie]

If I ever hop on the OSGi bandwagon again, I might take a shot at bundlifying LWJGL.   It would certainly handle the problem of natives nicely, just toss a Bundle-NativeCode header in the manifest and boom, done.

Unfortunately, something tells me you won't get a whole lot of traction in general getting game devs to write OSGi bundles  

[princec]

I really don't see what the problem is here :/ NSIS. Installer. Private JRE. Small launchy executable or even a batch file. Windows done. Mac and Linux almost trivial.

Cas

[sproingie]

Yep, OSGi is more useful for distributing frameworks, where every customer is potentially a snowflake with a unique configuration of the platform, needing multiple simultaneous versions of whatever libraries.  Calling it overkill for a client-side game installation is an understatement. 

Needing a private JRE is an embarassment.  Hopefully Jigsaw helps with that.

[princec]

Needing a private JRE is an embarassment.  Hopefully Jigsaw helps with that.

Goodness no, a private JRE is the best thing ever. It becomes a "known quantity" when supporting things, and you get to choose exactly which JDK you want to code to as well.

Cas

[Cero]

whats the current state of jigsaw anyway ?