## About Us

Discord Team Channel: #team-64

omridan#1377,
dylan28#7389,
jordanbelinsky#5302,
Turja Chowdhury#6672

Domain.com domain: positivenews.space

## Inspiration

Over the last year headlines across the globe have been overflowing with negative content which clouded over any positive information. In addition everyone has been so focused on what has been going on in other corners of the world and have not been focusing on their local community. We wanted to bring some pride and positivity back into everyone's individual community by spreading positive headlines at the users users location. Our hope is that our contribution shines a light in these darkest of times and spreads a message of positivity to everyone who needs it!

## What it does

Our platform utilizes the general geolocation of the user along with a filtered API to produce positive articles about the users' local community. The page displays all the articles by showing the headlines and a brief summary and the user has the option to go directly to the source of the article or view the article on our platform.

## How we built it

The core of our project uses the Aylien news API to gather news articles from a specified country and city while reading only positive sentiments from those articles. We then used the IPStack API to gather the users location via their IP Address. To reduce latency and to maximize efficiency we used JavaScript in tandem with React opposed to a backend solution to code a filtration of the data received from the API's to display the information and imbed the links. Finally using a combination of React, HTML, CSS and Bootstrap a clean, modern and positive design for the front end was created to display the information gathered by the API's.

## Challenges we ran into

The most significant challenge we ran into while developing the website was determining the best way to filter through news articles and classify them as "positive". Due to time constraints the route we went with was to create a library of common keywords associated with negative news, filtering articles with the respective keywords out of the dictionary pulled from the API.

## Accomplishments that we're proud of

We managed to support a standard Bootstrap layout comprised of a grid consisting of rows and columns to enable both responsive design for compatibility purposes, and display more content on every device. Also utilized React functionality to enable randomized background gradients from a selection of pre-defined options to add variety to the site's appearance.

## What we learned

We learned a lot of valuable skills surrounding the aspect of remote group work. While designing this project, we were working across multiple frameworks and environments, which meant we couldn't rely on utilizing just one location for shared work. We made combined use of Repl.it for core HTML, CSS and Bootstrap and GitHub in conjunction with Visual Studio Code for the JavaScript and React workloads. While using these environments, we made use of Discord, IM Group Chats, and Zoom to allow for constant communication and breaking out into sub groups based on how work was being split up.

## What's next for The Good News

In the future, the next major feature to be incorporated is one which we titled "Travel the World". This feature will utilize Google's Places API to incorporate an embedded Google Maps window in a pop-up modal, which will allow the user to search or navigate and drop a pin anywhere around the world. The location information from the Places API will replace those provided by the IPStack API to provide positive news from the desired location. This feature aims to allow users to experience positive news from all around the world, rather than just their local community. We also want to continue iterating over our design to maximize the user experience.
## Inspiration

We are all software/game devs excited by new and unexplored game experiences. We originally came to PennApps thinking of building an Amazon shopping experience in VR, but eventaully pivoted to Project Em - a concept we all found mroe engaging. Our swtich was motivated by the same force that is driving us to create and improve Project Em - the desire to venture into unexplored territory, and combine technologies not often used together.

## What it does

Project Em is a puzzle exploration game driven by Amazon's Alexa API - players control their character with the canonical keyboard and mouse controls, but cannot accomplish anything relevant in the game without talking to a mysterious, unknown benefactor who calls out at the beginning of the game.

## How we built it

