A was written by Wen Hui, B was written by Alexis and C was written by Nicole.
Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.
Connexus has a virtual companion that provides hints to the user during gameplay. This simplifies the process of searching through the internet for American culture references and word definitions themselves. It helps to bridge the gap in this digital game of Connections for users who might not be technologically savvy or well versed with the internet enough to search for hints on their own. Our game is built such that the user can just interact with the physical game without having to open their own digital devices at all, making it inclusive to individuals of different technological skill levels. Additionally, Connexus helps to make Connections more accessible to everyone, even for people who might have low attention spans when interacting with digital devices or those who are more tactile learners. Our game makes Connections a game that stimulates the player’s sense of touch instead of just sense of sight, allowing them to be more engaged and focused in the game.
Part B: … with consideration of cultural factors. Cultural factors are encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people.
Connexus was created to address the frustrations of new and non-native players by offering an interactive, educational, and culturally adaptable gameplay experience that NYT Connections currently is lacking. This game is designed for more inclusivity across cultures by bridging language gaps while still maintaining the challenge and fun of the original game especially for English Language Learners (ELLs). It addresses the need for accessibility and engagement by helping players who would struggle with ambiguities in word meanings due to multiple word definitions, cultural references or elitist knowledge assumptions as the creator of the game mentions. This is accomplished with the virtual companion that will retrieve hints from an API and also it supports customizable puzzles that allows for players to come up with their own puzzles either for educational use or for fun. By allowing for a personal twist, you can create different cultural contexts as well which would make the game more inclusive. Also, Connexus provides physical and movable blocks that would shift from a purely digital interface to a more engaging gameplay that would be beneficial for different learning styles.
Part C: … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.
Connexus doesn’t have too many significant environmental considerations other than the power consumption and physical materials. Each block has an on-board microcontroller and LCD display that needs to be powered by a battery. In order to reduce the amount of waste that our project generates in the form of dead batteries (which could be harmful to the environment if not disposed of correctly), we opted to use rechargeable batteries with an on/off switch. This way, the same batteries could be used over and over again until they run out of recharge cycles, and energy can be conserved when not in use by switching the batteries off.
Additionally, the RPi that is hosting the web app will be consuming power as it makes API calls to the dictionary API and coordinates the hardware and software components of our system. These processes consume power, so we want to minimize the communication that the web app has to make with external APIs and the hardware subsystems (i.e. blocks). Writing efficient code based on interrupts and requests as opposed to constantly polling for responses is one way we plan to minimize communication. Furthermore, we “prefetch” all the dictionary API calls/responses at the start of the game and then access these locally in the program, as opposed to making repeated API calls every time a user navigates to a word’s “hint” page, so as to minimize our interaction with the external API. All these measures are in an effort to not waste unnecessary power.
Weekly Questions
• What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
The primary risk we anticipate would be the multi block integration with the grid. We have only tested our code logic with one block’s circuit since the rest of our components had not yet arrived. If there are issues with using the multiplexer to interface with multiple UART lines, we will have to explore alternatives. The risk can be managed by modifying the program to utilize other communication protocols like I2C instead. If the latency is too high, the complexity of the UART communication algorithm can be simplified.
Another risk is the secure placement of parts within the block. In each block, there will be the Pico, LCD, battery components and pogo pins. It is important to secure the components to maintain the electrical connection. Initially, we soldered wires directly from the pogo pin wires to the LCD breakout board, but the wires would break easily. Our solution was to solder female pins onto the other side of the Pico breakout board to allow us to plug in wires for the pogo pins. We aim to test the completed blocks with this layout to see if the connection remains secure. Otherwise, our mitigation would be to make 3D printed holders for the components within the blocks to hold them in place.
• Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
For the design, we were initially going to use wood to make the grid. However, we looked into procuring wood but realized that it was too expensive for our budget. We decided to switch to using cardboard instead since it was easier to build and cheaper to procure, while still maintaining the rigidity we need for the grid. The cost for our project will be reduced with this change.
• Provide an updated schedule if changes have occurred.
For our schedule, we are on track and there has not been major changes. We are not going to build the actual grid yet, but instead focus on prototyping a platform to place the grid pogo pins on for testing. The plan now is to focus on having fully built blocks to test the end to end functionality of multiple blocks with the grid circuit.
• This is also the place to put some photos of your progress or to brag about a component you got working
In the past week, we have fully built one block including laser cutting all the cutouts for the pogo pins and charging port, and placing all the soldered components into the block. We have also soldered all the components to prepare them for the remaining blocks, only being left with the laser cutting of the blocks before they can be fully tested.
On the software side, we have fleshed out the design for the Embedded Controller, Game Controller and Web App functions and how they interface with one another. We have also written out all the code functions we need for the RPi and Pico and tested a single Pico with the RPi.
We also have a functioning webapp with Merriam Webster API integration and was able to simulate submission and loading of words from the webapp side. There is also exposed API endpoints for the embedded controller to trigger when the submit button is pressed.
Everything is ready for a primary end-to-end integration and testing next week!
