search

thecommons-urbit / chess

Distribution repo for Urbit Chess app
Other
26 stars 8 forks source link

Display material difference #134

Closed rovmug-ticfyn closed 1 year ago

rovmug-ticfyn commented 1 year ago

This PR will resolve #11 by displaying the material difference. Initial commit just displays a number for the material advantage, then display of pieces will be added.

rovmug-ticfyn commented 1 year ago

Your approach to the material difference algorithm makes sense, so I'll begin making those changes. In terms of efficiency, should the material difference be stored in frontend state and only recomputed when a piece is captured?

ashelkovnykov commented 1 year ago

@rovmug-ticfyn That's a good question. Really, it should be stored in the backend state:

It would be easier to compute the material difference in the backend as the game went along: when there's a capture, record the captured piece and increment / decrement the material value of white / black. This is the kind of info any chess UI would be interested in rendering, so it makes sense to store it in the backend.

However, it's annoying to deal with the marks, the undo logic, the JS objects, etc. when adding a data field to the backend that needs to be sent to the frontend. Computing the material difference in the frontend as you are now (each iteration, just before rendering, without storing it) is easy and self-contained and gets us a working material difference display.

Caching the material difference in a map: FEN -> result would certainly improve the efficiency somewhat, but ultimately it's a half-measure since we should pull this into the backend.

That's all context to say: I leave it up to you. I think any of the above solutions are acceptable, since they all get us a working material difference display and the sub-optimal ones are quick & easy to implement, and easily replaceable.

rovmug-ticfyn commented 1 year ago

Material difference is now rendering, but I need to continue debugging some incorrect behavior.