Spellcaster

Host Settings

WE ARE GOING FOR BEST UI/UX!

Inspiration

This project stemmed from a stupid joke I made to my co-worker (now project partner) during our shift as CS100 graders. We were told about CutieHack's theme by a student in the class. My partner, being a fan of Harry Potter, said, "Code Quest? Like wizards and spells?" I jokingly responded that it would be funny if we made a "SPELLing bee for wizards." We both thought it was a pretty cool idea and decided, right at that moment, to attend our first ever hackathon together.

We were inspired primarily by Monkeytype, but have not seen any game of this specific nature ourselves.

What it does

Spellcaster is a 1v1 online multiplayer game in which two players compete to see who can spell complex spell names (i.e. "Avada Kedavra") quickly and accurately. The game expects you to listen to these spell names and, without ever seeing your own input, spell them out on your keyboard. Using the backspace key is also not allowed. If one player performs much more dominantly than their opponent, they can perform a knockout and win the game without finishing all of the rounds. At the end of the game, each players speed and accuracy is revealed, and a winner is chosen if one has not already prevailed.

How we built it

We initially wanted to avoid the headache of web sockets, but swapping a laptop back and forth would be a serious hindrance to gameplay. So we began by setting up skeleton code (which we called "Phase 1") with socket.io. After that, we worked on making sure an interrupted TLS connection between client and server could be established. Then, we began working on the node.js, worrying about lobby creation and state management. React.js + Tailwind was our choice for building a frontend as quick as possible. And lastly, we leveraged AI tools (GPT 5.1 Codex + Claude Sonnet 4.5) while keeping close watch over recommended changes. Both of us are experienced in this stack and therefore used LLMs as a tool to boost productivity.

Challenges we ran into

Host/challenger race conditions and edge cases. When the host left the game, the challenger would be prompted with a defeat. And occasionally, the host would lose the ability to click "Enter" to "cast their spell," in which case they also were not able to score points for that round at all.
Making keyboard input appear on the visual keyboard during the actual game. This taught us a lesson in that even things that appear really simple could end up being painful.
Component styling getting jumbled up.
The "beam" that the wizards push toward eachother during the game was (and still is) a particularly difficult challenge. We can't seem to be satisfied with the styling because we're really only using native browser elements.

Accomplishments that we're proud of

UI/UX. We think that the colorful, "wizard-y" frontend is quite appealing. Our efforts were geared toward trying to avoid overwhelming potential players.
Our teamwork. We really maximized our productivity and refrained from leaving our table for well over eleven hours. We also did a great job of separating concerns and not getting in eachother's way.

What we learned

Work should not be divided evenly. It should be divided according to each others skills. When we had trouble with our tasks in the last twelve hours, we simply swapped tasks, eliminated the bottleneck, and proceeded. It didn't matter if we had to take each other's laptops.