Move error handling to front-end

game.validate-move will now return an error code is the move is invalid.
default error messages are found in lib/constants.fnl. error handling is
now handled on the front end.

1 files changed, 39 insertions, 0 deletions

diff --git a/doc/tilde30.t b/doc/tilde30.t
index c931c07..8a6911a 100644
--- a/doc/tilde30.t
+++ b/doc/tilde30.t
@@ -272,5 +272,44 @@ and will be spending a lot of time on my back.
 So I'm either going to get a lot on 9mm,
 or nothing at all.
 We'll see!
+.
+.
+.IP "20 - 21"
+I was having back surgery!
+.
+.
+.IP "WEEK THREE REVIEW"
+Finished the game, and then had a major surgery.
+Doing some tidying up and housekeeping now.
+Organzing tests,
+breaking stuff out into modules.
+Rewriting and refactoring a couple of functions.
+Generally getting ready to start thinking
+about Stretch Goal 1: Story Mode.
+I have a vague inkling of an idea about
+doing some kind of generative story / narration
+based on each move of the game.
+Assign symbolic meaning to the outer, middle, and inner rings of the board.
+Add a little twist based on whether the move is a capture, a slide, a placement.
+That kind of thing.
+Not sure how I want to do it exactly yet.
+I'd like to be able to show the story progress as you play.
+But updating the story every move seems like kind of a lot.
+Maybe just at every game phase.
+So three installments.
+One at the end of Placement,
+the second at the end of Movement,
+and the third at the end of the game?
+Anyway.
+
+Up next: big refactor of the validation logic.
+I don't want it to just print to console
+if I'm going to eventually support multiple frontends.
+I need to return an error code or something
+for the client to interpret.
+I'm still interested in the Result / Either monad option
+but I think I'm doing to first try the conventional lua way
+and throw an error, and then 'pcall' the function and handle the error politely.
+
 
 .pl \n[nl]u