Johnathan Blow on a Programming Language for Games

There are plenty of ways to get data out of a function other than the return.

 

http://www.learncpp.com/cpp-tutorial/73-passing-arguments-by-reference/

 

My point was that it is not SIMPLE to return two values from a function. Why people always defend obtuse programming languages by saying that programmers are too lazy write the required extra 20 lines of code that is only required once is strange to me. Surely the point of C++ is that people are too lazy to write machine code. Lots of people agree with me otherwise they wouldn't have invented programming languages like Go.

 

Say you have a game with lots of textures. They are all set to the default texture. Then if the game forgets to set a particular texture, no big deal, the game won't crash. Compared with if you set the texture to null.

The default texture could have a function that writes an error message to a log file when it gets used.

To me that is preferable to releasing a game with potential crash bugs in it.

 

I think you mean for game developers. For programmers, you have as much or as little control as you choose. I'm in a WebGL and OpenGL course right now, and the amount of control is slightly overwhelming.

 

Why doesn't Jonathan Blow just use Unity or a game engine? Surely Braid is not that difficult! I've played the first couple of levels and it's just a 2D platform game as far as I can tell??? Also, couldn't Super Meat boy be made in Unity too?

It's not like Minecraft or even Fez which needs a dedicated game engine???

Is it just the price of Unity that is too high for independent game devs? Or do they just like to suffer? Or is it too mainstream for hipster coders?

 

I think this answer may differ person to person. Whatever the case is you better be a good damn developer if you want to write things from scratch.

I know in certain cases some of these talented developers have a certain attitude or ego that basically makes them feel little to use a platform like Unity, instead they opt to build their own thing for pride's sake. Others just decide to build their own thing because they would rather be more flexible than stick to a specific workflow. Whatever the case is talent is required to get it done, and whether these guys are one way or another there's one thing for sure, they're all very talented developers.

 

I understand that attitude because I used to like to do everything from scratch. Like half the fun was making the sprite engine or 3D engine or physics or whatever. And the game engines at the time were a bit limited.

Maybe if they were to redo these games today they might use a game engine as there have been improvements in them since those times (probably even due to the success of those indie games!)

 

There are advantages to building your own solution from scratch. Having complete control over your code can be nice if you want to do something a certain way.

Also while Unity may support a lot of platforms, properly written C++ with SDL can support even more.

 

Here's what Tommy Refenes says about working with an engine when he was asked about it:

I feel when this question is asked, its being asked by people that assume there is a magical tool that makes games for you. Fact of the matter is there are tools that do a bunch of the engine stuff for you. If you aren’t interested in learning a programming language for the purposes of building a game engine look at something like Unity or UDK. They take the heavy lifting away from you and allow you to just create a game. There is a cost to this though. You are limited by the system presented to you with those tools. These tools are full of features that are well built, stable, and amazing, but sometimes they will not do what you want.

Personally I don’t like limitations and I really enjoy having my hands deep in the development so I avoid these tools and build my games from code I’ve written over the years. That’s not to say Super Meat Boy couldn’t exist in something like Unity. It could to an extent. Due to the limitations though it would not be the same game, it would not control the same, and it would not look the same. The essence would be there, but the game as we know it would not be. It’s up to you though. Again, it’s what you are comfortable with. Amazing games are made with UDK, Unity and the like...and amazing games are made without them.

http://supermeatboy.com/author/tommy/

