Why Video Games Need Their Own Programming Language

[gardian06]

to summarize some points from article.
'people know C because that is what is taught, and C is what everything is written in, and for'
no: a high number of programming degrees will suggest C++ as an introductory language. most of the time they don't even want to consider going into teaching real C cause it will just end up confusing to many students (one of my biggest anger issues at a C++ book is when it teaches C and says that it is C++ because there are differences), but they will usually also offer the same classes in C#, Java, and maybe a 4th or even 5th language if they have the instructor. the reason that they teach these languages is that they are all compiled object oriented languages that can easily have data-structures, and libraries applied (if not included by default). and your whole thing on 'everyone knows C, and all the jobs are in C' this is so much BS that I want you to cite you source cause just doing a google search on programming jobs only 1 in 5 will expressly require knowledge of C++ the higher majority (3 in 5) of them will require something like Java.

'computers these days have so much more processing power, and memory that they don't need something so heavily designed for high performance' then you go on to say that 'there are these portions that do need high performance'
first make up your mind either we do have so much system ability that we can sacrifice performance, or we need to keep an eye on performance. I have spent a good portion of my programing career correcting the mistakes of people who not only spouted, but fundamentally believed the former statement. they write code that does not clean up after itself, and that just ends up making a mess of things bogging down a simple operation that if done with performance in mind will have no impact, but ends up slowing EVERYTHING down.

'there are game engines like Unreal that allow for the lighter parts to be scripted, but the heavier stuff to be coded in C++[sic]'
the funny thing is that first UnrealScript is a love child of C++ and ActionScript, and the funniest part about your statement is that you write your AI code in UnrealScript, and the AI isn't even done in C++. if you purchase their $5,000,000 per seat license then you can write your AI code in C++, but yeah $5,000,000. then you still come into the fact that everything that is written in UnrealScript gets compiled anyways

the big issue with game development is that it has become to compartmentalized in the AAA space. for you indie space you have a small team that is probably coding everything, and directly implementing as they go. while in the AAA space you have an entire team working on the tools, and then when they are done the game is handed off to the level design team and they can cause grand problems for their un-knowledged. hows this I am willing to bet money that of those 10 studios, and 4 years to make AC: Unity at least 8 of those studios, and 3 of those years were spent making the tools for the game, and only the last 2 studios, and 1 year (if that) were spent assembling the game. the is necessitated by the issue that these "Level Designers" don't necessarily know how to use the tools they are given, and then either underutilized them or overtax them. something tells me that again AC: Unity the system was only designed for up to 900 AI agents on screen, but the people doing the level design through in an extra 100 just make it seem more "full" which is why framerate tanks.

the issue is not the language. the issue is that people either don't know how to use what they have, and therefore don't want to learn, or are unwilling to take the time to find the answer. there are hundreds of people in the programming community that spend a good portion of their work day on programming Q&A sites willing to answer questions.

 

[renegade7]

This article could have stood to be researched a little better.

First, I have no idea where the 1983 figure comes from. C first appeared in 1972 and its last update was in 2011. Calculus is nearly 350 years old, and it forms the core of engineering, and thus of the entire technical world, and no one seems to be complaining that "our math is too old!".

People study C not only because it's the most common language in the technical profession, but because it is the most powerful general-purpose computing language out there.

It is correct to a point to say that C was not intended for applications at today's scales of integration. But that is absolutely not to say that C is an insignificant language, unfit for anywhere outside the computer engineering classroom. It is the language that drives microcontrollers, like those driving hardware-level processes in your computer (the system BIOS, network, fan, USB, and drive controllers), or those that go in more general consumer electronics. And by that I mean NEARLY ALL OF THEM ARE PROGRAMMED IN C.

Additionally, C is a language that is very simple to learn but takes years to master. It's taught because it is both very general, but also unlike higher-level languages like Java or Python it doesn't "black box" anything. For the student, that means they get a fundamental understanding of how computing works and a ready-to-go working knowledge of programming, and for the professional that means they get the tools they need to precisely design functions for any application. Because of that simplicity, it also serves as the starting point for learning more specialized languages. It also happens to be incredibly fast compared to higher-level languages.

Second, calling C++ a mere upgrade to C is like calling IBM Watson an upgrade to the abacus. C is not necessarily suitable for commercial applications, but that's what C++ is for. I t's a totally different programming paradigm. Also, C++ is more than capable of being used to program game engines. For performance, it is literally the best you can do short of writing the games in assembly.

