I agree, Java is perfectly fine. Oh hey, what language is Minecraft written in?
Okay, completely ignore my earlier post. I explicitly stated that you should not program a game in Java because Minecraft did it. I absolutely hate it when people immediately bring Minecraft into any sort of language discussion.
Name one reason why programming this game in Java would benefit the game in any way.
Could you explain why it isn't?
It's pretty much holding you back. I'm assuming that this game is going to run on a desktop, and that pretty much takes away several pros Java has right there. Java is a good language, don't get me wrong, but this is just not where it should be used.
Since there was little information given to us by the OP, I'm assuming quite a few things here.
The Meaning of Life, the Universe, and Everything.
Location:
A place...
Join Date:
1/6/2014
Posts:
61
Location:
Error: Location not found.
Minecraft:
EndGameMC_
Xbox:
REKT Orbit
Member Details
The game would be downloaded and played on the desktop of the PC. Its not a browser game. I said I know lines of code w/ Java and that was before I posted this thread. I do understand that C++ is much more common and many people use it.
I'm trying to tell you that Java isn't made for this type of stuff. You're only hurting yourself.
C++ isn't made for games, either. Actually, pretty much all general purpose programming languages aren't made for games.
I will say that if your goal is to actually accomplish something, then Java or C# would be a better choice than C++. The less time you have to spend messing around with low-level stuff, the better.
Personally, I prefer C#, just because I find it to be a more expressive language (I also think the whole type erasure thing for Java generics is kind of stupid; but that's going to be mostly a non-issue in this case).
Rollback Post to RevisionRollBack
Never attribute to malice what can adequately be explained by incompetence.
I'm trying to tell you that Java isn't made for this type of stuff. You're only hurting yourself.
As Yourself said(heh, get it?), developing a game would be faster in Java. It would also be more fun, in my opinion. You can also spend all that extra time you get optimizing your game. You might be so behind on developing features in C++ that your game is less efficient that something made in Java.
In the end, it all comes down to opinion. There's no right or wrong in this case.
The Meaning of Life, the Universe, and Everything.
Location:
A place...
Join Date:
1/6/2014
Posts:
61
Location:
Error: Location not found.
Minecraft:
EndGameMC_
Xbox:
REKT Orbit
Member Details
I really need a final decision on what language to learn. Out of Java, C++, and C#, which is the best for programming the game? Just tell me if you need more details about the game, too.
I really need a final decision on what language to learn. Out of Java, C++, and C#, which is the best for programming the game? Just tell me if you need more details about the game, too.
I'd say Java. Although, Java and C# are nearly the same thing look-wise. The nice thing about Java is cross-compatibility.
I will say that if your goal is to actually accomplish something, then Java or C# would be a better choice than C++. The less time you have to spend messing around with low-level stuff, the better.
There are libraries and game engines. You wont have to touch low-level things.
The nice thing about Java is cross-compatibility.
Well C++ can run on more places than Java, and I'd say C# is pretty cross-platform too.
C++ isn't made for games, either. Actually, pretty much all general purpose programming languages aren't made for games.
That's not what I was getting at.
As Yourself said(heh, get it?), developing a game would be faster in Java.
If you want to develop a game faster, then use C#. I'm telling you that Java isn't the right tool here.
It would also be more fun, in my opinion. You can also spend all that extra time you get optimizing your game.
Except there's only so much you can do on a virtual machine.
You might be so behind on developing features in C++ that your game is less efficient that something made in Java.
That makes no sense whatsoever.
I really need a final decision on what language to learn. Out of Java, C++, and C#, which is the best for programming the game? Just tell me if you need more details about the game, too.
I'd say C++. But we still know close to nothing about what you want your game to be.
Let me ask this: What do you do in C++ for game development that can't be done in Java?
Every language can create a game. Whether the game will run at a desired rate is another matter entirely.
But,
Things Java can't do that C++ can:
Pointers
Memory Management
inline assembly (Not used by me, but some do)
More platforms
Easy access to binary data
Operator overloading
Let me ask this: What do you do in C++ for game development that can't be done in Java?
In high-quality game development, C++ can squeeze out extra optimization where memory-managed languages like Java and C# can't.
For indie developers, the only reason you might want C++ over Java is if you didn't want to rely on the users installing (the correct version of) Java and instead wanted a native program that doesn't require additional software.
For beginners, I'd probably recommend C#, though.
Not only is it quicker to build programs from scratch, and is more 'user-friendly', but it also has the XNA framework which is simply beneficial for new game developers. It is much easier to use XNA in C# than it is to use SDL or SFML in C++.
An indie developer could develop a game in a much more reasonable amount of time using tools you can find in C#, than you could using C++. (Unless you already know C++ very well, but don't know any C#, when the time to create something would be subjective and be biased towards previous knowledge.)
And squeezing out optimization is not really an issue for indies.
There is nothing they could ever do to maximize CPU or GPU resources without programming badly. C++ would not help you there, if anything it would just give you errors instead.
C++ is still a good language, though. It's good for a programmer to understand memory management even if they always use a memory-managed language. It's just not 'beginner friendly' as they say, for this reason.
Understanding memory management helps you get a grasp on pointers, references, and such... Which are things still used in other languages like C#, even if you aren't using them directly anymore. They are still 'there'... The compiler is just doing a lot of it for you.
In high-quality game development, C++ can squeeze out extra optimization where memory-managed languages like Java and C# can't.
For indie developers, the only reason you might want C++ over Java is if you didn't want to rely on the users installing (the correct version of) Java and instead wanted a native program that doesn't require additional software.
That's mostly who I was targeting. My statement was too broad. I really meant only in relation to small time developers/amateurs/beginners. My bad.
There are libraries and game engines. You wont have to touch low-level things.
Well C++ can run on more places than Java, and I'd say C# is pretty cross-platform too.
That's not what I was getting at.
C++ is not a good place to start because it's a terribly bloated language that has a lot of confusing features. At similar skill levels between both languages, it is almost always faster to develop something of equivalent functionality in Java than it is in C++.
I think perhaps one of those cumbersome things I encounter in C++ is just how files usually end up organized. At work one of the more annoying things I have to do in C++ is add a member variable because it requires modifying two separate files: the header and the source. If you want to avoid that you end up inlining everything into header files and if the project ends up being any reasonable size, you'll start getting irritated by build times, because just about any change results in a full rebuild.
Even build times on the order of 10s of seconds get frustrating when you're trying to debug problems where you're constantly making changes and then rebuilding and running the code again to see if the problem's been fixed.
Speaking of debugging, the support for C++ debugging is not terrific. I'm not sure how it works in Java, but debugging things line-by-line in C# is an absolute breeze compared to C++. If I want to debug something in C++, I have to do a debug build, which usually means a full rebuild that ends up taking significantly more time than a release build. The resulting code will then have horrendous performance which can be extremely frustrating if you're waiting for it to load resources in completely un-optimized code.
Which, by the way, is what gives C++ its performance: compiler optimizations. This is something that C# and Java don't really have to a significant degree. Those languages leave optimizations to the JIT, which can perform some optimizations that a compiler can't, because the JIT has access to runtime behavior where a compiler can only reason statically.
If you want to develop a game faster, then use C#. I'm telling you that Java isn't the right tool here.
Except there's only so much you can do on a virtual machine.
That makes no sense whatsoever.
I'd say C++. But we still know close to nothing about what you want your game to be.
C# would be my next choice.
For beginners there's not going to be a significant difference in effort between Java or C#. Most of the additional features that C# provides are something that a beginner probably wouldn't need to deal with to a significant degree anyway (and anyone asking what language to use is a beginner).
There is plenty of stuff you can do to optimize even in a virtual machine environment (which is mostly a non-issue). If you want good performance, pick good algorithms, don't fret over what language you're going to use. And don't under any circumstances break the two rules of optimization:
1. Don't do it.
2. Don't do it yet.
Optimization comes last and only when and where it's needed. Premature optimization is the tool of the devil.
Every language can create a game. Whether the game will run at a desired rate is another matter entirely.
But,
Things Java can't do that C++ can:
Pointers
Memory Management
inline assembly (Not used by me, but some do)
More platforms
Easy access to binary data
Operator overloading
Inline assembly is not a feature of C++, it's a compiler extension and it ends up being different depending on which compiler you're using.
Technically C# has something similar since it provides you with the ability to emit IL at runtime (basically letting you write compiled at runtime). Similar things exist for Java.
I also don't know what you mean by "easy access to binary data". Reading and writing binary data is pretty similar between all languages since they typically abstract it away as streams. I guess about the only difference is that C++ can reinterpret_cast a pointer to an arbitrary object and then screw with the bytes. I wouldn't really advertise that as a feature because it's really just an example of a lack of type safety in C++.
Also C++ doesn't technically feature any actual memory management features (perhaps with the exception of smart pointers nowadays). The programmer handles all memory management in C++. Java and C# handle memory management for you since garbage collection is kind of a core feature of both languages.
Rollback Post to RevisionRollBack
Never attribute to malice what can adequately be explained by incompetence.
The focus on what language is good for writing games is about as useful as focusing on what kind of hammer is good for murdering pedophiles. Fact is that 99.9% of real-world hammer usage is not used for murdering pedophiles and therefore focussing on desirable hammer traits for that purpose will not give you a hammer that does any good for other tasks that use a hammer.
I think perhaps one of those cumbersome things I encounter in C++ is just how files usually end up organized. At work one of the more annoying things I have to do in C++ is add a member variable because it requires modifying two separate files: the header and the source. If you want to avoid that you end up inlining everything into header files and if the project ends up being any reasonable size, you'll start getting irritated by build times, because just about any change results in a full rebuild.
If you hate it so much, why not define complete classes in one file?
Even build times on the order of 10s of seconds get frustrating when you're trying to debug problems where you're constantly making changes and then rebuilding and running the code again to see if the problem's been fixed.
How is your file structure in your work project organized?
Speaking of debugging, the support for C++ debugging is not terrific. I'm not sure how it works in Java, but debugging things line-by-line in C# is an absolute breeze compared to C++. If I want to debug something in C++, I have to do a debug build, which usually means a full rebuild that ends up taking significantly more time than a release build. The resulting code will then have horrendous performance which can be extremely frustrating if you're waiting for it to load resources in completely un-optimized code.
Can be fixed by always compiling as a debug build, then building it as release when you need to release the product.
Which, by the way, is what gives C++ its performance: compiler optimizations. This is something that C# and Java don't really have to a significant degree. Those languages leave optimizations to the JIT, which can perform some optimizations that a compiler can't, because the JIT has access to runtime behavior where a compiler can only reason statically.
Fair enough.
Inline assembly is not a feature of C++, it's a compiler extension and it ends up being different depending on which compiler you're using.
Well, considering the 2 main C++ compilers support it...
If you were developing on other architectures, I can see that as a problem.
Even then, compilers usually let you link assembly source to your project.
If you hate it so much, why not define complete classes in one file?
He already has issues with build times. separating the declarations into a separate header file improves build times because the header file is what can get compiled against- it is the linker that will do the job of actually matching it up to the actual implementation.
In this vein the point is that even though you technically have a choice, separating them into a .cpp and a .h is going to work out better almost every time. Not to mention that it makes it possible to link against already compiled .obj files which drastically improves build times, because the .cpp files that are already compiled can simply be linked against rather than recompiling the source files to object files.
How is your file structure in your work project organized?
That's not related to his problem. We can safely assume that he is (smartly) using the separate .cpp and .h files since he has pointed out how dumb it is that it is required for any sort of usability in the compiler. the C++ compiler is slow because C++ is one of the most difficult languages to parse. For example:
a b(c);
Variable definition or function declaration? if "c" is a variable, than it defines a variable named b of type a, that is directly initialized with c. However if c is a type, than it declares a function named b that takes a c and returns an a.
Can be fixed by always compiling as a debug build, then building it as release when you need to release the product.
This doesn't fix any of the problems mentioned. Debug builds are slow even if they are incremental with existing debug built .obj files. And performance is still going to be slow. When it comes to C++ you shouldn't be using a debug build unless you are specifically debugging anyway.
Well, considering the 2 main C++ compilers support it...
Microsoft's compiler uses an _asm{} block. gcc uses asm("assembly code");
Also, within the in-lined assembly itself, Microsoft's compiler uses Intel syntax, whereas gcc uses AT&T syntax. which means that assembly you write inline in one compiler isn't going to work in the other even if you ifdef to change the block declaration. And that is so far ignoring gcc's "extended ASM" features.
If you were developing on other architectures, I can see that as a problem.
Even with the two compilers you mentioned it's already a nightmare. "movl _x, %eax" in the gcc asm inliner has to be changed to "mov eax, [_x]" for VC.
Even ignoring that, it becomes a problem because modern systems support two architectures- x64 and x86. C# and Java- unless coded poorly- can be switched to use x64, x86, or the highest available with a compiler switch- it technically just controls the actual compiler output of the jitter.
With C++ you have to recompile everything to switch.
guess what this does for the ASM? Well, thankfully, it's mostly backwards compatible...
however, usually ASM is used for squeezing the best performance via hand-tuned instructions via cycle counting. Fact is that changing the architecture- even simply moving to a new CPU (eg 486->Pentium caused many Assembly optimizations to destroy performance rather than improve it because they caused the dual-pipelined Pentium CPU to discard entire prefetch queues for certain branch operations)
And again- it's non-standard. Arguing that it's De Facto and therefore OK seems to completely ignore the prior art and evidence about how bad that is- which is a lesson already learned by both C and C++.
Java
At least 86% of what I say is always correct.
Name one reason why programming this game in Java would benefit the game in any way.
It's pretty much holding you back. I'm assuming that this game is going to run on a desktop, and that pretty much takes away several pros Java has right there. Java is a good language, don't get me wrong, but this is just not where it should be used.
Since there was little information given to us by the OP, I'm assuming quite a few things here.
I don't think that was meant to be answered.
Less time dinking around with low level crap and boilerplate and more time dinking around with actual game design and development.
C++ isn't made for games, either. Actually, pretty much all general purpose programming languages aren't made for games.
I will say that if your goal is to actually accomplish something, then Java or C# would be a better choice than C++. The less time you have to spend messing around with low-level stuff, the better.
Personally, I prefer C#, just because I find it to be a more expressive language (I also think the whole type erasure thing for Java generics is kind of stupid; but that's going to be mostly a non-issue in this case).
As Yourself said(heh, get it?), developing a game would be faster in Java. It would also be more fun, in my opinion. You can also spend all that extra time you get optimizing your game. You might be so behind on developing features in C++ that your game is less efficient that something made in Java.
In the end, it all comes down to opinion. There's no right or wrong in this case.
Proud member of spigotmc.org.
Go with C#.
"Programmers never repeat themselves. They loop."
I'd say Java. Although, Java and C# are nearly the same thing look-wise. The nice thing about Java is cross-compatibility.
Proud member of spigotmc.org.
C# has Mono for cross platform.
"Programmers never repeat themselves. They loop."
There are libraries and game engines. You wont have to touch low-level things.
Well C++ can run on more places than Java, and I'd say C# is pretty cross-platform too.
That's not what I was getting at.
If you want to develop a game faster, then use C#. I'm telling you that Java isn't the right tool here.
Except there's only so much you can do on a virtual machine.
That makes no sense whatsoever.
I'd say C++. But we still know close to nothing about what you want your game to be.
C# would be my next choice.
Let me ask this: What do you do in C++ for game development that can't be done in Java?
Thinking about coming a mod to simply not moderate.
Every language can create a game. Whether the game will run at a desired rate is another matter entirely.
But,
Things Java can't do that C++ can:
Pointers
Memory Management
inline assembly (Not used by me, but some do)
More platforms
Easy access to binary data
Operator overloading
In high-quality game development, C++ can squeeze out extra optimization where memory-managed languages like Java and C# can't.
For indie developers, the only reason you might want C++ over Java is if you didn't want to rely on the users installing (the correct version of) Java and instead wanted a native program that doesn't require additional software.
For beginners, I'd probably recommend C#, though.
Not only is it quicker to build programs from scratch, and is more 'user-friendly', but it also has the XNA framework which is simply beneficial for new game developers. It is much easier to use XNA in C# than it is to use SDL or SFML in C++.
An indie developer could develop a game in a much more reasonable amount of time using tools you can find in C#, than you could using C++. (Unless you already know C++ very well, but don't know any C#, when the time to create something would be subjective and be biased towards previous knowledge.)
And squeezing out optimization is not really an issue for indies.
There is nothing they could ever do to maximize CPU or GPU resources without programming badly. C++ would not help you there, if anything it would just give you errors instead.
C++ is still a good language, though. It's good for a programmer to understand memory management even if they always use a memory-managed language. It's just not 'beginner friendly' as they say, for this reason.
Understanding memory management helps you get a grasp on pointers, references, and such... Which are things still used in other languages like C#, even if you aren't using them directly anymore. They are still 'there'... The compiler is just doing a lot of it for you.
That's mostly who I was targeting. My statement was too broad. I really meant only in relation to small time developers/amateurs/beginners. My bad.
Thinking about coming a mod to simply not moderate.
C++ is not a good place to start because it's a terribly bloated language that has a lot of confusing features. At similar skill levels between both languages, it is almost always faster to develop something of equivalent functionality in Java than it is in C++.
I think perhaps one of those cumbersome things I encounter in C++ is just how files usually end up organized. At work one of the more annoying things I have to do in C++ is add a member variable because it requires modifying two separate files: the header and the source. If you want to avoid that you end up inlining everything into header files and if the project ends up being any reasonable size, you'll start getting irritated by build times, because just about any change results in a full rebuild.
Even build times on the order of 10s of seconds get frustrating when you're trying to debug problems where you're constantly making changes and then rebuilding and running the code again to see if the problem's been fixed.
Speaking of debugging, the support for C++ debugging is not terrific. I'm not sure how it works in Java, but debugging things line-by-line in C# is an absolute breeze compared to C++. If I want to debug something in C++, I have to do a debug build, which usually means a full rebuild that ends up taking significantly more time than a release build. The resulting code will then have horrendous performance which can be extremely frustrating if you're waiting for it to load resources in completely un-optimized code.
Which, by the way, is what gives C++ its performance: compiler optimizations. This is something that C# and Java don't really have to a significant degree. Those languages leave optimizations to the JIT, which can perform some optimizations that a compiler can't, because the JIT has access to runtime behavior where a compiler can only reason statically.
For beginners there's not going to be a significant difference in effort between Java or C#. Most of the additional features that C# provides are something that a beginner probably wouldn't need to deal with to a significant degree anyway (and anyone asking what language to use is a beginner).
There is plenty of stuff you can do to optimize even in a virtual machine environment (which is mostly a non-issue). If you want good performance, pick good algorithms, don't fret over what language you're going to use. And don't under any circumstances break the two rules of optimization:
1. Don't do it.
2. Don't do it yet.
Optimization comes last and only when and where it's needed. Premature optimization is the tool of the devil.
Inline assembly is not a feature of C++, it's a compiler extension and it ends up being different depending on which compiler you're using.
Technically C# has something similar since it provides you with the ability to emit IL at runtime (basically letting you write compiled at runtime). Similar things exist for Java.
I also don't know what you mean by "easy access to binary data". Reading and writing binary data is pretty similar between all languages since they typically abstract it away as streams. I guess about the only difference is that C++ can reinterpret_cast a pointer to an arbitrary object and then screw with the bytes. I wouldn't really advertise that as a feature because it's really just an example of a lack of type safety in C++.
Also C++ doesn't technically feature any actual memory management features (perhaps with the exception of smart pointers nowadays). The programmer handles all memory management in C++. Java and C# handle memory management for you since garbage collection is kind of a core feature of both languages.
How is your file structure in your work project organized?
Can be fixed by always compiling as a debug build, then building it as release when you need to release the product.
Fair enough.
Well, considering the 2 main C++ compilers support it...
If you were developing on other architectures, I can see that as a problem.
Even then, compilers usually let you link assembly source to your project.
He already has issues with build times. separating the declarations into a separate header file improves build times because the header file is what can get compiled against- it is the linker that will do the job of actually matching it up to the actual implementation.
In this vein the point is that even though you technically have a choice, separating them into a .cpp and a .h is going to work out better almost every time. Not to mention that it makes it possible to link against already compiled .obj files which drastically improves build times, because the .cpp files that are already compiled can simply be linked against rather than recompiling the source files to object files.
That's not related to his problem. We can safely assume that he is (smartly) using the separate .cpp and .h files since he has pointed out how dumb it is that it is required for any sort of usability in the compiler. the C++ compiler is slow because C++ is one of the most difficult languages to parse. For example:
Variable definition or function declaration? if "c" is a variable, than it defines a variable named b of type a, that is directly initialized with c. However if c is a type, than it declares a function named b that takes a c and returns an a.
This doesn't fix any of the problems mentioned. Debug builds are slow even if they are incremental with existing debug built .obj files. And performance is still going to be slow. When it comes to C++ you shouldn't be using a debug build unless you are specifically debugging anyway.
Microsoft's compiler uses an _asm{} block. gcc uses asm("assembly code");
Also, within the in-lined assembly itself, Microsoft's compiler uses Intel syntax, whereas gcc uses AT&T syntax. which means that assembly you write inline in one compiler isn't going to work in the other even if you ifdef to change the block declaration. And that is so far ignoring gcc's "extended ASM" features.
Even with the two compilers you mentioned it's already a nightmare. "movl _x, %eax" in the gcc asm inliner has to be changed to "mov eax, [_x]" for VC.
Even ignoring that, it becomes a problem because modern systems support two architectures- x64 and x86. C# and Java- unless coded poorly- can be switched to use x64, x86, or the highest available with a compiler switch- it technically just controls the actual compiler output of the jitter.
With C++ you have to recompile everything to switch.
guess what this does for the ASM? Well, thankfully, it's mostly backwards compatible...
however, usually ASM is used for squeezing the best performance via hand-tuned instructions via cycle counting. Fact is that changing the architecture- even simply moving to a new CPU (eg 486->Pentium caused many Assembly optimizations to destroy performance rather than improve it because they caused the dual-pipelined Pentium CPU to discard entire prefetch queues for certain branch operations)
And again- it's non-standard. Arguing that it's De Facto and therefore OK seems to completely ignore the prior art and evidence about how bad that is- which is a lesson already learned by both C and C++.