A prototype system for directing tourists and residents alike from busy and popular parts of Aberdeen to those which are less popular, and less busy. Built for the Code the City Hack Weekend 30. Developed by Josh Britain and Caitlin Thaeler, with additional help/moral support from Fariha Ibhnat, Iain Maki Guan, Andreas Maita, and Holly Sinclair.
At the heart of the system are 'portals', displays with cameras creating a two-way link between a busy location and a less busy one (for example - Union Square could connect to Greyhope Bay). If two users stand in front of either portal, they can see and possibly even speak to each other as if looking through a window. This system already exists, linking Vilnius, Lithuania to Lublin, Poland. The difference here is that it is possible to practically travel from one portal to the other in a matter of minutes instead of hours or days.
In order to encourage people to visit the other end of the portal, a game is introduced. This game encourages users to travel to a given location by counting how many people have done so, providing rewards if enough people do (i.e if 100 people travel to the location, then all 100 of them get a reward. Further goals could increase the reward.). How these rewards will operate is out of the scope of this prototype but could be integrated with abdn go. The counter would probably reset on a schedule, for example every 24 hours. Tracking how many people have been to both locations is done by the user scanning a QR code. The server identifies the user and if they have scanned the QR codes for both portals, the counter is incremented.
For the prototype implementation, the applications runs as two different web apps. The main user interface on the displays and on user's web browsers when they scan the QR code is a React app (in the aberlink subdirectory). Separated from this is a basic API which uses express, which stores/manages the counter and serves QR codes (although these are actually generated by an external API) and tracks users. User visits are tracked by storing the IP of the client when they load the /visit API route, along with an array of every location they have visited (this is embedded in the link served by the QR code for the relevant location). If the user is seen to have visited, for example, locations 1 and 2, then the counter is incremented. If the counter reaches a specified goal (i.e 100), then the main board displays a message indicating the goal has been reached. The actual video stream for each portal is served through two Twitch streams. The original intention was to use YouTube, but it is not possible to embed an unlisted YouTube stream and none of us had an existing account with streaming access that we were willing to go live on publicly.
- The API is currently extremely insecure
- Using Twitch for webcam streaming is frankly a terrible way of doing things since it requires two accounts for every portal. Ideally something like https://gstreamer.freedesktop.org/ would be used.
- For our limited demonstration, we used two laptops (an old MacBook Pro and a Microsoft Surface Go). In an actual implementation, a screen similar to the billboards you see on the sides of bus stations would be used (including protective plexiglass to keep the boozers from smashing our hard work!). If two cameras instead of one were available, face tracking and depth mapping could be used to give the illusion of an actual portal, distorting the image based on the head position of the viewer. Something like this paper I found could also be used to negate the need for face tracking and allow multiple viewers without breaking the illusion.