What languages do game programmers use?

Shoseki · 7 Sep 2007 at 23:34

The thing is, that performance will always be a consideration... the latest embedded hardware will require more and more c++ for drivers, and it is natural that as the cutting edge, games will want to use c++ to push the envelope.

Only once we breach the "technology is so strong, nothing can beat it" level will we see c# type languages becoming mainstream. And even then, the c++ boys will be able to do a lot more than the c# boys, not to mention that c++ is an international standard, whereas c# is just one more interpreted language such as java, but without the international community to support it.

There are literally millions of c++ developers.

Psyk · 8 Sep 2007 at 14:09

I suppose the problem with C# is it's lack of portability. It's all well and good if you make an Xbox 360 game with C# and XNA, but what happens when you want to port it to PS3? You would have to make the game completely from scratch.

Una · 8 Sep 2007 at 14:48

Psyk said:
I suppose the problem with C# is it's lack of portability. It's all well and good if you make an Xbox 360 game with C# and XNA, but what happens when you want to port it to PS3? You would have to make the game completely from scratch.

Actually C# could be more portable than C/C++. If there was a VM written for the PS3 it would be much easier to port your programs across. If your writing it in C/C++ you need tons of preprocessor directives to deal with the differences in architecture (PPC/x86 etc..)

~J~ · 8 Sep 2007 at 16:59

Una said:
Actually C# could be more portable than C/C++. If there was a VM written for the PS3 it would be much easier to port your programs across. If your writing it in C/C++ you need tons of preprocessor directives to deal with the differences in architecture (PPC/x86 etc..)

You've kinda negated (and answered the main question).

Any language, portable or not, could be ported if a VM was written for it. But the processor would be running the VM which in turn is running code so that's TWICE as much processing power needed for something that could be done in one native language.

It's like me trying to have a conversation with someone in German. I can't speak German, I can speak French. I have a friend who can speak French and German, so I translate English to French, and he translates from French to German and back again!

The directives you talk about, whilst kinda true, doesn't really make much of an issue these days because the hardware vendors supply .h files for nearly every access to the entire machine. Hence why developing a game for an ATI graphics card is exactly the same code as that for an Nvidia card because all your do is executing the same code but using a different header file.

Una · 8 Sep 2007 at 17:44

~J~ said:
You've kinda negated (and answered the main question).

Any language, portable or not, could be ported if a VM was written for it. But the processor would be running the VM which in turn is running code so that's TWICE as much processing power needed for something that could be done in one native language.

As Lagz has said earlier the overhead of using a managed language compared to a non managed language is getting smaller and smaller as time goes on. There is a trade off between developer cycles and cpu cycles and for something like the games industry where the publishers have a lot of the influence on the deadlines being able to develop quicker is always handy.

I don't see C/C++ dieing out in the next 10+ years in games dev but I think there will be more adapation on managed languages in future.

Smit · 9 Sep 2007 at 13:01

I think most still use C/C++ at the moment. I have seen a game or two being done in Java, can't remember which game it was though. I recall that it was an FPS game on the PC but can't remember anything other than that.

Lagz · 9 Sep 2007 at 18:23

~J~ said:
Any language, portable or not, could be ported if a VM was written for it. But the processor would be running the VM which in turn is running code so that's TWICE as much processing power needed for something that could be done in one native language.

How did you decide that running C# code on a VM is twice as slow as running native C++ code? Its more like 5% at most.

Basically modern VMs compile intermediate code on the fly into native code - and then execute the native code directly on the hardware. The only overhead involved is the on-the-fly compilation (the first time each bit of program runs it needs to be compiled into native code) and the running of the garbage collector (and I'm guessing that most games engines implement their own garbage collector in C/C++ anyway - albeit more specialised and controlled than the general C# one).

Infact running code on a VM can actually be faster than executing native code. This is because VMs can use runtime information to perform additional optimisations when they do their on-the-fly compilation, which is not possible when statically compiling C/C++ code. Modern VMs are able to look at runtime properties of a program, and where additional optimisations can be made they dynamically re-compile bits of code in order to make additional optimisations.

Psyk · 9 Sep 2007 at 22:35

Lagz said:
Infact running code on a VM can actually be faster than executing native code. This is because VMs can use runtime information to perform additional optimisations when they do their on-the-fly compilation, which is not possible when statically compiling C/C++ code. Modern VMs are able to look at runtime properties of a program, and where additional optimisations can be made they dynamically re-compile bits of code in order to make additional optimisations.

That can potentially a disadvantage. Sometimes a developer might want things to be strictly controlled, and having a VM running in the background removes some of that control.

Energize · 10 Sep 2007 at 01:16

If they programmed games using java. Would they work on every platform?

Shoseki · 10 Sep 2007 at 01:33

The GNU build toolchain with autotools is designed to make c++ work on many different platforms. That is why all the best open source projects work on god knows what platforms with little editing :

1) ./configure (or bootstrap if configure not yet created)
2) make
3) sudo make install