We used a combination of C++, Pyhon, and lots of shell scripting to create our project. The client-side game code runs on Unreal Engine 4, and is a combination of C++ classes and Blueprint (Epic's visual programming language) scripts. Those scripts and classes communicate an intermediary server running Python/Flask, which in turn communicates with the Alexa API. There were many challenges in communicating RESTfully out of a game engine (see below for more here), so the two-legged approach lent itself well to focusing on game logic as much as possible. Sacha and Akshay worked mostly on the Python, TCP socket, and REST communication platform, while Max and Trung worked mainly on the game, assets, and scripts.

The biggest challenge we faced was networking. Unreal Engine doesn't naively support running a webserver inside a game, so we had to think outside of the box when it came to networked communication.

The first major hurdle was to find a way to communicate from Alexa to Unreal - we needed to be able to communicate back the natural language parsing abilities of the Amazon API to the game. So, we created a complex system of runnable threads and sockets inside of UE4 to pipe in data (see challenges section for more info on the difficulties here). Next, we created a corresponding client socket creation mechanism on the intermediary Python server to connect into the game engine. Finally, we created a basic registration system where game clients can register their publicly exposed IPs and Ports to Python.

The second step was to communicate between Alexa and Python. We utilitzed [Flask-Ask](https://flask-ask.readthedocs.io/en/latest/) to abstract away most of the communication difficulties,. Next, we used [VaRest](https://github.com/ufna/VaRest), a plugin for handing JSON inside of unreal, to communicate from the game directly to Alexa.

The third and final step was to create a compelling and visually telling narrative for the player to follow. Though we can't describe too much of that in text, we'd love you to give the game a try :)

## Challenges we ran into

The challenges we ran into divided roughly into three sections:

* **Threading**: This was an obvious problem from the start. Game engines rely on a single main "UI" thread to be unblocked and free to process for the entirety of the game's life-cycle. Running a socket that blocks for input is a concept in direct conflict with that idiom. So, we dove into the FSocket documentation in UE4 (which, according to Trung, hasn't been touched since Unreal Tournament 2...) - needless to say it was difficult. The end solution was a combination of both FSocket and FRunnable that could block and certain steps in the socket process without interrupting the game's main thread. Lots of stuff like this happened:

```
while (StopTaskCounter.GetValue() == 0)
    {
        socket->HasPendingConnection(foo);
        while (!foo && StopTaskCounter.GetValue() == 0)
        {
            Sleep(1);
            socket->HasPendingConnection(foo);
        }
        // at this point there is a client waiting
        clientSocket = socket->Accept(TEXT("Connected to client.:"));
        if (clientSocket == NULL) continue;
        while (StopTaskCounter.GetValue() == 0)
        {
            Sleep(1);
            if (!clientSocket->HasPendingData(pendingDataSize)) continue;
            buf.Init(0, pendingDataSize);
            clientSocket->Recv(buf.GetData(), buf.Num(), bytesRead);
            if (bytesRead < 1) {
                UE_LOG(LogTemp, Error, TEXT("Socket did not receive enough data: %d"), bytesRead);
                return 1;
            }
            int32 command = (buf[0] - '0');
            // call custom event with number here
            alexaEvent->Broadcast(command);
            clientSocket->Close();
            break; // go back to wait state
        }
    }

```

Notice a few things here: we are constantly checking for a stop call from the main thread so we can terminate safely, we are sleeping to not block on Accept and Recv, and we are calling a custom event broadcast so that the actual game logic can run on the main thread when it needs to.

The second point of contention in threading was the Python server. Flask doesn't natively support any kind of global-to-request variables. So, the canonical approach of opening a socket once and sending info through it over time would not work, regardless of how hard we tried. The solution, as you can see from the above C++ snippet, was to repeatedly open and close a socket to the game on each Alexa call. This ended up causing a TON of problems in debugging (see below for difficulties there) and lost us a bit of time.

* **Network Protocols**: Of all things to deal with in terms of networks, we spent he largest amount of time solving the problems for which we had the least control. Two bad things happened: heroku rate limited us pretty early on with the most heavily used URLs (i.e. the Alexa responders). This prompted two possible solutions: migrate to DigitalOcean, or constantly remake Heroku dynos. We did both :). DigitalOcean proved to be more difficult than normal because the Alexa API only works with HTTPS addresses, and we didn't want to go through the hassle of using LetsEncrypt with Flask/Gunicorn/Nginx. Yikes. Switching heroku dynos it was.

The other problem we had was with timeouts. Depending on how we scheduled socket commands relative to REST requests, we would occasionally time out on Alexa's end. This was easier to solve than the rate limiting.

* **Level Design**: Our levels were carefully crafted to cater to the dual player relationship. Each room and lighting balance was tailored so that the player wouldn't feel totally lost, but at the same time, would need to rely heavily on Em for guidance and path planning.