Being close to the hardware is the point. When you simplify the language to "save programmer time", what you're doing is you're putting more operations in black boxes (and thus out of the ability of the programmer to precisely control them to suit the application) and, worse, you're forcing the CPU to do more operations and store more data in RAM. If you're aware of the massive amount of operations that a 3D game engine must do, you'll immediately see why this is a problem and why those processor cycles are precious. There's nothing at all wrong with higher-level languages and it is for precisely the reason that they're easier to program in that they're favored for simple applications, so please don't take me for an elitist. But when you need a powerful general-purpose language that you can do anything with, and much more importantly do it well, you need an object-oriented language, and the industrial standard happens to be C++, and not without good reason.

 

[LaoJim]

C came out in 1983? Holy fuck are we overdue for an update., but it looks like we won't have any for a few decades yet. Not without some seriously daring pioneers like the phone phreakers of old.

C was actually created between 1969 and 1973 (according to Wikipedia and my own recollection), it's C++ that came out in 1983. Thing is, unlike hardware, it's not necessarily the case that programming languages get worse with age. For all that our computers these days are millions of times faster than the original ones the basic principles of programming languages have not changed 'that' much, the big exception being object oriented programming which C++ includes. That's not to say that there haven't been advances like garbage collection, relational databases, and just-in-time compilation and so forth, it's just that they all involve trade offs that game developers aren't always willing to make.

The other point is that there are few languages more complicated than C++ (possible ML but that's fairly obscure), the whole trend is to make programming languages simpler. If you are smart (and the top game developers are very smart) you can do some incredibly clever and beautiful tricks with C++ (for example with generics). If you are a little less smart, you can also shoot yourself in the foot completely.

We do have several updates. Java and C# being the most visible ones.

Except that they aren't really updates, they are complete different languages dressed up to look like C. Java is basically SmallTalk disguised in C syntax, and C# is a Java clone which Microsoft produced after they fell out with Sun (not that C# doesn't do some things better than Java). As others have pointed out C++ has been constantly updated, the problem is that standards committee are slow and compiler implementers even slower.

he claims that "there are three reasonable languages... that we could even *think* of switching to... Go, D and Rust...These are basically niche languages without any history in games. What about the obvious candidates people have actually heard about and that have a considerable array of game-libraries and frameworks, such as, Java, C#, JavaScript, Lua?
".
This is kind of the point; Java isn't really suited to AAA development (although one man probably wouldn't have been able to program Minecraft in C). I don't buy into the idea of Java being a slow language, especially not these days, and people have done some pretty performance intensive stuff with it, but because you're asking the Java virtual machine to do a lot of your housekeeping for you, it's difficult to get the same control over performance that you get with C. It's not impossible, but for any project manager it's a huge risk to go with Java over C++ where the problems are well known. JavaScipt and Lua are even less suitable for game development.

I'm not too familiar with Go or Rust, but D is basically designed to be C(++) with some of the rough edges smoothed down, it can do pretty much the same thing that C can do but without some of the gotchas. It is untested, but theoretically with enough support/time/money it could become a "better C" My feeling looking at it though is that it is not different enough to C, nor are the problems with C so serious that it's really worth making the shift, especially until it comes to be better known. That said, if every company in the world decided to invest millions in D at the same time and plan to make C obsolete in 5 years time, it might not be a bad thing for the industry as a whole.

C++ is kind of awful (and when you're coding for speed you're not going to use a lot of its features over C), but not having a standard at all, and instead having a flood of different languages and systems, is IMO worse.

Yeah, it's a better the devil you know kind of situation. Companies need to be clear about which features of C++ are acceptable for the common or garden developer to use and which are more trouble than their worth.

 

[CrystalShadow]

Ah, trying to create new languages, even if they do tasks that aren't really covered yet by existing ones always seems to lead to trouble...

Just look at the GPGPU languages! - We only have 2 major graphics card manufacturers left, and yet, both of them came up with their on GPGPU language which is unlike the other. (ATI/AMD made theirs open source, but still...)

So now you have CUDA and OpenCompute, both trying to do the same task, and both only working on some of the hardware in existence...

Which, in effect you either aren't going to bother writing GPGPU code at all, are going to choose one and basically leave anyone with competing hardware out in the cold...

