## Introduction

[Best Friends Animal Society](http://bestfriends.org)'s mission is to **bring about a time when there are No More Homeless Pets**

They have an ambitious goal of **reducing the death of homeless pets by 4 million/year**
(they are doing some amazing work in our local communities and definitely deserve more support from us)

## How this project fits in

Originally, I was only focusing on a very specific feature (adoption helper).

But after conversations with awesome folks at Best Friends came a realization that **bots can fit into a much bigger picture in how the organization is being run** to not only **save resources**, but also **increase engagement level** and **lower the barrier of entry points** for strangers to discover and become involved with the organization (volunteering, donating, etc.)

This "design hack" comprises of seven different features and use cases for integrating Facebook Messenger Bot to address Best Friends's organizational and operational needs with full mockups and animated demos:

1. Streamline volunteer sign-up process
2. Save human resource with FAQ bot
3. Lower the barrier for pet adoption
4. Easier donations
5. Increase visibility and drive engagement
6. Increase local event awareness
7. Realtime pet lost-and-found network

I also "designed" ~~(this is a design hack right)~~ the backend service architecture, which I'm happy to have discussions about too!

## How I built it

```
def design_hack():
    s = get_sketch()
    m = s.make_awesome_mockups()
    k = get_apple_keynote()
    return k.make_beautiful_presentation(m)

```

## Challenges I ran into

* Coming up with a meaningful set of features that can organically fit into the existing organization
* ~~Resisting the urge to write code~~

## What I learned

* Unique organizational and operational challenges that Best Friends is facing
* How to use Sketch
* How to create ~~quasi-~~prototypes with Keynote

## What's next for Messenger Bots' Best Friends

* Refine features and code :D
## Inspiration 🪙

Our project is inspired by the 2D puzzle simulation game genre, in which the player has to find and analyze evidence, make decisions, and draw conclusions all while being immersed in an ever-evolving story. We wanted to try to emulate some of the engaging aspects of these games, while focusing it on the topic of fraud detection, a prevalent theme at Hack Western 10.

## What it does 🎮

Our project immerses the player into the role of a tax auditor, who is tasked with evaluating the different cases that come before them. The first feature that can be utilized by the player to help assist them in their investigation is the ability to interact with different documents relevant to the case at hand. These documents can be enlarged and minimized by the player at will, and can be moved across the screen with ease. Secondly, a computer sits on the player’s virtual workspace, with icons for various social media platforms that can be interacted with, presenting the possibility of more evidence being uncovered. After reviewing the accumulated evidence thoroughly (or not), there are three decision buttons at the player’s disposal: Approve, Audit, or Fraud. In order to progress onto the next case, one of these buttons must be pressed. The goal that the player is striving for in our game is to successfully complete a set number of cases of varying difficulty before the end of their shift, helpfully denoted by the green bar at the top of the screen that depletes from full. At the end of said shift, bonuses or penalties are applied to the player’s score or “paycheck” depending on how many cases were correctly decided upon, as well as living expenses are subtracted from the total winnings at the end.

## How we built it

The sprites and the pixel art background were both made using Aseprite and LibreSprite. The actual gameplay and case details were designed in the game engine Godot, with the game mechanics being programmed in the engine’s built-in language GDScript. Audacity was used to edit audio to be implemented as sounds effects in our game.

## Challenges we ran into 🕹️

One challenge we overcame was balancing accuracy and entertainment in portraying the player’s role as a tax auditor. We focused on capturing the essential aspects of the role while incorporating engaging elements such as unique tax fraud scenarios and attractive visuals to keep players entertained and immersed in their gaming experience. Another challenge that arose was trying to implement the player’s ability to minimize and enlarge the different documents. The mechanic to do this would initially trigger when it collided with another document, causing it to glitch rapidly between an enlarged and a minimized state. This issue was overcome once a better understanding of how masks and layers interact in Godot. The number of assets that needed to be created for our game was also a challenge. However, this was addressed by dividing up the responsibilities of developing different assets to each team member.

## Accomplishments that we're proud of 👾

We are definitely most proud of being able to release a **fully functional demo** of a video game in this time frame. Going from whiteboard mockups to a playable release required maximum focus from every one of our team members. We required specific assets that are not available online, as well as uncommon game mechanics that are not simple to implement. Not to mention, this being our first hackathon really pushed us to put our best foot forward and have something amazing to showcase.

## What we learned 📺

There were many positive learning opportunities during the course of the development of Credit Crimes. Firstly, as this was each team member’s first hackathon experience, we all learned lessons about how to brainstorm, narrow down, then plan out an idea for a hackathon project. We developed our abilities to start with a broad, general outlook on a problem, then generate specific features we wanted to see implemented. We found that game design requires extensive and thorough planning beforehand, in order to identify what is most crucial to the type of game that is going to be made. On the technical side, this project exposed each team member to new game development and art platforms, such as the Godot engine and its built in programming language GDScript, and the sprite design tools Aseprite and LibreSprite. We also reinforced the value of utilizing online resources to learn and then implement unfamiliar concepts rapidly.

## What's next for Credit Crimes 🎲

While much has been accomplished, as a consequence of being a project developed on a tight timeline, there are a few things in Credit Crimes that will need to be implemented at a future time. Firstly, there is general debugging to do, as the game mechanics were worked on for only a relatively short amount of time, leaving room for improvement. Next, we would like to add YouTube and other applications to the list of social media platforms available to players during their investigation, to increase the potential evidence they could acquire thus enhancing their gaming experience. Additionally, we want to increase our catalogue of possible scenarios the player could come across. A couple of ways we plan to explore this is by introducing cases that are a little more “grey” i.e. more nuanced and difficult to discern what would be the right thing to do and what would be the wrong thing to do given certain pieces of evidence, as well as presenting scenarios where the player actually winds up finding out that the person they are investigating is actually owed money/has benefits from the government! Finally, designing and adding in new sprites and animations will serve to increase immersion and enhance the player experience, so we would include this in our list of future improvements.

## Special Thanks 🙌

A special thank you goes out to Thierry Zurcher and Alexandre Cloutier from the CRA booth this weekend for providing us with invaluable feedback for our game mechanics!

Shout out to Althea Krebelj and users of r/PixelArt, as some of the social media posts were taken from art posted there.
## Inspiration

The vicarious experiences of friends, and some of our own, immediately made clear the potential benefit to public safety the City of London’s dataset provides. We felt inspired to use our skills to make more accessible, this data, to improve confidence for those travelling alone at night.

## What it does

By factoring in the location of street lights, and greater presence of traffic, safeWalk intuitively presents the safest options for reaching your destination within the City of London. Guiding people along routes where they will avoid unlit areas, and are likely to walk beside other well-meaning citizens, the application can instill confidence for travellers and positively impact public safety.

## How we built it

There were three main tasks in our build.

1) Frontend:
Chosen for its flexibility and API availability, we used ReactJS to create a mobile-to-desktop scaling UI. Making heavy use of the available customization and data presentation in the Google Maps API, we were able to achieve a cohesive colour theme, and clearly present ideal routes and streetlight density.

