-
-
Room Selection
-
Pre game set up - shows the cards on the players hand and cards on the field
-
Card dealed to each of the players
-
Players playing their cards onto the field where they can be seen by all players
Inspiration
Before March 2020, the senior year of high school was essentially spent playing card games in the study lounge. We played many different games and used a variety of rulesets. However, various events contributed to the decline of such connections. From quarantine, social distancing, and de-densifying due to COVID-19, to moving away from home for college, all of us could agree that something needed to be done about rekindling these connections. There had been no single, casual, flexible site to just play what we want, by our own rules, so we decided to create our own.
What it does
As you would play a physical card game, Card Party provides a deck of cards and allows you to do anything that you want to do. There is no limit to the number of participants. It is fast, almost instantaneous, giving players a taste of what it’s like to play in person again. There are no restrictions on turn orders, draw orders or anything at all - just a few helper functions to do mundane tasks like dealing cards. All a group of friends need to do is to join a room with the same code - any of their choosing - and they can get playing!
How we built it
Card Party is a full stack web application with a React frontend and a uWSGI Python server. Business logic is handled on the server side, with the front end only serving to display and send messages to the backend. However, the core of our application is the implementation of WebSockets on our Python server to provide a fast and reliable communication channel between the frontend client and server, and to ensure that the cards are played as close to real time as possible. We used the Sockets.IO library on the frontend, and python-socketsio library for the backend. We decided to serve the Python server over uWSGI for scalability. The frontend is hosted on Github-Pages, while the backend is hosted on Heroku.
Challenges we ran into
There were three big challenges that we had faced while working on the project. The first challenge is understanding WebSockets which is something new to us. Although the message-broadcasting system seemed easy to understand, it was nevertheless still difficult to understand how to implement it. We decided to have one team member focused on learning it, who then shared it to everyone else. Running a WSGI server was also pretty new to us. We spent a lot of time trying to figure out why it did not work when hosted, and after spending hours tearing our hairs out, we realized that it was a simple problem - the server was treating the port number as a path instead, and all we had to do was remove it. Finally, time would always be a problem for hackathons - trying to do as much work as possible with as little sleep as necessary. We decided to write up API contracts between the frontend, the websockets and the room instances so that we could work on different things simultaneously.
Accomplishments that we're proud of
We were incredibly proud of creating a pretty complete web application using mostly technology we are not too familiar with - and within such a short timeframe. It was an incredible feeling to be able to squash out most of the bugs (leaving only “features”), and yet still have some time to work on improving the user design. It was cool to turn an idea we have into an actual product - one that we think has a use even after the pandemic, in allowing people to connect to each other wherever they are. And, as engineering students, we were definitely proud of how great our acting was.
What we learned
We gained a whole lot of knowledge regarding the React framework, working with WebSockets, why writing good API contracts is important, and how to implement a WSGI server (and why). However, more important than these technical knowledge, we realized that rest is important! Your brain does not think well when you are tired, and in the end, we probably spent more time on simple problems (like the WSGI port number one) that could have been easily fixed with a little sleep. In the same vein, always try the easiest-looking solution first!
What's next for Card Party
Card Party has massive potential for growth. With a little more time (and expertise), we can probably get the web application to look much nicer, smoother, and with more animations. Beyond that, Card Party could be greatly expanded by working on some features we did not have the time for, like flipping cards, dealing with the board, and taking from another player’s hand. This opens up Card Party to a much larger possible pool of games. Card Party serves to be a single point of contact for a multitude of card games, but why stop there? It would also be helpful to add additional tools that may be used by various games, like a notepad, chips, or a leaderboard system. Finally, we believe that it would be a good idea to code up some logic for common games such as Blackjack, One Card, President, and the like - for when you just don’t know what to play - or even when you know exactly what you want to play.
Log in or sign up for Devpost to join the conversation.