• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

Any good alternative to c/c++, c# and java for game development? A modern c++?

The problem with the likes of Java and C# is that you become dependent on 3rd party software to run your code. Want to support a new platform? You're completely dependent on someone porting the Java VM and a C# framework for it, while C++ allows you to begin coding for it on day one.

Is C# is really problematic since most of the tools you would use with it are still on Windows, though that may change with Microsoft putting a lot of their .Net stuff as open source. At least with Java you "Only" have to worry about the JVM being ported.
 
Javascript *IS* a valid alternative.
It is going to everywhere real soon, if not already is.

With V8's speed, with WebGl being supported by iOS devices too, and with frameworks such as Pixi, it have never been easier to create a game with javascript. Also, we can get down to ASM.js-levels of optimizations if the need arises. Or web workers, or using gpu shaders for computing. Speed is no longer an issue from JS's part.

It is not C++-like at all, but it is a valid way to game development. Not to mention that you will love it to hell and back when you come to the part of programming game logic. JavaScript's stucture offers good flexibility in that regard.
 
Javascript is putrid though. So putrid that people are writing compilers to compile pretty much anything else into Javascript.
 
I mostly develop software, so apoligies if I'm writing nonsense now.
But isn't the vast amount of game engines reliant on DirectX or, much less commonly, OpenGL - both of which won't necessarily run on all platforms, either?
Correct, but it's a considerable improvement when you have to retouch 25% of code that uses a different rendering API et cetera over having no support for the whole programming language.
 
Javascript is putrid though. So putrid that people are writing compilers to compile pretty much anything else into Javascript.

Javascript is not putrid. The people who cant* deal with Javascript's syntax and rules are free to use transpliers, but that does not prevent anyone from properly learning and understanding JS's structure.

When in mainstream web development, "knowing JS" means "knowing jQuery" and "dabbling in coffeescript", yeah, it might seem like JS is at fault here. But I do not think it is.

*Cant is not even the right word. "Not willing to" is more like it.
 
Uh, what? The only compiler for Rust is offline. Rust is a statically typed language, intended for writing things like operating systems and web browsers. I don't see how it's not fit for game engines.

+1 for Rust. It's an extremely type-safe language; concepts such as nullability and pointer ownership are encoded in the type system, so many issues that would appear in runtime with C++ are compile errors in Rust. It compiles to native code, and performance benchmarks are excellent. Given that it's a newer language, its biggest disadvantage is the limited ecosystem and mindshare. Still, absolutely worth checking out.
 
Ditto for Rust.

I also have a friend who is learning Swift for iOS development and he kind of described it as a more intuitive C++. So thats an option as well if you want to develop for Apple products.

As for me, I thought C++ was archaic until I had to deal with string literals in C :P
 
Javascript is not putrid. The people who cant* deal with Javascript's syntax and rules are free to use transpliers, but that does not prevent anyone from properly learning and understanding JS's structure.

When in mainstream web development, "knowing JS" means "knowing jQuery" and "dabbling in coffeescript", yeah, it might seem like JS is at fault here. But I do not think it is.

*Cant is not even the right word. "Not willing to" is more like it.

Agreed 100%. I have never met anyone that hates JavaScript who is actually good at writing it. Sure, it's a strange language. Scoping of "this" and prototypical inheritance are a definite concept hurdle. But once you're past that and know that you need to be careful with the type system (use === if in doubt!), it's a joy to write.
 
I like C because it's simple but I have never found a way to make it manageable. Is there some sort of pattern people use for namespacing and modules? I hate everything being global.
 
Just continue with c++/c#. If you want to be a game programmer you have to know them. Everyone that wants to program for games should work on their own renderer. You learn a ton about game development when you do this.

And someone that can write asset pipelines for engines will always find work. The big negative for Cryengine is the asset pipeline.
 
Agreed 100%. I have never met anyone that hates JavaScript who is actually good at writing it. Sure, it's a strange language. Scoping of "this" and prototypical inheritance are a definite concept hurdle. But once you're past that and know that you need to be careful with the type system (use === if in doubt!), it's a joy to write.
Honestly I could same the roughly same thing about C++... learn the type system and the notation, possibly with explanations why is it like that, and it's a beautiful language with so much expressive power.
 
