Jump to content

  • Log In with Google      Sign In   
  • Create Account


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
52 replies to this topic

#1 nimrodson   Members   -  Reputation: 275

Like
0Likes
Like

Posted 09 January 2013 - 08:44 AM

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.



Sponsor:

#2 Milcho   Crossbones+   -  Reputation: 1175

Like
5Likes
Like

Posted 09 January 2013 - 09:03 AM

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.



#3 Servant of the Lord   Crossbones+   -  Reputation: 18579

Like
7Likes
Like

Posted 09 January 2013 - 09:04 AM

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).


Edited by Servant of the Lord, 09 January 2013 - 09:06 AM.

It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#4 samoth   Crossbones+   -  Reputation: 4685

Like
4Likes
Like

Posted 09 January 2013 - 09:06 AM

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.

Edited by samoth, 09 January 2013 - 09:07 AM.


#5 Servant of the Lord   Crossbones+   -  Reputation: 18579

Like
4Likes
Like

Posted 09 January 2013 - 09:22 AM

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).


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#6 RobTheBloke   Crossbones+   -  Reputation: 2336

Like
1Likes
Like

Posted 09 January 2013 - 09:27 AM

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.



#7 snugsound   Members   -  Reputation: 181

Like
3Likes
Like

Posted 09 January 2013 - 10:45 AM

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).


Edited by snugsound, 09 January 2013 - 10:53 AM.


#8 Dan Mayor   Crossbones+   -  Reputation: 1712

Like
5Likes
Like

Posted 09 January 2013 - 10:47 AM

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.


Digivance Game Studios Founder:

Dan Mayor - Dan@Digivance.com
 www.Digivance.com


#9 MarlboroKing   Members   -  Reputation: 192

Like
3Likes
Like

Posted 09 January 2013 - 10:57 AM

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!



#10 TheChubu   Crossbones+   -  Reputation: 4138

Like
3Likes
Like

Posted 09 January 2013 - 11:24 AM

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


#11 Karsten_   Members   -  Reputation: 1577

Like
2Likes
Like

Posted 09 January 2013 - 11:40 AM

There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;) </troll>

On a more useful note...

@nimrodson, can you tell us why you can't get to grips with C++? Perhaps you should use a higher level library (like you would generally be forced to when using C# or Java).

If you use something like Irrlicht (with C++) or Irrlicht.NET (with C#), they should both be very similar in difficulty.

(Though unfortunately like most .NET bindings (XNA included) the Irrlicht.NET is quite unmaintained.)

Edited by Karsten_, 09 January 2013 - 11:54 AM.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


#12 nimrodson   Members   -  Reputation: 275

Like
0Likes
Like

Posted 09 January 2013 - 12:23 PM

@nimrodson, can you tell us why you can't get to grips with C++? Perhaps you should use a higher level library (like you would generally be forced to when using C# or Java).

 

I just was wondering if there are another options to design powerful games without falling in C++. I don't want to be misunderstood: I like C++ (I'm still learning it), but it seems that programming on it is the only way to get fastest games. It's a question, not an affirmation.

 

By the way, I thank all the past and future feedback.



#13 Servant of the Lord   Crossbones+   -  Reputation: 18579

Like
2Likes
Like

Posted 09 January 2013 - 12:37 PM

As mentioned by others, any language that compiles down to assembly and isn't running in a virtual machine would do decently. C++ (and plain C) have been the industry standard for awhile because they are very cross-platform and have a few features and benefits that let you eek even more speed out of computers with minimal effort (but at the cost of making the language more complex and easier to make mistakes with).

 

The two things that make C++ in general slightly faster than other languages is (A) C++'s ideology of "Don't pay for what you don't use" (empowering developers) and (B) C++'s language specification letting compilers implement the language however they choose (letting them taking interesting shortcuts and optimizations) as long as the result comes out the same (empowering compilers).

 

If you're learning C++, I strongly suggest you research the new features offered by the newest standard of the language: C++11

C++11 makes C++ safer and easier to learn, while actually improving speed in some common situations.


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#14 simast   Members   -  Reputation: 119

Like
1Likes
Like

Posted 09 January 2013 - 12:55 PM

Personally I think C/C++ is beautiful. You haven't learned programming until you are at the hardware level C/C++ allows you to be at. Still, for a newcomer - learning C++ (or even just C) is a bit overkill. As all the others, I do suggest starting with something more abstracted (Java/Python/C#/you name it).



#15 shadowomf   Members   -  Reputation: 315

Like
0Likes
Like

Posted 09 January 2013 - 01:07 PM

You should use whatever you like, however it will also change what kind of jobs you can do or you can't.

 

For example you can always go down the web development road (browser, flash, html5, webgl games) and nobody will care if you can use C/C++.

For mobile games C/C++ might be important or not, it depends. If you develop for android I believe C/C++ is not really important most of the time. I don't know how other mobile OS's work with C/C++.

 

Anything desktop related, C/C++ might be a requirement.

For big studios, probably, maybe they have game play programmer positions that only require some scripting language. Tools and pipeline development will probably also possible without C/C++. If you want to go down the engine development road, chances are getting smaller.

Smaller studios might not rely on C/C++ at all, maybe you have more luck there.

 

