I feel like "simplicity" is often fetishized to the point of counter-productivity.
Show me anything that either Blow or Muratori are doing that couldn't be done in an existing language or framework.
People laugh at games with thousand-case switch statements or if/else chains but they shipped and the end user doesn't care about logarithmic complexity. And most of the time it doesn't even matter. What fails with games more often than not is the design, not the code. What features in Jai make it superior to C++ for writing games specifically? Or does it, like Typescript for JS, only exist because of extreme antipathy towards C++?
Time is a resource too, and arguably a far more valuable one for developers than LOC or memory or what have you.
Right, if you look at say, Blue Prince, one of the most important "out of nowhere" type video game releases of 2025, the actual software engineering is trash. I'd fail code reviews for a lot of what was done, and there are cracks in the façade where a player will hurt themselves as a result - e.g. there's a bug where animations overwrite so you get short changed on the resources you were gathering when you go "too fast". Some of the intended features, especially in the 1.0 release, just don't work for reasons like somebody typo'd a variable name, or they forgot how a function worked.
But the game is amazing and that's what matters. Nobody wants to play six hours of carefully engineering tasteless crap, let alone (as many did with Blue Prince) six weeks. The 1.0 Blue Prince game was already excellent, unless you run into a nasty save corruption bug on PlayStation, whereas a game made Jon's way might be a soulless waste of your life even though perhaps the engineering is "better" in some sense.
The idea you have to pick between reasonable engineering and fun is a false dichotomy. Of course not every game will have the time budget to fix every unintended feature but your example game would have been more enjoyable (especially for the mentioned Playstation users) if the code had been written a bit better.
I think for games like Blue Prince, specifically, it’s not a false dichotomy.
Those are made in tiny teams. You can either spend more time tinkering with the gameplay mechanics and experimenting with the game parts; or you can put on your software engineer hat and make the code better (or, spend even more time to learn how to make the code better in the first place!).
This gets less true with scale of a team, and with 5000 people behemoths you probably should care _a lot_ more about the code; but ROI on improving the code in (relatively! Calling Blue Prince “small” is ridiculous.) small games is very dubious.
Of course programs will be worse when non-programmers are in charge of programming. That doesn't mean they shouldn't but lots of indie game attempts fail because the programmer (educated or not) doesn't have a clue about when to refactor and make sure the design of the system matches the intention of the game. You can only tinker until a certain point, after that you're just creating new bugs by fixing other bugs.
ID software once was a small team and they built complex games by writing tight code which was modular and very clear. Lots of their '3d era' contemporaries failed because their engines were sloppy, complicated, buggy and slow.
A lot of core game logic is presumably Tonda's work. He's a director, not a software engineer. He came into this, many years ago, wondering if the "easy" tools to make a video game meant he could just make the video game he was imagining, and of course the answer is "Yes, but..."
Blue Prince is (an extrapolation of) that first game, but it looks and sounds like competent people worked on it, not like something slapped together by a non-engineer in a week. However while you can hire experts to make "You know, like cool jazz for a mysterious underground area" or "Art that looks thematically like it was sketched, but also feels solid enough that you could lean on it" it's very difficult for software engineers to "just" fix the software to get rid of bugs because what's a bug? Only the puzzle designer knows for sure what they intended.
[[Spoilers! Do not read if you are still playing or might play]]
Is it a bug that "Swimming Trunks" don't let you swim? No! That's a Dad Joke. They're Trunks. Large locked wooden boxes. They're in the swimming pool, and if your pool has water in it, that means they're swimming.
When I picked a time from my near future in Shelter, it didn't work, that's a bug right? Nope. The Shelter cares about game time, not real world time. Make sure you know the date in game.
OK but is it a bug that being in Clock Tower at the Sacred Hour doesn't have any effect? Um, maybe? It seems as though the software doesn't believe clocks repeat, so only the first time will actually work. Or, maybe the second does too? It's hard to say. Try again?
I need food but somehow I keep digging up keys and money. That's a bug right? Nope, probably means you have made a Contraption which changed your dig probabilities.
OK, so that's also why my Door facings are weird even though I put my Compass-based Contraption in a Cloak Room? That one's probably a bug.
Still, "If you draft it quite late" ought to mean my Music Room has the key right? Well, maybe, what did you think "Quite late" meant?
"I thought after a few hours would do it". Huh. Well, maybe. "OK, what about Rank 7?". Rank Nine would be better, but it might be enough, depends. "I still get no key, are you sure this isn't a bug?". The most likely problem is that you've done Music Room. If so the most likely key to wrongly believe you did instead is Vault, although Station is also possible. Check the other locations.
It’s not a false dichotomy imo. If the creator of Blue Prince had concentrated on code quality it’s likely they’d never have shipped. The same would be true for the creator of Undertale.
That's true, a game like Blue Prince doesn't suffer from bad engineering because of the type of game it is. There are plenty of other games, like Cyberpunk 2077, where the lack of engineering made an otherwise good game unplayable and unenjoyable.
The fact remains that Blue Prince would have been more enjoyable for those people who did see those bugs had some time been spent on better engineering.
I think the question is whether Cyberpunk 2077 would ever have been made under the constraints that Blow and Muratori talk about. Like, Order of the Sinking Star looks pretty impressive, but from what I can tell it's basically just a bunch of Sokoban-style games operating on a fixed grid. You don't need anywhere near as complex an engine for that as you do for a game like Cyberpunk 2077.
My impression is that the Blow/Muratori style works well if you're the only person working on a game, or part of a very limited team, which is fair enough, but it naturally limits the scope of what you can achieve.
Having a 3D engine does not a AAA make. The Witness is a beautiful looking game, but the amount of state and interactions it has to deal with is orders of magnitude less than GTA: San Andreas. It is closer to the complexity a Myst remake would have.
It's not a lack of engineering, but a lack of time, no? 5 years later and Cyberpunk runs on the Switch 2, MacBook Air and Linux Gaming Handhelds. While also scaling beautifully to 64 core CPUs or $3000 Nvidia raytracing GPUs.
I'd add Dispatch as a more recent example of this. It's a buggy mess for such a simple game (I encountered multiple game breaking bugs in one play-through) but its reviews are overwhelmingly positive.
I think this is one of the first lessons independent developers quickly learn. I think we're initially geared to want to make beautiful, elegant, and technically pleasant code because it's our thing - it's like how e.g. a guitarist is going to want to play a song other guitarists would be impressed by. You spend a million hours perfecting Classical Gas, while Smoke On The Water goes down as one of the most iconic tracks and riffs in history.
I'm not endorsing slop, but rather advising against the equal but opposite.
>People laugh at games with thousand-case switch statements or if/else chains but they shipped and the end user doesn't care about logarithmic complexity.
This "not caring", from both coder and end user, is why the end user constantly gets buggy, slow, and resource hungry software, be it games, or other kinds.
> People laugh at games with thousand-case switch statements or if/else chains but they shipped and the end user doesn't care about logarithmic complexity.
Both Blow and Muratori would likely advocate for the this type of code to some degree.
I hate C++. It’s possibly my least favorite language. Slow compilation, awful mess of ideas scattered around, syntax soup, footguns galore. Typescript has become one of my favorite languages. It’s not perfect, but it’s surprisingly good and pragmatic. JS, on the other hand? No thanks. Static typing is something I never want to do without again.
I can’t find anything about Casey Muratori or Jon Blow discussing Yandere Simulator.
But even if they did comment on the quality of the code, when they talk about so simplicity they are generally talking about avoiding unnecessary abstractions (usually OOP abstractions), not any of what the OP is talking about.
> What features in Jai make it superior to C++ for writing games specifically?
Some examples that come to mind from my personal experience.
- Compile times. 1-2 seconds vs the typical build times in a C++/Rust game can be a game changer
- Massive compile time capabilities.. you can have an entire content pipeline executed at compile time, all written in Jai
- Builtin Type reflection.. another gamechanger in games for editors and such
- Very easy to debug, the minimalistic approach means the code is not heavily transformed by the compiler thus really easy for a debugger to follow and still performant. Example: loading the same gltf file in my engines in Rust and C++ debug mode is MUCH slower than debug mode in Jai.. again, game changer.. you hit build/run and you're back in the game in few seconds.
- Very easy to learn
- Very ergonomic in its minimalism
- A lot of small things you instantly miss when jumping to other language.. one thing on the top of my head.. the ability to have struct members "overlay" other specific locations.. so you could have a Matrix4 struct with Vector members "forward" "right" "up" etc
- The builtin "context" based "temp allocator".. perfect for games, anything that is needed for a frame goes in there with close to zero allocation time and it gets reset every frame at zero cost
Jai has a HUGE potential if it can survive Mr. Blow's ego.. which is a big big ask.
> What features in Jai make it superior to C++ for writing games specifically?
I know that Jonathan Blow can be abrasive and one-sided in his talks on programming, but I think we should be open-minded about Jai. Yes, he is making this language because he doesn't like C++, but you make it sound like he is hating on C++ just for the sake of it.
I mean, is it really so hard to imagine that someone might not like something about C++? There are plenty of people who think we could have a better systems language, which is why we have seen languages like Rust, Zig, and Odin pop up.
In Blow's case, he has said that he doesn't like Rust because he feels that satisfying the borrow-checker slows down iteration time[1], which is important especially in the early stages of game development when you are still experimenting with mechanics are where requirements and architecture are still very much subject to change.
As far as what Jai offers, it seems his focus is on making a simple but powerful language (contrary to C++'s ever-growing bag-of-tricks), with fast compile times (less than 3 seconds on a full build of his new game), better build and dependency management (no more cmake), and powerful meta-programming features.
In a talk on the language[2], he demos how he is able to use the language's meta-programming features to develop powerful code-analyzing and memory-analyzing tools.
These tools, in particular, hint at his philosophy: lots of ideas in programming like RAII, garbage collectors, and borrow-checking exist to save the programmer from themselves. He's not interested in this and believes that these features come with hidden costs. Instead of accepting those costs, he would rather have a language that gives him the tools to save himself.
Personally, I don't understand the hate. If Jai is a good language, then it will benefit all of us. If it's not, then his making it still hurts none of us.
I feel like a lot of people go after Jai because of what Jon Blow says about XYZ political issue. Jai seems perfectly reasonable for at least the narrow task of making games in an indie studio. The macro capabilities might be terrifying in a large enterprise, but if you're handrolling all your own code and don't have to worry about a software supply chain, who cares?
I go after Jai because I think the problems it is purported to solve are better and more readily solved with existing frameworks, libraries and engines, and I think the programming language itself is entirely too low a level for these things.
You don't need to design a specific language to implement structs of arrays, you can just... do that.
Jai hasn’t even had the whole array of structs to struct of arrays thing in years.
Also speeding up compilation time really does require a new language or at least a new compiler.
And why would you “go after” any language. If you don’t like it, don’t use it. The only thing going after it is going to do is to drive up the engagement metrics and make it more popular.
>And why would you “go after” any language. If you don’t like it, don’t use it.
We are on a discussion forum. One of the common use cases of a discussion forum is criticism and debate. Yes, we could all simply use the tools we want, and not use the tools we don't, and not waste time expressing an opinion either way, but again this is a discussion forum.
And it's not as if I posted "Jai delenda est" here, I think my opinions are mild compared to what people here have to say about javascript, or C++ or PHP or any other language. I just don't think that a gamedev specific language is a good idea, compared to implementing libraries and frameworks in an existing language. I don't like the bespoke languages used by frameworks like Godot or GameMaker either.
Jai is designed for games, it aims to do a few things that can help game developers, as well as developers in general.
- Lower compilation times for debug builds.
- Better debug messages.
- A standard library that comes with a production ready graphics API, so gamedevs don't need to worry about the current state of graphics API and can just dig in.
- Standard input API for cross OS development.
- AOS to SOA automatic conversion to simplify code that needs to be performant, while retaining a clean syntax.
- A context system, which should help with simplifying functions definitions while keeping things strongly typed.
- The ability to rewrite ASTs, to do compile time programming. Ideally simplifying code, while keeping runtime speed performant, and keeping compilation speed fast.
This is just to name a few off the top of my head. The performance and API stuff is directly going to help game devs. I view it similar to Odin, something that is in production software right now, where you can have a clean langugae, with a strong standard library and primitives to help you develop quickly.
This reads as if the process and the finished work are somehow separable. If your code is a mess that you hate working on, it seeps through to your design and your design process. I too had a brief period where, for example, I thought dynamic typing lessens friction, but in reality it just causes massively more friction down the line. Many people never get to go down the line, so that is fine for them, but not me.
>This reads as if the process and the finished work are somehow separable. If your code is a mess that you hate working on, it seeps through to your design and your design process.
I didn't say anything about hating working on the code, but every example of game code I've seen has been a mess, even in games that are considered well designed. So I have to disagree - the process and finished work often are separable. What are ports if not an example of that?
There's a fair bit of survivorship bias in there. Few games are considered "great". Roughly half the games get canned during development. So while it may be impossible to make any game in a reasonable amount of time without creating some sort of mess, nobody would argue that a worse process isn't detrimental to the project. It could be the difference between a game being good-but-flawed and a masterpiece, or between "not salvageable" and "shippable".
Moreover, the "survivability" of the process goes beyond just one project. Jon got so burned out on the C++ language that he'd rather create his own language for the next project than use it again. If he didn't have to do that, he'd likely be working on the next title already.
Note that of course Jai's tooling is also written in C++
As to why Rust, there's actual historical information about why Graydon wanted to make it and why Mozilla decided to fund that work after it was started.
Jon has said the intent was that Jai would allow him to make more games, because C++ held him back so much. So, yeah, it would need to be superior to C++ in at least this way, and by at least enough to justify the effort expended, writing C++, to develop Jai.
I mean, he's _allowed_. The Compiler Police aren't going to roll up to his house and take away his Jai compiler if there isn't a quorum of HN users blessing his efforts. But people can point out they don't feel the juice is worth the squeeze. Also, Blow is certainly an advocate for his position, which means this kind of public debate is germane to the question of if _other_ people should adopt Jai.
A syntax to mark structs to be stored as SOA in arrays is the only one I see that doesn't have a modern C++ analogue (besides things like no header files).
Const expressions, defer (but not sure its significantly different than using destructors), some smart pointer stuff...
I assume you need to compare it to C++ from more than a decade ago.
I think that document is no longer very close to Jai's current state, note that it wasn't edited for quite some time and Jon seems happy to just rip stuff out and replace it wholesale, after all there's only a handful of Jai programmers so if not now then when?
In particular I believe the SOA stuff is gone, my impression (I don't have privileged access) is that SOA is one of those ideas where you think "Oh! This changes everything" and for the next week or two every time you do something you realise SOA would make it better. But a year later you find yourself unwinding some of that SOA mania and you realise eh... this isn't such a great idea that it deserves to be a key language differentiator. It's not useless but it's also not fundamental so maybe write a library or something.
There are a few other data structure tricks which can hit people this way, I remember I had a brief period where I wanted to solve everything with Bloom Filters and then I got better.
In terms of languages you can go try yourself today, the closest might be Ginger Bill's Odin. Shared scepticism for both C++ and modern language trends, syntax is reminiscent though far from identical. I'd be surprised if you hate one but love the other.
Edited: Somehow I removed "no longer" from my initial sentence during editing, which inverted the sense, now fixed.
This. As much as I love listening to JB, graphics wise he’s not doing anything ground breaking, it could even be done on the web. But I understand for him the architecture for his games being perfect is what makes it worth it for him.
Except, this complexity isn't saving time and resources. This complexity admiration culture has resulted in slower code thats harder to understand, debug and maintain too. What should be used only for small amount of time is used from get go like complex architecture and deep abstraction. Fetishizing simplicity is bad too for sure but a blip on a radar and not such a trend and far less of an issue compared to fetishizing complexity thats rampant.
Not a game dev or even a gamer, I'm defending attack on simplicity not blow or muratori.
Show me anything that either Blow or Muratori are doing that couldn't be done in an existing language or framework.
People laugh at games with thousand-case switch statements or if/else chains but they shipped and the end user doesn't care about logarithmic complexity. And most of the time it doesn't even matter. What fails with games more often than not is the design, not the code. What features in Jai make it superior to C++ for writing games specifically? Or does it, like Typescript for JS, only exist because of extreme antipathy towards C++?
Time is a resource too, and arguably a far more valuable one for developers than LOC or memory or what have you.