Skip to content

Latest commit

 

History

History
15 lines (8 loc) · 1.27 KB

2019-10.md

File metadata and controls

15 lines (8 loc) · 1.27 KB

October

October 31st

In trying to make as few compromises as possible, I have slowed progress on my personal projects to a crawl.

Too much peer-to-peer stuff, too much client-only stuff, too much Ethereum stuff. Need to simplify if I'm ever going to finish any of these projects!

Stepping back into the emojinos codebase... first up, remove the Ethereum bits and get it running.

Why am I storing the tiles/positions in a set? I think it used to make sense but it's making resolving tile placement rules in a deterministic order really difficult... Or was that the point? If this were a physical boardgame you wouldn't use the historical order that tiles were placed, the board would resolve itself in an order-independent way? Surely at least calculating neighbors should be ordered, maybe clockwise or something. Is it possible for neighbor calculation to be a set as well as be deterministic?

Reminder for dealing with animations in a functional way: collect what to do first, then animate it.

This will be a game where a small action can have cascading consequences, it needs to be clear why things are happening so the player feels in control. I think that means if there are 'competing' tile transformations they should all be shown then the 'winner' is the last one to take effect.