Why Video Games Need Their Own Programming Language

Why Video Games Need Their Own Programming Language

The majority of video games are programmed in C++, a language that has been around since 1983. Game development needs its own programming language, and Shamus explains why.

Read Full Article

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.

Captcha: shoe shine <-- That's exactly what we don't need right now. We need a whole new pair of shoes.

I sometimes wonder if the next big thing will be a crossbreed between UnrealScript, Project Spark, Counter-Strike and Minecraft. PC gamers love to mod their stuff, and that idea has spread to the general gaming public; pretty much anyone can design a Halo map in Forge, or a LittleBigPlanet level.

It seems to me (someone who just about code, "Hello, world!" in Python) that we're going to reach a point pretty soon where we have a solid physics engine available to everyone (maybe the next Unreal), and a platform that lets you put whatever paint, basic mechanics, and objects you want on top of it with all the ease of using an Apple computer. Tie that to a decently flexible AI, and you've got a product that is both a game in itself, and the next tool for teaching a different programming language and attitude.

Nice to see a tech-related article here.

I'm not convinced about the premise though. There are a couple of potential objections. You say that C is mainly a systems language, which may be true, but isn't a game a complex system of individual, interconnected subsystems?
I guess what you were referring to by "system" is "close to the hardware" - which however again fits the requirements of most AAA games.

Also, you only briefly mention game engines like Unreal Engine, and go on to claim that most developers still code in C. I don't have any hard numbers, but I would think that most AAA games today are not coded from the ground up in C, but are rather built on one of the mainstream game engines. I also believe that most games use a higher-level scripting language for the game-specific code rather than C.

I think a real programming language specifically for games would be an interesting possibility to consider. But any thoughts on the subject should perhaps be more focused on what exactly would differentiate it from traditional programming languages and contemporary game engines. I think you put too much emphasis on how "out of date" the C language is, which might actually be inconsequential to the premise, since I don't think that many game programmers have contact with it anymore. Just the "game system" programmers, perhaps. :)

Cid Silverwing:
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.

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

Shamus Young:
Will Jon Blow invent that language? Statistically, I wouldn't bet on it.

Jon Blow is inventing that language. He's been working on the compiler in his off time and made some nice progress already, and has been streaming some of the programming work on the compiler (which has been awesome to watch). He's going to do a new talk tomorrow night at 7 PM PST at http://www.twitch.tv/naysayer88

I've been following it closely and it's really exciting. I'm a professional programmer, but not in the games industry, so I may not be able to contribute much. But I'm excited to see where it goes and use it when I can get my hands on it.

EDIT: Sorry if I'm coming across too aggressive here; you kinda hit a nerve.

Words can't describe how off the mark you are there.

The game logic has been implemented using script languages since the days of freaking Maniac Mansion. You know what SCUMM is? Exactly this. Lua, NWScript, they all exist for exactly this reason. The game logic being hardcoded in C or C++ is actually really rare.

You even miss Jon Blow's point: he was actually talking about replacing the whole language doing the grunt work, not just the game logic. IMHO, this too is completely bonkers. He also has no background in formal language design, and it shows.

In fact, I think we should rather go the other way: we should start decreasing all this cruft of useless abstractions we build up and think about programing closer to the bare metal again, think about efficiency. If you look at what the demoscene does with 64k (or even 4k!) binaries on 20, 30 years old hardware, you'd be amazed. We have computers that have 16GB of RAM, bogomips to the waazoo, and we're struggling with high input latency.

Shamus Young:
Will Jon Blow invent that language? Statistically, I wouldn't bet on it.

Jon Blow is inventing that language. He's been working on the compiler in his off time and made some nice progress already, and has been streaming some of the programming work on the compiler (which has been awesome to watch). He's going to do a new talk tomorrow night at 7 PM PST at http://www.twitch.tv/naysayer88

I've been following it closely and it's really exciting. I'm a professional programmer, but not in the games industry, so I may not be able to contribute much. But I'm excited to see where it goes and use it when I can get my hands on it.

(Sorry, this was supposed to be an edit.)

