C++ is most demanding and you have least knowledge of it. So that rule it out.

Many have said that C# bindings to openGL is 20% slower than Java have(lwjgl/jogl) but maybe that does not matter much.

So it's about flawor more than anything else. If you want use Unity then C# have some edge but otherwise I would prefer Java becouse of tools.

I go with theagentd xD I mean... Of course most of us will say Java. Go to a C++ Forum and most people will say c++ of course (can't understand those people, but whatever [even a friend which is highly skilled in c++, says that he hates the language xD])

I can only tell you my reasons for choosing Java.

I have the most skills and experience in java - biggest factor
C++ is quite old, full of shit and convoluted to say the least
C# is a microsoft standard - I might as well program games that only work on microsoft silverlight

also java games work without as much effort on at least 3 platforms

and performance, well, Server JVM is, once started, in many cases faster than C++

XNA is interesting, because its the easiest way of getting your game to a console - but I would only go so far as to port it, not write it exclusively for it

the only reason C++ is still so big, is that old established standards die slowly, just like Windows

At the start, for your first game. I would stick with what you know best. You will get more done faster and not be bogged down with learning new details. Your biggest enemy is not finishing anyway.

The tools are free for them all so download them and have a play with each one. Don't get caught in the trap of being a one language guy / language evangelist.  There's good and bad in all of them no matter what anybody tells you.

As per Kev's reply, the days of C# being Windows only are long gone. And XNA, most definitely, doesn't suck.

There's also game maker applications / frameworks (GameMaker, Unity, etc) that may be a better option if you just want to get games finished.

What sort of stuff do you want to write and what devices do you want to target? Answering that may help you decide which option to go for - at least initially anyway.


Oh, and Hi - first post :-)

 

I'm not resisting very hard though am I!

"Posted by Patrick Smacchia on January 19, 2009". Used an older version of Mono too.

There's also the MoMA tool: http://www.mono-project.com/Moma

In Java land, I've had a few folks recommend Slick as a decent framework.

 

C#, Boo, Javascript - core engine is C++ I believe.


Well, you've constantly proved that you can write great games using Java :-)


Agree 100% - Microsoft really, really dropped the ball with Xbox Live Indie Games. Use for fun / hobby projects. Still, it's awesome to see your games running on your Xbox. Big smiles there. And you never know, you could get lucky (Fortress Craft or the Dishwasher guy). Only way for most devs to write code for it though unless you miraculously manage to get on XBLA (although would you really want to do XBLA certification *shudder*)

XNA 4.0 is brill - they did a great job of tidying up all the crud. Not sure why people think they broke it - Well, actually I do. Most folks don't realise there are 2 profiles in XNA; Reach and HiDef. And as Reach is the default they assume all the fancy shadery goodness has been nerfed so they could target the Phone. They didn't. They made the reach profile robust enough to hit a wide range of hardware and fix up all various driver problems.

Desktop deployment is sucky though.


But Java isn't available on the Xbox so no worthwhile comparison can be made. It's the cheap ass Compact Framework they used that is the reason for 95% of the performance problems. If they have built a framework specifically for the console it would fly. And the in order CPUs don't like the branch heavy code the CF jitter produces.


C++11 may take away a lot of the 'pain' of traditional C++ but having not used I couldn't really comment.

As long as source code is separated in header and source files it simply can't be good 

Again, I thank you all for your comments. I have one more question to ask you, just to derail a little;

Is there something in java that you personally don't like, or hate, for that matter? Something I should be vary of, invest learning in the beginning, and so on?

edit: or avoid completely?

And i would say, forget getting applets to work... they sux!

Classpaths can be a real pain with Java... So figuring out how classpaths exactly work will prove extremely useful in the long term.

On the topic of choosing a programming language: I can program in assembly, C, C++, functional languages, C#, Python, Java, and some other languages that I forgot, and I tried to make games in some of these (most notably C, C# and Java), but Java is the first language I actually finished programming a game in. I think that's by far the most important selection criterium when you're starting out: choose a language that you will actually finish a game in. That rules out C/C++ as far as I'm concerned, since it simply takes much, much longer to get things done (unless you're a real pro at the language I guess, but even then). C# is quite possible, but you must like Microsoft / .NET and their approach to doing things. Also, once you have experience in game development I guess it's not that hard to switch to a different language..

There is no need of an equivalent of MoMa with Java, do you see the difference?

Oh how I could go on, but I think my primary gripe is an overall lack of expressiveness combined with a marketing effort that successfully convinced the larger community that this was a great feature and how none of us were worthy of wielding actual power in our language constructs.  Java as a platform, I love.  Java the language is the C of the JVM.

Ok, as for features you should avoid?  downcasting, unless it's absolutely positively necessary.  That goes double for instanceof.  Reflection, if it's used to "get around" static typing when a better design would suffice.    Manual use of threads and locks (use java.util.concurrent and concurrent collections instead).  RMI.  Use of serialization as a wire protocol or storage format (except for caches).   Using inheritance when composition will do.  Array covariance.  

The proliferation of "smart pointer" classes in C++ has led me to the complete opposite conclusion.  To say nothing of references, which have pointer semantics sometimes, value semantics other times, and act like plain old aliased names yet other times.