2) Backend:
We used Flask with Python to create a backend that we used as a proxy for connecting to the Google Maps Direction API and ranking the safety of each route. This was done because we had more experience as a team with Python and we believed the Data Processing would be easier with Python.

3) Data Processing:
After querying the appropriate dataset from London Open Data, we had to create an algorithm to determine the “safest” route based on streetlight density. This was done by partitioning each route into subsections, determining a suitable geofence for each subsection, and then storing each lights in the geofence. Then, we determine the total number of lights per km to calculate an approximate safety rating.

## Challenges we ran into:

1) Frontend/Backend Connection:
Connecting the frontend and backend of our project together via RESTful API was a challenge. It took some time because we had no experience with using CORS with a Flask API.

2) React Framework
None of the team members had experience in React, and only limited experience in JavaScript. Every feature implementation took a great deal of trial and error as we learned the framework, and developed the tools to tackle front-end development. Once concepts were learned however, it was very simple to refine.

3) Data Processing Algorithms
It took some time to develop an algorithm that could handle our edge cases appropriately. At first, we thought we could develop a graph with weighted edges to determine the safest path. Edge cases such as handling intersections properly and considering lights on either side of the road led us to dismissing the graph approach.

## Accomplishments that we are proud of

Throughout our experience at Hack Western, although we encountered challenges, through dedication and perseverance we made multiple accomplishments. As a whole, the team was proud of the technical skills developed when learning to deal with the React Framework, data analysis, and web development. In addition, the levels of teamwork, organization, and enjoyment/team spirit reached in order to complete the project in a timely manner were great achievements

From the perspective of the hack developed, and the limited knowledge of the React Framework, we were proud of the sleek UI design that we created. In addition, the overall system design lent itself well towards algorithm protection and process off-loading when utilizing a separate back-end and front-end.

Overall, although a challenging experience, the hackathon allowed the team to reach accomplishments of new heights.

## What we learned

For this project, we learned a lot more about React as a framework and how to leverage it to make a functional UI. Furthermore, we refined our web-based design skills by building both a frontend and backend while also use external APIs.

## What's next for safewalk.io

In the future, we would like to be able to add more safety factors to safewalk.io. We foresee factors such as:
 Crime rate
 Pedestrian Accident rate
 Traffic density
 Road type