When I first started to watch the stream (I began with the C introduction videos) I immediately noticed that Casey seemed to be what I feel is the norm for most game developers: low level C guys who pretty much hate abstractions and love to optimize things to the metal.
I have to admit that I though about giving up on the streams because of all the hatred he had for such things. At almost every video, he made sure to dismiss everything that make high level languages what they are, by saying why he hated every feature and that he was not in control of everything.
I started liking the stream a lot more after watching the later refactoring videos though, and after so many comments about API design and how APIs should be simple and developer friendly, I just can't believe how someone can like to fiddle with such low level, mundane operations.
I mean... just to get the contents of a file, one needs to call a bunch of functions each with half a dozen parameters, manually alocate memory for the file, and handle failures with deep nested if/else statements testing integer values against some undescript,untyped defines.
At the same time, in C# for example, I can read a file by simply calling File.ReadAllText or File.ReadBytes or something similar and it gives a nice lenght checked, automatically allocated array with the contents.
My question is how can someone who likes good and simple api design so much hate a language with such a clean api an syntax?
And I'm not even going about delegates/events, or iterators and yield, or async await, and many other features that would be almost impossible to implement and maintain in C.
So.... why all the hate? Have any of you guys ever used C#? Perhaps the hatred only exists for C++ and not for all other languages? Do you think a game like Bastion is a poor underperforming game (it was written in XNA using C# and later ported to iOS and Android using Xamarin)?
I feel sometimes that people are just reluctant to learn new things and use new tools... everytime I see Casey have to go to MSDN to look up parameter types and order for some function, a I remember he has VS2013 with some crazy intellisense suport right there, but insists in using command line tools and rudimentary text editors like Emacs it really makes me feel a bit sad for the industry at large, because I figure this is standard behavior for almost all game devs. In my opinion (and I'm not really trying to offend people here really) they are living in a cave and don't want to go outside.
I have to admit that I though about giving up on the streams because of all the hatred he had for such things. At almost every video, he made sure to dismiss everything that make high level languages what they are, by saying why he hated every feature and that he was not in control of everything.
I started liking the stream a lot more after watching the later refactoring videos though, and after so many comments about API design and how APIs should be simple and developer friendly, I just can't believe how someone can like to fiddle with such low level, mundane operations.
I mean... just to get the contents of a file, one needs to call a bunch of functions each with half a dozen parameters, manually alocate memory for the file, and handle failures with deep nested if/else statements testing integer values against some undescript,untyped defines.
At the same time, in C# for example, I can read a file by simply calling File.ReadAllText or File.ReadBytes or something similar and it gives a nice lenght checked, automatically allocated array with the contents.
My question is how can someone who likes good and simple api design so much hate a language with such a clean api an syntax?
And I'm not even going about delegates/events, or iterators and yield, or async await, and many other features that would be almost impossible to implement and maintain in C.
So.... why all the hate? Have any of you guys ever used C#? Perhaps the hatred only exists for C++ and not for all other languages? Do you think a game like Bastion is a poor underperforming game (it was written in XNA using C# and later ported to iOS and Android using Xamarin)?
I feel sometimes that people are just reluctant to learn new things and use new tools... everytime I see Casey have to go to MSDN to look up parameter types and order for some function, a I remember he has VS2013 with some crazy intellisense suport right there, but insists in using command line tools and rudimentary text editors like Emacs it really makes me feel a bit sad for the industry at large, because I figure this is standard behavior for almost all game devs. In my opinion (and I'm not really trying to offend people here really) they are living in a cave and don't want to go outside.
I don't presume to speak for Casey, but here's my 2c.
True, in C#, it's one line to read a file. It's also one line in C once the function has been written, and you only have to write that function once. What has the C programmer gained? They will have learned more about what is going on under the cover.
The overwhelming trend in game development is to alternate hard and soft layers. High-level languages have been a standard game development tool since at least the days of the Infocom Z-machine (probably one of the first "game engines", if not the first).
AGI/SCI, INF, QuakeC, Edith... there's a long and noble history of high-level languages there. The main change in the modern era is that off-the-shelf scripting languages like Lua (and, yes, C#) are a realistic possibility now.
While Handmade Hero probably won't have a full soft layer (because that's not really the point of the project), what Casey has done so far is the hard layer. As he rightly pointed out int he video, we haven't actually done any game programming yet; the platform API is, in a deep sense, the virtual machine on which the game will be written.
Do I think Bastion is an underperforming game? No, not at all. But don't forget that a lot of the performance is in the C# runtime and XNA. They are what allow you to deploy the same game to the XBox and to Windows Phone.
If you have an idea for a game and want to get it out there as quickly as possible, then by all means knock yourself out. That's a worthy thing; more decent working games in the world is great and I'm all for it. I'll happily buy it if it's the sort of game I like. But that's not what we're doing here. This game is handmade.
True, in C#, it's one line to read a file. It's also one line in C once the function has been written, and you only have to write that function once. What has the C programmer gained? They will have learned more about what is going on under the cover.
The overwhelming trend in game development is to alternate hard and soft layers. High-level languages have been a standard game development tool since at least the days of the Infocom Z-machine (probably one of the first "game engines", if not the first).
AGI/SCI, INF, QuakeC, Edith... there's a long and noble history of high-level languages there. The main change in the modern era is that off-the-shelf scripting languages like Lua (and, yes, C#) are a realistic possibility now.
While Handmade Hero probably won't have a full soft layer (because that's not really the point of the project), what Casey has done so far is the hard layer. As he rightly pointed out int he video, we haven't actually done any game programming yet; the platform API is, in a deep sense, the virtual machine on which the game will be written.
Do I think Bastion is an underperforming game? No, not at all. But don't forget that a lot of the performance is in the C# runtime and XNA. They are what allow you to deploy the same game to the XBox and to Windows Phone.
If you have an idea for a game and want to get it out there as quickly as possible, then by all means knock yourself out. That's a worthy thing; more decent working games in the world is great and I'm all for it. I'll happily buy it if it's the sort of game I like. But that's not what we're doing here. This game is handmade.
Personally I don't see Casey's attitude as hateful, but rather nostalgic. Like the teaser promo - there used to be a time when this was the only possibility and it spawned a generation of master coders with full understanding of low level programming.
Now that there are high level environments like Unity, everything just works like magic. Nowadays there are more games being created every year then ever before and a lot of them have better graphics and audio than the AAA games of the late 90's.
I think that the point of this series, is to fill some gaps for education wise. Even if we would use C# or even a ready made engine after this series, we would understand much more of the magic under the hood, and this will help us generate better games / code. Maybe even some of the followers will use this knowledge to develop a new engine, or low level innovative methodology.
If there's any "hate" that I sense from old school game developers, it's towards the new era of social gaming assembly lines. It was only made possible through the commoditization of game making that allows game producers to use large teams of minimum wage game developers in 3rd world countries to create a zillion games where the only innovation is in the analytics and the only optimization is in the in-app-purchases.
In conclusion:
Control, control, you must learn control
Now that there are high level environments like Unity, everything just works like magic. Nowadays there are more games being created every year then ever before and a lot of them have better graphics and audio than the AAA games of the late 90's.
I think that the point of this series, is to fill some gaps for education wise. Even if we would use C# or even a ready made engine after this series, we would understand much more of the magic under the hood, and this will help us generate better games / code. Maybe even some of the followers will use this knowledge to develop a new engine, or low level innovative methodology.
If there's any "hate" that I sense from old school game developers, it's towards the new era of social gaming assembly lines. It was only made possible through the commoditization of game making that allows game producers to use large teams of minimum wage game developers in 3rd world countries to create a zillion games where the only innovation is in the analytics and the only optimization is in the in-app-purchases.
In conclusion:
Control, control, you must learn control
Edited by Ron Sokolovsky
on
Was the OP directed at me, or at the Handmade Hero viewers in general? I wasn't sure if I was meant to be answering it or not, since it seemed to mostly talk about me in the third person :P
- Casey
- Casey
I think the word "Hate" does not apply here.
I don't presume to speak for anyone, this is my own opinion of what he's doing with the project.
I think his choice of tools is down to personal preference and what he is comfortable using. He wants to rapidly develop the project and this is probably the quickest medium he knows to achieve the goal of the project.
I personally like to use Visual Studio (I use it every day to develop C# ASP.net web app) and with the help of people on this forum I got his project up and running with Visual Studio. I too like the intellisense and I have it setup (colors etc) the way I like. This is a choice you have too, you don't need to do it exactly the way he does.
There is no question that he is capable of developing using some high-level language, but he chooses not to because he likes to have full control, as do many programmers, especially from that era.
There is a whole subset culture of programmers (Demoscene) who thrive to achieve crazy optimisations and tiny file sizes for the fun of it, that cannot be so easily achieved in high-level languages. Check out some 64kb intros(this is the exe size) on youtube. Ok so this doesn't quite apply here, but the reasoning is pretty much the same, optimising and control. You cannot guarantee what the optimiser and compiler will do to your code and more often than not it will bloat a lot of what your trying to achieve.
I believe you shouldn't dismiss tweaking the nuts and bolt, just because a high-level language gives you an easy alternative. There was a time when computing power was not abundant and people were forced to tweak and cheat for better performance. The younger generation of (or new) coders don't have to worry so much about performance and it understandable to wonder about why try to achieve such low-level optimisation. But I think it still does apply today, even with the abundance of powerful computers. When it comes to pumping pixels out on the screen, the better the performance directly translates to a better used experience.
I think you really should stick it out with the project, he clearly is a very knowledgeable fella and you will learn some great stuff off him, even if its just the stuff he points out that he doesn't like about high-level languages :D but I really doubt that's all you would learn.
I don't presume to speak for anyone, this is my own opinion of what he's doing with the project.
I think his choice of tools is down to personal preference and what he is comfortable using. He wants to rapidly develop the project and this is probably the quickest medium he knows to achieve the goal of the project.
I personally like to use Visual Studio (I use it every day to develop C# ASP.net web app) and with the help of people on this forum I got his project up and running with Visual Studio. I too like the intellisense and I have it setup (colors etc) the way I like. This is a choice you have too, you don't need to do it exactly the way he does.
There is no question that he is capable of developing using some high-level language, but he chooses not to because he likes to have full control, as do many programmers, especially from that era.
There is a whole subset culture of programmers (Demoscene) who thrive to achieve crazy optimisations and tiny file sizes for the fun of it, that cannot be so easily achieved in high-level languages. Check out some 64kb intros(this is the exe size) on youtube. Ok so this doesn't quite apply here, but the reasoning is pretty much the same, optimising and control. You cannot guarantee what the optimiser and compiler will do to your code and more often than not it will bloat a lot of what your trying to achieve.
I believe you shouldn't dismiss tweaking the nuts and bolt, just because a high-level language gives you an easy alternative. There was a time when computing power was not abundant and people were forced to tweak and cheat for better performance. The younger generation of (or new) coders don't have to worry so much about performance and it understandable to wonder about why try to achieve such low-level optimisation. But I think it still does apply today, even with the abundance of powerful computers. When it comes to pumping pixels out on the screen, the better the performance directly translates to a better used experience.
I think you really should stick it out with the project, he clearly is a very knowledgeable fella and you will learn some great stuff off him, even if its just the stuff he points out that he doesn't like about high-level languages :D but I really doubt that's all you would learn.
I think its more a matter of style, rather than hate or despise for Higher level Languages. Some game developers like to keep everything to bare bones minimal which makes sense if you want a really responsive and high performance experience from your game. Of course if you are making a Pick and click game, I am sure Casey would recommend you to use Flash or HTML instead (note:just speculating here). I have watched the prequel series and I loved every bit of it. I found it highly informative and made me think about my code in a different light.
I hope the OP doesn't hasn't yet given up on watching the series yet and hopefully will be able to overlook style differences and find some value in the series. GL!
I hope the OP doesn't hasn't yet given up on watching the series yet and hopefully will be able to overlook style differences and find some value in the series. GL!
First, I agree you can make perfectly good games with high(er)-level languages. But even then, knowing what goes on under the wraps is a must. Since Handmade Hero is first and foremost a learning resource, it makes sense to use C to explain what is really going on.
Second, why do so many programmers seem to dislike it? I think it's because of the frustration of not knowing what goes on under the wraps. Sometimes it does matter, yet the details are not explained. Sometimes you can check the source code, but that's not always an option.
As for good API design, I don't agree. Like others said, you can make a C function that reads a whole file pretty easily. Your C function will not be a bit different from your C#, except maybe you will have more control over the failure cases.
C does not have object-orientation, but OO rarely makes for very good APIs. Decoupling interfaces from implementations is the thing that's a bit lacking in C (although you *can* do that with C: just make a struct with function pointers).
C simply does not have a very powerful standard library, and it's true there's a lack of good general purpose C libraries (there's GLib, but its design is pretty awful). I'd argue using many libraries is not in the C culture however, precisely because some programmers want the most control possible, and to make the simplest thing that fits their requirements. Sometimes it's a good thing, sometimes not, it really depends.
Second, why do so many programmers seem to dislike it? I think it's because of the frustration of not knowing what goes on under the wraps. Sometimes it does matter, yet the details are not explained. Sometimes you can check the source code, but that's not always an option.
As for good API design, I don't agree. Like others said, you can make a C function that reads a whole file pretty easily. Your C function will not be a bit different from your C#, except maybe you will have more control over the failure cases.
C does not have object-orientation, but OO rarely makes for very good APIs. Decoupling interfaces from implementations is the thing that's a bit lacking in C (although you *can* do that with C: just make a struct with function pointers).
C simply does not have a very powerful standard library, and it's true there's a lack of good general purpose C libraries (there's GLib, but its design is pretty awful). I'd argue using many libraries is not in the C culture however, precisely because some programmers want the most control possible, and to make the simplest thing that fits their requirements. Sometimes it's a good thing, sometimes not, it really depends.
norswap
C simply does not have a very powerful standard library, and it's true there's a lack of good general purpose C libraries (there's GLib, but its design is pretty awful). I'd argue using many libraries is not in the C culture however, precisely because some programmers want the most control possible, and to make the simplest thing that fits their requirements. Sometimes it's a good thing, sometimes not, it really depends.
Seems to me from what I've observed so far that a lot of programmers who are serious about C are like Casey: they have developed their own platform layers and standard library long ago, which they occasionally tweak for performance and newer systems.
Also, in regards to OP, I'm not sure there's really a stereotype of "low level C game programmers" in fact, as far as I'm aware very few game programmers use straight C. Most who work at any sort of low level incorporate some aspects of C++, whichever ones are best for them. And there are plenty who do use C# and flash and other such high level languages. I was in that party until I started watching the streams and realized how inefficient everything I was doing was.
Hate is the wrong word here.
The simple fact is that in higher-level languages you yield control for ease-of-use. If you are pushing the boundaries of what is possible, this trade-off is unacceptable. You cannot in Java, C#, Python, Ruby, Javascript, etc (by their very design) have control over exactly how much memory they use and where it's located. You have very little insight into what machine instructions are going to get executed as a result of a snippet of code. In most sub-fields this is no-big-deal or even viewed as a boon.
In game programming and other fields that need to routinely push the limits of hardware this is a complete non-starter. Other fields include Robotics/AI, Scientific computing (e.g. CERN), and Systems Programming (e.g. Facebook or Google's server backend or classically Operating Systems)
I don't do game programming per-se, but I work in a field with surprisingly similar trade-offs. Honestly, my favorite language is Python. But, it's a non-starter for a lot of things I work on. Thus, I program primarily in C and C++ (sidenote: they are *not* the same language nor is one a strict subset of the other). I'd welcome a better way, but it's not here yet. However, I am watching Rust and D very closely.
The simple fact is that in higher-level languages you yield control for ease-of-use. If you are pushing the boundaries of what is possible, this trade-off is unacceptable. You cannot in Java, C#, Python, Ruby, Javascript, etc (by their very design) have control over exactly how much memory they use and where it's located. You have very little insight into what machine instructions are going to get executed as a result of a snippet of code. In most sub-fields this is no-big-deal or even viewed as a boon.
In game programming and other fields that need to routinely push the limits of hardware this is a complete non-starter. Other fields include Robotics/AI, Scientific computing (e.g. CERN), and Systems Programming (e.g. Facebook or Google's server backend or classically Operating Systems)
I don't do game programming per-se, but I work in a field with surprisingly similar trade-offs. Honestly, my favorite language is Python. But, it's a non-starter for a lot of things I work on. Thus, I program primarily in C and C++ (sidenote: they are *not* the same language nor is one a strict subset of the other). I'd welcome a better way, but it's not here yet. However, I am watching Rust and D very closely.
Edited by ajbonkoski
on
One of the main reasons is imo given in Handmade Hero Day 016.
From 31:10
https://www.youtube.com/watch?v=z...MBU&list=UUaTznQhurW5AaiYPbhEA-KA
But it's faaaaaar from the only reason. All ms crap is like this, vc++ is often a nightmare to install. The community version refused to install, and I have never seen vc++, the plattform sdk, windows update or anything out of ms "just fucking work".
I never have these problems with ANY other software. It's uniquely a problem with ms, that they seem to think it's cool to annoy users. Maybe inaccurate to say, but it always leave me the impression, right or wrong, that ms highlevel devteams are incompetent. Or that they underestimate the mountain of unnecessary frustration comming with using their stuff.
From 31:10
https://www.youtube.com/watch?v=z...MBU&list=UUaTznQhurW5AaiYPbhEA-KA
But it's faaaaaar from the only reason. All ms crap is like this, vc++ is often a nightmare to install. The community version refused to install, and I have never seen vc++, the plattform sdk, windows update or anything out of ms "just fucking work".
I never have these problems with ANY other software. It's uniquely a problem with ms, that they seem to think it's cool to annoy users. Maybe inaccurate to say, but it always leave me the impression, right or wrong, that ms highlevel devteams are incompetent. Or that they underestimate the mountain of unnecessary frustration comming with using their stuff.
Edited by Livet Ersomen Strøm
on
I think no one enjoys allocating memory and guessing how large a variable has to be. But people do enjoy something that is sleek and works with the minimum set of moving parts.
Yes, we would love to have a perfect combination of both. Something that generates programs that are fast, use little memory and work with any hard- and software. You program it by dancing your hands around like Tom Cruise in Minority Report.
Until we have that, some people will have to reach into the guts of computers and manipulate one bit at a time. Other people will use tools that were hopefully created by the first group and make nice things, too.
Also, 25,000 allocations are made for e...eystroke in the Omnibox of Chrome...
Yes, we would love to have a perfect combination of both. Something that generates programs that are fast, use little memory and work with any hard- and software. You program it by dancing your hands around like Tom Cruise in Minority Report.
Until we have that, some people will have to reach into the guts of computers and manipulate one bit at a time. Other people will use tools that were hopefully created by the first group and make nice things, too.
Also, 25,000 allocations are made for e...eystroke in the Omnibox of Chrome...
I've seen that game development has been moving towards higher and higher level languages as time has gone by.
First you couldn't write a game in C, because there was way too much overhead compared to assembly. Then you couldn't write game in C++ because there was too much overhead compared to C (with critical bits written in assembly). Today, it's common for parts of the game be scripted in Lua or something similar. Or you might make the whole game in unity and not write any low-level code yourself at all.
Graphics shaders started off as shader assembly, with c-style shader languages following not much after that, and then you can have higher-level artist tools on top of those, etc.
Things just tend to gravitate to higher abstraction levels.
First you couldn't write a game in C, because there was way too much overhead compared to assembly. Then you couldn't write game in C++ because there was too much overhead compared to C (with critical bits written in assembly). Today, it's common for parts of the game be scripted in Lua or something similar. Or you might make the whole game in unity and not write any low-level code yourself at all.
Graphics shaders started off as shader assembly, with c-style shader languages following not much after that, and then you can have higher-level artist tools on top of those, etc.
Things just tend to gravitate to higher abstraction levels.
C0D3
I hate to bring this topic back up, but one of topic that came up in the Jeff and Casey show was Garage Collection. He brings up good points about why it's bad esp in game development.
An example of a garage that is not suitable for game development
cmuratori
Was the OP directed at me, or at the Handmade Hero viewers in general? I wasn't sure if I was meant to be answering it or not, since it seemed to mostly talk about me in the third person :P
- Casey
Join in the discussion you goofball!