- 1
- 177 451
Alexandre Franco
Portugal
Registrace 23. 05. 2012
Jonathan Blow - How to program independent games - CSUA Speech
Jonathan Blow's speech at the UC Berkeley's Computer Science Undergraduate Association, in the same school he himself went, on April 1, 2011.
the-witness.net/news/ check it out if you're interested.
the-witness.net/news/ check it out if you're interested.
zhlédnutí: 177 467
24:40 "Generalized systems are less self-documenting than specific systems" That's a pretty good point. It is more concrete by default.
Im having trouble differentiating between refactoring and optimization here... In most times refactoring made optimizing my life better
I'm a huge fan of Jonathan Blow, and this is by far his most useful speech imo.
no modern software would pass the xbox certification lol
Wow
thanks for uploading!! I've been looking for this
33:30 _stomach rumbles_ ~Jonathan Blow, 2011
It's interesting to take all this talk about optimization and put it in the context of his presentation where he demonstrates how slow Photoshop is. Well what now? He says here that optimization is (often) bad but now he is pissed that it takes too long for Photoshop to open because it has not been optimized very well.
"How to Program Independent Games"
Photoshop is (likely) pessimized to hell. There's a nice middle ground between pessimization and optimization.
Had that same thought. However, what he advocates for is a simple code. I'm like 99% sure that photoshop isn't it. His main point is that simple actually is fast. I also like "pessimization" where your architecture choices are slow, you (should) know that and you use them extensively anyways.
@4:40 Was Jonathan Blow really this stupid back in 2011? Is he still? Any programmer who is tasked with writing an entire green tech project is going to write tens to hundreds of thousands of lines of code in a year. That doesn't mean you're "more productive", it just means you're doing a different kind of production: green tech. Green tech is when you spew out thousands of lines of shitty code that everyone else gets to maintain in the years to come. The reason the industry average is ~3000 is because people don't work on green tech: they spend most of their time maintaining mature software products, where your time is spent deleting bad code and replacing it with shorter, more concise and more maintainable code (a net negative in "lines written"), or investigating bugs in mature products where you can spend 90% of the time figuring out what is going wrong and end up simply editing a few lines (no new lines written) to fix it.
That's not even the point of the presentation please go touch some grass
3250 lines a year? that is absolutely nothing, even lazy me writes more than that!!! and im barely getting to the keyboard. i bet its true too, that programmers dont even type anything in the industry, cause its a retarded existance.
I like simple c++ :D.
So, what you're saying is that you like C?
can anyone explain why straightforward functions are better than many function calls? i could not follow his explanation
Because you can just read a big straightforward function from top to bottom. But with many small functions, you have to jump around in the code to read them, and the worst of all, you have to remember what they do.
Calls to other functions inside a function turn it into "choose your own adventure book". A straightforward function reads like a normal book. Of course nobody says you must never split a function into subfunctions. It's just that when you have one function that does one thing and no parts of it are needed anywhere else - you should probably just put some comments in there and leave it like that. You typically extract something you copy paste for 3rd-5th time in several different functions.
@@zhulikkulik 2 years later I think I got it based on practice. Thanks
@@dfghj241nice, can you give your insights and some examples of how you learnt?
3250 per YEAR? I write this much every month
That's probably a bad thing, as that code needs to be run, and people need to read it. You should produce fewer lines of code (with more or less the same functionality).
19:47 GENIUS, thank you Jonathan
35:30 the truly important part
1:00:10 how jon programs in c++
Just to be clear, when he says arrays of records he means arrays of structs? I’ve never heard the term record before.
Yeah.
"This isn't fooling anyone anymore" ... wish this were true :{
So I should be looking for CS papers that tell me how to simplify things in order to get them done faster in development. And to concentrate on using the kind of data structures which help me get things done fast and not add complexity costs down the line. Which sounds kind of like some of the agile ideas, YAGNI, etc. where you postpone optimization and other decisions for until you need them while keeping the code simple enough so that it's flexible and cheap to rewrite if necessary.
Limited life resource parameter.
I'm able to do 350 lines per hour, all bugs removed as well. I'd be able to make braid in just 22 12 hour days. It feels great to be intelligent.
@@chyza2012 I finished the entire engine in under a week. I got bored with making the story and doing game design so I went and worked on something else.
@@yellow6297 Denial like this is where your data intellectually goes very off. You are not able to make braid in 22 12 hour days in no reality, because it will in no reality take just 22 12 hour days due to the hundreds of things you have no experience and discipline to overcome.
Like who uses bst?s. Oh cs professor's. Simple is usually better. Easier to debug.
six years old, but still applies. Thanks!
9 now!
i wish this had auto generated subtitles. a bit hard to hear some of his words
Please add the subtitles or auto-transcript for those with hearing loss. Thank you!
27:15 he is referring to en.m.wikipedia.org/wiki/The_Mythical_Man-Month
23:51 research papers. Can't agree more. I'm not an idiot (I like to think) and was recently reading some graph layout papers. Indecipherable. Pseudo code v.bad. Missing chunks of information needed in order to actually get any benefit. basically, most of the time you need to do it yourself, through trial and error.
This is the kind of practical knowledge and wisdom you gain when you make your game from scratch and not use Unity or Unreal. It's your choice. You want to become like him or you just want to sell game.
"just want to sell game" You mean like Braid or Witness?
@@daleowens7695 yea i'd rather sell games.
8:27 ... Or 3 lmao
I will just write notes here for my future self: - Avoid optimization (and wasting time thinking about it). You don't usually need it in most cases. - Use Arrays for everything. Data structures are about optimization. - Don't build generalized systems. They are worse than hard-coded ones. - Deleting code is better than adding code. - Prefer big top-to-bottom straightforward functions, instead of function calls
Thanks
Function calls are clearer than giant functions in my opinion, they make it easier to read blocks of work, without requiring comments. They just need to be scoped, so they aren't accidentally reused or shared between different contexts...
what constitues a generalized system?
Love it but first and second points seem to be in direct conflict
@@dfghj241 im guessing something like unity vs custom game engine
Haha I wonder whether he ever apologized to John Romero.
Huh... did not expect that The Witness only has a few thousands LOC more than Braid. While I realize that the amount of content is mostly just assets, I figured that all the complexities of dealing with a 3D environment would require many more LOC than a 2D game.
Maybe he got smarter and followed his own principles. There more code you remove the better.
30:43 _"If there is some code that is like a 1000 lines long and only does one linear sequence of events, I actually prefer to be a 1000 lines long doing one linear sequence of events."_
KISS - Keep It Simple Stupid
I love this talk. It's interesting that the first point is about how you need to optimize your time coding and to do that you need to not waste time optimizing code. It's sort of an ironic way to make the point that human time is way more important than computer time.
1:03:00 he talks about failing certification on xbox 360 if the framerate is dropping. was it like for xbox live arcade only? cus lots of games are and were dropping frames on consoles so how does it gets certified lol pubg is literary payed for by microsoft and runs and looks and plays like shit
The readability is the key problem of generic systems, OOP and all kinds of frameworks. The more layers of generic nonsense that a system has, and the more "magic symbols" it needs the programmer to learn in order to actually understand the code, the worse it is. We are now living through a period of new frameworks popping up every month that is supposed to make your life easier, but its essentially a waste of time. Spend your time learning the core language and how to do things without a single library, that makes you a good programmer.
I agree with everything he's said here - All of the mistakes he mentioned exactly describe the mind-set of a new programmer. I'm in the business/ERP space but even there (where the computer science and optimisation elements are less important than functional correctness), these rules absolutely apply. These are lessons that are only learnt with experience.
I wonder, if he wants to optimize years of his life per program implementation, why he started on Jai? Isn't this new language of his (an attempt at optimizing C++) taking him too much time already and will take even more than it has already taken? He could probably write a game or two in this timeframe, or just enjoy life, not write anything for a while (there's plenty of other things to do without getting bored). IDK, Jai just sounds like a contradiction to me to what he is saying here. I have to say, I've done a lot of native and web development, just not C++, don't know how bad it is, so maybe I'm wrong and Jonathan will have more life left and games written after having finished Jai, but I'm skeptical.
No doubt making a language that better than C/C++ must also be a fun project on its own. The fact that he is also using it for the next game he is developing, makes it all the better - not only does he make a game, but also the language he wants to write it in.
Actually, he said quality of life was one of his core reasons for making Jai. He gets to spend the rest of his life not stressing over the things in C++ that make him want to tear his hair out. He said when he first got Jai working to a point he could actually use and play with it, he basically breathed a sigh of relief and decided he would never use C++ again for any game after the Witness shipped. Indeed, in his mission statement for Jai, he said that "the joy of programming" was a critical concern in the design of the language.
You don't consider that he may wants to improve the productivity of other game developers in general, so a more altruistic angle, by sacrificing his own time
Watch his presentations on the language if you want to know what he has to say about it....
Almost ship it in a year or two. No not two ... a year! Game releases 5 years later! :P
Wait yeah, why’d it take so long lol
@@tech6hutch 3d is hard
@@tech6hutch because The Witness is a unique game, with unic ideas, art style, level design and puzzles. Blow's games is not a conveyor of shit as most games now
@@nerdError0XF a conveyor of shit! haha awesome
This is so awesome. Working on a large project for a year now... wish I watched this before I started.
I like a lot of this advice because I basically love contrarian advice. There is so much group / herd "thinking" and mindless adherence to certain dogmas that it is almost an ethical duty to go against some of that. That being said, most of this advice is well-known from decades back ("Premature Optimization is the root of all evil" D. Knuth) but it is worthwhile to repeat again and again. One of my faves is actually removing code or accomplishing some functionality without introducing a lot of extraneous staff (libraries, frameworks, etc), much satisfying that adding complexity for the sake of very small efficiencies (the "very marginal benefits" mentioned in the video), or sometimes for the sake of using some design pattern that ultimately changes nothing other than complicate the code. This is something that happen with what I call "junior-seniors" and is a frequent nerd temptation to all of us, including me, of course. And one of everyone's favorites: generic systems, when a "Generalized system is usually worse than a specific one", which somehow seems to be counter-intuitive. There is something deeply human in this however, the desire to feel smart, to somehow come on top of our insecurities and of our peers.
I wish people would advise others to think for themselves, instead of promoting generalizations. It's not "your mileage may vary", it's "your mileage WILL vary" (usually, hopefully)
Actually, you're misusing Knuth's quote. He was talking about low-level optimization, which is rarely done nowadays. What Jonathan is talking about is quite different.
Right? ... Right? ... Right?? Yeah!
i think C++ is _B E A U T I F U L_
I disagree on using arrays instead of other data structures. Using arrays is an optimization(memory). So if you don't care about any optimization a use a linked list or something which has more memory usage etc.
Ok but he's not saying don't optimize, he's saying optimize for years of life required, first. And in his case, because of how he thinks, using arrays broadly is an optimization towards that end and is therefore beneficial.
But most of the stuff he says about optimizations is true. " optimize code is harder to read , harder to maintain .... has more assumptions". In the same vain arrays make assumptions about the data type, number of elements. On the other hand a Python List( because I can't think of one in C++) doesn't make those assumptions. You can just use it without first finding about the number of elements. You can reuse it easily. It's easy to change.
Ah yea I get what you're saying I suppose. Still I don't think he's suggesting that we do that, only saying thats his system. He probably has a mental/library work around for those problems. Arrays do have some issues, but for many the performance benefits far out weigh those negatives.
:) I agree. It's probably because of the domain( games).
No doubt this is more important in games where generally you code around a minimum memory requirement. So there is no need for lists and growing heaps, due to the fact that you know what the maximum length an array should become, and you need to be sure there is in fact memory to allocate this array before actually starting it. Imagine playing a game halfway through and then allocation fails and the game crashes and dies. Accessing an array is also very fast and easy so the code generally is very readable and easy to debug. In JIT type languages a lot of the performance is lost due to a garbage collection going crazy from having to collect all kinds of objects, so if you know how the maximum number of objects you need of a type before hand and just pre-allocate the memory, your code will run way faster and the GC can go to sleep.
Industry average lines of code 3200 per year? What? I write that in a couple of week...
He wrote 75 000 lines in 3 years of making Braid (aside from design, marketing, QA etc.) :) The 3200 are probably a figure like the one from Mythical Man Month. As he said - the average includes a lot of "bureaucratic" roles and projects. And cases like cleaning legacy code, where you actually have a "negative" contribution to lines count.
17:30 "Operational wisdom"... exactly.
@17:50 _"If I think somethings wrong with that they did, but what they did is kind of beyond my capability, maybe I just don't understand why they did what they did."_
"I prefer it to be a thousand lines long doing one linear sequence of events. I don't want to hide that fact!" This made me laugh a lot. Blow is making an important point I think. I used to take pride in shrinking all my functions by making lots of little functions, but you have to recognize when that's unnecessary.
calling a function is expensive. inline code is always faster :)
@@PauloConstantino167not only that. Reading a function that calls 100 other functions is hard because you have to scroll the file up and down all the time and sometimes even switch between the files to figure out what is going on. It's effectively a function call overhead multiplied by the fact that your brain doesn't run at 3,5GHz and doesn't have 16 gibs of ram.