Week 6
Week 6 saw me go ahead with the PR’s I had opened previously as well opening new PR’s. Continuing on Maze-activity, I decided to break the entire task into smaller tasks and tick them off one at a time in each commit, so that it becomes easier to keep track of changes. These smaller tasks included flake8 fixes, save hole placements in journal instances, update the rate at which a player falls into a hole (basic animation technique) and so on. Having smaller goals in mind helped me focus better and also led me to make minimal changes against master. That was a one of things I picked up while working on this activity, that breaking a task into smaller goals is a very effective way to write good code.
My mentor had the idea that rather than let the player just restart the Maze from the sratch, it would be nice if the information could be communicated to other players as well. What this essentially means is that the Maze must remain solvable. I remember having a discussion on GitHUb on how a new Maze is generated, and how the algorithm that generates the Maze has no concept of a solution. This fascinated me and I spent hours trying to understand how the algorithm worked. It did so by digging into the corners to ensure that the Maze is always solvable, and yet had no concept of a solution. Adding holes meant that some Mazes would remain unsolvable as no user could get past them, without having to restart once again.
My mentor desired that the maze remain solvable, and one way to do this would be to share information when the first player passes through a hole, thus allowing other players to pass through the hole the next time. Sounds simple right? Turned out that keeping the players in sync was a lot harder in reality. I decided to change the color of the hole when someone passes through it, and change its properties so that other players can pass through it as well. GTK, being a event-driven model, runs in one giant loop, and processes events as they are generated. This meant that the event of a player falling through a hole needs to sync with the other players who are solving the Maze at the same time. Collaboration adds some latency in handling events, so often it happened that the player would restart in one activity instance whereas in the other the animation of the player falling into the hole would continue to play.
Fixing Collaboration was biggest challenge and after hours of testing and debugging, I finally got it to work :D It turns out that my changes against master were a lot, and my mentor added commits on top of mine to minimise changes and perform redraws effectively.
Another thing I had failed to notice that there could be different versions of the game been shared, one instance where holes were added and the other without them. I felt quite angry at myself for ignoring something so trivial yet important, and I only realised this after my mentor had pointed it out.
Moving on, I decided to take a break from the feature of Search in Chat and worked upon Memorize-activity. One of the issues was to redesign the layout and make it more symmetrical, when the activity is run with an odd number of tiles.
Porting to sugar3.speech was yet another task I enjoyed. My initial go at it failed in several tracebacks, and thus I decided to understand the code a bit better before trying again. I did port the activity successfully, however, I had instantiated the speech.py module more than once. The module being based on Gstreamer, carries a lot of resources and thus my mentor felt it would be unwise to instantiate it more than once. He advised me to take up on the design pattern that is commonly used in sugar where an object is globally instantiated once in a separate module and imported in all other places where it is required.
Links to PR: Memorize: PR #25