And suddenly project X is working on some bizarre setup it was never designed to work on. Its called having a sane build environment. The only thing is the dependancies, and the "hardware specific libraries" which can be abstracted away using APIs such as OpenGL.

C++ is much, muuuuch more than just "the fastest most powerful programming language"...

Lagz · 10 Sep 2007 at 08:38

Energize said:
If they programmed games using java. Would they work on every platform?

As in every platform that has Java (Windows, Linux, Mac etc) - Yes.

~J~ · 11 Sep 2007 at 05:57

Lagz said:
As in every platform that has Java (Windows, Linux, Mac etc) - Yes.

Don't take this personal, and I have NO grievance with you, but your lack on understanding in this subject may have an impact on peoples willingness to learn.

Your "Yes" is simply not true at all.

Most games will use interrupts and/or pointers to do several things at once and 99% will require processor specific calls to achieve optimal results. Macs and PC's (and Windows and Linux for the latter) handle interrupts, pointers and direct calls differently and the hardware is totally different.

If the game was programmed that used networking, again it's TOTALLY different for Mac and PC based hardware, typical example is a PC will use COM1: and COM2: and a Mac will use "Modem" and "Printer" for essentially the same thing. Likewise Macs have to flush the data stream before allowing another, PC's don't.

File handling (loading binaries, resources) is totally different between all platforms. C:\Program Files\Game\Textures\tex34.jpg would certainly cause a crash on a Mac and Linux. The only way round this is to use relative directories rather than fixed directories but this assumes that the owner of the machine isn't someone who likes to 'tinker' with their machine and has the system configured how they want. C:\%os.root%\Drivers would work on the majority of machines but ONLY if the user hasn't moved their Drivers directory to somewhere else. If they have, the game is useless.

Talking of graphics, AWT is handled TOTALLY different on each and every version of Java platforms. There is not one VM that handles the AWT the same way across all platforms.

Java in Windows is a LOT faster than Java on a Mac. The differences in the two are so great that even advanced delta-timing just wouldn't cause a game to be the same product on either platform.

Java is cross platform because it is a language that can be run on a multitude of hardware (Mac, Windows, Linux, Symbian, etc) unlike something like VB.Net/c# which is only PC. But each and every platform has a different VM (and even then there are many variations in VM's) so the game would need to be tested on a multitude of machines with a multitude of VM's to ensure a wider compatibility.

If you wrote PURE Java, that is used the commands that are native to the language much like BASIC was years ago (GWBasic, Mallard, QBasic, pBasic, RealBasic, etc) then you'd be able to port relatively easy and with hardly any OS/Platform checking. But once you start adding anything to do with graphics, networking or specific calls to hardware, you're hitting none-portability.

I could go on, but the myth that Java is cross-platform is literally a google away and I'm surprised you didn't research more before posting your answer.

n3crius · 11 Sep 2007 at 15:36

I'm a hobbyist and right now I'm writing a game with C# and XNA. It's so much fun.

Suprises me how smooth and fast it all runs through the .NET Framework. Not just on my 360 in the front room but running the code on the lappy (which is really slow) gives great performance.

Energize · 11 Sep 2007 at 15:48

~J~ said:
I could go on, but the myth that Java is cross-platform is literally a google away and I'm surprised you didn't research more before posting your answer.

I should have known that java-loving Oracle were lying to me.

Lagz · 11 Sep 2007 at 16:26

~J~ said:
Don't take this personal, and I have NO grievance with you, but your lack on understanding in this subject may have an impact on peoples willingness to learn.

Your "Yes" is simply not true at all.

Well - it was a simplified answer. Some of your points are valid, most are not (really).

