I've thought about it a bunch over the years and my advice is to follow a few principles: procedural elements should almost always impact how the player plays, procedural elements should cross-interact with each other as much as possible, and procedural elements should be understandable to the player.
As an example in No Man's Sky the player immediately starts with a jetpack. It makes it so the terrain is approached the same way every time: you just jetpack over it. Very rarely something is tall enough to require you to walk around.
Legend of Zelda: Breath of the Wild is a positive counter example. You have stamina so you're constantly thinking about the height of cliff faces, you can glide so you're thinking about height points and straight lines through the world, cliff faces cannot be climbed in rain so you think about the weather, slopes can be slid down on a shield, etc. There are a bunch of systems that may you think about the topology of the terrain, so even just varying the height map becomes interesting.
Similarly in No Man's Sky there are different resources but they work the same way on each planet and the player interacts with them pretty much the same way everywhere.
When I say elements should be "understandable" what I mean is that a trap, which Dwarf Fortress falls into, is to add a vast simulation which the player feels they can never really grasp. Simulations should not be a black box because then they begin to feel like a random number generator.
The aim shouldn't be to make an "infinite" game but to make a very interesting system for the player to slowly understand and master. The developer shouldn't just add stuff, but they should think about the long journey (and eventual mastery) a player might take as they spend significant time with the systems.
I'm far outside the music creation space so you're basically asking me to spitball something, but I'll try!
I think "make it observable" is a good principle for a lot of software, but also is useful here. Like if you have something changing in how it operates think about perceptual clues that are unobtrusive but give the user a sense of what's going on. Think a car engine sounding weird, a laptop getting hot, or a water bottle being filled up rising in pitch.
Being able to rapidly clue in to how something is running in a bunch of different ways is useful. In synth plugin systems I've seen with node graphs I think having some sort of perception of data traveling that you can assess at a glance could be useful. I can see both color and perhaps the "texture" (dotted, dashed, etc.) of the connections being mapped to some important property of what's being transmitted.
On the "cross interactions" thing perhaps there's a design opportunity to find interesting properties of different components you wouldn't normally expose that you can feed into other systems. Perhaps if audio were to clip that is both something you don't want but also a control signal that can feed into something that self-corrects, or even entirely changes the composition. With that you might have some sort of dynamic gain that as it approaches clipping it steps into a new composition creating a strange "ecosystem" of sound.
In general there's some interesting opportunities to try to create real systemic components that try to make mechanisms with interesting properties rather than precisely controlled things. Perhaps you add an input that pulls the current moon phase, astrological signs, time of day, or weather. Then your composition could change and be a sort of live work each time, but not in a totally arbitrary way. If you wanted to extend the idea of "observability" all the way to the user you could by convention add some brief narration at the start describing the conditions of the composition "It is Wednesday. Rain is forecasted. The following composition has been changed accordingly."
It also may be interesting to weave in more sophisticated mathematical systems, or physics simulations, and then feed them into other components. It'd be quite odd but I can imagine like a bunch of balls on ice floating around and when they touch that creates a signal output, but you could have an input that's like "table shake". It'd be fun to see a program triggering these sort of rube goldberg-esque chain of things to create some sort of interesting sound scape.
Very helpful, thank you. Great ideas. Some of those exact things I've actually already planned or implemented, for the exact purposes you describe, and some are things I haven't at all thought of but which are definitely worth looking into.
That’s technically correct, but it still means that someone has to write the formal specs that Claude’s output is verified against, and someone has to design the formal languages the specs are written in. And once you have formal specs that truly covers all aspects that you ever will care about, it’s unclear if you couldn’t instead build a non-LLM mechanism that efficiently and deterministically spits out an implementation of such a spec.
I expect in the future it will become hybrid. Formal specs provide guardrails for LLMs / AI but within those guards LLMs will author traditional compiler programs and at times drop-down to manually compile / prove certain snippets.
Could we describe the first humans manually writing Assembly and their own higher level abstractions as "compilers"? Loosely I think we could, and LLMs fit the same mold.
I disagree in the sense that source code (compiler input) leaves little space as to the behavior of the resulting program. With LLMs, either there is much more implied leeway, in which case I’d argue that it’s different in nature. Or the specs will restrict the LLM output to a similar extent as a conventional programming language restricts a compiler’s freedoms, in which case it’s not clear that LLMs are the most expedient technology for generating that output.
Levels of abstraction actually matter with regard to how much observable behavior they leave unspecified, and with regard to how much control is needed over each respective behavioral aspect.
I don't think this is accurate. AI is driving the cost of software towards 0 and these AI models themselves are software.
Releasing the models for free accelerates the trend but if you're a startup that needs leverage it's a good way to build brand and customer momentum that will be relevant in the more established future market.
I can see an American company taking on the same strategy, and in fact Thinking Machines based out of San Francisco did that just a few days ago by releasing their first model with open weights.
My task in question was a number crunching task, basically doing multiply-and-add for 336-bit integers. I wrote a JS version, and a C version compiled into WASM by using Zig. You'd think that WebAssembly would trounce JS here, but it actually didn't.
The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers. Each number, despite being a double, was basically a 48-bit integer. Long multiplication requires splitting a 48-bit integer into two 24-bit integers so an intermediate multiplication result will fit in 48 bits.
The C version used 32x32=64-bit integer math. (Would have been nice if WASM had supported 64x64=128-bit multiplication)
Even with the overhead of using doubles instead of integers, the JavaScript and C versions ran at nearly the same speed. I think the C version was slightly faster, but not significantly. The C version took a lot longer to load, as it had to instantiate a Webassembly object, and had to run glue code to copy things in and out of Webassembly memory.
> and had to run glue code to copy things in and out of Webassembly memory.
Not surprising. The FFI boundary is always a bottleneck. If you can eliminate it, you will see where the WASM JIT shines. You have far more control over mechanical sympathy with C/WASM than JavaScript (though far from perfect).
Also, consider publishing your findings and ask for reviews for optimization opportunities.
It's used heavily by major web apps like Figma, it's used to run non-Javascript languages on Cloudflare Workers, many compute-heavy web libraries rely on Wasm modules, many web games rely on Wasm, it's used for safe plugins in some native apps like Microsoft Flight Simulator, amongst other use cases.
In a time where people are increasingly disillusioned with the tech industry & billionaires the imagery Apple puts forward of a literally siloed utopian ultra wealthy landscape probably does rub people the wrong way, at least at a subconscious level.
In the past Apple has been pretty good at anticipating and responding to shifting cultural dynamics. I wonder if they'll recognize and adjust?
I'm not sure it actually rubs people the wrong way, given Apple's sales numbers. Apple positions themselves as an aspirational brand. Everything they do is on purpose to enforce that. When people are upset at reality most people look for an escape into something else, not dive further into whats actually happening.
The siloed utopian landscape is the point. Apple tries to sell a modern, clean lifestyle status symbol. They are selling products for the person you hope you become, not the person you are right now. "Buy an iPhone, and this is what your life could look like."
Same deal as fad diets and gym memberships, its the illusion of being able to buy your way into a lifestyle without doing the hard work. Apple is selling an identity.
I agree with that, but I don't think it's incompatible with my observation.
Apple has often in the past positioned itself as an aspirational product for those who aim to be tasteful, talented, beautiful and wealthy.
The risk of becoming too disconnected from reality is that the typical person may stop aspiring to the sort of rich-person reality Apple presents. Think of how many of the symbols of wealth of prior generations, like fine tableware, were rejected by younger generations.
I am unfamiliar with this project and only skimmed this post but if this uses Rust for the main binary blob it should be possible to have the main thread blob shared with the other threads even with the blocking.
The blog post cites the concern that malloc could block, however when Rust's standard library is compiled with support for atomics enabled the Rust allocator's locking implementation busy loops instead of waiting on the main thread.
This means that if care is taken to avoid any other code that makes the main thread wait it should be possible to use a single shared binary instead of the more convoluted approach presented in the blog post.
Gosh, I think that means even when your code is wholly running on workers (where you would be able to use the atomic wait mentioned in the comment), it still will busy loop, doesn't it? At least it's within the allocator and not in the general implementation of Mutex... I think?
Yes that first sentence is correct and that's an unfortunate side effect. The Rust ecosystem eventually needs to evolve its multithreaded Wasm approach. Atomics are still only supported on Nightly Rust but it's been that way for 7+ years now.
And yes you're right again it's only in the allocator.
The green card process can take 9 to 20 months and applying for a green card demonstrates an intent to immigrate so it's highly likely attempts to return on other temporary visas like a student visa will be denied.
So they likely have to wait out the green card process abroad unless they secure a dual-intent visa like an H-1B.
There's also 75 countries that the US has shut down consular processing for so those people may be locked out getting a green card entirely.
I believe the issue with what you're describing is that if you're on a temporary visa, like a student visa, applying for a green card shows intent of immigration so you cannot return to the US on a student visa.
If you have an H-1B already you may be able to do what you're describing. If you're a recent grad in the US this basically locks you out of trying to get a green card until you've already secured an H-1B.
As an example in No Man's Sky the player immediately starts with a jetpack. It makes it so the terrain is approached the same way every time: you just jetpack over it. Very rarely something is tall enough to require you to walk around.
Legend of Zelda: Breath of the Wild is a positive counter example. You have stamina so you're constantly thinking about the height of cliff faces, you can glide so you're thinking about height points and straight lines through the world, cliff faces cannot be climbed in rain so you think about the weather, slopes can be slid down on a shield, etc. There are a bunch of systems that may you think about the topology of the terrain, so even just varying the height map becomes interesting.
Similarly in No Man's Sky there are different resources but they work the same way on each planet and the player interacts with them pretty much the same way everywhere.
When I say elements should be "understandable" what I mean is that a trap, which Dwarf Fortress falls into, is to add a vast simulation which the player feels they can never really grasp. Simulations should not be a black box because then they begin to feel like a random number generator.
The aim shouldn't be to make an "infinite" game but to make a very interesting system for the player to slowly understand and master. The developer shouldn't just add stuff, but they should think about the long journey (and eventual mastery) a player might take as they spend significant time with the systems.
reply