From a5f46ca84a85e3c71c6e3c5d4497326d3142f959 Mon Sep 17 00:00:00 2001
From: techieAgnostic <s@p7.co.nz>
Date: Tue, 28 May 2019 21:26:40 +1200
Subject: [PATCH] non compiling, rambling

---
 src/Cards.hs | 114 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 114 insertions(+)
 create mode 100644 src/Cards.hs

diff --git a/src/Cards.hs b/src/Cards.hs
new file mode 100644
index 0000000..0175089
--- /dev/null
+++ b/src/Cards.hs
@@ -0,0 +1,114 @@
+module Cards where
+
+import ComBoard.Types
+
+data cardInfoNeo = cardInfoNeo
+   { blah blah blah
+
+cl
+
+
+
+get given a set of lines
+
+pass p1
+playLineAnn p2 maya mark
+playReactLine p3 progknife kaji mark
+pass p1
+
+create curried versions of matching functions that are just missing boardstate
+
+[ pass p1 ...
+
+also accept information gathering
+
+listValidTargets areYouStillHere --in the react phase
+boardstate --print entire board
+
+either way improves or keeps the same the boardstate and appends log messages, and may return a string, if infogathering
+
+inside box we take the appropriate function and run it.
+
+this may scan cards for functions according to the board state
+
+we apply the affect of the function, moving things as they should, until we get to a choice.
+
+we then compile a list of all valid choices, as curried functions, and assign a message to each.
+
+the user can then select a function, which is saved as part of the board state, something like
+
+chooseOption 3
+
+which will run it.
+
+entire box is stored in a state monad on boardstate, so the state can be stored until data entry
+
+BOARDSTATE
+
+physical cards on the board are saved as a big sql table esque list
+
+[ (cid, CardSym, Zone, Owner, etc etc ]
+
+and search and changed with filters which is sorta gross but can find a better structure for later
+
+groups are as done previously, with another table list for mapping the characters to the main cards in play
+
+playerdata table, list of ids
+
+list of played cards, wrapped in modifier values, with reference to player.
+
+zones for mechanical zones like current stack
+
+the curried functions for choices
+
+list of evas in neotokyo
+
+list of angels
+
+list of all card info, stored something like
+
+cardsym
+
+stats, name etc
+
+big list of phase -> function pairs
+
+(ReactCard target speaker etc boardstate, (bigFunction that does what the card needs to do to get started in the box)
+
+box can then scan the list for valid timings, and run them.
+
+restrictions.
+
+each card also has some restriction fields by default
+
+eg reactCardRestriction :: BoardState -> Bool
+
+that says base case for whether to play it.
+
+then have global allowances, pair of functions that when applied to boardstate, returns bool.
+
+if the first one passes, the second is the new one to check.
+
+used to filter.
+
+after apply a list of restrictions, returns false if not allowed to play it.
+
+keep turn and timing step data in the boardstate, eg
+
+4.18.3 turn 4 step 18 substep 3
+
+so that we can have a timeout step for temporary affects
+
+also have ones relying on boardstate, and run a check on both timing and check to see if they expire
+
+encode target and ritsukoable effect information in board state, so they can be changed or checked later
+
+have unmodifiable start and end state phases that pass boardstate, moving to the next timing step.
+
+optionally also pause for input at certain levels of important step, but only accept info checking
+
+use box as black box for use as engine of a gui
+
+gui can get all info it needs to do its own logic on what to show
+
+