## Inspiration

Our team firmly believes that a hackathon is the perfect opportunity to learn technical skills while having fun. Especially because of the hardware focus that MakeUofT provides, we decided to create a game! This electrifying project places two players' minds to the test, working together to solve various puzzles. Taking heavy inspiration from the hit videogame, "Keep Talking and Nobody Explodes", what better way to engage the players than have then defuse a bomb!

## What it does

The MakeUofT 2024 Explosive Game includes 4 modules that must be disarmed, each module is discrete and can be disarmed in any order. The modules the explosive includes are a "cut the wire" game where the wires must be cut in the correct order, a "press the button" module where different actions must be taken depending the given text and LED colour, an 8 by 8 "invisible maze" where players must cooperate in order to navigate to the end, and finally a needy module which requires players to stay vigilant and ensure that the bomb does not leak too much "electronic discharge".

## How we built it

**The Explosive**

The explosive defuser simulation is a modular game crafted using four distinct modules, built using the Qualcomm Arduino Due Kit, LED matrices, Keypads, Mini OLEDs, and various microcontroller components. The structure of the explosive device is assembled using foam board and 3D printed plates.

**The Code**

Our explosive defuser simulation tool is programmed entirely within the Arduino IDE. We utilized the Adafruit BusIO, Adafruit GFX Library, Adafruit SSD1306, Membrane Switch Module, and MAX7219 LED Dot Matrix Module libraries. Built separately, our modules were integrated under a unified framework, showcasing a fun-to-play defusal simulation.

Using the Grove LCD RGB Backlight Library, we programmed the screens for our explosive defuser simulation modules (Capacitor Discharge and the Button). This library was used in addition for startup time measurements, facilitating timing-based events, and communicating with displays and sensors that occurred through the I2C protocol.

The MAT7219 IC is a serial input/output common-cathode display driver that interfaces microprocessors to 64 individual LEDs. Using the MAX7219 LED Dot Matrix Module we were able to optimize our maze module controlling all 64 LEDs individually using only 3 pins. Using the Keypad library and the Membrane Switch Module we used the keypad as a matrix keypad to control the movement of the LEDs on the 8 by 8 matrix. This module further optimizes the maze hardware, minimizing the required wiring, and improves signal communication.

## Challenges we ran into

Participating in the biggest hardware hackathon in Canada, using all the various hardware components provided such as the keypads or OLED displays posed challenged in terms of wiring and compatibility with the parent code. This forced us to adapt to utilize components that better suited our needs as well as being flexible with the hardware provided.

Each of our members designed a module for the puzzle, requiring coordination of the functionalities within the Arduino framework while maintaining modularity and reusability of our code and pins. Therefore optimizing software and hardware was necessary to have an efficient resource usage, a challenge throughout the development process.

Another issue we faced when dealing with a hardware hack was the noise caused by the system, to counteract this we had to come up with unique solutions mentioned below:

## Accomplishments that we're proud of

During the Makeathon we often faced the issue of buttons creating noise, and often times the noise it would create would disrupt the entire system. To counteract this issue we had to discover creative solutions that did not use buttons to get around the noise. For example, instead of using four buttons to determine the movement of the defuser in the maze, our teammate Brian discovered a way to implement the keypad as the movement controller, which both controlled noise in the system and minimized the number of pins we required for the module.

## What we learned

* Familiarity with the functionalities of new Arduino components like the "Micro-OLED Display," "8 by 8 LED matrix," and "Keypad" is gained through the development of individual modules.
* Efficient time management is essential for successfully completing the design. Establishing a precise timeline for the workflow aids in maintaining organization and ensuring successful development.
* Enhancing overall group performance is achieved by assigning individual tasks.

## What's next for Keep Hacking and Nobody Codes

* Ensure the elimination of any unwanted noises in the wiring between the main board and game modules.
* Expand the range of modules by developing additional games such as "Morse-Code Game," "Memory Game," and others to offer more variety for players.
* Release the game to a wider audience, allowing more people to enjoy and play it.
## Inspiration

