$PH\06f522\FinalProject\Standalone\GUIStatus061225.2230.txt Topics: Build Log; Current Status; Bugs; HCI topics; Lessons Learned. C:\Documents and Settings\Robert Lechner\public_html\ \ 06f522\FinalProject\Standalone\GUI has the latest source code and Anthony's ProjectGUI.vcproj with VC++/VS8 build capability. The built code runs from a shortcut on my desktop. 1. Build Log: -------------------- BUlding previously defined project named ProjectGUI at $PH\06f522\FinalProject\Standalone\GUI project name ProjectGUI: ----------- ------ Build started: Project: ProjectGUI, Configuration: Debug Win32 ------ Compiling... stdafx.cpp Compiling... CardGame.cpp DrawGL.cpp c:\documents and settings\robert lechner\public_html\06f522\finalproject\standalone\gui\drawgl.cpp(100) : warning C4100: 'card' : unreferenced formal parameter c:\documents and settings\robert lechner\public_html\06f522\finalproject\standalone\gui\drawgl.cpp(399) : warning C4100: 'my' : unreferenced formal paramete c:\documents and settings\robert lechner\public_html\06f522\finalproject\standalone\gui\drawgl.cpp(399) : warning C4100: 'mx' : unreferenced formal parameter ProjectGUI.cpp setengine.cpp Generating Code... Compiling manifest to resources... Linking... Embedding manifest... Build log was saved at "file://c:\Documents and Settings\Robert Lechner\public_html\06f522\FinalProject\Standalone\GUI\Debug\BuildLog.htm" ProjectGUI - 0 error(s), 3 warning(s) ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========= 2. Current Status: ------------------ The latest version of Standalone Setgame now runs OK on my IBM PC. I checked out from CVS and imported it and it compiled and linked after I prefixed "GL\" to these filenames under ProjectGUI Property Pages/Configuration Properties/\ Linker/Input/Additional Dependencies: "GL\Opengl32.lib GL\Glu32.lib GL\glut32.lib". My updated ProjectGUI.h also has #include "GL\glut.h" not . (This could or may have been checked in.) The build was also influenced by prior changes (such as adding glu.h and gl.h?) to the VC++ Express/VS8 libraries (TBCHecked). It scores +25 per valid set, -5 for an invalid set. The turn-around time from card3 click to set replacement appears instantaneous and is not a good HCI technique. 3. Bugs: ---------- There seems to be a bug in set replacement: sometimes the board = 12-card layout is invariant EXCEPT for replacement of a 3-card valid set. But most of the time the entire board is replaced. Code inspection is needed to find out why. The 3 warnings in drawgl.cpp on unreferenced parameters (card,mx,my) may reflect an interface change that was called for at the last minute in drawgl.cpp to replace 3 cards instead of the entire board, that is not yet implemented and may fix this bug. This bug undoubtedly propagates to the networked version, and may explain why a passive client did not get the correct replacements in AMiles' MCC networking demo. [TBD: Check if passive and active clients replace the same 3 card set with the same new cards and play continues from there.] One debug trick is to display the candidate set as one column of 4 radix 3 digits, one card per column, so each column can be added mod 3. TBD: a life test (deal until no more cards available, continuing the play with fewer cards on board until no more sets are possible). This requires the above bug to be fixed. To exit gracefully. I just hit letter q[uit]. 4. HCI topics: ----------- More delay between clearing the set before replacing it, and logging the updates as they occur, would make board layout changes more visible (and debuggable:-). One debug trick is to display the candidate set as one column of 4 radix 3 digits, one card per column, so each column can be added mod 3. This tableau would let each client learn the algorithm to validate a set by inspection. One HCI improvement might be to require one (or all) of the clients to implement the interesting asynchronous but unanimous decision to approve (or challenge) a valid set which results in clearing it everywhere, and second a timed decision to approve its replacement. A design-stage (pre-implememtation) state model was the appropriate avenue for detecting these omissions, and leads to more state diagram nodes in both client and server. Another TBD HCI issue is to add a help button to the GUI to display rules of the game. A draft of these rules might have detected a desire by passive clients to view the highlighted set before clearing it and the unexpected scoring of +25/-5 points that came from online imitation games and not the original setGame. 5. Lessons learned: ---------------- (1) Use a State Model for client/server interaction with enough detail to investigate HCI topics. (2) Add a help button on the GUI to display rules of the game. (3) ====================================