How big is AAA? Civ IV is Python with C++ for the heavy lifting. They moved to Lua for V. As noted, most of the game doesn't need the speed of C++.

As someone who regularly uses several languages (C, C++, Python, Perl (not by choice), C#, Java, JavaScript, bash, DOS bat (aieee)) I can confidently say that the idea of 'a' language for games will fail, because each language is designed for different things and people who do games are very opinionated. It's not really performance that holds Java back (there have been impressive performance demos), it's that Java is so damn verbose and restrictive because it's designed to keep business logic monkeys at huge corporations from doing too much damage to each other. Perhaps Ubisoft could use a bit more of that, you say, but it's not fun, so they won't do it voluntarily. It's like doing paperwork. Python and Ruby are effectively equivalent in capability, so instead people bicker about petty syntax things.

But routinely partitioning things into engine and game logic so you could use a less brittle language than C++ for the game logic would be a good start. As long as middleware components provide bindings this is not too hard, just requires some design up front so things aren't just reaching into where they shouldn't. Indies use this approach a lot. If I wrote something right now it'd probably be C# (Mono) on Unreal 4.

Fun to see some more technical articles here. I agree with you, it's really getting to the point where the bottlenecks are everywhere but on the actual CPU and GPU.

Just to be that guy, I want to nitpick and point out that modern C++ is fundamentally different from the C++ in the 80's. This might not be general knowledge, but programming languages actually also get content patches and updates, in their own way, albeit at a much slower pace than your programs and video games.

Here's a little roadmap from the C++ committee's webpage, for those who are interested: https://isocpp.org/std/status

SharedProphet:

Shamus Young:
Will Jon Blow invent that language? Statistically, I wouldn't bet on it.

Jon Blow is inventing that language. He's been working on the compiler in his off time and made some nice progress already, and has been streaming some of the programming work on the compiler (which has been awesome to watch). He's going to do a new talk tomorrow night at 7 PM PST at http://www.twitch.tv/naysayer88

I've been following it closely and it's really exciting. I'm a professional programmer, but not in the games industry, so I may not be able to contribute much. But I'm excited to see where it goes and use it when I can get my hands on it.

(Sorry, this was supposed to be an edit.)

Creating the language is one thing, disseminating the language is another thing entirely.

We are not seeing a big trend to get much closer to the bare metal (DirectX 12, MANTLE) for no reason, Shamus.
Like many people pointed out almost everything is done with scripting languages and/or with middleware doing all the C/C++ grunt work...

So far, the "problem" with C++ is that it is not a language specifically built around making games, so it doesn't have any native paradigm to support everyday structures of games. For a new language to be more useful, it has to be more than simply a new language, it has to be a new paradigm.

And isn't that the point of most game development engines out there? To provide an abstraction level with their own scripting language than is later compiled into whatever platform would be considered as its "final console".

At this point, it would seem like the easiest solution would be to make the engine developers to agree on an interpretation paradigm and language, and each console manufacturer can work on a compiler to that language. That would alleviate developers, while leaving the engine developers to fight on the realm of tools and development environments.

The John Carmack quote got me thinking... what if he were to make a new language? He's one of the most talented programmers on the planet, and if anyone could pull it off and do a good job, it's him. That isn't to say I don't think Blow can do it, but if Carmack were to try his hand at it, he'd almost certainly do better. Just like he pretty much always does with everything he touches.

P.S. Thanks

PrinceOfShapeir:
Creating the language is one thing, disseminating the language is another thing entirely.

There are a lot of game devs interested in what he's doing. It will happen. Widespread adoption may be a hurdle, but maybe not if it is just obviously much better to work with.

Lemmibl:
Just to be that guy, I want to nitpick and point out that modern C++ is fundamentally different from the C++ in the 80's. This might not be general knowledge, but programming languages actually also get content patches and updates, in their own way, albeit at a much slower pace than your programs and video games.

Here's a little roadmap from the C++ committee's webpage, for those who are interested: https://isocpp.org/std/status

Game devs know. That's a tech-intensive talk, but in short, many pro game programmers don't use a lot of the newer C++ features in their engines not because they don't know about them, but because they do.

oldtaku:
How big is AAA? Civ IV is Python with C++ for the heavy lifting. They moved to Lua for V. As noted, most of the game doesn't need the speed of C++.

...

But routinely partitioning things into engine and game logic so you could use a less brittle language than C++ for the game logic would be a good start.

Most games already do this. As you mentioned, Civ, like many other games, uses Lua (and it bogs down horribly when you get to the later stages of the game), the Unity game engine houses Mono to run game logic using .net (so you can write it in JavaScript, Boo, or C#), etc.

DrMcCoy:
You even miss Jon Blow's point: he was actually talking about replacing the whole language doing the grunt work, not just the game logic...

In fact, I think we should rather go the other way: we should start decreasing all this cruft of useless abstractions we build up and think about programing closer to the bare metal again, think about efficiency.

I think you're the one missing the point. It is this: the whole reason developers end up feeling they have to use different, slower languages for game logic is because it's such a pain to write C++, when if a language were made that didn't have to be as general purpose as C++ it could be just as nice to use as a scripting language without sacrificing the ability to write closer to the metal (as game engine programmers, including Jon Blow, already have to do constantly) for high performance.

OK, now I see where you're coming from. Having watched the first few minutes of the Jonathan Blow video, I see that the "C fixation" in this article is part of the source.

So my critique is somewhat shifted from you (Shamus) to John Blow.

I'm not up to date on his other games, but I've played Braid, fantastic game, yet completely overkill to code it in C++. There is no reason not to shift from C/C++ to something like Java, C# or Python for an indie-game like Braid. I wonder why he doesn't just take the leap instead of talking 2 hours about how we need a new programming language.

But maybe I'll be enlightened when I finish watching the whole thing.

I think there's too many programming languages as it is. It would be nice if the premise were true; know C++, make games. But in practice you'll be called on to work in one or more other languages, as well, and aren't likely to have much choice in the matter (unless you're indie).

To me, the real nightmare is web programming. This is the end result of everybody and their kid sister thinking (correctly) that the web needs a better language, and then writing (yet another) one. So now, I still need to know basics like HTML, JavaScript/JScript, CSS, and SQL, so I can debug when necessary. And in addition I need to know one or more of JQuery (not strictly a language but still), Ruby, Php, Python, etc., then there's the various Content Management Systems, and it just goes on and on and on and on.

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.

This seems relevant to the discussion at hand.

image

In my limited game coding experience, C++ is a mixed bag. It still gets used because some of it is exactly what you want to code in. But then a lot of other things aren't.

I have some respect for Jon Blow. Braid was a very unique game. But in my eyes his whole talk loses credibility six minutes into the video when he claims that "there are three reasonable languages... that we could even *think* of switching to... Go, D and Rust".

I'm not very opinionated about programming languages, but, seriously? It sounds like a joke. 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?

Even the best known language "Go" barely makes the top 20 most used programming languages at spot 19. I wonder if he is deliberately trying to be edgy or if these are simply the languages he happened to have contact with.

To me, using these languages as a "thought benchmark" makes no sense at all.

I really have to question why we need another programming language. Game control logic lends itself very well to object orientated paradigms and there are plenty of viable competing object orientated languages already.

Shaders already have their own languages and low-level engines are fine with their C and C++ language updates.

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.

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.

Cid Silverwing:
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.

Tiamat666:

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.

Tiamat666:
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.

[quote="Pyrian" post="6.866719.21673260"]
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.

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

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.

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

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.

CrystalShadow:

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.

wizzy555:

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.

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

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

renegade7:
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.

renegade7:
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.

renegade7:
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:

renegade7:

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.

renegade7:
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.

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

renegade7:
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."

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

He did not see that, thus the article.

Rebles:

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.

Rebles:

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.

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

 

Reply to Thread

Log in or Register to Comment
Have an account? Login below:
With Facebook:Login With Facebook
or
Username:  
Password:  
  
Not registered? To sign up for an account with The Escapist:
Register With Facebook
Register With Facebook
or
Register for a free account here