OP, I think the best thing you could do is stick with C++ but restrict yourself to using it basically as C with a few extra features. C++ has a lot of cruft, it's true, and I always recommend people to stay as far away from templates and operator overloading as much as possible. But if you want to make games, C++ is the lingua franca of game development. Especially in the AAA space, it's your best option. Just stay away from the nasty stuff that only serves to make your code less readable.

C# is also a good language and if you want to use Unity, it's your only option (Unity has a Javascript analog but no one uses it).
 
Agreed 100%. I have never met anyone that hates JavaScript who is actually good at writing it. Sure, it's a strange language. Scoping of "this" and prototypical inheritance are a definite concept hurdle. But once you're past that and know that you need to be careful with the type system (use === if in doubt!), it's a joy to write.
I like to think this is a bit of a Stockholm syndrome situation. I *do* know JS and I know a lot of other developers that use it (client side, Node, etc) from these people some of them like it, and I can see some things to like about it, but everyone acknowledges it is an awful hodgepodge language. I mean this makes perfect sense if you look at its history as a language. People get used to or learn to live with some of the awful...
 
Javascript is not putrid. The people who cant* deal with Javascript's syntax and rules are free to use transpliers, but that does not prevent anyone from properly learning and understanding JS's structure.

When in mainstream web development, "knowing JS" means "knowing jQuery" and "dabbling in coffeescript", yeah, it might seem like JS is at fault here. But I do not think it is.

*Cant is not even the right word. "Not willing to" is more like it.

I'm just not a fan of weak typed languages, and it being an interpreted language makes it annoying to debug too.
 
Can't really give recommendations; I've struggled myself with learning lower-level engine programming. Things like Unity have too many weird obstructions for me.

Also I write so much JS for my day job; it's basically staring into the mouth of madness when it comes to language design. It was created in 10 days and shows that weakness all over the place.

Not saying not to use it for a web game, though; I've created my own JS-based games and they've been alright. But if you are trying for web deploy, I'd recommend a language that transpiles to JS, such as Dart.
 
My advice is do not learn a niche programming language

In reality, a lot of programming is finding and fixing bugs - which is especially difficult if you are relying on third party libraries (and most non trivial projects fit into this category)

There is huge value in being able to google/stackoverflow any problems that happen - and they will happen.
 
C++ is great when you use a tiny, tiny subset of it and ignore anything that adds ambiguity. This is a bit radical for some, but I personally completely avoid things like templates, operator overloading, and various shorthands that hurt code readability.

I would add "function pointers" to the no-no list and multiple inheritance to the "avoid unless necessary". I missed the latter a lot when I switched to Java at work, but the truth is that it has circumvented all ambiguity problems it might have caused.

As others have suggested OP, the modern C++ is C++11/14, and if you aren't familiar with things like decltype, auto, unique_ptr<>, shared_ptr<>, weak_ptr<>, std::move, std::forward, constexpr, std::thread, move operations (constructors), std::function / lambdas, and a lot of other great renovations, you're missing out on what I'd argue is the only real modern C++.

Seems like C++ 2011/14 would be the choice for me if I got into programming at home. I'm typically skeptical of new languages until they have been adopted widely for many years, and tools for managed object ownership would be some of the things I would miss jumping back.
 
I am a bit surprised that you would call C++ archaic. I like to experiment with many different languages and when I get to use C++ it is always very refreshing.

From what I've heard though, there are ways to do things in Python and even Perl. You could always make something like an HTML5 game using Javascript. Javascript is mostly classless so it can be a pain at times, but when I was messing around with it I had some fun.
 
To be honest, the programming language is kind of irrelevant. What matters is which libraries, APIs, frameworks etc. are available to you and in that regard I doubt anything is going to beat C# and C++ anytime soon. It's more likely you'll get some frameworks that still use C++ at the core but expose their functions to other languages like Unity does and many other games do with Lua.

Also, I love Java but it's not really good for game programming :X

From what I've heard though, there are ways to do things in Python and even Perl. You could always make something like an HTML5 game using Javascript. Javascript is mostly classless so it can be a pain at times, but when I was messing around with it I had some fun.
There are going to be classes and inheritance* and other more common features in the new standard which many browsers alreay support most features of. I must admit I kind of hate normal Javascript but all these new features made me very interested.

