What I'm saying is that if you hold a lecture or publish a how-to which others will be watching/reading (and investing, or wasting their time on) then you should -- in my opinion -- at the very least have tried what you're going to show before you do the recording, and have a good plan, and some preparation done. That is, no such thing as "uh, I'm doing this for the first time, you know", or "uh, I don't know why this doesn't work right now".

Sure, I'd prefer a well prepared lecture with only necessary and interesting info as well, but there's room for different formats to coexist. It's a serious time investment from the content creators, they're not doing it to get paid, nor is it forced upon anyone so IMHO they get to decide the terms on which they wish to operate. It's okay that it's not for everybody.

Personally I haven't followed it closely, and I'm seriously disturbed at people learning programming or changing their habits based on Casey's ... opinions.

Do you mean generally speaking from some dude or Casey in particular? Would you care to elaborate?

Discussions about the pros and cons of OOP or standard containers miss the point so spectacularly that it's disappointing to see those arguments rehashed.

Missing the point seems to be the point of online discussion fora :P. It's why I mostly abstain from non-technical discussions, there seem to be a lot of points and everyone is arguing their own. For example, I'm not sure what 'the point' is that you're referring to, I don't have a team :ph34r:.

The point of this series is that people who are _actually_ deep into game or game technology-making rarely have the time or patience or interest to produce learning material. As a result _lots_ of the learning material on the internet are really disconnected from the actual complexity and issues or real quality game development in the field.

Or course Casey is improvising, but with the experience he has, his improvising hold more useful information than the quintillion of unfinished tutorials of the internet. He might be a little extremist in his views (I find so) but it is better to be extreme rather than mild, when 90% the learning material available otherwise are extreme in using techniques that misled a generation of programmers toward writing code and software that are terrible, and techniques that don't scale for advanced game development. This knowledge is genuinely disappearing because young programmers or schools don't feel they need to learn/teach it. But if nobody learns those proper things, what is at the core of programming and computer, we'll be all massively fucked.

It is an amazing gift to the world that those video exists. I hope someday they will get indexed / transcribed in more details.

Personally I haven't followed it closely, and I'm seriously disturbed at people learning programming or changing their habits based on Casey's ... opinions.

Do you mean generally speaking from some dude or Casey in particular? Would you care to elaborate?

It is my personal opinion that Casey's beliefs about what constitute good development practices are almost universally wrong. I do not care to elaborate beyond that, but I would encourage people to reflect on what reasons there are for assigning value to Casey's comments and opinions. Again, if it's just entertainment then by all means, enjoy. I don't begrudge him his video series or work. I just get nervous around the time people think that any particularly loud engineer has all the answers and I certainly don't believe Casey merits that amount of credibility. Take him as what he is - one voice.

I would say the same about e.g. Jon Blow, who is a much more accomplished individual in my view. I would say the same about myself.

I don't think anyone pretended that he detains the unique universal correct knowledge. It doesn't matter if Casey is an idealist elitist who maybe wouldn't function well with a team of newbies. What matter is that the knowledge and techniques he shares goes way beyond the average clueless stackoverflow poster who never made something serious.

The majority of contents in HH aren't "development practices" but discussing technology and issues that are quite universal. The development practice part amount for like a quarter so even if you didn't agree with all of them the rest is worthwhile if you can afford to follow it.

But then I've always fundamentally disagreed with some of Casey Muratori's ideas, such as his 'immediate mode GUI' which I consider an abomination.

In use or writing such a system?

In both. I've used such systems in Python and in C# and the whole concept is awful. It mixes structure and behaviour and presentation in one place, just like it mixes input and output in one place. But it's seductive to some programmers because it lets them stay in their comfort zone where everything is code. Who cares if you* need to recompile to change the layout? Not you, you recompile all the time. Who cares if you eventually end up implementing a caching system for UI elements that basically replicates a 'retained mode' UI in all but name? Not you, you enjoy interesting solutions to problems (that you caused yourself, but hey).

(* the 'hypothetical' you, here)

Continuing the theme of the thread, a similar thing goes for people who hate OOP, like the guy who gained notoriety for popularising the term 'entity systems' by insisting that they were the future for MMOs (they weren't) and that they are fundamentally incompatible with object-oriented coding (they're not). Sure, sometimes you can get faster executing code by focusing on data transformations instead of object interactions. But sometimes (often) you get more maintainable code by focusing on object interactions instead of data transformations. Each has its place, and there's no free lunch - scan back over the last few months of these forums to see how many people are confused about how to construct good, working component-oriented code. People are failing to finish their projects because they're chasing some super cache-coherence pipe dream instead.

For the life of me, I can't figure out what kind of hobby project could anyone be making in which language performance matters.

In the pre-pentium era, you had to use assembler (or really tight C/C++ ) to get console (Nintendo/Sega) performance. But that said, most modern (unperformant) languages are perfectly capable of doing great stuff on modern machines.

For hobby project performance, it usually comes down to *not abusing dynamic memory allocations*.

When Android started out there was a claim that C based NDK greatly reduced opengl draw-call overhead over Java. I decided to benchmark it out of curiosity, and found out that it gave me ~10% perfomance increase. What is 10% to a hobby game, if it means writing mixed code in Java and C?