## Accomplishments that we're proud of

The single largest thing we've come together in solving has been the integration of standard web protocols into a game engine. Apart from matchmaking and data transmission between players (which are both handled internally by the engine), most HTTP based communication is undocumented or simply not implemented in engines. We are very proud of the solution we've come up with to accomplish true bidirectional communication, and can't wait to see it implemented in other projects. We see a lot of potential in other AAA games to use voice control as not only an additional input method for players, but a way to catalyze gameplay with a personal connection.

On a more technical note, we are all so happy that...

THE DAMN SOCKETS ACTUALLY WORK YO

## Future Plans

We'd hope to incorporate the toolchain we've created for Project Em as a public GItHub repo and Unreal plugin for other game devs to use. We can't wait to see what other creative minds will come up with!

### Thanks

Much <3 from all of us, Sacha (CIS '17), Akshay (CGGT '17), Trung (CGGT '17), and Max (ROBO '16). Find us on github and say hello anytime.
## Inspiration

In North America alone, there are over 58 million people of all ages experiencing limited hand mobility. Our team strives to better facilitate the daily life for people who have the daunting task of overcoming their disabilities. We identified a disconcerting trend that rehabilitation options for people with limited motor function were too expensive. We challenged ourselves with developing an inexpensive therapeutic device to train fine motor skills, while also preserving normative routines within daily life.

## What it does

Xeri is a custom input device. Xeri allows for the translation of simple gestures into commands for a computer. Xeri requires a user to touch a specific digit to their thumbs in order to perform actions like right click, left click, scroll up, and scroll down. This touching action stimulates the muscle-mind connection enhancing it's ability to adapt to changes. With prolonged and consistent use of Xeri, patients will be able to see an improvement in their motor control. Xeri transforms the simple routine action of browsing the internet into a therapeutic medium that feels normal to the patient.

## How we built it

Xeri is composed of ESP32 Core v2, MPU6050 Gyroscope, four analog sensors, and four custom analog contacts. The ESP32 allows for bluetooth connection, the MPU allows for tracking of the hand, and the sensors and contacts allow for touch control. Xeri was developed in three prototype stages: P0, P1, and P2. In P0, we developed our custom analog sensors for our hands, created a rudimentary cardboard brace, and determined how to evaluate input. In P1, we replaced our cardboard brace with a simple gloved and modified to fit the needs of the hardware. In P2, we incorporated all elements of our hardware onto our glove and fully calibrated our gyroscope. Ultimately, we created a device that allows for therapeutic motion to be processed into computer input.

## Challenges we ran into

Xeri's development was not a trouble-free experience. We first encountered issues developing our custom analog contacts. We had trouble figuring out the necessary capacitance for the circuit, but through trial and error, we eventually succeeded. The biggest setback we had to mitigate was implementing our gyroscope into our code. The gyroscope we were using was not only cheap, but the chip was also defective. Our only solution was to work around this damage by reverse-engineering the supporting libraries once again

## Accomplishments that we're proud of

Our greatest achievement by far was being able to create a fully operable glove that could handle custom inputs. Although, Xeri is focused on hand mobility, the device could be implemented for a variety of focuses. Xeri's custom created analog contacts were another major achievement of ours due to their ability to measure analog signal using a Redbull can. One of our developers was very inspired by what we had built and spent some time researching and desiging an Apple Watch App that enables the watch to function as a similar device. This implementation can be found in our github for others to reference.

## What we learned

During the development process of Xeri, it was imperative that we had to be innovative with the little hardware we were able to obtain. We learned how to read and reverse-engineer hardware libraries. We also discovered how to create our own analog sensors and contacts. Overall, this project was incredibly rewarding as we truly developed a firm grasp on hardware devices.

## What's next for Xeri?

Xeri has a lot of room for improvement. Our first future development will be to make the device fully wireless, as we did not have a remote power source to utilize. Later updates would include, a replacement of the gyrosensor, a slimmed down fully uniform version, being able to change the resistance of each finger to promote muscle growth, and create more custom inputs for more accessibility.