“Experts and beginners both want to use the same tools. Children want to learn saxophone, not kazoo.” - Rich Hickey

I want to preorder this. I never do that, but i want this to be financially viable game

Love it. First heard Jonathan speak at a festival in Nottingham in 2008. Always great to hear his thoughts on design and programming.

"Get rect simp" went totally over Jonathans head, while us kids around  Wookash's age are like... giggling over here in the corner.

wookash is good. he patiently waited for an hour, then gently snuck the question in: "when will it be released?"

Now this is what i have been waiting for!

2:30:35 Tsoding mentioned let's go!!!!

Logline Timestamps
- 0:00 — Introduction and game design opening remarks
- 0:49 — Jonathan Blow returns for second podcast appearance
- 1:06 — Context about Sean Barrett's five-hour previous interview
- 1:36 — Decade-long development of Order of the Sinking Star and original short game plan
- 2:25 — Secret 20-year game project planned as installment series
- 3:54 — Order of the Sinking Star as four revised games based on existing material
- 7:37 — Team structure evolution and hiring strategy over ten years
- 9:46 — Sean Barrett's contributions to Braid as precedent for collaboration
- 11:31 — Inefficiency of large teams during early game design phase
- 12:10 — Visual art evolution and reaching final art style one year before release
- 13:58 — Sokoban genre history and the original Japanese warehouse keeper game
- 15:30 — Problems with early Sokoban design and unfair puzzle mechanics
- 16:46 — Modern Sokoban design philosophy and rule interaction complexity
- 17:09 — Using Sokoban as template for game mechanics without traditional grinding
- 19:18 — Visual design and technical implementation changes throughout development
- 20:24 — Atmospheric effects and complex rendering techniques for visual depth
- 26:29 — Note on personal shader knowledge and compiler work focus
- 28:04 — Design constraints for readable puzzle game aesthetics across all environments
- 29:14 — Multiple water system iterations and final Fourier transform algorithm
- 31:07 — Grid readability requirements and level design constraints
- 31:54 — Custom game editor demonstration and fast iteration philosophy
- 32:32 — Compiler optimization with LLVM and build time tradeoffs
- 35:43 — Potential future discussion with Chris Latner about language design
- 37:36 — Live editor walkthrough showing level creation and entity placement
- 39:17 — Source control and file management for complex game with thousands of levels
- 40:28 — Vertex painting technique for visual variety and material blending
- 43:03 — Material system example with distressed wood aging effect
- 46:52 — Performance discussion of custom tools versus bloated web software
- 47:31 — Water system implementation combining animation, grid lines, and wave physics
- 49:08 — Per-vertex painting for water grid strength and visual variation control
- 50:52 — Different material systems and energy disruption effects in the game
- 52:06 — Plans for modding tools and community engagement post-launch
- 54:07 — Custom UI system called get_wrecked for cross-platform interface building
- 55:13 — Dependency management problems in modern programming languages
- 58:26 — Module system design with type indicators and avoiding dependency hell
- 1:04:43 — Basic module with memory debugging and configurable allocators
- 1:10:46 — Jai language beta program with approximately 1,000 community members
- 1:11:31 — Post-launch plans for open sourcing compiler and game engine
- 1:14:17 — Deprecating old language features through compile-time metaprogramming
- 1:16:34 — Rewriting operator syntax automatically using compiler plugins
- 1:21:01 — Compile-time code execution and practical metaprogramming examples
- 1:23:57 — Simple compile-time execution with factorial demonstration
- 1:25:59 — Meta program for managing thousands of lines of code changes
- 1:27:14 — Example plugin system showing compiler message handling
- 1:29:06 — Why create a new programming language and pain points in C++
- 1:31:07 — Entity system generation through metaprogramming and reflection
- 1:36:07 — Introspection and type information for editor and serialization
- 1:37:42 — Command registration and automatic console command discovery
- 1:38:45 — Meta program architecture for managing compiler messages and code generation
- 1:40:33 — Alphabetizing generated code for consistency across parallel compilation
- 1:44:38 — Placeholders for generated code with compiler validation
- 1:46:00 — Run-when-all-typed pattern for factoring metaprogramming back into main code
- 1:50:35 — C++ complexity versus Jai's monolithic integrated design approach
- 1:52:55 — Multiple programming languages required for C++ development and configuration
- 1:54:31 — Unix philosophy critique and limitations of component-based systems
- 1:58:56 — Future language evolution and preventing design committee bloat
- 2:01:06 — Maintaining language coherence after open source release
- 2:02:22 — Seeing examples of coherent design that influence future creators
- 2:03:46 — Balancing time between compiler development and game design priorities
- 2:04:59 — Options for language governance and benevolent dictator model
- 2:08:46 — Raphael's contributions to compiler understanding and evolution
- 2:11:09 — Macro system limitations and power compared to Lisp-style macros
- 2:13:47 — Problems with macro-based code generation and debuggability
- 2:18:21 — Order of the Sinking Star Steam wishlist importance for store visibility
- 2:19:31 — Wishlisting mechanics and how Gabe Newell prioritizes store placement
- 2:21:06 — Engine open source philosophy and programmer-centric design goals
- 2:23:07 — Not competing with Unity and Unreal through different design philosophy
- 2:26:51 — Future games after Order of the Sinking Star moving beyond puzzle mechanics
- 2:27:37 — Managing online presence and avoiding selective negative clip amplification
- 2:29:02 — Disabling notifications and email-based communication for focus
- 2:32:42 — Selective beta recruitment and efficiency considerations
- 2:33:26 — Craftsmanship and vision in games like Blueprints and Animal Well
- 2:36:52 — Mobile gaming market structure versus PC and console creative possibilities
- 2:38:59 — Potential for new game genres emerging from unexpected successes

Jon Blow’s the type of guy to spend 10 years making a game just to show his compiler can build it in 1 second

Oh my God. For decades now I have been wondering why the way we build our programs is not written in the same programming language that we are using for our actual program. Of course because I too have had to deal with make files, Visual Studio projects, Qt projects, autoconf, CMake etc. often all in the same project.

Bought the Anniversary bundle of Braid and The Witness on Steam while waiting for this game!

The dev story is as compelling as the game itself! Can't wait to see the final product.

Jon is amazing. Not everything he says is agreeable, but it still holds much value.

2:34:02 that's so real. I was at uni, discussing something about performance oriented code with a lab assistant/graduate and he said "I know Jonathan blow, he blows". Mind you, that guy is in the camp "it's good enough to make profit so it doesn't matter how slow it is"

Happy to see Jonathan here again!

What a bringer of gifts! Thank you Jonathan.

Even if you don’t work in game dev, many of Jon’s points are applicable in other fields and disciplines. Great talk.

Not a game dev or really interested in games (anymore)… but I could listen to JB forever. You’re a very interesting, smart, and probably an awesome dude. Also, we share a lot of the same world views, etc. Keep up the good work.
Cheers from Norway 🇳🇴

Never heard of Mach bands before! Finally I have a word for this phenomena! I love when knowledgeable people drop a bunch of concepts you've never heard of, creating a list of stuff for you to Google and learn about.

Mewgenetics in less than a month! Really hope Jon will manage to release the game in 2026, will be such an amazing year for video games
Also would've been very fun to see Jon and Edmund talk :D

The simple rule for branching in shaders is: you pay the time cost of both branches. Branch 1 executes, then all threads in branch 1 pause while branch 2 executes. If all threads in the subgroup take the same branch there’s no penalty.