~J~ said:
Most games will use interrupts and/or pointers to do several things at once and 99% will require processor specific calls to achieve optimal results. Macs and PC's (and Windows and Linux for the latter) handle interrupts, pointers and direct calls differently and the hardware is totally different.

If your writing a game in Java you wont be using pointers etc. You will be using Java, so this is an issue about performance (i.e. not being able to do all these things) not about portability.

~J~ said:
If the game was programmed that used networking, again it's TOTALLY different for Mac and PC based hardware, typical example is a PC will use COM1: and COM2: and a Mac will use "Modem" and "Printer" for essentially the same thing. Likewise Macs have to flush the data stream before allowing another, PC's don't.

Its trivial to deploy a Java game using an installer that will determine the system platform and set such things accordingly (i.e. pick between 3 configuration files), or just have one download per platform which is identical except for different configuration files. This is a very minor problem.

~J~ said:
File handling (loading binaries, resources) is totally different between all platforms. C:\Program Files\Game\Textures\tex34.jpg would certainly cause a crash on a Mac and Linux. The only way round this is to use relative directories rather than fixed directories but this assumes that the owner of the machine isn't someone who likes to 'tinker' with their machine and has the system configured how they want. C:\%os.root%\Drivers would work on the majority of machines but ONLY if the user hasn't moved their Drivers directory to somewhere else. If they have, the game is useless.

Well if I installed a game and then decided to delete its (relative) texture directory and move it somewhere else, then I wouldn't expect it to work! Hence your comment about moving relative files is void. If you wanted to you could have a configuration file that the user could update if they wanted to do something like that (although why would they!?). I cant think of a reason why you would need the drivers folder.

~J~ said:
Talking of graphics, AWT is handled TOTALLY different on each and every version of Java platforms. There is not one VM that handles the AWT the same way across all platforms.

I don't think this is an issue. If you were writing an openGl game in Java the sole purpose of AWT would be to open a single window, into which JOGL would render. Infact I believe you can bypass the use of AWT altogether since there are cross platform bindings for things like GLFW, which will open you a window for openGL rendering.

~J~ said:
Java in Windows is a LOT faster than Java on a Mac. The differences in the two are so great that even advanced delta-timing just wouldn't cause a game to be the same product on either platform.

This is a performance issue. Its like saying the game wont be the same on a fast PC as on a slow PC, which applies to all languages! Presumably if people started using Java for games, then Sun would improve the performance of the Mac VM if it is actually lagging behind.

~J~ said:
I could go on, but the myth that Java is cross-platform is literally a google away and I'm surprised you didn't research more before posting your answer.

Thanks for the tip. Unfortunately I don't need to look on google, because I've already written Java code which:
1. Uses OpenGL via JOGL to render 3D graphics
2. Connects to serial ports using RXTXcomm and controls serial devices
3. Networks between multiple machines
I've found it to be very portable between Windows and Linux (I don't have a Mac). The Java code is entirely platform independent and just uses a configuration file for things like finding out what the serial ports are called. All the issues you mention are quite minor.

Una · 11 Sep 2007 at 17:26

Cant really say I am a fan of java but there has been commercial games written in it.

Runescape (MMORPG) for example :- http://en.wikipedia.org/wiki/Runescape

NokkonWud · 11 Sep 2007 at 20:57

C++ almost exclusively.

Markus123 · 12 Sep 2007 at 02:11

Where I work we use C++ for the game/core, C# for game tools (i.e level editors, character generators, etc).

"Realtime Worlds" (Crackdown Developers) are supposedly writing a game exclusively in C# at the moment though so it'll be interesting to see how it turns out if it ever materializes.

NokkonWud · 12 Sep 2007 at 03:41

The feeling I got from Phil Wilson was that it was C++ as he was actively involved in a conversation regarding this at GameHorizon last week, but obviously he was very secretive regarding it, it's obviously not APB as that's built on the UE3 (and not the Crackdown engine as many would have you believe), but both APB and their next game are both online games, so if they feel they can get a better engine from C# for online play then that's understandable.

I heard rumours it was a brand new, MMO engine for a new 'Elite' game, which would be a massive coup.

Can I just ask where you work Markus123?

Shoseki · 12 Sep 2007 at 11:26

~J~ said:
Don't take this personal, and I have NO grievance with you, but your lack on understanding in this subject may have an impact on peoples willingness to learn.

Your "Yes" is simply not true at all.

