## Inspiration

A twist on the classic game '**WikiRacer**', but better!
Players play Wikiracer by navigating from one Wikipedia page to another with the fewest clicks. WikiChess adds layers of turn-based strategy, a dual-win condition, and semantic similarity guesswork that introduces varying playstyles/adaptability in a way that is similar to chess.
It introduces **strategic** elements where players can choose to play **defensively or offensively**—misleading opponents or outsmarting them. **Victory can be achieved through both extensive general knowledge and understanding your opponent's tactics.**

## How to Play

**Setup**:
Click your chess piece to reveal your WikiWord—a secret word only you should know. Remember it well!
**Game Play**:
Each turn, you can choose to either **PLAY** or **GUESS**.

### **PLAY Mode**:

* You will start on a randomly selected Wikipedia page.
* Your goal is to navigate to your WikiWord's page by clicking hyperlinks.
	+ For example, if your WikiWord is "BANANA," your goal is to reach the "Banana" Wikipedia article.
* You can click up to three hyperlinks per turn.
* After each click, you'll see a semantic similarity score indicating how close the current page's title is to your WikiWord.
* You can view the last ten articles you clicked, along with their semantic scores, by holding the **TAB** key.
* Be quick—if you run out of time, your turn is skipped!

### **GUESS Mode**:

* Attempt to guess your opponent’s WikiWord. You have three guesses per turn.
* Each guess provides a semantic similarity score to guide your future guesses.
* Use the article history and semantic scores shown when holding **TAB** to deduce your opponent's target word based on their navigation path.
**Example**:
If your opponent’s target is "BANANA," they might navigate through articles like "Central America" > "Plantains" > "Tropical Fruit." Pay attention to their clicks and semantic scores to infer their WikiWord.

## Let's talk strategy!

**Navigate Wisely in PLAY Mode!**

* Your navigation path's semantic similarity indicates how closely related each page's title is to your WikiWord. Use this to your advantage by advancing towards your target without being too predictable. Balance your moves between progress and deception to keep your opponent guessing.

**Leverage the Tug-of-War Dynamic**:

* Since both players share the same Wikipedia path, the article you end on affects your opponent's starting point in their next PLAY turn. Choose your final article wisely—landing on a less useful page can disrupt your opponent's strategy and force them to consider guessing instead.
	+ However, if you choose a dead end, your opponent may choose to GUESS and skip their PLAY turn—you’ll be forced to keep playing the article you tried to give them!

**Semantic Similarity**: **May Not Be the Edge You Think It Is**

* Semantic similarity measures how closely related the page's title is to your target WikiWord, not how straightforward it is to navigate to; use this to make strategic moves that might seem less direct semantically, but can be advantageous to navigate through.

**To Advance or To Mislead?**

* It's tempting to sprint towards your WikiWord, but consider taking detours that maintain a high semantic score but obscure your ultimate destination. This can mislead your opponent and buy you time to plan your next moves.

**Adapt to Your Opponent**:

* Pay close attention to your opponent's navigation path and semantic scores. This information can offer valuable clues about their WikiWord and inform your GUESS strategy. Be ready to shift your tactics if their path becomes more apparent.

**Use GUESS Mode Strategically**:

* If you're stuck or suspect you know your opponent’s WikiWord, use GUESS mode to gain an advantage. Your guesses provide semantic feedback, helping refine your strategy and closing in on their target.
	+ Choosing GUESS also automatically skips your PLAY turn and forces your opponent to click more links. You can get even more semantic feedback from this, however it may also be risky—the more PLAY moves you give them, the more likely they are to eventually navigate to their own WikiWord.

## How we built it

Several technologies and strategies were used to develop WikiChess. First, we used **web scraping** to fetch and clean Wikipedia content while bypassing iframes issues, allowing players to navigate and interact with real-time data from the site. To manage the game's state and progression, we updated game status based on each hyperlink click and used **Flask** for our framework. We incorporated **semantic analysis** using spaCy to calculate **NLP**similarity scores between articles to display to players. The game setup is coded with **Python**, featuring five categories—animals, sports, foods, professions, and sciences—generating two words from the same category to provide a cohesive and engaging experience. Players start from a page outside the common category to add an extra challenge. For the front end, we prioritized a user-friendly and interactive design, focusing on a minimalist aesthetic with **dynamic animations** and many smooth transitions. Front-end techstack was made up of **HTML/CSS, JS, image generation tools, Figma.**

## Challenges we ran into

One of our biggest challenges was dealing with **iframe access controls**. We faced persistent issues with blocked access, which prevented us from executing any logic beyond simply displaying the Wikipedia content. Despite trying various methods to bypass this limitation, including using proxy servers, the frequent need to check for user victories made it clear that iframes were not a viable solution. This challenge forced us to pivot from our initial plan of handling much of the game logic on the client side using JavaScript. Instead, we had to **rely heavily on backend solutions**, particularly web scraping, to manage and update game state.

## Accomplishments that we're proud of

Despite the unexpected shift in our solution approach, which significantly increased the complexity of our backend and required **major design adjustments**, we managed to overcome several challenges. Integrating web scraping with real-time game updates and **ensuring a smooth user experience** were particularly demanding. We tackled these issues by strengthening our backend logic and refining the frontend to enhance user engagement. Despite the text-heavy nature of the Wikipedia content, we aimed to make the interface visually appealing and fun, ensuring a seamless and enjoyable user experience.

## What we learned

As beginners in hacking, we are incredibly proud of our perseverance through these challenges. The experience was a great learning opportunity, and we successfully delivered a product that we find both enjoyable and educational. **Everyone was able to contribute in their own way!**

## What's next for WikiChess

