## Inspiration

We were inspired to make a text adventure based on Yale's campus and were inspired to take on Datto's challenge and make it less than 4 kb.

## What it does

Allows user to travel around Yale's campus and interact with characters and objects to make it to Yale's award ceremony.

## How I built it

We used Python.

## Challenges I ran into

Keeping the source code under four kilobytes.

## Accomplishments that I'm proud of

Successfully uploading then accessing the game's data online.

## What I learned

How to store game assets online and fetch them in real time.

## What's next for YHacks Adventure

A graphical user interface to allow better immersion for the user.
## Inspiration

We wanted to build something fun and challenging, using the knowledge we already had. We originally wanted to build a text-based game, since it was simpler and more within our skill level, but we decided to build 2D graphics in order to challenge ourselves.

## What it does

It's a game where you can fight enemies and explore the map. There was going to be enemies more weapons, a choice of characters, and more animations for the sprites but we ran out of time

## How we built it

We used Eclipse as an IDE to build the game from the ground up, with all the classes and the methods that run the game

## Challenges we ran into

One challenge we ran into was how we can have multiple people working on the code at once. So we decided we would each work on different classes, then spend some time at he end just bringing everything together. The biggest challenge, however, was our lack of experience. In all honesty, even though there are some problems, and the game is far from perfect, this is much more than we thought we were capable of and as such we are very proud.

## Accomplishments that we're proud of

We're proud of how, despite our basic knowledge of Java, we were able to build some more advanced things such as entity collisions, a camera that follows the player, and even a map that changes each time you play the game. As we mentioned above, our biggest achievement is how much we learned about Java. We only had a basic knowledge of Java before this hackathon but now we furthered our understanding of Java. In fact, most of our time was spent learning how to do things.

## What we learned

We learned how to build collisions, graphics, sprites, game states, packages, extended classes, tiles, and a moving camera to the game.

## What's next for Rogue Dungeon

Adding enemies, more maps, sounds, weapons, converting it to an executable java and monsters
## 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.