Passionate full stack developer, course author for Educative, book author for Packt.
Find my work and get to know me on my Linktree: https://linktr.ee/thormeier
It's a lot of overhead, though, and as mentioned, I ran into two bluescreens before I got it working. I'm pretty sure one could use the water physics of the game to store more data and make this halfway usable, but the engineering involved would be way over the top.
two BSODs is the real commit cost. that water physics angle sounds like a great post even if it never ships - the gap between feasible and sensible is where the best dev stories live.
Passionate full stack developer, course author for Educative, book author for Packt.
Find my work and get to know me on my Linktree: https://linktr.ee/thormeier
I have the suspicion that the BSODs were actually caused by the amount of end points the game had to create once I clicked on the "Turn on API" button. The game does offer memory units that store single bits and can operate in various modes, so theoretically one could use a single HTTP lever as the input bit, a counter made up of a handful of those memory units and a few logic gates (I implemented a binary counter as a starting exercise, which was surprisingly easy) and a few hundred more memory units as the actual memory to have it act like a bit stack that could be addressed. It's a bit over-simplified, but RAM doesn't work all that differently, actually. It would complicate both reading and writing a lot, but I'm pretty sure it would be less memory intensive and scale a lot better. Downside is that the writing requests from the browser then need to be well-ordered, whereas now they can all be fired simultaneously and the addressing is done via the HTTP lever's names. Alternatively, one could use something like 21 input bits plus a few more for the address, allowing to store individual characters in memory "cells", so the HTTP requests can be fired in packets, improving performance.
Just thinking aloud here, but in theory, once that's implemented, we're not far off to just building a CPU. Add a ROM storage plus a rudimentary 2-colour-display and you've got a full-blown programmable computer. All the parts are there, it's only if the game crashes before the first frame renders or not lol
It's a lot of overhead, though, and as mentioned, I ran into two bluescreens before I got it working. I'm pretty sure one could use the water physics of the game to store more data and make this halfway usable, but the engineering involved would be way over the top.
two BSODs is the real commit cost. that water physics angle sounds like a great post even if it never ships - the gap between feasible and sensible is where the best dev stories live.
I have the suspicion that the BSODs were actually caused by the amount of end points the game had to create once I clicked on the "Turn on API" button. The game does offer memory units that store single bits and can operate in various modes, so theoretically one could use a single HTTP lever as the input bit, a counter made up of a handful of those memory units and a few logic gates (I implemented a binary counter as a starting exercise, which was surprisingly easy) and a few hundred more memory units as the actual memory to have it act like a bit stack that could be addressed. It's a bit over-simplified, but RAM doesn't work all that differently, actually. It would complicate both reading and writing a lot, but I'm pretty sure it would be less memory intensive and scale a lot better. Downside is that the writing requests from the browser then need to be well-ordered, whereas now they can all be fired simultaneously and the addressing is done via the HTTP lever's names. Alternatively, one could use something like 21 input bits plus a few more for the address, allowing to store individual characters in memory "cells", so the HTTP requests can be fired in packets, improving performance.
Just thinking aloud here, but in theory, once that's implemented, we're not far off to just building a CPU. Add a ROM storage plus a rudimentary 2-colour-display and you've got a full-blown programmable computer. All the parts are there, it's only if the game crashes before the first frame renders or not lol
that tracks - spinning up hundreds of endpoints at once is the kind of burst the kernel isn't designed for