I bet it reflects a reality of the hardware! A lot of optimization nowadays is around memory access patterns. Random memory access is more expensive than compute in a lot of cases. See things like ECS

What was the benefit of using 3 different types of VS Code, over opening three instances of the same editor?

I feel this hard. I'm finding that most companies I've interacted with show diminishing returns on technical skills, instead incentivising people problem solving. Like it's actually hard to find a problem where deep technical skill is truly necessary and aligns with $$$

I've seen that typically up to 90-99% of states are soft lock states

I mean exploring every -winnable- state! Right now I do that by exploring every state and then trimming out the soft locked ones at the end. Next optimization step would be to use some sort of A* to find the win state and work backwards, I think. When/if solving becomes the bottleneck

🤩 Does this mean I can achieve my dream of validating my build and deployment pipeline locally? No more branches full of 100 tweak commits?!

Dang, so close to getting into that contributer list!

I found an issue and would contribute a fix, is the website open source?

I may be wrong but I hope that in the general case (for other types of games) solving the graph is O(n) where n is the number of possible game states. At its core it is graph traversal, and both depth-first-search and breadth-first-search are linear time IIRC

Every node repels every other node, that's the hard part :'). I could walk all the neighbors to apply spring forces in O(e), but for the repellent force it's O(n^2) to brute force. The Octree brings it down to O(n log(n)) in theory

And it turns out that visualization is the most compute intensive part! There are many games I can solve in a couple seconds that take minutes to render out

Thanks! The secret is that this is just a visualization, meaning the graph is fully solved already. So I can adjust the speed of reveal very easily without worrying about process time.

Plus with source generators creating that much code via duplicated classes could be easier to maintain compared to the more dynamic approach

Does the schedule go up on ludumdare.com anymore?

In my mind the magic of the wifi block is the ability to assign different values to the same "transmitter" name in different blocks. In one block it's height, in another it's width, but inside both they get labelled as "distance" internally. Same encapsulation + naming benefits as a regular function

Copy paste nodes from one wifi scope into another like you would copy paste a couple lines of code from one function into another, and it Just Works

What if you could drag a "(((a" receiver out of a box w/ an "a)))" transmitter and into another box w/ the same plug and have it all work!? does BP support that? I dunno if its good, but it could be interesting to support that.