diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/musings.txt | 2 | ||||
| -rw-r--r-- | doc/tilde30.t | 201 |
2 files changed, 203 insertions, 0 deletions
diff --git a/doc/musings.txt b/doc/musings.txt new file mode 100644 index 0000000..afc8394 --- /dev/null +++ b/doc/musings.txt @@ -0,0 +1,2 @@ +# musings and learnings +2024-06-14T19:42:55-06:00 i sure do miss types sometimes. i'd like a little warning to pop up and warn me that i'm returning a string, e.g., when i ought to be returning a bool. i wonder if i could use some kind of a fake struct.. it would just a table, obviously. but maybe i could write a function that registers structs with a struct registry? and then another function to wrap functions that take a struct as a parameter to enforce the shape of the struct? diff --git a/doc/tilde30.t b/doc/tilde30.t new file mode 100644 index 0000000..5eeb436 --- /dev/null +++ b/doc/tilde30.t @@ -0,0 +1,201 @@ +--- +title: TILDE30 +subtitle: nine mens morris fennel game +author: dozens +created: 2024-06-01 +updated: 2024-06-14 +--- +.pl 999i +.ce +{{title}} + +.ce +{{subtitle}} + +.IP 01 +what is up tilde30 fans it's ya boi dozens back with another up date on my +project! today i found a bug that was preventing mills from being recognized +as mills. my algorithm for detecting mills is kind of (probably needlessly?) +complex. but luckily, i had already written a small module for writing unit +tests. so after a small refactor to isolate the individual steps as functions +that i can export, i imported them into a test file and was able to more +carefully examine each step. turns out the culprit was a small reducer in +which i was doing an 'and' when i ought to have been doing an 'or'. literally +just changed one word and that fixed it. but i'm still pleased with the +process by which i arrived at that realization. i'm now confident that the +entirety of the mill detection algorithm does what i want it to do. yay unit +tests! +. +. +.IP 02 +today's goal was to implement capturing. but instead i discovered a bug in +rendering the board, and fixed that. i didn't bother taking the time to +really understand why the bug was happening. but after rewriting (and +simplifying) the render function, it's working correctly now. so yippee for +that. up next: capturing! +. +. +.IP 03 +went to go do some remote smol computering. posted up at the library and fixed +a small typo that was preventing the game state from advancing from phase 1 +to phase 2. and that's about all i could stand doing whilst coding on my +phone. later, on my laptop, successfully implemented capturing. next +up: prevent a player from capturing a checker that is part of a mill. i think +this will lead to a refactoring of the 'mill?' algorithm to generalize it a +little more. +. +. +.IP 04 +i did not work on tidle30 today. not enough spoons. +. +. +.IP 05 +today i did the refactor of the 'mill?' algorithm. +i ended up making it much more simple than how i had originally written it. +and it works pretty great! +the goal of this refactor was to be able check for a mill +after a move in order to change the game phase from placing to capture, +and also to check for a mill before a move +in order to check whether a capture is legal. +(a capture cannot break up a mill.) +as predicted, +my test-driven development workflow +made the refactor pretty painless. +i just got tripped up for a while +because i didn't realize i was passing the wrong type of move to the function. +you see, i have two different representations of a move: +one is a number 1 - 24 referring to the index of an array of player moves +(that is, the game state is a single array with values 0 = vacant, 1 = occupied by player 1, 2 = player 2); +and the other is an alphanumeric value (e.g. A1, b4, 7G) +referring to a place on the game board. +i frequently have to convert e.g. B2 into 4. +and what i don't really have right now +is a good type system that can tell me if i passed the wrong type to a function. +oh well! +i guess i'll have to do some manual type checking +in each function if i really want that kind of type safety. +this completes milestone 3: capture a checker. +next up: +implement some kind of a play counter +so the game can transition from placing to sliding. +.nf +http://cgit.tilde.town/~dozens/9mm/commit/?id=7776b2011a2585723078b275c838fd7332488d76 +.fi +. +. +.IP 06 +added transitioning from Placing to Moving, +and also implemented Moving logic. +this completes milestones 4 and 5. +starting to feel like a real game! +after getting my ass beat yesterday +by unknown function parameter types, +i added some type assertions to my new function. +and sure enough, +later on i passed the wrong value to the function. +but this time the assertion failed +and gave me a useful error message. +wahoooooo! +no time wasted tonight haha. +up next: +fix a bug that prevents captures from happening +during the moving phase? +watching: +maniac (2018) on netflix, +starring emma stone and jonah hill. +.nf +http://cgit.tilde.town/~dozens/9mm/commit/?id=f985dc4e5c9fdec06436c21440c3dc7245369847 +.fi +. +. +.IP 07 +as i said earlier, +there is currently a bug +that is preventing the board +from updating when a capture happens. +instead of working on the bug, +i instead focused on how sad it makes me +to have to enter 18 - 20 moves every time +just to test the capturing ui in the moving phase of the game. +this sadness inspired me to write an expect(1) script +that will interact with the game ui +and make all the moves for me. +much faster! +then i abstracted and isolated the moves +into a data file +so that for future ui testing, +i can just write down a list of moves +and not write a whole expect script. +and then i wrote a small awk script +that will convert data files into expect files. +so now i have some basic ui scripting, +which is maybe the first step toward actual ui testing? +and i have already used it to confirm the behavior +in both the placing phase +and the moving phase. +so it's not anything unique to phase 2 +despite my original suspicions. +thanks, tests! +up next: +fix the dang bug +.nf +http://cgit.tilde.town/~dozens/9mm/commit/?id=91b1662302c14cf84ca8b90c1f3ec20a585f67a5 +.fi +. +. +.IP 08 +with fresh eyes, +i was able to see the bug that was preventing capturing. +it was a single line in the update function. +and i deleted it! +then i set about trying to allow transitioning +moving to flying. +but i introduced another bug +that i can't find right now.. +it prevents capturing in the moving phase. +i'll have to look at it more later. +right now, +i have to finish packing! +i'm going on vacation! +we'll see whether or not i'm able to continue +working on 9mm / tilde30 +while away from home. +i'm not bringing my laptop. +so i'll be limited to coding on my phone +with my little folding bluetooth keyboard. +. +. +.IP "WEEK ONE REVIEW" +when i look back on week one, +i feel like i made more progress +than i had expected to. +even while spending time on writing unit tests +and "ui tests." +if i keep up this pace +then i expect i'll be done with the game in another week. +but i'm on vacation next week, +so i'm not confident that i will keep up the pace. +whether or not i get around to it as part of tilde30, +i do want to build a gui frontend for the game. +because i think that would be fun. +. +. +.IP "09-13" +i did not do any computering +during this five day low-tech beach vacation. +. +. +.IP 14 +fixed the bug that prevented capturing during the moving phase. +implemented flying! +and also handled an edge case +where you cannot break up a mill +when capturing +unless there are no other non-milled checkers. +in which case +you can break up a mill +when capturing. +up next: +ending the game. + +.pl \n[nl]u |