Starting Off

 

This week we started off by deciding on what we wanted to pursue this project. We didn’t have too many ideas, but the first idea we have, we all agreed upon it and got started.

 

TLDR

​

* Initial Idea

* Interactive AR running game, that would allow people to run against themselves or friends

* Functionality/Design Choices

* Players able to record and upload their runs

* Selection of which run to choose to race against

* Points system for incentive

* Toggleable minimap between AR view and Map view

* API research

* Flask in order to create a database and retain information

* Need to create C# API script in order for login, account creation, fetching friends/run, uploads

 

Idea: Virtual Run

​

The idea we decided to go with is an AR app we currently call “Virtual Run”. In this app we wanted to spice up the act of running by appealing to people’s competitiveness. We decided a good way to do this would be by allowing the user to record and upload their runs, and then select runs between themselves or their friends in order to compete against them. While doing so, we wanted to allow the user to view a virtual avatar of the other runner as they compete.​

 

Functionality and User Flow

In order to determine how the app would look we first start designing a mock up via Figma (found here). The first screen we would have would be the login screen where the user is able to access their account and even create a new one. From there the user would be taken to the Home Screen where they can see their most recent run, and select if they wished to race themselves, or their friends. Upon selecting the “Solo Mode” button the user would be taken immediately to the race map, which is their GPS and the AR camera in a small window. If the user selects the “Race others” option, they would then be taken to a screen where they can select which person they’d like to race against (including their own self) and it would showcase the time the person had for their track. After selecting which person they want to race the user would then be taken to the map screen. From here we would have a menu button in which the user could select the options to record their race, clear the recording and flip which view takes precedence (between AR mode and Map mode). When the user records their race, a line generates the path they take. Once a user has a race recorded, they have the option to save and name their race. And once a user plays the recorded race, a virtual runner appears in the AR mode, and begins to follow the path created on the map mode, and the user can begin the race!

​

Currently we have implemented the basic functionality of the app, where the user can record their race, play it back and clear their recording. The user is also able to toggle their view.

​

APIs

​

As VirtualRun involves different individuals running against each other, we required a backend that allowed information from different user devices to be shared. Thus, we had to plan out the APIs, database schemas and the interfaces exposed to the Unity application.

Thereafter, we formally defined the SQL database schema for the entire project. As for APIs, we used the Flask framework and chose to focus this week on building the APIs that allowed the fetching and storing of run data and points. We then hosted the backend on PythonAnywhere.

On the client side, we used the System.Net library for the sending and receiving of http requests to our API endpoints as JSON data packets. All http code was encapsulated in a class and the interface was exposed via public member functions in order to abstract away the networking details from other parts of the code base.

​

Issues and Challenges

​

There are challenges integrating Mapbox with Unity's ARFoundation library. Ideally, an object placed within the world at a GPS coordinate should be viewable from a mobile device through the AR camera. However this is difficult as the AR camera has its own coordinate system which is different from the coordinate system of the Mapbox world, which is oriented towards the real world North. In addition, there are position discrepancies between the tracked pose, which error grows over time, and the phones GPS position. We need to spend more time familiarizing with the AR libraries to overcome this issue.

​

​

Financial Sustainability

We considered a user pay model but decided against it as it would discourage early adoption, especially given how our app promotes a significantly different running routine than what most people are used to. We instead settled on a freemium-sponsorship combination model. We would solicit sponsors in the athletic wear area such as Nike and Adidas by allowing them to advertise in the app. Instead of traditional banner type advertisements, the constant presence of an AR avatar allows more seamless product placement via the attire that the avatar is wearing. For instance, the avatar could wear a Nike shirt and Adidas shoes. In addition, we plan to provide power users with the option to customize their avatar's attire for a small fee. This will be implemented as custom items that the user can purchase and modify through an in-app store.