The problem is not many can do proper C++ with SDL (I'm in that category despite having a lot of programming experience).

 

It sounds harder than it actually is. Most aspects of your game that will be platform specific are handled by SDL. It even has custom data types that allow you to always have specifically the number of bits you need (normal C++ int varies based on whether the platform is 32- or 64-bits, but int32 is always 32-bit).

 

Having made games from scratch and in game engines, I think that many of the differences are in the mind of the programmer rather than actual differences. If you can get the same pixels turning different colours in a game engine as you can writing it from scratch there is no real difference.

I think a 3D based engine like Unity, I would struggle getting pixel alignment right for 2D games but that may be because I don't know enough about Unity for how to do that.

Another issue would be optimising. Which might take you as much time trying to learn how Unity's inner workings loads things as doing it yourself. For example, trying to work out why a scene is loading so slowly.

It's just that Braid seems such a simple game from what I've seen it would be an ideal one to use a game engine!

 

I'l pretty sure that's not a good example since it'll keep chugging along just fine without textures. Either way the result was probably based on what you assigned it to be, so there's no reason why you couldn't assign it a default value instead of a null.

You know, taken out of context, I kind of sound like an asshole. Although in context where I said 'if C++ wasn't such a pain in the ass to set up' from within the same sentence that I was quoted in, I'm not too sure that was how it sounded.

It's not like there aren't half a dozen different ways to get around needing to return a tuple though, so whatever.

 

Wait wait, Unity GC is different from UE4 GC. Unreal one's not general purpose, it's actually gazillions faster than Mono GC as it's deeply integrated into the engine and the unreal framework. Mono's GC is unpredictable, UE4 one's not. You also have 100% control of your memory in UE4. Besides, I've never run into a major problem with my projects in Unity as I always design them around limitations.

 

He's a bad example since meatboy failed hard repeatedly when played at under a 60fps framerate. It wasn't framerate independent at all. Had he used something like Unity, which would have been easier, it would have been cross platform by default, had no downsides and most likely would have run just fine across multiple platforms. At least he would have known what deltaTime was.

I'm getting bored of developers with a couple of indie titles under their belts trying to sway the industry with big talk. If I'm going to listen to someone talk shop, it's probably going to be a big player like Carmack, or someone who changed the industry for the better. I'd pay good money to sit down with Jim Blinn for example.

Its the quiet unsung heroes that you need to listen to the most, people who just get on with it and have contributed so much to our profession. Then there's old heroes like Jeff Minter, Sid Meier and David Braben, people I've met and greatly admire if only briefly.

They don't talk all big and loud, and when they do, it makes a lot of sense.

 

That just sounds like a steaming pile to me. So even if I made an exact duplicate of super mario in unity and ran an emulator on the same computer using the same input, the unity game would be nothing like mario on the nes because it doesn't have it's soul.

Little known fact, the souls of nes cartridges were born when Shigeru Miyamoto lightly blows into each one before packaging. So blowing into old cartridges is in fact rekindling the life Miyamoto first birthed.

 

Which is true in more ways than you think. The C way of returning things was, I believe, derived from how to make things easiest for compilers and CPUs (much like the rest of the C language). Sometimes* - especially in lower level languages - it's well worth making the programmer look after some things for themselves because doing that makes sure they're aware of what's actually happening under the hood.

Plus, is it really as complicated as you imply? Here's a Unity ray cast:

Code (csharp):

1.  
2. Ray r = new Ray(blah);
3. RaycastHit hitInfo = new RaycastHit();
4. bool didHit = Physics.Raycast(r, out hitInfo, blah);
5.  

Check it out - two different bits of data being returned with one extra line and one extra keyword.

* Not all the time. For instance, in some cases a language might be designed for use cases where it genuinely doesn't matter, is counter to design, or where the runtime is so far from the metal that it's noit going to make a practical difference in any case.

 

Another programming language? Aren't we already have plenty of them?

 

Well if you want to return multiple values from a function then you either return a bunch of data like RaycastHit, or you pass some values by ref, and these will get modified by the function, then you can essentially pass as much as you like.

ReturnSomeNonsense(ref a, ref b);
print(a + b);

etc

 

Braid was done before Unity supported the Xbox. But I imagine the motivation is because Blow is several years into developing The Witness, which is 3d first person, probably has a codebase many times larger than Braid, and is longing for ways to improve productivity.

 

I have experienced some prejudice in fact from hipster-gamers as in "That's not a real game, that was made in Unity!" or "You're just some kid whose learned how to make games in Unity!" (as if that's an insult!) Usually these insults are from non-programmers so I don't take them seriously. But it's kind of a strange attitude. Maybe because they teach Unity at some colleges it is not considered cool. Would they say the same about people using the Doom engine? "That's not a real game that's a Doom mod" perhaps. Luckily I don't target my apps at hipster-gamers. The general public seem to appreciate Unity made games.

 

@hippocoder and @RockoDyne, not saying I agree with what he's saying, I'm just reiterating the attitude of such developers.

 

Say you have a variable "price". Set it to zero initially, and the program won't crash if you forget to set it later! (Of course, your customers might get free products instead...)

The problem with having defaults like that is that exceptions are *supposed* to halt everything, rather than let the system get into a bad state. Trying to eliminate exceptions is trying to eliminate the wrong problem. They aren't there to make coding hard. They're there to prevent your program from doing stupid things. If you get exceptions, you haven't written safe enough code.

Back to the game example, having defaults for everything could mean that your game passes testing with *tons* of bugs that make the game unplayable in certain situations where those defaults weren't good enough. Sure, it doesn't crash, but it doesn't *work* either. It's better to have that sloppy coding exposed for what it is than to hide it.

 

Absolutely. I often write code during development with the explicit purpose of stopping the program and telling me the invalid state I was heading towards and how I got there.

For instance, lets say I miss a component when setting up a player character. Then I press, say, the "use" button in my game.

Oh snap, my game halted! But wait a second, I'm going to fix it right now, and I know exactly what it is and how to fix it and it'll take about 10 seconds. How is that not a win?

Also, when working with other people, it's way more useful for them to say "It crashed with this message" than to just say "Hey dude, it started doing weird stuff, and I can't open doors any more". If they've a little initiative they can probably even fix it themselves, in fact.

If using exceptions doesn't make your overall project more efficient then you're not using them as effectively as you could be.

 

One useful thing that came out of this thread is I took a deeper look at Go for my server side backend and found it perfect for my needs. I was using Python which was great but concurrency was a little wonky whereas with Go it is a breeze. Doing lots of actor simulation on the server side things were already starting to get a bit slow and the equivalent functions in Go just blow it away. Really a great language for systems type stuff if you don't need a front end written in it.

 

I started learning Go and it starts off all nice and simple and "pure" but then it get's itself in a muddle owing to the fact that it's notation doesn't quite work in certain circumstances and so it adds on all these special cases and becomes actually more complicated than the languages it was supposed to simplify!

I think probably the simplest languages I've seen so far have been BASIC (as in the old style 10 PRINT "HELLO"; 20 GOTO 10) and Javascript. Once types and objects enter the picture most languages trip themselves up. Perhaps there is a theorem that any type based language can never be complete and will continually bloat forever. Much like when a language can refer to itself you can construct infinite embedded sentences: "He said that she said that he said that....."

 

What notation doesn't work?

 

Reading this thread makes me dizzy

Every language and every game engine got its good and bad days because they were built for different reasons. Some are meant to be high-level while others are low-level. Sure, some stuff are poorly designed or doesn't follow standards and suffer from that but poorly performing programs are typically the result of a poor program. He either didn't understand the language well enough or didn't understand that this was the wrong language for the job.

C++ is an example of a wonderful, powerful language but it can sometimes be like removing a hornets nest with nukes. That is why I like Unity and C#, they make life really simple for me when working on a prototype but I can never hope to use that combo optimize a game the same way I would be able to do with C++ and UE4 (unless Unity share some source code with me)... but do I need that level of optimization all the time? Especially if I can finish my game faster with Unity and C# and still get a smooth, high frame-rate? Right tools for the right job... there are also more languages and engines out there

Jonathan Blow wanted a dedicated game programming language... I can't at the moment see the need for one... I haven't met a need that couldn't be easily solved with one of the existing languages that I know. It is typically my own fault when I run into a wall My biggest wish these days would be that some one sorted out the on-going shader mess in the industry... but that is mostly a hardware issue.

 

I get the feeling you may have misinterpreted his idea. It wasn't about making a language for games so much as making a language for game programmers. The point isn't to solve a problem, but to reduce the amount of time spent on less than important tasks. Most of what he talks about is making memory management cleaner and trying to get away from having to deal so much with data sanitation.

 

It seems from what he's saying is that he's not using the object orientated capabilities of C++. More like using it like C. Trying to make all his own data structures instead of using the standard libraries like STL. In my experience anyone who proclaims "I'm a REALLLY good programmer" is probably not really a good programmer!

 

He's not the best by far, but he's not claiming to be. He's stating things as he sees them, speaking from the experience of having released his own games and working on a very large one at the moment.

Hubris is no indicator of ability.

 

He did claim to be in Indie Game the Movie. But all programmers tend to think they're geniuses when they first learn programming. I know I did!


"I'm Invincible!" The hubris of the self taught programmer.
Still it's interesting to hear from game programmers and how they actually work rather than how they "should" work according to the people who make the computer languages.

He's a good business man though. I hear he's rich now.

 

How is writing your own data structures evidence of not being a good programmer? Or avoidance of OO? Yes, those things can be silly in some cases, in others they're perfectly valid and might even actually be important.

 

he made a follow-up talk.

 

In non-game programming, with the exception of embedded programming, not using the existing tested and optimized data structures is generally considered foolish.

In game engine programming (and embedded!) it's generally the opposite, where you really might save a little CPU by doing it the most optimal way at the risk of having some bugs or spending more programmer hours no it. It all depends on what world you come from.

Engines like Unity have changed things a bit, and they're treated more like generic application programming, where using someone else's code is probably the best choice for any common situation. I'm not surprised that Unity programmers feel the same as application programmers. (And for games that don't push the limits, I agree with them.)

To be honest, I don't think anything that Blow has done comes close to pushing any limits. He's definitely not Carmack, and Braid and Witness aren't Quake. Witness could have been done in Unity a lot easier, IMO.

Blow's insistence that GC is the devil is slightly out of scale with reality. It's bad, but it can be managed effectively enough, as many developers have already shown with Unity. It could be done better. GC-hinting would help a lot. (Player's in the menu or a dialogue? Let that garbage be recycled! They're in the middle of a big fight? Keep that garbage around for a while!) While you can currently force it to happen, you can't force it *not* to, and you can't do it over time, only all at once. (From what I know, anyhow.)

Having said all that, I think his ideas for improvements would improve *all* programming, and not just gamedev. It's not that he's wrong, just that it's not as necessary as he thinks.

 

Blow has a habit of talking in absolutes, which makes his stuff very hard to watch for anyone with experience. His talk about smaller functions and inlining was driving me up a wall until he got to Carmack's quote which is a lot more loose than his rant. Now that I know where he was coming from, I can understand why he's saying these things, but he's far too absolute about it still. I think people would be able to tolerate his other idiosyncrasies if he'd calm that down a bit.

 

I don't think there was anything in Braid that needed very much optimisation in the first place. Was there? Certainly not in terms of graphics: a few sprites and a background. Maybe in terms of recording the movements of everything. But I'm sure the XBox could cope with any of that even with managed code. It wasn't like Doom or Quake trying to make a 3D game on very low hardware.
Maybe I've missed something.

 

That was my point, yes.

 

The GC is being tamed, but it's not like it's being done particularly cleanly. Most of it is just people descending into C++ style memory management where they call for blocks of memory and trash it once done. I wouldn't argue that the GC needs to go. I would be more interesting in it as a debugger or used in some kind of opt-in manner.

As for the more recent video, he kind of lost me with lambdas. Can't disagree too much with the development cycle ideas though. I can't remember if that wasn't just how I was taught. I'm pretty sure the 'factor larger functions into smaller ones' came with the caveat of 'only if it's valid and valuable anywhere else.'

 

There are some who argue that it's better to make smaller functions to keep everything tidy and easier to manage mentally. If a function does 3 distinct things, separate it out into 3 properly-named functions and it's a *lot* easier to read that function now, and it's easier to read each of the smaller functions, too. I agree with Carmack's "keep it in sequence" statement, but that could also mean just keeping the 3 functions in order in the source code.

In general, I rarely end up doing that, but I've done it when it makes the code easier to digest mentally.

In the article he references, his fellow programmer splits things out when they're done twice. I generally don't do it until it's used 3 times, because by then I have enough information to know how it's going to be used in different situations and how generic the function needs to be. I end up doing a lot less work that way.

He did spend a long time on lambdas for some reason. I think he spends a lot of time inlining and then un-inlining code, and it bothers him that the syntax is different more than it would most people. In fact, I haven't managed to finish the new one yet because it got really boring halfway through. I'll head back in in a bit for the rest.

 

I don't think C++ is "the end" as far as engine programming goes. I'm old enough to remember when everyone was saying that "real programmers" would never switch to C++ because it was too slow compared to straight C, and even knew some people who were old enough back then to remember when everyone was saying "real programmers" wouldn't switch to C because it was too slow compared to assembly. As hardware and OS's get more advanced, the old performance bottlenecks stop being bottlenecks and the need for more maintainable code and faster development time outweighs the desire to get your bits to move slightly faster than someone else's bits.

IMHO, the biggest change that will take place in the next generation is concurrent programming. We're eventually going to hit the limits of Moore's law, and already most hardware is starting to rely on multiple processors instead of one big processor, so algorithms and languages are going to have to evolve to allow easy and optimized massive concurrency, something that C++ is pretty terrible at. After that, who knows, we may end up with quantum processors, which will require new algorithms using a whole new mathematical categorization of optimization, and new languages to easily support quantum concurrency, something which would be extremely painful and slow in C++.

 

I'm not particularly old, and *I* remember people saying things like that. And while I saw their points, they completely disregarded how complicated things get as games get more and more complex. It's simply not possible to write a modern AAA game in Assembly due to economic factors.

In fact, I think we are quickly approaching a time when it's going to require higher-level languages to be competitive.

I agree that a focus on multiple processing cores is the future. To a limited extent, we're already doing that with GPUs and such, but CPUs really need to step into that game, too.

One bright point there is that being forced to use new technology often gives birth to new genres, so we might see new types of games come forth because of it.

 

Naughty Dog optimizes Uncharted and Co. in assembler code. One reason why they can achieve so high quality on an old hardware. (Optimizing SPU management etc)

 

Optimizes, sure. But not write the whole thing in it.