Anyhow, it's possible to work in gamedev without C/C++.

 

Besides if you want to write a really fast game and don't want to use C/C++, you can always use Assembly. biggrin.png



#16 CryoGenesis   Members   -  Reputation: 495

Like
1Likes
Like

Posted 09 January 2013 - 01:47 PM

When I was asking this question I decided to email and 'industry veteran'. He said that when he employs people he is looking for C++ developers. As a Java coder wanting to be a game developer, this kind of gave me the urge to learn C++. In my opinion, I think C++ gives you a lot more access to your machine and code (if that makes sense) whilst Java is a lot easier to code. But, this could just be because I've been coding in Java for two or so years.

 

The only problem I ever have with C++ is trying to use external libraries. The Windows SDK sucks ass and requires a lot more code than writing windows apps in Java. I always get compiler errors from Visual C++ and it usually takes me an hour or two (3 days in the case of CUDA) to get the IDE to stop being a pain in the ass. In the case of Java, it's just referencing a single file then writing your code. In the case of C++, add a bunch of DLLs to here and here then add these include files to your compiler's include folder.... It's just a pain in the ass. I wonder if there's a way to write straight to the graphics card in C++ so I don't have to bother with any external libraries.

 

My advice would be that C++ is a good choice but if it's too hard at the start you should try an easier language and move onto C++ later.



#17 Ravyne   Crossbones+   -  Reputation: 7120

Like
0Likes
Like

Posted 09 January 2013 - 01:54 PM

There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;) </troll>

 

Except that shaders *are* compiled into intermediate code for distribution, or distributed as source. Its the graphics card driver that takes the IL or source code and produces GPU-specific hardware instructions.

 

IL gives you portability, and sometimes that's exactly what you need. The Just-In-Time compilation technology is getting better all the time, and it can do run-time optimizations that static compilers just can't. Likewise, static compilers can do other optimizations that JIT compilers just don't have the luxury of time to afford.

 

I actually prefer C++ for most things myself, because its what I know and am used to, but its not the case today that JIT-compiled languages are so much slower than native languages that the conclusion is foregone. Native languages mostly shine brightest when you have to get down really low and control/influence exactly how memory is organized and accessed, or to employ hardware features that a language like C# just doesn't expose at a low level (say, SIMD or intrinsic instructions). In other words, the really processing-intensive, big-data kind of things. For the 90% of your game code that just deals with mundane game logic, flow control, messaging queues, etc, native code doesn't offer any clear speed advantage, and a case can be made that a C# or Java-style language (or plain-jane C++ heavy on standard library usage) is easier to write and maintain. What I'm saying is that 90% or more of your game should be optimized for maintainability, rather than performance, so you can't use that as a metric for saying C++ is the best choice.



#18 wintertime   Members   -  Reputation: 1647

Like
0Likes
Like

Posted 09 January 2013 - 02:31 PM

I think when people advocate not using C++ its mostly cause in their mind they see examples of bad old C++ they had seen some time ago which were done the C way (sadly even books often do this). If you do it the modern C++ way there is probably not much difference in the difficulty level to other languages, but you still have the option of doing some other things if needed for optimization later.

Other than that you would just have to download some library _of_your_choice_ yourself and then for example #include "SFML.h", instead of hoping you get what you want when doing import java.awt.*; .



#19 demongunsman   Members   -  Reputation: 136

Like
1Likes
Like

Posted 09 January 2013 - 02:55 PM

To put things in simple terms I guess... It's not the language you choose, It's the language you are best at. For example, Assembly is more closer to the computer, but that does not necessarily mean it will be better. It's all about coding neatly and efficiently. I know a bit of java and a bit of C++. I find that I am much better at C++ and that I get much better results with my programs in C++ rather than Java. That is just me, that doesn't mean you should not learn java and pick up on C++ . You've got to explore a bit, see what suits you. And if your looking into getting games your going to have to know multiple languages anyway. So for your first language, choose the easiest for you so you can get your feet wet. Every language has its ups and downs.


Edited by demongunsman, 09 January 2013 - 02:56 PM.


#20 Karsten_   Members   -  Reputation: 1577

Like
1Likes
Like

Posted 09 January 2013 - 03:22 PM




There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;)

Except that shaders *are* compiled into intermediate code for distribution, or distributed as source. Its the graphics card driver that takes the IL or source code and produces GPU-specific hardware instructions.
I did specifically say runtime (after all, most software is distributed in text form on UNIX). Though in some of the later specs of OpenGL, apparently you can use compiled (native) code rather than compiling it up from source at runtime.

Basically, if the shaders were JIT compiled as they were being used rather than being compiled natively up front. It is highly likely you would get worse performance. This is exactly the same with .NET.
For example, Assembly is more closer to the computer, but that does not necessarily mean it will be better
Except that C compilers (especially optimizing ones) *do* produce better ASM than a human (if asked to with -S in gcc). Whereas C# simply runs ontop of another (large) layer of software so can only ever be slower. It doesn't bring anything to the table speed wise. The only thing it (ahem.. Java) brought to the table was a (flawed) non-deterministic memory management system.

You can create fast games with vm languages... Just not as fast as native code... obviously

Edited by Karsten_, 09 January 2013 - 03:53 PM.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS