Jonathan Blow - How to program independent games - CSUA Speech
ฝัง
- เผยแพร่เมื่อ 5 ต.ค. 2024
- 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... check it out if you're interested.
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
Take note: This is hard-earned wisdom.
The bots have invaded our lord and saviour's domain. We must defend.
This guy is solid, and has a finger on the pulse of every shiny-eyed fresh CS grad ready to build their first big new better-then-ever program... with the latest algorithmic arcana and the cleverest metal-tight optimizations... and an array of other ill-prepared habits our academia and early instincts seems to foster. He accurately and logically tears those self-destructive attitudes down in pursuit of a better paradigm he defines fairly well considering time constraints.
I have seen suffering over these issues in every programming organization or group I have worked with since becoming a programmer.
why tf do you speak like that
"It's easy to see benefits of an idea developed for benefit's sake." Quotable.
@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."_
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
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.
This is so awesome. Working on a large project for a year now... wish I watched this before I started.
What a refreshing talk...This is the way to program that I also have found being most effective.... It's a bit like a the commersial I once read for matlab, "if you save 2 days of programming, then it doesn't matter that the calculation takes 10 minutes longer"
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.
"We're going to work on it for another year or 2..." - well, the upper bound was reasonably accurate.
+David Han (handyj443)
The title slide says this talk was done in April 2011. So it was actually almost 5 years before release.
+Nameguy He's talked about that before. At that time (2011-ish) the game was basically done. It was all in crappy programmer art, but the game was there. So all he had to do was hire someone to do the visuals and tweak a few things as needed. There was a point when they decided to seriously upgrade the visuals, which meant hiring more people and pushed the release date back significantly.
+Jeffery Wells I was thinking about that as he mentioned his "cost of life" metric for efficiency: another side effect of moving slow is that the state of the art keeps progressing, meaning by the time you make something perfect, it seems out-of-date. Witness has an interesting polished-but-classic quality to it for that reason, I imagine.
+lordmyrann I think the witness has done alright on that front because it is quite a unique art style
A generalized system is worse than a specific one.. counter-intuitive to most programmers but found out through my own experience that its very true.
Definitely, very few problems map nearly onto a generalized solution
"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.
24:40 "Generalized systems are less self-documenting than specific systems"
That's a pretty good point. It is more concrete by default.
I'm a huge fan of Jonathan Blow, and this is by far his most useful speech imo.
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."_
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.
2011 + 1 year of polishing = 2015, and The Witness is not released yet :)
Hi, I'm here from the future, The Witness shipped and is quite a big success for him :)
@@higgins007 Hi, I'm from a little bit further in the future, and you know we have this virus now that prevented Jon from announcing his new game :)
@@obiwanus Hello from the further, further future! Getting ready and excited for the public beta release of his language Jai while having VERY high expectations for it considering Rust going full speed converting pissed off C++ programmers on their side.
@@meanmole3212 Hello from the even further future. Still no public beta, but the language is looking very good. The future me has tried Rust and ditched it after one year, because of the friction involved and the fear that it's going to become another C++ eventually.
@@obiwanus I'm from an even further further future. Just passing by to say that this comment section branch is hilarious😂
Thank you for this invaluably helpful presentation!
Wow...this was so good.
no modern software would pass the xbox certification lol
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.
Thank you very much for posting this.
thanks for uploading!! I've been looking for this
Please add the subtitles or auto-transcript for those with hearing loss. Thank you!
Nice talk. Thank you Jonathan blow and Berkeley.
Great talk. I think the slides are a while ahead of the audio?
***** Probebly him switching too early :P
@@alexandrefranco3101 Well, it's still off by one slide :/ (At least somewhere around 10:00 to 25:00.)
19:47 GENIUS, thank you Jonathan
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.
24:00 Blow is basically saying, a swiss army knife will never be as good at cutting bread as a bread knife, or as adept for uncorking a wine bottle as a corkscrew.
I think you missed the point. Also, with just a bread knife or with only a corkscrew you`re limited to opening wines or cutting bread, instead eating a half good cutted bread with a not-so-good-opened whine.
Except that's not what he's saying.
six years old, but still applies. Thanks!
9 now!
27:15 he is referring to en.m.wikipedia.org/wiki/The_Mythical_Man-Month
35:30 the truly important part
amazing talk but i wish auido quality was better
Just to be clear, when he says arrays of records he means arrays of structs? I’ve never heard the term record before.
Yeah.
Records was a common term in programming language theory back in the day, especially in languages like Pascal
Im having trouble differentiating between refactoring and optimization here... In most times refactoring made optimizing my life better
Thank you very much!
i wish this had auto generated subtitles. a bit hard to hear some of his words
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?
17:30 "Operational wisdom"... exactly.
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.
Haha I wonder whether he ever apologized to John Romero.
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.
Right? ... Right? ... Right?? Yeah!
"This isn't fooling anyone anymore" ... wish this were true :{
Don't agree with many of the suggestions, but still a worthwhile watch for any aspiring game developers
Right!
I know, right?
This was a great talk!
1:00:10 how jon programs in c++
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.
i can do that 3250 lines of code in a week
im honestly curious, how do you pull that off?
superknife24
ctrl-c
ctrl-v ctrl-v ctrl-v ctrl-v ctrl-v....
i remember like one year ago, i could write 1000-2000 lines of code a week, i mean its really not that hard !
It all depends on what you are writing. In some cases you are choked by the complexity of what you are trying to make and other times you are choked by the speed of your fingers.
Limited life resource parameter.
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.
56:15 nice stuff
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.
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).
Wow
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
18:10 they are fast,
I would have to disagree with what Blow said at 33:10, that not admitting personal mistakes is human nature. I'd say that is prevalently cultural garbage dragged from certain tribes back in yesteryear an individual convincing the tribe about an accorded action(hunting a specific gazelle), then being wrong(choosing the fast one) and being punished(as it was the cultural habit in such tribe.) Today, western cultures unfortunately tend to demean mistakes as well, rather than create testbeds so that people can sand-box ideas into potentially great products, but risking also failure and certain level of harm. Hopefully that is changing.
Like who uses bst?s. Oh cs professor's. Simple is usually better. Easier to debug.
I like simple c++ :D.
So, what you're saying is that you like C?
KISS - Keep It Simple Stupid
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.
8:27 ... Or 3 lmao
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....
@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
Bit too complex for me, I don't code
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.
2300 lines of code per year? Industry standard? What is he talking about? 2k lines a day is more like it.
photoallergic he said it was most likely due to bureaucratic numbers due to people not being productive.
2k lines a day? Don't lie to yourself.
Only 2300 lines a day? So lazy. It should be at least 10000 lines a day.
33:30 _stomach rumbles_ ~Jonathan Blow, 2011