After looking at the Hack the 6ix prizes, we were all drawn to the BLAHAJ. On a more serious note, we realized that one thing we all have in common is accidentally killing our house plants. This inspired a sense of environmental awareness and we wanted to create a project that would encourage others to take better care of their plants.

## What it does

Poképlants employs a combination of cameras, moisture sensors, and a photoresistor to provide real-time insight into the health of our household plants. Using this information, the web app creates an interactive gaming experience where users can gain insight into their plants while levelling up and battling other players’ plants. Stronger plants have stronger abilities, so our game is meant to encourage environmental awareness while creating an incentive for players to take better care of their plants.

## How we built it + Back-end:

The back end was a LOT of python, we took a new challenge on us and decided to try out using socketIO, for a websocket so that we can have multiplayers, this messed us up for hours and hours, until we finally got it working. Aside from this, we have an arduino to read for the moistness of the soil, the brightness of the surroundings, as well as the picture of it, where we leveraged computer vision to realize what the plant is. Finally, using langchain, we developed an agent to handle all of the arduino info to the front end and managing the states, and for storage, we used mongodb to hold all of the data needed.
[backend explanation here]

### Front-end:

The front-end was developed with **React.js**, which we used to create a web-based game. We were inspired by the design of old pokémon games, which we thought might evoke nostalgia for many players.

## Challenges we ran into

We had a lot of difficulty setting up socketio and connecting the api with it to the front end or the database

## Accomplishments that we're proud of

We are incredibly proud of integrating our web sockets between frontend and backend and using arduino data from the sensors.

## What's next for Poképlants

* Since the game was designed with a multiplayer experience in mind, we want to have more social capabilities by creating a friends list and leaderboard
* Another area to explore would be a connection to the community; for plants that are seriously injured, we could suggest and contact local botanists for help
* Some users might prefer the feeling of a mobile app, so one next step would be to create a mobile solution for our project
## Introducing Nuisance

### Inspiration

When prompted with the concept of **Useless Inventions**, and the slight delay from procrastinating the brainstorming process of our idea, we suddenly felt very motivated to make a little friend to help us. Introducing **Nuisance**. A (not so friendly) Bot that will sense when you have given him your phone. Promptly running away, and screaming if you get too close. An interesting take on the game of manhunt.

### What it does

**Nuisance** detects when a *phone* is placed in its possession. It then embarks on a random journey, in an effort to play everyone's favourite game, keep away. If a daring human approaches before *Nuisance* is ready to end the game, he screams and runs away; only a genuine scream of horror stands a chance of reclaiming the device. Adding a perfect touch of embarrassment and a loss of dignity.

### How we built it

1. Arduino Due
2. 2 wheels
3. Caster Wheel
4. H-bridge/ Motor Driver
5. Motors
6. 2 UltraSonic Sensors
7. Noise Sound Audio Sensor
8. PIR Motion sensor
9. 1 Grove Buzzer v1.2
10. large breadboard
11. 2 small breadboard
12. OCD display
13. Force sensor
14. 9V battery
15. 3\*1.5 = 4.5 V battery
16. A bit of wires
and a **lot** of cardboard

*and some software*

### Challenges we ran into

* different motor powers / motors not working anymore

We had an issue during the debugging phase of our code regarding the *Ultrasonic Sensors*. No matter what was done, they just seemed to constantly be timing out. After looking extensively into the issue, we figured out that the issue was neither hardware nor software related. The breadboard had sporadic faulty pins that we had to be considerate of. Thus causing us to test the rest of the breadboard for integrity.

Furthermore, we had a lot of coding issues regarding the swap between our Arduino uno and due. The Arduino due did not support the same built in libraries, such as tone (for the buzzer).

We also had issues with the collision detection algorithm at first. However, with a lil tenacity, *and the power of friendship*, you too can solve this problem. We originally had the wrong values being processed, causing out algorithm to disregard the numbers we required to gauge distance accurately.

### Accomplishments that we're proud of

* completed project..?

### What we learned

* yell at a nuisance if you want ur stuff back?

Never doubt the

## What's next for Nuisance

Probably more crying