*I'm aware you can hamfist those into the weird prototyping system in JS, but I meant as a native language feature.
 
Uh, what? The only compiler for Rust is offline. Rust is a statically typed language, intended for writing things like operating systems and web browsers. I don't see how it's not fit for game engines.

I see. I think I'm confusing Rust with Dart (I think), which, last time I checked, basically translated your code to Javascript (although it might have come along a bit since then).
 
C++ is great when you use a tiny, tiny subset of it and ignore anything that adds ambiguity. This is a bit radical for some, but I personally completely avoid things like templates, operator overloading, and various shorthands that hurt code readability.

Use the stack for most things, but allocate on the heap for any kind of resource. Use automatic pointers. Use libraries for everything and only "roll our own" if you have to.

In the end, it ends up looking fairly close to C# in clarity.

Templates help code readability. They identify the type when called, and reduce spaghetti code. Templates are very useful and helpful.
 
Templates help code readability. They identify the type when called, and reduce spaghetti code. Templates are very useful and helpful.

Watch out, though. Templates can go seriously wrong:

v1TP1wN.png
 
I would add "function pointers" to the no-no list and multiple inheritance to the "avoid unless necessary". I missed the latter a lot when I switched to Java at work, but the truth is that it has circumvented all ambiguity problems it might have caused.

Agreed. I learned a lot from Java and C#. I'd say working with C# in particular improved my C++ a lot.

Templates help code readability. They identify the type when called, and reduce spaghetti code. Templates are very useful and helpful.

Lately I've been favoring composition over inheritance, so less polymorphism and less need for generics. But yeah, when I need generics I might still end up using templates, but I generally try to avoid them.

edit: I'm sleepy, the above reasoning might not make sense. I guess it's intuitive to avoid them for some reason in my particular coding style. I should think on why that is when I am not so groggy. :)


I'd say that well used operator overloading definitively improve readability, not hurt it.

Obviously when you use it correctly (I mean, overloading + for a vector class (or [] ) makes things easier to understand...) Of course, if you overload () to perform an obscure action on the class just to spare some characters in source, that's not wise at all.

I find it to be a huge hindrance when working with other people, just because it's implicit behavior. You might expect something intuitive to happen when doing an operation, but really there's no way to know how it'll behave, short of looking it up. But people have different coding styles, I guess. For me, it's all about parsimony.

In any case, a C++ style guide is a must for any kind of group work.
 
Operator overloading only makes sense (for me) for mathematical types and even then I think operator overloading should be carefully considered (see the ambiguity of the * operator for vector types, which is a good reason not to overload that operator for vectors at all).
I define it for scalar * vector, vector * scalar, and matrix * vector but not vector * vector.
 
OP, I think the best thing you could do is stick with C++ but restrict yourself to using it basically as C with a few extra features.

Do not do this. Never treat C++ as C with extras. They are different languages with different paradigms, and should be treated as such. Mixing them like that is a quick way to write code that both C programmers and C++ programmers will find cringe-worthy.
 
I define it for scalar * vector, vector * scalar, and matrix * vector but not vector * vector.

I assume you are sticking with one rendering API? Because what you are doing can cause big problems when going from Direct X to OpenGL, because vectors are stored differently between the APIs (column vs row).

I use preprocessor directives to make my life easier in cases like that.
 
Do not do this. Never treat C++ as C with extras. They are different languages with different paradigms, and should be treated as such. Mixing them like that is a quick way to write code that both C programmers and C++ programmers will find cringe-worthy.
Dunno, a lot of people find 'C with Classes' fairly agreeable. :P
 
D is in fact C++ without the legacy code, but that unfortunately means it's missing significant portions of the C++ standard library. As a language it's basically better than C++ in every way except for adoption, A result of the legacy-code jettison is obviously also that you're not going to see much in terms of backward-portable code; D code generally is D code, not code that can double as C++/C code.

Did they fix the garbage collector already? I heard a lot of people end up declaring everything as struct to circumvent its issues.
 