Our first priority would be to implement an **online lobby feature** that would allow users to play virtually with their friends rather than only locally in person. We would also like to introduce more word categories, and to have a **more customized metric than semantics for the similarity score**. Ideally, the similarity score would account for the structure of Wikipedia and the strategies that WikiRacers use to reach their target article other than just by going with the closest in word meaning. We would also like to introduce a **timer-based gameplay** where players would be limited to time instead of turns to encourage a faster-paced game mode.
**[DEMO VIDEO LINK — On Loom!](https://www.loom.com/share/2b15581b7fe34ec7974c26f24ad3829f?sid=87ea8fee-5efa-46c1-984f-bb6bab8d664a)** ✨

## Inspiration

We were inspired by how Wikipedia links to other Wikipedia pages so that you can find the information quickly and painlessly if you don't know what a word means. We felt this technology would save people a lot of time parsing jargon-heavy documents, and help you *understand* your readings for school!

## What it does

Source Scanner takes raw text, and intelligently selects words/phrases that can be reasonably assumed to need definition or extra information, and makes it so that we can hover over those words and find helpful definitions, as well as links off-site to places such as Wikipedia for further reading!✨

We know that when you're reading, it takes a while for your brain to really process and understand words, and on occasion, we "gloss" over words we can usually infer through context. While this helps our comprehension skills, we want to make information more accessible for students to *actually* learn new vocabulary and concepts that they may not have learned on their own!

## How we built it 👩🏻‍🔬

On the backend, when a user makes a request for our web app to parse input and return more information, our app sends the user-inputted information to OpenAI's API with an engineered prompt to parse the user input for words and concepts that may need to be defined and puts those, along with definitions, into an easily parse-able data structure. From there, each of those concepts is fed into [Metaphor's API](https://metaphor.systems/) to generate relevant links, and the best link by confidence score is displayed as a hyperlink to the user upon hovering over the previously selected word, along with a definition. We use MongoDB to store user information, Google Cloud for user authentication, and Vercel for website deployment.

* ReactTS
* TailwindCSS
* NextJS
* tRPC
* MongoDB
* Prisma
* Google Cloud
* Metaphor API
* OpenAI API

## Challenges we ran into

One of the main challenges our group ran into was integrating so many moving parts and getting them to work together seamlessly. Getting OAuth with Google Cloud to work with tRPC, Prisma, and MongoDB Atlas was quite the challenge with the different ways they interact with each other. Another hurdle was prompt engineering to request meaningful data from ChatGPT and Metaphor because there's a lot of specificity and accuracy that need to come together to get something that would benefit the user. Finally, having specific UI components, such as tooltips, actually helps, rather than hinders, the user experience was a definite learning curve.

## Accomplishments that we're proud of

We are very proud of the fact that we not only successfully achieved a design with a large number of moving parts, but we did so while building out several well-designed pages that are easily understandable for site users.

## What we learned 🫶🏼

We learned a lot about working with the OpenAI and Metaphor APIs, as well as the power of a good prompt and a better AI when it came time to parse through the input. We also appreciated the opportunity to refamiliarize ourselves with React and design elements of websites.

## What's next for SourceScanner ⚡️⚡️

The next step for SourceScanner is adding more of what we call "lenses," or areas of the internet to search for answers. We only have one (the "Wikipedia" lens), but we plan to expand to other prompts and websites for more niche information, such as C or C++ documentation.
## Inspiration

2 days before flying to Hack the North, Darryl forgot his keys and spent the better part of an afternoon retracing his steps to find it- But what if there was a personal assistant that remembered everything for you? Memories should be made easier with the technologies we have today.

## What it does

A camera records you as you go about your day to day life, storing "comic book strip" panels containing images and context of what you're doing as you go about your life. When you want to remember something you can ask out loud, and it'll use Open AI's API to search through its "memories" to bring up the location, time, and your action when you lost it. This can help with knowing where you placed your keys, if you locked your door/garage, and other day to day life.

## How we built it

The React-based UI interface records using your webcam, screenshotting every second, and stopping at the 9 second mark before creating a 3x3 comic image. This was done because having static images would not give enough context for certain scenarios, and we wanted to reduce the rate of API requests per image. After generating this image, it sends this to OpenAI's turbo vision model, which then gives contextualized info about the image. This info is then posted sent to our Express.JS service hosted on Vercel, which in turn parses this data and sends it to Cloud Firestore (stored in a Firebase database). To re-access this data, the browser's built in speech recognition is utilized by us along with the SpeechSynthesis API in order to communicate back and forth with the user. The user speaks, the dialogue is converted into text and processed by Open AI, which then classifies it as either a search for an action, or an object find. It then searches through the database and speaks out loud, giving information with a naturalized response.

## Challenges we ran into

We originally planned on using a VR headset, webcam, NEST camera, or anything external with a camera, which we could attach to our bodies somehow. Unfortunately the hardware lottery didn't go our way; to combat this, we decided to make use of MacOS's continuity feature, using our iPhone camera connected to our macbook as our primary input.

## Accomplishments that we're proud of

As a two person team, we're proud of how well we were able to work together and silo our tasks so they didn't interfere with each other. Also, this was Michelle's first time working with Express.JS and Firebase, so we're proud of how fast we were able to learn!

## What we learned

We learned about OpenAI's turbo vision API capabilities, how to work together as a team, how to sleep effectively on a couch and with very little sleep.

## What's next for ReCall: Memories done for you!

We originally had a vision for people with amnesia and memory loss problems, where there would be a catalogue for the people that they've met in the past to help them as they recover. We didn't have too much context on these health problems however, and limited scope, so in the future we would like to implement a face recognition feature to help people remember their friends and family.