What to Consider When Developing a Video Game
To make a video game of your own, you'll need a fun idea for a game, which is a big hurdle...
For further actions, you may consider blocking this person and/or reporting abuse
C++ is not cross-platform very much. Different compilers frequently generate binaries that work differently. And, you have to recompile your code for different platforms, while Java has cross-platform binaries by default.
Also, manual memory control is always a negative trait of C++, not a positive one. Manual memory control fails everywhere, comparing with garbage collector.
Interesting! This space has been very opinionated online. I kept reading how memory management in C++ helps with speed and performance. I have a background in JavaScript and am beginning my learning in C++. I also plan to learn C# and Java. From what I've read about Java, the cross-platform capabilities sound so convenient. Are you familiar with Java? Do you use it regularly? If so, what do you like about it?
Java memory allocation in fact is faster than C or C++ ones. I made benchmarks recently, and I am going to write an article about that. I used Java for two years in my personal projects, but last 6 months I use Clojure (Lisp on JVM), making my game.
If you know how to benchmark properly, you can find yourself, that modern Java is faster than C and C++, or equal. JIT compiler has much more freedom and information, than traditional static compilers.
Though, good luck using C++ for making games. Having competitors struggling with C++ is a very good thing for everyone else
I see more studios struggling to adopt Rust than to code with C++.
Yes, Rust hysteria is a real thing.
When I say that C++ is bad, I don't say Rust is better.
One thing, C# is not specific to Windows... I've been coding games in C# with Unity since 2011, and I've not had a Windows computer in all that time!
This indeed is true. It is not hard to make C# projects that are built entirely on Linux, that even cross-compile to different linux targets, and build with forward compile (native) code. The nuget infrastructure works the same on Linux. And one can even produce stand-alone binaries that work well with docker, too, that target alpine musl libc, and are often no worse in size than say golang binaries.
Linux choices for cross-platform front-end ui's may be more limited, but most games are scene renders on a window anyway. C# has peculiarities, but both C++ and C# are peculiarity by design ;). I do not talk much about C# simply because nobody asks me to produce things with C#. One could talk about F#, too, as it is a great example of what a properly expressed general purpose functional language can look like.
I must have read some inaccurate information about C#. I'll update my post. Thank you for your insight!
I noticed that a lot of people make this a assumption.
C# started off as a Microsoft's attempt to replace Java on Windows, so the assumption has a bit of truth in it. But indeed, C# is a perfectly multi-platform language nowadays, has been for more than a decade.
It's also a VM-based language, just like Java. It has less focus on the "compile once, run everywhere" idea, though - understandable as that idea didn't quite work for Java either. But if you feel like it, you can even spin up a .NET VM inside a browser and write a web app in C#.
Yeah, Unity even compiles IL back into C++ for a bunch of platforms.
2024 and people still think C# and .NET are specific to Windows when .NET Core was released in 2016.
I agree the main idea, which C++ give a better control on computer resources and hardware.
But I find Javascript option analysis very (very) short!
The given libraries are totally out of date, whereas there are powerfull alternatives today for 3D games like Babylon.js (just by Microsoft) or Three.js!
On other hand, even if C++ has still granularity advantages, new versions of theses above libraries bring now native GPU api control through WebGL, so I think we have to consider them more a little bit.
While Babylon and Three.js are great, they are not the best for intense graphical games. One is better off using WASM for massive multiplayer and intense graphical games. When speed and memory is not a concern, Babylon and Three.js are great
I am considering JavaScript more since I have a background in that language. I am learning C++ and used this article as an opportunity to learn more about it. Due to time constraints, I had to cut my research short on JavaScript, Python, and Lua. Perhaps in a future article, I'll dive deeper into JavaScript's use in the gaming world.
I did a bunch in PlayCanvas; it was fun and performant enough for a whole slew of games. Choosing probably depends on whether you want to learn C++ or you want to make games. If the latter, I'd recommend PlayCanvas or Babylon.js - if the former then as others have said, choose your engine and the language is chosen for you.
I think the title is wrong. People do not choose C++ for game development; engine creators choose the programming language people should use with their engines.
Exactly. Games using Unreal will be largely written in C++, games in Unity will be in C#, Godot games will be in Go, and RPGMaker in JS. Most studios aren't going to be creating a game engine from scratch.
I need to change that title for sure. It was an early inspiration for writing this article, and my opinion changed while researching, but I forgot to revise the title. Thank you for giving it a read! I am new to the space, and I've been writing articles to learn more and give me a reason to research areas I wouldn't normally spend a lot of time in.
Lol what about .NET MAUI?
What particularly makes me laugh about all of the banter below is that so many of you go on about which language is faster, then declare a 4 byte integer to hold a simple flag. Instead of going on about which language is milliseconds faster, try writing tighter code, more efficient code. I see this happen all the time in (supposedly) high speed, timing critical business integrations.
This is the same argument as fat guys on bicycles trying to save an ounce or two of weight on their bicycle, when they could lose pounds of their own weight and save their money.
Maybe they don't want to admit that they invested so much effort learning one or two bad languages.
Seems to be easy – install both Java and C and do honest benchmarks.
No reply to my allegation your benchmark is fake? I mean it in good spirit. It's NOT an honest benchmark what you've posted because 1) calling Win32 VirtualAlloc under the hood is eventually necessary and 2) the JVM has already done this by tike you start measuring your Java benchmark performance, whereas your C++ version does not start able to access any already-OS- allocated memory.
Because c++ have the opp
Things I've found to be true with Java:
Yes, you can write once and have code run on Windows, iOS and Linux operating systems (and some others as well) but the user has have Java installed.
An alternative is to compile the Java code with a built-in, customized JVM. In this case, one needs a JVM for each OS, and it can be a bit of a task setting this up for each.
I found that there are some differences in the ratio between font sizes and pixels, for Windows vs iOS/Linux systems. For this, I've resorted to creating alternate sets of constants to be used with a given OS that pertain to the size of fields.
There are a couple Game Engines that primarily use Java: JMonkeyEngine and libjdx.
Personally, I dislike pointers. I find their use makes code more difficult to read and more prone to bugs. You may not have any problem with them.
For the most part, Java is very close C++ in terms of performance speed, and to me, easier to code with Java, and it is better adapted to multithreading and functional coding. But it's been a number of years since I checked out how these aspects are handled in C++. I assume there have been improvements.
I think it's a shame that the Java game engines didn't get the level of support similar to Unity or Unreal. IDK why, but it does seem that on a number of occasions Oracle decided to ignore requests by the Java gaming community to open up some aspects of the GPU and graphics in a way that would have allowed faster rendering. There are folks that have a better understanding of the history than I do.
Deceived OOP-cultist bro still hasn't realized that the Java version isn't actually newly allocating RAM from raw Win32 VirtualAlloc calls like the C++ version is, but that the bloated, slow, unnecessary Java virtual machine has already spent time to allocate these resources. I don't even need to look at the code to conclude this, because there's no way to actually get new heap memory besides making a syscall to OS functions, which is the same whether called from machine instructions compiled with C++ or machine instructions runtime on the fly submitted by the slow, gratuitous JVM. I studying this author's writings as he is following the extreme opposite programming philosophy spirit as me - watch Mike Acton 2014 presentation for a refutation of the OOP mindset religious deception.
If I receive a reply, I anticipate a gaslighting philosophical argument about definitions of memory allocation, rather than admitting that Java isn't faster than C++. I anticipate a false argument that, "JVM is already running by the time your program starts, so all allocation is as if new". No, because I could make a C++ program that reserves a huge int array on the heap from the OS up-front at initialization, and then calls a user-supplied compiled DLL function taking a pointer to "base into array scratch memory arena", and inside the function, do the same thing you did. What the C++ DLL would be doing is exactly what your Java version is doing - not actually calling OS to reserve more memory, but returning previously allocated pages - whereas your C++ test does not allocate from a language-created hidden reserve buffer implemented as an secret abstraction in the JVM, deceiving the programmer as in this case. I am so thankful to develop software in Pascal and C, where I know for each line pretty much exactly what actual assembly code will be actually executed. As Mike Acton brilliantly and pithily emphasizes, the hardware is the platform.
I think the point should maybe that Java is actually between 80-100% as fast at C++ at anything nontrivial, and that it takes rather a lot less time and effort. So where you could sit around writing all sorts of code to do these sorts of things to eke out a little bit more performance, we'd be busy just implementing game logic and shipping while you're still in the debugger losing hair over some mysterious segfault that "only seems to happen in debug"
Yes, that's the ridiculous standard argument against Data Oriented Design that all my experience has proven false, but this author (not of this post, Meyer, but the guy in the comments with fake benchmark) is going even farther by making false claims Java memory allocation is faster. Even what you wrote being true doesn't exculpate the dishonesty of this author. I write native Win32 D3D12 graphics application in raw Pascal with low level C style memory management and dont deal with the issues the OOP cultists like to project like segfaults. I SAVE developer time by not dealing with confusing high level garbage such as in Java.
See Battledroid for something written in Java as a comparison
How I could forget, that Minecraft had much better performance in every aspect, before Microsoft bought it and transfered to C++
This interesting
Good job!