Has the industry changed, or are commercial games still C/C++?

I'm pretty sure it is atm but I'm not 100% sure. I have heard of C# but I'm not really sure what it is yet. I might get it and try it out.

If by "commercial" you mean games you'll actually see in stores, then yes, they are almost exclusively written in C or C++. Seeing how most companies already have large C/C++ codebases, and are the only languages really supported by consoles, things likely wont change for a long time.

Quote:

Original post by _swx_ If by "commercial" you mean games you'll actually see in stores, then yes, they are almost exclusively written in C or C++. Seeing how most companies already have large C/C++ codebases, and are the only languages really supported by consoles, things likely wont change for a long time.

I agree. C++ has been around for so long that noone would bother changing it anyway. Too much work, esspecially for peeps like Microsoft.... lazy people...

right now, I'd say the core of the games (engine and parts which need to be "fast") are indeed written in C or C++, however alot of the game logic is now shifted out to other languages, Civ4 for example uses Python, NWN used Lua, Eve as you say uses Python and many other games use them or their own scripting system to make the game logic work (this could well include C# as its hostable as a scripting language).

Could someone please tell me what Python is? I've come across it a few times, but don't know what it is...

www.python.org

Depends on what part of the game you are talking about. Tools might be written in C# or a multitude of other languages including C/C++. Tech is likely to be C/C++. Gameplay is likely to be a mixture of scripting languages such as Lua and C/C++.

Quote:

Original post by _swx_ If by "commercial" you mean games you'll actually see in stores, then yes, they are almost exclusively written in C or C++. Seeing how most companies already have large C/C++ codebases, and are the only languages really supported by consoles, things likely wont change for a long time.

I mainly agree with you, but I think that for exampe C# will be supported by consoles too. With XNA the .net framework will be available for the next X-Box. But of course it can take a long time until this is accepted by game developers.

georg

Even when it is, a developer that adopts C# for his console games is going to be giving up the option for a PS3 and Rev port(seems unlikely sony/nintendo is going to support .NET on it). That alone is likely going to turn most real developers off of using it. C# However I think is be perfect for indies or Xbox Live Arcade games. Many of the big developers target multiple consoles. They aren't going to maintain 2 seperate codebases.

Quote:

Original post by DrEvil Even when it is, a developer that adopts C# for his console games is going to be giving up the option for a PS3 and Rev port(seems unlikely sony/nintendo is going to support .NET on it). That alone is likely going to turn most real developers off of using it. C# However I think is be perfect for indies or Xbox Live Arcade games. Many of the big developers target multiple consoles. They aren't going to maintain 2 seperate codebases.

There is a discussion about this particular subject on sweng-gamedev right now. C# can be executed using mono - meaning that you can use it on a PS3 if you want (edit: and if you adapt mono to the PS3 - this has to be done). The main problem about C# on console is the garbage collector - but again, if one can run the GC at a known time, the problem vanish.

More about the ongoing discussion here

Regards,

Just to clear up a few things:

- Commercial as in on the shelves at your local EB or GameStop.

- I'm talking about any and all aspects of game programming. However, for the sake of argument, the programming language used to make the game should be the one that was mostly used. For example, I'm sure Eve Online had a lot of its core componenets in C++, but it was mostly programmed using Python. Thus, it's considered to be programmed in Python. So I'm not talking about commercial games that just use one single language (in fact, what games do these days?), I'm talking about commercial games that use one language more than another.

Hope that clears up those questions.

In any case, I didn't consider Consoles and Handhelds (such as PSP and Nintendo DS). Something tells me those systems will remain C++ oriented for some time, unless somehow Microsoft changes that. But like someone else said, that won't even be until their next system (unless they were referring to the 360), so it won't be for a very, very long time.

EDIT:
Looks like C# can be used on the Xbox 360, but I still haven't heard of any games being programmed in it for the system. I'm sure once that starts happening, Microsoft will make a huge deal about it. And I haven't seen any sort of PR, so we can assume it hasn't happened yet.

C/C++ isn't going anywhere anytime soon. Consoles are the easiest point to make given that their dedicated hardware is well suited to aggressive optomisation, but also when considering imature toolchains C/C++ is easy to work with to reap substantial benifits.

I don't know many programmer who can look at a section of Python or Lua and have a rough idea what the ASM thats generated will look like but pretty much everyone i work with has a decent idea of what is generated from the C++ they write.

There may be exceptions to the rule but i'm yet to see a game that has the majority of its codebase in a script language, EVE may be an exception but i'm still lincline to think not.

As for the why, the competitive market will account for a non trivial part of that decision. The faster you run, the more frame time you have left to add sparkle or some additional AI characteristics etc, again thats a bit console centric but the theory holds for PC titles as well. Plus, as was mentioned, the code base is there already and works well. If its not broken, don't fix it.

I have to say that all applications that I have worked that relys on heavy or need fast computations all choose C/C++ as the language to implement those components (and I am not a game developer). It's simply faster. I would not say the Eve online is done in python. The game logic is done in python which is completely different. It is not uncommon to use languages like java, lua or python untop of an C/C++ engine though..

-si

This thread is kinda funny, yes as of current the majority use C/C++ for core engine development however this very likely to change (infact it must) in the next ~5-10 years for good reasons.