C++14 is pretty awesome actually, you just need to be selective with which features you opt in to use. I'm using it quite heavily now after a 10+ year hiatus and I'm surprised how far it has come with the 11/14 additions. Very clean and expressive without sacrificing the control over memory access patterns that is crucial to performant code with large datasets (like games).
 
Lately I've been favoring composition over inheritance, so less polymorphism and less need for generics. But yeah, when I need generics I might still end up using templates, but I generally try to avoid them.

Favoring composition is a good thing, as I've been realizing these past few years, especially because it facilitates useful patterns like the decorator and solves needs that you would otherwise attack with multiple inheritance (see above). At first it feels like a chore having to implement and maintain all those methods manually in the outer class again, but it actually kind of promotes keeping interfaces lean, so it's kind of win/win.

In any case, a C++ style guide is a must for any kind of group work.

The one thing I love most about Java is that it's so style-standarized and devoid of potentially harmful functionality that I rarely feel the urge to gouge my eyes out when reading coworker code, unlike with C++. It also seems that programmers brought up on Java seem to favor the same, more verbose variable and method names I do (nothing like debugging someones' code where every variable and method name is an acronym).
 
The one thing I love most about Java is that it's so style-standarized and devoid of potentially harmful functionality that I rarely feel the urge to gouge my eyes out when reading coworker code, unlike with C++. It also seems that programmers brought up on Java seem to favor the same, more verbose variable and method names I do (nothing like debugging someones' code where every variable and method name is an acronym).

You're mistaking Java's focus and limitations as a language for style-uniformity.
Everyone you work with coding in Java probably writes in a very similar way because the language itself does not allow too much variety in style. Whether that is a good or a bad thing is up for discussion and a matter of personal taste.

I have seen bad code in Java, in Python, in C#, in C++ and in C. The notion that "bad code only exists/does not exist in [enter language name here]" is a myth. Bugs such as memory leaks can still happen in Java, even when it lacks "harmful functionality".

Where I work we use verbose variable names, among other choices resulting from common sense. And none of us was "brought up with Java".
 
I assume you are sticking with one rendering API? Because what you are doing can cause big problems when going from Direct X to OpenGL, because vectors are stored differently between the APIs (column vs row).

I use preprocessor directives to make my life easier in cases like that.
Yes, though I call glUniformMatrix4fv with transpose=GL_TRUE anyways. The cost seems to be unnoticeable.

Though, I don't see how that's related to overloading operators. You'll have to deal with that regardless of whether you use overloads or normal functions.
 
As a non-coder, I think I'm gonna check out Rust just out of curiosity. Seems like a good idea to learn a language while it's new. I won't be doing anything professionally, so what the hell.
 
Templates help code readability. They identify the type when called, and reduce spaghetti code. Templates are very useful and helpful.


Right but I think I kind of get what he means. There are some things where the syntax really makes the code far more ugly and less intuitive. shared_ptr and unique_ptr are probably very good examples of this.


I like C++ though, but I can see where some legibility issues being a very real thing.

I think rust is a contender, but there's some stuff that really makes me dislike it. Specifically, I dislike the return syntax (specifically, I hate that the intended way to return from a function is to leave out a semi-colon in the last statement. I get what they were going for, but I think it leaves a lot of room for error.)

edit:
As a non-coder, I think I'm gonna check out Rust just out of curiosity. .

Honestly, if you're just delving into coding, Rust probably isn't a very good place to start. I think something along the lines of C# will give you what you want and simplify the process. Similarly, C++ is better documented so if you DO want control, go with that instead of rust.

Rust is a bit like the wild west right now. It's interesting, but it needs more time to develop.
 
Honestly, if you're just delving into coding, Rust probably isn't a very good place to start. I think something along the lines of C# will give you what you want and simplify the process. Similarly, C++ is better documented so if you DO want control, go with that instead of rust.

Rust is a bit like the wild west right now. It's interesting, but it needs more time to develop.

Fair enough, thanks for the advice. I taught myself some baby BASIC at 8, but I haven't tried anything since (fuck that was 30 years ago), outside of some very simple lisp for autocad. I ran across that codeacademy website at some point - not to derail, but do you have any opinion on it?

Edit: hrm that page has changed a lot since I first visited it. Maybe I'll check it out for python at some point.
 
