The blog for Jonathan Blow's puzzle game The Witness, with posts on engine tech, shaders, console certification, and the Jai compiler.
HN links it as the home of The Witness and for Blow's game programming posts; commenters also praise the game's art and tree-making posts.
TFA has some good points. I'd go even further on the situation where you quit your job to work on an indie game -- if you ever find yourself doing this, and you've never built a game by yourself before, you'd better have several years of runway.
For many years one of my favorite talks about indie games development was Jonathan Blow's speech at UC Berkeley CSUA (2011) (http://the-witness.net/news/2011/06/how-to-program-independent-games/)
Initially I loved his main message during the talk: "You have to be brutally effective to finish a project in a reasonable amount of time."
But there's a part in the Q&A that later grew to be even more poignant to me:
https://www.youtube.com/watch?v=JjDsP5n2kSM#t=1h13m8s
> Q: You said you worked on many projects before Braid which didn't quite get completed. What was special about Braid which made you complete it?
> A: What was special was it had been a long time since I'd finished anything on my own, and I sat down and decided that "Dammit I'm going to finish something this time". And, "To that end, so I can finish this, I'm gonna make something that is technically pretty simple"...
For some of us, it's REALLY HARD to complete a side-project while working full-time job. For most of my career I had completed a real game only when it was for a job (or for a client) and I worked on it full-time.
The single reason I hadn't made a game as a side project was because I'd quit before I finished. I finally figured out something that worked…
Sometimes rigid code is simpler, sure. But what I am arguing is that it is almost never more debuggable / maintainable.
What I am saying is not specific to test and branch, though test and branch is great because it gives you these big code blocks into which you can insert more code and it's clear where that code lives and under what circumstances it runs. Which is something you don't get in assembly language, which is part of why the assembly language reply is a goofy straw-man argument.
Yes, my reply was a bit irritable; I would definitely prefer to have a reasonable discussion, but the assembly-language thing was the first volley in being unreasonable. Putting up a straw man like that is an attempt to win the argument, not an attempt to understand the other person's position. I detected this and decided, well, if that's the position, then it is useless trying to make further / deeper rational arguments, so I am just going to say, this comes from a lot of experience, so take it or leave it.
As fatbird replied, "This is shitty." (I can't reply to his reply yet because of the timed reply thing, so I am including it here.) Maybe it is shitty, I don't know, but it's true and sometimes you just have to say the true thing to be expedient and get on with life.
I don't have time to teach people on the internet how to program. I work my ass off for 4 years at a time to build and ship games that are critically acclaimed and played by millions of people. These are the kinds of…
I've been enjoying the game too. This quote from Jonathan's development blog more than anything in this New Yorker article has helped me understand his narrative intent with the game:
> "But if you have an eye for detail, you may notice the elements of modern construction shoring up the design of an older structure with a different purpose. The design of the new structure tells you something about what the newer guys were doing there, and how it differs from what the older guys were doing there. And if you look really closely, you can see traces of the original footprint of the site (perhaps these are very subtle, some bricks just rising above the dirt in a few places), and infer the purpose of this very old site too.
> "If you see the different civilizations that came to this island as embodying different philosophies; and you see the structures they built as representative of the way these philosophies led them to interact with the world; and you see further that when they replaced a site, it represents the rejection of some older worldview that they consider no longer useful, then perhaps you start to get some idea of the amount of backstory that can be encoded into the world, nonverbally.
- http://the-witness.net/news/2011/12/architecture-in-the-witness/
They don't necessarily have to, and even if they did, it may not be obvious.
Consider a financial company working to improve prediction algorithms for their in-house use, hiring smartypants PhDs and giving them free reign and great pay. The result after ten years could be way ahead (or even just a little ahead) of the academic world's work and never release a product with a sticker for a big shiny new algorithm.
The firm wouldn't even have to stand out in its success; it could do reasonably well compared to others, and just attribute a lot of its modest success to its algorithmic insights.
Even in externally released products, really clever ways to get around things aren't necessarily visible. Just today I was reading about Jonathan Blow's work [1] on localised kriging [2] for his upcoming game The Witness. He's pulling from advanced geostatics academia for a little feature he wanted in a game, and if he didn't blog about it (and then discuss enhancements in the comments) no one would know it existed - even once the game is released. A small example to be sure, but I think it exemplifies the point.
[1] http://the-witness.net/news/2010/05/kriging-is-cool/
[2] http://en.wikipedia.org/wiki/Kriging
http://the-witness.net/news/2011/06/how-to-program-independent-games/
This was posted on HN recently. Skip to slide 18. In it, the guy talked about premature optimization, curiously, of the same thing: linear iteration over an array vs using a hash implementation.
His example was that in his youth, he was on the Doom forums, and he was doing mods, and took a look at the code that loaded the different asset files. And he was abhorred that the code used an array to linearly iterate over to find the asset to load. He started complaining on the newsgroups, and then Doom guys said you don't know what you're talking about, etc.
In this case, it was where that code just didn't matter in terms of run time, because the order of magnitude difference in looking up an asset and actually loading the asset was huge, and it just didn't matter. And because they used a dumb implementation, they could optimize for developer productivity and go on to code that mattered, like the rendering.
That said, I think the thing to keep in mind is, which parts of your problem space is of the core importance, and keep an eye on difference of order of magnitude in the different solutions you were thinking about implementing
> The funding for underrepresented creators was a condition of my involvement in this project, so doesn't represent his values so much as mine. He was at least willing to do it though, which I'm not sure he would be today.
Interesting, and thanks for the sources. I was under the impression that it was the same fund as that announced in 2010 [1] but the date in [2] plus the apparent timeline does align.
"I'm not sure he would be today" is a strawman and just Hazelden's own current views of Blow, but I doubt there's going to be a direct quote (or even better, a new grant from Thekla) to back it up. But yes, 7 years is a long time and the political landscape has changed "somewhat".
[1] http://the-witness.net/news/2010/03/announcing-indie-fund/
[2] https://www.gamesindustry.biz/the-witness-studio-offering-usd20-000-grants-to-underrepresented-developers