Is it such possible to create fast games without using C/C++ ?

Started by
50 comments, last by shadowomf 11 years, 3 months ago

Hi,

I'm not dexterous in C/C++ programming and I'm starting to think that I never will be. So, how far can I go in the game industry bypassing these programming languages?

Thanks.

Advertisement

It's certainly possible to create fast games without c/c++ - they're not necessarily the fastest languages to use in all cases anyway.

There's been plenty of games written in Java, for example. You've also probably seen the wide variety of Flash games that run perfectly fine, which are written in Actionscript. Along with that you have C# and XNA to develop games in. There's also games made in Javascript which are quite good. And that's not even going into other languages like Python, Perl, Ruby and a lot of others too.

If you're worried that only c/c++ can deliver the performance for modern games - don't. There are a lot of other languages that you can make great performance games with.

If you're looking for a job in the game industry - a lot of the programming jobs do require some c/c++ knowledge (from what I've seen), but there are still plenty of job offers which require other language knowledge.

That's my two cents anyway.

Learn Python, make games, then learn another language, make games, then learn C++, and make games.

Stick with Python for at least two years.

Python is easier to learn and use. When learning any language, you are learning both the language and also computer programming in general. If learning C++'s complexities alongside computer programming is too much, try to learn computer programming with a simpler language like Python so when you later (4-5 years from now) return to C++ all you need to do is learn the language without trying to learn programming at the same time.

Warning: If you pick up Python, don't switch to another language for at about three years. It is important not to jump from language to language, or you risk putting yourself into a bad cycle where you only learn the surface-level knowledge of languages without learning the more important depths.

It is definitely possible to make fast games using other languages, but C++ is the industry standard (or so I hear - I'm not in the industry).

Huge games like EVE are written in Python. Many others are written in C# or Java (say, Minecraft, Runescape). Insofar, it is very possible not only to successfully write a game in "not C/C++" and to find a job in the industry.

However, I find the "I'm starting to think that I never will be" bit somewhat of a show-stopping attitude. It is most definitively not something you want to say in an interview.

But on the flip-side, huge games like EVE have their core written in C++ (for speed), with Python layered over it (for ease of coding and convenience).

Many games are actually written in two languages: C++ and a scripting language (often Lua or Javascript).

Hi,

I'm not dexterous in C/C++ programming and I'm starting to think that I never will be. So, how far can I go in the game industry bypassing these programming languages?

Thanks.


From the point of view of working in the industry: You'll probably need some C/C++ knowledge.

From the point of view of just making a game: Things such as GLSL/HLSL shaders can make a huge difference to the performance of your game, and there's no reason why a shader uploaded to the GPU from C++ will be any faster than one uploaded from javascript / C# / python. For any core language you are using, algorithmic optimisations have the largest effect on a games performance, followed closely by memory optimisations (e.g. compression etc). A game written is something like python which uses the right data structures and algorithms, should be able to perform closely to an equivalent game written in 'vanilla' C++. You may find that computation heavy code will run slower than the equivalent C++ code, although you may be able to make use of middleware to claw back that difference (e.g. using a good physics engine). The biggest win from C++ is still the ability to use SIMD optimisations. Mono.SIMD goes someway to providing an alternative (although not sure if it's really worth the effort). The only other common optimisation is to make use of multiple threads, which you should be able to use on most decent languages these days without a problem. In a nutshell, your computer has a lot of horsepower available, and so the language choice shouldn't pose a barrier to accessing that.

There are two separate questions here:

* does C/C++ perform better than X/Y/Z?
* is it important to learn C/C++ to get a job in the industry?

Anything that compiles to native code is going to run faster than something that doesn't. This is the reason engines are built in C++. But, as Servant of the Lord points out, most larger games use a high-level scripting language for actual game logic. There are many reasons for this: separation from engine/low-level code, reducing the amount of compiling that's required, allowing less technical users to script game logic, etc.

I think it's important to learn a C-like language, as it's the basis of many low AND high-level languages, but I would argue that knowing C/C++ inside and out is not a necessity unless you're working on console games, or working on game engines directly (building them, or extending them beyond their original design).

http://snugsound.com/

Speed and performance of your game in most cases depends more on properly writing your code than it does the particular language. C/C++ is a very open very powerful language but the sad truth is that around 80% or more of people that use it have bugs, errors, memory leaks, crashes and so on. Just because you use the most powerful top level coding language doesn't mean your end product will be faster.

For a bit more detail on this google the difference between C# and C++ on Windows. C# uses an intermediary byte code language or sorts where you precompile the program on the development machine and distribute. When that program / game is ran for the first time on the end users machine it will run the final compile process and try to optimize to the user's hardware. Many times this can make the C# program effectively run faster than a C++ program. Yes you see many bench marks that say C++ can add 2 numbers together .000001 seconds faster than C# but that really has minimal effect on the end result.

Take shaders for example, one of the most important visual pieces of a game. Shaders are hardware scripts of sorts, it's a where you script an action for the video cards shader model to perform on your graphics. This is an area where .NET, XNA and C# are actually starting to prove themselves faster than C++ and Direct X. The C# builds are optimizing to the exact video card on the players machine giving them access to some higher level shader API's that would not be available on a common portable build that C++ would make.

It's a modern age, most people have fairly modern multi core processors, powerhouse video cards and lots of ram. The gaming industry is opening to more and more languages and the effective or visual performance isn't really suffering the way's it used to. To put it a little simpler, even intermediary languages such as Java and C# don't slow down like they used to. Your players computer has the muscle to perform the couple extra ticks of logic these languages provide, the benefit is more so shifting now to the fact that languages like Java and C# are safer for lesser experienced coders. C# In particular has amazing garbage collectors, leak protection, a superb built in debugger, per hardware optimization on final compilation and much more.

All in all, yes it's perfectly possible to make a fast game in almost any language that has access to Direct X or Open GL. If you hit something that seems to be lagging crack open the books and figure out what you did wrong or what you might do to improve on what your doing. The languages themselves don't provide as many of the hurdles as poor coding practice does and some other languages (again, Java and C#) actually go the extra step to protect your program from your bad decisions. I don't mean to say you are a bad coder, even the best of us sometimes make silly mistakes. It's just better to have a language built on a framework that actually pulls it's weight both in the development and execution stages.

Dan Mayor

Professional Programmer & Hobbyist Game Developer

Seeking team for indie development opportunities, see my classifieds post

All that can be said is you can write an equivalant game in a different language, with the same speed.

That being said, it all comes down to how it was coded. You can write a fast game in C# or Java if coded correctly, and a bloated slow game in C++.

There are reasons why others like the language they chose. So in the end, it's what you're most comfortable with. Unless you are going for industry, learn what you can on everything!

I don't follow. Shaders are shaders. They're not touched by whatever VM you're using. They get passed from the API (DirectX/OpenGL) to the driver and from there to the GPU. The only difference is that if you use C++, chances are that the API functions jump through less hoops to get to the driver whereas in Java for example, you must use a wrapper and the VM's native interface. VMs don't optimize for video cards, drivers do.

Take shaders for example, one of the most important visual pieces of a game. Shaders are hardware scripts of sorts, it's a where you script an action for the video cards shader model to perform on your graphics. This is an area where .NET, XNA and C# are actually starting to prove themselves faster than C++ and Direct X. The C# builds are optimizing to the exact video card on the players machine giving them access to some higher level shader API's that would not be available on a common portable build that C++ would make.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

This topic is closed to new replies.

Advertisement