Or... You double your workload implementing everything twice. (or 3 times even, just in case you find something that can't run either of those...)

This is why new languages have such a hard time catching on...

 

[fractal_butterfly]

Why is there no one pointing out, that there are things like the visual scripting languages like Kismet for the Unreal Engine or FlowGraph for the CryEngine? They are based on finite state machines and flow graph like structures, and are "programmed" by simply clicking, dragging and connecting logic blocks.
They are easy to use for designers and heavily speed up the game logic programming work, since they can be used for rapid prototyping. I think, the "new programming language for games" is already existing, it's just not seen as a programming language since it so so unlike programming.

 

[wizzy555]

Why is there no one pointing out, that there are things like the visual scripting languages like Kismet for the Unreal Engine or FlowGraph for the CryEngine? They are based on finite state machines and flow graph like structures, and are "programmed" by simply clicking, dragging and connecting logic blocks.
They are easy to use for designers and heavily speed up the game logic programming work, since they can be used for rapid prototyping. I think, the "new programming language for games" is already existing, it's just not seen as a programming language since it so so unlike programming.

Gone Home used some visual scripting addon for the unity engine which already uses C# to make it easier than C++.

 

[Kahani]

The big problem with the idea of a game-specific programming language is that games are not all the same. A chess program may be different from a word processor, but an FPS could easily be just as different from both as they are from each other. There's a reason we already have multiple different game engines, drivers, operating systems, and so on - no single solution is the best in every situation. Hell, the article even makes this point itself when it notes that some parts of a game need to worry more about efficiency and speed than others, and frequently use different languages because of this. If people already use different languages to meet different needs within a single game, let alone between different games, it's obviously stupid on the face of it to suggest that a single language could magically meet everyone's needs.

 

[Tarfeather]

Or... You double your workload implementing everything twice. (or 3 times even, just in case you find something that can't run either of those...)

You might even have to do that with the same language. GPUs are highly specific and often just moving up a few versions in the same "brand" will require you to rewrite your code to get full performance.

On topic, though, when it comes to programming languages, it really doesn't so matter which one you use. What's more important is the way you think about your program. Some languages try to force you into a specific style of thinking. C++ doesn't, and I appreciate that. But there really isn't any need for a new language, unless it were a language that completely revolutionized the way you program(and the reason C++ is still so widely used, is that that hasn't happened in the past 30+ years).

You may say that languages like haskell etc. revolutionized the way you program. Well, they might have, but you can still do the things you do in haskell in C++ or any other language. All that changes is syntax and some compiler checks. Unfortunately, in a production environment, giving up on some haskell-specific compiler checks and using C++ will still lead to faster development than using haskell.

 

[fractal_butterfly]

Why is there no one pointing out, that there are things like the visual scripting languages like Kismet for the Unreal Engine or FlowGraph for the CryEngine? They are based on finite state machines and flow graph like structures, and are "programmed" by simply clicking, dragging and connecting logic blocks.
They are easy to use for designers and heavily speed up the game logic programming work, since they can be used for rapid prototyping. I think, the "new programming language for games" is already existing, it's just not seen as a programming language since it so so unlike programming.

Gone Home used some visual scripting addon for the unity engine which already uses C# to make it easier than C++.

Indeed. Several other games used a plugin named PlayMaker for Unity, even big companies like Blizzard use them. Not for the whole game, since you still need programmers to create the actions to be used with the flowgraph, but it enables Artists and Designers to create game logic on the fly.

 

[Rebles]

This article could have stood to be researched a little better.

As could have you and with research I mean, actually read the article.

First, I have no idea where the 1983 figure comes from. C first appeared in 1972 and its last update was in 2011.

The 1983 figure comes from C++, as stated in the article.

It is correct to a point to say that C was not intended for applications at today's scales of integration.

As mentioned in the article.

But that is absolutely not to say that C is an insignificant language, unfit for anywhere outside the computer engineering classroom.

Nowhere in the article does he say anything like that. No. On the other hand he goes on a whole page how it is a language that is close to the hardware and basically saying:

It is the language that drives microcontrollers, like those driving hardware-level processes in your computer (the system BIOS, network, fan, USB, and drive controllers), or those that go in more general consumer electronics. And by that I mean NEARLY ALL OF THEM ARE PROGRAMMED IN C.

Second, calling C++ a mere upgrade to C is like calling IBM Watson an upgrade to the abacus.

Now you are arguing semantics. To that point, he never said that C++ is a upgrade to C. Descendant and "newer hipper version" are the actual phrases.

Being close to the hardware is the point. When you simplify the language to "save programmer time", what you're doing is you're putting more operations in black boxes

His point was that while you want to be close to the hardware in some parts (graphics, character animation, AI, physics systems) you don't want it in others (interface, game logic, networking, processing of player input).

If you're aware of the massive amount of operations that a 3D game engine must do,

He is: "Shamus Young has been writing programs for over 30 years, from the early days of BASIC programming in the 80s to writing graphics and tech prototypes today."

you'll immediately see why this is a problem and why those processor cycles are precious.

He did not see that, thus the article.

 

[renegade7]

His point was that while you want to be close to the hardware in some parts (graphics, character animation, AI, physics systems) you don't want it in others (interface, game logic, networking, processing of player input).

Modern games are not all written as a single cohesive program. They are modular. In very general terms, there is the game engine and the game's actual content. It needs to be stated very clearly that these are two distinct entities, and you don't just program the entire project in a single language.

Now, there is no good sense programming the content of a game (AI scripting, graphical assets, etc) in a language like C++. But the engine is a much more complicated beast. The engine itself is not actually a game, it is a program that loads and processes the assets into the game you actually play. In memory, those assets are data structures, and being an object oriented language, C++ is ideal for such applications.

The purpose of the engine, functionally, is to coordinate the assets along with the logic and player input. Higher-level aspects of the game are only instructions telling the engine what to do.

Interface, game logic, networking, and processing of player input all depend on careful coordination between the engine and the assets. If by "interface" you mean simply what the commands are, then yes, that can be separate. But in terms of how those commands are actually handled in data, you can't get away with just saying that because they're simple, they don't need to be low-level. Same goes for networking.

As could have you and with research I mean, actually read the article.

Of course, though I knew enough after I read "I will not be making a distinction between C++ and C". They are very different.

A program in C is a set of instructions that operate directly on data that is loaded into memory and executed sequentially.

A program in C++ creates structures in memory that contain data and instructions and manipulates those structures. This makes it very ideal for game engines.

That is not just semantics or nitpicking for programmers. That is a fundamental difference in how the two languages operate.

 

[Tamayo]

All Turing-complete languages are equally "powerful"; there is no problem that can be solved by a C program that cannot also be solved by an Intercal program. Unfortunately, it's really hard to write a program in Intercal, and it's absurdly hard to read an Intercal program to figure out what it does. Moreover, a competently-written C program will certainly solve the problem in orders of magnitude less time than any Intercal program will.

As pointed out in the article, C and C++ are artifacts of their design in the 1970s and 1980s. C is hardly a high-level language at all, but rather a macro assembler for the PDP-11 minicomputer. Like any macro assembler, it gives very close control over the workings of the computer, but it makes huge assumptions about exactly which computer is being used; as time has gone on and the kinds of hardware and software to which C and C++ have been applied have evolved, the impedance mismatch between the expectations of those languages and the requirements of the programmers have grown as well. For example, C does not have any linguistic method for controlling parallel processing; it leaves that up to the operating system, if there is one. C++ added in a grudging nod to concurrency officially in 2011. Essentially all processors for gaming computers, console or PC, have more than one CPU core; GPUs have thousands of cores. As pointed out in another posting above, there are two major GPU vendors, each of which wants programmers to use a different, incompatible, incomparable dialect of C to control its product. Using any variant of C is an error for writing anything that is not the Linux kernel; requiring graphics programmers to do their jobs twice in two different ways in a language that is intended for writing PDP-11 device drivers is just plain nuts.

I think that the real goal here is to design a language wherein writing programs to run on GPUs is less difficult, or at least less difficult than rocket science. A few of them exist now. Haskell was mentioned in another post above; it's the most common purely-functional language in use right now, and it was explicitly designed for parallelism. There are libraries ready for using Haskell with GPUs and they work well. They do maintain a C-ish flavour, however, despite all of their authors' efforts, because they are interfacing with C libraries.

But---it seems that for really explicitly defined, constrained realms of computation, such as producing gobs and gobs of polygons on screen sixty or more times per second, the full generality of a Turing-complete language is more a detriment than an advantage. If there exists a program in your language that can emulate a Turing machine, then there exists another program in that language which will not halt. However, if you impose a requirement that every program in your language must halt, then you cannot write certain kinds of programs such as emulators or operating systems in that language. You can, however, write lots of other useful programs, such as compilers or ray-tracers or graphics servers. Furthermore, the compilers for such limited languages are simpler to build and simpler to make powerful, because they don't have to make the all same kinds of assumptions that compilers for Turing-complete languages must make. They can truly optimize, because they can deduce more about the behaviour of any given program than a compiler for a Turing-complete language can. Such limited languages are almost necessarily functional-ish in style, but even seasoned Haskellers tend to find them a bit weird. Still, presumably, it would be easier to train a new programmer in one of these weird dialects than to make him or her into another John Carmack.

I know the D language. I like it. It's a much better C++. Nevertheless, D is not the language in which graphics engines, let alone whole games, should be written. D is a grand language in which to write compilers---but compilers are really simple programs. A new language for writing graphics engines must take the programmer further away from the machine, not closer to it (let alone closer to some [em]other[/em] machine), and furthermore it must protect the programmer from the stunning complexity of massively-parallel processing. John Carmack is right: graphics programming is harder than rocket science, but that's because he's building his graphics engines with the linguistic equivalent of stone knives and bear skins.