679 karma · joined January 8, 2015
The architecture of the games are such that the main game logic runs both on the client and the server. The server runs the logic to provide the authoritative game state and send it out to all the clients, and the clients run the logic to predict where they're going to be immediately after you press an input to compensate for the network latency. Since the client is predicting what will happen using the same code paths, the game logic need to be completely deterministic so that it desynchronizes from the server as little as possible.
With the TS/JS game we essentially just hope that running the same JS bundle in node and any client browser produces the same results for all the collision/gameplay math, and it seems to luckily not cause us any problems. For the game in rust though, compiled and optimized native rust floating point math would drift from our client webassembly builds surprisingly quickly, so we decided to pack all the shared logic in to a wasm bundle that gets loaded on both the server and the client, and we're using Wasmer to do that :)
The Wasmer API is super ergonomic and it's been a pleasure to work with. I think the only thing that would make our lives better that I can think of is being able to ignore imports and have them auto-bind to noop functions or functions that immediately return zero in the case of non-void imports. Since we're using the same wasm bundle for the client and server, there's a bunch of client-only rendering bindings that we just ignore and never call from the server-only and shared wasm code in the bundle, and currently we're using a hacky script that uses wasm-objdump to generate a rust module with a bunch of noops in imports!{}.
[1] https://github.com/WebAssembly/design/blob/main/Nondetermini...
This is quite possibly the worst take about anything I've ever heard. Intelligent human-monkey hybrids brought in to the world for the purpose of having their organs harvested, vs lil pocket computer.
Healthcare requires a whole setup, so additionally it's hard to talk about what you even have the right to, concretely. I agree it's a semantic distinction, but I think it is helpful, because it separates rights in to the kinds that are fundamentally attached to human beings and the kinds that are basically strong preferences for the existence of different institutions.
As a first crack at it, let's just give everyone who makes less than say $10k per year a bundle of aid that amounts to the fixed value of $1000 per month. This perhaps an improvement because we aren't ignoring the needs of the poor, but it creates a problem, which is what a welfare trap is. Imagine the graph for this situation. If you're making over $10k per year it's y = x, but if you're making less it's y = x + ($1000/month). So at x = ($1000/month) there's a sharp drop in take-home money. So people who would perhaps like to make a little more money are disincetivized from doing so because they would stop taking home that $1k per month and be exchanging it for a much smaller raise.
The negative income tax proposal attempts to solve this first by just providing cash to poor people instead of various goods that are hard to measure, and then by ensuring that the curve we're talking about never has a negative slope or drop. For instance imagine if you make zero dollars, you're given $1000/month, but then for every additional dollar you make independently, you receive 25 cents less aid. You'll always want to make more independently in this situation even if you don't keep it all.