C++ is an industry standard, perhaps looking into C++ AMP which is specifically designed for parallel computing which technology wise is the future. It's a push from AMD but supported by Microsoft, etc. and is part of their HSA initiative.
 
Rust is awesome and a real contender in this space. I love it and have been contributing to it for a while now. However, you might want to wait for a bit for the ecosystem to improve. In particular, one thing that hurts it in games specifically is that while linking to C is easy, it can't deal with C++ APIs well yet. This is something that will likely improve with time, but for now you're going to be restricted to libraries that provide a good C interface, and pure Rust stuff. You also are going to miss some features from C++--while Rust will never have full templates, right now it lacks really important stuff for game development like being able to parameterize a type over a value (think, e.g., a ring buffer that can specialize on length at compile time) or placement new (want this so bad).

Pretty much all of this stuff is planned, but for now I would only use Rust for a hobby game. And I say that as basically Rust's biggest fan. That said, I strongly encourage any C++ programmer to check it out--it's one of the few language actively catering to C++ programmers and it has real money behind it (unlike D or Nim, sadly). If you have an issue with it (particularly one where you can't get acceptable performance compared to C++), complain--the core team is listening. e.g., today someone noticed that they couldn't get the same bytecode out of a Rust implementation of a function as the C++ one, so someone investigated and submitted a patch to fix the codegen.
 
C++ progress moves very slowly but it has improved a lot in 11. Rust is looking very interesting indeed. I hope it gets more commercial support.
 
C++14 is the modern C++, and it's great. C++17 will be even better. There was pretty much a standstill in C++ in the 00s, but now progress is quick.
Also, don't listen to people that tell you t only use subsets of the language (or worse, those that tell you not to use boost). Unless something is truly dangerous or outdated of course, like auto_ptr.

Finally, it never hurts to learn more languages, but only once you're familiar with the language-independent principles of programming in general.

Edit: Oh and Rust is neat.
 
Fair enough, thanks for the advice. I taught myself some baby BASIC at 8, but I haven't tried anything since (fuck that was 30 years ago), outside of some very simple lisp for autocad. I ran across that codeacademy website at some point - not to derail, but do you have any opinion on it?

Edit: hrm that page has changed a lot since I first visited it. Maybe I'll check it out for python at some point.

I haven't used codeacademy myself but I've heard a lot of people talk very highly of it.

When I began coding I spent most of my time reading the C++ Language Tutorial and also hit up the Java language tutorial when I wanted a more high level understanding of basic concepts. Stack overflow is good for questions, I still use it pretty religiously (albeit that may be because I still have to improve a lot of my own coding fundamentals.)

Python may be a really good place to start too. I have experience with it and enjoy it quite a bit.
 
C++14 is the modern C++, and it's great. C++17 will be even better. There was pretty much a standstill in C++ in the 00s, but now progress is quick.
Also, don't listen to people that tell you t only use subsets of the language (or worse, those that tell you not to use boost). Unless something is truly dangerous or outdated of course, like auto_ptr.
C++ is a rather terrible minefield for people inexperienced with programming, but if it's taught to them, initially sticking to a subset makes it a lot better pedagogically. In particular: no pointers or manual memory allocation, not even smart pointers, no preprocessor macros, no using the "C" portions of the C++ standard library. Beginner code doesn't need any of these, and one can write a lot of interesting code without them - eg. when I was running a hardcore computer graphics course where many of the students hadn't done C++ before, it was no problem sticking to that subset in 99% of the code the students had to read or write. I'd also say sticking to that subset initially is very good for people who already know C who are getting into C++, because the temptation to stick to the old bad ways is strong.
 
I hated pointers.

But you really miss them when they aren't available.
It takes some getting use to. Also most languages that don't have explicit pointers still use them extensively. Hence people need to at least understand them, especially with Java where the Language decides what is a pointer and what is not.
 
I hated pointers.

But you really miss them when they aren't available.

I was introduced to programming through C++ so pointers have never been an issue for me although the real aha moment was when I was learning an assembly language where integers and pointers were the same thing. That significantly eased future understanding.
 
I hated pointers.

But you really miss them when they aren't available.
Dat feel when you understand pointers finally and have unlimited power. Man, it just became so much easier to do everything(especially when i learned you can have functions return a pointer).
 
Top Bottom