This week, I spent a lot of time on the design and implementation of the async version of the game. The current problem is that the current control flow of the system blocks too much on user input. This makes it basically impossible to do anything asynchronous in the state, such as reset the game or correct a card. So, the change to an asynchronous model is necessary but adds other challenges. The new model consists of the same 4 nodes (UNO, Controller, Displayer, & Manager), except now the manager is at the top level, and it facilitates the asynchronous communication between the other three nodes using thread-safe queues in Python. The code looks very similar to what I have written in Golang for Distributed Systems.
Because of this refactor, I am slightly behind schedule. I will work diligently on finalizing the new control flow for the first part of this week. Then, I will switch to helping David with the website portion. I hope, in collaboration with David’s work, to have a fully tested new control flow and a basic working website. Then I can transition into making the website functionality more complex.
There are two main areas in which I have done verification and validation: card classification, and control flow.
- Card classification: I have spent a lot of time validating the model in different conditions. In fact, this validation is exactly how I landed on a specific model + hyperparameters combo. Offline, I have seen 100% accuracy on the validation and test datasets. When actually using the device, we have seen very few mistakes. We have played at least 20 games of UNO and only witnessed 1 error in the color classification. This was a color classification from the bottom camera, and it thought a blue card was green. This mistake was more likely a lighting problem, however.
- As for control flow, we have tested all scenarios that can appear in the game, except calling UNO and calling an UNO failure. We must wait for the new async model to test this. Since I implemented logging inside of the game manager, we are able to confirm the game’s state after each scenario. Some examples of tested scenarios are: playing +4, calling bluff, failed bluff call, playing +2, playing skip, playing reverse, drawing a card, playing a wildcard, and more.
Once the new asynchronous model is implemented, I will do similar testing on each of the scenarios outlined above. Also, once the website is up and running, we will use more logging to verify its robustness.