When doing browser stuff, there were endless conversations about which java-script engine runs faster, when actually, the most demanding part of the game code is how fast your browsers' native DOM and Canvas functions can run. (They are written in C inside the actual browser code).

I would be very surprised if language performance is ever an issue in your *hobby* project.

Selection of language should be a factor of personal preferences and available platform tools.

That said, I personally don't like the new and fashionable untyped scripting languages (like Python) because I don't like chasing runtime errors that a Java/Scala/C(++/#) compiler could have easily caught for me.

For the life of me, I can't figure out what kind of hobby project could anyone be making in which language performance matters.
In the pre-pentium era, you had to use assembler (or really tight C/C++ ) to get console (Nintendo/Sega) performance. But that said, most modern (unperformant) languages are perfectly capable of doing great stuff on modern machines.
For hobby project performance, it usually comes down to *not abusing dynamic memory allocations*.

When Android started out there was a claim that C based NDK greatly reduced opengl draw-call overhead over Java. I decided to benchmark it out of curiosity, and found out that it gave me ~10% perfomance increase. What is 10% to a hobby game, if it means writing mixed code in Java and C?

When doing browser stuff, there were endless conversations about which java-script engine runs faster, when actually, the most demanding part of the game code is how fast your browsers' native DOM and Canvas functions can run. (They are written in C inside the actual browser code).

I would be very surprised if language performance is ever an issue in your *hobby* project.
Selection of language should be a factor of personal preferences and available platform tools.

That said, I personally don't like the new and fashionable untyped scripting languages (like Python) because I don't like chasing runtime errors that a Java/Scala/C(++/#) compiler could have easily caught for me.

Performance matters a lot when you go beyond simple things, doesent matter if its hobby or professional.
Without proper optimizations, like structuring your data to fit in the cacheline, paying attention to alignment, handling memory with care - you will just have less time you can spend in your actual game: Less entities, less physical bodies, less particles, you name it.

I really like the handmade hero series and the way casey teaches things.
Its really good that something of that level is out there, so we will get reminded that knowing and using the underlying system resources is really important.

Without proper optimizations, like structuring your data to fit in the cacheline, paying attention to alignment, handling memory with care - you will just have less time you can spend in your actual game: Less entities, less physical bodies, less particles, you name it.

If this is the game you want to get into, then it pays to have a real background in computer architecture and CPU design. Consider some reading material:

https://www.amazon.com/Computer-Organization-Design-Fifth-Architecture/dp/0124077269

https://www.amazon.com/Inside-Machine-Introduction-Microprocessors-Architecture/dp/1593276680/

Performance matters a lot when you go beyond simple things, doesent matter if its hobby or professional.
Without proper optimizations, like structuring your data to fit in the cacheline, paying attention to alignment, handling memory with care - you will just have less time you can spend in your actual game: Less entities, less physical bodies, less particles, you name it.

I really like the handmade hero series and the way casey teaches things.
Its really good that something of that level is out there, so we will get reminded that knowing and using the underlying system resources is really important.

• I am curious as to what would you define as "beyond simple things?". Especially for a hobby games developer?
• Why do you think that choosing a slow language means that you cannot optimise for performance?

These are not empty questions. There are things to consider when choosing performant languages...

For example C and C++ refactoring tools are nowhere near what you can get for C#, Java, Javascript, and Python.

Just try to compare visual assist (which is a great product) to anything you can get for free for any of the above languages.

I haven't touched assembly language in a long while, but I never encountered any decent toolchain for using it...

That translates to more time writing code, whereas with C# you could spend that time optimising your code to use better data-structures and more advanced threading techniques.

Switching to C++ does not guarantee your game will run faster. It does guarantee that you will spend more time developing each feature. When you have a big budget and infinite man hours that's tolerable. However, if you don't have infinite time (if this is your hobby) then you might end spending time optimizning stuff with very little performance gains instead of working on your game.

You can do a lot of things which are "beyond simple" on today's super powerful machines (and today's super powerful phones). However you should probably define what beyond simple means before you commit to writing it in C. Most probably you will find that you can write it in other languages with processing power to spare.

Even then, you can write your core loops in C and assembler, and write everything else in a higher lever language. A long time ago I made the mistake of writing entire functions in assembly, when all I really needed to do was write 10 lines of assembly code in one for-loop and write the rest in C++. (C++ was considered slow when it came out). That's because said 10 lines executed many times for each game step. However writing the other 100s of lines in assembler took alot more time and barely gave me any gains (because it was not processor intensive to begin with), so it was just time wasted. (I did have alot of fun learning assembly though)

Without proper optimizations, like structuring your data to fit in the cacheline, paying attention to alignment, handling memory with care - you will just have less time you can spend in your actual game.

It's kind of funny, because you obviously mean "less milliseconds every frame to dedicate to graphics/physics/logic/etc".

But the reverse is also true : If you write "everything" from scratch, optimize everything even if you don't know if it's actually needed, and especially refuse to use already mature libraries/middleware("handmade philosophy"), you will have less development time to dedicate to the actual game.

After 2 years of development, what does Handmade Hero has to show for itself?

Just keep in mind most games, and particularly indie games, and probably your game, are not Crysis or Battlefield, and no, they don't need the kind of optimizations those games need.