Most notably C/C++ are not well suited (and no not C# either) to large-scale development of massively concurrent/parallel applications in large scale distributed environments written by medium to large development teams that we will have when we get consoles/PCs with +20, +100, +1000-core CPU, It's just not feasible.

I'm not going to bother getting into debates with some of what has been said, i'm not even going to try and convenience anyone, you can read The Next Mainstream Programming Languages: A Game Developer's Perspective by Tim Sweeney from Epic if you want convincing.

Whether you like it or not it's already in the current process and the games industry will only learn from there mistakes when we do get those next-gen consoles with +20-core CPUs and things get ridiculously unmanageable & inelegant.

[Edited by - snk_kid on March 25, 2006 11:09:13 AM]

Interesting snk, I found that slide just before reading this thread. Spooky. I like the slide, and some of Tim's ideas are cool - esp the language that does more than just syntax checking at compile time.

Every now and again, people (usually pure computer scientists) advocate using functional programming to solve all the ills of game programming, like Tim Sweeney is in the presentation above.

The main problem with this is that the majority of programmers don't think in functional terms (not all programmers are computer scientists), and functional programming languages are not as readable as imperative ones for both programmers and game designers, who may be writing scripting code.

When I was young, it was lisp that was the order of the day, then POP-11, and now Haskell - all of these were supposed to solve all the ills of software development, yet programs continued to be written in imperative languages like FORTRAN, C and C++. It's a case of programming in a manner that other people can understand, and has been *shown* to work over and over again, which is very important in commercial projects.

gregs you're taking my post (and that link) out of context and did you even bother to read anything properly there before you made a post because i don't think you have...

Quote:

Original post by gregs Every now and again, people (usually pure computer scientists) advocate using functional programming to solve all the ills of game programming, like Tim Sweeney is in the presentation above.

1. No we do not just "advocate using functional programming to solve all the ills" anywhere and without reason.



2. Tim isn't "just a computer scientist"



3. Tim is not just suggesting to use a functional language, he is suggesting language features for the design of band new programming languages.

Quote:

Original post by gregs The main problem with this is that the majority of programmers don't think in functional terms (not all programmers are computer scientists), and functional programming languages are not as readable as imperative ones for both programmers and game designers, who may be writing scripting code.

Did you even bother to read what was in that link, this isn't a suggetions for scripting languages, these are suggestions for new mainstream programming languages for massively concurrent/parallel applications in distributed environments such as next generation game engines. C/C++ is not suitable tool here.

functional/logic paradigms are more readable than imperative, that is the whole point, they are declarative.

Quote:

Original post by gregs When I was young, it was lisp that was the order of the day, then POP-11, and now Haskell - all of these were supposed to solve all the ills of software development

Who said that, and what relevance does this have to Tim's POPL06 pdf/ppt? well it doesn't and nobody here has suggested that.

Quote:

Original post by gregs , yet programs continued to be written in imperative languages like FORTRAN, C and C++.

Correction written in domain-specific areas, not in every problem domain.

Quote:

Original post by gregs It's a case of programming in a manner that other people can understand, and has been *shown* to work over and over again, which is very important in commercial projects.

More like shoehorning over, and over again more likely due to ignorance than anything else.

Quote:

Original post by snk_kid This thread is kinda funny, yes as of current the majority use C/C++ for core engine development however this very likely to change (infact it must) in the next ~5-10 years for good reasons. Most notably C/C++ are not well suited (and no not C# either) to large-scale development of massively concurrent/parallel applications in large scale distributed environments written by medium to large development teams that we will have when we get consoles/PCs with +20, +100, +1000-core CPU, It's just not feasible.

I find that extremely unlikely. It is true that most modern languages aren't currently well-suited for concurrent programming, but that doesn't mean those languages will all of a sudden vanish on the engine-development scene in the next few years. They just need to adapt, and do so rather soon. In particular, C++ should preferably add multithreading facilities to the standard library, and, even better, add high-level facilities for concurrency to the language itself, such as active objects. Short of being standard, it could even do fine with just readily available high-level tools, many of which are already in development. In fact, I'm even working on such a library.

Will C++ be used for engine development in the next 5 or 10 years? Yes, it probably still will. Why? Because there are already massive code-bases that exist in C++ and adding facilities for concurrency really isn't as difficult as many people imagine. Once more tools are available, adapting code to make it concurrent is much easier than starting over in a new language.

As well, Tim Sweeney's claims that functional programming should be prefered by "default" is at the very least, a purely opinionated point of view, and at the most, a sign of his ignorance of the methods for elegantly bringing concurrency to other paradigms. While functional programming is well-suited for concurrent programming, it is certainly not the only solution, and shouldn't even be the "default paradigm" just like there is no "default paradigm" now.

So how do languages like C++ have to adapt in the upcoming years? In particular, Herb Sutter describes in detail the benefits of active objects in his PDC talk on Concurrency which are simple, elegant, and easy to add to languages like C++. Note that adapting code to become concurrent in a language like C++ is not that difficult with such facilities, and he doesn't come to the conclusion that everyone writing concurrent code should just switch over to purely functional programming by default.

Keep in mind that from this point on, the vast majority of software should generally have lots of excess concurrency, not just game engines. This doesn't mean that everyone is going to ditch C++ or C#. Both languages are very easily adaptable and will likely still be widely used over the next 5, 10, or even 15 years. Just like now, people will use whatever paradigm they are comfortable with given the context. The need to add facilities for concurrency to a language is a hurdle, not a road-block.

Quote:

Original post by snk_kid Most notably C/C++ are not well suited (and no not C# either) to large-scale development of massively concurrent/parallel applications in large scale distributed environments written by medium to large development teams that we will have when we get consoles/PCs with +20, +100, +1000-core CPU, It's just not feasible.

Like Irix servers?
Are 1000+ cores CPUs equal cores even feastible with the curent or 20 year + technology?
In fact C++ should copy java.lang.Thread and java.util.concurrent verbatim, and be happy with that. I didn't encounter any mess when using Java threading model. (With exception of badly designed OS sheduler, and not fast enought switching on XP. These were however OS problems.)

BTW this is useful as well.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runnable.html