https://oskarstalberg.com/game/house/index.html
The author is on Twitter and sometimes tweets about development of his games and the techniques involved.
I'm actually procrastinating on HN from working on a GPU parallelised version that can generate millions of positions every frame. In Townscaper you can actually see that the algorithm runs quite slow and lags behind the players input, there's just a bunch of animation to hide it. I'm hoping to eventually get a version that can run in log2(mapsize) time.
[0]http://oskarstalberg.com/game/wave/wave.html [1]https://www.youtube.com/watch?v=2SuvO4Gi7uY
In the in the original WFC(wave function collapse)[0] versions it always used an example of a completed output and generated all valid tile combinations from that. For a game this means that the developer can use hand made maps as examples for it to create new plausible maps. In the common vernacular WFC doesn't use this step and just directly either generates what combinations work or the devs manually decide what tiles can be next to others. Perhaps only the combination of both steps should be considered WFC.
Just to guess I think this is probably a case of it being developed independently in different fields. It's good to have another name for it as I always hated it being called "wave function collapse" when that is a physics thing.
Edit: Found it: https://twitter.com/OskSta/status/1198958801363308544
He designed it so you can fit a saved town in a tweet.
"It's my own very context specific implementation. I know how many bits I need for each bit of data, so I just store it all in a big bit array. I then convert that bit array to my own custom base 64 format, based on 64 web safe characters."
Worth reading the whole thread, as will all of Oskars twitter feed its super interesting.
Not sure what you'd need a look up key for.
And done natively with no need for the plugin mess and security holes of Flash. The key would be navigating the feature creep that led to the bulk and security holes of Flash.
Unity already has the bulk, but the security holes shouldn't be as big of an issue given that it's "just a website" and runs in the browser sandbox.
There's nothing inherently large about WebAssembly, it's just that most practical wasm demos bundle emscripten (essentially an entire OS's standard library) or another very heavy layer in order to interop between the JS and WASM world.
As a bit of an experiment to see how small wasm could practically be with a minimal interop layer, I built this little project - the web demo is 90KB of JS + 70KB of wasm:
https://github.com/jordwest/cavernos
It was heavily inspired by this article which manages even smaller builds:
http://cliffle.com/blog/bare-metal-wasm/
There's a lot of room for improvement in terms of size optimisation in most projects, but it's still early days and for now most of them just bundle an OS compatibility layer to get things working quickly.
Once it loads though wow, the graphics are great, nice little physics effects. Wonder how many online games are like this. Light source/shadow also cool.
On subsequent loads it's fast like it's near 80-90% already.
edit The bottleneck is most likely distance too server and RTT
http://oskarstalberg.com/Townscaper/#IzhCuCAJioFFB00CAajRAN2...
https://www.youtube.com/watch?v=APIdkBwwWJI
at 1:12
Notably, the export strings are the same.
Basically: you're not missing anything from the core experience, but the browser version is slightly inferior. And buying the full version helps Oskar make more neat stuff in the future.
Edit: it's also a smaller build area.
What I really like about this is that the base grid is not straight. Therefore the buildings are arranged in a very European style.
Because a real world requirement in software development is the equivalent of, "I want to model my town".
And in townscaper I can't, because the presets don't fit my real world town.
So you then need to hire in a specialist block customiser who can write custom blocks for you to use in the modeller.
And then you realise you've just pushed the problem one step deeper.
EDIT ah, it's unity's fault apparently. According to caniuse WebGL is golden for all mobile browsers. They should get with the times ;)
One thing that the demo could improve on in the mobile department is that scrolling is too sensitive. Most attempts at tapping to modify the structure result in a totally random change of the camera.
I'm a big fan of Oskar.
Edit: Scratch that it does run. I got scared away by the message about webgl builds not being supported on Mobile.
The tutorial was about the previous web-based Brick Block by Oscar
