Programming language decisions

Make sure you learn how to create applets as you will get a ton more feedback from the community if you provide your game like that.

And i would say, forget getting applets to work… they sux! :smiley:

Applets are great to share your works with developers.

Applets are horrible to commercially depend upon => ship your own JRE as part of your standalone application.

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…

This.

Applets are causing lots of issues if you are going to try to make money on the project, but you get at least ten times as much comments if you put an applet up for us (or any other forum) to test instead of giving a download link.

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

I advise you to avoid autoboxing because it is quite easy to create very buggy things with them, particularily when you use them with ternary operators. Use applets with care as some browsers have a real poor support of them.

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.

actually you know what I like more in C++. You can say: ok this is a pointer String*
you are always sure in C++ what is a pointer and what not, while in java technically everything is a pointer and it can get hard to keep up in situations - of course this only depends on how you implements stuff

java puzzlers is a nice showcase of what to avoid

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.

I think that go-lang will be balance between c++ and java, so I think that is language of future.
I hope so that in the future we can make apps for android in go-lang, I heard some rumors about that :S.
http://golang.org/

Well if you mainly want to make a game, and dont have any preference for a specific language,
why not go for a gameengine instead.

unity
torque
gamestudio
XNA
UDK
Flash
etc…

You will have much quicker results then and gain selfesteem quicker, wich might later circle you back
to a more puristic approach using a language like c++ or Java with a lowlevel Graphics API.

I was going to say the same thing. And of course sometimes you get a pointer to garbage because it’s been accidentally deleted behind your back. Or maybe it’s something that acts like an opaque handle but it’s actually a pointer when used internally - or worse, callbacks or interfaces that force you to cast pointers to int or void*, then cast them back again and hope you’ve casted it back to the right class or it’ll just do Weird Shit™.

I had a fun talk with one of me programming friends and he said he spends so much time to make C++ work as intend while in Java it’s so easy. He often wonders why the sytax is so cribbeld xD My guess is that the founders of C and C++ are assembler dudes xD

Anyway, something I don’t like in Java:
operator overloading… I really hope that this will come some day .___.

Go is still too young (tools, ide’s, compilers, optimisations, developers, etc) and doesn’t provide anything significant above and beyond what is possible with C++, Java and other JVM languages. So far it just looks like yet another language that’ll be lost in the sea of new languages that come out all the time. Also I get the impression that Google are pushing it half heartedly especially now that they’ve got other darlings like Dart. So a bit premature to say that Go is the language of the future, it’ll take a lot more to topple well established languages like C++ and Java.

Different things surely? Go is aimed at back-end server work, Dart as a Javascript replacement.

Either way, my understanding is that while Go is used quite a lot internally they don’t really care about having it work on windows since they don’t run any windows servers. Which means it’s future use as a ‘proper’ multiplatform language are a bit bleak.

Yeh aware of that, was mostly coming from the direction that the single company is splitting its resources to push two different domain specific languages. Unlikely say Java which was initially pushed as a language that would work everywhere.

I wish Java had delegates like C#. But, you can implement that with Interfaces in Java and it doesn’t really apply to games.

Java doesn’t have a preprocesser ( as far as I know ), so it’s difficult to have conditional compiles.

Java also doesn’t have an alias for namespaces ( whoops, I meant packages ), not a big deal, but I use it in C#.

Working all day writing C#, come home and write JAVA, I mix up the keywords ( bool <> boolean, lock <> syncronize, package <> namespace, etc).

For any language, learn everything you can about multi-threading. Learn about every trap you can and how to avoid them.

If you get to the point where memory becomes an issue ( or if your bored and have some free time ) learn how the garbage collector works, especially for value types ( primitives and structs ) as opposed to objects.

Some J2ME developers use their own preprocessors and anyway, in my humble opinion, it is useless for J2SE, you can perform these tests once at runtime. If you use Java, think in Java or you will become very frustated as time goes by.

All three languages include:

  • Examples of excellent games built using them
  • Implementations with excellent performance (even when one is shown to be slower, it’s still damn fast)
  • Mature and battle tested implementations
  • Large and active communities
  • learning examples
  • Tutorials
  • lots of game-related libraries
  • tonnes and tonnes of other libraries (which you’ll need too)
  • on going development (with both implementation and libraries)

My overall point is that isn’t any real reason why you should use one over the other; they are all excellent.

But if I had to chose, it would be between C# and Java, but probably leaning towards C#. This is because I’ve seen tonnes of excellent stuff with C# that I’d love to use, and I like languages that run with adding new features (so I have more stuff to play with). I also develop pretty much exclusively on Windows, so I’d prefer good Windows support then cross platform. C# also has more, and larger, game development communities. However Java has NetBeans, which for Java development, is enough of a reason for me to use Java for a project.

If your really stuck, flip a coin, or roll a dice to decide. You can’t pick a bad option.