"Sus" (Real Life Among Us)

During the project several of the students asked "Why are we using REST calls to pass/fetch data? Couldn't we set up a socket connection instead?" There's a few reasons for this, but first we should at least talk about the pros and cons of using REST.

On the pros side, it's quite easy to support treating all our networking like they are web requests.  There are numerous libraries in place to handle all the data transfer, minimal networking involved, and the actions are well understood and documented.  On top of this, testing is made easier as we could easily try many of our API calls with nothing more than a smartphone and it's web browser.

Using a shared networking standard also makes integration with other apps easier.  Early on there was a lot of discussion about building additional stations out of computers, projectors, raspberry pi's, etc.  By using such a ubiquitous standard as web requests, any software and hardware we wanted to use would already be compatible.  If could fetch a webpage from the internet then it could be wired into our game.

There are a couple cons though.  The largest of these is the asynchronous "pull" nature of REST.  Data can only be requested, it can't be pushed.  This means if a change happens on the server, then there's no immediate way to tell the clients about it.  Instead, we had to design into the scanners a regular "keepalive" check.  This was a timer which would contact the server every half second to see if there were any updates the scanner cared about.

This naturally leads to a couple more issues.  Firstly, this meant we had to do more work keeping track of our game states and player states, as different scanners would call in at different times.  There was also no guarantee of when a scanner would update next, so it was possible for scanners to receive updates at different times.  There were several instances during play where scanners temporarily lost network connection and missed updates like voting for upwards of 4-5 seconds.

Theoretically this also wasted a bit of network bandwidth and put stress on the server, as every scanner was pinging home twice a second whether there were updates or not.  In reality though we never saw any degradation with just 8 scanners, and a stress test using Postman showed the server could process at least several hundred requests/second, so the 16-25 requests we were throwing at it weren't really an issue.

Overall though, the biggest reason we went with REST was to give the students a real-life experience using it.  The vast majority of programming work out there today is web-based; it's something they'll be going into anyway.  A project like this taught them all how to build APIs, make GET/POST requests, and move data, while being a lot more fun than simply building out a forum board or accounting application :)

There were two additional tools in the files which deserve a little mentioning.

The first is an RFID scanner application. The idea was we were going to use it to scan the RFID tags to get their UIDs.  We'd then store the UIDs on the server in a simple table referencing the actual tag name.

To be sure, the tag UIDs are stored on the server and work exactly like that.  Every time a scanner 'scans' an RFID, it calls the server with the UID to ask what the name of the tag is.  This way we could decouple the actual tags from the game code on the scanner - or even dynamically remap them without rebooting everything.  I'm not sure if the RFID scanner app is functional though.

It's fairly crude and wiping/rewriting the memory of the little ESP32's hundreds of times certainly isn't recommended in the long term.  But using it rapidly increased the speed at which we could prototype one - or multiple - scanners simultaneously.  

In the time it took to copy the changed code to one scanner manually we could flash with this script to 4-5 prototypes, test, make changes, and reflash again.  It also centralised the code as the raspy server would just pull the main dev branch straight from Github, then everything would work off that copy.  

This second item is fully functional and is in AD.py (and integrated into controller/model.py of the API)

This project is complete and will no longer be updated (unless one of the team chooses to pick it up and work on it independently).  

The game in it's current state works and is playable.  Specifically, the following features have been built:

• Connection to the central server
• Scanning of ID badges/stations/special tags
• assigning of teams
• playing of minigames
• sabotages
• murdering
• voting
• game winning/losing

What was not implemented:

• Rejoining of games in progress (I.E. if your scanner is turned off or loses wifi)
• Ghosts

What could be done better:

• Code needs a major refactoring (very messy, work of a dozen people with varying skill levels in a bit of a rush)
• 3d printed case needs a screen cover (too easy to see each other's screens over one's shoulders)
• A written "rulebook" covering actions required by humans
• Several minigames could do with tightening up/minor bug fixes.  One potentially locks you out of doing anything until a voting session starts