Most games will use interrupts and/or pointers to do several things at once and 99% will require processor specific calls to achieve optimal results. Macs and PC's (and Windows and Linux for the latter) handle interrupts, pointers and direct calls differently and the hardware is totally different.

I don't get it... I program iso c++ and build using the gnu autotools... a pointer is a pointer (with the only exceptions being difference between 64bit and 32bit)... interrupts may be handled differently but they are programmed in the same way... the hardware is mostly abstracted away by APIs (OpenGL, OpenAL etc etc)...

~J~ said:
If the game was programmed that used networking, again it's TOTALLY different for Mac and PC based hardware, typical example is a PC will use COM1: and COM2: and a Mac will use "Modem" and "Printer" for essentially the same thing. Likewise Macs have to flush the data stream before allowing another, PC's don't.

Once again, normal programmers use API's to handle this sort of thing, they don't "flush the data stream themselves" in one platform and not in another.

~J~ said:
File handling (loading binaries, resources) is totally different between all platforms. C:\Program Files\Game\Textures\tex34.jpg would certainly cause a crash on a Mac and Linux. The only way round this is to use relative directories rather than fixed directories but this assumes that the owner of the machine isn't someone who likes to 'tinker' with their machine and has the system configured how they want. C:\%os.root%\Drivers would work on the majority of machines but ONLY if the user hasn't moved their Drivers directory to somewhere else. If they have, the game is useless.

Paths may be differently handled, but tbh that syntactical, rather than programmatic difference, and easily handled with compiler conditionals. 99% of modern applications will use relative directories, and if the user has screwed around with where files need to be, of course the dependencies will fail, however, usually games are either

a) Self-contained and thus don't require high level dependancies that it can't determine on the system already (Who screws around with where Windows puts its' directx dlls anyway?)
b) Packaged properly in one of the repositories like Ubuntu where apt can install it, combined with any dependancies already in the system.
c) If the user screwed with their setup, they also screwed with the program, and they are responsible for setting library/include paths to where they moved the new libraries, with semantic links if necessary.

~J~ said:
Talking of graphics, AWT is handled TOTALLY different on each and every version of Java platforms. There is not one VM that handles the AWT the same way across all platforms.

Java in Windows is a LOT faster than Java on a Mac. The differences in the two are so great that even advanced delta-timing just wouldn't cause a game to be the same product on either platform.

AWT? You mean the ancient "platform native" windowing toolkit java used to use pre-2.0? I didn't think anyone used that any more. I have not heard of "advanced delta-timing", though a few googles bring up a lot of game development sites that aren't native c++ development communities... and you are complaining about performance?

~J~ said:
Java is cross platform because it is a language that can be run on a multitude of hardware (Mac, Windows, Linux, Symbian, etc)

No, java runs on a JVM. The JVM is compiled on a multiple of operating systems (Mac, Windows, Linux, Symbian are operating systems, not hardware)

~J~ said:
unlike something like VB.Net/c# which is only PC.

VB.net I have no idea, but c# and the .net development framework has MONO to run on other operating systems, which is open source.

~J~ said:
But each and every platform has a different VM (and even then there are many variations in VM's) so the game would need to be tested on a multitude of machines with a multitude of VM's to ensure a wider compatibility.

True, but as long as they are the same "version" of the JVM, they should run with limited compatibility problems. You major concern is whether your external apis like JOGL's hookup to opengl still works ok.

~J~ said:
If you wrote PURE Java, that is used the commands that are native to the language much like BASIC was years ago (GWBasic, Mallard, QBasic, pBasic, RealBasic, etc) then you'd be able to port relatively easy and with hardly any OS/Platform checking. But once you start adding anything to do with graphics, networking or specific calls to hardware, you're hitting none-portability.

As far as I was concerned, not that I program java a great deal any more, networking was handled by Java Sockets, and was operating system independant. Depending on whether you are using native java graphics (using the SWT or the old Graphics g), which might be a bit slow for games, or using something like JOGL, you might get different results, indeed.

~J~ said:
I could go on, but the myth that Java is cross-platform is literally a google away and I'm surprised you didn't research more before posting your answer.

Java itself is not cross platform, because it doesn't *see* the platform, all it sees is the JVM. The JVM acts as middleware to protect Java from having to see the nitty gritty. External libraries such as JOGL might have special cases I guess, I am not an expert in that.