We wanted to create an interactive user experience to highlight the amount of ads that we are exposed to in a browsing session online. Many times, native ads are hidden within the layout of a page, but, with web-parsing, we can show just how many and what kind of ads we are exposed to in our day-to-day online lives.
What it does
We launch a C script that pthreads multiple processes. One of these processes is a Unity C# script which launches a virtual environment with a keyboard that the user can enter a website url. It behaves as a producer for a python consumer script, which uses that url to launch a selenium browser and scrapes the HTML contents for all of the ads. From here, the roles of these two scripts flips and the python script produces the number of advertisements, n, on that page to the C# consumer, which then creates a game with n monsters that represent the number of ads on the page that the user must avoid in the virtual environment. All of this happens in real-time with the given user input.
How we built it
We split tasks among the team members in creating the virtual environment and creating the interactive interface. We made assumptions about what we could reasonably expect the other team to build and using those values as default parameters. In so doing, we could best utilize our varying skill sets.
Challenges we ran into
Seeing as Unity is much easier to run in Windows (non-Linux command prompt), creating a C script on a Mac OS was difficult to port over to the Windows machine for testing, especially since creating the environment is time consuming to ensure that the user will have a pleasant experience in the environment. Thus, we struggled porting libraries, such as and . We tried to use , which has most Linux functionality on Windows, though slower, but there were more compilation errors than it was worth resolving. Furthermore, debugging a concurrent algorithm had its challenges along with creating multiple user environments in a Unity script.
Accomplishments that we're proud of
We are proud of the fact that we have working component parts of this project that we, at many times, didn't think that we were going to get anywhere near finishing. The fact that we have a presentable project, in two different working component parts that simulate the response of the other, is an accomplishment in it of itself.
What we learned
We learned about thread packaging in C, implementing game algorithms in Unity, interaction between Unity and backend programs, and that we shouldn't give up on a project before you've eaten dinner and had a cup of coffee.
What's next for Advertisement Monster
Obviously, we would love to fully link both parts of this project, but there are so many more things that we can do. Our backend program can track so many more things than merely counting the number of ads on the page. It can get the conversion rate on a specific type of ad, the correlation between the number of ads on a page and the amount of time spent on that page, where on the page the ads come from, and so much more. In the Unity program, we can add all sorts of visualization to these statistics along with the graphics at the end of the game, we can keep the browser up and have the user shoot at the physical ad as it appears on the page and have that take out the monsters, and, again, there are so many more possibilities than just that. This would hopefully help users become more comfortable with what they are browsing, which ads they see, and how often they see them.
Log in or sign up for Devpost to join the conversation.