It's relatively expensive to find adjacencies atm (emphasis on the "find") but I don't expect to be moving tiles around too often. Characters/items/movable stuff won't need this kind of adjacency testing.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
What do I mean by smarter? Let's say each of our blocks has a position in a grid, [x, y]. (It's actually a 3D grid, so [x, y, z], but we can ignore the z for now)
The positions map to the block's index in z/y/x arrays. This means that a block's position can only be an integer like 1 or 2, but never a float like 1.25 or 2.81.
So a position like [0, 0] is fine but [0.5, 0] is not.
I'm currently experiencing a "where do I put whitespace in my code" crisis.
I've usually placed empty lines between pretty much everything except maybe variable definitions, but this makes different methods hard to spot and sometimes makes methods themselves harder to read?
But saving empty lines for just separating methods / class fields can lead to some very dense code.
The regular @croquet/react bindings have a lot of boilerplate that's available from their context object (e.g. a viewId) so these bindings folds that stuff in.
It’s still a lot of boilerplate though. Most of the “subscriptions” I’m writing are manually syncing these two data sources (the data published from the model and the React state).
tricker than I thought: making sure that pasted shapes don't end up on top of each other
Normally we'd like to place a pasted shape in the middle of the editor. You can think of this as an offset of [0,0] from the center.
But there are two circumstances where we'd want to offset this position. First, if the shapes that we copied happen to also be perfectly centered in the window, then we'd increase our offset (e.g. to [16, 16]).
Ever wonder why regular pencil tools wait until after you finish drawing to smooth out your line? It's usually because the app using a line-simplification algorithm—and these sorts of algorithms aren't "stable" as a line is changing. 🧵
Here's the algorithm at work, picking new points on almost every frame. Each solution is "correct" for each set of points, but it is overall "incorrect" in the sense that the solutions keep changing! codesandbox.io/s/simplified-t…
Why simplify at all? The "raw" input points are often very jerky and noisy.
Introducing rko, a three-letter state management library for #reactjs with built-in undo, redo, and local persistence. Built on @pmndrs zustand. github.com/steveruizok/rko.
The idea here is to update state either with a "patch", or a deep partial of the state containing only the changes that you want to make...
...or else a "command" made up of two patches, before and after. Only commands become part of the undo/redo stack.