nelfin / 4x4x4 Goto Github PK

Memory grows unlimited - consumes everything O.O

Computer should be getting high positive scores when crosses, but gets negative scores instead.

Need to change the sign or something in score_state() or evaluate()

If the worker receives the move (-1,-1,-1), it'll move, otherwise it'll read the other player's and then make it's move

Can't play against the computer if it won't listen to what you have to say.

Gotta remove TODOs, other large blocks of comments, add some other comments, maybe remove debug functions but they can probably chill. Also make sure we only output the good stuff.

Just +1/-1 win/loss? Or big positive for win, slight negative for forced move etc.

Could add buttons to VPython display. Heck, could even add a textbox for moves; no more terminal interaction

Edit: I pity the #6 that doesn't cause issues.

I am teh gays

While waiting for a reply from the worker, the visualiser won't receive keyboard input until a reply is received. Not very important

Should use VPython's red-cyan stereoscopic mode. For Science!

plain to see, refused to take. It was on the even diagonal on the y=0 slice.
I was on Josh's sparse_array prototype, any chance your score state function is returning too high values?

Heeyyyyy Andrew...

Can I get some more data in exp/report? namely to fill in the tables in this commit?
Obviously not the Heuristic column. Unless you feel like adding in heuristic choices of
alpha beta moves. Because that would be awesome.

Look at the commit 5b71f3b for more info. Only way to close cleanly is a keyboard interrupt in terminal, and then close the visual python window.

There's something wrong with what I've done with the makefile. It only recompiles worker.c when it has changed, but often a change in state_functions.c makes worker.c recompilation necessary.

I'd like a REALLY simple selection criteria for what move minimax takes first (in order to prune more quickly)
Possibly not even something for the final include, but I'd like to have it to talk about in the report.
I was thinking we could just select it based on the score in Josh's value map; simply pick moves with more lines through
them first.

Only basic victory stuff is done, no scoring of non-terminal states.

We need some way of passing around the last move, so that when we evaluate whether the board is a victory for someone, we can use the last move to speed things up. I'm thinking it could either go inside the state itself, or it could be included in the retval structure from the get_successors function.

Josh's: df5e1b2
Tim's: ffd8a2d

Sometimes on startup I've noticed a failure to communicate with the worker completely. Restarting fixes this issue, not sure what causes it.

Need to separate game tree generation with player logic.